commit 93ee63dfc0db8d35d904a4cb8eca9cef8b4b569e Author: Alexandre Frade Date: Thu Jul 30 15:36:55 2026 +0000 Linux 6.18.41-rt-xanmod1 Signed-off-by: Alexandre Frade commit 3e27e81ebc48dfe8d687bf0c5b8497ee94423fba Merge: 4b8d52e3d233 929ca27d531b Author: Alexandre Frade Date: Thu Jul 30 15:36:10 2026 +0000 Merge branch '6.18' into 6.18-rt commit 929ca27d531ba69ca84ce6600ca8842a2d816928 Author: Alexandre Frade Date: Thu Jul 30 15:33:48 2026 +0000 Linux 6.18.41-xanmod1 Signed-off-by: Alexandre Frade commit 1c784dbe2a35f827f3f13c56c4200e835d212014 Merge: 44db62f5aa97 2fe596715f84 Author: Alexandre Frade Date: Thu Jul 30 15:32:27 2026 +0000 Merge tag 'v6.18.41' into 6.18 This is the 6.18.41 stable release commit 2fe596715f840d053aed5cee5455f701bdcd2b50 Author: Greg Kroah-Hartman Date: Thu Jul 30 13:05:57 2026 +0200 Linux 6.18.41 Signed-off-by: Greg Kroah-Hartman commit 6a7ecc25abe6f0fecc6e62a05096987200edbd02 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 Signed-off-by: Sasha Levin commit 9f7268928ac0c5306a05d60c02c551c4b7a27a6f 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 Signed-off-by: Sasha Levin commit 44db62f5aa976e16c6745ad2473ec0ec31180f17 Author: Alexandre Frade Date: Sat Jul 25 18:29:43 2026 +0000 Linux 6.18.40-xanmod1 Signed-off-by: Alexandre Frade commit 8b49b49d26aa386027dd6e70af65852ef99a8df5 Merge: 27e97e554390 221fc2f4d0ed Author: Alexandre Frade Date: Sat Jul 25 18:27:06 2026 +0000 Merge tag 'v6.18.40' into 6.18 This is the 6.18.40 stable release commit 221fc2f4d0eda59d02af2e751a9282fa013a8e97 Author: Greg Kroah-Hartman Date: Fri Jul 24 16:17:26 2026 +0200 Linux 6.18.40 Link: https://lore.kernel.org/r/20260721152514.750365251@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Peter Schneider Tested-by: Wentao Guan Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Pavel Machek (CIP) Link: https://lore.kernel.org/r/20260722142910.893804136@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Pavel Machek (CIP) Tested-by: Florian Fainelli Tested-by: Peter Schneider Tested-by: Wentao Guan Tested-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 478c4d24193fe3e6aa2accd4874ae43000e4a217 Author: Selvin Xavier Date: Mon Jun 15 15:47:47 2026 -0700 RDMA/bnxt_re: Avoid repeated requests to allocate WC pages commit 441baa79043431807115fd030d7d0bb14ed441a0 upstream. 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: Greg Kroah-Hartman commit b87cbd4d198ae377be4815d8102fa9dfefb91dcc Author: Selvin Xavier Date: Mon Jun 15 15:47:37 2026 -0700 RDMA/bnxt_re: Initialize dpi variable to zero commit 978b27d6ce538bb832ccd69e45802824e4301c4b upstream. 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: Greg Kroah-Hartman commit 81e6faa5b64058258caab8406a297e207e356e66 Author: Gil Portnoy Date: Thu May 28 00:00:00 2026 +0000 ksmbd: fix durable reconnect double-bind race in ksmbd_reopen_durable_fd commit 7ce4fc40018de07f05f3035241122d992610dbfb upstream. Two concurrent same-user DHnC reconnects can both observe fp->conn == NULL before either sets it. ksmbd_reopen_durable_fd() checks fp->conn to guard against a handle already being reconnected, but the check and the binding assignment are not atomic: both threads pass the guard, both call ksmbd_conn_get() on the same fp, and both eventually reach kfree(fp->owner.name) -- a double-free of the owner.name slab object. The double-bound ksmbd_file also causes a write-UAF on the 344-byte ksmbd_file_cache object when a concurrent smb2_close() spins on fp->f_lock after the object has been freed by the losing reconnect path. KASAN on 7.1-rc5 (48-thread concurrent reconnect, 3000 cycles): BUG: KASAN: double-free in ksmbd_reopen_durable_fd+0x268/0x308 BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xac/0x150 Write of size 4 at offset 24 into freed ksmbd_file_cache object Five double-bind windows observed; 63 total KASAN reports triggered. Fix: validate and claim fp->conn under write_lock(&global_ft.lock) so the check-and-claim is atomic. ksmbd_lookup_durable_fd() already treats fp->conn != NULL as "in use" and skips such an fp; setting fp->conn before dropping the lock closes the race. ksmbd_conn_get() is a non-sleeping refcount increment, safe under the rwlock. The rollback path on __open_id() failure also clears fp->conn/tcon under the lock so concurrent readers see a consistent state. Fixes: b1f1e80620de ("ksmbd: centralize ksmbd_conn final release to plug transport leak") Assisted-by: Henry (Claude):claude-opus-4 Signed-off-by: Gil Portnoy Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 1badb6866482d46634d7840447558943ddad6afb Author: Thomas Richter Date: Tue Apr 14 14:42:41 2026 +0200 perf callchain: Handle multiple address spaces commit ae15db3e9b639491007cc1e9e99638e4b6091781 upstream. 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: Greg Kroah-Hartman commit 275eb399309479399b24affb372482bc5bdc41a1 Author: Randy Dunlap Date: Fri Jan 23 10:37:49 2026 -0800 seqlock: fix scoped_seqlock_read kernel-doc commit f88a31308db6a856229150039b0f56d59696ed31 upstream. Eliminate all kernel-doc warnings in seqlock.h: - correct the macro to have "()" immediately following the macro name - don't include the macro parameters in the short description (first line) - make the parameter names in the comments match the actual macro parameter names. - use "::" for the Example WARNING: include/linux/seqlock.h:1341 This comment starts with '/**', but isn't a kernel-doc comment. * scoped_seqlock_read (lock, ss_state) - execute the read side critical Documentation/locking/seqlock:242: include/linux/seqlock.h:1351: WARNING: Definition list ends without a blank line; unexpected unindent. [docutils] Warning: include/linux/seqlock.h:1357 function parameter '_seqlock' not described in 'scoped_seqlock_read' Warning: include/linux/seqlock.h:1357 function parameter '_target' not described in 'scoped_seqlock_read' Fixes: cc39f3872c08 ("seqlock: Introduce scoped_seqlock_read()") Signed-off-by: Randy Dunlap Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260123183749.3997533-1-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman commit 453cb79a15641853170d3abc46021d8e88750b58 Author: Ian Rogers Date: Thu Jan 22 09:58:46 2026 -0800 perf inject: With --convert-callchain ignore the dummy event for dwarf stacks commit e786a04b4a5461dd7e2829422314a5a6d5a664d9 upstream. On hybrid systems there is generally >1 event and a dummy event. The perf inject --convert-callchain option is failing to convert perf.data files on such systems reporting "--convert-callchain requires DWARF call graph." The failing event is the dummy event that doesn't need to be set up for samples. As such ignore this event when checking the evsels. Fixes: 92ea788d2af4e65a ("perf inject: Add --convert-callchain option") Signed-off-by: Ian Rogers Tested-by: Arnaldo Carvalho de Melo Cc: Adrian Hunter Cc: Alexander Shishkin 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: Greg Kroah-Hartman commit 2764d031efd6d9cc6dbded9deee15026f97f8f9a Author: Ilpo Järvinen Date: Wed Jan 21 15:14:17 2026 +0200 PCI: Fix Resizable BAR restore order commit 5528fd38f230c906fcebb202cc94fbb8ed8f122a upstream. The commit 337b1b566db0 ("PCI: Fix restoring BARs on BAR resize rollback path") changed BAR resize to layer rebar code and resource setup/restore code cleanly. Unfortunately, it did not consider how the value of the BAR Size field impacts the read-only bits in the Base Address Register (PCIe7 spec, sec. 7.8.6.3). That is, it very much matters in which order the BAR Size and Base Address Register are restored. Post-337b1b566db0 ("PCI: Fix restoring BARs on BAR resize rollback path") during BAR resize rollback, pci_do_resource_release_and_resize() attempts to restore the old address to the BAR that was resized, but it can fail to setup the address correctly if the address has low bits set that collide with the bits that are still read-only. As a result, kernel's resource and BAR will be out-of-sync. Fix this by restoring BAR Size before rolling back the resource changes and restoring the BAR. Fixes: 337b1b566db0 ("PCI: Fix restoring BARs on BAR resize rollback path") Reported-by: Ville Syrjälä Link: https://lore.kernel.org/linux-pci/aW_w1oFQCzUxGYtu@intel.com/ Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Ville Syrjälä Reviewed-by: Ville Syrjälä Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260121131417.9582-3-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 2fb74141ec54e1174b89260c8217cff7868ea5ad Author: Ilpo Järvinen Date: Wed Jan 21 15:14:16 2026 +0200 PCI: Fix BAR resize rollback path overwriting ret commit 08d9eae76b85263173f8c833800e3cc409ee1be4 upstream. The commit 337b1b566db0 ("PCI: Fix restoring BARs on BAR resize rollback path") added BAR rollback to pci_do_resource_release_and_resize() in case of resize failure. On the rollback, pci_claim_resource() is called, which can fail and the code is prepared for that possibility. pci_claim_resource()'s return value, however, overwrites the original value of ret so pci_do_resource_release_and_resize() will return an incorrect value in the end (as pci_claim_resource() normally succeeds, in practice ret will be 0). Fix the issue by directly calling pci_claim_resource() inside the if (). Fixes: 337b1b566db0 ("PCI: Fix restoring BARs on BAR resize rollback path") Reported-by: Ville Syrjälä Link: https://lore.kernel.org/linux-pci/aW_w1oFQCzUxGYtu@intel.com/ Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Ville Syrjälä Reviewed-by: Ville Syrjälä Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260121131417.9582-2-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 7425e7d82cb93c555ee947c381255265ab614d71 Author: Ian Rogers Date: Sat Dec 6 18:23:45 2025 -0800 perf symbol: Fix ENOENT case for filename__read_build_id commit 5c5f6fe32df2edb4f72bdca62ec2b9f20b7c5ba4 upstream. Some callers of filename__read_build_id assume the error value must be -1, fix by making them handle all < 0 values. If is_regular_file fails in filename__read_build_id then it could be the file is missing (ENOENT) and it would be wrong to return -EWOULDBLOCK in that case. Fix the logic so -EWOULDBLOCK is only reported if other errors with stat haven't occurred. Fixes: 834ebb5678d7 ("perf tools: Don't read build-ids from non-regular files") Signed-off-by: Ian Rogers Reviewed-by: James Clark Signed-off-by: Namhyung Kim Signed-off-by: Greg Kroah-Hartman commit a888f3d5970ff21e092bc9edcf3d9ffee9ae68a7 Author: Chukun Pan Date: Sat Nov 15 18:00:00 2025 +0800 pinctrl: airoha: fix pinctrl function mismatch issue commit f2bd5a0f59d052d16749bccf637690e51947a5d6 upstream. The blamed commit made the following changes: -#define PINCTRL_FUNC_DESC(id)... - .desc = PINCTRL_PINFUNCTION(#id, ... +#define PINCTRL_FUNC_DESC(id, table)... + .desc = PINCTRL_PINFUNCTION(#id, ... - PINCTRL_FUNC_DESC(pon)... + PINCTRL_FUNC_DESC("pon", pon)... It's clear that the id of funcs doesn't match the definition. Remove redundant #string from the definition to fix this issue: pinctrl-airoha ...: invalid function mdio in map table Fixes: 4043b0c45f85 ("pinctrl: airoha: generalize pins/group/function/confs handling") Signed-off-by: Chukun Pan Acked-by: Christian Marangi Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 267fdd9b6530c399dfd996e1a0a7628b45baf9f0 Author: Matt Bobrowski Date: Tue Jul 21 07:47:00 2026 -0400 bpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is uninitialized [ Upstream commit a6f0643e4f63cfaa0d5d4a69de4f132eac4b8fe4 ] When CONFIG_BPF_LSM=y is set, BPF inode storage maps (BPF_MAP_TYPE_INODE_STORAGE) are compiled into the kernel. However, if the BPF LSM is not explicitly enabled at boot time (e.g. omitted from the "lsm=" boot parameter), lsm_prepare() is never executed for the BPF LSM. Consequently, the BPF inode security blob offset (bpf_lsm_blob_sizes.lbs_inode) is never initialized and remains at its default compiled size of 8 bytes instead of being updated to a valid offset past the reserved struct rcu_head (typically 16 bytes or more). When a privileged user creates and updates a BPF_MAP_TYPE_INODE_STORAGE map, bpf_inode() evaluates inode->i_security + 8. This erroneously aliases the struct rcu_head.func callback pointer at the beginning of the inode->i_security blob. During subsequent map element cleanup or inode destruction, writing NULL to owner_storage clears the queued RCU callback pointer. When rcu_do_batch() later executes the queued callback, it attempts an instruction fetch at address 0x0, triggering an immediate kernel panic. Fix this by introducing a global bpf_lsm_initialized boolean flag marked with __ro_after_init. Set this flag to true inside bpf_lsm_init() when the LSM framework successfully registers the BPF LSM. Gate map allocation in inode_storage_map_alloc() on this flag, returning -EOPNOTSUPP if the BPF LSM is in turn uninitialized. This fail-fast approach prevents userspace from allocating inode storage maps when the supporting BPF LSM infrastructure is absent, avoiding zombie map states. Fixes: 8ea636848aca ("bpf: Implement bpf_local_storage for inodes") Reported-by: oxsignal Signed-off-by: Matt Bobrowski Signed-off-by: Daniel Borkmann Reviewed-by: Emil Tsalapatis Reviewed-by: Amery Hung Link: https://lore.kernel.org/bpf/20260628201103.3624525-1-mattbobrowski@google.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 779480ea79551c31964e74b9aef0e730faa3aa11 Author: Nicolin Chen Date: Tue Jul 21 08:22:46 2026 -0400 iommufd: Move vevent memory allocation outside spinlock [ Upstream commit 47443565d10c51366c9382dbc8597cd6c460b8a2 ] The veventq memory allocation happens inside the spinlock. Given its depth is decided by the user space, this leaves a vulnerability, where userspace can allocate large queues to exhaust atomic memory reserves. Move the allocation outside the spinlock and use GFP_NOWAIT, which can fail fast under memory pressure without dipping into the GFP_ATOMIC reserves or direct-reclaiming from the threaded IRQ handler. On allocation failure, queue the lost_events_header (so userspace learns of the drop) and return -ENOMEM so the caller learns of the kernel-side memory pressure. This is intentionally distinct from the queue-overflow path, which also queues the lost_events_header but returns 0: a full queue is an expected userspace-pacing condition rather than a kernel error. A subsequent change will cap the upper bound of the veventq_depth. Fixes: e36ba5ab808e ("iommufd: Add IOMMUFD_OBJ_VEVENTQ and IOMMUFD_CMD_VEVENTQ_ALLOC") Link: https://patch.msgid.link/r/5ff36b5d80f7f6299f851be532a5195c1d2f1dae.1779408671.git.nicolinc@nvidia.com Cc: stable@vger.kernel.org Reviewed-by: Jason Gunthorpe Signed-off-by: Nicolin Chen Reviewed-by: Kevin Tian Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 73b5d5cb1f5a1273dc3f0bb86e5a65527c3ec0c3 Author: Nicolin Chen Date: Tue Jul 21 08:22:50 2026 -0400 iommufd: Propagate allocation failure in iommufd_veventq_deliver_fetch() [ Upstream commit 489e63dd120bad52eba63f5506c214750cd5bc75 ] When the kzalloc_obj() fails in iommufd_veventq_deliver_fetch(), it returns NULL, falsely advertising to userspace that the queue is empty. Propagate the -ENOMEM properly to the caller. Fixes: e36ba5ab808e ("iommufd: Add IOMMUFD_OBJ_VEVENTQ and IOMMUFD_CMD_VEVENTQ_ALLOC") Link: https://patch.msgid.link/r/25d29feac909e36f78c145fa99ef2d4cb7a415da.1780343944.git.nicolinc@nvidia.com Cc: stable@vger.kernel.org Signed-off-by: Nicolin Chen Reviewed-by: Pranjal Shrivastava Reviewed-by: Kevin Tian Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ea7a76d7d614b5f82b4d0785f9af3550e860a71a 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 459adfc6cd35f70fc9df3ac53c9930dad18580d0 Author: Marc Zyngier Date: Wed Feb 25 10:47:18 2026 +0000 KVM: arm64: Deduplicate ASID retrieval code commit 54e367cb94d6bef941bbc1132d9959dc73bd4b6f upstream. We currently have three versions of the ASID retrieval code, one in the S1 walker, and two in the VNCR handling (although the last two are limited to the EL2&0 translation regime). Make this code common, and take this opportunity to also simplify the code a bit while switching over to the TTBRx_EL1_ASID macro. Reviewed-by: Joey Gouly Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/20260225104718.14209-1-maz@kernel.org [maz: cherry-pick as dependency of bb645aa0a4caeaf7f9cd32e9a948594d434c1a8f] Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 9d360fb820a3b9576d155e720ec44fef54d2efb5 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: Greg Kroah-Hartman commit ec976851ad93432bdbd0c53ec1348909d5366622 Author: SeongJae 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: Greg Kroah-Hartman commit 3b91c35961fa5553b4dd36db1f06e3b4acbfc05d Author: SeongJae 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 ba37cd4d8a7519677b317d89fa4de87ae1452099 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 19d9996435db84596e9f6e0a0c22489ec88dbb1c 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 c3a3d3986719026c85950bfa6f41a251fc46e16f Author: Qu Wenruo Date: Mon Jul 20 12:51:15 2026 -0400 btrfs: fix incorrect buffered IO fallback for append direct writes [ Upstream commit ff66fe6662330226b3f486014c375538d91c44aa ] [BUG] With the previous bug of short direct writes fixed, test case generic/362 (*) still fails with the following error with nodatasum mount option: # generic/362 0s ... - output mismatch (see /home/adam/xfstests/results//generic/362.out.bad) # - output mismatch (see /home/adam/xfstests/results//generic/362.out.bad) # --- tests/generic/362.out 2024-08-24 15:31:37.200000000 +0930 # +++ /home/adam/xfstests/results//generic/362.out.bad 2026-05-27 10:13:09.072485767 +0930 # @@ -1,2 +1,3 @@ # QA output created by 362 # +Wrong file size after first write, got 8192 expected 4096 # Silence is golden # ... *: If the test case has been executed before with default data checksum, the failure will not reproduce. Need the following fix to make it reliably reproducible: https://lore.kernel.org/linux-btrfs/20260528111659.87113-1-wqu@suse.com/ [CAUSE] Inside btrfs_dio_iomap_begin() for a direct write, we increase the isize if it's beyond the current isize. But if the direct io finished short, we do not revert the isize to the previous value nor to the short write end. Then if we need to fall back to buffered writes, and the write has IOCB_APPEND flag, then the buffered write will be positioned at the incorrect isize. The call chain looks like this: btrfs_direct_write(pos=0, length=4K) |- __iomap_dio_rw() | |- iomap_iter() | | |- btrfs_dio_iomap_begin() | | |- btrfs_get_blocks_direct_write() | | |- i_size_write() | | Which updates the isize to the write end (4K). | | | |- iomap_dio_iter() | | Failed with -EFAULT on the first page. | | | |- iomap_iter() | | |- btrfs_dio_iomap_end() | | Detects a short write, return -ENOTBLK | |- if (ret == -ENOTBLK) { ret = 0;} | Which resets the return value. | |- ret = iomap_dio_complet() | Which returns 0. | |- btrfs_buffered_write(iocb, from); |- generic_write_checks() |- iocb->ki_pos = i_size_read() Which is still the new size (4K), other than the original isize 0. [FIX] Introduce the following btrfs_dio_data members: - old_isize - updated_isize If the direct write has enlarged the isize. Then if we got a short write, and btrfs_dio_data::updated_isize is set, revert to the correct isize based on old_isize and current file position. And here we call i_size_write() without holding an extent lock, which is a very special case that we're safe to do: - Only a single writer can be enlarging isize Enlarging isize will take the exclusive inode lock. - Buffered readers need to wait for the OE we're holding Buffered readers will lock extent and wait for OE of the folio range. Sometimes we can skip the OE wait, but since all page cache is invalidated, the OE wait can not be skipped. But I do not think this is the most elegant solution, nor covers all cases. E.g. if the bio is submitted but IO failed, we are unable to do the revert. I believe the more elegant one would be extend the EXTENT_DIO_LOCKED lifespan for direct writes, so that we can update the isize when a write beyond EOF finished successfully. However that change is too huge for a small bug fix. So only implement the minimal partial fix for now. [REASON FOR NO FIXES TAG] The bug is again very old, before commit f85781fb505e ("btrfs: switch to iomap for direct IO") we are already increasing isize without a proper rollback for short writes. Thus only a CC to stable. CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Boris Burkov Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 998ee7f01ecfae48f32ffe790644ac237fe54886 Author: Qu Wenruo Date: Mon Jul 20 11:01:09 2026 -0400 btrfs: fix false IO failure after falling back to buffered write [ Upstream commit 66ff4d366e7eb4d31813d2acabf3af512ce03aa5 ] [BUG] The test case generic/362 will fail with "nodatasum" mount option (*): MOUNT_OPTIONS -- -o nodatasum /dev/mapper/test-scratch1 /mnt/scratch # generic/362 0s ... - output mismatch (see /home/adam/xfstests/results//generic/362.out.bad) # --- tests/generic/362.out 2024-08-24 15:31:37.200000000 +0930 # +++ /home/adam/xfstests/results//generic/362.out.bad 2026-05-27 10:21:17.574771567 +0930 # @@ -1,2 +1,3 @@ # QA output created by 362 # +First write failed: Input/output error # Silence is golden # ... *: If the test case has been executed before with default data checksum, the failure will not reproduce. Need the following fix to make it reliably reproducible: https://lore.kernel.org/linux-btrfs/20260528111659.87113-1-wqu@suse.com/ [CAUSE] Inside __iomap_dio_rw(), the -EFAULT/-ENOTBLK error is not directly returned. Thus we never got an error pointer from __iomap_dio_rw(). The call chain looks like this: btrfs_direct_write() |- btrfs_dio_write() |- __iomap_dio_rw() | |- iomap_iter() | | |- btrfs_dio_iomap_begin() | | Now an ordered extent is allocated for the 4K write. | | | |- iomi.status = iomap_dio_iter() | | Where iomap_dio_iter() returned -EFAULT. | | | |- ret = iomap_iter() | | |- btrfs_dio_iomap_end() | | | |- btrfs_finish_ordered_extent(uptodate = false) | | | | |- can_finish_ordered_extent() | | | | |- btrfs_mark_ordered_extent_error() | | | | |- mapping_set_error() | | | | Now the address space is marked error. | | | | return -ENOTBLK | | |- return -ENOTBLK | |- if (ret == -ENOTBLK) { ret = 0; } | Now the return value is reset to 0. | Thus no error pointer will be returned. | |- ret = iomap_dio_complete() | Since no byte is submitted, @ret is 0. | |- Fallback to buffered IO | And the buffered write finished without error | |- filemap_fdatawait_range() |- filemap_check_errors() The previous error is recorded, thus an error is returned However the buffered write is properly submitted and finished, the error is from the btrfs_finish_ordered_extent() call with @uptodate = false. [FIX] When a short dio write happened, any range that is submitted will have btrfs_extract_ordered_extent() to be called, thus the submitted range will always have an OE just covering the submitted range. The remaining OE range is never submitted, thus they should be treated as truncated, not an error. So that we can properly reclaim and not insert an unnecessary file extent item, without marking the mapping as error. Extract a helper, btrfs_mark_ordered_extent_truncated(), and utilize that helper to mark the direct IO ordered extent as truncated, so it won't cause failure for the later buffered fallback. [REASON FOR NO FIXES TAG] The bug itself is pretty old, at commit f85781fb505e ("btrfs: switch to iomap for direct IO") we're already passing @uptodate=false finishing the OE. But at that time OE with IOERR won't call mapping_set_error(), so it's not exposed. Later commit d61bec08b904 ("btrfs: mark ordered extent and inode with error if we fail to finish") finally exposed the bug, but that commit is doing a correct job, not the root cause. Anyway the bug is very old, dating back to 5.1x days, thus only CC to stable. CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Boris Burkov Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a4497a122e27f125ee650315d47942f9eaa5cb27 Author: Ahsan Atta Date: Mon Jul 20 14:08:35 2026 -0400 crypto: qat - fix restarting state leak on allocation failure [ Upstream commit 7d3ed20f7e46b3e991936fedd7a28f3ff4aec8d2 ] In adf_dev_aer_schedule_reset(), ADF_STATUS_RESTARTING is set before allocating reset_data. If the allocation fails, the function returns -ENOMEM without queuing reset work, so nothing ever clears the bit. This leaves the device permanently stuck in the restarting state, causing all subsequent reset attempts to be silently skipped. Fix this by using test_and_set_bit() to atomically claim the RESTARTING state, preventing duplicate reset scheduling races under concurrent fatal error reporting. If the subsequent allocation fails, clear the bit to restore clean state so future reset attempts can proceed. Cc: stable@vger.kernel.org Fixes: d8cba25d2c68 ("crypto: qat - Intel(R) QAT driver framework") Signed-off-by: Ahsan Atta Co-developed-by: Maksim Lukoshkov Signed-off-by: Maksim Lukoshkov Reviewed-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6c78081d047c59222317f717882e7ad2bd6ae318 Author: Qu Wenruo Date: Mon Jul 20 11:01:08 2026 -0400 btrfs: remove folio parameter from ordered io related functions [ Upstream commit a11d6912fdd9e57aff889ec97256b1d6b4e5bf06 ] Both functions btrfs_finish_ordered_extent() and btrfs_mark_ordered_io_finished() are accepting an optional folio parameter. That @folio is passed into can_finish_ordered_extent(), which later will test and clear the ordered flag for the involved range. However I do not think there is any other call site that can clear ordered flags of an page cache folio and can affect can_finish_ordered_extent(). There are limited *_clear_ordered() callers out of can_finish_ordered_extent() function: - btrfs_migrate_folio() This is completely unrelated, it's just migrating the ordered flag to the new folio. - btrfs_cleanup_ordered_extents() We manually clean the ordered flags of all involved folios, then call btrfs_mark_ordered_io_finished() without a @folio parameter. So it doesn't need and didn't pass a @folio parameter in the first place. - btrfs_writepage_fixup_worker() This function is going to be removed soon, and we should not hit that function anymore. - btrfs_invalidate_folio() This is the real call site we need to bother with. If we already have a bio running, btrfs_finish_ordered_extent() in end_bbio_data_write() will be executed first, as btrfs_invalidate_folio() will wait for the writeback to finish. Thus if there is a running bio, it will not see the range has ordered flags, and just skip to the next range. If there is no bio running, meaning the ordered extent is created but the folio is not yet submitted. In that case btrfs_invalidate_folio() will manually clear the folio ordered range, but then manually finish the ordered extent with btrfs_dec_test_ordered_pending() without bothering the folio ordered flags. Meaning if the OE range with folio ordered flags will be finished manually without the need to call can_finish_ordered_extent(). This means all can_finish_ordered_extent() call sites should get a range that has folio ordered flag set, thus the old "return false" branch should never be triggered. Now we can: - Remove the @folio parameter from involved functions * btrfs_mark_ordered_io_finished() * btrfs_finish_ordered_extent() For call sites passing a @folio into those functions, let them manually clear the ordered flag of involved folios. - Move btrfs_finish_ordered_extent() out of the loop in end_bbio_data_write() We only need to call btrfs_finish_ordered_extent() once per bbio, not per folio. - Add an ASSERT() to make sure all folio ranges have ordered flags It's only for end_bbio_data_write(). And we already have enough safe nets to catch over-accounting of ordered extents. Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Stable-dep-of: 66ff4d366e7e ("btrfs: fix false IO failure after falling back to buffered write") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1a648c50a5057e6a71b49a954ef438fd8aa22eb6 Author: Qu Wenruo Date: Mon Jul 20 11:01:07 2026 -0400 btrfs: replace for_each_set_bit() with for_each_set_bitmap() [ Upstream commit e6698b34fab33867ef3faeeea6feb165f31aae24 ] Inside extent_io.c, there are several simple call sites doing things like: for_each_set_bit(bit, bitmap, bitmap_size) { /* handle one fs block */ } The workload includes: - set_bit() Inside extent_writepage_io(). This can be replaced with a bitmap_set(). - btrfs_folio_set_lock() - btrfs_mark_ordered_io_finished() Inside writepage_delalloc(). Instead of calling it multiple times, we can pass a range into the function with one call. Reviewed-by: Boris Burkov Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Stable-dep-of: 66ff4d366e7e ("btrfs: fix false IO failure after falling back to buffered write") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 99d4ae3fbb5b198c6d5eac5a45f2ad4b46ecaf56 Author: Qu Wenruo Date: Mon Jul 20 11:01:06 2026 -0400 btrfs: concentrate the error handling of submit_one_sector() [ Upstream commit 44820d80026e0b509007d41c83d42f1213ee8589 ] Currently submit_one_sector() has only one failure path from btrfs_get_extent(). However the error handling is split into two parts, one inside submit_one_sector(), which clears the dirty flag and finishes the writeback for the fs block. The other part is to submit any remaining bio inside bio_ctrl and mark the ordered extent finished for the fs block. There is no special reason that we must split the error handling, let's just concentrate all the error handling into submit_one_sector(). Reviewed-by: Boris Burkov Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Stable-dep-of: 66ff4d366e7e ("btrfs: fix false IO failure after falling back to buffered write") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 382fd8004cc6004842a6a9772f16b2750207c2a0 Author: Thorsten Blum Date: Mon Jul 20 09:30:39 2026 -0400 crypto: atmel-sha204a - fail on hwrng registration error in probe path [ Upstream commit 49e05bb00f2e8168695f7af4d694c39e1423e8a2 ] Commit 13909a0c8897 ("crypto: atmel-sha204a - provide the otp content") overwrote the hwrng registration return value when creating the sysfs group, which allowed atmel_sha204a_probe() to succeed even if devm_hwrng_register() failed. Return immediately when devm_hwrng_register() fails, and report both hwrng and sysfs registration errors with dev_err(). Adjust the sysfs error log message for consistency. Fixes: 13909a0c8897 ("crypto: atmel-sha204a - provide the otp content") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 952db4b985c798c3791aa0151654c57fe781d65a Author: Neill Kapron Date: Mon Jul 20 06:54:48 2026 -0400 usb: gadget: f_fs: Tie read_buffer lifetime to ffs_epfile [ Upstream commit 8bdcf96eb135aebacac319667f87db034fb38406 ] Currently, ffs_epfile_release unconditionally frees the endpoint's read_buffer when a file descriptor is closed. If userspace explicitly opens the endpoint multiple times and closes one, the read_buffer is destroyed. This can lead to silent data loss if other file descriptors are still actively reading from the endpoint. By tying the lifetime of the read_buffer to the ffs_epfile structure itself (which is destroyed when the functionfs instance is torn down in ffs_epfiles_destroy), we eliminate the brittle dependency on open/release calls while correctly matching the conceptual lifetime of unread data on the hardware endpoint. Fixes: 9353afbbfa7b ("usb: gadget: f_fs: buffer data from ‘oversized’ OUT requests") Cc: stable Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Neill Kapron Link: https://patch.msgid.link/20260619040609.4010746-3-nkapron@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 69faa3779250df14f51d5084f938a99809546e52 Author: Tyler Baker Date: Sun Jul 19 22:25:51 2026 -0400 usb: gadget: f_fs: initialize reset_work at allocation time [ Upstream commit 3137b243c93982fe3460335e12f9247739766e10 ] ffs_fs_kill_sb() unconditionally calls cancel_work_sync() on ffs->reset_work when a functionfs instance is unmounted: ffs_data_reset(ffs); cancel_work_sync(&ffs->reset_work); However ffs->reset_work is only ever initialized via INIT_WORK() in ffs_func_set_alt() and ffs_func_disable(), and only on the FFS_DEACTIVATED path. That state is reached solely by ffs_data_closed() when the instance is mounted with the "no_disconnect" option, so for the common case (no "no_disconnect", or mounted and unmounted without ever being deactivated) reset_work is never initialized. ffs_data_new() allocates the ffs_data with kzalloc_obj() and does not initialize reset_work, and ffs_data_reset()/ffs_data_clear() do not touch it either, so reset_work.func is left NULL. cancel_work_sync() on such a work then trips the WARN_ON(!work->func) guard in __flush_work(): WARNING: kernel/workqueue.c:4301 at __flush_work+0x330/0x360, CPU#3: umount Call trace: __flush_work cancel_work_sync ffs_fs_kill_sb [usb_f_fs] deactivate_locked_super deactivate_super cleanup_mnt __cleanup_mnt task_work_run exit_to_user_mode_loop el0_svc On older kernels cancel_work_sync() on a zero-initialized work struct was a silent no-op, which hid the missing initialization. Initialize reset_work once in ffs_data_new() so it is always valid for the lifetime of the ffs_data, and drop the now-redundant INIT_WORK() calls from the two deactivation paths. Fixes: 18d6b32fca38 ("usb: gadget: f_fs: add "no_disconnect" mode") Cc: stable Signed-off-by: Tyler Baker Cc: Loic Poulain Cc: Dmitry Baryshkov Cc: Srinivas Kandagatla Tested-by: Loic Poulain Reviewed-by: Peter Chen Acked-by: Michał Nazarewicz Link: https://patch.msgid.link/20260609193635.2284430-1-tyler.baker@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8a2fdbf92cdc7d523a8d43823d96a4da1bfe6518 Author: Al Viro Date: Sun Jul 19 22:25:50 2026 -0400 functionfs: use spinlock for FFS_DEACTIVATED/FFS_CLOSING transitions [ Upstream commit 2005aabe94eaab8608879d98afb901bc99bc3a31 ] When all files are closed, functionfs needs ffs_data_reset() to be done before any further opens are allowed. During that time we have ffs->state set to FFS_CLOSING; that makes ->open() fail with -EBUSY. Once ffs_data_reset() is done, it switches state (to FFS_READ_DESCRIPTORS) indicating that opening that thing is allowed again. There's a couple of additional twists: * mounting with -o no_disconnect delays ffs_data_reset() from doing that at the final ->release() to the first subsequent open(). That's indicated by ffs->state set to FFS_DEACTIVATED; if open() sees that, it immediately switches to FFS_CLOSING and proceeds with doing ffs_data_reset() before returning to userland. * a couple of usb callbacks need to force the delayed transition; unfortunately, they are done in locking environment that does not allow blocking and ffs_data_reset() can block. As the result, if these callbacks see FFS_DEACTIVATED, they change state to FFS_CLOSING and use schedule_work() to get ffs_data_reset() executed asynchronously. Unfortunately, the locking is rather insufficient. A fix attempted in e5bf5ee26663 ("functionfs: fix the open/removal races") had closed a bunch of UAF, but it didn't do anything to the callbacks, lacked barriers in transition from FFS_CLOSING to FFS_READ_DESCRIPTORS _and_ it had been too heavy-handed in open()/open() serialization - I've used ffs->mutex for that, and it's being held over actual IO on ep0, complete with copy_from_user(), etc. Even more unfortunately, the userland side is apparently racy enough to have the resulting timing changes (no failures, just a delayed return of open(2)) disrupt the things quite badly. Userland bugs or not, it's a clear regression that needs to be dealt with. Solution is to use a spinlock for serializing these state checks and transitions - unlike ffs->mutex it can be taken in these callbacks and it doesn't disrupt the timings in open(). We could introduce a new spinlock, but it's easier to use the one that is already there (ffs->eps_lock) instead - the locking environment is safe for it in all affected places. Since now it is held over all places that alter or check the open count (ffs->opened), there's no need to keep that atomic_t - int would serve just fine and it's simpler that way. Fixes: e5bf5ee26663 ("functionfs: fix the open/removal races") Fixes: 18d6b32fca38 ("usb: gadget: f_fs: add "no_disconnect" mode") # v4.0 Tested-by: Samuel Wu Signed-off-by: Al Viro Stable-dep-of: 3137b243c939 ("usb: gadget: f_fs: initialize reset_work at allocation time") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5fb0b09180a0fff9a8891d31484cce6456138668 Author: Al Viro Date: Sun Jul 19 22:25:49 2026 -0400 functionfs: switch to simple_remove_by_name() [ Upstream commit c7747fafaba0dcdad3d7da240e961927b4865f98 ] No need to return dentry from ffs_sb_create_file() or keep it around afterwards. To avoid subtle issues with getting to ffs from epfiles in ffs_epfiles_destroy(), pass the superblock as explicit argument. Callers have it anyway. Reviewed-by: Greg Kroah-Hartman Signed-off-by: Al Viro Stable-dep-of: 3137b243c939 ("usb: gadget: f_fs: initialize reset_work at allocation time") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4744f07f6bb7cdf07349666d06059da4626a5000 Author: Al Viro Date: Sun Jul 19 22:25:48 2026 -0400 functionfs: don't bother with ffs->ref in ffs_data_{opened,closed}() [ Upstream commit fe47466282a69499ae17a22f064e827badb77078 ] A reference is held by the superblock (it's dropped in ffs_kill_sb()) and filesystem will not get to ->kill_sb() while there are any opened files, TYVM... Reviewed-by: Greg Kroah-Hartman Signed-off-by: Al Viro Stable-dep-of: 3137b243c939 ("usb: gadget: f_fs: initialize reset_work at allocation time") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 901c036cf6254cde695956c015ac89559bf72489 Author: Al Viro Date: Sun Jul 19 22:25:47 2026 -0400 functionfs: don't abuse ffs_data_closed() on fs shutdown [ Upstream commit fcb8985143540cbcb8e91c0ea8b7fb5d37c88177 ] ffs_data_closed() has a seriously confusing logics in it: in addition to the normal "decrement a counter and do some work if it hits zero" there's "... and if it has somehow become negative, do that" bit. It's not a race, despite smelling rather fishy. What really happens is that in addition to "call that on close of files there, to match the increments of counter on opens" there's one call in ->kill_sb(). Counter starts at 0 and never goes negative over the lifetime of filesystem (or we have much worse problems everywhere - ->release() call of some file somehow unpaired with successful ->open() of the same). At the filesystem shutdown it will be 0 or, again, we have much worse problems - filesystem instance destroyed with files on it still open. In other words, at that call and at that call alone the decrement would go from 0 to -1, hitting that chunk (and not hitting the "if it hits 0" part). So that check is a weirdly spelled "called from ffs_kill_sb()". Just expand the call in the latter and kill the misplaced chunk in ffs_data_closed(). Reviewed-by: Greg Kroah-Hartman Signed-off-by: Al Viro Stable-dep-of: 3137b243c939 ("usb: gadget: f_fs: initialize reset_work at allocation time") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c3e6860252102922205cb33f7f2be55b902f6180 Author: Al Viro Date: Sun Jul 19 22:25:46 2026 -0400 new helper: simple_remove_by_name() [ Upstream commit 4051a9115ad24bb9a691774730ca9c1dd56de665 ] simple_recursive_removal(), but instead of victim dentry it takes parent + name. Used to be open-coded in fs/fuse/control.c, but there's no need to expose the guts of that thing there and there are other potential users, so let's lift it into libfs... Acked-by: Miklos Szeredi Signed-off-by: Al Viro Stable-dep-of: 3137b243c939 ("usb: gadget: f_fs: initialize reset_work at allocation time") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 509b51327320bdeaef1969248177a446ded073ab Author: Mauricio Faria de Oliveira Date: Sun Jul 19 08:43:48 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 b78826a657998261e0bb3e285c872364ecf9f2af Author: Mauricio Faria de Oliveira Date: Sun Jul 19 08:43:47 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 6e5ef54b884f420013ff7b20c232bdb83fbb612e Author: Mauricio Faria de Oliveira Date: Sun Jul 19 08:43:46 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 41a4e80d5af04855e68ac88f5e2cd07fa67287f8 Author: Ben Dooks Date: Sat Jul 18 17:50:15 2026 -0400 usb: dwc3: fix dwc3_readl() and dwc3_writel() calls in dwc3_ulpi_setup() [ Upstream commit e0f844d9d74200d311c6438a0f04270834ba5365 ] The dwc3_ulpi_setup() calls the register read and write calls with dwc3->regs when both these calls take the dwc3 structure directly. Chnage these two calls to fix the following sparse warning, and possibly a nasty bug in the dwc3_ulpi_setup() code: drivers/usb/dwc3/core.c:796:45: warning: incorrect type in argument 1 (different address spaces) drivers/usb/dwc3/core.c:796:45: expected struct dwc3 *dwc drivers/usb/dwc3/core.c:796:45: got void [noderef] __iomem *regs drivers/usb/dwc3/core.c:798:40: warning: incorrect type in argument 1 (different address spaces) drivers/usb/dwc3/core.c:798:40: expected struct dwc3 *dwc drivers/usb/dwc3/core.c:798:40: got void [noderef] __iomem *regs Cc: stable Fixes: 9accc68b1cf0 ("usb: dwc3: Add dwc pointer to dwc3_readl/writel") Acked-by: Thinh Nguyen Signed-off-by: Ben Dooks Link: https://patch.msgid.link/20260703162033.2847599-1-ben.dooks@codethink.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e534790c4c272013c56261c55ab08a609a14f601 Author: Ingo Rohloff Date: Sat Jul 18 17:50:14 2026 -0400 usb: dwc3: Support USB3340x ULPI PHY high-speed negotiation. [ Upstream commit a28de63356575612954d4e5d5f48a2488f50e16d ] The Microchip USB3340x ULPI PHY requires a delay when switching to the high-speed transmitter. See: http://ww1.microchip.com/downloads/en/DeviceDoc/80000645A.pdf Module 2 "Device Enumeration Failure with Link IP Systems" For details on the behavior and fix, refer to the AMD (formerly Xilinx) forum post: "USB stuck in full speed mode with USB3340 ULPI PHY, ZynqMP." This patch uses the USB PHY Vendor-ID and Product-ID to detect the USB3340 PHY and then applies the necessary fix if this PHY is found. Signed-off-by: Ingo Rohloff Acked-by: Thinh Nguyen Link: https://patch.msgid.link/20260305121452.54082-2-ingo.rohloff@lauterbach.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: e0f844d9d742 ("usb: dwc3: fix dwc3_readl() and dwc3_writel() calls in dwc3_ulpi_setup()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bce232923aa9e8ca0f80b023c179977bbe977878 Author: Christoph Hellwig Date: Sat Jul 18 11:47:52 2026 -0400 xfs: use bio_reuse in the zone GC code [ Upstream commit 0506d32f7c52e41f6e8db7c337e0ce6374c6ffbb ] Replace our somewhat fragile code to reuse the bio, which caused a regression in the past with the block layer bio_reuse helper. Signed-off-by: Christoph Hellwig Reviewed-by: Hans Holmberg Reviewed-by: Carlos Maiolino Reviewed-by: Damien Le Moal Signed-off-by: Carlos Maiolino [ sashal: open-coded the bio_reuse logic at the call site as 6.18 lacks commit 7ca44303f9f6 ("block: add a bio_reuse helper") ] 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 adadb181ad42af8a178dc196e67230102e93a414 Author: Christoph Hellwig Date: Sat Jul 18 11:32:57 2026 -0400 xfs: only log freed extents for the current RTG in zoned growfs [ Upstream commit 44cccefe65749821d9a13523c8b763bf1262ef73 ] Otherwise a power fail or crash during growfs could lead to an elevated sb_rblocks counter. Note that the step function is much simpler compared to the classic RT allocator as zoned RT sections must be aligned to real time group boundaries. Fixes: 01b71e64bb87 ("xfs: support growfs on zoned file systems") Cc: # v6.15 Signed-off-by: Christoph Hellwig Reviewed-by: "Darrick J. Wong" Reviewed-by: Damien Le Moal Signed-off-by: Carlos Maiolino Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 47c0e0743302187eaf85e72809a4638286d09a65 Author: Christoph Hellwig Date: Sat Jul 18 11:32:56 2026 -0400 xfs: add a xfs_groups_to_rfsbs helper [ Upstream commit 0ec73eb3f12350799c4b3fb764225f6e38b42d1e ] Plus a rtgroup wrapper and use that to avoid overflows when converting zone/rtg counts to block counts. Signed-off-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Stable-dep-of: 44cccefe6574 ("xfs: only log freed extents for the current RTG in zoned growfs") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 57454944737f3ad9a8703aecbbb79713b513a94b Author: Vlad Poenaru Date: Sat Jul 18 07:44:41 2026 -0400 bpf: Allow LPM map access from sleepable BPF programs [ Upstream commit 2f884d371fafea137afea504d49ee4a7c8d7985b ] trie_lookup_elem() annotates its rcu_dereference_check() walks with only rcu_read_lock_bh_held(). Because rcu_dereference_check(p, c) resolves to "c || rcu_read_lock_held()", this passes for XDP/NAPI and classic RCU readers but fails for sleepable BPF programs, which enter via __bpf_prog_enter_sleepable() and hold only rcu_read_lock_trace(). trie_update_elem() and trie_delete_elem() have the same problem in a different form: they walk the trie with plain rcu_dereference(), which asserts rcu_read_lock_held() unconditionally. Both are reachable from sleepable BPF programs via the bpf_map_update_elem / bpf_map_delete_elem helpers, and from the syscall path under classic rcu_read_lock(). In the writer paths the trie is actually protected by trie->lock (an rqspinlock taken across the walk); we never relied on the RCU read-side lock to keep nodes alive there. A sleepable LSM hook that ends up touching an LPM trie therefore triggers lockdep on debug kernels: ============================= WARNING: suspicious RCU usage 7.1.0-... Tainted: G E ----------------------------- kernel/bpf/lpm_trie.c:249 suspicious rcu_dereference_check() usage! 1 lock held by net_tests/540: #0: (rcu_tasks_trace_srcu_struct){....}-{0:0}, at: __bpf_prog_enter_sleepable+0x26/0x280 Call Trace: dump_stack_lvl lockdep_rcu_suspicious trie_lookup_elem bpf_prog_..._enforce_security_socket_connect bpf_trampoline_... security_socket_connect __sys_connect do_syscall_64 This is lockdep-only -- no UAF, since Tasks Trace RCU does serialize against the trie's reclaim path -- but it spams the console once per distinct callsite on every debug kernel running a sleepable BPF LSM that touches an LPM trie, which is increasingly common. For the lookup path, switch the rcu_dereference_check() annotation from rcu_read_lock_bh_held() to bpf_rcu_lock_held(), which accepts all three contexts (classic, BH, Tasks Trace). Other map types already follow this convention. For trie_update_elem() and trie_delete_elem(), annotate the walks as rcu_dereference_protected(*p, 1) -- matching trie_free() in the same file -- since trie->lock is held across the walk. rqspinlock has no lockdep_map, so the predicate degenerates to '1' rather than lockdep_is_held(&trie->lock); the protection is real but not machine-verifiable. trie_get_next_key() also uses bare rcu_dereference() but is reachable only from the BPF syscall, which holds classic rcu_read_lock() before dispatching, so it is left untouched. Fixes: 694cea395fde ("bpf: Allow RCU-protected lookups to happen from bh context") Cc: stable@vger.kernel.org Signed-off-by: Vlad Poenaru Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/r/20260609135558.193287-2-vlad.wing@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8fccaeeb9e9c5685ea1799f1abd0c35709413f82 Author: Andrii Nakryiko Date: Sat Jul 18 07:44:40 2026 -0400 bpf: Consistently use bpf_rcu_lock_held() everywhere [ Upstream commit 48a97ffc6c826640907d13b199e29008f4fe2c15 ] We have many places which open-code what's now is bpf_rcu_lock_held() macro, so replace all those places with a clean and short macro invocation. For that, move bpf_rcu_lock_held() macro into include/linux/bpf.h. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Jiri Olsa Link: https://lore.kernel.org/bpf/20251014201403.4104511-1-andrii@kernel.org Stable-dep-of: 2f884d371faf ("bpf: Allow LPM map access from sleepable BPF programs") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0b92ad64d6e4bde85e6b9888404f9a7a2b65d269 Author: Nuoqi Gui Date: Sat Jul 18 07:44:34 2026 -0400 bpf: Keep dynamic inner array lookups nullable [ Upstream commit 53040a81ae57cdca8af8ac36fe4e661730cf7c6b ] An ARRAY_OF_MAPS can use an array created with BPF_F_INNER_MAP as its inner map template. A concrete inner array with a different max_entries value can then replace the template. After a successful outer map lookup, the verifier represents the resulting map pointer using the inner map template. Const-key lookup nullness elision consequently uses the template max_entries even though the runtime helper uses the concrete inner map max_entries. Do not elide lookup result nullness for maps marked with BPF_F_INNER_MAP, because the template max_entries does not prove that the key is in bounds for the concrete runtime map. Fixes: d2102f2f5d75 ("bpf: verifier: Support eliding map lookup nullness") Signed-off-by: Nuoqi Gui Acked-by: Eduard Zingerman Acked-by: Jiri Olsa Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20260607-f01-v2-v2-1-da48453146e8@mails.tsinghua.edu.cn Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c447be8d88c309f65c412c23fc09612967121fcc Author: Mykyta Yatsenko Date: Sat Jul 18 07:44:33 2026 -0400 bpf: Introduce struct bpf_map_desc in verifier [ Upstream commit 98c4fd2963cb2bc5eae22b5365e6bbf3a5cd0f14 ] Introduce struct bpf_map_desc to hold bpf_map pointer and map uid. Use this struct in both bpf_call_arg_meta and bpf_kfunc_call_arg_meta instead of having different representations: - bpf_call_arg_meta had separate map_ptr and map_uid fields - bpf_kfunc_call_arg_meta had an anonymous inline struct This unifies the map fields layout across both metadata structures, making the code more consistent and preparing for further refactoring of map field pointer validation. Acked-by: Eduard Zingerman Signed-off-by: Mykyta Yatsenko Link: https://lore.kernel.org/r/20260130-verif_special_fields-v2-1-2c59e637da7d@meta.com Signed-off-by: Alexei Starovoitov Stable-dep-of: 53040a81ae57 ("bpf: Keep dynamic inner array lookups nullable") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dccb3c557879de05ac2b7c853149fc0010aedd71 Author: Mykyta Yatsenko Date: Sat Jul 18 07:44:32 2026 -0400 bpf: Consistently use reg_state() for register access in the verifier [ Upstream commit 7af3339948601e188d93d7e03326aeb8fcbd6bea ] Replace the pattern of declaring a local regs array from cur_regs() and then indexing into it with the more concise reg_state() helper. This simplifies the code by eliminating intermediate variables and makes register access more consistent throughout the verifier. Signed-off-by: Mykyta Yatsenko Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/r/20260113134826.2214860-1-mykyta.yatsenko5@gmail.com Signed-off-by: Alexei Starovoitov Stable-dep-of: 53040a81ae57 ("bpf: Keep dynamic inner array lookups nullable") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 60eed44674295423cd28a2255c38cea80b8cc256 Author: Christoph Hellwig Date: Sat Jul 18 07:20:31 2026 -0400 xfs: initialize iomap->flags earlier in xfs_bmbt_to_iomap [ Upstream commit 327e58826eb72f8bae9419cf1a4e722b57c85694 ] Otherwise we lose the IOMAP_IOEND_BOUNDARY assingment for writes to the first block in a realtime group, and could cause incorrect merges for such writes. Fixes: b91afef72471 ("xfs: don't merge ioends across RTGs") Cc: # v6.13 Signed-off-by: Christoph Hellwig Reviewed-by: "Darrick J. Wong" Signed-off-by: Carlos Maiolino Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 607217f7ad419b53926f71e3f75001813bbc08ad Author: Tristan Madani Date: Fri Jul 17 15:55:16 2026 -0400 hfs/hfsplus: fix u32 overflow in check_and_correct_requested_length [ Upstream commit 966cb76fb2857a4242cab6ea2ea17acf818a3da7 ] check_and_correct_requested_length() compares (off + len) against node_size using u32 arithmetic. When the caller passes a large len value (e.g. from an underflowed subtraction in hfs_brec_remove()), off + len can wrap past 2^32 and produce a small result, causing the bounds check to pass when it should fail. For example, with off=14 and len=0xFFFFFFF2 (underflowed from data_off - keyoffset - size in hfs_brec_remove), off + len wraps to 6, which is less than a typical node_size of 512, so the check passes and the subsequent memmove reads ~4GB past the node buffer. Fix this by widening the addition to u64 before comparing against node_size. This prevents the u32 wrap while keeping the logic straightforward. Reported-by: syzbot+6df204b70bf3261691c5@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6df204b70bf3261691c5 Tested-by: syzbot+6df204b70bf3261691c5@syzkaller.appspotmail.com Reported-by: syzbot+e76bf3d19b85350571ac@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e76bf3d19b85350571ac Tested-by: syzbot+e76bf3d19b85350571ac@syzkaller.appspotmail.com Fixes: a431930c9bac ("hfs: fix slab-out-of-bounds in hfs_bnode_read()") Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Reviewed-by: Viacheslav Dubeyko Signed-off-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/20260505111300.3592757-2-tristmd@gmail.com Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7676ea09beb5d2c861db2b9d4bd5fffef600f836 Author: Viacheslav Dubeyko Date: Fri Jul 17 15:55:15 2026 -0400 hfs/hfsplus: prevent getting negative values of offset/length [ Upstream commit 00c14a09a70e10ae18eb3707d0059291425c04bd ] The syzbot reported KASAN out-of-bounds issue in hfs_bnode_move(): [ 45.588165][ T9821] hfs: dst 14, src 65536, len -65536 [ 45.588895][ T9821] ================================================================== [ 45.590114][ T9821] BUG: KASAN: out-of-bounds in hfs_bnode_move+0xfd/0x140 [ 45.591127][ T9821] Read of size 18446744073709486080 at addr ffff888035935400 by task repro/9821 [ 45.592207][ T9821] [ 45.592420][ T9821] CPU: 0 UID: 0 PID: 9821 Comm: repro Not tainted 6.16.0-rc7-dirty #42 PREEMPT(full) [ 45.592428][ T9821] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 45.592431][ T9821] Call Trace: [ 45.592434][ T9821] [ 45.592437][ T9821] dump_stack_lvl+0x1c1/0x2a0 [ 45.592446][ T9821] ? __virt_addr_valid+0x1c8/0x5c0 [ 45.592454][ T9821] ? __pfx_dump_stack_lvl+0x10/0x10 [ 45.592461][ T9821] ? rcu_is_watching+0x15/0xb0 [ 45.592469][ T9821] ? lock_release+0x4b/0x3e0 [ 45.592476][ T9821] ? __virt_addr_valid+0x1c8/0x5c0 [ 45.592483][ T9821] ? __virt_addr_valid+0x4a5/0x5c0 [ 45.592491][ T9821] print_report+0x17e/0x7c0 [ 45.592497][ T9821] ? __virt_addr_valid+0x1c8/0x5c0 [ 45.592504][ T9821] ? __virt_addr_valid+0x4a5/0x5c0 [ 45.592511][ T9821] ? __phys_addr+0xd3/0x180 [ 45.592519][ T9821] ? hfs_bnode_move+0xfd/0x140 [ 45.592526][ T9821] kasan_report+0x147/0x180 [ 45.592531][ T9821] ? _printk+0xcf/0x120 [ 45.592537][ T9821] ? hfs_bnode_move+0xfd/0x140 [ 45.592544][ T9821] ? hfs_bnode_move+0xfd/0x140 [ 45.592552][ T9821] kasan_check_range+0x2b0/0x2c0 [ 45.592557][ T9821] ? hfs_bnode_move+0xfd/0x140 [ 45.592565][ T9821] __asan_memmove+0x29/0x70 [ 45.592572][ T9821] hfs_bnode_move+0xfd/0x140 [ 45.592580][ T9821] hfs_brec_remove+0x473/0x560 [ 45.592589][ T9821] hfs_cat_move+0x6fb/0x960 [ 45.592598][ T9821] ? __pfx_hfs_cat_move+0x10/0x10 [ 45.592607][ T9821] ? seqcount_lockdep_reader_access+0x122/0x1c0 [ 45.592614][ T9821] ? lockdep_hardirqs_on+0x9c/0x150 [ 45.592631][ T9821] ? __lock_acquire+0xaec/0xd80 [ 45.592641][ T9821] hfs_rename+0x1dc/0x2d0 [ 45.592649][ T9821] ? __pfx_hfs_rename+0x10/0x10 [ 45.592657][ T9821] vfs_rename+0xac6/0xed0 [ 45.592664][ T9821] ? __pfx_vfs_rename+0x10/0x10 [ 45.592670][ T9821] ? d_alloc+0x144/0x190 [ 45.592677][ T9821] ? bpf_lsm_path_rename+0x9/0x20 [ 45.592683][ T9821] ? security_path_rename+0x17d/0x490 [ 45.592691][ T9821] do_renameat2+0x890/0xc50 [ 45.592699][ T9821] ? __pfx_do_renameat2+0x10/0x10 [ 45.592707][ T9821] ? getname_flags+0x1e5/0x540 [ 45.592714][ T9821] __x64_sys_rename+0x82/0x90 [ 45.592720][ T9821] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 45.592725][ T9821] do_syscall_64+0xf3/0x3a0 [ 45.592741][ T9821] ? exc_page_fault+0x9f/0xf0 [ 45.592748][ T9821] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 45.592754][ T9821] RIP: 0033:0x7f7f73fe3fc9 [ 45.592760][ T9821] Code: 00 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 48 [ 45.592765][ T9821] RSP: 002b:00007ffc7e116cf8 EFLAGS: 00000283 ORIG_RAX: 0000000000000052 [ 45.592772][ T9821] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f7f73fe3fc9 [ 45.592776][ T9821] RDX: 0000200000000871 RSI: 0000200000000780 RDI: 00002000000003c0 [ 45.592781][ T9821] RBP: 00007ffc7e116d00 R08: 0000000000000000 R09: 00007ffc7e116d30 [ 45.592784][ T9821] R10: fffffffffffffff0 R11: 0000000000000283 R12: 00005557e81f8250 [ 45.592788][ T9821] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 45.592795][ T9821] [ 45.592797][ T9821] [ 45.619721][ T9821] The buggy address belongs to the physical page: [ 45.620300][ T9821] page: refcount:1 mapcount:1 mapping:0000000000000000 index:0x559a88174 pfn:0x35935 [ 45.621150][ T9821] memcg:ffff88810a1d5b00 [ 45.621531][ T9821] anon flags: 0xfff60000020838(uptodate|dirty|lru|owner_2|swapbacked|node=0|zone=1|lastcpupid=0x7ff) [ 45.622496][ T9821] raw: 00fff60000020838 ffffea0000d64d88 ffff888021753e10 ffff888029da0771 [ 45.623260][ T9821] raw: 0000000559a88174 0000000000000000 0000000100000000 ffff88810a1d5b00 [ 45.624030][ T9821] page dumped because: kasan: bad access detected [ 45.624602][ T9821] page_owner tracks the page as allocated [ 45.625115][ T9821] page last allocated via order 0, migratetype Movable, gfp_mask 0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO0 [ 45.626685][ T9821] post_alloc_hook+0x240/0x2a0 [ 45.627127][ T9821] get_page_from_freelist+0x2101/0x21e0 [ 45.627628][ T9821] __alloc_frozen_pages_noprof+0x274/0x380 [ 45.628154][ T9821] alloc_pages_mpol+0x241/0x4b0 [ 45.628593][ T9821] vma_alloc_folio_noprof+0xe4/0x210 [ 45.629066][ T9821] folio_prealloc+0x30/0x180 [ 45.629487][ T9821] __handle_mm_fault+0x34bd/0x5640 [ 45.629957][ T9821] handle_mm_fault+0x40e/0x8e0 [ 45.630392][ T9821] do_user_addr_fault+0xa81/0x1390 [ 45.630862][ T9821] exc_page_fault+0x76/0xf0 [ 45.631273][ T9821] asm_exc_page_fault+0x26/0x30 [ 45.631712][ T9821] page last free pid 5269 tgid 5269 stack trace: [ 45.632281][ T9821] free_unref_folios+0xc73/0x14c0 [ 45.632740][ T9821] folios_put_refs+0x55b/0x640 [ 45.633177][ T9821] free_pages_and_swap_cache+0x26d/0x510 [ 45.633685][ T9821] tlb_flush_mmu+0x3a0/0x680 [ 45.634105][ T9821] tlb_finish_mmu+0xd4/0x200 [ 45.634525][ T9821] exit_mmap+0x44c/0xb70 [ 45.634914][ T9821] __mmput+0x118/0x420 [ 45.635286][ T9821] exit_mm+0x1da/0x2c0 [ 45.635659][ T9821] do_exit+0x652/0x2330 [ 45.636039][ T9821] do_group_exit+0x21c/0x2d0 [ 45.636457][ T9821] __x64_sys_exit_group+0x3f/0x40 [ 45.636915][ T9821] x64_sys_call+0x21ba/0x21c0 [ 45.637342][ T9821] do_syscall_64+0xf3/0x3a0 [ 45.637756][ T9821] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 45.638290][ T9821] page has been migrated, last migrate reason: numa_misplaced [ 45.638956][ T9821] [ 45.639173][ T9821] Memory state around the buggy address: [ 45.639677][ T9821] ffff888035935300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 45.640397][ T9821] ffff888035935380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 45.641117][ T9821] >ffff888035935400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 45.641837][ T9821] ^ [ 45.642207][ T9821] ffff888035935480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 45.642929][ T9821] ffff888035935500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 45.643650][ T9821] ================================================================== This commit [1] fixes the issue if an offset inside of b-tree node or length of the request is bigger than b-tree node. However, this fix is still not ready for negative values of the offset or length. Moreover, negative values of the offset or length doesn't make sense for b-tree's operations. Because we could try to access the memory address outside of the beginning of memory page's addresses range. Also, using of negative values make logic very complicated, unpredictable, and we could access the wrong item(s) in the b-tree node. This patch changes b-tree interface by means of converting signed integer arguments of offset and length on u32 type. Such conversion has goal to prevent of using negative values unintentionally or by mistake in b-tree operations. [1] 'commit a431930c9bac ("hfs: fix slab-out-of-bounds in hfs_bnode_read()")' Signed-off-by: Viacheslav Dubeyko cc: John Paul Adrian Glaubitz cc: Yangtao Li cc: linux-fsdevel@vger.kernel.org Link: https://lore.kernel.org/r/20251002200020.2578311-1-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko Stable-dep-of: 966cb76fb285 ("hfs/hfsplus: fix u32 overflow in check_and_correct_requested_length") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f9b4b03ccc9c69bf7f7298d4559906ebea7143b3 Author: Jann Horn Date: Fri Jul 17 07:18:34 2026 -0400 proc: protect ptrace_may_access() with exec_update_lock (part 1) [ Upstream commit 6650527444dadc63d84aa939d14ecba4fadb2f69 ] Fix the easy cases where procfs currently calls ptrace_may_access() without exec_update_lock protection, where the fix is to simply add the extra lock or use mm_access(): - do_task_stat(): grab exec_update_lock - proc_pid_wchan(): grab exec_update_lock - proc_map_files_lookup(): use mm_access() instead of get_task_mm() - proc_map_files_readdir(): use mm_access() instead of get_task_mm() - proc_ns_get_link(): grab exec_update_lock - proc_ns_readlink(): grab exec_update_lock Fixes: f83ce3e6b02d ("proc: avoid information leaks to non-privileged processes") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn Link: https://patch.msgid.link/20260518-procfs-lockfix-part1-v1-1-5c3d20e0ac33@google.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 07bf18dc63f78026166898e8ed0ce6209ded84ed Author: Oleg Nesterov Date: Fri Jul 17 07:18:33 2026 -0400 seqlock: Change do_task_stat() to use scoped_seqlock_read() [ Upstream commit b76f72bea2c601afec81829ea427fc0d20f83216 ] To simplify the code and make it more readable. [peterz: change to new interface] Signed-off-by: Oleg Nesterov Signed-off-by: Peter Zijlstra (Intel) Stable-dep-of: 6650527444da ("proc: protect ptrace_may_access() with exec_update_lock (part 1)") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c897fd63762e0189c08795c7423def5291c3d0fa Author: Peter Zijlstra Date: Fri Jul 17 07:18:32 2026 -0400 seqlock: Introduce scoped_seqlock_read() [ Upstream commit cc39f3872c0865bef992b713338df369554fa9e0 ] The read_seqbegin/need_seqretry/done_seqretry API is cumbersome and error prone. With the new helper the "typical" code like int seq, nextseq; unsigned long flags; nextseq = 0; do { seq = nextseq; flags = read_seqbegin_or_lock_irqsave(&seqlock, &seq); // read-side critical section nextseq = 1; } while (need_seqretry(&seqlock, seq)); done_seqretry_irqrestore(&seqlock, seq, flags); can be rewritten as scoped_seqlock_read (&seqlock, ss_lock_irqsave) { // read-side critical section } Original idea by Oleg Nesterov; with contributions from Linus. Originally-by: Oleg Nesterov Signed-off-by: Peter Zijlstra (Intel) Stable-dep-of: 6650527444da ("proc: protect ptrace_may_access() with exec_update_lock (part 1)") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 497c6bae5167428596575f20af6613ff5671f383 Author: Jann Horn Date: Thu Jul 16 12:45:14 2026 -0400 proc: protect ptrace_may_access() with exec_update_lock (FD links) [ Upstream commit 6255da28d4bb5349fe18e84cb043ccd394eba75d ] proc_pid_get_link() and proc_pid_readlink() currently look up the task from the pid once, then do the ptrace access check on that task, then look up the task from the pid a second time to do the actual access. That's racy in several ways. To fix it, pass the task to the ->proc_get_link() handler, and instead of proc_fd_access_allowed(), introduce a new helper call_proc_get_link() that looks up and locks the task, does the access check, and calls ->proc_get_link(). Fixes: 778c1144771f ("[PATCH] proc: Use sane permission checks on the /proc//fd/ symlinks") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn Link: https://patch.msgid.link/20260518-procfs-lockfix-part1-v1-2-5c3d20e0ac33@google.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 903d78e5aca7792fb4169c7ca83f403056823d53 Author: Christoph Hellwig Date: Thu Jul 16 12:45:13 2026 -0400 proc: rename proc_setattr to proc_nochmod_setattr [ Upstream commit 690005b0b1e6b567c88b7790e6d90d4d6c9e09cc ] What is currently proc_setattr is a special version added after the more general procfs ->seattr in commit 6d76fa58b050 ("Don't allow chmod() on the /proc// files"). Give it a name that reflects that to free the proc_setattr name and better describe what is doing. Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20260325063711.3298685-5-hch@lst.de Reviewed-by: Jan Kara Signed-off-by: Christian Brauner Stable-dep-of: 6255da28d4bb ("proc: protect ptrace_may_access() with exec_update_lock (FD links)") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b56400364aed5c34d6e1a0b493081290a5328a9c Author: Haofeng Li Date: Thu Jul 16 07:21:47 2026 -0400 ksmbd: validate NTLMv2 response before updating session key [ Upstream commit 954d196bebb2b50151cb96454c72dc113b2af1ac ] ksmbd_auth_ntlmv2() derives the NTLMv2 session key into sess->sess_key before it verifies the NTLMv2 response. ksmbd_decode_ntlmssp_auth_blob() then continues into KEY_XCH even when ksmbd_auth_ntlmv2() failed. With SMB3 multichannel binding, the failed authentication operates on an existing session and the session setup error path does not expire binding sessions. A client can send a binding session setup with a bad NT proof and KEY_XCH and still modify sess->sess_key before STATUS_LOGON_FAILURE is returned. Relevant path: smb2_sess_setup() -> conn->binding = true -> ntlm_authenticate() -> session_user() -> ksmbd_decode_ntlmssp_auth_blob() -> ksmbd_auth_ntlmv2() -> calc_ntlmv2_hash() -> hmac_md5_usingrawkey(..., sess->sess_key) -> crypto_memneq() returns mismatch -> KEY_XCH arc4_crypt(..., sess->sess_key, ...) -> out_err without expiring the binding session Derive the base session key into a local buffer and copy it to sess->sess_key only after the proof matches. Return immediately on authentication failure so KEY_XCH is only processed after successful authentication. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Fixes: f9929ef6a2a5 ("ksmbd: add support for key exchange") Cc: stable@vger.kernel.org Signed-off-by: Haofeng Li Reviewed-by: ChenXiaoSong Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 74c2f0ffb81c8f3f5e3e1b8d3649d3cf5753341d Author: Eric Biggers Date: Thu Jul 16 07:21:46 2026 -0400 ksmbd: Use HMAC-MD5 library for NTLMv2 [ Upstream commit 3a597e6e9701eb7af04864ffdc0a6a91bc8c6496 ] For the HMAC-MD5 computations in NTLMv2, use the HMAC-MD5 library instead of a "hmac(md5)" crypto_shash. This is simpler and faster. With the library there's no need to allocate memory, no need to handle errors, and the HMAC-MD5 code is accessed directly without inefficient indirect calls and other unnecessary API overhead. To preserve the existing behavior of NTLMv2 support being disabled when the kernel is booted with "fips=1", make ksmbd_auth_ntlmv2() check fips_enabled itself. Previously it relied on the error from crypto_alloc_shash("hmac(md5)") being bubbled up. I don't know for sure that this is actually needed, but this preserves the existing behavior. Signed-off-by: Eric Biggers Acked-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: 954d196bebb2 ("ksmbd: validate NTLMv2 response before updating session key") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 51c5f7e84cfed4e6f7496009e58b66f4ffddadb3 Author: Eric Biggers Date: Thu Jul 16 07:21:45 2026 -0400 ksmbd: Use HMAC-SHA256 library for message signing and key generation [ Upstream commit 924067ef183bd17f39d790752190f99982524598 ] Convert ksmbd_sign_smb2_pdu() and generate_key() to use the HMAC-SHA256 library instead of a "hmac(sha256)" crypto_shash. This is simpler and faster. With the library there's no need to allocate memory, no need to handle errors, and the HMAC-SHA256 code is accessed directly without inefficient indirect calls and other unnecessary API overhead. Signed-off-by: Eric Biggers Acked-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: 954d196bebb2 ("ksmbd: validate NTLMv2 response before updating session key") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bd27d9504d20005435722250c8c9066e339584e8 Author: Eric Biggers Date: Thu Jul 16 07:21:44 2026 -0400 ksmbd: Use SHA-512 library for SMB3.1.1 preauth hash [ Upstream commit e009cb1e3093977c5b96a1c6697a7dc9332222d5 ] Convert ksmbd_gen_preauth_integrity_hash() to use the SHA-512 library instead of a "sha512" crypto_shash. This is simpler and faster. With the library there's no need to allocate memory, no need to handle errors, and the SHA-512 code is accessed directly without inefficient indirect calls and other unnecessary API overhead. Signed-off-by: Eric Biggers Acked-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: 954d196bebb2 ("ksmbd: validate NTLMv2 response before updating session key") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 427faaa52b0b399940c1a88065a5c310d10dad15 Author: Namjae Jeon Date: Thu Jul 16 07:21:21 2026 -0400 ksmbd: track the connection owning a byte-range lock [ Upstream commit c1016dd1d8b2bcd1158bbaabe94a31bb7e7431fb ] SMB2_LOCK adds each granted byte-range lock to both the file lock list and the lock list of the connection which handled the request. The final close and durable handle paths, however, remove the connection list entry while holding fp->conn->llist_lock. With SMB3 multichannel, the connection handling the LOCK request can be different from the connection which opened the file. The entry can therefore be removed under a different spinlock from the one protecting the list it belongs to. A concurrent traversal can then access freed struct ksmbd_lock and struct file_lock objects. Record the connection owning each lock's clist entry and hold a reference to it while the entry is linked. Use that connection and its llist_lock for unlock, rollback, close, and durable preserve. Durable reconnect assigns the new connection as the owner when publishing the locks again. Fixes: f5a544e3bab7 ("ksmbd: add support for SMB3 multichannel") 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 6a37bc484f12e02c850461272ef41e0a20592dcb Author: DaeMyung Kang Date: Thu Jul 16 07:21:20 2026 -0400 ksmbd: centralize ksmbd_conn final release to plug transport leak [ Upstream commit b1f1e80620deb49daf63c2e677046599b693dc1f ] ksmbd_conn_free() is one of four sites that can observe the last refcount drop of a struct ksmbd_conn. The other three fs/smb/server/connection.c ksmbd_conn_r_count_dec() fs/smb/server/oplock.c __free_opinfo() fs/smb/server/vfs_cache.c session_fd_check() end the conn with a bare kfree(), skipping ida_destroy(&conn->async_ida) and conn->transport->ops->free_transport(conn->transport). Whenever one of them is the last putter, the embedded async_ida and the entire transport struct leak -- for TCP, that is also the struct socket and the kvec iov. __free_opinfo() being a final putter is not theoretical. opinfo_put() queues the callback via call_rcu(&opinfo->rcu, free_opinfo_rcu), so ksmbd_server_terminate_conn() can deposit N opinfo releases in RCU and have ksmbd_conn_free() run in the handler thread before any of them fire. ksmbd_conn_free() then observes refcnt > 0 and short-circuits; the last RCU-delivered __free_opinfo() falls onto its bare kfree(conn) branch and the transport is lost. A/B validation in a QEMU/virtme guest, mounting //127.0.0.1/testshare: each iteration holds 8 files open via sleep processes, force-closes TCP with "ss -K sport = :445", kills the holders, lazy-umounts; repeated 10 times, then ksmbd shutdown and kmemleak scan. state conn_alloc conn_free tcp_free opi_rcu kmemleak ---------- ---------- --------- -------- ------- -------- pre-patch 20 20 10 160 7 with patch 20 20 20 160 0 Pre-patch conn_free=20 with tcp_free=10 directly demonstrates the bare-kfree paths skipping transport cleanup; kmemleak backtraces point into struct tcp_transport / iov. With this patch tcp_free matches conn_free at 20/20 and kmemleak is clean. Move the per-struct final release into __ksmbd_conn_release_work() and route the three bare-kfree final-put sites through a new ksmbd_conn_put(). Those sites now pair ida_destroy() and free_transport() with kfree(conn) regardless of which holder happens to release the last reference. stop_sessions() only triggers the transport shutdown and does not itself drop the last conn reference, so it is unaffected. The centralized release reaches sock_release() -> tcp_close() -> lock_sock_nested() (might_sleep) from every final putter, including __free_opinfo() invoked from an RCU softirq callback, which trips CONFIG_DEBUG_ATOMIC_SLEEP. Defer the release to a dedicated ksmbd_conn_wq workqueue so ksmbd_conn_put() is safe from any non-sleeping context. Make ksmbd_file own a strong connection reference while fp->conn is non-NULL so durable-preserve and final-close paths cannot dereference a stale connection. ksmbd_open_fd() and ksmbd_reopen_durable_fd() take the reference via ksmbd_conn_get() (the latter also reorders the fp->conn / fp->tcon assignments before __open_id() so the published fp is never observed with fp->conn == NULL); session_fd_check() and __ksmbd_close_fd() drop it via ksmbd_conn_put(). With that invariant, session_fd_check() can take a local conn pointer once and use it across the m_op_list and lock_list iterations even though op->conn puts may otherwise drop the last reference. At module exit the workqueue is flushed and destroyed after rcu_barrier(), so any release queued by a trailing RCU callback is drained before the inode hash and module text go away. Fixes: ee426bfb9d09 ("ksmbd: add refcnt to ksmbd_conn struct") Signed-off-by: DaeMyung Kang Acked-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: c1016dd1d8b2 ("ksmbd: track the connection owning a byte-range lock") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c7c884a1305aa4540eb7942a50bd356b34120e1f Author: Davide Ornaghi Date: Thu Jul 16 06:18:49 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 [ replaced start_creating_noperm() and CLASS(filename_kernel) with open-coded getname_kernel()/inode_lock_nested()/lookup_one_qstr_excl() equivalents absent in 6.18 ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e205f3e7e8c31a47cd11efb6cf663a527177e432 Author: Namjae Jeon Date: Thu Jul 16 06:18:19 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 90a93fb3230c9d9dc4b36342a1c942567b8423ea Author: David Howells Date: Thu Jul 16 06:18:18 2026 -0400 cifs: SMB1 split: Add some #includes [ Upstream commit a7c7f35bcf0943ba85ab14bafbfbcbc3a30ad402 ] Add some #includes to make sure things continue to compile as splitting occurs. Signed-off-by: David Howells cc: Steve French cc: Paulo Alcantara cc: Enzo Matsumiya cc: linux-cifs@vger.kernel.org cc: linux-fsdevel@vger.kernel.org cc: linux-kernel@vger.kernel.org Acked-by: Enzo Matsumiya 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 ff943e1f3d31fbc5d7bf502dd1735729ac145b85 Author: David Howells Date: Thu Jul 16 06:18:17 2026 -0400 cifs: SMB1 split: Rename cifstransport.c [ Upstream commit b09eab52b307df58a36f34d047378053a2e13e13 ] Rename cifstransport.c to smb1transport.c in order to give consistent names SMB1-specific files. Signed-off-by: David Howells cc: Steve French cc: Paulo Alcantara cc: Enzo Matsumiya cc: linux-cifs@vger.kernel.org cc: linux-fsdevel@vger.kernel.org cc: linux-kernel@vger.kernel.org Acked-by: Enzo Matsumiya 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 36da806f7fbaee56ad9e81859deec203f9728700 Author: Siwei Zhang Date: Wed Jul 15 17:13:38 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 6d0eeebe22ba7d1ceebd824bc519432efab0419d Author: Pauli Virtanen Date: Wed Jul 15 17:13:37 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 ef382a6baf0a95cf199fdf6bba2fd08e58b0a249 Author: Xiaolei Wang Date: Wed Jul 15 07:40:28 2026 -0400 media: nxp: imx8-isi: Fix use-after-free on remove [ Upstream commit b670bf89824ede5d07d20bb9bfbafb754846081d ] KASAN reports a slab-use-after-free in __media_entity_remove_link() during rmmod of imx8_isi: BUG: KASAN: slab-use-after-free in __media_entity_remove_link+0x608/0x650 Read of size 2 at addr ffff0000d47cb02a by task rmmod/724 Call trace: __media_entity_remove_link+0x608/0x650 __media_entity_remove_links+0x78/0x144 __media_device_unregister_entity+0x150/0x280 media_device_unregister_entity+0x48/0x68 v4l2_device_unregister_subdev+0x158/0x300 v4l2_async_unbind_subdev_one+0x22c/0x358 v4l2_async_nf_unbind_all_subdevs+0xfc/0x1c0 v4l2_async_nf_unregister+0x5c/0x14c mxc_isi_remove+0x124/0x2a0 [imx8_isi] Allocated by task 249: __kmalloc_noprof+0x27c/0x690 mxc_isi_crossbar_init+0x22c/0x560 [imx8_isi] Freed by task 724: kfree+0x1e4/0x5b0 mxc_isi_crossbar_cleanup+0x34/0x80 [imx8_isi] mxc_isi_remove+0x11c/0x2a0 [imx8_isi] The problem is that mxc_isi_remove() calls mxc_isi_crossbar_cleanup() before mxc_isi_v4l2_cleanup(). The crossbar cleanup frees the media entity pads, but the subsequent v4l2 cleanup still tries to remove media links that reference those pads. Fix this by calling mxc_isi_v4l2_cleanup() before mxc_isi_crossbar_cleanup() to ensure all media entities are properly unregistered while the pads are still valid. Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver") Cc: stable@vger.kernel.org Signed-off-by: Xiaolei Wang Reviewed-by: Frank Li Reviewed-by: Laurent Pinchart Link: https://patch.msgid.link/20260507041318.491594-2-xiaolei.wang@windriver.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4278953ff0cd42364499da5e378882523ad27d42 Author: Frank Li Date: Wed Jul 15 07:40:27 2026 -0400 media: nxp: imx8-isi: use devm_pm_runtime_enable() to simplify code [ Upstream commit 078161dd44d6f848a62a473206d69025607736ec ] Use devm_pm_runtime_enable() to simplify code. Change to use dev_err_probe() because previous goto change to return. No functional change. Signed-off-by: Frank Li Reviewed-by: Laurent Pinchart Link: https://patch.msgid.link/20260116-cam_cleanup-v4-2-29ce01640443@nxp.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Stable-dep-of: b670bf89824e ("media: nxp: imx8-isi: Fix use-after-free on remove") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 49cd5ac6de8de39a14ead609bb552d372d5602cd Author: Giovanni Cabiddu Date: Tue Jul 14 20:47:11 2026 -0400 crypto: qat - fix VF2PF work teardown race in adf_disable_sriov() [ Upstream commit 277281c10c63791067d24d421f7c43a15faa9096 ] The VF2PF interrupt handler queues PF-side response work that stores a raw pointer to per-VF state (struct adf_accel_vf_info). Currently, adf_disable_sriov() destroys per-VF mutexes and frees vf_info without stopping new VF2PF work or waiting for in-flight workers to complete. A concurrently scheduled or already queued worker can then dereference freed memory. This manifests as a use-after-free when KASAN is enabled: BUG: KASAN: null-ptr-deref in mutex_lock+0x76/0xe0 Write of size 8 at addr 0000000000000260 by task kworker/24:2/... Workqueue: qat_pf2vf_resp_wq adf_iov_send_resp [intel_qat] Call Trace: kasan_report+0x119/0x140 mutex_lock+0x76/0xe0 adf_gen4_pfvf_send+0xd4/0x1f0 [intel_qat] adf_recv_and_handle_vf2pf_msg+0x290/0x360 [intel_qat] adf_iov_send_resp+0x8c/0xe0 [intel_qat] process_one_work+0x6ac/0xfd0 worker_thread+0x4dd/0xd30 kthread+0x326/0x410 ret_from_fork+0x33b/0x670 Add a PF-local flag, vf2pf_disabled, that gates work queueing, worker processing, and interrupt re-enabling during teardown. Set this flag atomically with the hardware interrupt mask inside adf_disable_all_vf2pf_interrupts(). After masking, synchronize the AE cluster MSI-X interrupt and flush the PF response workqueue before tearing down per-VF locks and state so all in-flight work completes before vf_info is destroyed. Introduce adf_enable_all_vf2pf_interrupts() to clear the flag and unmask all VF2PF interrupts under the same lock when SR-IOV is re-enabled. This ensures the software flag and hardware state transition atomically on both the enable and disable paths. Cc: stable@vger.kernel.org Fixes: ed8ccaef52fa ("crypto: qat - Add support for SRIOV") Signed-off-by: Giovanni Cabiddu Reviewed-by: Ahsan Atta Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4b51ee8a40fe47864197d73cc02b191de7a6b072 Author: Alexandru Hossu Date: Tue Jul 14 20:07:36 2026 -0400 staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr() [ Upstream commit 1463ca3ec6601cbb097d8d87dbf5dcf1cb86a344 ] Three IE/attribute parsing functions have missing bounds checks. rtw_get_sec_ie() and rtw_get_wapi_ie() iterate over a raw IE buffer without verifying that the header bytes (tag + length) are within the remaining buffer before reading them. Additionally, rtw_get_sec_ie() compares the 4-byte WPA OUI at cnt+2 without checking that at least 6 bytes remain, and rtw_get_wapi_ie() compares a 4-byte WAPI OUI at cnt+6 without checking that at least 10 bytes remain. rtw_get_wps_attr() reads wps_ie[0] and wps_ie+2 unconditionally at entry, before verifying that wps_ielen is large enough to contain the 6-byte WPS IE header (element_id + length + 4-byte OUI). Inside the attribute loop, get_unaligned_be16() is called on attr_ptr and attr_ptr+2 without checking that 4 bytes remain in the buffer. Add a cnt+2 bounds check before each loop body in rtw_get_sec_ie() and rtw_get_wapi_ie(), guard each multi-byte comparison with a minimum IE length requirement, add a wps_ielen < 6 early return in rtw_get_wps_attr(), and add a 4-byte bounds check in its inner loop. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable Signed-off-by: Alexandru Hossu Link: https://patch.msgid.link/20260522004531.1038924-8-hossu.alexandru@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5d76bc296bb5821f89ec2b3a78c2a36e5a436cde Author: Nikolay Kulikov Date: Tue Jul 14 20:07:35 2026 -0400 staging: rtl8723bs: fix spaces around binary operators [ Upstream commit 0c9d1b56f9af0762a5be5118e1bb962f23784dc4 ] Add missing spaces and fix line length to comply with kernel coding style. Signed-off-by: Nikolay Kulikov Reviewed-by: Ethan Tidmore Link: https://patch.msgid.link/20260221172751.52329-1-nikolayof23@gmail.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 1463ca3ec660 ("staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 48323ebaeeeedadd64ee8ffee65b2e6b094acf32 Author: William Hansen-Baird Date: Tue Jul 14 20:07:34 2026 -0400 staging: rtl8723bs: core: move constants to right side in comparison [ Upstream commit cf0f2680c30d4b438a5e84b73dc70be405936b54 ] Move constants to right side in if-statement conditions. Signed-off-by: William Hansen-Baird Link: https://patch.msgid.link/20251224100329.762141-3-william.hansen.baird@gmail.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 1463ca3ec660 ("staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 73cc54326de459192d4bfd332cd78eb7cde1e7ee Author: Marco Nenciarini Date: Tue Jul 14 16:02:36 2026 -0400 PCI: Skip Resizable BAR restore on read error [ Upstream commit ee7471fe968d210939be9046089a924cd23c8c3b ] pci_restore_rebar_state() uses the Resizable BAR Control register to decide how many BARs to restore (nbars) and which BAR each iteration addresses (bar_idx). When a device does not respond, config reads typically return PCI_ERROR_RESPONSE (~0). Both fields are 3 bits wide, so nbars and bar_idx both evaluate to 7, past the spec's valid ranges for both fields. pci_resource_n() then returns an unrelated resource slot, whose size is used to derive a nonsensical value written back to the Resizable BAR Control register. Bail out if any Resizable BAR Control read returns PCI_ERROR_RESPONSE. No further BARs are touched, which is safe because a config read that returns PCI_ERROR_RESPONSE indicates the device is unreachable and restoration is pointless. Fixes: d3252ace0bc6 ("PCI: Restore resized BAR state on resume") Signed-off-by: Marco Nenciarini Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/666cac19b5daa0ab0e0ab64454e76b4d24465dbd.1776429882.git.mnencia@kcore.it Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f33837a75447329f716e0a3d886da1a2a956fe23 Author: Ilpo Järvinen Date: Tue Jul 14 16:02:35 2026 -0400 PCI: Move Resizable BAR code to rebar.c [ Upstream commit 9f71938cd77f32a448f40a288e409eca60e55486 ] For lack of a better place to put it, Resizable BAR code has been placed inside pci.c and setup-res.c that do not use it for anything. Upcoming changes are going to add more Resizable BAR related functions, increasing the code size. As pci.c is huge as is, move the Resizable BAR related code and the BAR resize code from setup-res.c to rebar.c. Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Reviewed-by: Christian König Link: https://patch.msgid.link/20251113180053.27944-2-ilpo.jarvinen@linux.intel.com Stable-dep-of: ee7471fe968d ("PCI: Skip Resizable BAR restore on read error") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2242c75b632864325fd22699e418d51f6b8ed87e Author: Ilpo Järvinen Date: Tue Jul 14 16:02:34 2026 -0400 PCI: Add kerneldoc for pci_resize_resource() [ Upstream commit d787018e2dfdc4c1331538e7a8717690d1b7c9b3 ] As pci_resize_resource() is meant to be used also outside of PCI core, document the interface with kerneldoc. Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Alex Bennée # AVA, AMD GPU Link: https://patch.msgid.link/20251113162628.5946-8-ilpo.jarvinen@linux.intel.com Stable-dep-of: ee7471fe968d ("PCI: Skip Resizable BAR restore on read error") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4b5322f0002aac02a0f9907ac2358811330d982c Author: Ilpo Järvinen Date: Tue Jul 14 16:02:33 2026 -0400 PCI: Fix restoring BARs on BAR resize rollback path [ Upstream commit 337b1b566db087347194e4543ddfdfa5645275cc ] BAR resize operation is implemented in the pci_resize_resource() and pbus_reassign_bridge_resources() functions. pci_resize_resource() can be called either from __resource_resize_store() from sysfs or directly by the driver for the Endpoint Device. The pci_resize_resource() requires that caller has released the device resources that share the bridge window with the BAR to be resized as otherwise the bridge window is pinned in place and cannot be changed. pbus_reassign_bridge_resources() rolls back resources if the resize operation fails, but rollback is performed only for the bridge windows. Because releasing the device resources are done by the caller of the BAR resize interface, these functions performing the BAR resize do not have access to the device resources as they were before the resize. pbus_reassign_bridge_resources() could try __pci_bridge_assign_resources() after rolling back the bridge windows as they were, however, it will not guarantee the resource are assigned due to differences in how FW and the kernel assign the resources (alignment of the start address and tail). To perform rollback robustly, the BAR resize interface has to be altered to also release the device resources that share the bridge window with the BAR to be resized. Also, remove restoring from the entries failed list as saved list should now contain both the bridge windows and device resources so the extra restore is duplicated work. Some drivers (currently only amdgpu) want to prevent releasing some resources. Add exclude_bars param to pci_resize_resource() and make amdgpu pass its register BAR (BAR 2 or 5), which should never be released during resize operation. Normally 64-bit prefetchable resources do not share a bridge window with the 32-bit only register BAR, but there are various fallbacks in the resource assignment logic which may make the resources share the bridge window in rare cases. This change (together with the driver side changes) is to counter the resource releases that had to be done to prevent resource tree corruption in the ("PCI: Release assigned resource before restoring them") change. As such, it likely restores functionality in cases where device resources were released to avoid resource tree conflicts which appeared to be "working" when such conflicts were not correctly detected by the kernel. Reported-by: Simon Richter Link: https://lore.kernel.org/linux-pci/f9a8c975-f5d3-4dd2-988e-4371a1433a60@hogyros.de/ Reported-by: Alex Bennée Link: https://lore.kernel.org/linux-pci/874irqop6b.fsf@draig.linaro.org/ Signed-off-by: Ilpo Järvinen [bhelgaas: squash amdgpu BAR selection from https: //lore.kernel.org/r/20251114103053.13778-1-ilpo.jarvinen@linux.intel.com] Signed-off-by: Bjorn Helgaas Tested-by: Alex Bennée # AVA, AMD GPU Reviewed-by: Christian König Link: https://patch.msgid.link/20251113162628.5946-7-ilpo.jarvinen@linux.intel.com Stable-dep-of: ee7471fe968d ("PCI: Skip Resizable BAR restore on read error") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c18646165f21f7afccb92a9fe1ecc64d31cc403d Author: Ilpo Järvinen Date: Tue Jul 14 16:02:32 2026 -0400 PCI: Free saved list without holding pci_bus_sem [ Upstream commit 1d8a0506f69895b7cfd9d5c4546761c508231a8a ] Freeing the saved list does not require holding pci_bus_sem, so the critical section can be made shorter. Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Alex Bennée # AVA, AMD GPU Link: https://patch.msgid.link/20251113162628.5946-6-ilpo.jarvinen@linux.intel.com Stable-dep-of: ee7471fe968d ("PCI: Skip Resizable BAR restore on read error") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 534f20cdddc311444ff4398f202df283ac6d5a9c Author: Ilpo Järvinen Date: Tue Jul 14 16:02:31 2026 -0400 PCI: Try BAR resize even when no window was released [ Upstream commit 121d3e9e4b217f2f23715901fb15c6a3ca2bab46 ] Usually, resizing BARs requires releasing bridge windows in order to resize it to fit a larger BAR into the window. This is not always the case, however, FW could have made the window large enough to accommodate larger BAR as is, or the user might prefer to shrink a BAR to make more space for another Resizable BAR. Thus, replace the check that requires that at least one bridge window was released with a check that simply ensures bridge is not NULL. Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Alex Bennée # AVA, AMD GPU Link: https://patch.msgid.link/20251113162628.5946-5-ilpo.jarvinen@linux.intel.com Stable-dep-of: ee7471fe968d ("PCI: Skip Resizable BAR restore on read error") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dbb1d8507dd923f87cafa71fe575f8d9c458b248 Author: Ilpo Järvinen Date: Tue Jul 14 16:02:30 2026 -0400 PCI: Change pci_dev variable from 'bridge' to 'dev' [ Upstream commit 34c702ea0497e092a487eacdf28a037f43e3e39f ] Upcoming fix to BAR resize will store also device BAR resource in the saved list. Change the pci_dev variable in the loop from 'bridge' to 'dev' as the former would be misleading with non-bridges in the list. This is in a separate change to reduce churn in the upcoming BAR resize fix. While it appears that the logic in the loop doing pci_setup_bridge() is altered as 'bridge' variable is no longer updated, a bridge should never appear more than once in the saved list so the check can only match to the first entry. As such, the code with two distinct pci_dev variables better represents the intention of the check compared with the old code where bridge variable was reused for a different purpose. Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Alex Bennée # AVA, AMD GPU Reviewed-by: Alex Bennée Link: https://patch.msgid.link/20251113162628.5946-4-ilpo.jarvinen@linux.intel.com Stable-dep-of: ee7471fe968d ("PCI: Skip Resizable BAR restore on read error") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0d1c263e6fd731f3032b2e0e1bd150cd6021d918 Author: Ilpo Järvinen Date: Tue Jul 14 16:02:29 2026 -0400 PCI/IOV: Adjust ->barsz[] when changing BAR size [ Upstream commit 4687b3315a3f76647746f5b7f92684cf1045b085 ] pci_rebar_set_size() adjusts BAR size for both normal and IOV BARs. The struct pci_sriov keeps a cached copy of BAR size in ->barsz[] which is not adjusted by pci_rebar_set_size() but by pci_iov_resource_set_size(). pci_iov_resource_set_size() is called also from pci_resize_resource_set_size(). The current arrangement is problematic once BAR resize algorithm starts to roll back changes properly in case of a failure. The normal resource fitting algorithm rolls back resource size using the struct pci_dev_resource easily but also calling pci_resize_resource_set_size() or pci_iov_resource_set_size() to roll back BAR size would be an extra burden, whereas combining ->barsz[] update with pci_rebar_set_size() naturally rolls back it when restoring the old BAR size on a different layer of the BAR resize operation. Thus, rework pci_rebar_set_size() to also update ->barsz[]. Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Alex Bennée # AVA, AMD GPU Link: https://patch.msgid.link/20251113162628.5946-3-ilpo.jarvinen@linux.intel.com Stable-dep-of: ee7471fe968d ("PCI: Skip Resizable BAR restore on read error") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0dfad346c293ea3cbca122676ceb493706da69e5 Author: Richard Zhu Date: Tue Jul 14 13:49:21 2026 -0400 PCI: imx6: Configure REF_USE_PAD before PHY reset for i.MX95 [ Upstream commit 0c26b1c34d12d4debfb5363cc0be6cdf68e87ba2 ] According to the i.MX95 PCIe PHY Databook, the ref_use_pad signal in the Common Block Signals section selects the reference clock source connected to the PHY pads. Per the specification, any change to this input must be followed by a PHY reset assertion to take effect. Move the REF_USE_PAD configuration before the PHY reset toggle to comply with the required initialization sequence. Fixes: 47f54a902dcd ("PCI: imx6: Toggle the core reset for i.MX95 PCIe") Signed-off-by: Richard Zhu [mani: renamed the callback and helper to match the usecase] Signed-off-by: Manivannan Sadhasivam Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260518072715.3166514-2-hongxing.zhu@nxp.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e53d54b92f0c286e2644da70f4d542577749a720 Author: Franz Schnyder Date: Tue Jul 14 13:49:20 2026 -0400 PCI: imx6: Fix reference clock source selection for i.MX95 [ Upstream commit 88cc4cbe08bba27bb58888d25d336774aa0ccab1 ] In the PCIe PHY init for the i.MX95, the reference clock source selection uses a conditional instead of always passing the mask. This currently breaks functionality if the internal refclk is used. To fix this issue, always pass IMX95_PCIE_REF_USE_PAD as the mask and clear bit if external refclk is not used. This essentially swaps the parameters. Fixes: d8574ce57d76 ("PCI: imx6: Add external reference clock input mode support") Signed-off-by: Franz Schnyder Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Acked-by: Richard Zhu Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260325093118.684142-1-fra.schnyder@gmail.com Stable-dep-of: 0c26b1c34d12 ("PCI: imx6: Configure REF_USE_PAD before PHY reset for i.MX95") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1228926e1e4d605cc74d9e675558982a6f2cf446 Author: Chris Mason Date: Tue Jul 14 09:43:07 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 79ac87bb1a4c861e5c7c40b11dcc3d4a92ec6790 Author: Jisheng Zhang Date: Tue Jul 14 09:43:06 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 7ed120b1a007bace57c461805519d70e1af44e59 Author: Alex Williamson Date: Tue Jul 14 09:27:08 2026 -0400 vfio/mlx5: Fix racy bitfields and tighten struct layout [ Upstream commit f2365a63b02ddea32e7db78b742c2503ec7b81f1 ] Bitfield operations are not atomic, they use a read-modify-write pattern, therefore we should be careful not to pack bitfields that can be concurrently updated into the same storage unit. This split takes a binary approach: flags that are only modified pre/post open/close remain bitfields, flags modified from user action, including actions that reach across to another device (ex. reset) use dedicated storage units. Note mlx5_vhca_page_tracker.status is relocated to fill the alignment hole this split exposes. Bitfield justifications: migrate_cap: written only in mlx5vf_cmd_set_migratable() at probe chunk_mode: written only in mlx5vf_cmd_set_migratable() at probe mig_state_cap: written only in mlx5vf_cmd_set_migratable() at probe Dedicated storage units: mdev_detach: written in the VF attach/detach event notifier mlx5fv_vf_event() at runtime log_active: written in mlx5vf_start_page_tracker()/ mlx5vf_stop_page_tracker() during runtime dirty tracking deferred_reset: written in mlx5vf_state_mutex_unlock()/ mlx5vf_pci_aer_reset_done() during runtime reset handling is_err: set by tracker error handling and dirty-log polling at runtime object_changed: set by tracker event handling and cleared by dirty-log polling at runtime Fixes: 61a2f1460fd0 ("vfio/mlx5: Manage the VF attach/detach callback from the PF") Fixes: 79c3cf279926 ("vfio/mlx5: Init QP based resources for dirty tracking") Fixes: f886473071d6 ("vfio/mlx5: Add support for tracker object change event") Cc: Yishai Hadas Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Alex Williamson Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20260615191241.688297-5-alex.williamson@nvidia.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f8272331da877eec8fe8e89a1e98e6a710e12490 Author: Cássio Gabriel Date: Tue Jul 14 00:05:39 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 6438d0707087ec9d2bc4e1d72d983d22dee521f9 Author: Cássio Gabriel Date: Tue Jul 14 00:05:38 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 1ed7ff33cfc8cf55185dd5355e708790b1144d7b Author: Geoffrey D. Bennett Date: Mon Jul 13 22:09:14 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 ad5c5bdb0f5809dfadf53734948b0b4671e85546 Author: Geoffrey D. Bennett Date: Mon Jul 13 22:09:13 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 2745574697ee49bd667d88ef66cf5c619a78705a Author: Zhang Lixu Date: Mon Jul 13 13:57:33 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 7f680924c5c2b4ea44979005ba4faec0a72c04d7 Author: Rafael J. Wysocki Date: Fri Jul 10 11:47:10 2026 -0400 ACPI: NFIT: core: Fix possible deadlock and missing notifications [ Upstream commit 18a00ed0e718473f5c3fcfa49df46c944575e60c ] After commit 9b311b7313d6 ("ACPI: NFIT: Install Notify() handler before getting NFIT table"), ACPI NFIT driver removal may deadlock if an ACPI notify on the NFIT device is triggered concurrently. A similar deadlock may occur if an ACPI notify on the NFIT device is triggered during a failing driver probe. The deadlock is possible because acpi_dev_remove_notify_handler() calls acpi_os_wait_events_complete() after removing the notify handler and the driver core invokes it under the NFIT platform device lock which is also acquired by acpi_nfit_notify(). Thus acpi_os_wait_events_complete() may be waiting for acpi_nfit_notify() to complete, but the latter may not be able to acquire the device lock which is being held by the driver core while the former is being executed. Moreover, after commit 03667e146f81 ("ACPI: NFIT: core: Convert the driver to a platform one"), there are no sysfs notifications regarding NVDIMM devices because __acpi_nvdimm_notify() always bails out after checking the driver data pointer of the device's parent. That parent is the ACPI companion of the platform device used for driver binding, so its driver data pointer is always NULL after the commit in question which was overlooked by it. A remedy for the deadlock is to use a special separate lock for ACPI notify synchronization with driver probe and removal instead of the device lock of the NFIT device, while a remedy for the second issue is to populate the driver data pointer of the NFIT device's ACPI companion when the driver is ready to operate, so do both these things. However, since the new lock is not held across the entire teardown and acpi_nfit_notify() should do nothing when teardown is in progress, make it check the driver data pointer of the NFIT device's ACPI companion, in analogy with the existing check in __acpi_nvdimm_notify(), and bail out if that pointer is NULL. Fixes: 9b311b7313d6 ("ACPI: NFIT: Install Notify() handler before getting NFIT table") Fixes: 03667e146f81 ("ACPI: NFIT: core: Convert the driver to a platform one") Signed-off-by: Rafael J. Wysocki Cc: All applicable # 9995e4404ea4: ACPI: NFIT: core: Eliminate redundant local variable Reviewed-by: Dave Jiang Link: https://patch.msgid.link/3420096.aeNJFYEL58@rafael.j.wysocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cf5f93228e7aba5d0a36f276d702060348ee73f3 Author: Rafael J. Wysocki Date: Fri Jul 10 11:47:08 2026 -0400 ACPI: NFIT: core: Use devm_acpi_install_notify_handler() [ Upstream commit 198541ad53c0d0d891fedea4098f9953a0f566c0 ] Now that devm_acpi_install_notify_handler() is available, use it in acpi_nfit_probe() instead of a custom devm action removing an ACPI notify handler installed via acpi_dev_install_notify_handler(). Also drop the explicit ACPI_COMPANION() check against NULL that is not necessary any more becuase devm_acpi_install_notify_handler() carries out an equivalent check internally and use ACPI_HANDLE() to retrieve the platform device's ACPI handle. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/3048737.e9J7NaK4W3@rafael.j.wysocki Stable-dep-of: 18a00ed0e718 ("ACPI: NFIT: core: Fix possible deadlock and missing notifications") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d57d2aae87b23978ac71c058c51650bd4a3aef2b Author: Rafael J. Wysocki Date: Fri Jul 10 11:47:07 2026 -0400 ACPI: bus: Introduce devm_acpi_install_notify_handler() [ Upstream commit ca70ce555a1eb8edf5fb1d5575f1fe19c9ae17f4 ] Introduce devm_acpi_install_notify_handler() for installing an ACPI notify handler managed by devres that will be removed automatically on driver detach. It installs the notify handler on the device object in the ACPI namespace that corresponds to the owner device's ACPI companion, if present (an error is returned if the owner device doesn't have an ACPI companion). Currently, there is no way to manually remove the notify handler installed by it because none of its users brought on subsequently will need to do that. Signed-off-by: Rafael J. Wysocki [ rjw: Kerneldoc comment refinement ] Link: https://patch.msgid.link/2268031.irdbgypaU6@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki Stable-dep-of: 18a00ed0e718 ("ACPI: NFIT: core: Fix possible deadlock and missing notifications") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 34f4d0e4e5065237d15651df759a99e81b7f9f51 Author: Rafael J. Wysocki Date: Fri Jul 10 11:47:06 2026 -0400 ACPI: driver: Check ACPI_COMPANION() against NULL during probe [ Upstream commit e4865a56d013e86e46ea6acea15bb6eae01898ff ] Since 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(), platform drivers that rely on the existence of a device's ACPI companion object should verify its presence. Accordingly, add requisite ACPI_COMPANION() or ACPI_HANDLE() checks against NULL to 13 platform drivers handling core ACPI devices. Also change the value returned by the ACPI thermal zone driver when the device's ACPI companion is not present to -ENODEV for consistency with the other drivers. Signed-off-by: Rafael J. Wysocki Reviewed-by: Hans de Goede Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/4516068.ejJDZkT8p0@rafael.j.wysocki Cc: 7.0+ # 7.0+ Stable-dep-of: 18a00ed0e718 ("ACPI: NFIT: core: Fix possible deadlock and missing notifications") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3b2628f7682aea8d9ce09ad4b9a3bd144b451eaa Author: Rafael J. Wysocki Date: Fri Jul 10 09:32:35 2026 -0400 ACPI: NFIT: core: Fix acpi_nfit_init() error cleanup [ Upstream commit 38bf27511ef41bffebd157ec3eba41fc89ba59cd ] If acpi_nfit_init() fails after adding the acpi_desc object to the acpi_descs list, that object is never removed from that list because the acpi_nfit_shutdown() devm action is not added for the NFIT device in that case. Next, the acpi_nfit_init() failure causes acpi_nfit_probe() to fail, the acpi_desc object is freed, and a dangling pointer is left behind in the acpi_descs. Any subsequent ACPI Machine Check Exception will trigger nfit_handle_mce() which iterates over acpi_descs and so a use-after-free will occur. Moreover, if acpi_nfit_probe() returns 0 after installing a notify handler for the NFIT device and without allocating the acpi_desc object and setting the NFIT device's driver data pointer, the acpi_desc object will be allocated by acpi_nfit_update_notify() and acpi_nfit_init() will be called to initialize it. Regardless of whether or not acpi_nfit_init() fails in that case, the acpi_nfit_shutdown() devm action is not added for the NFIT device and acpi_desc is never removed from the acpi_descs list. If the acpi_desc object is freed subsequently on driver removal, any subsequent ACPI MCE will lead to a use-after-free like in the previous case. To address the first issue mentioned above, make acpi_nfit_probe() call acpi_nfit_shutdown() directly on acpi_nfit_init() failures and to address the other one, add a remove callback to the driver and make it call acpi_nfit_shutdown(). Also, since it is now possible to pass NULL to acpi_nfit_shutdown() or the acpi_desc object passed to it may not have been initialized, add checks against NULL for acpi_desc and its nvdimm_bus field to that function and make acpi_nfit_unregister() clear the latter after unregistering the NVDIMM bus. Fixes: a61fe6f7902e ("nfit, tools/testing/nvdimm: unify common init for acpi_nfit_desc") Fixes: fbabd829fe76 ("acpi, nfit: fix module unload vs workqueue shutdown race") Signed-off-by: Rafael J. Wysocki Cc: All applicable Reviewed-by: Dave Jiang Link: https://patch.msgid.link/1963615.tdWV9SEqCh@rafael.j.wysocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 83f29da85dc9d9a32fe62cd1055e8e6705e6bf80 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 f84c0bae0e8dd08a88fa2495687acc9f5c638222 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 174dc8103ab7b124ff976d06406f8c09c97f49dc 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 5b8f11cbe8ad5726b2b63ff1574d5cffa4df18c2 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 4f96903e2fd228aa96013372402d650f6dbe5cb3 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 aa276aa6cbfbc5622bf974cf9be1d579ce4a5fab 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 52990f6b575265d678717bad9178e59bcc5d2299 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 eefcd3ca245c1056c43c8a5a3cc1ec475e1d08cd 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 c02237966c199df2303fe6808ee1735bb299f503 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 8d94498cc4453282e6ef981ef863ba5f643b1fba 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 cf7258f57d18026b8f77c0e80ff1805e9caf7250 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 4b5de4007e5bf8edfb2947a3a76e8b328dc05969 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 de2bc884d887047732918050d03fd6f1d6b3f6fd 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 bf9848a22a8e50d39d5e8d871581f0a8110f16b3 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 04ebd3766861f219325852c9598e0f0281cb3636 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 ac2d9f6b4f90519ba7ead7baba04e8074bcb3975 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 a59cfa165aee3e29d06145041c0ebe46a51de604 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 b8df3a993f690cd639a158ad6ad6cfc5da709f49 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 90576bd6921a91eb038bffbb4b9467c2dc26aa1d 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 584657c5fc58d7a840623a2fa06331c9661dd0f1 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 3c1e92f75e11a11492b8cb901fceeb9f16ae6415 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 82753ac86cb3d641b8634a61335fd0f04a61cc1a 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 3fb7edd2018bb1ad0a68157383d9b9dac33dd645 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 d4ec18f48ce78a3bf7c999ac908691007375fe99 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 39151f0708c84221e94cdd6aa070aba5d7cb1c01 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 a75d2b5249e385e9b2cb23ffca945bb0e5e33ebf 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 fd701fc0d065260ad2e5c2ff1c830afb73012590 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 6744ab60dfac55d1df5733960aad5be300984301 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 dbd14f736be02cfe73049bd801af89becd1a0749 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 6926d13865aaa1548b8ba1f57f56e5df78e10774 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 688bd4c6144d23be6ba935c4b089ee3ba64e9839 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 55b26abb1fa1ec406b3ad11b43c49c7624257565 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 bdc0b8bfdc142439d6708b072e8159eb515ee7b0 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 65446b85595a4bec4400889e02021487ce92076a 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 816559409e340acaa5c9d868291dab30d8c80263 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 262da8b6ea03d01ee7ed01ad309e4c89941f6b14 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 9b8df4da2cf79317ceaa0500fb96601b0d720cf5 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 afa0db5322c5f26c565d8c0a7c8f68244c3d5f9b 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 d94160a5d1ac3936a5c09676e35336aaef6444c1 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 ba481c0b537607b238e64c3e92b4d39d6ea1b790 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 4ff3960f3527189bc115a927ed3561c758f562f1 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 9a0464fcfae4f35874eddfbc3925cc1661dacd65 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 c844b7d9a9586de15dd28c06da5cc7f6ab28787d 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 8131a91fe2dea7b1316cf5557ab13627f545b406 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 3dfec7490f3a26708b7a139d1bde7b6f8414e78f 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 c6b4d454865a81ceea1422243aaaedc363b6f713 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 fad36954b29592ce463254179c3043697678481f 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 eadd0c2c76aee6a738f17f251434c77db3c606c8 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 38cc4867540ae8beedfe41a1a1a6ed37052c77d6 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 91ec52dd2a5d9f791ea8fe2c83c8859cd64b8180 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 7a9a69641b68aca95f5fb001b05b87c4544cb580 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 52007bfdce5310e8c8a29849bfbfb188a1e50ca0 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 1155a9d0a2e0d708e4168f70a0b437324d4ed211 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 ccdf1770a4ba27e31599d24ad970d77a371c7912 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 5f5783c7806fc2b9e9e777cfa0b85a2203e48b2b 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 26b131b2d5b55a81ef6182769d28105a870c0eb2 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 b2f426a9a22886071966432ede8fceafffe12b8c 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 2cf10d042562283ff4ae97c02d0993d4f1b5ea29 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 83fb4c2c5344f02eac929f66de3c9d1adfcde04c 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 247d055504dcc852e539b9f7f30d19f9741474bf 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 61a7ff4a62003b55a15022567486741b3bd83914 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 685fb410d90e54fb18cbf43b7c25fe4afd14fb84 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 5df30f05db96552903680a17f858d250dfd9e86e 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 77caf2d6eba7cb94a7ecd7b369a5974fd7d7c054 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 f0745496f7c171271cafd9457df3b914a483ddeb 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 a5a367756926de1c21a013ea5ed7fc2219f4cb4f 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 018d7ad26cb8bdfe9842f2ca68a42b0bfdcc82fe 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 2faf0198168d2017cb528a79f76c560fda3b6e94 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 d8d4fa0c4f818e30b6f6737bdd989b7e2b511cae 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 07f5eb6d268a37bd9e131079489655cd599182e0 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 1286a4156333753cae99b3f2da3c4456a08eae2c 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 1dce4f4bb3c1c02080b1a45bdd2abb2913a6642a 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 82fc886e244c76fadf05ef1958aaf8815478ccde 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 2c76c01a505c133b6d5fc1f7815c57de63087da3 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 b4427ee3667c57065976d382257e073d40d1caf7 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 6c52226072a3c61337b1eec1799bb987748884fa 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 e2b7ee61989f2d39df6c2cc06f9db1aea69bdb09 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 5889064919a1e5c0a9469c54895000414fc46944 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 99a6f37b113c46815deb160c5012073563679ef4 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 ac58088d70b8acdf9cf25db87ecff8c55660d63d 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 f0aad157576da199c146c1bb266442befa7912ca 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 715cce38424fb2488ef2c5e6e6ffbfe1b74a9e67 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 664480021f6a4ce97e3778739af3a834a66e82e0 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 c6c990f7208c9ad08b6e2ac448f3741dd9cd3fc1 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 8dc6c7e8c96787ce49289d6efc5ff79330c01177 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 6e21d1253ef1322718984b9c45f561d1f8a3823b 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 6c98ccdb9a0967e04a7b1866eb0d97c0c8c0e403 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 f5c5065963024390ddad51bd455d1adc710de575 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 a66d45e0ce6d73cd79962d422388e61bfaf0cb50 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 ddbb6e3dc9bb4743de686aa1598c31e745cee76b 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 a65f49b6f7ece756394f8f0e85570020e7fd0e35 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 20ac8131f8c90608e99b96221ec6313b9bf3907e 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 612cda6630f2e6a054ac69fbfef9411261d92fef 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 4b73889941b95f82c7386f64de9c979bd3b7b8d8 Author: Ihor Solodrai Date: Mon Feb 23 11:07:17 2026 -0800 selftests/bpf: Add simple strscpy() implementation commit 63c49efc987afefc6b9bb7de083eb8748e0b1789 upstream. Replace bpf_strlcpy() in bpf_util.h with a sized_strscpy(), which is a simplified sized_strscpy() from the kernel (lib/string.c [1]). It: * takes a count (destination size) parameter * guarantees NULL-termination * returns the number of characters copied or -E2BIG Re-define strscpy macro similar to in-kernel implementation [2]: allow the count parameter to be optional. Add #ifdef-s to tools/include/linux/args.h, as they may be defined in other system headers (for example, __CONCAT in sys/cdefs.h). Fixup the single existing bpf_strlcpy() call in cgroup_helpers.c [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/string.c?h=v6.19#n113 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/string.h?h=v6.19#n91 Signed-off-by: Ihor Solodrai Link: https://lore.kernel.org/r/20260223190736.649171-2-ihor.solodrai@linux.dev Signed-off-by: Alexei Starovoitov Cc: Shung-Hsi Yu Signed-off-by: Greg Kroah-Hartman commit da7f17c2d5bb444101003e37ea323a58d889eacb Author: Sean Christopherson Date: Mon Jul 20 11:03:29 2026 +0800 KVM: TDX: Account all non-transient page allocations for per-TD structures [ Upstream commit a8b2924676ec42d76597f849baba31acc3ba1bfc ] Account all non-transient allocations associated with a single TD (or its vCPUs), as KVM's ABI is that allocations that are active for the lifetime of a VM are accounted. Leave temporary allocations, i.e. allocations that are freed within a single function/ioctl, unaccounted, to again align with KVM's existing behavior, e.g. see commit dd103407ca31 ("KVM: X86: Remove unnecessary GFP_KERNEL_ACCOUNT for temporary variables"). Fixes: 8d032b683c29 ("KVM: TDX: create/destroy VM structure") Fixes: a50f673f25e0 ("KVM: TDX: Do TDX specific vcpu initialization") Cc: stable@vger.kernel.org Reviewed-by: Kai Huang Reviewed-by: Rick Edgecombe Link: https://patch.msgid.link/20260129011517.3545883-4-seanjc@google.com Signed-off-by: Sean Christopherson [ Binbin: Resolved conflicts in __tdx_td_init() due to lacking commits eac90a5ba0aa and 69050f8d6d07, retain nr_configured_hkid increment and kcalloc() call. ] Signed-off-by: Binbin Wu Signed-off-by: Sasha Levin commit d0cc2c74060be4559a1fae1428f40802fb2eba6c 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 6cec36c795c03a4c660205a992fbefa10eeb9e78 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 55da782eb4545d9baf2cb030121f3adbc8e7f25d 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 35267819b25074084130b6a7be18bbaf44d3ae74 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 2059c28bd725beded01277cdf1f67be33e714323 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 cb5cca1d2a908ddd5e357971de0f2009617b8d6a 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 314f21c9dd0dc9fb986a585b75927fc2b5a7ccf3 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 1905ebabe638c946aced00c4bb664da26cac56d5 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 19c148cb82d11bb7cc7d86038a94e608a297e63c 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 234cd54fc500f69db43e37de38603da617fbbeea 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 03d8843b143ebbbfaf48511922abc6e886575a61 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 68cadc3698c7de88966d306d12ec9c6217da228a 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 9571af2eec8023af9a1671b7f2cd4ab400011724 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 0b2f9c908f930ec4be17d389723f9a202d6a883c 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 6596baf8041100a9d1647beb5ea8ea4496ce058f 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 ab625256882e0e25ff6d72cc276424d8c02b21fc 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 b3d835407846134b0d54637c0281b39bebef831d 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 3f85fcd520aa703824b1958f35169925ddae2558 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 e89b8829693e65217d587dceeaad4826c96c731b 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 121c5f31c3fb70d4a23e8a084f5cb8b3ec63be8d 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 3118e97dae533fb45964b87bbed1801afcff7c65 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 5d7bd8790309b9e344da099117f449a9e86eeb6a 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 d3b9026ef78da3018a7d2c5a9c9d611de6d45c47 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 4e16bc75c750213eac24e5494be2753d3e7ea3df 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 b6e040b5143cc2d378f7490b560e39d56afe09aa 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 ac761e66708d51dac35c4c7f1891ea991dc788f0 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 0630f2c3c16c08271f550bee7c260dcde95fc8d1 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 6cb15b81ff545840048fb0e1a6e827d560dbf367 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 f77117530fc3f5932ffb107182a6dd34006be9b6 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 afd147e59b32a00dc505f88fe2922bf07c82bb81 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 ea6a188ee805e841a0e242f14d15953e0dfa74bb 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 633cadbc0b8323f5cc140a285d2432089dbb534e 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 fcff712d0e3d183843ec3916470ee6cc3455baad 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 b33ac2d39953efb12f598c0dae242c5f644ea669 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 ed3cc4218070d6b98bf5fb456dccae424fd38c4f 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 0e8115a7ed9a99ff9495615a575a6c0f43566d10 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 f516cba88bf952d847e5c96d0e87f17eaae7ee6f 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 383934c249a9817d242d02d30bfbc8defbf0d533 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 9c964fc9507aeab74376ba9f892cf84ad6950dfe 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 99c428d7ef644d3e394f3072f905040c16dab18d 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 05ac85da121980dba89de0966c1c47e7489dc4b7 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 f28c5cabb2df09ad1fcfb7cdb2b3ed2f690d81f0 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 c8d3d83f2eaaf7659de76e8d44e8fc88ee346042 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 6329d1af316a4b154465d008cf74e075282938ad 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 87e2f89dea078572fb9e13864cec2b1bd8e89b71 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 6aacc18004b1a915ccb8a829d30279a37988066e 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 df87532e9212238509f23effd0ca39d9c3062d21 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 9b871369cbb4532f6715e044d6b9c4ceb036e5b6 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 cb7bdae7fba404852ade34b0c1445fbaf3e54fbb 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 004ccd2d3b4ac36a300e05e01df152e5c02a5a82 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 f1516c56ac540da1769f264c3cfefe4499548a5d 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 255fb7b0cdc947b1c01929c7f133281342a3a6b5 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 d0a8a6660d58e4a9f191c01e07d4db61f8bcf264 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 ed08497977820e002a62cb114440f365cc7a087f 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 d495b403d5b357dfe506b963bd7a78ecd5c7b667 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 257321a1c036da417f5d9c47b95c7e58f62bf263 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 4e370b5289624f46a356dcc94f9f87025eaa6036 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 7aa8f3dba53422465dbe1be8dbb7240304462bb2 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 089e05b644d5aa786c21af467c80b24d691becb1 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 c8d743bb0e98ac9bbb3d5a84c3ded3cd54b357b0 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 f15eaa3801f2f9207dff156f1ab3e7436ce52bb1 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 2a0858cba1dab49df2a6b14acfcb4bc70a50f720 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 5dfd8042635278613da3b88553e25ade2103cd58 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 aa5113e7155f4ea81d2c0303ab5cb272d4b32627 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 0c4e9bb1d4101030f55c869f18bd3ece39a77bbb 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 92e3c93d60be1f2425738cd66dbadac7d6bc0cd1 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 ee458c3c18343ea18ea8eda357581366b8304598 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 461d36b5ddafc4b851ddb54486f8170fa281aebe 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 1247615aadb74c89c1b2f01a6de7df9dab92ecb3 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 e0b0163a65758ec3a2361ae1cea407898c27f21e 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 d61c12573ed9768690fdcb2bc38846a1bcb01358 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 021dab70eb37dd34e9a2742667b7ef522fb00208 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 1fcb5e29dd7a5b85adb9d8b539911741d878e829 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 7f76245960a332f39b08cc556e675d1765dc5bbb 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 ac2136dc4441dc71cc6ebc35b68fcd764931a6dc 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 8a3c44a003176282ee4306b7c96e5a536c6f0707 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 ffd17a393921af784f9b2391d6be8b135162fe9f 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 2977b5fe401c1812640c2abf04514c4856a3647c 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 af382ffca93e52d2c2c1d40f4635e351e296dbab 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 0b6252afcd1965f77c6a6f8a802a2e1381822b98 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 c4f626ddf2350652ad2f79daf1f10847f3f6eabd 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 0993dc5fc619c0b25ab1310cb11d65e78351c0fe 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 b06a4a397ac826603f39875cb7c7819a41365196 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 35f0ac19efb1a3f6c5e12c00e475a9ec2d9c3a6d 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 cd830e0bc25ee2d38cbfbdbb3cd77c5f53b2b6d5 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 37beb16e08cae94cc05840c7274225e3b0b38ae7 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 7bef39ba76eb7307ed22a50329e0f5776dbeda58 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 b88a511308779c225005d7994b8744561bdbafbc 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 765ba1c91823a296447528791b89a6504947fd5c 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 5e4c8e08ce95730c87d6ada0bdbe1131a3c06393 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 26355295ce21cb046546085c3a81abe68160a784 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 2944113ad5fbcdf5d349d857c03d2a44b6de75b8 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 2eaa3ad450141cfcf187bb43cb8335eb336b5f87 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 59cef6abc924a84824b0c3f563a7fe74cd5fc7a4 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 0ffc032294a29601b1019dba91aa1a930d90df17 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 ebe0a55d954fa8da383b6192edb8f763dcb002d5 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 d44b828eb551bd59ba9f22457825cc3db3a39fc1 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 9b092f9e6b34db11710d74c85f364878fbad41f0 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 ada4b9a5087ea7f30dd8e4c6411a4fb6547eb1ed 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 95bdf3950d668f83dd08f864f68da4b8dbed22bb 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 8ca2a19a987a7d1cb4c916ed9723a1c6993b4276 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 e0f688ccb20f10fe16c4873ccf808eb3d1d5c96a 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 5b0c4c916f202b8fd13d12afb6af62b385622f81 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 16d3ccdabb8dee9be2cdcd6d3f9a125572ec0454 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 e497fef9ad7e913f52de6f97e818f56915e96164 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 0ced34b4bbc046cf215a4172548e9a0e1832f00b 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 33a1bee413628378fd036a4f2b17ba86b0bc560c 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 bccae122dab8fbed24f9f650486b490c124bc6e8 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 8bd84316bbaf357e790e32c6795d791cadff7ab1 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 e6a395a71f4652261d09b572a03c96052662a056 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 2f3f471a448a5be40e35d55d0eb26775bc762b86 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 5d3240f42a667e29262aff76fdebfcdac4980626 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 6d2c973926d0612360693bc559be2ffde836151b 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 500716a007b2e5c081600bf84978fe5e951c61e1 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 1dcd7565e5909d87b604e8fe8565c9a6d9b01f42 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 3cd6f93f3d593838d4aa17a55379291c2250dc28 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 6cc15183573691761ea0c91447a5952ef9b4ae9e 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 fe623f9515bb07bd88c15ad4ca34cfa03682f8e3 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 eafc5aca7156465a901cb7900e6ececc190c07f3 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 e628d9169f9e110d5c4fc696c83c1958ce73b519 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 27d16a19ae74f547ea99bdaa90fd44957845a296 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 d8bc45c4c1a45fd22bf547adfcfc0d128bebed60 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 cea03d67db3a880893360bdbb1b0b8d9b33b1799 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 1e41ca4a7fba2e680d6950e9511245255fffa46c 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 ddbc4a8a4fe296f1fa2e59f7d176fc7c773df640 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 7926c1e4be86379945fb5f168888ac4d2aaf6c91 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 933654508b2bc36e2c3c086c0365e2403fb2141f 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 934d1cd40e2893bf7a041b54f6afd1c008d7a21c 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 ba33b4f9d3423accd2c91a0b0b0680cd589922f2 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 781f28bd982cf3deee7b084cb9e61cef44bb107e 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 36ca587f55a2c04468a89fd16174bb2f78dc04ec 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 0d078152fcab71f7a273b41051affb07f74a028a 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 9ac007affa77c3dc3def53760e3d69c350fc9967 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 3fac46068fe4cea22ed373432b9173a915e8e60d 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 ff7bcc9d71bf4017fe7d0db99a542c46ad3c7662 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 0fd20c1905abc90754bfaa60fdd0d91fd3b724cb 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 c0806df5cf806545160f3fdac3c888926ceac557 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 433e5e70cdc1edf382d28d08a885b22e2b98b7da 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 693bf91d4db134f9b1c2840c8e287eee3d993bac 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 c9ef79e34bc1eac4fd59051e5c7b96a74e59d46f 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 e5824d5b841d99a2bcdd4e2c256643293bbc22c1 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 fc74244e0cc2520b9a42f5e9fa285c7588ea76db 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 3ebe0ee6527e85cb448a085ade59404332067af2 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 012683accbb7d2bcf1264f2a0ecd6aa1dcea4d68 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 2174c68f623b74bd8690a4a6a4a52882d8ac3dc3 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 5e512d370a01b594d2dc01a8ad954af51d8c322f 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 4db3b6a2a8ecf2a89d26a4090ace4072c6fad050 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 499714de42ab4d2e778cbb10186684142a1222eb 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 671889c553ea55e2da6a4f3b15f4c0fa40f2f0d1 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 bd73971fad89d5ee4ea0ba9b92d2ea08733c4a64 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 d5d5a21fb33cd9b963aea99da81e4dacd452cd95 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 4bbfcf9c7e46cae58257150bf834853559382e28 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 a8874c34c4a973f9922908a4b8be1d1278f01e42 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 ace3a0c839f3bfe1779c6708e7709c824b96dc2f 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 b6337e3687d3d6652b951f534dfc62fbbdcdb9a4 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 bf53557a96d4cf50995778d413acaa40e66c59fb 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 8d263bae573dc6cd8a7f68eeea3cf4112fc90cd7 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 83405848e40302811d90b22b216f1f10794d0d61 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 a7bbf83dfebdc91609da4fb9a3669819b4375fdc 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 8d610017c992de705b304d3d727a6e3a86af6149 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 d8dcbbfa0d695a5244059aa34a2e81f3e8df1082 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 4e4beef747c687bd087988cf1cbd1e979dfd938e 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 da5234df0941665f3a3f5b80f3dab94046537be0 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 749e2051da3b0704b645001e7038c1029c252668 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 07ed8b178548014d3d3466b2d088fc9eb84bf5fd 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 b6a6fb6803d5248ed51805cea451c6cc0279994a 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 4d67bdef35c329bf63f8d2521556b0458ae3d145 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 43b987ed35be9be21a303d1036d4241fec9943df 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 40a04601a3f66cabd6629c258a07af645a658865 Author: SeongJae 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 f18c561eb9c51f1ba3adb6117926a98a66599848 Author: SeongJae 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 f322955d9a1c344ed943752f05aacea7bc22e025 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 1caee6e084a96ada94658f261ced377d85af3f03 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 bd2e9be9ebb64264087eee9674b94b4d6f2e7362 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 193e6471e985c2f25d09b3fe96ec52f4eab89bd4 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 1f18aac2637220b5847d073447498e81ddca10b2 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 ff05a98150ebb2b03919a9c05c576681e86abbb7 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 f3624cc069195001c88df7a291af215f2133ff2c 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 aaa1f956c0fc41089a4a534da7df91552a08a47c 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 0fad25687d4d3fa1fdd313d31b9cb5817c425029 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 be306b8d9143a9c076c804a7ca025d69caf9c448 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 908c9243ba309997b73cbda3e4c563d0fb345ee9 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 7adb38279812c9c06b0e3fa7382f4d7887f3fa2d 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 50b5e83384e7fed3d11d18b79ff350e9d6d89861 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 d240cd98f5f7b65c90f6b2b6abe3232ccdc405ab 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 09fddd52c1b0cef2c086d61be8f3d5dc92e36565 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 ccd6b70798737573a5e7cf2759aa99a24bd1de1b 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 640627f07c79be6fc1a572fc749490a8f62844c2 Author: SeongJae 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 722e6c54bde6391fb95f0357f555aca887c7b18c 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 1697d253f51cf5e3825a3423ff49e128a3502ab2 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 9227b387eee50dbf0e2fc67047a877177f121f74 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 a3d81de441233a92ec21469cd0c4eb3c26b95cd8 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 a39d281f207b9ce108fd6ce1e9a736530efb6e1d 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 d3fd2d358df0ca712183509cbbed6a16bde1d17e 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 11a3bc25f2c309bbe33cd3be57f2743ffde2330a 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 2c551f14f55e4ce0ca84d2870b491b9cac670120 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 620a37ea7d6264a8d0d8791b5e1ffffbb62d8bc9 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 51aad3d89a2dd2bd34713785b0f2fd5177eb33b6 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 69e18135e2a004a79505451dbef07314ea16e1eb 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 46d59ff421824b6483549d87f14efffbbbd1f6cb 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 1161c4b5bd0048c8148e919f818a33cff3623ef0 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 66014ab165cb01bfef5836939412a8ef98d5d5ff 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 65b23bec1fca6e9ebdc3e6041ebf8c6ab074141b 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 3f9ee75a97a769be258784c22b89657acb5ed9bd 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 30d490bb2c4cd220e7dedf862ab6a09eb5dcbad5 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 f4ca396bdd60b4e0a665b2589bfc4ddbea9bda2b 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 78955fdce8ff654e6d33a2fa90882a1e7eb26330 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 7199c78c3a3e399a4dc439d845826793880ccedc Author: Pauli Virtanen Date: Sat Apr 18 18:41:12 2026 +0300 Bluetooth: SCO: hold sk properly in sco_conn_ready commit 4e37f6452d586b95c346a9abdd2fb80b67794f39 upstream. sk deref in sco_conn_ready must be done either under conn->lock, or holding a refcount, to avoid concurrent close. conn->sk and parent sk is currently accessed without either, and without checking parent->sk_state: [Task 1] [Task 2] sco_sock_release sco_conn_ready sk = conn->sk lock_sock(sk) conn->sk = NULL lock_sock(sk) release_sock(sk) sco_sock_kill(sk) UAF on sk deref and similarly for access to sco_get_sock_listen() return value. Fix possible UAF by holding sk refcount in sco_conn_ready() and making sco_get_sock_listen() increase refcount. Also recheck after lock_sock that the socket is still valid. Adjust conn->sk locking so it's protected also by lock_sock() of the associated socket if any. Fixes: 27c24fda62b60 ("Bluetooth: switch to lock_sock in SCO") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 77eb0cf57009ec4ae5044db1a8096d1d787765a4 Author: Pauli Virtanen Date: Sun Apr 12 21:47:42 2026 +0300 Bluetooth: SCO: fix sleeping under spinlock in sco_conn_ready commit b819db93d73f4593636299e229914052b89e3ef2 upstream. sco_conn_ready calls sleeping functions under conn->lock spinlock. The critical section can be reduced: conn->hcon is modified only with hdev->lock held. It is guaranteed to be held in sco_conn_ready, so conn->lock is not needed to guard it. Move taking conn->lock after lock_sock(parent). This also follows the lock ordering lock_sock() > conn->lock elsewhere in the file. Fixes: 27c24fda62b60 ("Bluetooth: switch to lock_sock in SCO") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 96dd35f1942cdd5db7675eee1086193cc2e16001 Author: Benoît Sevens Date: Mon Mar 23 12:47:37 2026 +0000 HID: playstation: validate num_touch_reports in DualShock 4 reports commit 82a4fc46330910b4c1d9b189561439d468e3ff11 upstream. The DualShock 4 HID driver fails to validate the num_touch_reports field received from the device in both USB and Bluetooth input reports. A malicious device could set this field to a value larger than the allocated size of the touch_reports array (3 for USB, 4 for Bluetooth), leading to an out-of-bounds read in dualshock4_parse_report(). This can result in kernel memory disclosure when processing malicious HID reports. Validate num_touch_reports against the array size for the respective connection types before processing the touch data. Signed-off-by: Benoît Sevens Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 88ba8454685087dd2b0edc07af8c1feb61574258 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 d8e2f3e1bc207749ad58b12f40c41b0b4cd5f4e9 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 3256c05d5a9db34346eaf20f52dddde984852d77 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 d2b657c9653fcebca828a2ead13f444e0da68817 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 a90f4fff9025371bce5371daa610af957de8dd6a 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 c945f6007e7851e74706c72f98763023699bcd97 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 8f54162e07d3eea1e4ff21464cf2a815d79b6510 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 2c989ab8e20543212f0f4fc7d7f092a529074b8c 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 6a65ac8a81e903bb4b555c1d13532f5cb0167a4a 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 ee878decf9e570c5ff52c88690de75881e7d8f2a 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 9e16b6751a8206de0b865d99bb02771e6751d12d 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 8f76277d02176cd739945bba3379448e2e22e799 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 e5e18886aadd3870e2d84e32a9678317fab1dd9e 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 3b4c70c40f2e135a50cd38fc61c7d23a296a9981 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 b8afcf799b2cc92c41beebd029e53ed18960184a 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 85a71a81854e0e191ad0e533eabb4eff54866feb 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 e6b43acd34b219b807e65096ce207b087942779d 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 fa1ebae4206e6afc8caa642e9eb1bbe39a9a724f 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 8514585aa9553b648a0b19fa38083c5a0af4cce8 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 221ee479a49fb2fcc5d64b8eb94bd1d70e622280 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 5ab0eba9c8819506bcb72348fd701f8a9006f95e 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 046f6244da9b68e463a849b21446b9424e531491 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 394e2bdf7594e9190d6abc2c5e98c48b1a34b017 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 f7c67c97b37c11f2a95c204092fb8159f2779e8f 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 1a1d6e3ef6cf5851cf0c70dab37de94c80699852 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 19ffeb30fdfce63f8d6aca71bcdddb3f69d46278 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 16a42c88c4667fa0bd944e438a667e059551f1f1 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 6dd51d84a9502553e58beade72823258871b8111 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 3a134c3fb5f0d21871d65d0855d8bf6e5900645d 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 d61a80b17254be7230bc5544f8e62ddf21ab38e2 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 fc633a598206d4f23af782db7c0b5f3a82751d2c 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 e9cdf741ffcb4630fe75c4910457b749d86664bd 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 c6854d9f4e1bd7f0fc16f94bb080feebc3b1ed16 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 c4d6442ac3ed00041fe4e1df715717ed78a7d37f 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 1c4f67c89fd27c4df4c70b135c2c59627698b3c0 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 679ced28a9dc2f6dc679eb05027d779693e60902 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 b2dbbedfa935cc60f127f0153c741effba37181c 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 3cd9a5792cbea81139c24320986dd0db69e9b5d0 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 a58230f3a7c4f6c3261786bc1efb72c42e68cd25 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 2bcf2c5052fb5e73e255140ab43f056aef409c27 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 02b6b0e892aea582590671796fd6eff5b93ea93f 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 0ca505346c5e2905ab7b5313af801fcf38f594a8 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 07f9ddbf5e799c24a3a52ec9bd7b729a6f6d69d5 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 a1b672a3b537242ac698dbbd11273d1a100892db 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 aff589556ed772cb1c0c2d7b4d91ec45c0c39416 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 ca028334343a140efda4b22e53cbce2c5e94a489 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 e42d8322b67f21493a832ec338aad1c93bd01ea7 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 4b068759d308777a99ca809a1d514bbf7ae3bef9 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 51c367230e30ed80b49d5330831c1f2c59405b02 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 e0f276f1918a202e9c3ac72baffd311cecb6b8db 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 d3abaedf6a58469610136d2dace1a85cddf7afcf 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 121577383b5cf221e86581e0f2bcca4c66f17469 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 4ebe2c3a7db6332aab3655f8c552ca387c1dc199 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 009a8514745b16c468acc25aa00539abbf38e1b5 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 58bc18e03481b62f0ec53fe47f36615d52660a7d 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 d81860691e4cfa14d596136ea2727f244e9e5950 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 e1ca9b8559e0f5959228626bdeaae530a1ee0337 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 12fe6a56506ed3bf0aaf6130a29102ce1fce62da 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 ad54698255a4b988cae1ad908c158c1d4128887c 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 146b708bc75f1e6cf70df31195632c9946cb70fd 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 c2c795a320e7ef9aa69c7f4bd2c9ac07064eff9a 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 febb5b4f67ace78d6b6862cc3c853b64710afb6c 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 9423e1f105270af33971a8e3e02f0db2c231f226 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 d684ce2db92b1093bcca2b42e5160a5fe23eb496 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 e8c9aae8c950869f65af8b9dd2f71f861ea6e433 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 6854cf33dddb212bd7c3d69189623876e7334075 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 d5436e18e4fc2886ac306304d884ea3b92e1edbf 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 4ead4def04659739c399bfcb063f8a906194c79f 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 5c50db5bcbb9073cb2fd97be51b962de92f429e9 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 884b44256041ec6b2dcbe8e6a67384d26145cba1 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 09f35145f3a4aacea4d9b914ad895bf5af8fc4ae 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 5000bcae71c869cba6674c326fec2d8ad659ae3a 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 7099e7148f81c605bbc319b16ce0131540341560 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 7996013b85687034d2e820cef94d6404192e3a3d 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 d1379888cc4230bac647ec24ab83306afbd03e88 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 97542f15dc4cf6cd3fdc035e482dca54246ddf48 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 ba06690b28be950bd46d938d9b919c4024292627 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 df72596278b0e22dac5ef2881e9221a3a2c4ed11 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 d19dca8194ebed371e624331c6be2cb73b562caf 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 79fdd2aa774e44847cd9bb7edc811e73e3dc7bfe 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 5fb75c5272950b3ebe8bdee7abfdafd44f38313b 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 9f8eaef40e955cd0aecd4e157af2a749611d6214 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 33d79ad6ecedf7baf4ac495716798b51a3d90b8e 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 f3efcef6648ba9be40b0712c569ded7918e8c6ba 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 45f2e6505fcf63b0bda2490751210c78cfe5842b 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 efe27b19a15c384cad7c80de399f3107ab070e6d 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 199b570d7fca1aa70e596f10a6276997becffb6d 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 1ee200a1764f89ecc0f48620a3a3e2439c9565b9 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 f550bf32b9a064bc0f60af9579c39586d3cfea81 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 7da4d1a6b74004d02adfa06a0b49495e12636903 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 804821b69b2d164eef35d3dbb7eaebe354e9eeec 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 c632a27f35cff488310a40461c6b138029a4256c 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 bd938c985ab345d52177eb1a268d0d64ba0c8bae 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 ead9f10428c7342e5524bf6d8f7057fe048fe6c1 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 a98bda2305f3f66a993d835e9e948d92734c1b50 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 4fd52ac541ce1f2a2212b98320b60e911d9bbe71 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 68f9773754f05a533a36493986b809d9d33c4a41 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 e2e3fb995175c34136a10ae3b8bc277a5ba55d6c 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 508e55e81870d444078dcd3a6cbc9c27b13062fd 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 e8dc96a42571e7a09795ed59fc6f6269e88dc93a 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 89edae416141265b169378a8f434c752176749fa 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 5526d1997aea6c9bd865ca4d4894b52e799d735c 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 908391d801b24dc242026c7ccf37185a3d443d36 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 eebf439aa7a1369cb14f355584b4ffb03988cd71 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 e62adb157c2eaad9ad4867ec6cd9af5b9a51b1c7 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 22100a8f73d4ae4f17697dae93d4e2e1d283a6ec 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 61a55fa24a5d737436018764a647fe5b6cb36371 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 d34deef34c99bb4b3ebd2ac51058857827a20e7e 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 0c4fbdaca225b97122b61b68c5353caa33a253c3 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 711d912b18763af62a63aa8f2419a774eb63bba4 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 fb4293173db2d474d8fbc0e5ecf4943e6df2b40e 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 d8715b5a8fdb23fef576700e71d0c253dbeddad4 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 3a2b47d1b4b3de54d030a7fdb6a322c970513ee3 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 2d8b3c3e129973a51ae924bdcf6993a76b828814 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 b65e46eed9e52483e949e026f9b445f9201284fd 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 1627e7d5c9b09721a141d07cedb178882f1ded67 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 327595e7c34e36fdb5c9245596404d66fa84aede 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 3de77d2f34c2bc2acaedabc2c5e0a561b85c283a 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 ee3f7566bcf331fe669e104fd925e5946fb6869d 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 1550b07bca2bba9eb69a5f5f855a1fa2513ddc90 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 346e2d666a29ae7233c56b356a0487eb1d42589b 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 14e03ecd3b1b5fc03c082b27a2f8889f8290c30e 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 5b0427ba582d143a364301f825f4e32272f06d2d 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 13965a7b190f37b89548f0197cbf2603f27cc9c7 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 b784cd1c24d89bf71be2efe1e948ff7c03371e57 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 df0e3e70f6995465e6e357bae1d1f0fa9fffd77a 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 8f48cfe657409fb5c7ba0521b14da6d47546d9cf 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 7510451a58c271131d353243c636964334e0b5b4 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 d73f4249776dd970ad65a69cfc51613dd8a034bb 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 d340e351a0a74264b36b5880690eda8347548741 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 238c612357b5a25f03eacf356f95034f8551f218 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 f60ec3058a85447008b88b762c859d336163acb3 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 27506827a01f6dd7a49fc9572a37012db245164b 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 d269eb67d2e58f7eb55c895e07fbf9f66d77cc51 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 9ce741c22df4fd9546e30306317ac7df3607e48f 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 75e984fe0cb9e7fbde0c8ee838c61ce8573d3ea3 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 3bfcce441c552133adeeb99c294d0ce8a62612ef 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 7cc438c99bba324a0562b1bafa747b10f7e251df 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 9579d625171a140dc56c903f58ee50fdc8a0c243 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 7aa0e64fea778a9e3df73e64da95367ff8ad2ea5 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 72119397cdff64d8c011addd7d39e3332aa46c0d 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 762116dfa72865c82151970960f7cf34f44b21c8 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 267809e2c56fbea486f7250c8a4acddcc3c54dc5 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 1cd434ac1c222448bc121bd2e2dd7a95e8704670 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 5e15cf51982f85383e32d907e8f71b85ad3cf213 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 6c736c5ccf4a3aed68fc4042963d9b07629ef362 Author: Rosen Penev Date: Thu Mar 19 17:53:38 2026 -0700 gpio: dwapb: reduce allocation to single kzalloc [ Upstream commit 9a5bf2f53b76b1619c602f9e751fe4c0e64713ca ] Instead of kzalloc + kcalloc, Combine the two using a flexible array member. Allows using __counted_by for extra runtime analysis. Move counting variable to right after allocation as required by __counted_by. Signed-off-by: Rosen Penev Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260320005338.30355-1-rosenp@gmail.com Signed-off-by: Bartosz Golaszewski Stable-dep-of: d775b9451eb8 ("gpio: dwapb: Defer clock gating until noirq") Signed-off-by: Sasha Levin commit d7b5497e0e45be7aabeb120ce01f54f34de57888 Author: Jisheng Zhang Date: Mon Nov 24 08:20:52 2025 +0800 gpio: dwapb: Use modern PM macros [ Upstream commit 3f19e57cbfb55d743d60aeebf5d5c48cc7fd5d4e ] Use the modern PM macros for the suspend and resume functions to be automatically dropped by the compiler when CONFIG_PM or CONFIG_PM_SLEEP are disabled, without having to use #ifdef guards. This has the advantage of always compiling these functions in, independently of any Kconfig option. Thanks to that, bugs and other regressions are subsequently easier to catch. Signed-off-by: Jisheng Zhang Acked-by: Linus Walleij Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20251124002105.25429-2-jszhang@kernel.org Signed-off-by: Bartosz Golaszewski Stable-dep-of: d775b9451eb8 ("gpio: dwapb: Defer clock gating until noirq") Signed-off-by: Sasha Levin commit a3010b732d620218d869370f690b06d81e10d45e 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 e8a4c9fc437b16aef38f86ce3275677e36924259 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 b3eeb586f94c706c456cd18ca290a6aeddca3e77 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 ec5e96aee75d27779b9a860307679f13f33adb0c 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 0c602cb8f148a36bfb39c25ade400bdadc023c4f 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 bfc9e7be289df11e8e38c98cd78019d67fdd0bd5 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 b69b1ab121fe835e7601b0b587c9f565e4913b21 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 da4d8eea0c5f33ea35c0e1d9e5f3e439f3b987ce 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 dfc8373893b1876bb367700eac9d776316dabd96 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 23a83bac3356e7b211bcdcf581a31f7b536a2c24 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 026c236f0eefeebaae05c400ce102e6f05b2ec85 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 3bfb96d9bc6a7ed0b99c7db329cc2e22a28d84bb 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 6f9b23eb92a894ae1118893996943990ee0b860e 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 1b12612c367e4be9b0814c0468e7e687835315b4 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 b066420e57f3402a52c998678b4678252ac9bb63 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 1e71a40d101547380590db582213c1f1dce1f041 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 5c7e3755abf663f033de24f917b77685e9543045 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 60fddda7207d81fea71463abd403f0b10f74f2e1 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 420aabb32da4381d8d7cdcaa6a77fad9eaceb0a4 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 6a802de97a8bf8d5f1e4a048c67de9a8c2d2f9eb 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 4eef84b09a3836919360c4232b0f16651a155eec 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 b29b67c729de032112b2ac7b366a32d303ba5150 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 3d441be2b1c5e98167302fa1c7b61960a067b112 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 e702f6dd5d21e331f55fd9168c0210542008546d 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 a597a722fb71a534138c20359b655726622b5f17 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 4a4a1d41c6e901e773bcf795f562a47fa71f692a 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 b153cfe84b1340c69a13d0957665a2bfcf21239c 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 66f57dc92aeb60f65fabd6f5b407326fc4f9a703 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 a6185c21d5510cd0328a3149c0281e09dc2d8c10 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 91ac1d7fd51e3497630156d9a932f33a6d48dd3d 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 61a959b82f1aecd6d2d35c208013dd077cac9d10 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 4c65c3d9f660b5fd8d5ebde59e84ae42bf4ebe7a 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 dd395744e4ed87956fcbf81ecc6a20c51e35fa4e 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 d354e523c6f740db758cafcd4c11bb7913285ed8 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 793b55c3f36f56ab7897b3873460841372dc1004 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 232a2f2fce9b92b825cc2955a28f6e448d2d59ed 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 86652704a7fd41a5a8459027e08640bbd1952826 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 c9170c83b0e0fc2065a4c2bca5bf1f90c5880156 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 2265b2b1c5aaa276f584c1a6246bb8c5ea90025b 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 adc7dda728ca3e340a413e3bbc10cf159e1866a4 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 a0a56b4480a0dc921a42cd70e9fc081a12ab8359 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 f9a9abd7bbdab3dfe1b1155e1457dc02b5e14ea5 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 78b1074966d290d4517f42bc81e13c4349368d12 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 a9b89752c2726e88ea67994fb97a0316b24d30b7 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 1bb33d959aabcde07d724b5eb9992462e91fa79a 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 7838131e296dfbb639ea278901a53c018322c11e 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 8ab75e445c161c4cb504aa98e20ce1dd1ecd8e9a 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 1f38f65bf965fce9aa159d45c5347538f56c5973 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 08b2145470667962661ef131afcc8de5a62fdc32 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 abe3536a4bedcc43de80b6d4d7e3d57e9ba382a5 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 ce6aced2e85542a29f6d6cdf050286ddd0688185 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 158c5a0b1dfc0e6a419efe18404047a4d2dff59e 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 657449e5581a41e61933b6c4e0157c22cd24b7d6 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 2ffb70a8a01988046bb207b7d0af9358a8337378 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 8afb1a787a2802caf1895dd96745cfd6790a6f95 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 5492799ec5d27be3bd454dcaf046bc7054f637ae 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 0acbc09d2aca0432af45cec114f20d55ceafaec4 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 63d3f283858fae097fb09ddd4ce46bb0bc1f9d01 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 5ea289ca751c47125f6a4138c93ba10c05cd28f0 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 b5bc1e5d5ce57271df15c8663edc721479c17761 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 083a0ddc9cd49088ba0d9cb2f98524dfb1182dd8 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 6eb0d929202a3ebd3222e10699f813599b2f4ac1 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 aa24cec5b34700e498bb7b307217a365137f278a 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 8530206911fd66ad739ca5ce95f1d069f3d42204 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 a2038514e69371eb493083a6a897ed20fcbb8acb 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 374fd8122421f1729dcb5c68ab7c19fb8db3de57 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 fba8e250ce5f380037e10b988dfffe06ad983835 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 a203f2c3892b19f2061fa2af2f3166c5894a0f59 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 47120164c63d398eee897307352693cb95a54397 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 5a5ac2852cd326529d02f778bc1aa6184701f4d7 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 d020e7f27bf65eecd3805404702f716b2b6d9e73 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 6b1304ce6cff058e495a2bf3d6462eb948518ebc 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 a03387e1f6251d754475b011ffc605b4412ecb67 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 df9ffdceac053086f29f06b1f937824cb73f5584 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 124440df267dcdcc5bd4aac9888e2b3b80cf65fe 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 a8323fb2ab6cd6978f359daeed6688e0cadf32ba 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 4e8d498d32b6c67d73bb8b317ff316ff37897a3e 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 c5d75800539bca6f42b4d213dfe5158879b2fe81 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 f0069a262bd41fe4b7dfc21c018cadc605b97b66 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 62988204162fc382cfc7d9a185d40a751261e3a3 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 898cb5a7c4154478440b6886d387233df3597df0 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 e0881f5cc4d7130c5a70e96d37111f613ff06fc2 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 f148f86c65b8f9ef2466ad8506e721749e4957fb 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 3b51d6f07a19996703c5a2d770ac72fb7538ebe3 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 acbf1ecc22f3c33e9e3c33fae70696bf0eb7b928 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 a9d098b346db561ec3ab24d6b1adfc4aec4c728f 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 1497a438ea34a0bacb78c1ac8563c73d9ab02141 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 dd0b2976b7c0f4ea806855ed19ffad967d36610e 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 b4b3458ef88df4798632619f018791d4344bcd92 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 9b7d05cbaa60108642402100efa6aa288dd33023 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 ef940e042f32941aa035dac1cd96ee153e0a8c69 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 58ba00999898b1e42734d671e824cfda04c810c8 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 86d379fcf1b79bdf4bc2ac891297f30f63d041d8 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 0a7d9c7c5f1f208c523abbb4db6aea7bc1fad3db 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 d8a01d27873e04bebd357dc87859aa756e0b28b2 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 83df3e2594cd78aa40b1246a19879abb4891945b 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 898ca04b096b9e4640300eab91468c826a1ec92b 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 489291b6b56978cc50d34e8e13f9636ea296ba8a 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 36554592e2f5cac16ff8bf73720d38a6d9ef4a20 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 1797eb92f0b39ecb3348c873dcca2caa1e7cce4d 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 f14c3926fee38e5309749f0ba3c7ae28216afea3 Author: Srinivas Kandagatla Date: Fri Oct 31 12:07:02 2025 +0000 ASoC: codecs: lpass-va-macro: add SM6115 compatible [ Upstream commit 893e2fd509e968cc1d76caadee0f5d2f2c72f137 ] SM6115 does not have "macro" clock, so its bindings differ with existing SoC support in va-macro. So add dedicated compatible in both driver and dt-bindings to be able to address that difference. Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20251031120703.590201-6-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Stable-dep-of: 0773610eef71 ("ASoC: codecs: lpass-va-macro: Fix LPASS Codec Version for SC7280") Signed-off-by: Sasha Levin commit 3d3638fe921371e52be77baefe792c126fcdfc8c 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 4e9f4ca9dc73c2b2acba772ebadc54f644fd819a 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 bca3100f550281c2f2418652338bced3b35af0e6 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 ad6215d76b644fe4cde6271ba9805ca473d40f03 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 1681cc7974a6123f5d5740b03bc11e4784bd2542 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 b17751a2ebc4aef3ce6be6f71ee8df92bf5ddfcd 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 8dba7a94a269b88e500aafc25ad567ef6a423698 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 8d501b1411548442aaf1de3268654046f5bcf4c1 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 e94d53a9ac22cf43c7d6163c6cb8b0028c25aae1 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 f4af803269ccd192a6299f1c1658b831578d2b1a 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 46dee20d30b707225fe2afe9bc1e165a489bf92a 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 8e0b7f94fb394d80c061b1d99d54f58f4f931ef7 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 776f70bafd45c67b1fe63179808513c65e9a0699 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 d6cd34d17b951f7e1dc8b3fa4d00de7f4ecc3e6a 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 f28d7b5f1578a7501ab17b10643ed1e4f729187e 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 d990a01b853e5b816d5e344f5e6813b2b83614a2 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 2d149a20275ac16ea8c579fc251eef323f7c3e76 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 92d05883ef3376ca9f86533b59b7522e5a90162c 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 43a6c6fb6ec503c4a68d83ac7ca6513120120a73 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 de051b146022cbaf23b960d1fd771d93507c8f52 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 6727f580cf4622819fadaa94ed619065d0965253 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 9075efb9b2c1d9d7a8285c937b64aa93ca0c41b7 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 c1e7286d05318403bfb444cca85728009deed5a1 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 7a7c7263bbbc4653ad669301d823da7a686d1bd5 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 ed295077a2214e9a9331e3d1577127def37cfa0a 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 0a8a729481c8e240f00e3ff19402e1bc40b847d8 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 2f3c0895fb20ab0901d1e879e897aa7a4ce7cf5a 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 b15a3cc68e2450aa0edd94a74a7bdd45fcc17dd9 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 b84dd48f9da1eb132bdc06a944423cd5a1641ef1 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 e0ac054416bf4e913fe96cefefe94e3331bbe6fa 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 9dc3cf8a35906db733f1cb4f9a552aab86f65d54 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 0c11a1da41a647b6cfc00d415516053dd7f0aa62 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 a69ccea6d7eb63f3309da1086c4c0da97b56afd0 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 5fd1f0512748d35f86ce7efa95b24dbe12d95063 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 d0bfd7004a87f4d2436eb8ac9a7bede6eeab783e 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 5b6165d7ec38477e8cfa41bfa464959957953822 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 ea43e7a231aa264722aff20aa397003d754cc2b6 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 4e62be1490d23d7b37ea550e82f46e9d4ffa6bc2 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 123b559aa6bb6aa77be7b38611eff3f56adabdbf 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 419017dd2dda2cfa9485e350587e64206eee33e7 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 ae58dbf1d78d7d5d247b112286412470a63b3eb4 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 2bf70e0306f8d63740a4e39e551ab46779d66d61 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 b060606bc7e4614746dc93a245e06e923a027146 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 56c26538f0e585cd990eb476c24827fea98a8037 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 2140c2f3f2e7b066e1ae616ede8856cafd8015e9 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 ff127c0aa52799c16b4ad87a99d2b8f91986247b 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 a9e6707322ef215d39d4655b176c094f45f0ab52 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 410629528067029096dba7ad7bc49e4a5e92708d 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 7557df1b60f20430f9525fcb71da8b3f6bf70ba7 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 03b743586a2469744e96e9c1015096d07240935d 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 a0904f7d270358efdaa2e7dff465824d83800cd3 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 94defb18ac792fd16407d5a52ad0d3f5055c4b43 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 04117aea9bc11a08c594c68ce23ed259dbddb777 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 56ec2a08d27b5c6513bdca791416d014b2597106 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 d2a41c85beb56c5f1db39a805b238b3f47567fc5 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 60a6689b9a5df004fbc29148a2d8f6919190eae3 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 33e1875d6b5b552a2e5652b40074c604199354ee 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 d3e9a7e2ce9dc01fa8765966acfa84f37e06be1b 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 329f2626ee5cb8fafdf6b58b624311529c57cb45 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 a73e7ac3f3b69e9581ec7bfd889ff3e9b8c773f7 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 49fa1be621dde8f526d36e5791aded8fafda1e9c 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 4d919c9b770996365806b6c8d701912d52baa306 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 3db13f82ba3145a122a79cd3dc5a500bd666d5c5 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 828fad4fd418bcdb9f5d66fec0d184c52a85ec31 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 630ce3806b706411da05731f21700271398ec5dd 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 c0057e5f762b99129f7935b9e2fbb5fd3fd6b610 Author: Jakub Kicinski Date: Mon Feb 23 12:37:01 2026 -0800 eth: bnxt: rename ring_err_stats -> ring_drv_stats [ Upstream commit 6c32b07650676ab4c112ff8e9d345b6770ae2be5 ] We recently added GRO stats to bnxt, which are maintained by the driver. Having "err" in the name of the struct for ring stats no longer makes sense (as pointed out by Michael, see Link). Rename them to "drv" stats, as these are all maintained by the driver (even if partially based on info from descriptors). Michael suggested calling these misc, happy to go back to that. IMHO "drv" is a bit more meaningful that "misc". Pure rename using sed, no functional changes. Link: https://lore.kernel.org/CACKFLimgibJ0qkM1AacZVh8MKKy-pE_AAc4KPKZ7GUqebmXW9A@mail.gmail.com Reviewed-by: Michael Chan Link: https://patch.msgid.link/20260223203702.4137801-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: 40529e58629b ("eth: bnxt: improve the timing of stats") Signed-off-by: Sasha Levin commit 33168db149d01be889edca8b1718e171b3ca628e Author: Jakub Kicinski Date: Fri Feb 6 16:35:01 2026 -0800 eth: bnxt: gather and report HW-GRO stats [ Upstream commit a7fc1a488f09f0fbf727fe3ca5b017e7657f152d ] Count and report HW-GRO stats as seen by the kernel. The device stats for GRO seem to not reflect the reality, perhaps they count sessions which did not actually result in any aggregation. Also they count wire packets, so we have to count super-frames, anyway. Reviewed-by: Michael Chan Link: https://patch.msgid.link/20260207003509.3927744-2-kuba@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: 40529e58629b ("eth: bnxt: improve the timing of stats") Signed-off-by: Sasha Levin commit b0d0eb13a0441a8ebf4f227843deaf494f1e2c33 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 77bb0bbfcc4e777ca653174689e5e363f8ee63d1 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 1f6a4aec0d36647eb2f67cd69db22bd28cabe2cb 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 68115a7a336fc9d1e60058a3565da071a4c91d19 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 de80d04b13deca47a1f05e0bee6488cffe0674b5 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 eaffdd113f560b2c41e1860c94223003d754e945 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 854065a75e375e570495df40e2fe9e94115250e4 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 4cc632fe63df8b1f849573758700ed80b9cb7d3b 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 04c082b7dc5bf4c6e239ba4ed00e6eb4819cde76 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 dd6d8e4412f805937f61f00bbfdfe831978be235 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 9415a94cf62273b98a04635cedee5e7be2e2dd54 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 e1e7c72a2301d6f74ec981fc459fbe5cd495a64c 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 9cc0f8e63e8c34cf43def35cbd305ba711181a1f 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 5e4c4ab99abc906fd2c73e284df547e2adea236b 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 7550becf33014f851afa25c5393a41ab13a60ab2 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 9697db03e010391c55ae75192cbdf30c5a72c114 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 3bdfa0e435f3198494bdb0f3f87c2fe7fc955191 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 b05337635be3cac6f7c26fb56773d24e86ee0084 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 68b41e68a62299f26cb16af422b5c7d1c69dafd9 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 aa33b44f70bfec8d431005c42706104a25062e16 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 56e5f8a409f8c62584f96658f74a5a95043d6555 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 93f95538b611a9f69d9f0fffc2f3cc51cd91dedd 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 ea24f911ead85ba3d570a31e37c52b6c949f6928 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 a6450f7cfae57b382cbaf66a577765c9a88b3c58 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 2066e692ec7a10af63d9c75899c9a66946cfede9 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 1d51aff78f078af1a80e9496c2f4643f4c0ef0a0 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 a103cdb0681e7185d1b0a12ce6a7c5416c208ccd 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 2855ec137a22404ef3fae9c2b9cfb9cfcd5b3cef 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 da603b606ceb35d29dc88ea1e1e201a5820a06e0 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 5636f0f3bd99b4e89527b721ff50db0df36431f3 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 ceef83f0eaf9c7115cb00aeb71295b369b0deefe 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 a0c5fdeb5fa257f8c6d469af266bc087cb5de6a2 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 5dda4f164a633cfd55d445ca5a3d2664bd41abf0 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 9200c8149910d97887d83355886ceb1af0c4f21b 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 55fc2f99d09798b4c427ca480e55840289c1bf9a 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 c8add1d06512bfd2c5953300d931028aaaa79890 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 0caa28e9789411d831aa00e32c56252f7003669e 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 471b62966c782d407a8f6c50d630c35272db9b28 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 9dbfd514148dd1d256cc546f91ef58425031a509 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 a8673dbd3d4a0303562130e3f6842a23a7b63ea0 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 31b28910abe347bf68c6eaa3bb1b20b701071005 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 fff7d3ea3a4c4483940ce2fc91041308d4dff179 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 8c65c58868ecc580610ef6a852b45cda5e3eae25 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 58cd8ff69e33c0994c6f23dc172c106332ba01cc 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 b805de2abfa346ca6653bbe58629b95be259e4f6 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 37e3e8a2c3bfdd503209f043f8bbfbdcf5a1d92f 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 502b3ae43f7988e07750eb3f8da295403fba3472 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 002ebbcc8414c6c0339caf3adb8748cf4bfba52c 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 7e23965d44f06ed93fb5362fb1e321b769eecc3b 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 d32e4301a0e5ee897a82e9b3daebb4d4e303c660 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 8e935c51b65d968a022ceced3ddbdd7fda08553e 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 4c61d28634fbf09f0f497ff4545dda9d9c59b6be Author: Pablo Neira Ayuso Date: Fri Oct 10 12:32:23 2025 +0200 netfilter: flowtable: move path discovery infrastructure to its own file [ Upstream commit 93d7a7ed07342f5e3da2d250cfd67f899d0b5318 ] This file contains the path discovery that is run from the forward chain for the packet offloading the flow into the flowtable. This consists of a series of calls to dev_fill_forward_path() for each device stack. More topologies may be supported in the future, so move this code to its own file to separate it from the nftables flow_offload expression. Signed-off-by: Pablo Neira Ayuso Stable-dep-of: e409c23c2d06 ("netfilter: nft_flow_offload: zero device address for non-ether case") Signed-off-by: Sasha Levin commit 13c6ba6e0f216018add9709603ec2f6309502bb6 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 5baa149abb41a5129e2932a562dcd5c90b9aa189 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 12088da6add5b003657c8506c5b0fcef835083b8 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 8087bb360a936a6314d22b567e4b861656943eb6 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 c4d257734e91bfcdc71d41843392dd6400b5bb1b 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 a0afd353c2f7e74c8d3632c00a2e85c02a9cafe7 Author: Jozsef Kadlecsik Date: Thu May 14 10:55:13 2026 +0200 netfilter: ipset: annotate "pos" for concurrent readers/writers [ Upstream commit 7f7445840b7771338618930e45ee641104b38ed8 ] The "pos" structure member of struct hbucket stores the first free slot in the hash bucket of a hash type of set and there are concurrent readers/writers. Annotate accesses properly. Fixes: 18f84d41d34f ("netfilter: ipset: Introduce RCU locking in hash:* types") Signed-off-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Stable-dep-of: e4b4984e28c1 ("netfilter: ipset: Don't use test_bit() in lockless RCU readers in hash types") Signed-off-by: Sasha Levin commit 7228cc8ff6265332406a2353d5286dc9765caac0 Author: Jozsef Kadlecsik Date: Fri May 8 22:58:58 2026 +0200 netfilter: ipset: Fix data race between add and dump in all hash types [ Upstream commit 2358f7427ccd6ec8867a48205d8fcec973683a3f ] When adding a new entry to the next position in the existing hash bucket, the position index was incremented too early and parallel dump could read it before the entry was populated with the value. Move the setting of the position index after populating the entry. v2: Position counting fixed, noticed by Florian Westphal. Fixes: 18f84d41d34f ("netfilter: ipset: Introduce RCU locking in hash:* types") Reported-by: syzbot+786c889f046e8b003ca6@syzkaller.appspotmail.com Reported-by: syzbot+1da17e4b41d795df059e@syzkaller.appspotmail.com Reported-by: syzbot+421c5f3ff8e9493084d9@syzkaller.appspotmail.com Signed-off-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Stable-dep-of: e4b4984e28c1 ("netfilter: ipset: Don't use test_bit() in lockless RCU readers in hash types") Signed-off-by: Sasha Levin commit 6d92dbd73d19a0622f60352ce9d9379f7a760112 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 2c5384c40a4ceba5446fdabadca10bc25c53c6ec 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 119903c3208304aba590ddcfb7cbc87fe0a321c0 Author: Yu Kuai Date: Thu Jan 15 01:12:32 2026 +0800 md: merge mddev serialize_policy into mddev_flags [ Upstream commit 10787568cc1f3f80afc510b2728751989dfa0ae6 ] There is not need to use a separate field in struct mddev, there are no functional changes. Link: https://lore.kernel.org/linux-raid/20260114171241.3043364-5-yukuai@fnnas.com Signed-off-by: Yu Kuai Reviewed-by: Li Nan Stable-dep-of: a286cb88ddb2 ("md/raid1: honor REQ_NOWAIT when waiting for behind writes") Signed-off-by: Sasha Levin commit 2e414af05a7cf154aa42946006b748886f6e1eee Author: Yu Kuai Date: Thu Jan 15 01:12:31 2026 +0800 md: merge mddev faillast_dev into mddev_flags [ Upstream commit 4f6d2e648cbe963b328cb8815290676da3866434 ] There is not need to use a separate field in struct mddev, there are no functional changes. Link: https://lore.kernel.org/linux-raid/20260114171241.3043364-4-yukuai@fnnas.com Signed-off-by: Yu Kuai Reviewed-by: Li Nan Stable-dep-of: a286cb88ddb2 ("md/raid1: honor REQ_NOWAIT when waiting for behind writes") Signed-off-by: Sasha Levin commit 9408c233a5bbeebb4aca9a3b9528d3fbab48edcf Author: Yu Kuai Date: Thu Jan 15 01:12:30 2026 +0800 md: merge mddev has_superblock into mddev_flags [ Upstream commit fba4a980403d2f489bc680dbff7d7d2514e669f9 ] There is not need to use a separate field in struct mddev, there are no functional changes. Link: https://lore.kernel.org/linux-raid/20260114171241.3043364-3-yukuai@fnnas.com Signed-off-by: Yu Kuai Reviewed-by: Li Nan Stable-dep-of: a286cb88ddb2 ("md/raid1: honor REQ_NOWAIT when waiting for behind writes") Signed-off-by: Sasha Levin commit 5464ee6442376a2790953ece3f0c7d2ae9824fb3 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 de3bd9809af7555611334cb6a071806744430ef7 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 d22e278cd067968d79e4ebe543dd87dd7e7b61ac 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 f4860dd988b1041d70595f2ed84de80f90cb7ebc 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 5d17ebdf6c2368a362428799feb1e4032545a037 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 3b40ebc19ad023d3d1ed8136d05969c4e6a427c0 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 45465b0e013541d5891395539fc6d3f144c5e234 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 7ae67f0e1c16b551a916cf6d6636ba6a32f49884 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 679fd0bf4f8ab18a290ce60ccbf1a643df41c471 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 4c16176fc11a61b7545464cb47c98b0c8a055fcb 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 a762b9865f494aa2dcee1393a7edded6c6099a05 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 c6d3bcb0f934d4297ac5fa1c8656ae40694fb601 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 68af74ad696cedad71f5e7dce70de658cd2b1232 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 112b5eff24e044561ee9599a0d34e0fcea1df4e0 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 5ffb2b4987cc909eb6c9e6a9487c25d5a919d99e 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 02c884d9aaca33ad25d517660b021e00f0df0b48 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 0dafdaaf8684bfb6c74d6580eaa8f5636382d33c 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 c7fc9adf4e006155f7f2aeda052fbcde25cdcc49 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 0d95587d662a5535e163d7eeb3bf4c02ad6cc4fb 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 f37f2f804796e1026d838af39aa8e8ec3d9a49ca 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 53c23d56b46b1ae51574d92110895086aead7ad7 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 25a867aa5e67a84333fa6e5c21292c5bcff86b90 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 207bb4ce8fe7de961ae7bb33569ad2cd61f44954 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 a6cfb924ad74efce254e99c197d2e3863de70868 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 3d45d40b872aec0073d4cf08956a6c9b87c5e396 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 290ad0a548915bc2f457e6d315e1537f00e16497 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 96ac562a9ea3020981f536384711190841c81aa8 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 211bb9d8f17c4136e72843bb00f9ed6fb12618b8 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 0e27d92f69b8e4c750a4b181cc05a86b9338c4f5 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 7bcd4ef375fa369407fc6c433084ad66d4492102 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 ca297485271c62cae7e87bf64b9ca41207b314f4 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 05b11debdffe03f2c4097b577d2a36c477bc7b0a 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 c8cb4a92eda6eff46a1b89e609d34709fe3d7e75 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 b389a5b215e35e5c4a006c7232a865657bd928cd 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 c13532ff67faed29340f4bd6d7a8c6bc219c02f8 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 87d23f25b5e97ec922ed77a7a79555337b4a1737 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 6d99379c58f7f1c6ab2cc7aba01a4f52d71adcfe 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 7248ae02a9453342dbc7d5237c25b28dce4af96d 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 a1a3360a0c44b8b5c134db2a9d0667b61c9cf523 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 1467ca02ddac401ac2013e9dc55be867b570422c 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 507a7b07f3fa3ba55e1274b6b28c7bd5f2a416a5 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 34cd92141a0243aac457baad2c2c164ce5441aea 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 95028569589f49fd7ea82fbd95be91343717ee1c 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 355e51eeffc6b19c6d54d5c2c3b52283d5f490f1 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 2024940522ef451098c940ab0b82d647de5e5d9b 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 1348bf64c1978aa329c333995de46f92d2895ba8 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 7d3532a0b11a242c14f8446f0e13f5c5b4f877b9 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 a56f29ad8aacf8dfa05716e11cc3dfb3126b7721 Author: Leo Yan Date: Fri Jan 23 13:32:04 2026 +0000 perf: Remove redundant kernel.h include [ Upstream commit 7a0ba3891104da77cfd1a16d41699e0fdf45603a ] Now that the bitfield dependency is resolved, the explicit inclusion of kernel.h is no longer needed. Remove the redundant include. Signed-off-by: Leo Yan Cc: Ian Rogers Cc: James Clark Cc: Namhyung Kim Signed-off-by: Arnaldo Carvalho de Melo Stable-dep-of: 542e88a4c6f7 ("perf cs-etm: Reject CPU IDs that would overflow signed comparison") Signed-off-by: Sasha Levin commit f8898d2eb71ae8e6f51bdd24a92cdffcc6a1c8f8 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 cafd80d81f08befd4b6a5fd949dded598f0ab303 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 1935d213aeb235fca1f8931967724ab24e10716a 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 aea30b437ebd02b9f1ba195581d46a8ed1c0049d 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 bc27041e8971e01fe8caa31d0e994931f3c9da3b 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 661f60a8a5cf8155181d99ca3ad88961a541653b 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 5d080b7324f0753736c95c1eb538a1f6b8fe6e58 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 debfcd673a6d14e71e82b6390b13cd8331416506 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 95bf4dbcd5022ffd924f570f63f357f9ec968852 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 Stable-dep-of: f973e52a9977 ("perf dso: Fix heap overflow in dso__get_filename() on decompressed path") Signed-off-by: Sasha Levin commit fa870f951793d9135ebf9c79da95b6b27fde4c00 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 Stable-dep-of: f973e52a9977 ("perf dso: Fix heap overflow in dso__get_filename() on decompressed path") Signed-off-by: Sasha Levin commit 3ae7947101b977f9fb0b8aece1c5cdd8c0f75360 Author: James Clark Date: Mon Nov 24 10:59:08 2025 +0000 perf tools: Don't read build-ids from non-regular files [ Upstream commit 834ebb5678d75d844f5d4f44ede78724d8c96630 ] Simplify the build ID reading code by removing the non-blocking option. Having to pass the correct option to this function was fragile and a mistake would result in a hang, see the linked fix. Furthermore, compressed files are always opened blocking anyway, ignoring the non-blocking option. We also don't expect to read build IDs from non-regular files. The only hits to this function that are non-regular are devices that won't be elf files with build IDs, for example "/dev/dri/renderD129". Now instead of opening these as non-blocking and failing to read, we skip them. Even if something like a pipe or character device did have a build ID, I don't think it would have worked because you need to call read() in a loop, check for -EAGAIN and handle timeouts to make non-blocking reads work. Link: https://lore.kernel.org/linux-perf-users/20251022-james-perf-fix-dso-block-v1-1-c4faab150546@linaro.org/ Signed-off-by: James Clark Signed-off-by: Namhyung Kim Stable-dep-of: f973e52a9977 ("perf dso: Fix heap overflow in dso__get_filename() on decompressed path") Signed-off-by: Sasha Levin commit 2c19e40753ec1f915ce58f56b7347d30b6562567 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 137eabe3c18ff5e12453e98c7b0fd0246288bfa2 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 ca3393e258f632b92f4f81903a965af1788562e7 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 f231387f3d2bbce38b99d49c54ec6a8128d0081b 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 17955f1995bf9985c5b27901730a270239e38344 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 85873b1bd3664af5cba608a014cd2df930d77f3e 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 38d3d33bf42c250053c4a06fc1b3a714f3ad0a74 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 c4f2afcdc547058806ecf3d3b0d9dca58026cad1 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 3891c061341fb73b3dd562392e7fb022596f29e7 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 57490b302b984e6c2b6dcc16e2d2af6f52a973ee 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 0bd450d40f8745b8ac1015b2dccfa6a6cc5eb41a Author: Jorge Marques Date: Mon Mar 23 17:11:29 2026 +0100 i3c: master: Move rstdaa error suppression [ Upstream commit 19a1b61fa623748f37f467e7813c58a2a792b90c ] Prepare to fix improper Mx positive error propagation in later commits by handling Mx error codes where the i3c_ccc_cmd command is allocated. Two of the four i3c_master_rstdaa_locked() are error paths that already suppressed the return value, the remaining two are changed to handle the I3C_ERROR_M2 Mx error code inside i3c_master_rstdaa_locked(), checking cmd->err directly. Reviewed-by: Frank Li Reviewed-by: Adrian Hunter Signed-off-by: Jorge Marques Link: https://patch.msgid.link/20260323-ad4062-positive-error-fix-v3-1-30bdc68004be@analog.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 fd32e8d4a2933143b7bcf5d13f5bc49fc01afbbc Author: Adrian Hunter Date: Fri Jan 23 08:33:23 2026 +0200 i3c: master: Add i3c_master_do_daa_ext() for post-hibernation address recovery [ Upstream commit c481ef12e713fb7c292d04f53b3532ac0804ab3d ] After system hibernation, I3C Dynamic Addresses may be reassigned at boot and no longer match the values recorded before suspend. Introduce i3c_master_do_daa_ext() to handle this situation. The restore procedure is straightforward: issue a Reset Dynamic Address Assignment (RSTDAA), then run the standard DAA sequence. The existing DAA logic already supports detecting and updating devices whose dynamic addresses differ from previously known values. Refactor the DAA path by introducing a shared helper used by both the normal i3c_master_do_daa() path and the new extended restore function, and correct the kernel-doc in the process. Export i3c_master_do_daa_ext() so that master drivers can invoke it from their PM restore callbacks. Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260123063325.8210-2-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 b07a318afca1624fabe1713cec74a1bab7e45bd1 Author: Adrian Hunter Date: Tue Jan 13 09:27:00 2026 +0200 i3c: master: Introduce optional Runtime PM support [ Upstream commit 990c149c61ee45da4fb6372e6b2fdd9808414e7a ] Master drivers currently manage Runtime PM individually, but all require runtime resume for bus operations. This can be centralized in common code. Add optional Runtime PM support to ensure the parent device is runtime resumed before bus operations and auto-suspended afterward. Notably, do not call ->bus_cleanup() if runtime resume fails. Master drivers that opt-in to core runtime PM support must take that into account. Also provide an option to allow IBIs and hot-joins while runtime suspended. Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260113072702.16268-20-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 882ee831366a15a7c4c9e1df6925011fb3a3d36c Author: Adrian Hunter Date: Tue Jan 13 09:26:45 2026 +0200 i3c: master: Replace WARN_ON() with dev_err() in i3c_dev_free_ibi_locked() [ Upstream commit 471895799c2f46688792e175ced936ffeb6cdf01 ] IBI disable failures are not indicative of a software bug, so using WARN_ON() is not appropriate. Replace these warnings with dev_err(). Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260113072702.16268-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 de2106d99b87aaf47542fd5f140929fefb00248d Author: Adrian Ng Ho Yin Date: Fri Dec 12 17:02:55 2025 +0800 i3c: add sysfs entry and attribute for Device NACK Retry count [ Upstream commit b58f47eb392680d4c6626c8b3b1fcf6412a0a02c ] Document sysfs attribute dev_nack_retry_cnt that controls the number of automatic retries performed by the I3C controller when a target device returns a NACK Add a `dev_nack_retry_count` sysfs attribute to allow reading and updating the device NACK retry count. A new `dev_nack_retry_count` field and an optional `set_dev_nack_retry()` callback are added to i3c_master_controller. The attribute is created only when the callback is implemented. Updates are applied under the I3C bus maintenance lock to ensure safe hardware reconfiguration. Signed-off-by: Adrian Ng Ho Yin Reviewed-by: Frank Li Link: https://patch.msgid.link/3c4b5082bde64024fc383c44bebeef89ad3c7ed3.1765529948.git.adrianhoyin.ng@altera.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 0d66830f302fd05f2d4e16a5a9e90b08c6f87a4d 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 eb9db96a5deb324c39f3652eee8703712b646b6d Author: Marco Crivellari Date: Fri Nov 7 14:29:49 2025 +0100 i3c: master: add WQ_PERCPU to alloc_workqueue users [ Upstream commit de53ad6ca49e5d73bba72d24b49ec5d40f33ee01 ] Currently if a user enqueues a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. alloc_workqueue() treats all queues as per-CPU by default, while unbound workqueues must opt-in via WQ_UNBOUND. This default is suboptimal: most workloads benefit from unbound queues, allowing the scheduler to place worker threads where they’re needed and reducing noise when CPUs are isolated. 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") This change adds a new WQ_PERCPU flag to explicitly request alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified. 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. Once migration is complete, WQ_UNBOUND can be removed and unbound will become the implicit default. Suggested-by: Tejun Heo Signed-off-by: Marco Crivellari Link: https://patch.msgid.link/20251107132949.184944-1-marco.crivellari@suse.com Signed-off-by: Alexandre Belloni Stable-dep-of: 527756cb9ebb ("i3c: master: Make hot-join workqueue freezable to block hot-join during suspend") Signed-off-by: Sasha Levin commit 45bbc1e1fe626e5c1ae0c20788c8b8759527bb62 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 d22ab94261c7b1214675ab6fa3d9300866d55bdd Author: Adrian Hunter Date: Tue Jan 13 09:26:47 2026 +0200 i3c: mipi-i3c-hci: Switch PIO data allocation to devm_kzalloc() [ Upstream commit 11d17c2855bfc04550557017eae02e92f3eeab1c ] The driver already uses managed resources, so convert the PIO data structure allocation to devm_zalloc(). Remove the manual kfree(). Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260113072702.16268-7-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Stable-dep-of: 093eb8e73c90 ("i3c: mipi-i3c-hci: Preserve RUN bit when aborting DMA ring") Signed-off-by: Sasha Levin commit 973fda38b124c35a7982c09d986be3fe969a4de2 Author: Adrian Hunter Date: Tue Jan 6 18:44:12 2026 +0200 i3c: mipi-i3c-hci: Allow for Multi-Bus Instances [ Upstream commit b8460480f62e16751876a1f367dc14fb62867463 ] Add support for MIPI I3C Host Controllers with the Multi-Bus Instance capability. These controllers can host multiple I3C buses (up to 15) within a single hardware function (e.g., PCIe B/D/F), providing one indepedent HCI register set and corresponding I3C bus controller logic per bus. A separate platform device will represent each instance, but it is necessary to allow for shared resources. Multi-bus instances share the same MMIO address space, but the ranges are not guaranteed to be contiguous. To avoid overlapping mappings, pass base_regs from the parent mapping to child devices. Allow the IRQ to be shared among instances. Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260106164416.67074-8-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Stable-dep-of: 093eb8e73c90 ("i3c: mipi-i3c-hci: Preserve RUN bit when aborting DMA ring") Signed-off-by: Sasha Levin commit 5625b8767ce3e521f4d716d6d6f19224de8127ad Author: Adrian Hunter Date: Tue Jan 6 18:44:08 2026 +0200 i3c: mipi-i3c-hci: Quieten initialization messages [ Upstream commit 581d5b7953b8f24d2f379c8c56ceaa7d163488ce ] The copious initialization messages are at most useful only for debugging. Change them from dev_info() or dev_notice() to dev_dbg(). Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260106164416.67074-4-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Stable-dep-of: 093eb8e73c90 ("i3c: mipi-i3c-hci: Preserve RUN bit when aborting DMA ring") Signed-off-by: Sasha Levin commit 2791dd42d41e38805572b12116f721c97c4fcc0c 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 fdf610a9a9e72e9f63a6ac7c9ea1d8e5a6002b57 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 b58d240883dfef8734a9d36fa333b049e2766ac0 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 66a6c61369d4120d6d988ec0eb07d0340f6a5acb 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 22dc9433d458cff1270f120685114a9753e0ad1b 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 3b918f6f5239087cf9f9224c356a1eb37dfcf46d 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 566d1ef98a7115026ef3c96c9d71c390aca29def 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 fbfdb5a94a48797bea232791e24c38f3aa3063c8 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 57b1bd4486d56254bb8af1a8f3d4445bbe505290 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 b427061ca498309bf581bb6f8df4ffcfe4c772cd 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 9111f76e8dc8cfe76908969f3fbec5a006f6b34d 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 ae02e603c0b39b29f3ce6fe3efe01b286af1a2a4 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 d82160132345688a09cbaa648cfdd16bb32e8ea2 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 ad965f36d2986741e5077efc83909f110970db8e 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 045dbe89ac31709abd73390d0805d52fece7ef39 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 d8ea44f6090c087fe255d9512fb808574b4d88e8 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 ef488d7429d23d131eec3d2c1e6f8292d37e92b7 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 f79519f636059b007d6abc91652f36dea4f54a20 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 514b84b1bf30f75f32c2fa66734dc1a177abb73e 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 11016555d7510a384c884d505ed20e3180beb7d9 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 872f9a63a108e2ccb94dac1209ce96dcc411f531 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 f77c490c45d46e125e9452bdf3376f8a7f6c8e00 Author: Ryder Lee Date: Mon Mar 2 17:46:48 2026 -0800 PCI: mediatek: Fix possible truncation in mtk_pcie_parse_port() [ Upstream commit ab4a4043db1fcc4fd4c5745c5be8caf053502e29 ] As reported by the W=1 warning below, content of the 'name' variable might get truncated with the existing size of 10 bytes. Though it is not practically possible to exceed the 10 bytes size, increase it to 20 to silence the warning for a clean W=1 build: $ make W=1 drivers/pci/controller/pcie-mediatek.o CALL scripts/checksyscalls.sh DESCEND objtool INSTALL libsubcmd_headers CC drivers/pci/controller/pcie-mediatek.o drivers/pci/controller/pcie-mediatek.c: In function ‘mtk_pcie_parse_port’: drivers/pci/controller/pcie-mediatek.c:963:43: error: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 6 [-Werror=format-truncation=] 963 | snprintf(name, sizeof(name), "port%d", slot); | ^~ drivers/pci/controller/pcie-mediatek.c:963:38: note: directive argument in the range [0, 2147483647] 963 | snprintf(name, sizeof(name), "port%d", slot); | ^~~~~~~~ drivers/pci/controller/pcie-mediatek.c:963:9: note: ‘snprintf’ output between 6 and 15 bytes into a destination of size 10 963 | snprintf(name, sizeof(name), "port%d", slot); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Ryder Lee [mani: commit log] Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/b835e360b42c5e0994f9301a34dbdf140a8d3ef5.1772493898.git.ryder.lee@mediatek.com Stable-dep-of: ebc1d9906894 ("PCI: mediatek: Use actual physical address instead of virt_to_phys()") Signed-off-by: Sasha Levin commit 9ca0a78a5d56133fe139eac216da941818c5628e 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 f1f5f8d334e914f93cef371236cc7b1131e73aab 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 cc6cd3fe8b8b1b9ae58790e85d9f94579506d53f 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 a3e758e7412287bcbeeaf7d247f0e3b716ba9d9a 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 f593775fecf5a2e0ac747a586a5fe8242c14e764 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 bafb6bfb346feefd84a8d55bbbfc88ed37aecaf1 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 fe4d8ad2e96f409c7492ee688c397cb885d40fe7 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 b0385203a09f0dd86415d8777b72d717ae0dc19b 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 41b3a92310450474821c8ea67e3916f317b22654 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 fbaf9bdfc0917c25c2d06426ba88692369c4a37a 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 d34b42ee0c74d11e82aadc4b28608f8b359a5cea 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 bc2fc12ce6e4d7166fcab575be0e9e6e1e3694c9 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 f830bb8d221f3ad4d7b22baa2645d42975d83526 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 76dfa13a0acb12146ebf3260449484a5ebc9b23a 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 56b17c84394f1213d05ece38657bb4dc6d5ad47c 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 f2e5262589d9487c8f8433c83d98609687e581b2 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 45e7900e1555c7d9e2d9efc4cd57f22f797f9261 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 4f883ab5bc7b77256af2762398761cb573463f37 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 490473192ac2f71a5d44086142c9f328e8fe3f2a 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 09962b811ef140dd9c57d86186139878988ad2f1 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 a6eec54329b432d6e537be3356b45227c42e1db5 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 e274dfa05904f21de2333faed1de805a031599d9 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 fa9eb50ddfea3871d5c9ee240d3d4d86bb89ee0e 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 b5a0a4a564d21c3b905d2c341e9bdc5409094d2d 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 007b4da2f38dcc16a13265416f4ca9f179bab610 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 469b22376ee73369711ecf2761bd122ef4195963 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 d7a2870dde3bb09d51d6b9c877642996ad6b92dd 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 345652531400f2407a4010538092a0be6e3bd88f 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 47b3dc59e09e9a70fa8f5777ea506dcf0fd64c0c 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 7471e66373a4444a57ef2192f8c4081202c54f45 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 28743571c17b58c21a7216fc9faaf8028df5869b 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 d0479c2b12974aa188b10d221a5770126b118b6d 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 6d52921f47020cf79496358f24b55b1e2a7c3e74 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 56ad33189ed5f7c1c4121bf6e9611b6f394bfdff 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 c32fe40b0c745983191e5b89110ea8c062db7d79 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 77051ef66e4ad282c373384707d94f287fa1ed32 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 2e0dd50e5a4dabe8079632f18004691126c09183 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 b9e8406651dcc1c19238aad11861a758683525b4 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 504028f561b19e9c3121ab24e4bce5ea9db20802 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 2a8244988316a4e1a2e0ad5a2d65295add2ae09d 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 3f4476a089a6d217e2687e0a8faa4d83abffb9cd 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 d6565e08166c8bea4029f2eaddd8f7e58f71fd06 Author: David E. Box Date: Thu Mar 12 18:51:44 2026 -0700 platform/x86/intel/vsec: Return real error codes from registration path [ Upstream commit a6ce8bf3c993d8c2e8a6aeb2596429c101fe4462 ] Stop collapsing registration results into booleans. Make intel_vsec_walk_header() return int and propagate the first non-zero error from intel_vsec_register_device(). intel_vsec_register() now returns that error directly and 0 on success. This preserves success behavior while surfacing meaningful errors instead of hiding them behind a bool/-ENODEV, which makes debugging and probe ordering issues clearer. Reviewed-by: Ilpo Järvinen Signed-off-by: David E. Box Link: https://patch.msgid.link/20260313015202.3660072-6-david.e.box@linux.intel.com Signed-off-by: Ilpo Järvinen Stable-dep-of: 375bbbbd112a ("platform/x86/intel/vsec: Restore BAR fallback for header walk") Signed-off-by: Sasha Levin commit 4df30a4dc0e975e6ec1aa9bfd5d42aa8d7273138 Author: David E. Box Date: Thu Mar 12 18:51:43 2026 -0700 platform/x86/intel/vsec: Switch exported helpers from pci_dev to device [ Upstream commit 353042d54d82f6c46449f0ee38c244b5a13c1fe4 ] Preparatory refactor for ACPI-enumerated PMT endpoints. Several exported PMT/VSEC interfaces and structs carried struct pci_dev * even though callers only need a generic struct device. Move those to struct device * so the same APIs work for PCI and ACPI parents. Acked-by: Rodrigo Vivi Signed-off-by: David E. Box Link: https://patch.msgid.link/20260313015202.3660072-5-david.e.box@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Stable-dep-of: 375bbbbd112a ("platform/x86/intel/vsec: Restore BAR fallback for header walk") Signed-off-by: Sasha Levin commit 817ab332d37ceecafb4ca67437ec11817422acd4 Author: David E. Box Date: Thu Mar 12 18:51:42 2026 -0700 platform/x86/intel/vsec: Decouple add/link helpers from PCI [ Upstream commit c62fd96a04e4a7b847448f97ecfe9f3fe706e7b3 ] This refactor prepares for adding ACPI-enumerated PMT endpoints. While intel_vsec is bound to PCI today, some helpers are used by code that will also register PMT endpoints from non-PCI (ACPI) paths. Clean up PCI-specific plumbing where it isn’t strictly required and rely on generic struct device where possible. Signed-off-by: David E. Box Reviewed-by: Ilpo Järvinen Reviewed-by: Michael J. Ruhl Link: https://patch.msgid.link/20260313015202.3660072-4-david.e.box@linux.intel.com Signed-off-by: Ilpo Järvinen Stable-dep-of: 375bbbbd112a ("platform/x86/intel/vsec: Restore BAR fallback for header walk") Signed-off-by: Sasha Levin commit e6523bcafeb61b61d2ffd993a5edc19e7bdaa147 Author: Randy Dunlap Date: Mon Dec 15 22:38:00 2025 -0800 platform/x86/intel/vsec: correct kernel-doc comments [ Upstream commit 20e20b147cf7cb6780a5b95da2a0e37c52cd1015 ] Fix kernel-doc warnings in intel_vsec.h to eliminate all kernel-doc warnings: Warning: include/linux/intel_vsec.h:92 struct member 'read_telem' not described in 'pmt_callbacks' Warning: include/linux/intel_vsec.h:146 expecting prototype for struct intel_sec_device. Prototype was for struct intel_vsec_device instead Warning: include/linux/intel_vsec.h:146 struct member 'priv_data_size' not described in 'intel_vsec_device' In struct pmt_callbacks, correct the kernel-doc for @read_telem. kernel-doc doesn't support documenting callback function parameters, so drop the '@' signs on those and use "* *" to make them somewhat readable in the produced documentation output. Signed-off-by: Randy Dunlap Link: https://patch.msgid.link/20251216063801.2896495-1-rdunlap@infradead.org Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Stable-dep-of: 375bbbbd112a ("platform/x86/intel/vsec: Restore BAR fallback for header walk") Signed-off-by: Sasha Levin commit c0d97519c9dfb25d43b68e720decc5f672f57b4f Author: Xi Pardee Date: Tue Oct 14 14:45:33 2025 -0700 platform/x86:intel/pmc: Relocate lpm_req_guid to pmc_reg_map [ Upstream commit c2bc11f1f204ef916ec96e45cf329e42873b37d6 ] Relocate the lpm_req_guid field from pmc_info to pmc_reg_map. The previous implementation stored lpm_req_guid in pmc_info and relied on pmc_core_find_guid() to retrieve the correct GUID, which was unnecessary. Since lpm_req_guid is specific to PMC, pmc_reg_map is a more appropriate location for this information. Signed-off-by: Xi Pardee Link: https://patch.msgid.link/20251014214548.629023-6-xi.pardee@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Stable-dep-of: 375bbbbd112a ("platform/x86/intel/vsec: Restore BAR fallback for header walk") Signed-off-by: Sasha Levin commit b95e1facc5b7f11a3f1362386cb696ac7043a06f Author: Xi Pardee Date: Tue Oct 14 14:45:32 2025 -0700 platform/x86:intel/pmc: Rename PMC index variable to pmc_idx [ Upstream commit 7848154c3a11fb3ffbffd150f2185f97b5a6595a ] Rename all PMC index variables to pmc_idx in core.c. This improves code readability and consistency. Signed-off-by: Xi Pardee Link: https://patch.msgid.link/20251014214548.629023-5-xi.pardee@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Stable-dep-of: 375bbbbd112a ("platform/x86/intel/vsec: Restore BAR fallback for header walk") Signed-off-by: Sasha Levin commit 3e86797c0699d9b4312e5df491699983352d74a5 Author: Xi Pardee Date: Tue Oct 14 14:45:30 2025 -0700 platform/x86:intel/pmc: Add support for multiple DMU GUIDs [ Upstream commit 3b603955f2423cf668ebd5ba670019a5b4960cc5 ] Enable support for multiple DMU GUIDs to accommodate Arrow Lake H/U platforms. Arrow Lake U/H may have several GUIDs pointing to a single telemetry region providing die C6 value Add support to search for available GUIDs. Signed-off-by: Xi Pardee Link: https://patch.msgid.link/20251014214548.629023-3-xi.pardee@linux.intel.com [ij: add include & reverse logic in a loop] Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Stable-dep-of: 375bbbbd112a ("platform/x86/intel/vsec: Restore BAR fallback for header walk") Signed-off-by: Sasha Levin commit 4f129fc6f756f8541e5bff45b1804cc11b1ec712 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 d3491b23bc207dd282d244488b910cbaf1e49356 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 a5c0ba31eef9ec11557004a05d4e7c5bd14c6be3 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 f0aaa198e068b6546224f0dceaa64c5fec0aa811 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 a57692ad365f321729a2d244c915492be77e728f 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 f161ef7b0dd2f51fdb002ba4a4e9bf0ee7409218 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 a6f147b23e36154a84f8c5f1dca3974925d56190 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 a70375f0b793ed438bb624ebfb1547a4e73a1877 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 b694c7de94bc5267627cde2dce0335a96a5253ae 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 f84949dd17847b5a6ada28ff6224144c7544a71f 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 53442c7d0c888e51b8bc3da196970a669cc6b294 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 becc90a04780a1ac75678c1c726c780e72b645ba 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 e7ae0883c8c89b901226de43862184bf37054338 Author: Chuck Lever Date: Fri Mar 6 16:56:28 2026 -0500 xprtrdma: Post receive buffers after RPC completion [ Upstream commit 704f3f640f72db4d44ec5ce3db8d4e150c974bc7 ] rpcrdma_post_recvs() runs in CQ poll context and its cost falls on the latency-critical path between polling a Receive completion and waking the RPC consumer. Every cycle spent refilling the Receive Queue delays delivery of the reply to the NFS layer. Move the rpcrdma_post_recvs() call in rpcrdma_reply_handler() to after the RPC has been decoded and completed. The larger batch size from the preceding patch provides sufficient Receive Queue headroom to absorb the brief delay before buffers are replenished. Signed-off-by: Chuck Lever Signed-off-by: Trond Myklebust Stable-dep-of: e786233d2e0b ("xprtrdma: Decouple req recycling from RPC completion") Signed-off-by: Sasha Levin commit f043dd58fbd79b8e560fb0c7079b3b6fe4ed63c7 Author: Chuck Lever Date: Fri Mar 6 16:56:24 2026 -0500 xprtrdma: Close lost-wakeup race in xprt_rdma_alloc_slot [ Upstream commit 765bde47fe7f197dabeb12da76831f40d0b20377 ] xprt_rdma_alloc_slot() and xprt_rdma_free_slot() lack serialization between the buffer pool and the backlog queue. A buffer freed after rpcrdma_buffer_get() finds the pool empty but before rpc_sleep_on() places the task on the backlog is returned to the pool with no waiter to wake, leaving the task stuck on the backlog indefinitely. After joining the backlog, re-check the pool and route any recovered buffer through xprt_wake_up_backlog(), whose queue lock serializes with concurrent wakeups and avoids double-assignment of slots. Because xprt_rdma_free_slot() does not hold reserve_lock, the XPRT_CONGESTED double-check in xprt_throttle_congested() is ineffective: a task can join the backlog through that path after free_slot has already found it empty and cleared the bit. Avoid this by using xprt_add_backlog_noncongested(), which queues the task without setting XPRT_CONGESTED, so every allocation reaches xprt_rdma_alloc_slot() and its post-sleep re-check. Fixes: edb41e61a54e ("xprtrdma: Make rpc_rqst part of rpcrdma_req") Signed-off-by: Chuck Lever Signed-off-by: Trond Myklebust Stable-dep-of: e786233d2e0b ("xprtrdma: Decouple req recycling from RPC completion") Signed-off-by: Sasha Levin commit b7bc8e7f09ae4b76019373c66919c68730c14f3c Author: Chuck Lever Date: Fri Mar 6 16:56:23 2026 -0500 xprtrdma: Avoid 250 ms delay on backlog wakeup [ Upstream commit 100142093e22b3f7741ac88e94878bb3694e306f ] Commit a721035477fb ("SUNRPC/xprt: async tasks mustn't block waiting for memory") changed xprt_rdma_alloc_slot() to set tk_status to -ENOMEM so that call_reserveresult() would sleep HZ/4 before retrying. That rationale applies to xprt_dynamic_alloc_slot(), where an immediate retry under memory pressure wastes CPU, but not to the RDMA backlog path: a task woken from the backlog has a slot waiting for it, so the 250 ms rpc_delay adds latency without benefit. This also aligns the code with the existing kernel-doc for xprt_rdma_alloc_slot(), which already documented %-EAGAIN. Fixes: a721035477fb ("SUNRPC/xprt: async tasks mustn't block waiting for memory") Signed-off-by: Chuck Lever Signed-off-by: Trond Myklebust Stable-dep-of: e786233d2e0b ("xprtrdma: Decouple req recycling from RPC completion") Signed-off-by: Sasha Levin commit 44b73b4b7eff734d852abda30f9fefe8161039b9 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 f3f21b94cf98001abc6bef5c4844d8241e67371e 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 e8dc126e8039584fe1ed5cb26e4fa1cd83b0889e 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 c0e6bb2b0408fcac6382158ee2bd9fdc45eceee9 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 9f1ef67c041ef592c13603957ba08b6f21010004 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 329ec20a86091d2a6e5b4fe507545e7d678a22a2 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 7d49f0ddaf5a4834ecf7085c13f4f8eac6a431b8 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 8e2c460a8f0e44d1c3f6ee338aabbd7aec814de0 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 eaf937b501fd0cfaba68f89654f4de2b223f397f 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 032692e4525a00392a4de8bb500f2e45bcd3487f 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 c7c8bab87d0df275333ca3483ffb9b8ec86bc643 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 e16012f8f63d33a4e0d5e1c6d992c63f60b7e9a7 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 330219fe8523f4d1212217283278b7f4ad2f815f 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 01564c1a260f6ddcf5357348075539eeeb8c79d4 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 c05ba5b57505aa8958e50a7a6158336e225e0ff7 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 c4406dbe5d8f4b3c322e483261bdbc7cf3872d2f 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 b1f76836327124db88056d6ed37311844dd48578 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 1517402d0a81cf8c37745c97c2e8dfc77ff75c3a 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 d6b586bb8f4892ffd772d04c29023c6561fecde8 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 2f9f7224e769196744f8fc863dc08404ff1e240e 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 278e30717c356e5e3078e5a2a6bcc6401fba9801 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 21a9b87ada08db49e487f1b41f3bc39bf700a669 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 652cea73b7b7b7c622a2be670e44e3c499c6d49f 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 068e9b6a07bc0998b63c5a2561535ba394c48764 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 1d25a8418c8904d5ad4cd49a1d9b64ad98ec7d41 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 89489a31f44437edb5c799abb8005b1ea2a16a6d 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 ea486d61b1663b345ce1bfdb2ec04903f61dd82f 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 18961e0f8966e41642b537bbba8d3933388c8511 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 93f3e84fc74e660cdbab507fb63faf449d860c25 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 d78b16d078149327010f2df604c079d757300b9f 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 a498063f95bddff3c17ad048fdbcf884b0eeb9e8 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 da40583823153f830e089b2fde08498cc25a38db 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 038a0f01dda595dceda8f0c9c5172b1297281929 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 c5388a957cf1da3c60d696358ec5c746bd35f5b7 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 a31893206588374d7d16fad387189d8165c7efd3 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 097fcf945d93a8126d807ba64710443da9db20f6 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 26fa946925a094f9cca28c621a82eaa1faa495c2 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 0147c544cbc6e14cc2d5624ae90a416c85353be3 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 1cddef80a180af74c33d2f26c962ce92b60fded4 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 9ac3675bf875792dced45efbf47116719a7c097b 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 3d57672119525c59ed73ea21accb001ccbcd6cfd 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 6ec473b3603426af39f9e6a5ecbd3cc6f13214eb 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 f835b69fbeaeb7011c0729df8194bf9ee3283040 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 fd6b65ade11908b46d3d972c95bc68e8022dc809 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 be62602fe0797f650af9c49d1b445e1453d12f6c 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 de93ef83f99e8d6d477da107703e76ddc079a1b1 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 96c8f732cadf7885ca05129f18b9ae3024c7ff92 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 fdee9f207a48ce204ec6cfceaa1459d2473600a5 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 3d5e4cc0d9dce79b0429da3134ac7b072ab9009f 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 d72ece584c44829c4ebcecf54d22e1dec10bf026 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 92f8b1d83383454a8bbf2f7bf3bfd0a856c8ce46 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 2b2b1613b734bec8097a6701e98c6496630c16e8 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 02d03c61e8a7b016956acb48e8a2512d16d87517 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 43078449ad6236d839e4d707954d2e36b10a6706 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 45652323ce74b2df957837483257e409d25eafa6 Author: Namhyung Kim Date: Tue Jan 13 15:29:02 2026 -0800 perf inject: Add --convert-callchain option [ Upstream commit 92ea788d2af4e65ad7a144ccfff50667e9a0d227 ] There are applications not built with frame pointers, so DWARF is needed to get the stack traces. `perf record --call-graph dwarf` saves the stack and register data for each sample to get the stacktrace offline. But sometimes this data may have sensitive information and we don't want to keep them in the file. This new 'perf inject --convert-callchain' option creates the callchains and discards the stack and register after that. This saves storage space and processing time for the new data file. Of course, users should remove the original data file to not keep sensitive data around. :) The down side is that it cannot handle inlined callchain entries as they all have the same IPs. Maybe we can add an option to 'perf report' to look up inlined functions using DWARF - IIUC it doesn't require stack and register data. This is an example. $ perf record --call-graph dwarf -- perf test -w noploop $ perf report --stdio --no-children --percent-limit=0 > output-prev $ perf inject -i perf.data --convert-callchain -o perf.data.out $ perf report --stdio --no-children --percent-limit=0 -i perf.data.out > output-next $ diff -u output-prev output-next ... 0.23% perf ld-linux-x86-64.so.2 [.] _dl_relocate_object_no_relro | - ---elf_dynamic_do_Rela (inlined) - _dl_relocate_object_no_relro + ---_dl_relocate_object_no_relro _dl_relocate_object dl_main _dl_sysdep_start - _dl_start_final (inlined) _dl_start _start Reviewed-by: Ian Rogers Signed-off-by: Namhyung Kim Cc: Adrian Hunter Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Stable-dep-of: 059e9100d82a ("perf event: Fix size of synthesized sample with branch stacks") Signed-off-by: Sasha Levin commit 28ebd287a7fade131aa985d80023beb8b3a5952d 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 fc5ce5606db5733e81ff6d99cb86856df2241136 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 7d881615fb6373f71fc628b3f00186aeca87a3d5 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 91353d63bbf61870959cdeace7c8ffa2815091f7 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 e6bc4e127707d338b776b4d5e44f91177ee2090a 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 67d0475e78b398918a00429a942216624a533ca4 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 5732869c70d42006725d7c726412737530c25b6a 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 f28906e7e32fd6d8737668ea9795f2ce8c90c660 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 210c202c0576b8e86502f04beb5c5318bcf5e731 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 226feccaac81833f227e7ad4b7702ff5c918211f 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 6abdf27fbcfb3e419efa85e60ece8782223780c1 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 5bb87456dcd66870a2529bc22f4535027697f890 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 601a9b2e3b2fbbf708384861186f5c4cc4281d67 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 b773c7161cea7b82b006341dc756988cad3d5b08 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 e1b79f77336d1b8fd4797f557315ef8c74f71719 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 c788955b4a1459b55c2a63e341df41f4f1d768a8 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 2ce4d93768d2c65a33c49e66b050d637a918e875 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 1d495446ec7ace5b61da366ffb161ee8319dd9a2 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 78f264c0cb2ac966f0e1efd53f4cd7cb41a30b76 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 10021c2d33061b7704129bc4cdfcacf9cc396349 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 48dde5c56426ce95cc966ed9bffcdc4c9a0c43ea 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 65d87f28daec31903fc39fee0744f7a0059c19f2 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 1ac8f4c112aa99828fdda5b1ba5ca50e676ee1c8 Author: Leo Yan Date: Tue Nov 11 18:58:42 2025 +0000 coresight: etm4x: Remove the state_needs_restore flag [ Upstream commit 9e9182cab5ebc3ee7544e60ef08ba19fdf216920 ] When the restore flow is invoked, it means no error occurred during the save phase. Otherwise, if any errors happened while saving the context, the function would return an error and abort the suspend sequence. Therefore, the state_needs_restore flag is unnecessary. The save and restore functions are changed to check two conditions: 1) The global flag pm_save_enable is SELF_HOSTED mode; 2) The device is in active mode (non DISABLED). Reviewed-by: Yeoreum Yun Reviewed-by: Mike Leach Tested-by: James Clark Signed-off-by: Leo Yan Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20251111-arm_coresight_power_management_fix-v6-8-f55553b6c8b3@arm.com Stable-dep-of: 2ab4645fe420 ("coresight: ete: Always save state on power down") Signed-off-by: Sasha Levin commit a454f61747c97e2eadaa7a35ffc1f4b1645c6a53 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 d3896c944338c3fdb0d61a919d57e6705113c2d6 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 c3ca7c6741af3520ae66f2cebd1a9ee0b985dc1b 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 fb940466fd4d3cdc7e084cd8777c838b2217ee45 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 bb3d592c7d6c4ec8ac6640c690ca13298e7e8e90 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 466c7f87de52d429b76a56064ab6959e4a312b6f 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 db2d8b6525bddd04d1e1a076172efdbea473cf78 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 02e2dadd62eae41a14698bfbaafe2a9ab35eee9b 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 f938bc8fde518758928f2ca97a7aab413c9615f7 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 430dac191905be20a60f6e7a2eae0479e4d358f8 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 d8f88803152f035b9f1f7b9ebeadf0a55b34302a 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 4fd51f413d7b566c3578d391d1d2a037dda0b1cb 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 25e85dc040a6c93e90000fdb558101bc88982d6c 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 baebd892f8a2c03f27c63ef0b4dcf19306ea2bcf 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 f04166c8677aac1c33c060e1b15e9ddcc5e9f3ce Author: Christian Brauner Date: Thu Apr 23 11:56:07 2026 +0200 eventpoll: rename ep_remove_safe() back to ep_remove() [ Upstream commit 0bade234723e40e4937be912e105785d6a51464e ] The current name is just confusing and doesn't clarify anything. Link: https://patch.msgid.link/20260423-work-epoll-uaf-v1-4-2470f9eec0f5@kernel.org Signed-off-by: Christian Brauner (Amutable) Stable-dep-of: 0c4aefe3c2d0 ("eventpoll: Fix epoll_wait() report false negative") Signed-off-by: Sasha Levin commit 13bf9879b778b2f4b260b45bed18f31806120d1e 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 9c1c120471a679592d0321bb35e8e571fe6e2b78 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 ae1f3460833d3e427420ab260278ec0e45d68c86 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 d35e4032f16d7621468c8b56816e7935ebf590a7 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 706fe1ce4f3a5185ded7eb669ea071713b50969d 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 35d3d6ff2bc1e7aaecb15d5377ebbd6227acae0d 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 aa0c43c13c0bf50c2eea1d590addc9ac7100a1e7 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 0fe155aa844e44157b82b7390f15b2a49a59765c Author: Kalesh AP Date: Mon Mar 2 16:30:31 2026 +0530 RDMA/bnxt_re: Move the UAPI methods to a dedicated file [ Upstream commit eee6268421a2ccc6d47d8e175a1f4bfcd78a83ca ] This is in preparation for upcoming patches in the series. Driver has to support additional UAPIs for some applications. Moving current UAPI implementation to a new file, uapi.c. Link: https://patch.msgid.link/r/20260302110036.36387-2-sriharsha.basavapatna@broadcom.com Signed-off-by: Kalesh AP Reviewed-by: Selvin Xavier Signed-off-by: Sriharsha Basavapatna Signed-off-by: Jason Gunthorpe Stable-dep-of: a57592c6392a ("RDMA/bnxt_re: Fail DBR related page allocation UAPIs if the feature is disabled") Signed-off-by: Sasha Levin commit 95d46a8d3ba9fdbe356fe7ed0117bc78dac9d557 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 104a7ff382a58a83cae018925e3574c784e8274c 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 5a48dd5150d7c6b9fef64157a6ad0f3e9df80d45 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 4c55003566c0b730876809cca2d79539b6823ee4 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 93e133b9193cb415b8cd0e81839fbbafb2a3359c 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 d774cdbda6634a78d0f2baf201ee5a8c57f3bc0e 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 0d8a12d7143126afdf9fbe2e3d438650dd6603ed 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 db1616263a2c53bd8b2248d0b08ea05f7af2d714 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 66919a6d72b9e32efb4dc7c517f95e4d6ba245c5 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 527cd14a416f23d6e681ea6bac176cf8533770f4 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 73711688479df333acc134e3730fff1acba1843e 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 92f38fe85198ace9b211bc7712b7951acfb94560 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 fe09dd288722f1c749b7506c0b3e7841a7d85027 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 81567d2b3f4dc4fc32f8b61433738bce2cafd4a1 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 073d95725269676c8b1dd6edbc156897067ef683 Author: Eric Dumazet Date: Fri Feb 27 15:11:20 2026 +0000 net: remove addr_len argument of recvmsg() handlers [ Upstream commit 8341c989ac77d712c7d6e2bce29e8a4bcb2eeae4 ] Use msg->msg_namelen as a place holder instead of a temporary variable, notably in inet[6]_recvmsg(). This removes stack canaries and allows tail-calls. $ scripts/bloat-o-meter -t vmlinux.old vmlinux add/remove: 0/0 grow/shrink: 2/19 up/down: 26/-532 (-506) Function old new delta rawv6_recvmsg 744 767 +23 vsock_dgram_recvmsg 55 58 +3 vsock_connectible_recvmsg 50 47 -3 unix_stream_recvmsg 161 158 -3 unix_seqpacket_recvmsg 62 59 -3 unix_dgram_recvmsg 42 39 -3 tcp_recvmsg 546 543 -3 mptcp_recvmsg 1568 1565 -3 ping_recvmsg 806 800 -6 tcp_bpf_recvmsg_parser 983 974 -9 ip_recv_error 588 576 -12 ipv6_recv_rxpmtu 442 428 -14 udp_recvmsg 1243 1224 -19 ipv6_recv_error 1046 1024 -22 udpv6_recvmsg 1487 1461 -26 raw_recvmsg 465 437 -28 udp_bpf_recvmsg 1027 984 -43 sock_common_recvmsg 103 27 -76 inet_recvmsg 257 175 -82 inet6_recvmsg 257 175 -82 tcp_bpf_recvmsg 663 568 -95 Total: Before=25143834, After=25143328, chg -0.00% Signed-off-by: Eric Dumazet Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260227151120.1346573-1-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: c010995b29c8 ("sockmap: Fix use-after-free in udp_bpf_recvmsg()") Signed-off-by: Sasha Levin commit 4e40056bb5c829f0423f0a6694a0477726d2147e 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 264d6a79c96ee3fd21eb3a95504e4c390675e5bf 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 5e8627b7a7b7ce338c5008fbef3219a9b3c9e1ae 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 e803077769248591a4ce230703050883917125fd 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 9f32d4c2de85fdcfc5a385437da64d3bf4fe520c 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 74badb5e2b00ab67774b7340773ac0b70e2a7785 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 21303c4a2b7275e626c6b67de0f45f2d5b9bb3e7 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 7a59146cb9ade235eddd7326764524b7fb2b54bd 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 87d1eaffeec41b6d6735c33391b7294bbde15f85 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 98a965cb1e767b54b6bbd831b6cea26f521a8f51 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 287d506d4e0865918cec82bb1361f283a08c979b 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 f01fb6138f8eb606b56ce9158e2d8b72352c53f4 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 4d48c08a0bf6c6ab8c07df37ee8794da891eec80 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 dcac6e4221f39f4f80adc7fb761c358a612fca62 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 36edab340a0675e1a8856cb9b7dae845acb733e9 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 b91b241a4eefedc7fddd3f12b35cb93f97c57d9d 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 1bb02353e79f7218160d44b5375bb69125142030 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 77a1ea975c8774764dc52f2167f4febd90b46953 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 8008ef973f0123192fdd29cbc6852850a0ab96d9 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 6564ce3a2f9c2511547a215229a74c3b727f5d84 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 f1e1c6eb82482f1226b6349ec85136d326a235ac 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 20575400fc1baedb8285683a0481e5610e9a7031 Author: Ivan Vecera Date: Tue Feb 3 18:39:59 2026 +0100 dpll: Enhance and consolidate reference counting logic [ Upstream commit 729f5e0153bda8c0423fb7c5795865b6b77ca050 ] Refactor the reference counting mechanism for DPLL devices and pins to improve consistency and prevent potential lifetime issues. Introduce internal helpers __dpll_{device,pin}_{hold,put}() to centralize reference management. Update the internal XArray reference helpers (dpll_xa_ref_*) to automatically grab a reference to the target object when it is added to a list, and release it when removed. This ensures that objects linked internally (e.g., pins referenced by parent pins) are properly kept alive without relying on the caller to manually manage the count. Consequently, remove the now redundant manual `refcount_inc/dec` calls in dpll_pin_on_pin_{,un}register()`, as ownership is now correctly handled by the dpll_xa_ref_* functions. Additionally, ensure that dpll_device_{,un}register()` takes/releases a reference to the device, ensuring the device object remains valid for the duration of its registration. Reviewed-by: Aleksandr Loktionov Signed-off-by: Ivan Vecera Reviewed-by: Arkadiusz Kubalewski Link: https://patch.msgid.link/20260203174002.705176-7-ivecera@redhat.com Signed-off-by: Paolo Abeni Stable-dep-of: 32239d600236 ("dpll: fix stale iteration in dpll_pin_on_pin_unregister()") Signed-off-by: Sasha Levin commit ebe4bd3560a7a01aa20ed6849a6cc20c714e978d Author: Ivan Vecera Date: Tue Feb 3 18:39:57 2026 +0100 dpll: Support dynamic pin index allocation [ Upstream commit 711696b3e168cea4165e7b7f051f3f442a347430 ] Allow drivers to register DPLL pins without manually specifying a pin index. Currently, drivers must provide a unique pin index when calling dpll_pin_get(). This works well for hardware-mapped pins but creates friction for drivers handling virtual pins or those without a strict hardware indexing scheme. Introduce DPLL_PIN_IDX_UNSPEC (U32_MAX). When a driver passes this value as the pin index: 1. The core allocates a unique index using an IDA 2. The allocated index is mapped to a range starting above `INT_MAX` This separation ensures that dynamically allocated indices never collide with standard driver-provided hardware indices, which are assumed to be within the `0` to `INT_MAX` range. The index is automatically freed when the pin is released in dpll_pin_put(). Reviewed-by: Aleksandr Loktionov Signed-off-by: Ivan Vecera Reviewed-by: Arkadiusz Kubalewski Link: https://patch.msgid.link/20260203174002.705176-5-ivecera@redhat.com Signed-off-by: Paolo Abeni Stable-dep-of: 32239d600236 ("dpll: fix stale iteration in dpll_pin_on_pin_unregister()") Signed-off-by: Sasha Levin commit f7aebaee2961bfcb86f282202d3dbd9b69db1a7c 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 34bd255dba321c6ba34313be827417b0382cbc51 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 1d072cc3ba4338d6b2acb85d50a3af5cf2b12a3e 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 417bd36a085d7a833bb00325de32447f45e273eb 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 3d90b15fb1918074c54e07161bc8a8f127614306 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 8d5f4be1348829d4482156bf77a96450f65138fa 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 450e48271827bdd3b11102796821e402e336f254 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 6d585d0dc674351e234a9695f9ad6511ab1f1237 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 446fe8ce699ce0a4d702f7b0fcdb50de340b9260 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 697db22a9dcc4b48451b1194ebbc9cd1e7a8bd00 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 62ce489acb428a936bdf243e7b92b3eb341447cf 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 bd851b10daee7199a658458b8ce250e95a334500 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 755108bb7a5083e911294c416cfea605dc75632f 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 0500af8630c3253f0dde879bd3a73a06bb2f2b3f 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 a05d638b607460514bd0a8afae64be71df15a04d 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 ce311bd2e36596f0aa2c92ca86fb3e019ac57eae 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 67cec2f1eb9e58719d622e92e2278ceda72dbd85 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 d0503357653ee62188987a26baa2d7f3689f367e 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 7f4aa81f5bb276cfe1800f3f0f0a082cadcbb662 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 0c22c009243595cc67d2d296f8512d2e54d2115d 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 1c9246a199e19b2fd36e94feed60e55f27103a4f 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 dae23c545eb5a2be3b27a82fd0f611894fb8ab69 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 1749fef4bda0f4b6a6c8391cada8e87b6b39397d 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 2ba237315193604f41fb5109c06bf0fc61e2c4e4 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 fb4d57b83356d4bd411b45ede3024e0ff42c9b5e 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 5f99a396f706afc749448659d1565991330e4f71 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 4941205f5fa391c845671a6a655fe72451df29e7 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 a27481516d32f222b71fa78363c2d31070f2e0b0 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 7e401233f9bb74a626e70698d0d62f3a94ac0676 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 3cfa3d8e0dc167850edeb5bf5a07757db83fd54e 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 cebaefe1aceb650d5c99a4c0e1a4dde09e211818 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 66dbb13eeb2fc339f8f548a9076be4c1a94857b0 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 51a1d9836acc76a1bd16170b2f4b35f11036593f 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 ed8605c6f39b9b84f9a4631db6deb25e7f1e973c 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 a090880c1f544589427e5b7050c40fb211ccecb4 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 bb4a5b3c91af3c8d705bb2e9f6f8069a70db26fc 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 0a8b5b74f0e6b6b9ce453bcfa4baa502c4c7577a 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 10e05634ddc19953d7357a39eebee4e142dc8397 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 e098c9c6477dfa3cb363282100108484ceba5cc5 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 0f1510e84d7bfc3eb9538efa65c6ea0aadf1078c 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 9131e4b023e0db5764680034bdc94aeae0b0f33d 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 cb527e063a32ee422dc2766a9aca620bf903ffbf 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 d3ff718c0c7153e2641e6a09507bace14fc5c402 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 4b87a2497276a72fd63028e7419abf0fb7ed837b 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 1bc1487f7a7f579ddd61e27b2fd226a1418df037 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 f704db4b0318a80d973e5e69e56b37e6e9ea093a 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 3a1687e0506be10475db73bf9287635410741669 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 7e694ac97591c4f4b793d4741b91709cdbbda819 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 ec4d352747a62c1082f16c11a74b37d6eb85a5a3 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 7f206a8d8d82296aa2d30bf5f3e5bb73fc44591d 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 a0fd1086a57b982f8c24ae4ab165c2af39fe1735 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 e8815ae9dcdc563d9a770388cee874442255bc58 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 f1b4df9c260c51726da2e86e19322825fddeefd0 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 e284bb94ad4512ec0bcd9b91bda99e67c507f7f8 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 c86c861c64b586720ab34e125445253aaf9f7285 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 0eab19ab9cb1be241347c6525a6a17f0e8cbaf9b 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 c83255f3cf22d13c5b9736668cbe38a098fd6d5a 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 ad6963c3bb458fc1b722627405800c32e4cd840b 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 5985ddfd3e83fee2e021ed6908d4026516f47278 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 db3cd694ded4c8d492b62c7228e9c0d9230b13d0 Author: Christian Marangi Date: Fri Nov 7 00:57:04 2025 +0100 pinctrl: airoha: generalize pins/group/function/confs handling [ Upstream commit 4043b0c45f8555a079bdac69a19ed08695a47a7b ] In preparation for support of Airoha AN7583, generalize pins/group/function/confs handling and move them in match_data. Inner function will base the values on the pinctrl priv struct instead of relying on hardcoded struct. This permits to use different PIN data while keeping the same logic. Signed-off-by: Christian Marangi Signed-off-by: Linus Walleij Stable-dep-of: bdc95d7e8de3 ("pinctrl: airoha: an7581: add missed gpio32 pin group") Signed-off-by: Sasha Levin commit 0234e8fc296e7c9c778a0cd96e1b8e5b87b3902d 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 46fbafe3d2d569d828e8d24a7dbe1659f63685cf 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 d416dcefdbac90d96b22485fd93f28229ad9984b 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 1201dbb260507fac155a43b83b7e7080396cf4ca 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 d2acea4f4747576547566869186f1ef71884e2de 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 42a9a76f314ef1eb54039fc3e2a63d7773d5ec06 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 91ad3088ee1b7c939f95bfc586231e55e2c06a94 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 f00f5c0dd55319bc33b76f72c853bda0e0a32eda 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 c998a09c7144e0bcf7c1d1b57b0b9f8bcb866939 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 f0ada4846d11b08996b0c68b6dc77429eb2cf7da 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 cb20a9b50efe06620936cf3a761c37c299abdf9f 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 47636f0a70b3637621640e7681eb296047794f35 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 6b2c271d2c394194159cfbd7fc26a2f6b97a8214 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 484b3b9aa79867dfff53c99c64309d06885bfde6 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 88cb304c0be0c67b25314ed4583657680370f874 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 8b55e7ec116ca3466cacf80507481ba63cd8e670 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 3ef0cfa77a3d526591be069850d186c255e3f0cc 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 54556d53943823df656bc27f388fc6771d20930c 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 86e0b37738deab1456205ca89ecbb3693559b390 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 321c73baf54d971ce3771fea275c98a247f7ee35 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 646614dcb16070745d65957adaddadfc000519a4 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 f9d922023445112cb56442c4aa057cdbc13dc11f 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 79366023aa891ca31376021a7bccff6384ca1ff1 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 1f5f94c6c6b2e4eaa5b45815509e21d0c6cfa81e 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 a2d0a57538fd0b3b3ab75d64bb64f4cd2fab13a2 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 3d56f3fb201ff6c0d60d2ee3822ce7638cb39a83 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 ecb9be4fc8be04abe5bfd39218f118b2393635df 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 da6f86ff4f2dd490bea52419a49e19680efd5847 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 37e85be551c4de3da45048ddd48f5aaee2e25939 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 e6d83f877d5ab47202a16b6c321e724964caa709 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 701ea71c17c925ddf42479c26ba686a6029ec54f 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 2aa37c8ef1092c6f088e23a90bffefc672831c09 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 f85410ebf20bba5880698837e8edfc8798536421 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 18285888cb41a87262e8bd90d3093530cee1df08 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 943f5917c53ca5aab980b0c9faebf7770978d7b3 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 ba641829c11cba5b89fcd9000dbea300fa1b7502 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 bd5e90b0f5a0915325d6d2b86be5cd29d859c81c 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 ebb579c5c0f0f13bd9814eda136337c605e18558 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 de590cdf7efec8a0b6da90ae2ab5fc5df26810b9 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 0678fed27def92ab3b6af88e5b8df18eb8117bb2 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 47e5302722e09860bef18cd4e075bb823448cf0c 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 90a9c909c5b75e26c83132ce6fd851dff79e63ad 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 3b15d02be05e74321adb1e0ae0cb4ccfba7c6cb1 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 7ec839c7c0bc10ccb7a17ac4fada0910b674c5a4 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 ad12fdaaed16c6e75f2f826c0ea7c2b19c57da63 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 3b6e6fefa57f4f0afc94bd72a55a91dbca288368 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 6b8e35685c18c7d5298121503e432bf846c9076f 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 6356a829a1edcaa6b973f298373db47c34674e2e 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 42f34c478fcdf7f3c1a9dfcc211abfd3efd86f01 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 1a399103cacc902058888e1254578c0c9f340f5b 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 dfb27e5dd9e4d34fbb74fa834c644dcef0be2be9 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 06e65d6cf80490bc0457d339595d1ed5a89e8899 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 c386e90a7ce8ddec9f038e9437661a2821b0ce89 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 856fa6a21586f86c4db058a7e7aeff36f9254231 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 a10e4959a73be5b70f59e1f7678bed78ea720906 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 b8bf7c221b36451e9a88a33daa0bbbadcb73ad54 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 bd3b91ff13006661afa19f8bea78d414fdfe0114 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 c7a83899203ed36696a2d35ddd03c0f522874a63 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 3f0ea6d14fa4492d5d25a4e1eb023a6c47ef455f 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 ce9d5a021cfca451a40f8d2a5efe11ae6a844656 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 c788617705c3a6b9702e7cd51d95d395ad687ddc 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 a2e8b5264f92e6c4b5080304ab9c726e93960514 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 bbd664b7c77f6488cd5652231c0fe01d069a73ea 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 648a3960e366410d8c7117b06bfae993d563e2c3 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 44cff0737127b609c2c40bf41f439bdd031a217d 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 f775e7bda9a4f53d06315595935394f0d3540165 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 c2bd9fdb448d6f367b2dcc6c274df18cb6ed49c3 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 0404baeb9e43008ef8ace970a250666759312b69 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 298821692d447c2f7b1bc9ef41cd88a31bf56436 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 637ef4961470e04455102b34ac484a34d8eca0a4 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 f25d6e4ec4c257030592bd671f113cf9584c52f0 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 9e82497138abea7d5c6e65015663d907fbcbf6b4 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 1279bdab5fa1f28c168e54215db506e87c6fac1e 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 e8d89baf921703c281d1181e1e562db518357851 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 e123f0ab02d054ad15e4777d5f924fbf9b497a9c 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 fd284b12810e4fb7eea8334c6e38af78e3d1237d 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 8119fe468b01f9854f2d01e4e32da588ad7346e5 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 d4f84bfa089fe71f775d25beb29303e844494c25 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 f5657d399b7ef9f4adc5e427eae413fe45ccc5cc 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 c213b71a2d41635e386bd6432256533b817456e6 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 920dcf1cb8dae867fe464946e0ce8c81f4003fb2 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 dde04550fd6ff7cfee5655b9030e2d869673470e 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 6cb635ad1006dacb8d616e66703105c3f002440f 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 b7474f4432dd9559ada03b01a8cd3472cd02c61d 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 84932636d020b5d235ee0a38b7d8895075feef16 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 8daa1a64711ed68d1c9bf59392e30d63dc4a8fce 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 8b0510cc3a4a000d4ed1a56cd96231f3d3ba94c5 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 74ac1ce1f4afdb3b80b6742fa28fb86c8c51d31b 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 c04e0cde2fa38acda5b4a1ac087379d6e245f70b 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 834d4cc067fa6c7c7262b715045f3ceeaef08c14 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 4b2b6bc7f5ebe75f5d4d4421896594f6a71e3e87 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 af8f0ea1f0a3a5fb5ed2b8fed3f1501d644597ee 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 f03782f7f41f2afee5076a1ef08ced5649218771 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 1b5d8a248c3afa640bcc99fa95abcd1e36f3ee18 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 495e7e832c670a718caa8906c6f589f34f739715 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 efe57b72196ae5b243e9ce70561a0c17bab79fbd 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 58513d6d1241015bed216f6284afdb4e76dda14e 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 2eb39de4962f842d653e96818ae372665cd481fd 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 f6183983ce1ff254d629a333739082b39d7c5eb6 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 04255bda8d795cf69adb2c31c7d6fcd7a1250f85 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 e6ab22200e449223e3bc8313108f3c95a1f775cf 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 f3ef944c55991b6b6c85e9be6a7a807e79c17113 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 b5087fc4ef1f8faf2c09d4078718a7ae68ae0949 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 ab4b5a07e1c1a7ebfbb32f5e1a6a3c98e9bb0df6 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 f9173e0fc026c882fc89878c803861549f96c9ae 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 54cab78df0375196aaec4e3109191653d21751df 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 844a1ae78e220e922882e1e25699234170b2dd59 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 47831b503ecb7643ec2af63b9c286f0b5e14ee6f 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 fe5414d6b39959dfa1207be7b05b7e0beecf820a 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 77b4bfc1ce32a63340c382428425574cd4dd5e4f 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 d53eecbca16f056abba274075cb15120ab062518 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 e6665d36b37b4edc5c50c1a94894a6082249ca11 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 dd0d22fdae4cb6b2016c70c0ef3cbfeede678e08 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 8ebc31b86dccdef1c222ecf1ff6efa27dade05fe 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 5c9c67cf7a3d16051dfb90e98836f530964dfb8e 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 b171119082bab57ff3a715fd8593be8c44af0fa6 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 4dbb71c046f72a953bb4acdfe382f301bc18d7f7 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 dce1e3cf735d1fa5b71c9889d442f7c5388590cf 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 7b819a84f1d5fd18fc07734aaba525161f2010b9 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 c3ebf67cf8a9629b815aa8a8000979e3563ff963 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 a087b2d3411e7f9df71ba3293596923ee2c70d65 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 3fa7139b5f42731a61f78c42433adae13f9adc21 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 0e389fc290c350c67591abf4c367119f4689f310 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 3fe2d0d21c8ae2c37770e5aee9bf51cb13ba526e 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 bb44a7690a4d553da705919cf666a80f5ca9011c 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 9af58d10d0d8c08b822de5fc99e61f31a87ede8d 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 9a030fcb4b192a508113787ef28fb97e27dcf6f6 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 b8d15e85596ad8993d42e0703a9741961a2f03eb 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 b64120d54278e87a9c21dca7c85b75d4d72d1d59 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 ac9e29b191a039e886f4a8108364fa452f2edb52 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 58cbb1c2aadf84309521d8fc2165500f55b89645 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 4e18e9361aab05fadf114c1ed8746be1388c0f39 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 f5102e0fc3c6dc8685549891a96e4589fdb3e211 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 7f229d27bf27c7e589eca690d8612763a7a4801f 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 73f9f54d71749f7cdd51285e9d92b8ca4e9fd977 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 4beed798daf4ddcbfa723d8d28a4e02ca62ed6bc 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 e82d515092a0cf2bca92f399d5c330c324879cea 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 8cbd587e8cdb6eb1bc304df87faf272e90019ecb 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 8d5ed4810e4794e7de5a727a33e515c37917dea2 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 c3b073a209a9baa691b744318ac929fecdd8847c 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 778bb4939d45768f4ec5bde32fcc361e95de1cab 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 efe71fbced5242de5211a59ec9693353be77abd3 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 5a1168ba0a95b65961c234ae21522dfe36d348e8 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 3777588848520f913ad2f97c110c8ffa5fbe80d7 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 5cf2c85b1231218a3e3e9f188afb4fe2e17903d5 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 0830287cc6cb73f1d7bffbf5e6b09099f6b21fa6 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 5e406928404d67a8da8aa3ae21732e1ea1a04118 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 36bdda0c86d51be003757d8d43bfa834250312cf 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 ffa974b2f50ad8b911b9066d7aed84ad0afabcdb 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 8d763babb2a2f67b35724308ee790f87e57bc540 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 61f19729728243c82476dee31315143ed3275e7f 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 d81370c6c4f5f134590d9788eb01d59738574e80 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 846052542cfa644f3b13d70cfa6dcd27d35c9769 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 0de14eae6de886cf86555570d0808de4d9d4a7e5 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 abe383999640fb8958bd65a10492248729797209 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 b6862b6a25c6a925fb0b0e549ee4a52a8d2966fb 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 3a0f73d27a8d379a8852a378b3c3208143e3b3b2 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 91ca9eab008b962111d6260dbd382d16adfa314a 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 5c53406098b599c420b031e6ec5ba8a2f3794c50 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 d292b30e1b746ec22aed32f38fca65cc8e25a76e 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 901802925ebed22f55462e270e1faa4b68b0eb04 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 617a5a67ce01673e155c3e93d4519bb3bdcdef2b 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 cfcea221db933295bf2cd75a7f80d441c7a51e28 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 eb9b89baf30875252f1cd702bcaa09553792ccbe 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 adf0eb748d21d301e6376180d18991f3779c6ce1 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 2d642797dd1c18ea26c0ce642fa6c1f6d4dfc599 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 f0742d09eb6ba81b5eadc1287d8d51e1186fb092 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 9e565962d999ea77a2b11bb71ae45e27516cf82d 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 8ec64276ecd24ad57031ed04246569c0e4ffbc68 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 ab4d04bf8b2f30032f026a6987c84119d19a6fd4 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 803087a16a4eab1980a68ceb3967e3a05e8d2035 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 f3389fbaff1a1017da0e79cb95594f80f493391d 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 a441c0794ac28d546628e93daf44237ecf441104 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 a7131340d0f95df9a541257dccab5d85e6bcdd2b 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 5ac9e793ba2583d72740d929e7858a6c82e22ed5 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 b7313f23ea5a79b199a007bfad64a866cc2c22e7 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 e04e384274f83accb6af33b092152ad6ac946596 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 0e2f0833556c8c5269deb457b89d538644a3b747 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 d2cf52ba2803bb2b7c2423678579e28b46fc0914 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 b41923dbf67690850b56359d0de8705172d78642 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 ff4e38a37ba531b06dc5c23b9da8ffa31f9b3095 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 bc7c166cc1012fa94a343172007c727667075814 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 ffe754288750ae9e3b8f28227bbabaa43e3206c7 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 f8f48c851a0d24e3ef4f9b95701e7774dd70ca5d 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 5420eebf3b3c162bfaf965f30e61cd1d689e5732 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 02558c86b6b761063e9399e6b939984500327ef1 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 4779f435627b2b22757a37926b843d98e32aa97a 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 bae436a78a05890958e50a4e9be0944097193a16 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 5da012c605fd51cbe0314aa641acc5e4a9fe3ea3 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 9a84ced0243c74aa431ec287555054c69e6167d1 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 ed5c94cf4ee9edb302c9242ddaf4218d49d185f5 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 bdaea74abcf0cc484925bdf46a92cde73f2d4a99 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 6d536a910717248cb3925d0e6c3595793cd1c752 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 4f3c17f14cf9085a9c9ae2145f748ea55cf6d4e9 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 5eac10c52139682a78a9442cb4ab1eb19eb07d69 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 5231093c082951f030f16769c280641411b17bd0 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 8572232ed74f54d1cc02477b0ad2a5cc1dc63dc7 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 ce7a2e26e144fb6121506703d5d3c3d501478cc3 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 3852478d34c7baa490ba9c7374ee901a56eea577 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 070f356ea4f419e4e85e4089381f4477f41d969e 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 598ed7393a639c7547b28ff3e14db9f1ac37c132 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 afdb92d9c374d107abbe55f54481e71b3c45f177 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 e545fcba3660ce4e8a29556c82d4732957cada67 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 c87339cc08aa0af70e200f2255e9a8b747fe06bf 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 39e8be33387e3c5033982384c8448022a221e4d1 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 ed7ba8d048a4c15ce64d6f9aa9e09c188ba32230 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 340936ebf5aec7652d6544d9bed299243836239f 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 2ab7c96d8c3fb7c9d34b1387488ff031c5831a39 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 79240eee5a40014d9edfabe19f06b35ffa84e5f8 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 142b34f7e329c6b827cc3937c323667ecefff027 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 8c0d3cf0d5108c96317e0eca92b60dd368867cef 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 6b617b6ccb6eb61188d91ba6f6988350218101e4 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 40a2a91da02c434938f0ba53877984820800b5f0 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 05d85fd32e4fe9ba37ee243a49415f6557b8d162 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 b7ac7ba19a0b83c3cf73321f58ab287e08999d55 Author: Wander Lairson Costa Date: Tue Jan 6 08:49:39 2026 -0300 rtla: Introduce for_each_action() helper [ Upstream commit 648634d17c813b35da775982662e56ea8ce750de ] The for loop to iterate over the list of actions is used in more than one place. To avoid code duplication and improve readability, introduce a for_each_action() helper macro. Replace the open-coded for loops with the new helper. Signed-off-by: Wander Lairson Costa Link: https://lore.kernel.org/r/20260106133655.249887-4-wander@redhat.com Signed-off-by: Tomas Glozar Stable-dep-of: dd520daffbc9 ("rtla/actions: Restore continue flag in actions_perform()") Signed-off-by: Sasha Levin commit dc266f6c4e2628576ab33042b6b2a12480220026 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 10753da2d659dd425a6e620f47f86852d604f67f 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 0db1949084e85a72d174a7dea3259b94fe5a9305 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 dc1470299d11d6275ace86fd9509944adec1b5c2 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 3e8aed5edaeeb237f97255d711aac6b5843fc059 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 140d6fff4ed266592492a23444043842b4af7a62 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 cba2ee57fd302727aea7d41e9d9cd0969f5df0fb 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 ba3209704b3cd46961e4e081af5c52a780785648 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 24639c4dc466e879640d8a0f51e1c1a265bff633 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 eb9280ea8dbd25e1e3be233da1729705dd042d76 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 2739d234d895283b518d316c5e1df98994e56982 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 95e0b4bc29ab9a4f850bae80d8457a778ee62aae 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 c418c956c21c97ee66270c1260daff9adfb39390 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 11165fe2c5ea0516debe486d91df67abbe36905e 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 6dc781778b595be94c31395b2cb167f65145d91f 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 de236b813d8b4df0beb1511a2fa4cfb062e59896 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 56694f00fbe1042a344c19e9cef7dc62428b06f5 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 02f156309de0d65641cea88c27d011c2e1b1ea5a 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 c4bb92b3ef54c8b41b81909eceee83dada94789c 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 3880ee7c88d78c3ece6f9af3bfff94f6e698aeb7 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 0a294feec21b68834c12a3b10900acddb305bce9 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 2c12b0dfcedad501cb7bf4389462f42225731ced 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 8db227dd895a84bf09c0172e5054a62c8ee9740b 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 0c83d13f9b3f1ff066b9ec0f181e8e19f9493213 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 c9a3ceeddc6ad16a3592881fbe2fe94913798284 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 c9670fd84df12bceb0ec4a9d1ef35a7ec25ffd09 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 80f8e2302e639d456f4e1930c362b3c2e2c47e2d 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 9420871183eabb3b826ebfdf5b5691af85abc7e0 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 66f44ec974ab372e4e1ee9eac4245237c94e8f68 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 16138ea9833d6bb1bed37a3321f282242704bf02 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 f67fbbfc3beb850b1ee20a621a51a72a33f90360 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 e59a6aa89e0fcd1d0707832eb4654fd9ae7d31e6 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 424d51d33c7541a86934067c2c0538124687fc90 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 7a551951ebeb5b3f05bdb04a73d4593869c984c4 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 394ed8ad05889bfa442cdbf93f5b50068a6a20ce 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 090f5fb1e3e23df9dc6380a9fa0b1309c084f20b 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 c11039512df495b6e9cfdb2ab25341aa09b2473f 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 13db458099f28963a088f4f2b7c9be2025f8ac7a 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 3fcbfc50dd52f12d9f964dad57c23d9a213f9662 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 376951c51cdd02334eab7e1c65e2da0c67522e71 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 4a6f5cc42c7bf7cd6f982aaf517289abcf1a5dc1 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 ae62edb00c0ebe99f7dadd0c6c24789aa52979a4 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 2df37ead6d84b8df5340edad444ca5f7edeec0a3 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 62c8cc825f49e20120d893c9171b8d7b055f9493 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 b0444205ba39e44c27f3ebfb7994f0e9a546ed34 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 29de8448174cfd93431316c1560e9bc2966b95f3 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 2469039f0fd687ed351591984622e763196bff32 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 baa333b2700a7fa3529d504529c8c10060fd687c 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 09a2a7d041a78d9113cc7fb8bf53f8a3a4f0315e 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 4ba44339fd3ac10849caac1cb478e4e8254077e1 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 3c808cac676c5058b492e759272f380520f1465f 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 0d0ce8c7025ac9d0db9f32c8d00ea4e57cca0f5c 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 a8be1bc8d124fb8af0e0c8cd572280edd0def8a8 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 dc36463b283d9b9a236bbbf6b57ee74fcd3a6bb8 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 a2303478e7301ff33b8309096715d8ecd92b0fee 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 b3e05859cb516331f27f312651f5934f9f15408c 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 11daac2817dca75e3eabb2050bc620c29e686fcd 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 15e7368de5842ffb248b0643cd40f3a57b2c1b5c 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 a88f6da618e8b441b28eb753d2d5f6d9af9909d1 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 276e731b1b5778c7f4180e6e7c99272ed03c62f5 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 16bf3154f8a8029c08cb6e9dab1892a97307cbf5 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 c67c672047667e5b1ff62ffea07fb7993faeae3e 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 75c0bc011abddc311b07a2a393620221e3913743 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 407aeb8c1aee8499ac303e29640327613fd556c4 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 bac3e70c2fb10d3ecfb7bff95cd520c2f2ca14d1 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 1f60c3cc302d2df7330ef84de09e2c9d02fc00ef 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 3024229e4a5af93d6731634dd1b825e62844ea0f 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 63aa7dda9a1ede4b479924765e8c514e2b1fb9b1 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 d57e67ea48e4d095052f2b14d8dd7593621f862f 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 2e3e4cc0dd349f54574526868065d3139ba65f58 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 5d6f34dc4f056ddb70da73b1b96d7663b4e24ec3 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 084d7d5668f30720629aaa0b9c6c0eb358f4eb4b 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 6a576739ce4c974157fb5d3d366361bf80bc9146 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 0da72a88dbbabd846a0c322f9a35973cfd32053c 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 5e353d9497f95ebead4fc3fc8cd7eb3ee878bef5 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 6a357ceb2110052c6909b246daa63f66ea6639cc 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 bcfc49f1bcf1b2bb5e77b6f7d7fd18adf443e0d7 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 e4d599a286b5ab5bfde2f83b93687cfdbf214549 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 7471006cd854d159723344be809e8287a2d75502 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 be2c137f23d15f03f25052edd00a76b49fbce9f9 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 65572fbd86033ae2370125593d59b8be34253aaf 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 5100febf8e9d6c8c5ba8dc6534c6a5e3376e5989 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 ffa85a2c197935ace6f1634ad9eb0a44bc615670 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 2cd221fca036b5a6f5516075a63af2c178ad7d52 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 65e344925fa30abf50c8de8c150b397715fa2066 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 b61af0268e3d1308c466bf0be5dced844eafc1ef 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 5c1196b5a3bf368b169d435d6b22cc7d237be3d1 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 d8cae30582f068352d7fd9356402472e9713f0ce 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 68eae3592438d5421e23f2156ad7c407b526c44f 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 21650fe221ea9b72809140b691589dde8bff3eab 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 cb414aff28e18e6f5cff9f87ea31376ed8af317b 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 8b42290df1765670ee8a31975d9798bb9fed078d 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 d29b9c38f6eb4fdf984ec74f7782d7abd7f89483 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 69bc4a3998742479d0097ae7d15fd61f5da4fbd2 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 a0f64cf8bfcb39e533d9e27aeb763a8d81b7f39d 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 4c57df82af833368bed790e6e9f3641f265c97d0 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 28b91fd2adc4f57485537a85a9348ad27bdc4dd9 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 94ab8a6e02bae0eb094053bd54e73653133e0ec3 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 689bb48c828caa1ed1fe67009679e46c13818aed 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 27af16a44f59075dd908d15fa3d05afa366c1f4f 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 886fb63981a921d9aa9678ed292dee084795316c 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 2e2e5888764bab89e040fbb43bef508622d5f4ca 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 8200ffd8259f0944cacd37e64b42f327932edaf2 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 9fe7605c1c14394e87e8761fe7f0581e6a333491 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 02367b12b303a2883d05a300ff3dd27c23dec5ad 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 e003f3a4be738f650e283e92d07017c3fef8da52 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 8960088511ca168fc7d18977d93cc368357ad390 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 0dd1cf48a4217625ecf94fccb7d7060883a1f4e9 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 feb10ab7abc2445e05995f62c1d60e88c1fb30f5 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 9e642727b97ddd4defe1315060b77335a2b2496a 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 e725aedd26e96e35d682073e7090cd097fffbc67 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 f9f1a2cd912da08adab8ad25efe43c78934b3bb6 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 712714f818d83373847874ab0f8e426be79296cf 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 4695cfab48f909cb760f6f64117d9c82236ab939 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 6acd2fbd00f9c72aebefce63fc2e73e8f3d79061 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 9b21d5bd33a7f04a2f4dbc440150cc1d55a2c32b 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 aac63bbea8fd5a34f1a4305cb73369068f952d32 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 c5c79d92da0f9a09f48be5e2aabed2d6d1a96294 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 25b0061adc1c1dd53d4957daaac617bd191dbcfa 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 46696b0b2123475d7f95909435c09808fc5ffd23 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 8fe4736532639f585355b458d7b76c4153225b52 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 224d7300b5691efe453c5c39d2c6bcc0124440a3 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 4a8cde6f7281ea2c4c290f9ad9923b3631defceb 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 470984f1c2ed8caaabd41c57028b78cf737b24e9 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 5f7777f0da03002efe350889e9923f59554fb4ad 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 b9c6ad49a942dd9363710d38a21244b20cb98ee8 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 a5e026d5b94874bbc16a28942535fe19e6ad4e83 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 6173c83d4d7910b351e39426cfa87ebbffce4a7b 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 2b553fcec1cd81921c7f7c2cd4ac4acbfe4e2352 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 d003d9bb44da1b48af56689bd2be855962f5cae6 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 76a4c3af3253dc7b27390710c7f402dbb862fa81 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 02b001d89157af83e1421d896836a6946568d3a3 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 a402b3d09381525dd4fbe888f7464e71692fdbcb 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 c599af2eacd66a6558ea241e743cc2f27673ddc8 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 796ff973077c70f73a3e9cc2d8399b22a4978fc4 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 53baa6b90f499a7b1fb7a3787cf3e03d35dcb6c4 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 928f758f8f2143eabd0c7aadab67182641045ed6 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 2b2a17af8d8c7a5aafa6095f65a7c4041c085656 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 4534f70aa70421dfd32ea00398dcee17c694bac5 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 facbb592e22dd674cbf5707e44288de38f48d08c 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 1917015aa0a1d5e418370fe2c3f085356801e73c 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 d6e8d6b2f8f043124ae8f16c616ecbf333557d45 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 29fd4f4c73e2bf387a28a0e6ff1f948713814a23 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 19eb0ab0bdffb347f7670ebc1244b56815dba726 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 5435fd3edcb11c7cc4002847c83e9a50b49284dc 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 7c79be7e634474a0914a17474ceb112013c2a619 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 a83e77d1e52c01c50096e6e97c57d34e0590d628 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 fbeea02c3564d1e289d9c5dd676409be314fdf49 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 ad445de67359f24088d4305c05fbd7e34c4e35e3 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 01155ded5d4dad61840a9a3c33ab56778ef1f100 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 7a1ab5fdcae896e20ca6d68fa0fbd2816cb7471f 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 1ef3d1338d94ec41f58fbfb6ba7742a27ea61d89 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 aefc30e4a829c1683f6ae999df7f9310c27eae6c 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 cc77f0d91e3214e4292208f02a1dc09a31f9aac7 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 543ed0f61d56501cc585162da600bbedd7c08c0f 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 1638e178e49154f3c60139e33c819650889e4378 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 cc6ef5ee7d88a5125df80b5c83c7e2978f316ae8 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 228db770fb0869fd0ddfa2ba7bf8387d6b608820 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 123e1cd95ba540653745c5d70bb9b9d6eabcb5c7 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 d8367ee271aba04cd3e85692fd23ec3896b8cfb4 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 d72ae2c63b683cb4783546b0968482888946577b 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 8f8233d544acacf1a370026efa2f836f5fc207bb 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 58d0b4c55cdfd843696e56e484367ccd2ed71d47 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 6005cdd9f48fdaba4131ce5e82e67531f3cfbe4e 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 d10227f899c902941f1fb536991c9052b0ead238 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 595710e6838c3fc746660bffde9a4bc52a864f40 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 2dfe817167af0d75bcd647fe2404a9a0d26ef6c1 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 afea00ffcf41ce678ee00fcd6dde9835bd6ce2ba 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 bc4737e55ec4157380bf010f772719e82deba094 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 392c03362c2782302c6e36f7b0a06745fb3640ca 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 06dc892561f5a08b2493c34c8ec2cb94dea33159 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 d9dfa176899d488e48bb7342d2c43ddd36e66318 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 daf5d03ddb8ccbe4a9bf22b320de049d2f17a3d1 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 41a60487b5b04e036024c2698f001f45ff250185 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 353f26c74660bcbd8d82cd76622748e14a5a5db3 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 626fa93d194db63bd1bcd4a8c1573b0848a3e997 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 ab487bb0402afa9397db27662925caa5f4c326a2 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 b3ec263a719e0d499bd95d20012d90d7e8641655 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 0d60b835bca42f0f790689dd47819ed881a92ccc 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 68dc52f308a17c3103a349f722dd5dea32c50a88 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 8e644d9a8c8dc96b91ddacb89e3edbcd42d1259e 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 d50d320e88b4c558f0fca5f63e2dd32f647010f5 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 24186d6f9b07eaf61a8ae1ed984bb353c9952d18 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 6617df8c246311c82cebf061a4cee55b9df60922 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 231414253b648b3518b56f09710b831945d6a2fc 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 8b4d1854295b023f4ce2665200927de28ac35d6a 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 cc848a080f7a6848dfeef441722419fdcbfe9b8d 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 23b3d457d8387bcb2a61063a9e520063ada9335f 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 b83ecf80e28afb7b6595ba79932e77ca68a5a83d 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 8cd8cf3052fff9a4b86b25734f610e4af03786d3 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 a89a13aea38ae990f50287f490e494f8052828de 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 f9be514984471ff0003738b2e1efed12bc3433ff 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 8db6a2c95e36938076b37466ce36774526a5c8c3 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 647e8e69c6ea35b8ed3968617aa694f4df51ff33 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 7940e5c535489deaab3d831c192c089a17df98e0 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 0fc5b37faec26241d3cbee732e29ac35ad3184f8 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 2b69b61057eb0b3db9ad754ef0f1436b7af3a9f5 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 0d643a46fdea676afd408b6f81514288903c07e4 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 844b8525ce503405c462ad67f750bec648720397 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 9ada3931beb37068fcb725b34b0398457009f343 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 d3b642cf95d48234590cc91450d8705a9bf6b540 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 35a967ff8b24db09ee429c39c5b5e6571639997d 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 2ecd118fb6913584a4889a4a778aef5283bae579 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 c37095c431c39000ce818d3ff568a61b0e0ee02a 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 d354716245192de2d203f2b35f22ab8dc13595e2 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 03fd857c33456ef23761ce6732474550c37de7e2 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 d97a6b4a5a4fb30ebdabfe2c40ac9163c9428cd6 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 79982331c1738c84679f2b88a69ddb402292196f 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 19cb644d0ca5960be3e8c196e0c8a6da5f526ab9 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 bf58be93c51ba02fc05023257261f882175f5ead 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 aed8111f2392d70c64bb0a55b3daf70e0df598ff 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 0f64f808fb4ee55abc0ac2d983f80c6e49697a6e 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 1a9baac645769691ee0bf0fe6d7379257e8ee714 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 caf800e0cab945e02059f29c8829d1493b46991b 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 6b2c0cd5f9689dff51dc221d25fe28b393353e9a 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 2f33044aedd7aa314d026fa39a809cb4381c208c 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 ae7f5b05d225c85d425f8e8a43deafa41ee143b7 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 12e43f99242b0dbb213ab9ed074116658f1d2967 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 e0a71cbf0c1906a2eccbe69dd7d7f36fd1511d66 Author: Kuniyuki Iwashima Date: Wed Apr 15 18:48:29 2026 +0000 af_unix: Drop all SCM attributes for SOCKMAP. [ Upstream commit 965dc93481d1b80d341bdd16c27b16fe197175ee ] SOCKMAP can hide inflight fd from AF_UNIX GC. When a socket in SOCKMAP receives skb with inflight fd, sk_psock_verdict_data_ready() looks up the mapped socket and enqueue skb to its psock->ingress_skb. Since neither the old nor the new GC can inspect the psock queue, the hidden skb leaks the inflight sockets. Note that this cannot be detected via kmemleak because inflight sockets are linked to a global list. In addition, SOCKMAP redirect breaks the Tarjan-based GC's assumption that unix_edge.successor is always alive, which is no longer true once skb is redirected, resulting in use-after-free below. [0] Moreover, SOCKMAP does not call scm_stat_del() properly, so unix_show_fdinfo() could report an incorrect fd count. sk_msg_recvmsg() does not support any SCM attributes in the first place. Let's drop all SCM attributes before passing skb to the SOCKMAP layer. [0]: BUG: KASAN: slab-use-after-free in unix_del_edges (net/unix/garbage.c:118 net/unix/garbage.c:181 net/unix/garbage.c:251) Read of size 8 at addr ffff888125362670 by task kworker/56:1/496 CPU: 56 UID: 0 PID: 496 Comm: kworker/56:1 Not tainted 7.0.0-rc7-00263-gb9d8b856689d #3 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 Workqueue: events sk_psock_backlog Call Trace: dump_stack_lvl (lib/dump_stack.c:122) print_report (mm/kasan/report.c:379) kasan_report (mm/kasan/report.c:597) unix_del_edges (net/unix/garbage.c:118 net/unix/garbage.c:181 net/unix/garbage.c:251) unix_destroy_fpl (net/unix/garbage.c:317) unix_destruct_scm (./include/net/scm.h:80 ./include/net/scm.h:86 net/unix/af_unix.c:1976) sk_psock_backlog (./include/linux/skbuff.h:?) process_scheduled_works (kernel/workqueue.c:?) worker_thread (kernel/workqueue.c:?) kthread (kernel/kthread.c:438) ret_from_fork (arch/x86/kernel/process.c:164) ret_from_fork_asm (arch/x86/entry/entry_64.S:258) Allocated by task 955: kasan_save_track (mm/kasan/common.c:58 mm/kasan/common.c:78) __kasan_slab_alloc (mm/kasan/common.c:369) kmem_cache_alloc_noprof (mm/slub.c:4539) sk_prot_alloc (net/core/sock.c:2240) sk_alloc (net/core/sock.c:2301) unix_create1 (net/unix/af_unix.c:1099) unix_create (net/unix/af_unix.c:1169) __sock_create (net/socket.c:1606) __sys_socketpair (net/socket.c:1811) __x64_sys_socketpair (net/socket.c:1863 net/socket.c:1860 net/socket.c:1860) do_syscall_64 (arch/x86/entry/syscall_64.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Freed by task 496: kasan_save_track (mm/kasan/common.c:58 mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:587) __kasan_slab_free (mm/kasan/common.c:287) kmem_cache_free (mm/slub.c:6165) __sk_destruct (net/core/sock.c:2282 net/core/sock.c:2384) sk_psock_destroy (./include/net/sock.h:?) process_scheduled_works (kernel/workqueue.c:?) worker_thread (kernel/workqueue.c:?) kthread (kernel/kthread.c:438) ret_from_fork (arch/x86/kernel/process.c:164) ret_from_fork_asm (arch/x86/entry/entry_64.S:258) Fixes: c63829182c37 ("af_unix: Implement ->psock_update_sk_prot()") Fixes: 77462de14a43 ("af_unix: Add read_sock for stream socket types") Reported-by: Xingyu Jin Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260415184830.3988432-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9b6c12e1a6be033fa79880d85edde41908b68d12 Author: Vasant Hegde Date: Mon Apr 20 08:42:04 2026 +0000 iommu/amd: Use maximum PPR log buffer size when SNP is enabled on Family 0x19 [ Upstream commit 1f44aab79bac31f459422dfb213e907bb386509c ] Due to CVE-2023-20585, the PPR log buffer must use the maximum supported size (512K) on Genoa (Family 0x19, model >= 0x10) systems when SNP is enabled, to mitigate a potential security vulnerability. Note that Family 0x19 models below 0x10 (Milan) do not support PPR when SNP is enabled. Hence the PPR log size increase is only applied for model >= 0x10. All other systems continue to use the default PPR log buffer size (8K). Apply the errata fix by making the following changes: - Introduce global new variable (amd_iommu_pprlog_size) to have PPR log buffer size. Adjust variable size for Genoa family. - Extend 'amd_iommu_apply_erratum_snp()' to also set the PPR log buffer size to maximum for Family 0x19 model >= 0x10 when SNP is enabled. - Rename PPR_* macros to make it more readable. Link: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3016.html Cc: Borislav Petkov Cc: Suravee Suthikulpanit Cc: Joerg Roedel Signed-off-by: Vasant Hegde Tested-by: Dheeraj Kumar Srivastava Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit a4fb0954f3dc2e893fa87653327f16bc517f3822 Author: Vasant Hegde Date: Mon Apr 20 08:42:03 2026 +0000 iommu/amd: Use maximum Event log buffer size when SNP is enabled on Family 0x19 [ Upstream commit 58c0ac6125d89bf6ec65a521eaeb52a0e8e20a9f ] Due to CVE-2023-20585, the Event log buffer must use the maximum supported size (512K) on Milan/Genoa (Family 0x19) systems when SNP is enabled, to mitigate a potential security vulnerability. All other systems continue to use the default Event log buffer size (8K). Apply the errata fix by making the following changes: * Introduce new global variable (amd_iommu_evtlog_size) to have event log buffer size. Adjust variable size for family 0x19. * Since 'iommu_snp_enable()' must be called after the core IOMMU subsystem is initialized, it cannot be moved to the early init stage. The SNP errata must also be applied after the 'iommu_snp_enable()' check. Therefore, 'alloc_event_buffer()' and 'iommu_enable_event_buffer()' are now called in the IOMMU_ENABLED state, after the errata is applied. * Adjust alloc_event_buffer() and iommu_enable_event_buffer() to handle all IOMMU instances. * Also rename EVT_* macros to make it more readable. Link: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3016.html Cc: Borislav Petkov Cc: Suravee Suthikulpanit Cc: Joerg Roedel Signed-off-by: Vasant Hegde Tested-by: Dheeraj Kumar Srivastava Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 62dde71ca2c8cfe74d7d01699bb14b81b8d4afb4 Author: Rochan Avlur Date: Thu Jul 16 09:51:27 2026 -0700 exfat: preserve benign secondary entries during rename and move [ Upstream commit 942296784b2a9439651750c42f540bf2579b330f ] Commit 8258ef28001a ("exfat: handle unreconized benign secondary entries") added cluster freeing for benign secondary entries inside exfat_remove_entries(). However, exfat_remove_entries() is also called from the rename and move paths (exfat_rename_file and exfat_move_file), where the old entry set is being relocated rather than deleted. This causes benign secondary entries such as vendor extension entries to be silently destroyed on rename or cross-directory move, violating the exFAT spec requirement (section 8.2) that implementations preserve unrecognized benign secondary entries. Fix this by adding a free_benign parameter to exfat_remove_entries() so callers can suppress cluster freeing during relocation, and extending exfat_init_ext_entry() to copy trailing benign secondary entries from the old entry set into the new one internally. Also clean up the error paths to delete newly allocated entries on failure. Fixes: 8258ef28001a ("exfat: handle unreconized benign secondary entries") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-fsdevel/CAG7tbBV--waov7XVu2FHQEc6paR92dufS=em9DW5Kzsrpu3iQg@mail.gmail.com/ Signed-off-by: Rochan Avlur Reviewed-by: Yuezhang Mo Signed-off-by: Namjae Jeon Signed-off-by: Rochan Avlur Signed-off-by: Sasha Levin commit f3a0dd2d88e837abe3301c6c00472c5876ae82c9 Author: Daniel Borkmann Date: Fri Jul 17 12:47:29 2026 +0800 selftests/bpf: Add tests for stale delta leaking through id reassignment commit cac16ce1e3786bd98cec0c108e3bc06ed3d3c6a9 upstream. Extend the verifier_linked_scalars BPF selftest with a stale delta test such that the div-by-zero path is rejected in the fixed case. # LDLIBS=-static PKG_CONFIG='pkg-config --static' ./vmtest.sh -- ./test_progs -t verifier_linked_scalars [...] ./test_progs -t verifier_linked_scalars #612/1 verifier_linked_scalars/scalars: find linked scalars:OK #612/2 verifier_linked_scalars/sync_linked_regs_preserves_id:OK #612/3 verifier_linked_scalars/scalars_neg:OK #612/4 verifier_linked_scalars/scalars_neg_sub:OK #612/5 verifier_linked_scalars/scalars_neg_alu32_add:OK #612/6 verifier_linked_scalars/scalars_neg_alu32_sub:OK #612/7 verifier_linked_scalars/scalars_pos:OK #612/8 verifier_linked_scalars/scalars_sub_neg_imm:OK #612/9 verifier_linked_scalars/scalars_double_add:OK #612/10 verifier_linked_scalars/scalars_sync_delta_overflow:OK #612/11 verifier_linked_scalars/scalars_sync_delta_overflow_large_range:OK #612/12 verifier_linked_scalars/scalars_alu32_big_offset:OK #612/13 verifier_linked_scalars/scalars_alu32_basic:OK #612/14 verifier_linked_scalars/scalars_alu32_wrap:OK #612/15 verifier_linked_scalars/scalars_alu32_zext_linked_reg:OK #612/16 verifier_linked_scalars/scalars_alu32_alu64_cross_type:OK #612/17 verifier_linked_scalars/scalars_alu32_alu64_regsafe_pruning:OK #612/18 verifier_linked_scalars/alu32_negative_offset:OK #612/19 verifier_linked_scalars/spurious_precision_marks:OK #612/20 verifier_linked_scalars/scalars_self_add_clears_id:OK #612/21 verifier_linked_scalars/scalars_self_add_alu32_clears_id:OK #612/22 verifier_linked_scalars/scalars_stale_delta_from_cleared_id:OK #612/23 verifier_linked_scalars/scalars_stale_delta_from_cleared_id_alu32:OK #612 verifier_linked_scalars:OK Summary: 1/23 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260407192421.508817-4-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Shung-Hsi Yu Signed-off-by: Sasha Levin commit 985b8a0e52c5828450cc478d2198c1dacc21f40d Author: Daniel Borkmann Date: Fri Jul 17 12:47:28 2026 +0800 selftests/bpf: Add tests for delta tracking when src_reg == dst_reg commit ed2eecdc0c6613353bc1565e900d2b23237713da upstream. Extend the verifier_linked_scalars BPF selftest with a rX += rX test such that the div-by-zero path is rejected in the fixed case. # LDLIBS=-static PKG_CONFIG='pkg-config --static' ./vmtest.sh -- ./test_progs -t verifier_linked_scalars [...] ./test_progs -t verifier_linked_scalars #612/1 verifier_linked_scalars/scalars: find linked scalars:OK #612/2 verifier_linked_scalars/sync_linked_regs_preserves_id:OK #612/3 verifier_linked_scalars/scalars_neg:OK #612/4 verifier_linked_scalars/scalars_neg_sub:OK #612/5 verifier_linked_scalars/scalars_neg_alu32_add:OK #612/6 verifier_linked_scalars/scalars_neg_alu32_sub:OK #612/7 verifier_linked_scalars/scalars_pos:OK #612/8 verifier_linked_scalars/scalars_sub_neg_imm:OK #612/9 verifier_linked_scalars/scalars_double_add:OK #612/10 verifier_linked_scalars/scalars_sync_delta_overflow:OK #612/11 verifier_linked_scalars/scalars_sync_delta_overflow_large_range:OK #612/12 verifier_linked_scalars/scalars_alu32_big_offset:OK #612/13 verifier_linked_scalars/scalars_alu32_basic:OK #612/14 verifier_linked_scalars/scalars_alu32_wrap:OK #612/15 verifier_linked_scalars/scalars_alu32_zext_linked_reg:OK #612/16 verifier_linked_scalars/scalars_alu32_alu64_cross_type:OK #612/17 verifier_linked_scalars/scalars_alu32_alu64_regsafe_pruning:OK #612/18 verifier_linked_scalars/alu32_negative_offset:OK #612/19 verifier_linked_scalars/spurious_precision_marks:OK #612/20 verifier_linked_scalars/scalars_self_add_clears_id:OK #612/21 verifier_linked_scalars/scalars_self_add_alu32_clears_id:OK #612 verifier_linked_scalars:OK Summary: 1/21 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260407192421.508817-3-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov [shung-hsi.yu: missing context from commit 223ffb6a3d05 ("selftests/bpf: add reproducer for spurious precision propagation through calls").] Signed-off-by: Shung-Hsi Yu Signed-off-by: Sasha Levin commit d75376fbc8563f63a584014e73f4e6d8086fc7ab Author: Daniel Borkmann Date: Fri Jul 17 12:47:27 2026 +0800 bpf: Clear delta when clearing reg id for non-{add,sub} ops commit 1b327732c84640c1e3da487eefe9d00cc9f2dd34 upstream. When a non-{add,sub} alu op such as xor is performed on a scalar register that previously had a BPF_ADD_CONST delta, the else path in adjust_reg_min_max_vals() only clears dst_reg->id but leaves dst_reg->delta unchanged. This stale delta can propagate via assign_scalar_id_before_mov() when the register is later used in a mov. It gets a fresh id but keeps the stale delta from the old (now-cleared) BPF_ADD_CONST. This stale delta can later propagate leading to a verifier-vs- runtime value mismatch. The clear_id label already correctly clears both delta and id. Make the else path consistent by also zeroing the delta when id is cleared. More generally, this introduces a helper clear_scalar_id() which internally takes care of zeroing. There are various other locations in the verifier where only the id is cleared. By using the helper we catch all current and future locations. Fixes: 98d7ca374ba4 ("bpf: Track delta between "linked" registers.") Reported-by: STAR Labs SG Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260407192421.508817-2-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov [shung-hsi.yu: `delta` field was called `off` before commit 3d91c618aca4 ("bpf: rename bpf_reg_state->off to bpf_reg_state->delta"), and clear_singular_ids() does not exists before commit b2a0aa3a8739 ("bpf: Clear singular ids for scalars in is_state_visited()")] Signed-off-by: Shung-Hsi Yu Signed-off-by: Sasha Levin commit 19836e8145de96c7cc77a2ee69983e1079bcdaa1 Author: Daniel Borkmann Date: Fri Jul 17 12:47:26 2026 +0800 selftests/bpf: Add a test cases for sync_linked_regs regarding zext propagation commit 4a04d13576fd69149b91672b5f1dc62eca272fa5 upstream. Add multiple test cases for linked register tracking with alu32 ops: - Add a test that checks sync_linked_regs() regarding reg->id (the linked target register) for BPF_ADD_CONST32 rather than known_reg->id (the branch register). - Add a test case for linked register tracking that exposes the cross-type sync_linked_regs() bug. One register uses alu32 (w7 += 1, BPF_ADD_CONST32) and another uses alu64 (r8 += 2, BPF_ADD_CONST64), both linked to the same base register. - Add a test case that exercises regsafe() path pruning when two execution paths reach the same program point with linked registers carrying different ADD_CONST flags (BPF_ADD_CONST32 from alu32 vs BPF_ADD_CONST64 from alu64). This particular test passes with and without the fix since the pruning will fail due to different ranges, but it would still be useful to carry this one as a regression test for the unreachable div by zero. With the fix applied all the tests pass: # LDLIBS=-static PKG_CONFIG='pkg-config --static' ./vmtest.sh -- ./test_progs -t verifier_linked_scalars [...] ./test_progs -t verifier_linked_scalars #602/1 verifier_linked_scalars/scalars: find linked scalars:OK #602/2 verifier_linked_scalars/sync_linked_regs_preserves_id:OK #602/3 verifier_linked_scalars/scalars_neg:OK #602/4 verifier_linked_scalars/scalars_neg_sub:OK #602/5 verifier_linked_scalars/scalars_neg_alu32_add:OK #602/6 verifier_linked_scalars/scalars_neg_alu32_sub:OK #602/7 verifier_linked_scalars/scalars_pos:OK #602/8 verifier_linked_scalars/scalars_sub_neg_imm:OK #602/9 verifier_linked_scalars/scalars_double_add:OK #602/10 verifier_linked_scalars/scalars_sync_delta_overflow:OK #602/11 verifier_linked_scalars/scalars_sync_delta_overflow_large_range:OK #602/12 verifier_linked_scalars/scalars_alu32_big_offset:OK #602/13 verifier_linked_scalars/scalars_alu32_basic:OK #602/14 verifier_linked_scalars/scalars_alu32_wrap:OK #602/15 verifier_linked_scalars/scalars_alu32_zext_linked_reg:OK #602/16 verifier_linked_scalars/scalars_alu32_alu64_cross_type:OK #602/17 verifier_linked_scalars/scalars_alu32_alu64_regsafe_pruning:OK #602/18 verifier_linked_scalars/alu32_negative_offset:OK #602/19 verifier_linked_scalars/spurious_precision_marks:OK #602 verifier_linked_scalars:OK Summary: 1/19 PASSED, 0 SKIPPED, 0 FAILED Co-developed-by: Puranjay Mohan Signed-off-by: Puranjay Mohan Signed-off-by: Daniel Borkmann Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260319211507.213816-2-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Shung-Hsi Yu Signed-off-by: Sasha Levin commit 07259d661c9d43205f7a7f20f4328b2a2a6f0533 Author: Puranjay Mohan Date: Fri Jul 17 12:47:25 2026 +0800 selftests/bpf: Add tests for improved linked register tracking commit 47fcf4dc0a346dd0b873a679c547d6848bd85a37 upstream. Add tests for linked register tracking with negative offsets, BPF_SUB, and alu32. These test for all edge cases like overflows, etc. Signed-off-by: Puranjay Mohan Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260204151741.2678118-3-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Shung-Hsi Yu Signed-off-by: Sasha Levin commit 564e4ce9fb4011531f64f8986951e43c42852456 Author: Puranjay Mohan Date: Fri Jul 17 12:47:24 2026 +0800 selftests: bpf: Add test for multiple syncs from linked register commit 086c99fbe45070d02851427eab5ae26fe7d0f3c0 upstream. Before the last commit, sync_linked_regs() corrupted the register whose bounds are being updated by copying known_reg's id to it. The ids are the same in value but known_reg has the BPF_ADD_CONST flag which is wrongly copied to reg. This later causes issues when creating new links to this reg. assign_scalar_id_before_mov() sees this BPF_ADD_CONST and gives a new id to this register and breaks the old links. This is exposed by the added selftest. Signed-off-by: Puranjay Mohan Tested-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260115151143.1344724-3-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Shung-Hsi Yu Signed-off-by: Sasha Levin commit 3659deaf7bf690510899a73906b772740d94342c 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 c401492e01c7bfd38cf14c94d85c7efafe7d1a25 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 088ee46c18d99baef453afd74181dd40ade044ad Author: Sagi Grimberg Date: Sun May 10 23:30:29 2026 +0300 nvmet-tcp: Fix potential UAF when ddgst mismatch commit dbbd07d0a7020b80f6a7028e561908f7b83b3d5a upstream. Shivam Kumar found via vulnerability testing: When data digest is enabled on an NVMe/TCP connection and a digest mismatch occurs on a non-final H2C_DATA PDU during an R2T-based data transfer, the digest error handler in nvmet_tcp_try_recv_ddgst() calls nvmet_req_uninit() — which performs percpu_ref_put() on the submission queue — but does NOT mark the command as completed. It does not set cqe->status, does not modify rbytes_done, and does not clear any flag. When the subsequent fatal error triggers queue teardown, nvmet_tcp_uninit_data_in_cmds() iterates all commands, checks nvmet_tcp_need_data_in() for each one, and finds that the already-uninited command still appears to need data (because rbytes_done < transfer_len and cqe->status == 0). It therefore calls nvmet_req_uninit() a second time on the same command — a double percpu_ref_put against a single percpu_ref_get. Reported-by: Shivam Kumar Reviewed-by: Christoph Hellwig Signed-off-by: Sagi Grimberg Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 2ed3c9d955e8cd6361f130623baa664a75fb345f Author: Shivam Kumar Date: Wed Mar 18 18:56:58 2026 -0400 nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error path commit 4606467a75cfc16721937272ed29462a750b60c8 upstream. In nvmet_tcp_try_recv_ddgst(), when a data digest mismatch is detected, nvmet_req_uninit() is called unconditionally. However, if the command arrived via the nvmet_tcp_handle_req_failure() path, nvmet_req_init() had returned false and percpu_ref_tryget_live() was never executed. The unconditional percpu_ref_put() inside nvmet_req_uninit() then causes a refcount underflow, leading to a WARNING in percpu_ref_switch_to_atomic_rcu, a use-after-free diagnostic, and eventually a permanent workqueue deadlock. Check cmd->flags & NVMET_TCP_F_INIT_FAILED before calling nvmet_req_uninit(), matching the existing pattern in nvmet_tcp_execute_request(). Reviewed-by: Christoph Hellwig Signed-off-by: Shivam Kumar Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 588718101e8449605f1c7e858fecb7cfa701cdab 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 c646431865f4b1a5b14067233fa27b11e05e0d46 Author: Hyunwoo Kim Date: Thu Jul 16 14:24:34 2026 +0100 KVM: arm64: Bound used_lrs when flushing the pKVM hyp vCPU commit 8cc8bbbfab14c22c5551d0dd19b208a44b141c76 upstream. flush_hyp_vcpu() copies the host vGIC state into the hyp's private vCPU on every run. The vGIC list register save and restore use used_lrs as their loop bound and expect it to stay within the number of implemented list registers. While this is generally the case, flush_hyp_vcpu() copies vgic_v3 verbatim and does not enforce this, so a value provided by the host is used at EL2 to index vgic_lr[] and access ICH_LR_EL2 (host -> EL2). Fix by clamping used_lrs to the number of implemented list registers after the copy, as the trusted path already does in vgic_flush_lr_state(). The number of implemented list registers is constant after init, so it is replicated once from kvm_vgic_global_state.nr_lr into hyp_gicv3_nr_lr rather than read on every entry. Cc: stable@vger.kernel.org Fixes: be66e67f1750 ("KVM: arm64: Use the pKVM hyp vCPU structure in handle___kvm_vcpu_run()") Signed-off-by: Hyunwoo Kim Reviewed-by: Fuad Tabba Tested-by: Fuad Tabba Link: https://patch.msgid.link/20260606175614.83273-3-imv4bel@gmail.com Signed-off-by: Marc Zyngier [ tabba: adjust context in flush_hyp_vcpu() and kvm_hyp.h ] Signed-off-by: Fuad Tabba Signed-off-by: Sasha Levin commit d7860b682da55433b5da0591b0e4c1982ecd2689 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 commit de5a46f3b2c8d3cd20afa158bd3a725e3e3d6fd3 Author: Kuniyuki Iwashima Date: Wed Jul 15 14:07:04 2026 +0200 tcp: Add preempt_{disable,enable}_nested() in reqsk_queue_hash_req(). [ Upstream commit e10902df24488ca722303133acfc82490f7d59ad ] syzbot reported a weird reqsk->rsk_refcnt underflow in __inet_csk_reqsk_queue_drop(). The captured reqsk_put() in __inet_csk_reqsk_queue_drop() is called only when it successfully removes reqsk from ehash. Moreover, reqsk_timer_handler() calls another reqsk_put() after that. This indicates that the reqsk was missing both refcnts for ehash and the timer itself. Since all the syzbot reports had PREEMPT_RT enabled, the only possible scenario is that reqsk_queue_hash_req() is preempted after mod_timer() and before refcount_set(), and then the timer triggered after 1s aborts the reqsk due to its listener's close(). Let's wrap mod_timer() and refcount_set() with preempt_disable_nested() and preempt_enable_nested(). Note that inet_ehash_insert() holds the normal spin_lock() (mutex in PREEMPT_RT), so it must be called outside of preempt_disable_nested(), but this is fine. The lookup path just ignores 0 sk_refcnt entries in ehash and tries to create another reqsk, but this will fail at inet_ehash_insert(). [0]: refcount_t: underflow; use-after-free. WARNING: lib/refcount.c:28 at refcount_warn_saturate+0xb2/0x110 lib/refcount.c:28, CPU#0: ktimers/0/16 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ktimers/0 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)} Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 RIP: 0010:refcount_warn_saturate+0xb2/0x110 lib/refcount.c:28 Code: e4 7d d1 0a 67 48 0f b9 3a eb 4a e8 38 3d 23 fd 48 8d 3d e1 7d d1 0a 67 48 0f b9 3a eb 37 e8 25 3d 23 fd 48 8d 3d de 7d d1 0a <67> 48 0f b9 3a eb 24 e8 12 3d 23 fd 48 8d 3d db 7d d1 0a 67 48 0f RSP: 0000:ffffc90000157948 EFLAGS: 00010246 RAX: ffffffff84a1301b RBX: 0000000000000003 RCX: ffff88801ca98000 RDX: 0000000000000100 RSI: 0000000000000000 RDI: ffffffff8f72ae00 RBP: ffffffff99ae3b01 R08: ffff88801ca98000 R09: 0000000000000005 R10: 0000000000000100 R11: 0000000000000004 R12: ffff8880425ef568 R13: ffff8880425ef4f8 R14: ffff8880425ef578 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff888126386000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7b46710e9c CR3: 000000000dbb6000 CR4: 00000000003526f0 Call Trace: __refcount_sub_and_test include/linux/refcount.h:400 [inline] __refcount_dec_and_test include/linux/refcount.h:432 [inline] refcount_dec_and_test include/linux/refcount.h:450 [inline] reqsk_put include/net/request_sock.h:136 [inline] __inet_csk_reqsk_queue_drop+0x3ce/0x440 net/ipv4/inet_connection_sock.c:1007 reqsk_timer_handler+0x651/0xdf0 net/ipv4/inet_connection_sock.c:1137 call_timer_fn+0x192/0x5e0 kernel/time/timer.c:1748 expire_timers kernel/time/timer.c:1799 [inline] __run_timers kernel/time/timer.c:2374 [inline] __run_timer_base+0x6a3/0x9f0 kernel/time/timer.c:2386 run_timer_base kernel/time/timer.c:2395 [inline] run_timer_softirq+0x67/0x170 kernel/time/timer.c:2403 handle_softirqs+0x1de/0x6d0 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0x69/0x100 kernel/softirq.c:1151 smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c:160 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: d2d6422f8bd1 ("x86: Allow to enable PREEMPT_RT.") Reported-by: syzbot+e809069bc15f26300526@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6a1a7bcf.0a9e871e.332604.000b.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Reviewed-by: Sebastian Andrzej Siewior Link: https://patch.msgid.link/20260601182101.3183993-1-kuniyu@google.com Signed-off-by: Jakub Kicinski [updated to not require timeout changes from commit 3ce5dd8161ec ("tcp: Remove timeout arg from reqsk_queue_hash_req()") DCCP was retired by commit 2a63dd0edf38 ("net: Retire DCCP socket.") after the release of 6.12, so the shared inet_csk_reqsk_queue_hash_add still requires the timout argument] Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit e0caf7c3d49c72f0f9036359e9d5478ae95c930c Author: ChenXiaoSong Date: Sun Jun 28 07:42:43 2026 +0000 smb/server: do not require delete access for non-replacing links [ Upstream commit 851ed9e09639e0daf79a506ce26097b296ed5518 ] Reproducer: 1. server: systemctl start ksmbd 2. client: mount -t cifs //${server_ip}/export /mnt 3. client: touch /mnt/file; ln /mnt/file /mnt/hardlink 4. client err log: ln: failed to create hard link 'hardlink' => 'file': Permission denied 5. server err log: ksmbd: no right to delete : 0x80 Fixes: 13f3942f2bf4 ("ksmbd: add per-handle permission check to FILE_LINK_INFORMATION") Cc: stable@vger.kernel.org Reported-by: Steve French Signed-off-by: ChenXiaoSong Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit bbf04810b2a0672c8bcfede41b5ba0391ec69f0b Author: Roger Pau Monne Date: Tue Jul 14 22:13:42 2026 +0200 nvme-pci: DMA unmap the correct regions in nvme_free_sgls commit a54afbc8a2138f8c2490510cf26cde188d480c43 upstream. The call to nvme_free_sgls() in nvme_unmap_data() has the sg_list and sge parameters swapped. This wasn't noticed by the compiler because both share the same type. On a Xen PV hardware domain, and possibly any other architectures that takes that path, this leads to corruption of the NVMe contents. Fixes: f0887e2a52d4 ("nvme-pci: create common sgl unmapping helper") Reviewed-by: Christoph Hellwig Signed-off-by: Roger Pau Monné Signed-off-by: Keith Busch [nb: drop the attrs parameter added in 6.19 by commit 61d43b1731e0 ("nvme-pci: migrate to dma_map_phys instead of map_page"), which is not in 6.18.y] Signed-off-by: Nicolai Buchwitz Signed-off-by: Sasha Levin commit 40e44eff5116d49b9c5ebab9854a0e2aa377b676 Author: Arnaldo Carvalho de Melo Date: Tue Jan 20 17:57:43 2026 -0300 perf trace: Deal with compiler const checks commit 2c850606a46b319d5128bda59f67b1fc642d94ef upstream. The strchr() function these days return const/non-const based on the arg it receives, and sometimes we need to use casts when we're dealing with variables that are used in code that needs to safely change the returned value and sometimes not (as it points to really const areas). Tweak one such case. Reviewed-by: Ian Rogers Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 30bbd7e8999d1275cd457f820aa2717c514ac405 Author: Arnaldo Carvalho de Melo Date: Thu Dec 11 19:17:56 2025 -0300 perf trace: Don't change const char strings commit c85eff00cf296c146a2b189166eaf85188cd1487 upstream. We got away with this so far but now with fedora 44 complaining about the return value of strchr et all, lets use strdup for good measure. Reviewed-by: Ian Rogers Link: https://lore.kernel.org/r/20251211221756.96294-5-acme@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit bc29e0699b35deca0c3ec20d6ae995095231c2b4 Author: Arnaldo Carvalho de Melo Date: Thu Dec 11 19:17:54 2025 -0300 perf diff: Constify strchr() return variables commit f6f41aef53761517391b6192fe5b4bc30b2d717a upstream. Newer glibc versions return const char for strchr() when the 's' arg is const, change the return variable to const to match that. Also we don't need to turn that ',' into a '\0', as strtol() will stop in the first invalid char. No need to touch read only memory. First noticed with fedora 44. Reviewed-by: Ian Rogers Link: https://lore.kernel.org/r/20251211221756.96294-3-acme@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 292f32503eda369ee316e1069251dc85eca0301a Author: Arnaldo Carvalho de Melo Date: Tue Jan 20 18:16:09 2026 -0300 perf list: Don't write to const memory commit 29132d16965e66fed0bf7b38242e7e57df294ba0 upstream. Something now detected on fedora 44, where strchr() returns const if it is passed a const pointer: util/print-events.c: In function 'print_sdt_events': util/print-events.c:89:29: error: initialization discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers] 89 | char *bid = strchr(sdt_name->s, '@'); | ^~~~~~ Fix it by using strchrnul() + strncmp() instead of temporarily scrubbing it with '\0'. Reviewed-by: Ian Rogers Suggested-by: David Laight Link: https://lore.kernel.org/r/20260121112536.27fd5d11@pumpkin Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit d03adc7039c393678a1b7156cbc6d64a9b1ca0ee Author: Arnaldo Carvalho de Melo Date: Tue Jan 20 18:26:44 2026 -0300 perf list: Signal changing const memory is ok commit 9a0a5b5ac4372da84394dc329f763d6b7d384a86 upstream. In this case its a temp list that is created just for listing events and will be deleted at the end, so just cast it to get rid of the compiler warning. Reviewed-by: Ian Rogers Signed-off-by: Arnaldo Carvalho de Melo [ Also do it for print_symbol_events() - gregkh ] Signed-off-by: Greg Kroah-Hartman commit 4283a813d7089f8a28162995d779eae26f918067 Author: Arnaldo Carvalho de Melo Date: Tue Jan 27 02:22:00 2026 -0300 perf tp_pmu: Address const-correctness errors in recent glibcs commit 0341eab66ba03a1f439db91f03bccd5b0a360842 upstream. To avoid having more variables, just cast the const variable searched to non-const since the result will not be modified, its only later that that variable will be used to modify something, but then its non-const memory being modified, so using a cast is the cheapest thing here. Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 018533cfe83cff6fff8a5bdec39139a02fcd78d3 Author: Arnaldo Carvalho de Melo Date: Tue Jan 27 01:15:47 2026 -0300 perf units: Constify variables storing the result of strchr() on const tables commit 0e14cb3b24f8f301cf6490a4493afc98321ed5bb upstream. As newer glibcs will propagate the const attribute of the searched table to its return. Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit e7d3f92238a3d0535fa7c559914f40ef06ba146f Author: Arnaldo Carvalho de Melo Date: Tue Jan 27 02:15:30 2026 -0300 perf hwmon_pmu: Constify the variables returning bsearch() on const tables commit 0e47251e8cc438d5b59fcd86d27efade01976fe1 upstream. To address const-correctness errors on newer glibcs (-Werror=discarded-qualifiers). Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 5bcff7ce5c3b15938f5316c13b1f88e174cf3cab Author: Arnaldo Carvalho de Melo Date: Thu Dec 11 19:17:55 2025 -0300 perf tools: Use const for variables receiving str{str,r?chr}() returns commit 45718bce7daf39c618188b70a52644bb5a2f968a upstream. Newer glibc versions return const char for str{str,chr}() where the haystack/s is const so to avoid warnings like these on fedora 44 change some variables to const: 36 8.17 fedora:44 : FAIL gcc version 15.2.1 20251111 (Red Hat 15.2.1-4) (GCC) libbpf.c: In function 'kallsyms_cb': libbpf.c:8489:13: error: assignment discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers] 8489 | res = strstr(sym_name, ".llvm."); Reviewed-by: Ian Rogers Link: https://lore.kernel.org/r/20251211221756.96294-4-acme@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit ee8ab4e8e7029ddb058ddccc758ab1e85b77f9c4 Author: Arnaldo Carvalho de Melo Date: Tue Jan 27 01:15:47 2026 -0300 perf metricgroup: Constify variables storing the result of strchr() on const tables commit b42868624c7d00206f77d19a6fbfea73a44ff6f2 upstream. As newer glibcs will propagate the const attribute of the searched table to its return. Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 8bac35a8fd98fe284632c1a6049cb4b0a12c80bb Author: Arnaldo Carvalho de Melo Date: Tue Jan 27 01:15:47 2026 -0300 perf trace-event: Constify variables storing the result of strchr() on const tables commit 97b81df7225830c4db3c17ed1235d2f3eb613d3d upstream. As newer glibcs will propagate the const attribute of the searched table to its return. Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit a816153dd85754887dea979c1309e5a96a6ee691 Author: Arnaldo Carvalho de Melo Date: Tue Jan 27 01:15:47 2026 -0300 perf demangle-java: Constify variables storing the result of strchr() on const tables commit 79bba3a1834e7ba6c437674582cc9f3ae6fb638c upstream. As newer glibcs will propagate the const attribute of the searched table to its return. Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit f8cb25b1d5ed2b7c8f5c36446c7f7757e4b45b96 Author: Arnaldo Carvalho de Melo Date: Tue Jan 27 02:09:37 2026 -0300 perf session: Don't write to memory pointed to a const pointer commit f1321cce848c558fde4c0c6bcd5e53f3cefd3af2 upstream. Since it is freshly allocated just attribute it to a non-const pointer and then change it via that pointer. That way we avoid const-correctness warnings in recent glibc versions. Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 5f6d997641de9892f54c4e12dd6a3a47462f8df4 Author: Arnaldo Carvalho de Melo Date: Tue Jan 27 01:15:47 2026 -0300 perf bpf-event: Constify variables storing the result of strchr() on const tables commit 8bf093acb3f1f07d846c86e32308f9f9954ed579 upstream. As newer glibcs will propagate the const attribute of the searched table to its return. Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 3b540ba9606bf87148c6f5989598dd534147fe40 Author: Ian Rogers Date: Wed Nov 19 15:36:21 2025 -0800 perf tools: Switch printf("...%s", strerror(errno)) to printf("...%m") commit bac74dcbd48b5b441e47841fd0fe507c7b0bcbaf upstream. strerror() has thread safety issues, strerror_r() requires stack allocated buffers. Code in perf has already been using the "%m" formatting flag that is a widely support glibc extension to print the current errno's description. Expand the usage of this formatting flag and remove usage of strerror()/strerror_r(). Signed-off-by: Ian Rogers Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Alexandre Ghiti Cc: Blake Jones Cc: Chun-Tse Shao Cc: Dmitriy Vyukov Cc: Dr. David Alan Gilbert Cc: Haibo Xu Cc: Howard Chu Cc: Ingo Molnar Cc: Jiri Olsa Cc: Leo Yan Cc: Peter Zijlstra Cc: Stephen Brennan Cc: Thomas Falcon Cc: Yunseong Kim Cc: Zhongqiu Han Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 659a56ba86a9694f6b5f33fcdcfc70f1579c13e3 Author: Arnaldo Carvalho de Melo Date: Thu Dec 11 19:17:53 2025 -0300 perf list: Remove unused 'sep' variable commit d311783bc68b011c77a4ef81321de2c94d7deffc upstream. It is just being set to the return of strchr() but never used, just ditch it and with it get rid of a warning about it not being const on fedora 44. Reviewed-by: Ian Rogers Link: https://lore.kernel.org/r/20251211221756.96294-2-acme@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 33250aa5cfade9bb7d4bdadc09b28788b85e7569 Author: Arnaldo Carvalho de Melo Date: Tue Jan 27 01:15:47 2026 -0300 perf jitdump: Constify variables storing the result of strchr() on const tables commit 68abacb0686651dd3f0bbce2fa94b438afeb2fc4 upstream. As newer glibcs will propagate the const attribute of the searched table to its return. Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 972c65697792ceca49db4dbd1776e3a486a1de76 Author: Arnaldo Carvalho de Melo Date: Tue Jan 27 01:15:47 2026 -0300 perf time-utils: Constify variables storing the result of strchr() on const tables commit 21c0bc9144834e39762dd6fddbb255ebb80cf079 upstream. As newer glibcs will propagate the const attribute of the searched table to its return. Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 9ae21594ee518158ce6f5c5de3c39614418fa8aa Author: Arnaldo Carvalho de Melo Date: Tue Jan 27 12:43:43 2026 -0300 perf strlist: Remove dont_dupstr logic, used only once commit 612e4022c616eba66ed15e6b7a9924251e0298e8 upstream. Ian Rogers noticed that 678ed6b707e4b2db ("perf strlist: Don't write to const memory") breaks the 'Remove thread map' 'perf test' entry, because it keeps pointers to the temporary string introduced to avoid touching the const memory. This is because the thread_map__new_by_[pt]id_str() were the only methods using the slist->dont_dupstr knob to keep pointers to the original const string list, as it uses strtol to parse numbers and it stops at the comma. As this is the only case of dont_dupstr use, dupstr being the default, and it gets in the way of getting rid of the last const-correctness, remove this knob, with it: $ perf test 37 37: Remove thread map : Ok $ Fixes: 678ed6b707e4b2db ("perf strlist: Don't write to const memory") Reported-by: Ian Rogers Tested-by: Ian Rogers Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 110ce8fed0f8e6efe42442d1b916723e69ca10fa Author: Arnaldo Carvalho de Melo Date: Tue Jan 27 02:03:01 2026 -0300 perf strlist: Don't write to const memory commit 678ed6b707e4b2db250f255d2f959322896dae65 upstream. Do a strdup to the list string and parse from it, free at the end. This is to deal with newer glibcs const-correctness. Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 27e97e5543909af9fabefa114b49339b8c5a659e Author: Alexandre Frade Date: Sat Jul 18 16:45:22 2026 +0000 Linux 6.18.39-xanmod1 Signed-off-by: Alexandre Frade commit a4b496b054d48ba8e1ac59e2c21a7b20030bb1c1 Merge: e67923a55781 f89c296854b7 Author: Alexandre Frade Date: Sat Jul 18 16:44:30 2026 +0000 Merge tag 'v6.18.39' into 6.18 This is the 6.18.39 stable release commit f89c296854b755a66657065c35b05406fc18264d Author: Greg Kroah-Hartman Date: Sat Jul 18 16:53:38 2026 +0200 Linux 6.18.39 Link: https://lore.kernel.org/r/20260716133044.672218725@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Florian Fainelli Tested-by: Peter Schneider Tested-by: Miguel Ojeda Tested-by: Ron Economos Tested-by: Wentao Guan Tested-by: Shuah Khan Tested-by: Pavel Machek (CIP) Link: https://lore.kernel.org/r/20260717101904.922623678@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Florian Fainelli Tested-by: Pavel Machek (CIP) Tested-by: Peter Schneider Tested-by: Mark Brown Tested-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 06b1729436efc1d2b3866b50825bece3d18355f8 Author: Darrick J. Wong Date: Mon Jul 13 23:05:10 2026 -0700 xfs: use rtrefcount btree cursor in xchk_xref_is_rt_cow_staging commit ee248157da501f0c02688fb64e5359f2832b0b01 upstream. LOLLM points out that we pass the wrong btree cursor here. We want the rtrefcount btree cursor, not the non-rt one. This is fairly benign since it only affects tracing data. Cc: stable@vger.kernel.org # v6.14 Fixes: 91683bb3f264c0 ("xfs: cross-reference checks with the rt refcount btree") Signed-off-by: "Darrick J. Wong" Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 457a93a233bd78ade8531d65b5a13d9727af9c85 Author: Darrick J. Wong Date: Mon Jul 13 23:05:41 2026 -0700 xfs: write the rg superblock when fixing it commit 9af789fa274bc14b907f811f79fa988a6fc6d4e7 upstream. The rtgroup superblock fixer should write the rtgroup superblock. LOLLM noticed this, oops. :/ Cc: stable@vger.kernel.org # v6.13 Fixes: 1433f8f9cead37 ("xfs: repair realtime group superblock") Signed-off-by: "Darrick J. Wong" Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit e696ef088f557d1c82b564f0d3a61bf568025412 Author: Darrick J. Wong Date: Mon Jul 13 23:06:28 2026 -0700 xfs: fix off-by-one error when calling xchk_xref_has_rt_owner commit 5d72a68f2007ba2a968d6bf47dba3f4620bd182e upstream. LOLLM noticed an off-by-one error when computing the length of the rtrmap to cross-check. Cc: stable@vger.kernel.org # v6.14 Fixes: 037a44d8277adf ("xfs: cross-reference the realtime rmapbt") Signed-off-by: "Darrick J. Wong" Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 6403ef9a81e6c27e9e77c1a4d8df29331c41089c Author: Darrick J. Wong Date: Mon Jul 13 23:07:30 2026 -0700 xfs: don't zap bmbt forks if they are MAXLEVELS tall commit 59c462b0f5cfa107794228051724b34ae9334168 upstream. LOLLM noticed a discrepancy between the bmbt level checks in the libxfs bmbt code vs. the inode repair code. We do actually allow a bmbt root that proclaims to have a height of XFS_BM_MAXLEVELS. Cc: stable@vger.kernel.org # v6.8 Fixes: e744cef2060559 ("xfs: zap broken inode forks") Signed-off-by: "Darrick J. Wong" Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 1ea0868a477b78d1b6a7ca043231ae6c0c5ea5cc Author: Darrick J. Wong Date: Mon Jul 13 23:06:59 2026 -0700 xfs: fully check the parent handle when it points to the rootdir commit ba150ce63453ccd74bae1404c1dfedbd01ecfd55 upstream. LOLLM noticed that the directory tree path checking declares the path to be ok if the inumber in the parent pointer reaches the root directory. Unfortunately, it neglects to check that the generation is correct. Fix that by moving the generation check up. Cc: stable@vger.kernel.org # v6.10 Fixes: 928b721a11789a ("xfs: teach online scrub to find directory tree structure problems") Signed-off-by: "Darrick J. Wong" Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit c9662ffd62c4e1b701a4076e9181732e3c09da37 Author: Darrick J. Wong Date: Mon Jul 13 23:07:15 2026 -0700 xfs: clamp timestamp nanoseconds correctly commit 15e38a9366b31d3d61081ead115f1dff59379e24 upstream. LOLLM noticed an off-by-one error in the nsec clamping; fix that so that we never have tv_nsec == 1e9. Cc: stable@vger.kernel.org # v6.8 Fixes: 2d295fe65776d1 ("xfs: repair inode records") Signed-off-by: "Darrick J. Wong" Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 424be21ed8cd4251f015f01fde8e4ec1bfc2e445 Author: Darrick J. Wong Date: Mon Jul 13 23:06:43 2026 -0700 xfs: handle non-inode owners for rtrmap record checking commit 353a5900bc85234e7df05caac37698042dc26348 upstream. LOLLM noticed that two helper functions in the rtrmapbt scrub code don't actually handle non-inode owners correctly -- CoW staging extents and rgsuperblock extents are not shareable, but they are mergeable. Fix these two helpers. Cc: stable@vger.kernel.org # v6.14 Fixes: 2d9a3e98053e8c ("xfs: allow overlapping rtrmapbt records for shared data extents") Signed-off-by: "Darrick J. Wong" Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit d399b026a6b34228bf6d8258acbf7bb6b8e17c56 Author: Darrick J. Wong Date: Mon Jul 13 23:06:12 2026 -0700 xfs: set xfarray killable sort correctly commit 540ddc626245f12f56326ee0c1601f71ebb41d64 upstream. LOLLM noticed that we *disable* interruptible sorts when the KILLABLE flag is set. This is backwards. Fix the incorrect logic, and rename the variable to make the connection more obvious. Cc: stable@vger.kernel.org # v6.10 Fixes: 271557de7cbfde ("xfs: reduce the rate of cond_resched calls inside scrub") Signed-off-by: "Darrick J. Wong" Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 08b191ae64659cc3c4006352827b78f0d48d1e33 Author: Darrick J. Wong Date: Mon Jul 13 23:05:26 2026 -0700 xfs: use the rt version of the cow staging checker commit 881f2eb0fcdea2f46a50fa6a892fe9e3ccf19e01 upstream. LOLLM also noticed that xchk_rtrmapbt_xref ought to be using the rtdev version of the "is this a cow extent?" helper function, not the datadev one. Cc: stable@vger.kernel.org # v6.14 Fixes: 91683bb3f264c0 ("xfs: cross-reference checks with the rt refcount btree") Signed-off-by: "Darrick J. Wong" Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 104584477883b0fdb220f2c2892907394453da43 Author: Darrick J. Wong Date: Mon Jul 13 23:05:57 2026 -0700 xfs: grab rtrmap btree when checking rgsuper commit ea6e2d9de25d2095845e0cdf2274e581fd40d636 upstream. LOLLM noticed that we aren't grabbing the rtrmap btree when we check the realtime group superblock. As a result, none of the cross-referencing checks have ever run. Fix this. Cc: stable@vger.kernel.org # v6.14 Fixes: 428e4884656db9 ("xfs: allow queued realtime intents to drain before scrubbing") Signed-off-by: "Darrick J. Wong" Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit d1c4c40599c376aeb0c93068a2ae344e79ee4b90 Author: Darrick J. Wong Date: Mon Jul 13 23:04:55 2026 -0700 xfs: don't wrap around quota ids in dqiterate commit d766e4e5e85d829629c3ba503802fe1303d7b591 upstream. LOLLM noticed that q_id is an unsigned 32-bit variable. If it happens to be set to XFS_DQ_ID_MAX due to a filesystem that actually has a dquot for ID_MAX, then this addition will truncate to zero and the iteration starts over. Fix this by casting to u64. Cc: stable@vger.kernel.org # v6.8 Fixes: 21d7500929c8a0 ("xfs: improve dquot iteration for scrub") Signed-off-by: "Darrick J. Wong" Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 206c09b04dc5469c7ff14d8aceff2d47c88078d9 Author: Darrick J. Wong Date: Mon Jul 13 23:03:44 2026 -0700 xfs: resample the data fork mapping after cycling ILOCK commit 2f4acd0fcd862e22eab45690ec2c08c80b6ef2e7 upstream. xfs_reflink_fill_{cow_hole,delalloc} are both presented with an inode, a data fork mapping, and a cow fork mapping. Unfortunately, these two helpers cycle the ILOCK to grab a transaction, which means that the mappings are stale as soon as we reacquire the ILOCK. Currently we refresh the cow fork mapping by re-calling xfs_find_trim_cow_extent, but we don't refresh the data fork mapping beforehand, which means that the xfs_bmap_trim_cow in that function queries the refcount btree about the wrong physical blocks and returns an inaccurate value in *shared. If *shared is now false, the directio write proceeds with a stale data fork mapping. Fix this by querying the data fork mapping if the sequence counter changes across the ILOCK cycle. Cc: hch@lst.de Cc: stable@vger.kernel.org # v4.11 Fixes: 3c68d44a2b49a0 ("xfs: allocate direct I/O COW blocks in iomap_begin") Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit d98f22d2e11e0a36493aeb25b2933571ee90d9a4 Author: Weiming Shi Date: Thu Jul 2 09:20:00 2026 -0700 xfs: fail recovery on a committed log item with no regions commit 2094dab19d45c487285617b7b68913d0cc0c1211 upstream. If the first op of a transaction is a bare transaction header (len == sizeof(struct xfs_trans_header)), xlog_recover_add_to_trans() adds an item but no region, leaving it on r_itemq with ri_cnt == 0 and ri_buf == NULL. The header can be split across op records, so later ops may still add regions; the item is only invalid if the transaction commits with none. The runtime commit path never emits such a transaction, so this only happens on a crafted log. It came from an AI-assisted code audit of the recovery parser. xlog_recover_reorder_trans() calls ITEM_TYPE() on the item, which reads *(unsigned short *)item->ri_buf[0].iov_base and faults on the NULL ri_buf. Reject it there, before the commit handlers that also read ri_buf[0]. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:xlog_recover_reorder_trans (fs/xfs/xfs_log_recover.c:1836) xlog_recover_commit_trans (fs/xfs/xfs_log_recover.c:2043) xlog_recover_process_data (fs/xfs/xfs_log_recover.c:2501) xlog_do_recovery_pass (fs/xfs/xfs_log_recover.c:3244) xlog_recover (fs/xfs/xfs_log_recover.c:3493) xfs_log_mount (fs/xfs/xfs_log.c:618) xfs_mountfs (fs/xfs/xfs_mount.c:1034) xfs_fs_fill_super (fs/xfs/xfs_super.c:1938) vfs_get_tree (fs/super.c:1695) path_mount (fs/namespace.c:4161) __x64_sys_mount (fs/namespace.c:4367) Fixes: 89cebc847729 ("xfs: validate transaction header length on log recovery") Cc: stable@vger.kernel.org # v4.3 Reported-by: Xiang Mei Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Weiming Shi Reviewed-by: Christoph Hellwig Reviewed-by: "Darrick J. Wong" Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit dca861f2cc9e6fe991dd23567601d112ca2ccc4f Author: Andrey Albershteyn Date: Thu Jul 9 17:24:07 2026 +0200 xfs: fix null pointer dereference in tracepoint commit 9202ee546b0cd71004eed7598546efe4660097da upstream. If dfp is not NULL we exit early here, when dfp is NULL it's allocated in xfs_defer_alloc() but not assigned. The tracepoint tries to dereference members of dfp struct. Signed-off-by: Andrey Albershteyn Cc: stable@vger.kernel.org # v6.8 Fixes: 3f3cec031099c3 ("xfs: force small EFIs for reaping btree extents") Reviewed-by: "Darrick J. Wong" Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit fdafa1e68dc75045b7b617e6e7d2854950804d83 Author: Shoichiro Miyamoto Date: Sat Jul 11 22:33:26 2026 +0900 smb: client: reject overlapping data areas in SMB2 responses commit 8986c932905ea508d66da421eb2eb6e676ace1fe upstream. Commit 53b7c271f06b ("smb: client: restrict implied bcc[0] exemption to responses without data area") restricted the implied bcc[0] length exception to responses without a data area. However, the overlap handling in __smb2_calc_size() clears data_length, which can make an invalid response appear to have no data area and so qualify for the exception. Track data area overlap separately and reject such responses before applying the length compatibility exceptions. Fixes: 53b7c271f06b ("smb: client: restrict implied bcc[0] exemption to responses without data area") Cc: stable@vger.kernel.org Signed-off-by: Shoichiro Miyamoto Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 1991d49433e90b2202de2fe90be3c24161873d7c Author: Zhaoyang Huang Date: Mon Jun 8 17:09:39 2026 +0800 Revert "f2fs: remove non-uptodate folio from the page cache in move_data_block" commit ccaba785821970f422c47770331c7e3271763f17 upstream. This reverts commit 9609dd704725a40cd63d915f2ab6c44248a44598. The kernel panics are keeping to be reported especially when the f2fs partition get almost full. By investigation, we find that the reason is one f2fs page got freed to buddy without being deleted from LRU and the root cause is the race happened in [2] which is enrolled by this commit. There are 3 race processes in this scenario, please find below for their main activities. The changed code in move_data_block() lets the GC path evict the tail-end folio from the page cache through folio_end_dropbehind(). Once folio_unmap_invalidate() removes the folio from mapping->i_pages, the page-cache references for all pages in the folio are dropped. The folio is then kept alive only by temporary external references, which allows a later split to operate on a folio whose subpages are no longer protected by page-cache references. After the page-cache references are gone, split_folio_to_order() can split the big folio into individual pages and put the resulting subpages back on the LRU. For tail pages beyond EOF, split removes them from the page cache and drops their page-cache references. A tail page can then remain on the LRU with PG_lru set while holding only the split caller's temporary reference. When free_folio_and_swap_cache() drops that final reference, the page enters the final folio_put() release path. In parallel, folio_isolate_lru() can observe the same tail page with a non-zero refcount and PG_lru set. It clears PG_lru before taking its own reference. If this races with the final folio_put() from the split path, __folio_put() sees PG_lru already cleared and skips lruvec_del_folio(). The page is then freed back to the allocator while its lru links are still present in the LRU list. A later LRU operation on a neighboring page detects the stale link and reports list corruption. [1] [ 22.486082] list_del corruption. next->prev should be fffffffec10e0ac8, but was dead000000000122. (next=fffffffec10e0a88) [ 22.486130] ------------[ cut here ]------------ [ 22.486134] kernel BUG at lib/list_debug.c:67! [ 22.486141] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 22.488502] Tainted: [W]=WARN, [O]=OOT_MODULE [ 22.488506] Hardware name: Spreadtrum UMS9230 1H10 SoC (DT) [ 22.488511] pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 22.488517] pc : __list_del_entry_valid_or_report+0x14c/0x154 [ 22.488531] lr : __list_del_entry_valid_or_report+0x14c/0x154 [ 22.488539] sp : ffffffc08006b830 [ 22.488542] x29: ffffffc08006b868 x28: 0000000000003020 x27: 0000000000000000 [ 22.488553] x26: 0000000000000000 x25: 0000000000000004 x24: fffffffec10e0ac0 [ 22.488564] x23: 00000000000000e8 x22: 0000000000000024 x21: dead000000000122 [ 22.488574] x20: fffffffec10e0a88 x19: fffffffec10e0ac8 x18: ffffffc080061060 [ 22.488585] x17: 20747562202c3863 x16: 6130653031636566 x15: 0000000000000058 [ 22.488595] x14: 0000000000000004 x13: ffffff80f91e0000 x12: 0000000000000003 [ 22.488605] x11: 0000000000000003 x10: 0000000000000001 x9 : ffe85721f0e25f00 [ 22.488615] x8 : ffe85721f0e25f00 x7 : 0000000000000000 x6 : 6c65645f7473696c [ 22.488625] x5 : ffffffed39b23026 x4 : 0000000000000000 x3 : 0000000000000010 [ 22.488636] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 000000000000006d [ 22.488647] Call trace: [ 22.488651] __list_del_entry_valid_or_report+0x14c/0x154 (P) [ 22.488661] __folio_put+0x2bc/0x434 [ 22.488670] folio_put+0x28/0x58 [ 22.488678] do_garbage_collect+0x1a34/0x2584 [ 22.488689] f2fs_gc+0x230/0x9b4 [ 22.488697] f2fs_fallocate+0xb90/0xdf4 [ 22.488706] vfs_fallocate+0x1b4/0x2bc [ 22.488716] __arm64_sys_fallocate+0x44/0x78 [ 22.488725] invoke_syscall+0x58/0xe4 [ 22.488732] do_el0_svc+0x48/0xdc [ 22.488739] el0_svc+0x3c/0x98 [ 22.488747] el0t_64_sync_handler+0x20/0x130 [ 22.488754] el0t_64_sync+0x1c4/0x1c8 [2] CPU0 (f2fs GC) CPU1 (split_folio_to_order) CPU2 (folio_isolate_lru) F: pagecache refs = n F: extra refs = GC + split F: PG_lru set move_data_block() folio = f2fs_grab_cache_folio(F) ... __folio_set_dropbehind(F) folio_unlock(F) folio_end_dropbehind(F) folio_unmap_invalidate(F) __filemap_remove_folio(F) folio_put_refs(F, n) folio_put(F) split_folio_to_order(F) folio_ref_freeze(F, 1) ... lru_add_split_folio(T) list_add_tail(&T->lru, &F->lru) folio_set_lru(T) __filemap_remove_folio(T) folio_put_refs(T, 1) /* T refcount == 1, PageLRU set */ folio_isolate_lru(T) folio_test_clear_lru(T) free_folio_and_swap_cache(T) folio_put(T) /* refcount: 1 -> 0 */ __folio_put(T) __page_cache_release(T) folio_test_lru(T) == false /* skip lruvec_del_folio(T) */ free_frozen_pages(T) folio_get(T) lruvec_del_folio(T) later: list_del(adjacent->lru) next == &T->lru next->prev == LIST_POISON / PCP freelist BUG Cc: stable@vger.kernel.org Fixes: 9609dd704725 ("f2fs: remove non-uptodate folio from the page cache in move_data_block") Signed-off-by: Zhaoyang Huang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 1c56c46519353112005c248982a7074c63da4926 Author: Luiz Augusto von Dentz Date: Fri Jun 12 10:21:09 2026 -0400 Bluetooth: 6lowpan: Fix using chan->conn as indication to no remote netdev commit d38eaf611839b85ade3dd3db309dbc8aaaaf0095 upstream. b66774b48dd9 ("Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref") don't reset the chan->conn to NULL anymore making the bt# netdev not be remove once the last l2cap_chan_del is removed. Instead of restoring the original behavior this remove the logic of keeping the interface after the last channel is removed because it never worked as intended and the l2cap_chan_del always detach its l2cap_conn which results in always removing the channel anyway. Fixes: b66774b48dd9 ("Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit e697df336662b5b14e10a3419d5d8967acdc7977 Author: Mikhail Gavrilov Date: Tue Jun 16 12:09:14 2026 +0500 timekeeping: Register default clocksource before taking tk_core.lock commit 8fa30821180a9a19e78e9f4df1c0ba710252801e upstream. Commit f24df84cbe05 ("time/jiffies: Register jiffies clocksource before usage") moved the jiffies clocksource registration into clocksource_default_clock(), so that it is registered lazily on the first call. __clocksource_register() acquires clocksource_mutex, but the first caller is timekeeping_init(), which invokes clocksource_default_clock() while holding tk_core.lock, a raw spinlock. Acquiring a sleeping mutex while holding a raw spinlock is invalid. The default clocksource only has to be registered before tk_setup_internals() consumes its mult/shift/maxadj. Neither clocksource_default_clock(), the ->enable() callback, nor the registration itself need tk_core.lock, so fetch and enable the clock before acquiring the lock. This preserves the "register before usage" ordering while keeping clocksource_mutex out of the raw spinlock section. clocksource_default_clock() has a second caller, clocksource_done_booting(), which invokes it with clocksource_mutex already held. That path avoids a recursive lock because timekeeping_init() has already run and set cs_jiffies_registered, so the registration is skipped there. This change does not alter that; it only fixes the invalid wait context in timekeeping_init(). Fixes: f24df84cbe05 ("time/jiffies: Register jiffies clocksource before usage") Signed-off-by: Mikhail Gavrilov Signed-off-by: Thomas Gleixner Reported-by: Breno Leitao Reported-by: Oleg Nesterov Reviewed-by: Breno Leitao Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260616070914.65818-1-mikhail.v.gavrilov@gmail.com Signed-off-by: Greg Kroah-Hartman commit 9e04055ab5fc0470a0031ee6934739f9aa8f34a5 Author: Neill Kapron Date: Fri Jun 19 04:06:03 2026 +0000 usb: gadget: f_fs: Initialize epfile->in early to fix endpoint direction checks commit 82cfd4739011bdc7e87b5d585703427e89ddfaa5 upstream. When parsing endpoint descriptors, ffs_data_got_descs() generates the eps_addrmap which contains the endpoint direction. However, epfile->in was previously only populated in ffs_func_eps_enable() which executes upon USB host connection. As a result, early userspace ioctls like FUNCTIONFS_DMABUF_ATTACH that run before the host connects would see epfile->in as 0, leading to incorrect DMA directions. By moving the initialization to ffs_epfiles_create(), epfile->in is accurate before userspace opens the endpoint files. Fixes: 7b07a2a7ca02 ("usb: gadget: functionfs: Add DMABUF import interface") Cc: stable Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Neill Kapron Link: https://patch.msgid.link/20260619040609.4010746-2-nkapron@google.com Signed-off-by: Greg Kroah-Hartman commit 75e1d2787005d0bb6ea9dd2ed41a41f2bdceb957 Author: Adam Li Date: Sat Oct 11 06:43:22 2025 +0000 sched/fair: Only update stats for allowed CPUs when looking for dst group commit 82d6e01a0699800efd8b048eb584c907ccb47b7a upstream. Load imbalance is observed when the workload frequently forks new threads. Due to CPU affinity, the workload can run on CPU 0-7 in the first group, and only on CPU 8-11 in the second group. CPU 12-15 are always idle. { 0 1 2 3 4 5 6 7 } {8 9 10 11 12 13 14 15} * * * * * * * * * * * * When looking for dst group for newly forked threads, in many times update_sg_wakeup_stats() reports the second group has more idle CPUs than the first group. The scheduler thinks the second group is less busy. Then it selects least busy CPUs among CPU 8-11. Therefore CPU 8-11 can be crowded with newly forked threads, at the same time CPU 0-7 can be idle. A task may not use all the CPUs in a schedule group due to CPU affinity. Only update schedule group statistics for allowed CPUs. Signed-off-by: Adam Li Signed-off-by: Peter Zijlstra (Intel) Cc: Erwan Velu Signed-off-by: Greg Kroah-Hartman commit 0b466cf1b96e191b06b496c4de79da15315c3a9a Author: Joanne Koong Date: Tue Jun 9 14:36:58 2026 -0700 fuse-uring: remove request-less entries from ent_w_req_queue to fix NULL deref commit 1c57a69be962d459c5e705f5cb4355b841b3461c upstream. If a copy into the userspace ring buffer fails, a request will be terminated and fuse_uring_req_end() will set ent->fuse_req to NULL but it will leave the entry on ent_w_req_queue in FRRS_FUSE_REQ state. This can lead to a NULL deref if the request expiration logic scans ent_w_req_queue in the window before the entry is moved off it. Fix this by taking the entry off ent_w_req_queue and changing its state from FRRS_FUSE_REQ to FRRS_INVALID before terminating the request. Fixes: 4fea593e625c ("fuse: optimize over-io-uring request expiration check") Cc: stable@kernel.org Signed-off-by: Joanne Koong Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit e1711479e9068ea31b31353a702a51e639c3d059 Author: Bernd Schubert Date: Mon Jun 8 23:03:45 2026 +0200 fuse-uring: make a fuse_req on SQE commit only findable after memcpy commit 1efd3d474fc0ba74dfd984249bca78807d739812 upstream. Bad userspace might try to trick us and send commit SQEs request unique / commit-id of requests that are not even send to fuse-server (io_uring_cmd_done() not called) yet. fuse_uring_commit_fetch() ends the fuse request when the ring entry has a wrong state, but that could have caused a use-after-free with the memcpy operations in fuse_uring_send_in_task(). In order to avoid such races the call of fuse_uring_add_to_pq() is moved after the copy operations and just before completing the io-uring request - malicious userspace cannot find the request anymore until all prepration work in fuse-client/kernel is completed. This also moves fuse_uring_add_to_pq() a bit up in the code to avoid a forward declaration. Also not with a preparation commit, to make it easier to back port to older kernels. Reported-by: xlabai Reported-by: Berkant Koc Fixes: c090c8abae4b6b ("fuse: Add io-uring sqe commit and fetch support") Cc: stable@kernel.org # 6.14 Signed-off-by: Bernd Schubert Reviewed-by: Joanne Koong Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 39c8e925b207afceffaa5382416ed405e0223a03 Author: Bernd Schubert Date: Mon Jun 8 23:03:44 2026 +0200 fuse-uring: Avoid queue->stopped races and set/read that value under lock commit b70a3aca16934c196f92abb17b01c1647b9bb63c upstream. There are several readers of queue->stopped that check the value under lock, but fuse_uring_commit_fetch() did not and actually the value was not set under the lock in fuse_uring_abort_end_requests() either. Especially in fuse_uring_commit_fetch it is important to check under a lock, because due to races 'struct fuse_req' might be freed with fuse_request_end, but another thread/cpu might already do teardown work. Cc: stable@kernel.org # 6.14 Fixes: 4a9bfb9b6850fec ("fuse: {io-uring} Handle teardown of ring entries") Reported-by: Berkant Koc Reported-by: xlabai Signed-off-by: Bernd Schubert Reviewed-by: Joanne Koong Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 23a356e0bd96c8d5fb3ddff069f692bf10cab5c1 Author: Bernd Schubert Date: Mon Jun 8 23:03:43 2026 +0200 fuse-uring: Avoid use-after-free in fuse_uring_async_stop_queues commit d351da75066955144515cb2f9aa959f24a04287a upstream. fuse_uring_async_stop_queues() might run when the last reference on ring->queue_refs was already dropped. In order to avoid an early destruction a reference on struct fuse_conn is now taken before starting fuse_uring_async_stop_queues() and that reference is only released when that delayed work queue terminates. Fixes: 4a9bfb9b6850 ("fuse: {io-uring} Handle teardown of ring entries") Cc: stable@kernel.org # 6.14 Reported-by: Berkant Koc Signed-off-by: Bernd Schubert Reviewed-by: Joanne Koong Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit bb476ef8e1027a9d509fbaaf81f5061a07e9e5a7 Author: Chris Mason Date: Mon Jun 8 17:28:55 2026 -0700 fuse-uring: end fuse_req on io-uring cancel task work commit bea4fe98204b6ce7eb8e29f7bf867dd7619b3ddd upstream. When io_uring delivers task work with tw.cancel set (PF_EXITING, PF_KTHREAD fallback, or percpu_ref_is_dying on the ring context), fuse_uring_send_in_task() takes the cancel branch, assigns -ECANCELED, and falls through to fuse_uring_send(). That path only flips the entry to FRRS_USERSPACE and completes the io_uring cmd; it never discharges the ring entry's owning reference to the fuse_req that fuse_uring_add_req_to_ring_ent() handed it at dispatch time. fuse_uring_send_in_task() tw.cancel == true err = -ECANCELED fuse_uring_send(ent, cmd, err, issue_flags) ent->state = FRRS_USERSPACE list_move(&ent->list, &queue->ent_in_userspace) ent->cmd = NULL io_uring_cmd_done(-ECANCELED) /* ent->fuse_req still set, req still hashed */ The fuse_req stays linked on fpq->processing[hash] and fuse_request_end() is never invoked. The originating syscall thread blocks in D-state in request_wait_answer() until fuse_abort_conn() runs, which can be the entire connection lifetime. For FR_BACKGROUND requests fc->num_background is never decremented either, so repeated cancels inflate the counter until max_background is hit and all later background ops stall. tw.cancel does not imply a connection abort (e.g. a single io_uring worker thread exits while the fuse connection stays up), so this cannot be left for fuse_abort_conn() to clean up. Ending the req but still routing the entry through fuse_uring_send() is not enough: that leaves a req-less entry on ent_in_userspace, and ent_list_request_expired() dereferences ent->fuse_req unconditionally on the head of that list, which would then NULL-deref. Fix the cancel branch to release the entry directly. Remove it from the queue, complete the io_uring cmd, end the fuse_req, free the entry, and drop its queue_refs (waking the teardown waiter if it was the last). Fixes: c2c9af9a0b13 ("fuse: Allow to queue fg requests through io-uring") Cc: stable@vger.kernel.org Reviewed-by: Joanne Koong Assisted-by: kres (claude-opus-4-7) Signed-off-by: Chris Mason Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 50f3e03db823cabc41fe35c27d77c2bdb112baad Author: Joanne Koong Date: Mon Jun 8 12:21:49 2026 -0700 fuse-uring: fix moving cancelled entry to ent_in_userspace list commit 198f45eeb9f78b2a2d6d8be95e4e43468eb2c6bc upstream. fuse_uring_cancel() moves entries that are available (these have no reqs attached) to the ent_in_userspace list. ent_list_request_expired() checks the first entry on ent_in_userspace and dereferences ent->fuse_req unconditionally, which will crash on a cancelled entry that was moved to this list. Fix this by freeing the entry and dropping queue_refs directly in fuse_uring_cancel(). This is safe because cancel is the cancel handler itself - after io_uring_cmd_done(), no more cancels will be dispatched for this command, and teardown serializes with cancel via queue->lock. Since cancel now decrements queue_refs, fuse_uring_abort() must no longer gate fuse_uring_abort_end_requests() on queue_refs > 0, as cancelled entries may have already dropped queue_refs while requests are still queued. Remove the gate so abort always flushes requests and stops queues. Reported-by: Heechan Kang Tested-by: Heechan Kang Reviewed-by: Bernd Schubert Fixes: 4fea593e625c ("fuse: optimize over-io-uring request expiration check") Cc: stable@vger.kernel.org Suggested-by: Jian Huang Li Suggested-by: Horst Birthelmer Signed-off-by: Joanne Koong Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit b156bb9966972122b148acab8bdf415cdb8176a3 Author: Chris Mason Date: Fri Jun 5 12:27:07 2026 -0700 fuse-uring: fix data races on ring->ready commit 46725a0056c884cf58a6897f222892807327d82d upstream. On weakly-ordered architectures, the store to fiq->ops can be reordered past the store to ring->ready, allowing a CPU that sees ring->ready == true via fuse_uring_ready() to dispatch requests through a stale fiq->ops pointer. Upgrade the store to smp_store_release() and the load in fuse_uring_ready() to smp_load_acquire() so that the preceding WRITE_ONCE(fiq->ops, ...) is visible to any CPU that observes ring->ready == true. Additionally, fuse_uring_do_register() publishes ring->ready with WRITE_ONCE() but the fast-path check reads it with a plain load. This is a marked-vs-unmarked access that KCSAN will flag. Wrap it in READ_ONCE() to mark it without adding unnecessary ordering. Also wrap the fc->ring load in fuse_uring_ready() in READ_ONCE() to prevent the compiler from reloading it between the NULL check and the dereference. Fixes: c2c9af9a0b13 ("fuse: Allow to queue fg requests through io-uring") Cc: stable@vger.kernel.org Reviewed-by: Joanne Koong Assisted-by: kres (claude-opus-4-7) Signed-off-by: Chris Mason Reviewed-by: Bernd Schubert Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 0483fffdeeb363f320e6bf5fc0f0306007507306 Author: Chris Mason Date: Fri Jun 5 12:27:06 2026 -0700 fuse-uring: fix EFAULT clobber in fuse_uring_commit commit 3a0a8bc51a13951c5141262bf770eeea3e0b6228 upstream. copy_from_user() returns the number of bytes not copied as an unsigned residual on failure (1..sizeof(struct fuse_out_header)). fuse_uring_commit stores that residual in ssize_t err, sets req->out.h.error to -EFAULT, then jumps to out: with err still holding the positive residual. err = copy_from_user(&req->out.h, &ent->headers->in_out, sizeof(req->out.h)); if (err) { req->out.h.error = -EFAULT; goto out; /* err is the positive residual */ } ... out: fuse_uring_req_end(ent, req, err); fuse_uring_req_end() then runs if (error) req->out.h.error = error; which overwrites the just-assigned -EFAULT with the positive residual. FUSE callers such as fuse_simple_request() test err < 0 to detect failure, so the positive value is interpreted as success and the caller proceeds with an uninitialised or partial req->out.args. Fix by assigning err = -EFAULT in the failure branch before jumping to out, so fuse_uring_req_end() receives a negative errno and sets req->out.h.error to -EFAULT. Fixes: c090c8abae4b ("fuse: Add io-uring sqe commit and fetch support") Cc: stable@vger.kernel.org Reviewed-by: Joanne Koong Assisted-by: kres (claude-opus-4-7) Signed-off-by: Chris Mason Reviewed-by: Bernd Schubert Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 7366e6f4d2b4c7002b13fb01219e83679dad4127 Author: Ji'an Zhou Date: Tue Jun 9 09:58:51 2026 +0000 fuse: clear intr_entry in fuse_resend and fuse_remove_pending_req commit f8fce75fedf73ac72aa09163deb8f4291fdcaad2 upstream. When fuse_resend() moves a request from fpq->processing back to fiq->pending, it sets FR_PENDING and clears FR_SENT but does not remove the requests intr_entry from fiq->interrupts. If the request had FR_INTERRUPTED set from a prior signal, intr_entry remains dangling on fiq->interrupts. When the requesting task then receives a fatal signal, fuse_remove_pending_req() sees FR_PENDING=1, removes the request from fiq->pending and frees it via the refcount path, also without cleaning intr_entry. The stale intr_entry causes use-after-free when fuse_read_interrupt() iterates fiq->interrupts: - list_del_init(&req->intr_entry) -> UAF write on freed slab - req->in.h.unique -> UAF read, data leaked to userspace Remove intr_entry from fiq->interrupts in fuse_resend() for interrupted requests before they are placed back on fiq->pending. Add a WARN_ON if the intr_entry is not empty on request destruction. Fixes: 760eac73f9f6 ("fuse: Introduce a new notification type for resend pending requests") Cc: stable@vger.kernel.org # 6.9 Signed-off-by: Ji'an Zhou Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 096cb2e58a6db23015f25b3b95e8d0e1bf112020 Author: Joanne Koong Date: Wed Apr 8 10:25:10 2026 -0700 fuse: fix io-uring background queue dispatch on request completion commit 31da059891bd3be9c6e59280b8e1777ead90db34 upstream. When a background request completes via the io_uring path, the background queue gets flushed to dispatch pending background requests, but this is done before the connection-level background counters (fc->num_background, fc->active_background) are properly accounted, which may reduce effective queue depth to one. The connection-level counters are decremented in fuse_request_end(), but flush_bg_queue() flushes the /dev/fuse path queue (fc->bg_queue), not the io_uring per-queue bg one, which means pending uring background requests on the queue are never dispatched in this path. Fix this by accounting the connection-level background counters first before flushing the queue's background queue. Since fuse_request_bg_finish() clears FR_BACKGROUND, fuse_request_end() will skip the background cleanup branch entirely, which avoids any double-decrements; it will call the wake_up(&req->waitq) branch but this is effectively a no-op as background requests have no waiters on req->waitq. Reviewed-by: Bernd Schubert Fixes: 857b0263f30e ("fuse: Allow to queue bg requests through io-uring") Cc: stable@vger.kernel.org Signed-off-by: Joanne Koong Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit be353caffa8640f5e25fb3714ce8b0cef5e410e5 Author: Joanne Koong Date: Mon May 18 22:28:07 2026 -0700 fuse: re-lock request before returning from fuse_ref_folio() commit b5befa80fdbe287a98480effed9564712924add5 upstream. fuse_ref_folio() unlocks the request but does not re-lock it before returning. fuse_chan_abort() can end the request and the async end callback (eg fuse_writepage_free()) can free the args while the subsequent copy chain logic after fuse_ref_folio() accesses them, leading to use-after-free issues. Fix this by locking the request in fuse_ref_folio() before returning. Fixes: c3021629a0d8 ("fuse: support splice() reading from fuse device") Cc: stable@vger.kernel.org Signed-off-by: Joanne Koong Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit e6620208bdd346a01262ef68b76aaf4e8f1667a1 Author: Alberto Ruiz Date: Wed Apr 8 17:23:40 2026 +0200 fuse: fix device node leak in cuse_process_init_reply() commit 9fa4f7a53406430ee9982f2f636a15b338185122 upstream. If device_add() succeeds during CUSE initialization but a subsequent step (cdev_alloc() or cdev_add()) fails, the error path calls put_device() without first calling device_del(). This leaks the devtmpfs entry created by device_add(), leaving a stale /dev/ node that persists until reboot. Since the cuse_conn is never linked into cuse_conntbl on the failure path, cuse_channel_release() sees cc->dev == NULL and skips device_unregister(), so no other code path cleans up the node. This has several consequences: - The device name is permanently poisoned: any subsequent attempt to create a CUSE device with the same name hits the stale sysfs entry, device_add() fails, and the new device is aborted. - The collision manifests as ENODEV returned to userspace with no dmesg diagnostic, making it very difficult to debug. - The failure is self-perpetuating: once a name is leaked, all future attempts with that name fail identically. Fix this by introducing an err_dev label that calls device_del() to undo device_add() before falling through to err_unlock. The existing err_unlock path from a device_add() failure correctly skips device_del() since the device was never added. Testing instructions can be found at the lore link below. Link: https://lore.kernel.org/all/20260408-wip-cuse-leak-fix-v1-0-1c028d575e97@redhat.com/ Signed-off-by: Alberto Ruiz Fixes: 151060ac1314 ("CUSE: implement CUSE - Character device in Userspace") Cc: stable@vger.kernel.org Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 6e2d84fdeac05bfd858e84a76353fdb84f23a43e Author: Samuel Moelius Date: Wed Jun 10 00:37:18 2026 +0000 fuse: avoid 32-bit prune notification count wrap commit 54243797cedf55447b4c5d560e8cd709900061ae upstream. FUSE_NOTIFY_PRUNE validates the nodeid payload length with: size - sizeof(outarg) != outarg.count * sizeof(u64) On 32-bit kernels, size_t is also 32 bits, so the daemon-controlled count multiplication can wrap. A prune notification with count 0x20000000 and no nodeid payload passes the check, enters the copy loop, and asks the device copy path to read nodeids that are not present in the userspace write buffer. In QEMU this reaches the fuse_copy_fill() BUG_ON(!err) path. Validate the payload length with array_size() instead. That accepts exactly the same valid messages, but avoids wrapping arithmetic before the copy loop consumes the count. Assisted-by: Codex:gpt-5.5-cyber-preview Fixes: 3f29d59e92a9 ("fuse: add prune notification") Cc: stable@vger.kernel.org Signed-off-by: Samuel Moelius Reviewed-by: Joanne Koong Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 69cfae58b9a3282d832dd83377323bab36f69c5c Author: Matthew R. Ochs Date: Tue May 26 08:20:21 2026 -0700 fuse: back uncached readdir buffers with pages commit 4dd6f6d3085a84e74b0a1efec3a05ed0b5125dce upstream. Commit dabb90391028 ("fuse: increase readdir buffer size") changed fuse_readdir_uncached() to size its temporary buffer from ctx->count. This is useful for overlayfs and other in-kernel callers that use INT_MAX to indicate an unlimited directory read. The larger buffer is currently supplied as a kvec output argument. For virtiofs, kvec arguments are copied through req->argbuf, which is allocated with kmalloc(..., GFP_ATOMIC). A large uncached readdir buffer can therefore require a multi-megabyte contiguous atomic allocation before the request is queued. Avoid the large bounce-buffer allocation by backing uncached readdir output with pages and setting out_pages. Transports such as virtiofs can then pass the pages as scatter-gather entries instead of copying the output through argbuf. Map the pages with vm_map_ram() only while parsing the returned dirents. The existing parser can then continue to use a linear kernel mapping. [SzM: separate allocation of pages into a helper function] Fixes: dabb90391028 ("fuse: increase readdir buffer size") Cc: stable@vger.kernel.org Signed-off-by: Matthew R. Ochs Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 423a78ff7928c2601013f73ec6d896f5597d0df5 Author: Michael Bommarito Date: Tue Jun 2 15:47:00 2026 -0400 RDMA/siw: bound Read Response placement to the RREAD length commit 7d29f7e9dbd844cae4d3e559cf78324b9642fd6b upstream. In drivers/infiniband/sw/siw/siw_qp_rx.c, siw_proc_rresp() places each inbound Read Response DDP segment at sge->laddr + wqe->processed and then accumulates wqe->processed, but it never checks the running total against the sink buffer length on continuation segments. siw_check_sge() resolves and validates the sink memory only on the first fragment (the if (!*mem) branch), and siw_rresp_check_ntoh() compares the cumulative length against wqe->bytes only on the final segment (the !frx->more_ddp_segs guard). A connected siw peer that answers an outstanding RREAD with Read Response segments that keep the DDP Last flag clear, carrying more total payload than the RREAD requested, drives wqe->processed past the validated sink buffer; the next siw_rx_data() call writes out of bounds at sge->laddr + wqe->processed. siw runs iWARP over ordinary routable TCP, so the peer is the remote end of an established RDMA connection and needs no local privilege. Bound every segment before placement, exactly as siw_proc_send() and siw_proc_write() already do for their tagged and untagged paths, and terminate the connection with a base-or-bounds DDP error when the Read Response would overrun the sink buffer. This is the second receive-path length fix for this file. A separate change rejects an MPA FPDU length that underflows the per-fragment remainder in the header decode; that guard does not cover this case, because here each individual segment length is self-consistent and only the accumulated placement offset overruns the buffer. Fixes: 8b6a361b8c48 ("rdma/siw: receive path") Link: https://patch.msgid.link/r/20260602194700.2273758-1-michael.bommarito@gmail.com Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit ab45808c141a3b1e04e37aeced7c180ef77449ba Author: Maher Sanalla Date: Tue Jun 9 14:16:38 2026 +0300 RDMA/core: Fix broadcast address falsely detected as local commit 942cd47faa2047b46dfd85745603eba9006973e6 upstream. When rdma_resolve_addr() is invoked with a broadcast destination on an IPoIB interface, is_dst_local() inspects the resolved route and incorrectly concludes that the address is local. As a result, the resolution fails with -ENODEV. The issue stems from using '&' to compare rt_type with RTN_LOCAL. The RTN_* values form a sequential enum, not a bitmask (RTN_LOCAL=2, RTN_BROADCAST=3). Thus, "rt_type & RTN_LOCAL" yields a non-zero result for a broadcast route as well. Replace '&' with '==' when comparing rt_type against RTN_LOCAL. Link: https://patch.msgid.link/r/20260609-fix-rdma-resolve-addr-v1-1-449b8b4e6c09@nvidia.com Cc: stable@vger.kernel.org Fixes: c31e4038c97f ("RDMA/core: Use route entry flag to decide on loopback traffic") Signed-off-by: Maher Sanalla Reviewed-by: Vlad Dumitrescu Signed-off-by: Edward Srouji Reviewed-by: Parav Pandit Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 5a45d0aa1fa50a333ce5763ade744e2d89838667 Author: Zhenhao Wan Date: Fri Jun 12 01:15:54 2026 +0800 RDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdma_write_sg commit 963af8d97a8c6a117134a8d0db1415e0489200b1 upstream. When the server answers an RTRS READ, rdma_write_sg() builds the source scatter/gather entry for the IB_WR_RDMA_WRITE that returns data to the peer. Its length is taken directly from the wire descriptor: plist->length = le32_to_cpu(id->rd_msg->desc[0].len); rd_msg points into the chunk buffer that the remote peer filled via RDMA-WRITE-WITH-IMM (rtrs_srv_rdma_done() -> process_io_req() -> process_read()), so desc[0].len is attacker-controlled and, before this change, was only rejected when zero. The source address is the fixed chunk start (dma_addr[msg_id]) and the source lkey is the PD-wide local_dma_lkey, which is not tied to the chunk's MR mapping, so the verbs layer does not constrain the transfer length to max_chunk_size. msg_id and off are bounded against queue_depth and max_chunk_size in rtrs_srv_rdma_done(), but desc[0].len is a separate field that was not checked against the chunk size. A peer that advertises desc[0].len larger than max_chunk_size can make the posted RDMA write read past the chunk's mapped region. The resulting behaviour depends on the IOMMU configuration: with no IOMMU or in passthrough mode the read may extend into memory adjacent to the chunk and be returned to the peer, which can disclose host memory; with a translating IOMMU the out-of-range access is expected to fault and abort the connection. In either case the transfer exceeds what the protocol permits and is driven by a remote peer. Reject a descriptor length above max_chunk_size, mirroring the existing off >= max_chunk_size bound in rtrs_srv_rdma_done(). Legitimate clients do not exceed it: the client sets desc[0].len to its MR length, which is capped at the negotiated max_io_size (max_chunk_size - MAX_HDR_SIZE). Fixes: 9cb837480424 ("RDMA/rtrs: server: main functionality") Link: https://patch.msgid.link/r/20260612-master-v1-1-70cde5c6fdc9@gmail.com Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Zhenhao Wan Reviewed-by: Md Haris Iqbal Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 95de76f6ad4743dc6c350e170522c74ef93e62bb Author: Dmitry Torokhov Date: Mon Jun 29 22:49:15 2026 -0700 Input: maplecontrol - set driver data before registering input device commit fe938ee497d58c644f6910cfe6ae155f6fb3e523 upstream. Set maple driver data before calling input_register_device() to ensure that it is available if the device is opened immediately and the callback is triggered. Cc: stable@vger.kernel.org Assisted-by: Antigravity:gemini-3.5-flash Tested-by: Florian Fuchs Link: https://patch.msgid.link/akNYib9hQFNN1fA9@google.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 9376c744bea2c1fc759443802a3a4dad14cf4498 Author: Dmitry Torokhov Date: Mon Jun 29 22:47:34 2026 -0700 Input: maplemouse - set driver data before registering input device commit 738f24bbbc95dd50cb4229d1ed62a05f29db2bda upstream. Set maple driver data before calling input_register_device() to ensure that it is available if the device is opened immediately and the callback is triggered. Cc: stable@vger.kernel.org Assisted-by: Antigravity:gemini-3.5-flash Tested-by: Florian Fuchs Link: https://patch.msgid.link/akNXw45L_8bxD6QV@google.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 699e3abac02de62080c9a95c26b38aec694e415c Author: Dmitry Torokhov Date: Mon Jun 29 18:44:41 2026 -0700 Input: maple_keyb - set driver data before registering input device commit 536394ec81419b67d9f4f0028812c4372397be1b upstream. Set maple driver data before calling input_register_device() to ensure that it is available if the device is opened immediately and the callback is triggered. Cc: stable@vger.kernel.org Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit d7f66fbab5d212840d81b410ddc63780a8d54c4a Author: Dmitry Torokhov Date: Fri Jul 3 23:01:12 2026 -0700 Input: mms114 - fix multi-touch slot corruption commit adea84ee6cdea611146c4251d3c1616f5a09feca upstream. If the touchscreen controller reports a touch ID of 0, the driver calculates the slot ID as touch->id - 1, which underflows to UINT_MAX. This is passed to input_mt_slot() as -1. Since the input core ignores negative slot values, the active slot remains unchanged. The driver then reports the touch coordinates for the previously active slot, corrupting its state. Fix this by rejecting touch reports with ID 0. Fixes: 07b8481d4aff ("Input: add MELFAS mms114 touchscreen driver") Cc: stable@vger.kernel.org Reported-by: sashiko-bot@kernel.org Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260704060115.353049-1-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 1b4cb75f254fb0224db1b65a1bb1f735a87df01d Author: Florian Fuchs Date: Mon Jun 29 18:33:42 2026 -0700 Input: maplemouse - fix NULL pointer dereference in open() commit ee89db004238bd0b034f2a6176e175561658750b upstream. Commit 555c765b0cc2 ("Input: mouse - drop unnecessary calls to input_set_drvdata") dropped the input_set_drvdata() call in probe because the data appeared to be unused. However, dc_mouse_open() and dc_mouse_close() were using maple_get_drvdata(to_maple_dev(&dev->dev)). This appears to be accessing the data attached to an instance of maple_device structure, while in reality this actually retrieves driver data from the input device's embedded struct device (doing invalid conversion of input device structure to maple device). After input_set_drvdata() was removed, that lookup started returning NULL and opening the input device dereferences mse->mdev. Restore input_set_drvdata() and convert open() and close() to use input_get_drvdata() so the dependency is no longer hidden. Fixes: 6b3480855aad ("maple: input: fix up maple mouse driver") Fixes: 555c765b0cc2 ("Input: mouse - drop unnecessary calls to input_set_drvdata") Signed-off-by: Florian Fuchs Link: https://patch.msgid.link/20260628230715.2982552-1-fuchsfl@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 37fbe63bccf21e3b98636f6ed4f9bd7891baaefd Author: Xu Rao Date: Wed Jun 24 17:47:39 2026 +0800 Input: gscps2 - advance receive buffer write index commit d86d4f8cbb5a55a3b9b86f7b5ab8c4cdda600a3f upstream. Commit 44f920069911 ("Input: gscps2 - use guard notation when acquiring spinlock") moved the receive loop into gscps2_read_data() and gscps2_report_data(). While moving the code, it preserved the writes to buffer[ps2port->append], but omitted the following producer index update from the original loop: ps2port->append = (ps2port->append + 1) & BUFFER_SIZE; As a result, append never advances. Since gscps2_report_data() only reports bytes while act != append, the receive buffer always appears empty and no keyboard or mouse data reaches the serio core. Restore the omitted index update. Fixes: 44f920069911 ("Input: gscps2 - use guard notation when acquiring spinlock") Cc: stable@vger.kernel.org # 6.13+ Signed-off-by: Xu Rao Link: https://patch.msgid.link/460B5655BA580C60+20260624094739.850306-1-raoxu@uniontech.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 8301c335305344d4da4ab9442b6a399dacfe5b8d Author: Bryam Vargas Date: Sun Jun 14 14:19:43 2026 -0700 Input: mms114 - reject an oversized device packet size commit 66725039f7090afe14c31bd259e2059a68f04023 upstream. mms114_interrupt() reads a packet of touch data from the device into a fixed-size on-stack buffer struct mms114_touch touch[MMS114_MAX_TOUCH]; which holds MMS114_MAX_TOUCH (10) events of MMS114_EVENT_SIZE (8) bytes, i.e. 80 bytes. The length of the I2C read into it is taken verbatim from the device: packet_size = mms114_read_reg(data, MMS114_PACKET_SIZE); if (packet_size <= 0) goto out; ... error = __mms114_read_reg(data, MMS114_INFORMATION, packet_size, (u8 *)touch); packet_size is a single device register byte (0x0F) and the only check is the lower bound packet_size <= 0; it is never bounded against the size of touch[]. A malfunctioning, malicious or counterfeit controller (or an attacker tampering with the I2C bus) can report a packet_size of up to 255, so __mms114_read_reg() writes up to 175 bytes past the end of touch[] on the IRQ-thread stack: a stack out-of-bounds write that can overwrite the stack canary, saved registers and the return address. A well-formed device never reports more than the buffer holds, so reject an oversized packet and drop the report, consistent with the handler's other error paths, rather than reading past the buffer. Fixes: 07b8481d4aff ("Input: add MELFAS mms114 touchscreen driver") Signed-off-by: Bryam Vargas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260612-b4-disp-dc4b8dc4-v1-1-d7cb0a828d92@proton.me Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 3e6f007b43e2fc6546e21fa74ee62c38984a6672 Author: Bryam Vargas Date: Sat Jun 13 20:07:20 2026 -0500 Input: touchwin - reset the packet index on every complete packet commit 478cdd736f2ce3114f90e775d7358136d3977b94 upstream. tw_interrupt() accumulates each non-zero serial byte into a fixed three-byte buffer with a running index that is only reset once a full packet has been received *and* the device's two Y bytes agree: tw->data[tw->idx++] = data; if (tw->idx == TW_LENGTH && tw->data[1] == tw->data[2]) { ... tw->idx = 0; } The reset is gated on tw->data[1] == tw->data[2], a value the device controls. A malicious, malfunctioning or counterfeit Touchwindow peripheral can stream non-zero bytes whose 2nd and 3rd bytes differ: the index reaches TW_LENGTH without the equality holding, is never reset, and keeps growing, so tw->data[tw->idx++] walks off the end of the three-byte array and the rest of the heap-allocated struct tw, one attacker-chosen byte at a time -- an unbounded, device-driven heap out-of-bounds write. Reset the index on every completed packet and report an event only when the two Y bytes match, like the other serio touchscreen drivers do. Fixes: 11ea3173d5f2 ("Input: add driver for Touchwin serial touchscreens") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Link: https://patch.msgid.link/20260613-b4-disp-69921bfd-v1-1-82c036899959@proton.me Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 05dee4007cf3029163ac6c09f2b313b7cd177cff Author: Kris Bahnsen Date: Thu May 7 16:49:43 2026 +0000 Input: ads7846 - don't use scratch for tx_buf when clearing register commit 856668312685d9a8f32d49a135a89c429d309f81 upstream. The workaround for XPT2046 clears the command register, giving the touchscreen controller a NOP. The change incorrectly re-uses the req->scratch variable which is used as rx_buf for xfer[5], so by the time xfer[6] occurs, the contents of req->scratch may not be 0. It was found that the touchscreen controller can end up in a completely unresponsive state due to it being given a command the driver does not expect. Instead, rely on the spi_transfer behavior of tx_buf being NULL to transmit all 0 bits and use the scratch variable for the rx_buf for both the 1 byte command to and 2 byte response from the controller. Also relocates the scratch member of struct ser_req to force it into a different cache line to prevent any potential issues of DMA stepping on unrelated data in other struct members due to sharing the same cache line. This change was tested on real TSC2046 and ADS7843 controllers, but not the XPT2046 the workaround was originally created for. Confirming that the original modification to clear the command register does not impact either real controller. Fixes: 781a07da9bb94 ("Input: ads7846 - add dummy command register clearing cycle") Cc: stable@vger.kernel.org Co-developed-by: Mark Featherston Signed-off-by: Mark Featherston Signed-off-by: Kris Bahnsen Link: https://patch.msgid.link/20260507164943.760009-1-kris@embeddedTS.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 75b12874b4172533b9efc349db328cb1a59c3981 Author: Dmitry Torokhov Date: Mon Jun 22 22:35:18 2026 -0700 Input: mms114 - fix touch indexing for MMS134S and MMS136 commit a6ac4e24c1a8a533bb61035184fdcc7eede4cc8d upstream. The MMS134S and MMS136 touch controllers have an event size of 6 bytes rather than 8 bytes. When __mms114_read_reg() reads the touch data packet from the device into the touch buffer, the events are packed tightly at 6-byte intervals. However, the driver iterates through the events using standard C array indexing (touch[index]), where each element is sizeof(struct mms114_touch) (8 bytes) apart. As a result, any touch events beyond the first one are read from incorrect offsets and parsed improperly. Fix this by explicitly calculating the byte offset for each touch event based on the device's specific event size. Fixes: 53fefdd1d3a3 ("Input: mms114 - support MMS136") Fixes: ab108678195f ("Input: mms114 - support MMS134S") Reported-by: sashiko-bot@kernel.org Assisted-by: Antigravity:gemini-3.5-flash Reviewed-by: Bryam Vargas Link: https://patch.msgid.link/20260616050912.1531241-1-dmitry.torokhov@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 70019779325f2bb5f5a4098e91e79c655f50fcef Author: Bryam Vargas Date: Mon Jun 22 20:47:50 2026 -0700 Input: iforce - bound the device-reported force-feedback effect index commit 0e9943d2e4c63496b6ca84bc66fd3c71d40558e2 upstream. iforce_process_packet() handles a status report (packet id 0x02) by taking a force-feedback effect index straight from the device wire and using it to address the per-effect state array: i = data[1] & 0x7f; if (data[1] & 0x80) { if (!test_and_set_bit(FF_CORE_IS_PLAYED, iforce->core_effects[i].flags)) ... } else if (test_and_clear_bit(FF_CORE_IS_PLAYED, iforce->core_effects[i].flags)) { ... } The index is masked only with 0x7f, so it ranges 0..127, but core_effects[] holds only IFORCE_EFFECTS_MAX (32) entries. For an index of 32..127 the test_and_set_bit()/test_and_clear_bit() is an out-of-bounds single-bit read-modify-write past the array. core_effects[] is the second-to-last member of struct iforce, so the write lands in the trailing members and beyond the embedding kzalloc()'d iforce_serio / iforce_usb object. data[1] is unvalidated device payload on both transports (the USB interrupt endpoint and serio), and the status path is not gated on force feedback being present, so a malicious or counterfeit device can set or clear a bit at an attacker-chosen offset past the object. Reject an out-of-range index instead of indexing with it. Bound against the array dimension IFORCE_EFFECTS_MAX rather than dev->ff->max_effects so the check guarantees memory safety regardless of how many effects the device registered. A legitimate "effect started/stopped" status always carries an index below IFORCE_EFFECTS_MAX, so well-formed devices are unaffected; the neighbouring mark_core_as_ready() loop is already bounded and is left untouched. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bryam Vargas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260613-b4-disp-4828d263-v1-1-02320e1a89dd@proton.me Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 3b32303460155603d25444274856013d211d5e1f Author: Bryam Vargas Date: Fri Jun 12 21:10:33 2026 -0500 Input: goodix - clamp the device-reported contact count commit 5ed62a96e06be4e94b8296b7932afee550a70e04 upstream. goodix_ts_read_input_report() copies the number of touch points reported by the device into an on-stack buffer u8 point_data[2 + GOODIX_MAX_CONTACT_SIZE * GOODIX_MAX_CONTACTS]; which is sized for at most GOODIX_MAX_CONTACTS (10) contacts. The only runtime check bounds the per-interrupt count against ts->max_touch_num, but that value is taken verbatim from a 4-bit field of the device configuration block and is never clamped: ts->max_touch_num = ts->config[MAX_CONTACTS_LOC] & 0x0f; The nibble can be 0..15, so a malfunctioning, malicious or counterfeit controller (or an attacker tampering with the I2C bus) can advertise up to 15 contacts. goodix_ts_read_input_report() then accepts a touch_num of up to 15 and the second goodix_i2c_read() writes ts->contact_size * (touch_num - 1) bytes past the one-contact header into point_data - up to 30 bytes (45 with the 9-byte report format) beyond the 92-byte buffer: a stack out-of-bounds write. Clamp max_touch_num to GOODIX_MAX_CONTACTS, the number of contacts point_data[] is sized for, when reading it from the configuration. Fixes: a7ac7c95d468 ("Input: goodix - use max touch number from device config") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: Hans de Goede Link: https://patch.msgid.link/20260612-b4-disp-6844625d-v1-1-df0aed080c9d@proton.me Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 01e0317c256c560d8dcce2e9825eb6142ee34611 Author: Ranjan Kumar Date: Mon Jun 22 22:31:05 2026 -0700 Input: elan_i2c - prevent division by zero and arithmetic underflow commit df2b818fa009c10ff6ba875a1663ff001cda9558 upstream. The Elan I2C touchpad driver queries the device for its physical dimensions and trace counts to calculate the device resolution and width. However, if the device firmware or device tree provides invalid zero values for x_traces or y_traces, it results in a fatal division-by-zero exception leading to a kernel panic during device probe. Add checks to ensure these parameters are non-zero before performing the division. If invalid trace values are detected, fall back to a safe default of 1. Additionally, prevent an arithmetic underflow in the touch reporting logic. Previously, if the calculated or fallback width was smaller than ETP_FWIDTH_REDUCE (90), the subtraction would underflow, resulting in a massive unsigned integer being reported to userspace. Clamp the adjusted width to a minimum of 0 to safely handle small physical dimensions and fallback scenarios. Completing the probe with safe fallback values ensures the sysfs nodes are created, keeping the firmware update path intact so a recovery firmware can be flashed to the device. Fixes: 6696777c6506 ("Input: add driver for Elan I2C/SMbus touchpad") Fixes: e3a9a1290688 ("Input: elan_i2c - do not query the info if they are provided") Signed-off-by: Ranjan Kumar Link: https://patch.msgid.link/20260612060339.3829666-1-kumarranja@chromium.org Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit e849c6f51e6877104c765da084e001ec37c8e119 Author: Bryam Vargas Date: Sun Jun 14 00:36:12 2026 -0500 Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count commit d577e46785d45484b2ab7e7309c49b18764bf56c upstream. rmi_f30_map_gpios() allocates gpioled_key_map with min(gpioled_count, TRACKSTICK_RANGE_END) == at most 6 entries, but rmi_f30_attention() iterates the full f30->gpioled_count (device query register, range 0..31) and dereferences gpioled_key_map[i], and input->keycodemax is set to the full gpioled_count while input->keycode points at the 6-entry allocation. A device that reports gpioled_count > 6 with GPIO support enabled therefore causes an out-of-bounds read on the attention interrupt and out-of-bounds read/write through the EVIOCGKEYCODE/EVIOCSKEYCODE ioctls, which bound the index only against keycodemax. This is the same defect as the F3A handler, which was copied from F30. Size the keymap for the full gpioled_count; the mapping loop still assigns only the first min(gpioled_count, TRACKSTICK_RANGE_END) entries. Fixes: 3e64fcbdbd10 ("Input: synaptics-rmi4 - limit the range of what GPIOs are buttons") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Link: https://patch.msgid.link/20260614-b4-disp-818d6bda-v1-2-cf39a3615085@proton.me Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 8db211aed83733073b0814adaeeab61d4521474e Author: Bryam Vargas Date: Sun Jun 14 00:36:11 2026 -0500 Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count commit 57c10915f2c16c90e0d46ad00876bf39ece40fc2 upstream. rmi_f3a_initialize() takes the GPIO count from the device query register (f3a->gpio_count = buf & RMI_F3A_GPIO_COUNT, range 0..127). rmi_f3a_map_gpios() then allocates gpio_key_map with min(gpio_count, TRACKSTICK_RANGE_END) == at most 6 entries, but rmi_f3a_attention() iterates the full gpio_count and dereferences gpio_key_map[i], and input->keycodemax is set to the full gpio_count while input->keycode points at the 6-entry allocation. A device that reports gpio_count > 6 therefore causes an out-of-bounds read of gpio_key_map[] on every attention interrupt, and out-of-bounds accesses through the input core's default keymap ioctls: EVIOCGKEYCODE reads past the buffer (leaking adjacent slab memory to user space) and EVIOCSKEYCODE writes a caller-controlled value past it, for any process able to open the evdev node, since input_default_getkeycode() and input_default_setkeycode() only bound the index against keycodemax. Size the keymap for the full gpio_count. The mapping loop is unchanged: it still assigns only the first min(gpio_count, TRACKSTICK_RANGE_END) entries; the remaining slots stay KEY_RESERVED (devm_kcalloc zero-fills) and are skipped when reporting. Fixes: 9e4c596bfd00 ("Input: synaptics-rmi4 - add support for F3A") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Link: https://patch.msgid.link/20260614-b4-disp-818d6bda-v1-1-cf39a3615085@proton.me Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 11f275f01c46ba8aaf9ce224f00e241d2d655193 Author: Haoxiang Li Date: Wed Jun 10 16:41:16 2026 -0700 Input: synaptics-rmi4 - unregister function handlers on physical driver registration failure commit 6251f7d3472c0409e30f8d6a24f10d33d12e3f9a upstream. If rmi_register_physical_driver() fails, the current error path unregisters only the RMI bus. The function handlers registered earlier remain registered with the driver core. Add a separate error path to unregister the function handlers before unregistering the bus in this failure case. Fixes: 2b6a321da9a2 ("Input: synaptics-rmi4 - add support for Synaptics RMI4 devices") Signed-off-by: Haoxiang Li Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260610064633.2837084-1-haoxiang_li2024@163.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit bb5133a7d5f3fe5c387770e25f2e00e682ce11ed Author: Mingyu Wang <25181214217@stu.xidian.edu.cn> Date: Tue May 12 17:35:34 2026 +0800 i2c: i801: fix hardware state machine corruption in error path commit 10dd1a736d557e310a77117832874729a0175d57 upstream. A severe livelock and subsequent Hung Task panic were observed in the i2c-i801 driver during concurrent Fuzzing. The crash is caused by an unconditional hardware register cleanup in the error handling path of i801_access(). When i801_check_pre() fails (e.g., returning -EBUSY because the SMBus controller is actively used by BIOS/ACPI), the kernel does not actually acquire the hardware ownership. However, the code jumps to the 'out' label and executes: iowrite8(SMBHSTSTS_INUSE_STS | STATUS_FLAGS, SMBHSTSTS(priv)); This forcefully clears the INUSE_STS lock and resets the hardware status flags without owning the controller. Doing so interrupts ongoing BIOS/ACPI transactions and totally corrupts the SMBus hardware state machine. Consequently, all subsequent i801_access() calls fail at the pre-check stage, triggering an endless stream of "SMBus is busy, can't use it!" error logs. Over a slow serial console, this printk flood monopolizes the CPU (Console Livelock), starving other processes trying to acquire the mmap_lock down_read semaphore, ultimately triggering the hung task watchdog. Fix this by moving the 'out' label below the hardware register cleanup. If i801_check_pre() fails, we safely bypass the iowrite8() and only release the software locks (pm_runtime and mutex), strictly adhering to the rule of not releasing resources that were never acquired. Fixes: 1f760b87e54c ("i2c: i801: Call i801_check_pre() from i801_access()") Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> Cc: # v6.3+ Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260512093534.348655-1-w15303746062@163.com Signed-off-by: Greg Kroah-Hartman commit b2523f26979e0b5bd1422772176b2233fcd1f6d0 Author: Carlos Song Date: Mon May 25 11:14:50 2026 +0800 i2c: imx-lpi2c: mark I2C adapter when hardware is powered down commit 218cfe364b55b2768221629bd4a69ad190b7fbbc upstream. On some i.MX platforms, certain I2C client drivers keep a periodic workqueue which continues to trigger I2C transfers. During system suspend/resume, there exists a time window between: - suspend_noirq and the system entering suspend - the system starting to resume and resume_noirq In this window, the I2C controller resources such as clock and pinctrl may already be disabled or not yet restored. If a workqueue triggers an I2C transfer in this period, the driver attempts to access I2C registers while the hardware resources are unavailable, which may lead to system hang. Mark the I2C adapter as suspended during noirq suspend and block new transfers until resume, ensuring that I2C transfers are only issued when hardware resources are available. Fixes: 1ee867e465c1 ("i2c: imx-lpi2c: add target mode support") Signed-off-by: Carlos Song Cc: # v6.14+ Acked-by: Mukesh Savaliya Reviewed-by: Frank Li Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260525031450.3183421-1-carlos.song@oss.nxp.com Signed-off-by: Greg Kroah-Hartman commit 369635fbcf7f3b5cfffde92469d6c8349dbcc810 Author: Guillermo Rodríguez Date: Thu Jun 11 12:48:56 2026 +0200 i2c: stm32f7: truncate clock period instead of rounding it commit 111bb7f9f4a90b32e495d70a607c67b137f3074a upstream. stm32f7_i2c_compute_timing() derives the I2C clock source period (i2cclk) with DIV_ROUND_CLOSEST, which may round it up. When the period is overestimated, all timings computed from it (SCLDEL, SDADEL, SCLL, SCLH) come out shorter on the wire than calculated, and the resulting bus rate can exceed the requested speed, violating the I2C specification minimums for tLOW and tHIGH. For example, with a 104.45 MHz clock source (e.g. PCLK1, the reset-default I2C clock source on STM32MP1), i2cclk is rounded from 9.574 ns up to 10 ns. Requesting a 400 kHz fast mode bus with 72/27 ns rise/fall times and no analog/digital filters then produces an actual bus rate of 415.6 kHz with tLOW = 1254 ns, violating both the 400 kHz maximum rate and the 1300 ns tLOW minimum of the specification. Truncate the period instead, so that it can only be underestimated. The error then falls on the safe side: the programmed timings come out slightly longer than computed and the bus runs marginally below the target rate (375.3 kHz in the example above) while meeting the specification. i2cbus is left rounded-to-closest: it is only used as the target of the clk_error comparison and is never multiplied into the programmed timings, so nearest rounding remains accurate there. Fixes: aeb068c57214 ("i2c: i2c-stm32f7: add driver") Signed-off-by: Guillermo Rodríguez Cc: # v4.14+ Acked-by: Alain Volmat Reviewed-by: Pierre-Yves MORDRET Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260611104857.242153-1-guille.rodriguez@gmail.com Signed-off-by: Greg Kroah-Hartman commit b65667ec5e9a90b259f68f1cec559a983098bae1 Author: Haoxiang Li Date: Wed Jun 10 11:05:13 2026 +0800 i2c: davinci: Unregister cpufreq notifier on probe failure commit e43f32816a1b1fe5a86279411626fe3a9be56d45 upstream. davinci_i2c_probe() registers a cpufreq transition notifier before adding the I2C adapter. If i2c_add_numbered_adapter() fails, the probe error path releases the device resources without unregistering the notifier. Add a dedicated error path to unregister the cpufreq notifier after i2c_add_numbered_adapter() fails. Fixes: 82c0de11b734 ("i2c: davinci: Add cpufreq support") Signed-off-by: Haoxiang Li Cc: # v2.6.36+ Reviewed-by: Bartosz Golaszewski Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260610030513.2651018-1-haoxiang_li2024@163.com Signed-off-by: Greg Kroah-Hartman commit 56945871123e2b6de1c5231e2a60da65b36391bf Author: Andy Shevchenko Date: Thu Jun 18 16:49:34 2026 +0200 i2c: mpc: Fix timeout calculations commit 2e9a7f68329be41792c0b123c28e6c53c2fa2249 upstream. At first glance the harmless cleanup of the driver does nothing bad. However, as the operator precedence list states the '*' (multiplication) and '/' division operators have order 5 with left-to-right associativity the *= has order 17 and associativity right-to-left. It wouldn't be a problem to replace foo = foo * HZ / 1000000; with foo *= HZ / 1000000; if HZ constant is in Hertz. The problem is that in the Linux kernel HZ is defined in jiffy units, which is order of magnitude smaller than a million. That's why operator precedence has a crucial role here. Fix the regression by reverting pre-optimized calculations. Fixes: be40a3ae719f ("i2c: mpc: Use of_property_read_u32 instead of of_get_property") Signed-off-by: Andy Shevchenko Cc: # v6.4+ Reviewed-by: Chris Packham Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260618144934.3249950-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit b6d2af6fe9c1f5ec0484536753c979cbd40a8ac3 Author: Johan Hovold Date: Mon May 11 16:37:13 2026 +0200 i2c: core: fix adapter deregistration race commit b1a58ed9eab146b36f41a55db8f5d7ce9fdedf3f upstream. Adapters can be looked up by their id using i2c_get_adapter() which takes a reference to the embedded struct device. Remove the adapter from the IDR before tearing it down during deregistration (and on registration failure) to make sure its resources are not accessed after having been freed (e.g. the device name). Fixes: 35fc37f81881 ("i2c: Limit core locking to the necessary sections") Cc: stable@vger.kernel.org # 2.6.31 Cc: Jean Delvare Signed-off-by: Johan Hovold Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 71b7da959031f1cb216e6871cfd84ee82cd50c39 Author: Johan Hovold Date: Mon May 11 16:37:10 2026 +0200 i2c: core: fix adapter debugfs creation commit 07d5fb537928aad4369aaff0cbae73ba38a719af upstream. Clients can be registered from bus notifier callbacks so the debugfs directory needs to be created before registering the adapter as clients use that directory as their debugfs parent. Move debugfs creation before adapter registration to avoid having clients create their debugfs directories in the debugfs root (which is also more likely to fail due to name collisions). Note that failure to allocate the adapter name must now be handled explicitly as debugfs_create_dir() cannot handle a NULL name (unlike device_add() which returns an error). Fixes: 73febd775bdb ("i2c: create debugfs entry per adapter") Cc: stable@vger.kernel.org # 6.8 Cc: Wolfram Sang Signed-off-by: Johan Hovold Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 0345994d64761c73e1df23f075c7d6cc2dbc4cfb Author: Johan Hovold Date: Mon May 11 16:37:09 2026 +0200 i2c: core: fix adapter probe deferral loop commit 158efa411c57111d87bf265a3776614f32d70007 upstream. Drivers must not probe defer after having registered devices as that will trigger a probe loop if the devices bind to a driver (cf. commit fbc35b45f9f6 ("Add documentation on meaning of -EPROBE_DEFER")). Move the recovery initialisation, where the GPIO lookup may fail, before registering the adapter to prevent this. Fixes: 75820314de26 ("i2c: core: add generic I2C GPIO recovery") Cc: stable@vger.kernel.org # 5.9 Cc: Codrin Ciubotariu Signed-off-by: Johan Hovold Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 3351c5e77749a0c8a1e252b95420c143ebcf07ac Author: Johan Hovold Date: Mon May 11 16:37:08 2026 +0200 i2c: core: fix NULL-deref on adapter registration failure commit 2295d2bb101faa663fbc45fadbb3fec45f107441 upstream. If adapter registration ever fails the release callback would trigger a NULL-pointer dereference as the completion struct has not been initialised. Note that before the offending commit this would instead have resulted in a minor memory leak of the adapter name. Fixes: 3f8c4f5e9a57 ("i2c: core: fix reference leak in i2c_register_adapter()") Cc: stable@vger.kernel.org Cc: Joe Hattori Signed-off-by: Johan Hovold Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 9ec02cc9a04e502847a8313ea690001ae2051a27 Author: Johan Hovold Date: Mon May 11 16:37:06 2026 +0200 i2c: core: fix irq domain leak on adapter registration failure commit 8ce19524e4cc2462685f596a6402fbd8fb984ab2 upstream. Make sure to tear down the host notify irq domain on adapter registration failure to avoid leaking it. This issue was flagged by Sashiko when reviewing another adapter registration fix. Fixes: 4d5538f5882a ("i2c: use an IRQ to report Host Notify events, not alert") Cc: stable@vger.kernel.org # 4.10 Cc: Benjamin Tissoires Signed-off-by: Johan Hovold Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 59070040fd12e0b78d7b4d341d9f9a183237c5ff Author: Sebastian Alba Vives Date: Mon May 18 13:07:41 2026 -0600 fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region() commit fc3b071a7c8dc0f5d56defddf6e6fd5aaa3e1e27 upstream. afu_ioctl_dma_map() accepts a 64-bit length from userspace via DFL_FPGA_PORT_DMA_MAP ioctl without an upper bound check. The value is passed to afu_dma_pin_pages() where npages is derived as length >> PAGE_SHIFT and passed to pin_user_pages_fast() which takes int nr_pages, causing implicit truncation if length is very large. Validate map.length at the ioctl entry point before calling afu_dma_map_region(), rejecting values whose page count exceeds INT_MAX. Fixes: fa8dda1edef9 ("fpga: dfl: afu: add DFL_FPGA_PORT_DMA_MAP/UNMAP ioctls support") Cc: stable@vger.kernel.org Signed-off-by: Sebastian Alba Vives Reviewed-by: Xu Yilun Link: https://lore.kernel.org/r/20260518190742.61426-3-sebasjosue84@gmail.com Signed-off-by: Xu Yilun Signed-off-by: Greg Kroah-Hartman commit 34696563461c9a23177feb6d8aff43f4c0510278 Author: Mikhail Gavrilov Date: Tue Mar 31 11:16:57 2026 +0500 dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning commit 504e2b4ab97a51d56d966cd36d0997ad30b65b2d upstream. When CONFIG_DMA_API_DEBUG_SG is enabled, importing a udmabuf into a DRM driver (e.g. amdgpu for video playback in GNOME Videos / Showtime) triggers a spurious warning: DMA-API: amdgpu 0000:03:00.0: cacheline tracking EEXIST, \ overlapping mappings aren't supported WARNING: kernel/dma/debug.c:619 at add_dma_entry+0x473/0x5f0 The call chain is: amdgpu_cs_ioctl -> amdgpu_ttm_backend_bind -> dma_buf_map_attachment -> [udmabuf] map_udmabuf -> get_sg_table -> dma_map_sgtable(dev, sg, direction, 0) // attrs=0 -> debug_dma_map_sg -> add_dma_entry -> EEXIST This happens because udmabuf builds a per-page scatter-gather list via sg_set_folio(). When begin_cpu_udmabuf() has already created an sg table mapped for the misc device, and an importer such as amdgpu maps the same pages for its own device via map_udmabuf(), the DMA debug infrastructure sees two active mappings whose physical addresses share cacheline boundaries and warns about the overlap. The DMA_ATTR_SKIP_CPU_SYNC flag suppresses this check in add_dma_entry() because it signals that no CPU cache maintenance is performed at map/unmap time, making the cacheline overlap harmless. All other major dma-buf exporters already pass this flag: - drm_gem_map_dma_buf() passes DMA_ATTR_SKIP_CPU_SYNC - amdgpu_dma_buf_map() passes DMA_ATTR_SKIP_CPU_SYNC The CPU sync at map/unmap time is also redundant for udmabuf: begin_cpu_udmabuf() and end_cpu_udmabuf() already perform explicit cache synchronization via dma_sync_sgtable_for_cpu/device() when CPU access is requested through the dma-buf interface. Pass DMA_ATTR_SKIP_CPU_SYNC to dma_map_sgtable() and dma_unmap_sgtable() in udmabuf to suppress the spurious warning and skip the redundant sync. Fixes: 284562e1f348 ("udmabuf: implement begin_cpu_access/end_cpu_access hooks") Cc: stable@vger.kernel.org Signed-off-by: Mikhail Gavrilov Acked-by: Vivek Kasireddy Signed-off-by: Vivek Kasireddy Link: https://patch.msgid.link/20260331061657.79983-1-mikhail.v.gavrilov@gmail.com Signed-off-by: Greg Kroah-Hartman commit f8e1dc70efe4820c271de49a2ed2c7d5e10f445c Author: Mikhail Gavrilov Date: Sun Mar 15 04:27:22 2026 +0500 udmabuf: fix DMA direction mismatch in release_udmabuf() commit fb7b1a0ab25a6077d26cb3829e31743972d4f31d upstream. begin_cpu_udmabuf() maps the sg_table with the caller-provided direction (e.g., DMA_TO_DEVICE for a write-only sync), and caches it in ubuf->sg for reuse. However, release_udmabuf() always unmaps this sg_table with a hardcoded DMA_BIDIRECTIONAL, regardless of the direction that was originally used for the mapping. With CONFIG_DMA_API_DEBUG=y this produces: DMA-API: misc udmabuf: device driver frees DMA memory with different direction [device address=0x000000044a123000] [size=4096 bytes] [mapped with DMA_TO_DEVICE] [unmapped with DMA_BIDIRECTIONAL] The issue was found during video playback when GStreamer performed a write-only DMA_BUF_IOCTL_SYNC on a udmabuf. It can be reproduced with CONFIG_DMA_API_DEBUG=y by creating a udmabuf from a memfd, performing a write-only sync (DMA_BUF_SYNC_WRITE without DMA_BUF_SYNC_READ), and closing the file descriptor. Fix this by storing the DMA direction used when the sg_table is first created in begin_cpu_udmabuf(), and passing that same direction to put_sg_table() in release_udmabuf(). Fixes: 284562e1f348 ("udmabuf: implement begin_cpu_access/end_cpu_access hooks") Cc: stable@vger.kernel.org Signed-off-by: Mikhail Gavrilov Reviewed-by: Vivek Kasireddy Signed-off-by: Vivek Kasireddy Link: https://patch.msgid.link/20260314232722.15555-1-mikhail.v.gavrilov@gmail.com Signed-off-by: Greg Kroah-Hartman commit 0c93681aea0a1b8be14730a88abe77c840272e41 Author: Oliver Upton Date: Tue Jun 2 16:54:46 2026 -0700 KVM: arm64: Don't leak PFN when kvm_translate_vncr() races MMU notifier commit 9f76b039a72d7e06374aa96862f0232ed53f7787 upstream. In the case that kvm_translate_vncr() races with an MMU notifier the early return does not release a reference on the faulted in PFN. Add the necessary call to kvm_release_faultin_page() for the unused PFN. Cc: stable@vger.kernel.org Fixes: 069a05e535496 ("KVM: arm64: nv: Handle VNCR_EL2-triggered faults") Reported-by: Sashiko (local):gemini-3.1-pro Signed-off-by: Oliver Upton Link: https://patch.msgid.link/20260602235450.103057-2-oupton@kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 4ad73ef0e7966ecfe67de0060537b4cb14d9acd4 Author: Sean Christopherson Date: Thu Apr 23 09:26:27 2026 -0700 KVM: x86: Ensure vendor's exit handler runs before fastpath userspace exits commit 0ffedf43910e44b76c2c1db4e9fbf12b268190c1 upstream. Move the handling of fastpath userspace exits into vendor code to ensure KVM runs vendor specific operations that need to run before userspace gains control of the vCPU. E.g. for VMX (and soon to be for SVM as well), KVM needs to flush the PML buffer prior to exiting to userspace, otherwise any memory written by the final KVM_RUN might never be flagged as dirty. Note, waiting to snapshot CR0 and CR3 until svm_handle_exit() is flawed in general, as that risks consuming stale state in a fastpath handler. That will be addressed in a future change. Fixes: f7f39c50edb9 ("KVM: x86: Exit to userspace if fastpath triggers one on instruction skip") Cc: stable@vger.kernel.org Cc: Nikunj A. Dadhania Reviewed-by: Nikunj A. Dadhania Reviewed-by: Kai Huang Link: https://patch.msgid.link/20260423162628.490962-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit ab253cf6e11189d1c709494588736b3c194a1de5 Author: Xuanqing Shi <1356292400@qq.com> Date: Tue May 26 19:26:17 2026 -0700 KVM: VMX: Handle bad values on proxied writes to LBR MSRs commit ca674df13b195eb6d124ab059799d4e03fa40624 upstream. Use the "safe" WRMSR API when writing LBRs on behalf of the guest (or host userspace), and propagate any errors back to the instigator, as the value being written is untrusted. E.g. if the guest (or host userspace) attempts to set reserved bits in LBR_SELECT, then KVM needs to return an error, and not WARN on the bad value. Continue using the "unsafe" version of RDMSR, as it should be impossible to reach the helper with a completely bogus MSR, i.e. WARNing on RDMSR failure is very desirable, e.g. to make KVM bugs more visible. unchecked MSR access error: WRMSR to 0x1c8 (tried to write 0x0000000000004000) Call Trace: intel_pmu_set_msr+0x4e0/0x7f0 [kvm_intel] kvm_pmu_set_msr+0x17e/0x1c0 [kvm] kvm_set_msr_common+0xc76/0x1440 [kvm] vmx_set_msr+0x5e6/0x1570 [kvm_intel] kvm_emulate_wrmsr+0x54/0x1d0 [kvm] vmx_handle_exit+0x7fc/0x970 [kvm_intel] Fixes: 1b5ac3226a1a ("KVM: vmx/pmu: Pass-through LBR msrs when the guest LBR event is ACTIVE") Cc: stable@vger.kernel.org Signed-off-by: Xuanqing Shi <1356292400@qq.com> [sean: rework changelog, only modify WRMSR path, tag for stable@] Link: https://patch.msgid.link/20260527022617.3973884-1-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit eeb456eb355650963c3b8b1581bfd0c413742c23 Author: Sean Christopherson Date: Fri May 15 15:26:29 2026 -0700 KVM: VMX: Refresh GUEST_PENDING_DBG_EXCEPTIONS.BS on all injected #DBs commit c5bad4fa2d5dfd8c25140051a9807eba387a19b8 upstream. Move KVM's stuffing of GUEST_PENDING_DBG_EXCEPTIONS.BS when RFLAGS.TF=1 and MOV/POP SS or STI blocking is active into the exception injection code so that KVM fixes up the VMCS for all injected #DBs, not only those that are reflected back into the guest after #DB interception. E.g. if KVM queues a #DB in the emulator, or more importantly if userspace does save/restore exactly on the #DB+shadow boundary, then KVM needs to massage the VMCS to avoid the VM-Entry consistency check. Opportunistically update the wording of the comment to describe the behavior as a workaround of flawed CPU behavior/architecture, to make it clear that the *only* thing KVM is doing is fudging around a consistency check. Per the SDM: There are no pending debug exceptions after VM entry if any of the following are true: * The VM entry is vectoring with one of the following interruption types: external interrupt, non-maskable interrupt (NMI), hardware exception, or privileged software exception. I.e. forcing GUEST_PENDING_DBG_EXCEPTIONS.BS does *not* impact guest- visible behavior. Fixes: b9bed78e2fa9 ("KVM: VMX: Set vmcs.PENDING_DBG.BS on #DB in STI/MOVSS blocking shadow") Cc: stable@vger.kernel.org Reported-by: Hou Wenlong Closes: https://lore.kernel.org/all/b1a294bc9ed4dae532474a5dc6c8cb6e5962de7c.1757416809.git.houwenlong.hwl@antgroup.com Reviewed-by: Hou Wenlong Link: https://patch.msgid.link/20260515222638.1949982-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 35f3ea7e49a373ed982ff6fa62f96cd090c3bfa1 Author: Sean Christopherson Date: Thu May 14 14:31:15 2026 -0700 KVM: SVM: Only disable x2AVIC WRMSR interception for MSRs that are accelerated commit 8c63179d975f2029c948ecce622f72af616dbff7 upstream. When x2AVIC is enabled, disable WRMSR interception only for MSRs that are actually accelerated by hardware. Disabling interception for MSRs that aren't accelerated is functionally "fine", and in some cases a weird "win" for performance, but only for cases that should never be triggered by a well-behaved VM (writes to read-only registers; the #GP will typically occur in the guest without taking a #VMEXIT, even for fault-like exits). But overall, disabling interception for MSRs that aren't accelerated is at best confusing and unintuitive, and at worst introduces avoidable risk, as the APM's documentation is imperfect and contradictory. The table in "15.29.3.1 Virtual APIC Register Accesses" of simply states that such writes generate exits, where as "Section 15.29.10 x2AVIC" says: x2APIC MSR intercept checks and access checks have higher priority than AVIC access permission checks. CPU behavior follows the latter (which makes perfect sense), but all in all there's simply no reason to disable interception just to make a #GP faster. Note, the set of MSRs that are passed through for write is identical to VMX's set when IPI virtualization is enabled. This is not a coincidence, and is another motiviating factor for cleaning up the intercepts, as x2AVIC is functionally equivalent to APICv+IPIv. Fixes: 4d1d7942e36a ("KVM: SVM: Introduce logic to (de)activate x2AVIC mode") Cc: stable@vger.kernel.org Reviewed-by: Naveen N Rao (AMD) Link: https://patch.msgid.link/20260514213115.1637082-4-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 7949aa38e1094fc6da05cefcf7932e186086099a Author: Sean Christopherson Date: Thu May 14 14:31:14 2026 -0700 KVM: SVM: Disable x2AVIC RDMSR interception for MSRs KVM actually supports commit 7f4b7092d9a173a4271e28c0ed1fc235994e309b upstream. When toggling x2AVIC on/off, use KVM's curated mask of x2APIC MSRs that can/should be passed through to the guest (or not) when 2AVIC is enabled. Using the effective list provided by the local APIC emulation fixes multiple (classes of) bugs, as the existing hand-coded list of MSRs is wrong on multiple fronts: - ARBPRI isn't supported by KVM, isn't accelerated by AVIC (for read or write), and its #VMEXIT is fault-like, i.e. requires decoding the instruction. Disabling interception is nonsensical and suboptimal. - DFR and ICR2 aren't supported by x2APIC and so don't need their intercepts disabled for performance reasons. While the #GP due to x2APIC being abled has higher priority than the trap-like #VMEXIT, disabling interception of unsupported MSRs is confusing and unnecessary. - RRR is completely unsupported. - AVIC currently fails to pass through the "range of vectors" registers, IRR, ISR, and TMR, as e.g. X2APIC_MSR(APIC_IRR) only affects IRR0, and thus only disables intercept for vectors 31:0 (which are the *least* interesting registers). - TMCCT (the current APIC timer count) isn't accelerated by hardware, and generates a fault-like AVIC_UNACCELERATED_ACCESS #VMEXIT, i.e. requires KVM to decode the instruction to figure out what the guest was trying to access. Note, the only reason this isn't a fatal bug is that the AVIC architecture had the foresight to guard against buggy hypervisors. E.g. if hardware simply read from the virtual APIC page, the guest would get garbage (because the timer is emulated in software). Fixes: 4d1d7942e36a ("KVM: SVM: Introduce logic to (de)activate x2AVIC mode") Cc: stable@vger.kernel.org Reviewed-by: Naveen N Rao (AMD) Link: https://patch.msgid.link/20260514213115.1637082-3-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 4b200e0c9c339cfb9385e548cabcfdf52845717c Author: Sean Christopherson Date: Thu May 14 14:31:13 2026 -0700 KVM: x86: Add dedicated API for getting mask of accelerated x2APIC MSRs commit 8ba621f335a519b47cb7d3e3f4f15b5101b3a56f upstream. Add a dedicated local APIC API, kvm_x2apic_disable_intercept_reg_mask(), to provide the mask of x2APIC registers whose MSRs can and should be passed through to the guest when x2APIC virtualization is enable, and use it in lieu of the open-coded equivalent VMX logic. Providing a common helper will allow sharing the logic with SVM (x2AVIC), and as a bonus eliminates the somewhat confusing code where KVM enables interception for MSR_TYPE_RW, even though only the READ case actually needs to be updated. No functional change intended. Cc: stable@vger.kernel.org Reviewed-by: Naveen N Rao (AMD) Link: https://patch.msgid.link/20260514213115.1637082-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 6bea2f8becdb20d34378493c3b77a9b9cf8c6cfa Author: Hyunwoo Kim Date: Sun Jun 7 02:56:10 2026 +0900 KVM: arm64: Clear __hyp_running_vcpu when flushing the pKVM hyp vCPU commit e8042f6e1d7befb2fb6b10a75918642bcd0acf9a upstream. flush_hyp_vcpu() copies the host vCPU context into the hyp's private vCPU on every run. ctxt_to_vcpu() expects a guest context to have a NULL __hyp_running_vcpu, which is only ever set on the host context, so that it resolves the vCPU via container_of(). While this is generally the case, flush_hyp_vcpu() copies the context verbatim and does not enforce this, so a value provided by the host is dereferenced at EL2 (host -> EL2). Fix by clearing __hyp_running_vcpu after the copy. Cc: stable@vger.kernel.org Fixes: be66e67f1750 ("KVM: arm64: Use the pKVM hyp vCPU structure in handle___kvm_vcpu_run()") Signed-off-by: Hyunwoo Kim Reviewed-by: Fuad Tabba Tested-by: Fuad Tabba Link: https://patch.msgid.link/20260606175614.83273-2-imv4bel@gmail.com Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 2d710d4fcd2cd24f25df61f6fc68b02c034d079f Author: Zeng Chi Date: Thu Jun 11 20:46:44 2026 +0800 LoongArch: KVM: Add missing slots_lock for device register/unregister commit aeded601d6aceb57cdda4b2701d2ee00c43a8b69 upstream. kvm_io_bus_register_dev() and kvm_io_bus_unregister_dev() should be called under kvm->slots_lock. The unregister calls in ipi.c, eiointc.c and pch_pic.c were also missing this protection. Add it to match the register side. Cc: stable@vger.kernel.org Reviewed-by: Bibo Mao Signed-off-by: Zeng Chi Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 7c73a269a880b1399baacfb9d521415e6ef7ecc2 Author: Marc Zyngier Date: Sun Jun 7 18:57:45 2026 +0100 KVM: arm64: nv: Avoid dereferencing NULL VNCR pseudo-TLB commit 4be6cbeb93d26994bd1827ddbce391e3c4395c8f upstream. VNCR TLB invalidation occurs from MMU notifiers or TLBI instructions, and either can race against a vcpu not being onlined yet (no pseudo-TLB allocated). Similarly, the TLB might be invalid, and the invalidation should be skipped in this case. Both kvm_invalidate_vncr_ipa() and kvm_invalidate_vncr_va() are expected to perform the same checks, except that the latter doesn't check for the allocation and blindly dereferences the pointer. Solve this by introducing a new iterator built on top of the usual kvm_for_each_vcpu() that checks for both of the above conditions, and convert the two users to it. Reported-by: Hyunwoo Kim Link: https://lore.kernel.org/r/aiUvSbrWndQeUPc8@v4bel Fixes: 4ffa72ad8f37 ("KVM: arm64: nv: Add S1 TLB invalidation primitive for VNCR_EL2") Cc: stable@vger.kernel.org Reviewed-by: Oliver Upton Link: https://patch.msgid.link/20260607175745.297793-1-maz@kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit b51a7439c166aab2061ae6a7dff6f679fe6b11a1 Author: Mickaël Salaün Date: Wed May 13 12:51:08 2026 +0200 selftests/landlock: Filter dealloc records in audit_count_records() commit 26679fad81a471428707d2dd7b0418204c52b7e4 upstream. audit_count_records() counts both AUDIT_LANDLOCK_DOMAIN allocation and deallocation records in records.domain . Domain deallocation is tied to asynchronous credential freeing via kworker threads (landlock_put_ruleset_deferred), so the dealloc record can arrive after the drain in audit_init() and after the preceding audit_match_record() call. This causes flaky failures in tests that assert an exact records.domain count: a stale dealloc record from a previous test's domain inflates the count by one. Observed on x86_64 under build configurations that delay the kworker firing the dealloc callback (e.g. coverage instrumentation): the audit_layout1 tests in fs_test.c intermittently saw records.domain == 2 where 1 was expected. The fix is in the shared helper, so those existing checks become robust without needing a fs_test.c edit. Filter audit_count_records() with a regex to skip records containing deallocation status. The remaining domain records (allocation, emitted synchronously during landlock_log_denial()) are deterministic. Deallocation records are already tested explicitly via matches_log_domain_deallocated() in audit_test.c, which uses its own domain-ID-based filtering and longer timeout. With this filter in place, re-add the records.domain == 0 checks that were removed in commit 3647a4977fb7 ("selftests/landlock: Drain stale audit records on init") as a workaround for this race. Cc: Günther Noack Cc: stable@vger.kernel.org Depends-on: 07c2572a8757 ("selftests/landlock: Skip stale records in audit_match_record()") Fixes: 6a500b22971c ("selftests/landlock: Add tests for audit flags and domain IDs") Tested-by: Günther Noack Link: https://patch.msgid.link/20260513105112.140137-1-mic@digikod.net Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit 859fef2c3d40aa3c6297bba9f15bb95716550ddc Author: Mickaël Salaün Date: Fri Jun 12 19:27:55 2026 +0200 landlock: Set audit_net.sk for socket access checks commit d936e1a9170f9cadaa5f37586b1dfe6f20f98799 upstream. Set audit_net.sk in current_check_access_socket() to provide the socket object to audit_log_lsm_data(). This makes Landlock consistent with AppArmor, which always sets .sk for socket operations, and with SELinux's generic socket permission checks. The socket's local and foreign address information (laddr, lport, faddr, fport) is logged by the shared lsm_audit.c infrastructure when the socket has bound or connected state. Fields with zero values are suppressed by print_ipv4_addr()/print_ipv6_addr(), so the audit output is unchanged for the common case of bind denials on unbound sockets. For connect denials after a prior bind, the bound local address (laddr, lport) appears before the existing sockaddr fields (daddr, dest). No existing fields are removed or reordered, and the new field names (laddr, lport, faddr, fport) are standard audit fields already emitted by other LSMs through the same lsm_audit.c code path. Add a connect_tcp_bound audit test that binds to an allowed port and then connects to a denied one, verifying that the denial record reports laddr/lport from the bound socket in addition to the connect destination. Cc: Günther Noack Cc: Tingmao Wang Cc: stable@vger.kernel.org Fixes: 9f74411a40ce ("landlock: Log TCP bind and connect denials") Link: https://patch.msgid.link/20260612172757.1003481-1-mic@digikod.net Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit e4427c19554b56bb38408fba3c3e10e11e3d7f92 Author: Ricardo Robaina Date: Wed May 13 18:47:59 2026 -0300 audit: fix removal of dangling executable rules commit 888a0396e154524f4027f27da84bdbec9eb68916 upstream. When an audited executable is deleted from the disk, its dentry becomes negative. Any later attempt to delete the associated audit rule will lead to audit_alloc_mark() encountering this negative dentry and immediately aborting, returning -ENOENT. This early abort prevents the subsystem from allocating the temporary fsnotify mark needed to construct the search key, meaning the kernel cannot find the existing rule in its own lists to delete it. This leaves a dangling rule in memory, resulting in the following error while attempting to delete the rule: # ./audit-dupe-exe-deadlock.sh No rules Error deleting rule (No such file or directory) There was an error while processing parameters # auditctl -l -a always,exit -S all -F exe=/tmp/file -F path=/tmp/file -F key=dr # auditctl -D Error deleting rule (No such file or directory) There was an error while processing parameters This patch fixes this issue by removing the d_really_is_negative() check. By doing so, a dummy mark can be successfully generated for the deleted path, which allows the audit subsystem to properly match and flush the dangling rule. Cc: stable@kernel.org Fixes: 76a53de6f7ff ("VFS/audit: introduce kern_path_parent() for audit") Acked-by: Waiman Long Acked-by: Richard Guy Briggs Signed-off-by: Ricardo Robaina Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 32ca4aed2a66205b072fcfecabe220289a8149ff Author: Nicolin Chen Date: Wed Jun 3 14:26:53 2026 -0700 iommufd: Set upper bounds on cache invalidation entry_num and entry_len commit 4d70986002f2f3eaaed89124fb2522bded38b016 upstream. iommufd_hwpt_invalidate() takes a user-controlled entry_num and entry_len, each bounded only by U32_MAX. An entry_len beyond the kernel's struct size makes the copy helper verify the extra bytes are zero, scanning that excess in one uninterruptible pass; a multi-gigabyte value over zeroed user memory trips the soft-lockup watchdog. A large entry_num is the other half, driving the backend invalidation loop with no reschedule. The VT-d nested handler, for one, copies each entry and flushes caches per iteration, pinning the CPU on a non-preemptible kernel. Cap both in the ioctl. entry_len is held under PAGE_SIZE, above any request struct, and entry_num under 1 << 19, the order of a hardware invalidation queue and well beyond any real batch, bounding the per-call loop length. Fixes: 8c6eabae3807 ("iommufd: Add IOMMU_HWPT_INVALIDATE") Link: https://patch.msgid.link/r/447fa93663f7526eb361719e83fa8b649464483d.1780521606.git.nicolinc@nvidia.com Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen Reviewed-by: Lu Baolu Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 67daea4c09351467d08c408e6cd23f62501df262 Author: Nicolin Chen Date: Mon Jun 1 13:42:37 2026 -0700 iommufd: Avoid partial fault group delivery in iommufd_fault_fops_read() commit 091ab6d70dc444f56ed14faedbcacfc979f4c613 upstream. The cookie returned by xa_alloc() in iommufd_fault_fops_read() is per fault group, but the inner copy_to_user() runs per fault inside the group. If a copy fails mid-group, xa_erase clears the cookie and the group is restored to the deliver list, yet done is not rolled back. The function returns the partial byte count, with the successfully copied faults sitting at offsets below done carrying the now-erased cookie. The next read() then re-fetches the group, allocates a fresh cookie, and re-delivers every fault including the ones already copied; userspace sees duplicates carrying the new cookie, and a stale cookie that can never be responded to. Use a local group_done variable that tracks the per-group progress inside the inner loop, and only commit done = group_done after the inner loop has finished successfully. On a copy_to_user failure the outer break skips the commit, so done remains at its prior start-of-group baseline; the partial bytes already written past done are undefined to userspace per the read(2) contract, and the next read re-delivers the whole group atomically. Fixes: 07838f7fd529 ("iommufd: Add iommufd fault object") Link: https://patch.msgid.link/r/360cab4d4aeccb0bae275a970e2b3c340a71e0e0.1780343944.git.nicolinc@nvidia.com Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Nicolin Chen Reviewed-by: Pranjal Shrivastava Reviewed-by: Kevin Tian Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 5539da127d03c1f6c2e2a49fdfbe331a0ccbdea8 Author: Nicolin Chen Date: Mon Jun 1 13:42:36 2026 -0700 iommufd: Break the loop on failure in iommufd_fault_fops_read() commit 172fc8b19825a0f5884c38f2289188284e2d45ee upstream. On a copy_to_user() failure inside the inner list_for_each_entry, only the inner loop breaks; the outer while re-fetches the just-restored fault group and retries the failing copy_to_user() forever, spinning the reader at 100% CPU with fault->mutex held. Check rc after the inner loop and break the outer while as well. Fixes: 07838f7fd529 ("iommufd: Add iommufd fault object") Link: https://patch.msgid.link/r/336a9b6e44fe66a24199d3be777c405c85c98622.1780343944.git.nicolinc@nvidia.com Cc: stable@vger.kernel.org Signed-off-by: Nicolin Chen Reviewed-by: Pranjal Shrivastava Reviewed-by: Kevin Tian Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit f2dbe1dba01e6639731042b23d2e74cb773f8760 Author: Nicolin Chen Date: Mon Jun 1 13:42:35 2026 -0700 iommufd: Reject invalid read count in iommufd_fault_fops_read() commit 47916a54eeb2a9e654512ee609f71bd5b29db702 upstream. The read count must be large enough to hold one fault or a group's faults. iommufd_fault_fops_read() does not validate the count, but returns 0 as if the read had succeeded while leaving the pending fault in the queue. Return -EINVAL in the undersize cases. Fixes: 07838f7fd529 ("iommufd: Add iommufd fault object") Link: https://patch.msgid.link/r/85c118a606fbedc5c132a1f5ec223a5ba23b92d2.1780343944.git.nicolinc@nvidia.com Cc: stable@vger.kernel.org Signed-off-by: Nicolin Chen Reviewed-by: Pranjal Shrivastava Reviewed-by: Kevin Tian Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit f549a749b6255e6932d58c26a023adacb8049c9b Author: Nicolin Chen Date: Mon Jun 1 13:42:33 2026 -0700 iommufd: Reject invalid read count in iommufd_veventq_fops_read() commit 00203ca8323f9714630408c19a209b52397975e6 upstream. The read count must be large enough to hold a vEVENT header. For a normal vEVENT, it must also hold the trailing data following the header. iommufd_veventq_fops_read() does not validate the count, but returns 0 as if the read had succeeded while leaving the pending event in the queue. Return -EINVAL in both undersize cases. Fixes: e36ba5ab808e ("iommufd: Add IOMMUFD_OBJ_VEVENTQ and IOMMUFD_CMD_VEVENTQ_ALLOC") Link: https://patch.msgid.link/r/e1111adcc8a8882fbfd84accd6674dc846dc5689.1780343944.git.nicolinc@nvidia.com Cc: stable@vger.kernel.org Signed-off-by: Nicolin Chen Reviewed-by: Pranjal Shrivastava Reviewed-by: Kevin Tian Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 64011399d881966926b1e79e69d54d2c81010754 Author: Nicolin Chen Date: Mon Jun 1 13:42:32 2026 -0700 iommufd: Rewind header length in done if iommufd_veventq_fops_read() fails commit 01e41ad76c12ae5c49ab4ef4fc7dd54e9b8784d6 upstream. When the first event copy fails, rc = -EFAULT will not be reported as done is set to the length of the copied header. Rewind it to report rc correctly. Fixes: e36ba5ab808e ("iommufd: Add IOMMUFD_OBJ_VEVENTQ and IOMMUFD_CMD_VEVENTQ_ALLOC") Link: https://patch.msgid.link/r/78f8caeb6a5d667a26b870e3068cec47dd4b5be1.1780343944.git.nicolinc@nvidia.com Cc: stable@vger.kernel.org Signed-off-by: Nicolin Chen Reviewed-by: Pranjal Shrivastava Reviewed-by: Kevin Tian Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit f565297edf316016be4a1a9e2eb9f39359313f43 Author: Nicolin Chen Date: Thu May 21 17:36:34 2026 -0700 iommufd: Set veventq_depth upper bound commit 6ebf2eb46fbd5b40393ff8fbb847ba96925beaff upstream. iommufd_veventq_alloc() accepts any !0 veventq_depth from userspace, with an upper bound at U32_MAX. This leaves a vulnerability where userspace can allocate excessively large queues to exhaust kernel memory reserves. Cap the veventq_depth (maximum number of entries) to 1 << 19, matching the maximum number of entries in the SMMUv3 EVTQ (the largest use case today). Fixes: e36ba5ab808e ("iommufd: Add IOMMUFD_OBJ_VEVENTQ and IOMMUFD_CMD_VEVENTQ_ALLOC") Link: https://patch.msgid.link/r/8426cbaa5e8294472ec7f076ef427cc473be5985.1779408671.git.nicolinc@nvidia.com Cc: stable@vger.kernel.org Reviewed-by: Jason Gunthorpe Signed-off-by: Nicolin Chen Reviewed-by: Kevin Tian Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 5c5f1b5184f7d9786bd7d9646bdbbcdcee3c05f1 Author: Nicolin Chen Date: Thu May 21 17:36:32 2026 -0700 iommufd: Fix data_len byte-count vs element-count mismatch commit 85345becfead3255a5f875d4b4d82ea01d926239 upstream. kzalloc_flex() computes the allocation size. With event_data typed as u64, data_len is interpreted as a u64 element count. Yet, every caller and the read path treat data_len as a byte count. The current code over-allocates by sizeof(u64) and the __counted_by() annotation overstates the length by the same factor. Re-type event_data as u8. No functional change in user-visible behavior. Fixes: e36ba5ab808e ("iommufd: Add IOMMUFD_OBJ_VEVENTQ and IOMMUFD_CMD_VEVENTQ_ALLOC") Link: https://patch.msgid.link/r/f7665f839b9dce917d6bd394375a1cf56568d86b.1779408671.git.nicolinc@nvidia.com Cc: stable@vger.kernel.org Reviewed-by: Jason Gunthorpe Signed-off-by: Nicolin Chen Reviewed-by: Kevin Tian Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 04a177f91160ee18da98f5689482cf0f589ec869 Author: Kai Aizen Date: Thu Apr 30 20:56:30 2026 +0300 iommufd: Use sizeof(*hdr) instead of sizeof(hdr) in veventq read commit be93d186ae88a92e7aa77e122d4e661fa57b1e39 upstream. The bound-check in iommufd_veventq_fops_read() for the normal vEVENT path uses sizeof(hdr) where the surrounding code uses sizeof(*hdr): if (!vevent_for_lost_events_header(cur) && sizeof(hdr) + cur->data_len > count - done) { hdr is declared as struct iommufd_vevent_header *, so sizeof(hdr) evaluates to the size of the pointer. Surrounding code uses sizeof(*hdr) consistently: if (done >= count || sizeof(*hdr) > count - done) { ... if (copy_to_user(buf + done, hdr, sizeof(*hdr))) { ... done += sizeof(*hdr); struct iommufd_vevent_header is currently 8 bytes (two __u32 fields, flags and sequence), so on 64-bit (sizeof(void *) == 8) the two expressions happen to be equal and the check works as intended. On 32-bit (sizeof(void *) == 4) the check under-counts the header by 4 bytes: a vEVENT whose data_len causes 8 + cur->data_len to exceed count - done while 4 + cur->data_len does not will pass the check, then the loop will copy_to_user 8 bytes of header followed by data_len bytes of payload, writing past the user-supplied buffer. It is also a latent bug for any future expansion of struct iommufd_vevent_header beyond sizeof(void *) on 64-bit; the check should not depend on the type happening to match the host pointer width. Use sizeof(*hdr) to match the rest of the function and the actual amount that will be copied. Fixes: e36ba5ab808e ("iommufd: Add IOMMUFD_OBJ_VEVENTQ and IOMMUFD_CMD_VEVENTQ_ALLOC") Link: https://patch.msgid.link/r/20260430175630.67078-1-kai.aizen.dev@gmail.com Cc: stable@vger.kernel.org Reported-by: Kai Aizen Signed-off-by: Kai Aizen Reviewed-by: Kevin Tian Reviewed-by: Nicolin Chen Reviewed-by: Lu Baolu Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 50612ce318b1c156e920c69e5571897f9bedb49e Author: Weinan Liu Date: Thu May 28 22:31:47 2026 +0000 iommu/amd: Don't split flush for amd_iommu_domain_flush_all() commit 69fe699afe1afcb730164b86c228483c2da05f94 upstream. We have observed multiple full invalidations occurring during device detach when we are done using the vfio-device. blocked_domain_attach_device() -> detach_device() -> amd_iommu_domain_flush_all() -> amd_iommu_domain_flush_pages(..., CMD_INV_IOMMU_ALL_PAGES_ADDRESS) while (size != 0) { -> __domain_flush_pages( flush_size /* power of 2 flush_size */) -> domain_flush_pages_v1() -> build_inv_iommu_pages() -> build_inv_address() } build_inv_address() will trigger a full invalidation if the chunk size > (1 << 51). Consequently, the guest will issue multiple full invalidations for a single call to amd_iommu_domain_flush_all() Without this patch, we will see 10 time instead of 1 time full invalidations for every amd_iommu_domain_flush_all(). Cc: stable@vger.kernel.org Fixes: a270be1b3fdf ("iommu/amd: Use only natural aligned flushes in a VM") Suggested-by: Josef Bacik Suggested-by: Jason Gunthorpe Signed-off-by: Weinan Liu Reviewed-by: Wei Wang Reviewed-by: Jason Gunthorpe Reviewed-by: Samiullah Khawaja Reviewed-by: Suravee Suthikulpanit Reviewed-by: Vasant Hegde Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit bb354384f40bb087e7c44f0f0743a23fc945f91d Author: Lu Baolu Date: Thu Jun 4 14:03:06 2026 +0800 iommu/vt-d: Avoid WARNING in sva unbind path commit 534b5f98ab7319d8004bbc7dab6481462243e883 upstream. The Intel IOMMU driver allows SVA on devices even if they do not support PCI/PRI. Commit 39c20c4e83b9 ("iommu/vt-d: Only handle IOPF for SVA when PRI is supported") modified the SVA bind path to allow this configuration by skipping IOPF enablement when PRI is missing. However, it failed to update the unbind path. This creates an imbalance: the unbind path attempts to disable IOPF for a device that never had it enabled, triggering a WARNING in intel_iommu_disable_iopf(): WARNING: drivers/iommu/intel/iommu.c:3475 at intel_iommu_disable_iopf+0x4f/0x90d Call Trace: blocking_domain_set_dev_pasid+0x50/0x70 iommu_detach_device_pasid+0x89/0xc0 iommu_sva_unbind_device+0x73/0x150 xe_vm_close_and_put+0x4d2/0x1200 [xe] Fix this by bypassing IOPF operations for SVA domains on non-PRI hardware in both the bind and unbind paths. Fixes: 39c20c4e83b9 ("iommu/vt-d: Only handle IOPF for SVA when PRI is supported") Cc: stable@vger.kernel.org Reported-by: Nareshkumar Gollakoti Signed-off-by: Lu Baolu Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20260519052917.3729796-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 037ec8353711c79353b12d5634e0c9ff363a9efa Author: Eric Biggers Date: Fri May 29 16:32:08 2026 -0700 crypto: loongson - Remove broken and unused loongson-rng commit af3d1bb9a09daf928fc3f173689fb7904d6a6d4f upstream. The loongson-rng rng_alg has several vulnerabilities, including not providing forward security, and a use-after-free bug due to the use of wait_for_completion_interruptible(). Meanwhile, the rng_alg framework doesn't really have any purpose in the first place other than to access the software algorithms crypto/drbg.c and crypto/jitterentropy.c. Hardware-specific rng_algs have no in-kernel user, and unlike hwrng there's no feed into the actual Linux RNG. As such, there's really no point to this code. There are of course other rng_alg drivers that are similarly unused, but they're similarly in the process of being phased out, e.g. https://lore.kernel.org/r/20260529193648.18172-1-ebiggers@kernel.org and https://lore.kernel.org/r/20260529220430.34135-1-ebiggers@kernel.org Given that, there's no point in fixing forward these vulnerabilities, and it makes much more sense to simply roll back the addition of this driver. If this platform provides TRNG (not PRNG) functionality, it could make sense to add a hwrng driver, but it would be quite different. Link: https://lore.kernel.org/linux-crypto/20260525145939.GC2018@quark/ Fixes: 766b2d724c8d ("crypto: loongson - add Loongson RNG driver support") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 6bbe2000d9f9ffb828764eb6356e8c82feec6e1f Author: Zenghui Yu Date: Sun Jun 28 18:11:18 2026 +0800 selftests/mm: pagemap_ioctl: use the correct page size for transact_test() commit dccf636bf1e68c3fda92f0c9e1018ab7e0ac8b2c upstream. There are several places in transact_test() where we use the hardcoded 0x1000 (4k) as page size, which is not always correct for architectures supporting multiple page sizes. Switch to use the correct page size. Otherwise ./ksft_pagemap.sh on a 16k-page-size arm64 box fails with $ ./ksft_pagemap.sh [...] # ok 96 mprotect_tests Both pages written after remap and mprotect # ok 97 mprotect_tests Clear and make the pages written # Bail out! ioctl failed # # Planned tests != run tests (117 != 97) # # Totals: pass:97 fail:0 xfail:0 xpass:0 skip:0 error:0 # [FAIL] not ok 1 pagemap_ioctl # exit=1 # SUMMARY: PASS=0 SKIP=0 FAIL=1 1..1 Link: https://lore.kernel.org/20260628101118.35861-1-zenghui.yu@linux.dev Fixes: 46fd75d4a3c9 ("selftests: mm: add pagemap ioctl tests") Signed-off-by: Zenghui Yu Cc: Muhammad Usama Anjum Cc: David Hildenbrand Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Zenghui Yu Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 5c942ad7df75925ee166e7f0fb36892d8dde376b Author: Pedro Falcato Date: Thu Jun 25 16:38:53 2026 +0100 mm: do file ownership checks with the proper mount idmap commit e187bc02f8fa4226d62814592cf064ee4557c470 upstream. Ever since idmapped mounts were introduced, inode ownership checks (for side-channel protection) in mincore() and madvise(MADV_PAGEOUT) were done against the nop_mnt_idmap, which completely ignores the file's mount's idmap. This results in odd edgecases like: 1) mount/bind-mount with an idmap userA:userB:1 2) userB runs an owner_or_capable() check on file that is owned by userA on-disk/in-memory, but owned by userB after idmap translation 3) owner_or_capable() mysteriously fails as the correct idmap wasn't supplied In the case of mincore/madvise MADV_PAGEOUT, this is usually benign, because file_permission(file, MAY_WRITE) will probably succeed, as it uses the proper idmap internally, but it does not need to be the case on e.g a 0444 file where even the owner itself doesn't have permissions to write to it. Since this is clearly not trivial to get right, introduce a file_owner_or_capable() that can carry the correct semantics, and switch the various users in mm to it. The issue was found by manual code inspection & an off-list discussion with Jan Kara. Link: https://lore.kernel.org/20260625153853.913949-1-pfalcato@suse.de Fixes: 9caccd41541a ("fs: introduce MOUNT_ATTR_IDMAP") Signed-off-by: Pedro Falcato Reviewed-by: Jan Kara Reviewed-by: Christian Brauner (Amutable) Acked-by: David Hildenbrand (Arm) Cc: Al Viro Cc: Jann Horn Cc: Liam R. Howlett Cc: Matthew Wilcox (Oracle) Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 8dcaa0f87a88d720d13106f3a306c6b61d189d86 Author: Ketan Date: Tue Jun 23 02:48:04 2026 +0530 mm: page_ext: add count limit to page_ext_iter_next to prevent invalid PFN access commit ffd017237cfe99e6e5602ab14179b0e6878a0840 upstream. The page_ext iteration API does not validate if the PFN still belongs to a valid section while advancing the iterator. When dynamically adding memory in the hotplug path, it can lead to a NULL pointer dereference during page_ext_lookup at the boundary of the last valid section when iterator count equals __pgcount. The for_each_page_ext() macro calls page_ext_iter_next() as its loop increment. for_each_page_ext() does a "__page_ext = page_ext_iter_next(&__iter)" at the end. This causes page_ext_iter_next() to increment iter->index past __pgcount and call page_ext_lookup(start_pfn + __pgcount). During memory hotplug (online), the PFN at start_pfn + __pgcount may belong to a section that has not yet been initialized, causing page_ext_lookup() to trigger a NULL pointer dereference. [ 14.555124][ T846] Call trace: [ 14.555125][ T846] lookup_page_ext+0x6c/0x108 (P) [ 14.555127][ T846] page_ext_lookup+0x30/0x3c [ 14.555129][ T846] __reset_page_owner+0x11c/0x260 [ 14.571201][ T846] __free_pages_ok+0x5e8/0x8e0 [ 14.571204][ T846] __free_pages_core+0x78/0xf0 [ 14.571206][ T846] generic_online_page+0x14/0x24 [ 14.597782][ T846] online_pages+0x178/0x30c [ 14.597784][ T846] memory_block_change_state+0x284/0x32c [ 14.597787][ T846] memory_subsys_online+0x4c/0x64 [ 14.597789][ T846] device_online+0x88/0xb0 [ 14.597791][ T846] online_memory_block+0x30/0x40 [ 14.597793][ T846] walk_memory_blocks+0xac/0xe8 [ 14.597794][ T846] add_memory_resource+0x280/0x298 [ 14.656161][ T846] add_memory+0x60/0x98 Move the iteration boundary enforcement inside the iterator functions, so callers cannot inadvertently access beyond the requested range. Link: https://lore.kernel.org/20260623-page_ext-v3-1-a89799a5367c@oss.qualcomm.com Fixes: 9039b9096ea2 ("mm: page_ext: add an iteration API for page extensions") Signed-off-by: Ketan Kishore Suggested-by: David Hildenbrand Suggested-by: Matthew Wilcox Acked-by: Zi Yan Acked-by: David Hildenbrand (Arm) Cc: Brendan Jackman Cc: Johannes Weiner Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Luiz Capitulino Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 785ebd42b8b50dc13f3b705cd72352a82027ef38 Author: David Hildenbrand (Arm) Date: Thu Jun 11 12:01:55 2026 +0200 selftests: mm: fix and speedup "droppable" test commit cc13a7a618fe8354f16d74c06aaf9565a68e9ebd upstream. The droppable test currently relies on creating memory pressure in a child process to trigger dropping the droppable pages. That not only takes a long time on some machines (allocating and filling all that memory), on large machines this will not work as we hardcode the area size to 134217728 bytes. ... further, we rely on timeouts to detect that memory was not dropped, which is really suboptimal. Instead, let's just use MADV_PAGEOUT on a 2 MiB region. MADV_PAGEOUT works with droppable memory even without swap. There is the low chance of MADV_PAGEOUT failing to drop a page because of speculative references. We'll wait 1s and retry 10 times to rule that unlikely case out as best as we can. On a machine without swap: $ ./droppable TAP version 13 1..1 ok 1 madvise(MADV_PAGEOUT) behavior # Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0 Link: https://lore.kernel.org/20260611-droppable_test-v1-1-b6a73d99f658@kernel.org Fixes: 9651fcedf7b9 ("mm: add MAP_DROPPABLE for designating always lazily freeable mappings") Signed-off-by: David Hildenbrand (Arm) Reported-by: Aishwarya TCV Tested-by: Sarthak Sharma Tested-by: Lance Yang Reviewed-by: Dev Jain Reviewed-by: SeongJae Park Tested-by: Lorenzo Stoakes Reviewed-by: Lorenzo Stoakes Reviewed-by: Jason A. Donenfeld Cc: Anthony Yznaga Cc: Liam R. Howlett Cc: Mark Brown Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 279c2fa731122652ce9aace16dba1b575dbf5bc5 Author: Anthony Yznaga Date: Wed Apr 15 20:39:37 2026 -0700 mm: fix mmap errno value when MAP_DROPPABLE is not supported commit d86c9e971af2315119a78c564a802fafcebf1b6b upstream. Patch series "fix MAP_DROPPABLE not supported errno", v4. Mark Brown reported seeing a regression in -next on 32 bit arm with the mlock selftests. Before exiting and marking the tests failed, the following message was logged after an attempt to create a MAP_DROPPABLE mapping: Bail out! mmap error: Unknown error 524 It turns out error 524 is ENOTSUPP which is an error that userspace is not supposed to see, but it indicates in this instance that MAP_DROPPABLE is not supported. The first patch changes the errno returned to EOPNOTSUPP. The second patch is a second version of a prior patch to introduce selftests to verify locking behavior with droppable mappings with the additional change to skip the tests when MAP_DROPPABLE is not supported. The third patch fixes the MAP_DROPPABLE selftest so that it is run by the framework and skips if MAP_DROPPABLE is not supported. This patch (of 3): On configs where MAP_DROPPABLE is not supported (currently any 32-bit config except for PPC32), mmap fails with errno set to ENOTSUPP. However, ENOTSUPP is not a standard error value that userspace knows about. The acceptable userspace-visible errno to use is EOPNOTSUPP. checkpatch.pl has a warning to this effect. Link: https://lore.kernel.org/20260416033939.49981-1-anthony.yznaga@oracle.com Link: https://lore.kernel.org/20260416033939.49981-2-anthony.yznaga@oracle.com Fixes: 9651fcedf7b9 ("mm: add MAP_DROPPABLE for designating always lazily freeable mappings") Signed-off-by: Anthony Yznaga Acked-by: David Hildenbrand (Arm) Acked-by: Vlastimil Babka (SUSE) Reported-by: Mark Brown Reviewed-by: Pedro Falcato Reviewed-by: Lorenzo Stoakes (Oracle) Cc: Jann Horn Cc: Jason A. Donenfeld Cc: Liam Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 4d730cab96e6b75e4a07c4baf37294ebc07f795e Author: Vivian Wang Date: Tue Mar 3 13:29:49 2026 +0800 riscv: mm: Unconditionally sfence.vma for spurious fault commit 1b2c6b56a9fa0dcbef461039937de22b1cbecc7d upstream. Svvptc does not guarantee that it's safe to just return here. Since we have already cleared our bit, if, theoretically, the bounded timeframe for the accessed page to become valid still hasn't happened after sret, we could fault again and actually crash. Hopefully, these spurious faults should be rare enough that this is an acceptable slowdown. Cc: stable@vger.kernel.org Fixes: 503638e0babf ("riscv: Stop emitting preventive sfence.vma for new vmalloc mappings") Signed-off-by: Vivian Wang Link: https://patch.msgid.link/20260303-handle-kfence-protect-spurious-fault-v2-5-f80d8354d79d@iscas.ac.cn Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit 90405c8822c5d45d4d546e94914a8e3f19f36768 Author: Vivian Wang Date: Sat Jun 6 20:17:54 2026 -0600 riscv: mm: Define DIRECT_MAP_PHYSMEM_END commit f3336b48cf9d3f2d1fc78e3289c0ded2f00876ee upstream. On RISC-V, the actual mappable range of physical address space is dependent on the current MMU mode i.e. satp_mode (See Documentation/arch/riscv/vm-layout.rst). Define the DIRECT_MAP_PHYSMEM_END macro based on the existing virtual address space layout macros to expose this information to get_free_mem_region(). Otherwise, it returns a region that couldn't be mapped, which breaks ZONE_DEVICE. Cc: stable@vger.kernel.org # v6.13+ Tested-by: Han Gao # SG2044 Signed-off-by: Vivian Wang Link: https://patch.msgid.link/20260309-riscv-sparsemem-vmemmap-limits-v1-2-f40efe18e3cd@iscas.ac.cn Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit 1c8889e0db01fe5393e71c69cffddfe3f0f49d24 Author: Koichiro Den Date: Wed Mar 4 17:30:27 2026 +0900 NTB: epf: Fix request_irq() unwind in ntb_epf_init_isr() commit fcba26efe5efc7441f5505f4ccc69791214b40be upstream. ntb_epf_init_isr() requests multiple MSI/MSI-X vectors in a loop. If request_irq() fails part-way through, it jumps straight to pci_free_irq_vectors() without freeing already requested IRQs. Fix the error path by freeing any successfully requested IRQs before releasing the vectors. 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: Dave Jiang Cc: stable@vger.kernel.org # v5.12+ Link: https://patch.msgid.link/20260304083028.1391068-2-den@valinux.co.jp Signed-off-by: Greg Kroah-Hartman commit 33c0b96d7e1672be1de0053786637ea46fb81507 Author: Bryam Vargas Date: Fri Jun 12 14:29:06 2026 -0500 exfat: bound uniname advance in exfat_find_dir_entry() commit 3a1230e7b043c62737b05a3e9275ca83a43ad20a upstream. In exfat_find_dir_entry(), each TYPE_EXTEND (file name) entry advances the output pointer by a fixed amount while the loop guard only tracks the accumulated name length: if (++order == 2) uniname = p_uniname->name; else uniname += EXFAT_FILE_NAME_LEN; len = exfat_extract_uni_name(ep, entry_uniname); name_len += len; unichar = *(uniname+len); *(uniname+len) = 0x0; uniname grows by EXFAT_FILE_NAME_LEN (15) per name entry, but name_len grows only by the actual extracted length, which is shorter when a name fragment contains an early NUL. The only guard is `name_len >= MAX_NAME_LENGTH`, so a crafted directory with many short name fragments lets uniname run far past the p_uniname->name[MAX_NAME_LENGTH + 3] buffer while name_len stays small, causing an out-of-bounds read and write at *(uniname+len). The sibling extractor exfat_get_uniname_from_ext_entry() already stops on a short fragment (the lockstep `len != EXFAT_FILE_NAME_LEN` guard added in commit d42334578eba ("exfat: check if filename entries exceeds max filename length")); exfat_find_dir_entry() never got the equivalent. Track the per-entry write offset as a count and reject a fragment once the offset, or the offset plus the extracted length, would exceed MAX_NAME_LENGTH, before forming the output pointer. Fixes: ca06197382bd ("exfat: add directory operations") Cc: stable@vger.kernel.org Suggested-by: Namjae Jeon Signed-off-by: Bryam Vargas Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit a82e170637e050a803b4f37542371ef216bf66d2 Author: Andrii Kuchmenko Date: Mon May 18 17:32:33 2026 +0300 module: decompress: check return value of module_extend_max_pages() commit 786d2d84416a9a1c1a47b71a68d679d886284be2 upstream. module_extend_max_pages() calls kvrealloc() internally and returns -ENOMEM on allocation failure. The return value is never checked. If the initial allocation fails, info->pages remains NULL and info->max_pages remains 0. Subsequent calls to module_get_next_page() will attempt to dynamically grow the array by calling module_extend_max_pages(info, 0) since info->used_pages is 0. This results in kvrealloc(NULL, 0) returning ZERO_SIZE_PTR, which is treated as a success, leading to a dereference of ZERO_SIZE_PTR and a kernel oops. Fix: add the missing error check after module_extend_max_pages() and return immediately on failure. This matches the pattern used by every other kvrealloc() caller in the module loading path. Fixes: b1ae6dc41eaa ("module: add in-kernel support for decompressing") Cc: Dmitry Torokhov Cc: Luis Chamberlain Cc: stable@vger.kernel.org Signed-off-by: Andrii Kuchmenko Reviewed-by: Christophe Leroy (CS GROUP) [Sami: Corrected the analysis in the commit message.] Signed-off-by: Sami Tolvanen Signed-off-by: Greg Kroah-Hartman commit b883733302508be1c678ce90b63d6b403f849995 Author: Gabriele Monaco Date: Wed Jun 10 11:04:29 2026 +0200 rqspinlock: Fix order in raw_res_spin_(un)lock_irq to allow schedule commit b48bd16eb9fc57a463a337ca148516cdf3212d61 upstream. raw_res_spin_unlock_irqrestore() calls raw_res_spin_unlock() and then restores interrupts, this means preemption is enabled when interrupts are still disabled (as part of raw_res_spin_unlock()) so this cannot trigger an actual preemption. This is inconsistent with other spinlock implementations (raw_spin_unlock_irqrestore() and bpf_res_spin_unlock_irqrestore() itself). Adjust the macro to ensure interrupts are enabled before enabling preemption, allowing to schedule at that point. Make the same modification in the error path of raw_res_spin_lock_irqsave(). Fixes: 101acd2e78b1 ("rqspinlock: Add macros for rqspinlock usage") Cc: stable@vger.kernel.org Acked-by: Arnd Bergmann # asm-generic Acked-by: Waiman Long Acked-by: Kumar Kartikeya Dwivedi Signed-off-by: Gabriele Monaco Link: https://lore.kernel.org/r/20260610090431.32427-1-gmonaco@redhat.com Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit a937e92c1d00534b5c2e3e9f4381b7e988180797 Author: Benjamin Coddington Date: Thu Jun 11 17:02:15 2026 -0400 NFSv4: include MAY_WRITE in open permission mask for O_TRUNC commit 5140f099ecd8a2f2808b7f7b720ee1bad8468974 upstream. POSIX requires write permission to truncate a file, so an open() that specifies O_TRUNC must be authorized for write access regardless of the O_ACCMODE access mode. nfs_open_permission_mask() builds the access mask passed to nfs_may_open(), which is the local authorization gate for OPENs the client serves itself from a cached write delegation via the can_open_delegated() path in nfs4_try_open_cached(). The mask is derived from O_ACCMODE alone, so an open(O_RDONLY | O_TRUNC) against a file the caller cannot write requests only MAY_READ and passes the local check. The OPEN is then satisfied locally and the truncation is issued to the server as a SETATTR(size=0) over the delegation stateid, which the server accepts under standard write-delegation semantics. POSIX requires that this open fail with EACCES. Include MAY_WRITE in the mask whenever O_TRUNC is set so the local check matches the access the server would have enforced. Suggested-by: Trond Myklebust Fixes: af22f94ae02a ("NFSv4: Simplify _nfs4_do_access()") Cc: stable@vger.kernel.org Signed-off-by: Benjamin Coddington Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 75ca99875aa4e2241a0a3f5bfd2d03b44d93933d Author: Ricardo Robaina Date: Thu Jul 2 11:04:11 2026 -0300 audit: fix potential integer overflow in audit_log_n_hex() commit 65dfde57d1e29ce2b76fc23dd565eccd5c0bc0f0 upstream. The function calculates new_len as len << 1 for hex encoding. This has two overflow risks: the shift itself can overflow when len is large, and the result can be truncated when assigned to new_len (declared as int) from the size_t calculation. Fix by using check_shl_overflow() to catch shift overflow and changing new_len and loop counter i to size_t to prevent truncation. Cc: stable@vger.kernel.org Fixes: 168b7173959f ("AUDIT: Clean up logging of untrusted strings") Reviewed-by: Richard Guy Briggs Signed-off-by: Ricardo Robaina [PM: remove vertical whitspace noise] Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 2dad64a97e1df47f5d9ccb17fa319aa348617226 Author: Huihui Huang Date: Wed Jul 1 18:28:46 2026 +0800 tracing: Prevent out-of-bounds read in glob matching commit 0a6070839b1ef276d5b05bedfb787743e140fb17 upstream. String event fields are not necessarily NUL-terminated, so the filter predicate functions (filter_pred_string(), filter_pred_strloc() and filter_pred_strrelloc()) pass the field length to the regex match callbacks, and the length-aware matchers honour it. regex_match_glob() was the exception: it ignored the length and called glob_match(), which scans the string until it hits a NUL byte. Some string fields are not NUL-terminated. One example is the dynamic char array of the xfs_* namespace tracepoints, which is copied without a trailing NUL. For such a field, glob matching reads past the end of the event field, causing a KASAN slab-out-of-bounds read in glob_match(), reached via regex_match_glob() and filter_match_preds() from the xfs_lookup tracepoint. Add a length-bounded glob_match_len() and use it from regex_match_glob() so glob matching always stops at the field boundary. The matching loop is factored into a shared helper so glob_match() keeps its behaviour. Fixes: 60f1d5e3bac4 ("ftrace: Support full glob matching") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/da1aaf125fc3b63320b0c540fd6afa7c3d5b4f1a.1782836943.git.hhhuang@smu.edu.sg 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: Huihui Huang Signed-off-by: Ren Wei Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit c8b7e113f7b61eef2f017e6329c27c2331058c5a Author: Lee Jia Jie Date: Thu Jul 9 21:56:19 2026 +0800 perf/aux: Fix page UAF in map_range() commit 5948aaf64f81f217a25dcc2bf6c0779bca19566c upstream. map_range() reads rb->aux_pages[], rb->aux_nr_pages and rb->aux_pgoff via perf_mmap_to_page() while holding only event->mmap_mutex. Those fields are serialized by rb->aux_mutex, and mmap_mutex is per event. Thus, two events sharing one rb via PERF_EVENT_IOC_SET_OUTPUT can race rb_alloc_aux() with map_range(), leading to a page-UAF scenario as follows: CPU 0 CPU 1 ===== ===== rb_alloc_aux() map_range() [1]: allocate rb->aux_pages[0] [2]: rb->aux_nr_pages++ [3]: perf_mmap_to_page() returns rb->aux_pages[0] [4]: map it as VM_PFNMAP [5]: rb->aux_pgoff = 1 munmap the page [6]: free rb->aux_pages[0] Pages mapped as VM_PFNMAP have no refcount protection, so CPU 1 holds a mapping to a freed physical frame. Fix this by taking rb->aux_mutex across the page walk in map_range(). Fixes: b709eb872e19 ("perf: map pages in advance") Signed-off-by: Lee Jia Jie Signed-off-by: Ingo Molnar Cc: stable@vger.kernel.org Cc: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: Namhyung Kim Signed-off-by: Greg Kroah-Hartman commit af6048e913052dd59a6faa59e7c53ce627360ebc Author: Johan Hovold Date: Mon May 11 16:37:07 2026 +0200 i2c: core: fix hang on adapter registration failure commit 3c7e164344e5bcf6f274bbf59a3274f5caad9bc1 upstream. Clients may be registered from bus notifier callbacks when the adapter is registered. On a subsequent error during registration, the adapter references taken by such clients prevent the wait for the references to be released from ever completing. Fix this by refactoring client deregistration and deregistering also on late adapter registration failures. Fixes: f8756c67b3de ("i2c: core: call of_i2c_setup_smbus_alert in i2c_register_adapter") Cc: stable@vger.kernel.org # 4.15 Cc: Phil Reid Signed-off-by: Johan Hovold Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 22cb337370e6539b0418832c6040e9b00c1b74ca Author: Wentao Liang Date: Wed May 27 10:48:50 2026 +0000 regulator: scmi: fix of_node refcount leak in scmi_regulator_probe() commit fa11039d6cdff84584a3ef8cc1f5e1b56e045da2 upstream. scmi_regulator_probe() calls of_find_node_by_name() which takes a reference on the returned device node. On the error path where process_scmi_regulator_of_node() fails, the function returns without calling of_node_put() on the child node, leaking the reference. Add of_node_put(np) on the error path to properly release the reference. Cc: stable@vger.kernel.org Fixes: 0fbeae70ee7c ("regulator: add SCMI driver") Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260527104850.872415-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6b01ed165d2982a64ba75f86aa2cabac0b8697ef Author: Janne Grunau Date: Wed Dec 31 13:07:21 2025 +0100 watchdog: apple: Add "apple,t8103-wdt" compatible commit 14ca4868886f2188401fe06cd7bf01a330b3fb99 upstream. After discussion with the devicetree maintainers we agreed to not extend lists with the generic compatible "apple,wdt" anymore [1]. Use "apple,t8103-wdt" as base compatible as it is the SoC the driver and bindings were written for. [1]: https://lore.kernel.org/asahi/12ab93b7-1fc2-4ce0-926e-c8141cfe81bf@kernel.org/ Fixes: 4ed224aeaf66 ("watchdog: Add Apple SoC watchdog driver") Cc: stable@vger.kernel.org Reviewed-by: Neal Gompa Signed-off-by: Janne Grunau Link: https://lore.kernel.org/r/20251231-watchdog-apple-t8103-base-compat-v1-1-1702a02e0c45@jannau.net Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit f4dd5621a6eefd16666352ce90ec46920aa0737e Author: Vasily Khoruzhick Date: Tue Apr 14 11:17:16 2026 -0700 EDAC/i10nm: Don't fail probing if ADXL is missing commit e360a6d65bb46c527a5909430a31d640cdd5036e upstream. ADXL is not present in Coreboot- or Slimbootloader-based BIOSes and as result, the driver fails to probe there. Since commit 2738c69a8813 ("EDAC/i10nm: Add driver decoder for Ice Lake and Tremont CPUs"), i10nm_edac supports driver decoder. Switch to driver decoding when ADXL is not present. Signed-off-by: Vasily Khoruzhick Signed-off-by: Tony Luck Reviewed-by: Qiuxu Zhuo Cc: stable@vger.kernel.org # v6.1+ Link: https://patch.msgid.link/20260414181735.87023-1-anarsoul@gmail.com Signed-off-by: Greg Kroah-Hartman commit add1e4112e00b619614784bf630aeebfdefa23e1 Author: David Hildenbrand (Arm) Date: Wed Apr 29 12:49:14 2026 +0200 x86/mm: Fix freeing of PMD-sized vmemmap pages commit 39406c05f8f150f1685839acd38ffdd69ff92031 upstream. Commit bf9e4e30f353 ("x86/mm: use pagetable_free()"), switched from freeing non-boot page tables through __free_pages() to pagetable_free(). However, the function is also called to free vmemmap pages. Given that vmemmap pages are not page tables, already the page_ptdesc(page) is wrong. But worse, pagetable_free() calls: __free_pages(page, compound_order(page)); Since vmemmap pages are not compound pages (see vmemmap_alloc_block()) -- except for HVO, which doesn't apply here -- only first page of a PMD-sized vmemmap page is freed, leaking the other ones. Fix it by properly decoupling pagetable and vmemmap freeing. free_pagetable() no longer has to mess with SECTION_INFO, as only the vmemmap is marked like that in register_page_bootmem_memmap(). The indentation in remove_pmd_table() is messed up. Fix that while touching it. Bootmem info handling will soon be fixed up. For now, handle it similar to free_pagetable(), just avoiding the ifdef. [ dhansen: changelog munging. More imperative voice ] Fixes: bf9e4e30f353 ("x86/mm: use pagetable_free()") Signed-off-by: David Hildenbrand (Arm) Signed-off-by: Andrew Morton Signed-off-by: Dave Hansen Acked-by: Mike Rapoport (Microsoft) Tested-by: Lance Yang Link: https://lore.kernel.org/20260429-vmemmap-v2-1-8dfcacffd877@kernel.org Link: https://patch.msgid.link/20260429-vmemmap-v2-1-8dfcacffd877@kernel.org Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 808033d80d5c9f8adf7e8de9317389270ce13430 Author: Carlos Song Date: Mon May 25 14:23:57 2026 +0800 spi: fsl-lpspi: terminate the RX channel on TX prepare failure path commit 01980b5da56e573d62798d0ff6c86bcaa2b22cbe upstream. When dmaengine_prep_slave_sg() fails for the TX channel, the error path terminates the TX DMA channel but leaves the RX channel running. Since the RX channel was already submitted and issued prior to preparing the TX descriptor, returning -EINVAL causes the SPI core to unmap the DMA buffers while the RX DMA engine continues writing to them, leading to potential memory corruption or use-after-free. Terminate the RX channel before returning on the TX prepare failure path. Fixes: 09c04466ce7e ("spi: lpspi: add dma mode support") Cc: stable@vger.kernel.org Signed-off-by: Carlos Song Link: https://patch.msgid.link/20260525062357.3191349-3-carlos.song@oss.nxp.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 18d6048b1b1b4bc37c8883a39289f4b5c9a6fd5f Author: Carlos Song Date: Mon May 25 14:23:56 2026 +0800 spi: fsl-lpspi: replace dmaengine_terminate_all() with dmaengine_terminate_sync() commit e703ce47691b967fe9b4057fb1d062273211afa9 upstream. dmaengine_terminate_all() has been deprecated, so replace it with dmaengine_terminate_sync(). Fixes: 09c04466ce7e ("spi: lpspi: add dma mode support") Cc: stable@vger.kernel.org Signed-off-by: Carlos Song Link: https://patch.msgid.link/20260525062357.3191349-2-carlos.song@oss.nxp.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 75422f5e50222fa056cb8d0a837cd869892e7751 Author: Mark Rutland Date: Wed Jun 3 12:06:12 2026 +0100 arm64: fpsimd: Fix type mismatch in sme_{save,load}_state() commit 247bd153905085c18ff9006cca1ccb96dfd18e7f upstream. The sme_save_state() and sme_load_state() functions take a 32-bit int argument that describes whether to save/restore ZT0. Their assembly implementations consume the entire 64-bit register containing this 32-bit value, and will attempt to save/restore ZT0 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 ZT0, 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. Fixes: 95fcec713259 ("arm64/sme: Implement context switching for ZT0") 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 93f000e89976eb5cc55385d80516f247ca4a27a6 Author: Paul Louvel Date: Thu May 7 16:41:57 2026 +0200 crypto: talitos/hash - fix SEC2 64k - 1 ahash request limitation commit 6e12daff6ec125102a6fdcafc5aa7199f7ce8933 upstream. The problem described in commit 655ef638a2bc ("crypto: talitos - fix SEC1 32k ahash request limitation") also apply for the SEC2 hardware, but with a limitation of 64k - 1 bytes. Split ahash_done() into SEC1 and SEC2 paths: SEC1 continues to free the whole descriptor list at once, while SEC2 now iterates through descriptors one by one, submitting the next only after the previous completes, which is required since SEC2 cannot chain descriptors in hardware. Cc: stable@vger.kernel.org Fixes: c662b043cdca ("crypto: af_alg/hash: Support MSG_SPLICE_PAGES") Signed-off-by: Paul Louvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit fda9cb9b7191c981877ff7927aade2e26b841ec3 Author: Paul Louvel Date: Thu May 7 16:41:56 2026 +0200 crypto: talitos/hash - remove useless wrapper commit 907ae6088c82c9abae2d26477fddd60df6ad003b upstream. ahash_process_req() was a wrapper used in commit 655ef638a2bc ("crypto: talitos - fix SEC1 32k ahash request limitation"). Rename ahash_process_req_one() to ahash_process_req() and remove the wrapper. Cc: stable@vger.kernel.org Signed-off-by: Paul Louvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 99cc3f5511d8ba9d39cc60c46e9f82cadac7dfeb Author: Paul Louvel Date: Thu May 7 16:41:55 2026 +0200 crypto: talitos/hash - rename first_desc/last_desc to first_request/last_request commit 8bcf00671400ac3b3a4cc3011e6c1496dbd880fd upstream. In talitos_ahash_req_ctx and talitos_export_state, the fields first_desc and last_desc describe request-level (not descriptor-level) state. Rename them to first_request and last_request for clarity. last_desc is also removed from talitos_ahash_req_ctx as it is no longer used. Cc: stable@vger.kernel.org Signed-off-by: Paul Louvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit b960edc92c81be0ad008f3808e1ef2f1b26890a6 Author: Paul Louvel Date: Thu May 7 16:41:54 2026 +0200 crypto: talitos/hash - drop workqueue mechanism for SEC1 commit be4802afb1700534e48cb776d0d1e772c27de130 upstream. Now that SEC1 hash uses hardware descriptor chaining instead of a workqueue to process requests exceeding TALITOS1_MAX_DATA_LEN, the workqueue code is no longer needed. Remove sec1_ahash_process_remaining(), the related fields from talitos_ahash_req_ctx (request_bufsl, areq, request_sl, remaining_ahash_request_bytes, current_ahash_request_bytes, sec1_ahash_process_remaining), the dead code in ahash_done(), and simplify ahash_process_req() to call ahash_process_req_one() directly with the original areq->src and areq->nbytes. Cc: stable@vger.kernel.org Signed-off-by: Paul Louvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 042730207a9917949a5ba4704d5bc2c9fb0c4617 Author: Paul Louvel Date: Thu May 7 16:41:53 2026 +0200 crypto: talitos/hash - use descriptor chaining for SEC1 instead of workqueue commit f1ede6d95d8ad3b32c6a552d2baab805bd00fc38 upstream. Rework the SEC1 ahash implementation to build a chain of hardware descriptors, replacing the previous approach of submitting one descriptor at a time via a workqueue, introduced by commit 655ef638a2bc ("crypto: talitos - fix SEC1 32k ahash request limitation"). Introduce ahash_process_req_prepare() which iterates over the request data, allocating enough descriptors to cover the entire ahash request. The new fields (bufsl, src, first, last) are added to talitos_edesc for this purpose. common_nonsnoop_hash() no longer calls talitos_submit(); it only maps and sets up the descriptor. Submission is now done by the caller after the chain is built. ahash_free_desc_list_from() takes over calling common_nonsnoop_hash_unmap() for each descriptor during cleanup. Compared to the workqueue based solution, request are slightly faster since there is no more scheduling latency induced by the workqueue, and only one interrupt is generated by the device at the end of a chain. Commit 655ef638a2bc ("crypto: talitos - fix SEC1 32k ahash request limitation") : $ /usr/libexec/libkcapi/sha256sum ./test_5M.bin 013c5609d63c... ./test_5M.bin real 0m 0.41s user 0m 0.01s sys 0m 0.07s Now : $ /usr/libexec/libkcapi/sha256sum ./test_5M.bin 013c5609d63c... ./test_5M.bin real 0m 0.33s user 0m 0.01s sys 0m 0.20s Tested on a system with an MPC885 SoC featuring the SEC1 Lite. The increase in sys time is due to the fact that commit 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash on SEC1") can no longer be applied. Cc: stable@vger.kernel.org Signed-off-by: Paul Louvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 40a2e90acdb1a0963584c4d48c37dafae08f8410 Author: Paul Louvel Date: Thu May 7 16:41:52 2026 +0200 crypto: talitos/hash - prepare SEC1 descriptor chaining, remove additional descriptor commit 59b5d899e33701665f18abe6bebf987427876e3e upstream. Currently, when SEC1 has buffered data (nbuf != 0), the ahash code creates an additional descriptor on the fly inside common_nonsnoop_hash() to handle the remainder of the data. This approach is incompatible with the arbitrary-length descriptor chaining that follows. Remove the "additional descriptor" logic from common_nonsnoop_hash() and common_nonsnoop_hash_unmap(). Also remove the nbytes adjustment for SEC1 in ahash_edesc_alloc() that subtracted nbuf. Cc: stable@vger.kernel.org Signed-off-by: Paul Louvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit a8decb89920a1562634a68b8f3e9384b72df569e Author: Paul Louvel Date: Thu May 7 16:41:51 2026 +0200 crypto: talitos - move code in current_desc_hdr() into a standalone function commit f8713d9e6091755dd30f7f1cfa25f8440cddf81b upstream. Previously added code in current_desc_hdr() in order to add support for searching an offending descriptor inside a descriptor chain. Move that code into a standalone function to improve readability. Cc: stable@vger.kernel.org Signed-off-by: Paul Louvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit aea8cfbd60da997a59ccebf93045adbb812f8d5a Author: Paul Louvel Date: Thu May 7 16:41:50 2026 +0200 crypto: talitos - move dma mapping code in talitos_submit() into a standalone dma_map_request() function commit 5c0aa8cad7745505297103f05dda3fa06e8ac670 upstream. Previously added code to talitos_submit() in order to map an entire descriptor chain. Move that code into a standalone function to improve readability. Cc: stable@vger.kernel.org Signed-off-by: Paul Louvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 3fa1846f75edff437a7a9a001031a193e9d4629b Author: Paul Louvel Date: Thu May 7 16:41:49 2026 +0200 crypto: talitos - move dma unmapping code in flush_channel() into a standalone dma_unmap_request() function commit 4d9b0b7415b9e79a3d54d18b5ff230974ea78740 upstream. Previously added code to flush_channel() in order to unmap an entire descriptor. Move that code into a standalone function to improve readability. Cc: stable@vger.kernel.org Signed-off-by: Paul Louvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 664e7f16e74fcf73b8ae40cbf9a1e288bb5c4c3a Author: Paul Louvel Date: Thu May 7 16:41:48 2026 +0200 crypto: talitos - add chaining of arbitrary number of descriptor for the SEC1 commit f126384ed55279c3b676f89d5ab547b8de8df782 upstream. The SEC1 hardware can process a chain of descriptors without host intervention. Only the hash implementation currently use this feature, but with a chain of at most 2 descriptors added in commit 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash on SEC1"). Add supports for chaining an arbitrary number of descriptors in a chain. Adapt the ahash implementation to make it compatible. Cc: stable@vger.kernel.org Signed-off-by: Paul Louvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit f52aa95e3cae15311378a24f116224c797b1fa3d Author: Paul Louvel Date: Thu May 7 16:41:47 2026 +0200 crypto: talitos - use dma_sync_single_for_cpu() before reading descriptor header commit e17ff3d6ff907dc8406261e8fd3e1fc8a908f0f6 upstream. In order to know if a descriptor has been processed by the device, the driver polls the FIFO to see if DESC_HDR_DONE is set on a descriptor header to confirm completion. The current code does not make sure that the CPU gets up to date data before reading the descriptor. Fix this by calling dma_sync_single_for_cpu() before reading memory written by the device. Cc: stable@vger.kernel.org Fixes: 58cdbc6d2263 ("crypto: talitos - fix hash on SEC1.") Signed-off-by: Paul Louvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 7584c92f72447b20347ec8e7b6a17fb16b3daa4a Author: Ahsan Atta Date: Wed May 13 17:16:58 2026 +0200 crypto: qat - factor out AER reset helpers commit 56707afb92fee371c0f2e04332c9aa03cdb89793 upstream. Move the shutdown and recovery sequences out of adf_error_detected() and adf_slot_reset() into reset_prepare() and reset_done() helpers. This makes the AER recovery path easier to follow and prepares the common reset flow for reuse by additional PCI reset callbacks without duplicating the logic. No functional change intended. Cc: stable@vger.kernel.org Signed-off-by: Ahsan Atta Reviewed-by: Giovanni Cabiddu Reviewed-by: Damian Muszynski Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 6fb62b767f3e27661e8f8d2f7b85f4e098fcdb1a Author: Giovanni Cabiddu Date: Thu May 28 16:57:44 2026 +0100 crypto: qat - validate RSA CRT component lengths commit b3ac78756588059729b9195fcc9f4b37d54057a5 upstream. The generic RSA key parser (rsa_helper.c) bounds each CRT component (p, q, dp, dq, qinv) by the modulus size n_sz, but qat_rsa_setkey_crt() allocates half-size DMA buffers (key_sz / 2) and right-aligns each component with: memcpy(dst + half_key_sz - len, src, len) When a CRT component is larger than half_key_sz the subtraction underflows and memcpy writes past the DMA buffer, causing memory corruption. Add a len > half_key_sz check next to the existing !len check for each of the five CRT components so the driver falls back to the non-CRT path instead of writing out of bounds. Fixes: 879f77e9071f ("crypto: qat - Add RSA CRT mode") Cc: stable@vger.kernel.org Signed-off-by: Giovanni Cabiddu Reviewed-by: Ahsan Atta Reviewed-by: Laurent M Coquerel Tested-by: Laurent M Coquerel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit fabf364ef9db5c6315205f2eac1d066b7e044cbe Author: Ahsan Atta Date: Wed May 13 17:16:57 2026 +0200 crypto: qat - skip restart for down devices commit 9676657117b79f88c22875680c36d7da84b75eca upstream. Skip the shutdown and restart flow when adf_slot_reset() is entered for a device that is already down. In that case, leave ADF_STATUS_RESTARTING clear and let adf_slot_reset() restore PCI function state without calling adf_dev_up(), re-enabling SR-IOV, or sending restarted notifications. This is in preparation for adding reset_prepare() and reset_done() callbacks in adf_aer.c. Cc: stable@vger.kernel.org Signed-off-by: Ahsan Atta Reviewed-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit c3c5925791cff3b84d313293fd60f384d877d793 Author: Ahsan Atta Date: Wed May 20 13:41:55 2026 +0100 crypto: qat - protect service table iterations with service_lock commit 5c6f845e77ec35f9b7b047cc8f9789bf397cdd3e upstream. The service_table list is protected by service_lock when entries are added or removed (in adf_service_add() and adf_service_remove()), but several functions iterate over the list without holding this lock. A concurrent adf_service_register() or adf_service_unregister() call could modify the list during traversal, leading to list corruption or a use-after-free. Fix this by holding service_lock across all list_for_each_entry() iterations of service_table in adf_dev_init(), adf_dev_start(), adf_dev_stop(), adf_dev_shutdown(), adf_dev_restarting_notify(), adf_dev_restarted_notify(), and adf_error_notifier(). The lock ordering is safe: callers of the static helpers (adf_dev_up() and adf_dev_down()) acquire state_lock before service_lock, and no event_hld callback or service_lock holder ever acquires state_lock in the reverse order. Cc: stable@vger.kernel.org Fixes: d8cba25d2c68 ("crypto: qat - Intel(R) QAT driver framework") Signed-off-by: Ahsan Atta Co-developed-by: Maksim Lukoshkov Signed-off-by: Maksim Lukoshkov Reviewed-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit e310e8dc8ce72f5b314db631bd5e500c95b8fcd7 Author: Ahsan Atta Date: Wed May 13 17:16:55 2026 +0200 crypto: qat - notify fatal error before AER reset preparation commit 6931835f2fdd0cb9b1c7791748d7e67d0749056a upstream. Send fatal error notifications to subsystems and VFs as soon as AER error detection starts, before entering the reset preparation shutdown sequence. This reduces notification latency and ensures peers are informed immediately on fatal detection, rather than after restart-state setup and arbitration teardown. Cc: stable@vger.kernel.org Signed-off-by: Ahsan Atta Reviewed-by: Giovanni Cabiddu Reviewed-by: Damian Muszynski Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 45b65a21edbe0cf93a1e1451cfeefc5d4965deab Author: Ahsan Atta Date: Wed May 13 17:16:54 2026 +0200 crypto: qat - keep VFs enabled during reset commit 57518500053987672050dc2f7bf8a774d5d52fd9 upstream. When a reset is triggered via sysfs, the PCI core invokes the reset_prepare() callback while holding pci_dev_lock(), which includes the PCI configuration space access semaphore. If reset_prepare() calls adf_dev_down(), the call chain adf_dev_stop() -> adf_disable_sriov() -> pci_disable_sriov() attempts to acquire the same semaphore, resulting in a deadlock. Avoid this by skipping pci_disable_sriov() when ADF_STATUS_RESTARTING is set. During reset the PCI topology is preserved, so VF devices remain valid and enumerated across the reset. VF notification and the quiesce handshake via adf_pf2vf_notify_restarting() are still performed unconditionally so that VFs stop submitting work before the PF shuts down. Correspondingly, skip pci_enable_sriov() in adf_enable_sriov() when VFs are already present, since their PCI devices were preserved from before the restart. This is in preparation for adding reset_prepare() and reset_done() callbacks in adf_aer.c. Cc: stable@vger.kernel.org Signed-off-by: Ahsan Atta Reviewed-by: Giovanni Cabiddu Reviewed-by: Damian Muszynski Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 33cfc0ce28ac9f8c228a93dc4f1b70fc7c3d22c0 Author: Ahsan Atta Date: Wed May 13 17:16:59 2026 +0200 crypto: qat - handle sysfs-triggered reset callbacks commit 4627ef7019bc532f992c0723e881811ce12f0a02 upstream. A reset requested through /sys/bus/pci/devices/.../reset invokes the driver reset_prepare() and reset_done() callbacks. The QAT driver does not implement those callbacks today, so the reset proceeds without quiescing the device or bringing it back up afterward, which leaves the device unusable. Hook reset_prepare() and reset_done() into adf_err_handler so the common shutdown and recovery flow also runs for reset. Skip device quiesce if the device is already in a down state. Cc: stable@vger.kernel.org Signed-off-by: Ahsan Atta Reviewed-by: Giovanni Cabiddu Reviewed-by: Damian Muszynski Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 050bded706ee59d86615e8c535232edc55c200e0 Author: Ahsan Atta Date: Wed May 13 17:16:56 2026 +0200 crypto: qat - centralize bus master enable commit e5712ff82947dd02d118cee119ed36cec671d814 upstream. QAT driver currently toggles PCI bus mastering in multiple places (probe paths, and reset callbacks). This makes BME state depend on call ordering and on what PCI command bits were captured in saved PCI config state. Make BME control explicit and deterministic: - remove pci_set_master() from device-specific probe paths - add adf_set_bme() and call it from adf_dev_init() so BME is enabled at one point before device bring-up - drop redundant pci_set_master() and pci_clear_master from adf_aer.c and rely on the unified init path for BME enablement This is in preparation for adding reset_prepare() and reset_done() hooks. In the PCI reset callback flow, the PCI core saves and restores device configuration state around reset_prepare() and reset_done(). This change is needed to ensure that we are able to properly shutdown or reinitialize the device post sysfs triggered resets. Cc: stable@vger.kernel.org Signed-off-by: Ahsan Atta Reviewed-by: Giovanni Cabiddu Suggested-by: Andy Shevchenko Reviewed-by: Andy Shevchenko Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 5337b5cd3608a7d25cd89ce0225f4e020015edfa Author: Eric Biggers Date: Sun Apr 19 23:33:49 2026 -0700 crypto: drbg - Fix the fips_enabled priority boost commit a8a1f93080efc83a9ff8452954429ae379e9e614 upstream. When fips_enabled=1, it seems to have been intended for one of the algorithms defined in crypto/drbg.c to be the highest priority "stdrng" algorithm, so that it is what is used by "stdrng" users. However, the code only boosts the priority to 400, which is less than the priority 500 used in drivers/crypto/caam/caamprng.c. Thus, the CAAM RNG could be used instead. Fix this by boosting the priority by 2000 instead of 200. Fixes: 541af946fe13 ("crypto: drbg - SP800-90A Deterministic Random Bit Generator") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 53d38b93cadc08bcbe6e200bb19d37cb9bec1f1e Author: Eric Biggers Date: Sun Apr 19 23:33:48 2026 -0700 crypto: drbg - Fix drbg_max_addtl() on 64-bit kernels commit 6f49f00c981bbb9ef602966f19bfdbef46b681d2 upstream. On 64-bit kernels, drbg_max_addtl() returns 2**35 bytes. That's too large, for two reasons: 1. SP800-90A says the maximum limit is 2**35 *bits*, not 2**35 bytes. So the implemented limit has confused bits and bytes. 2. When drbg_kcapi_hash() calls crypto_shash_update() on the additional information string, the length is implicitly cast to 'unsigned int'. That truncates the additional information string to U32_MAX bytes. Fix the maximum additional information string length to always be U32_MAX - 1, causing an error to be returned for any longer lengths. Fixes: 541af946fe13 ("crypto: drbg - SP800-90A Deterministic Random Bit Generator") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 23b8b188cb32e5531d0f8d3af9506f8959cb369e Author: Eric Biggers Date: Sun Apr 19 23:33:45 2026 -0700 crypto: drbg - Fix returning success on failure in CTR_DRBG commit 39a31ad9e2a5ed7e9c9c6f711dca96c8c8f5f26b upstream. drbg_ctr_generate() sometimes returns success when it fails, leaving the output buffer uninitialized. Fix it. Fixes: cde001e4c3c3 ("crypto: rng - RNGs must return 0 in success case") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 441ea32cf2755a0dc593557056b00b7caa0651f5 Author: Tycho Andersen (AMD) Date: Mon May 4 10:51:47 2026 -0600 crypto: ccp - Do not initialize SNP for ioctl(SNP_CONFIG) commit 08f0e65e784c4b20e6e620dd4f68d8636073a3d2 upstream. Sashiko notes: > if SEV initialization fails and KVM is actively running normal VMs, could a > userspace process trigger this code path via /dev/sev ioctls (e.g., > SEV_PDH_GEN) and zero out MSR_VM_HSAVE_PA globally? Would the next VMRUN > execution for an active VM trigger a general protection fault and crash the > host? Refuse to re-try initialization if SNP is not already initialized for SNP_CONFIG. This is technically an ABI break: before if SNP initialization failed it could be transparently retriggered by this ioctl, and if no VMs were running, everything worked fine. Hopefully this is enough of a corner case that nobody will notice, but someone does, there are a few options: * do something like symbol_get() for kvm and refuse to initialize if KVM is loaded * check each cpu's HSAVE_PA for non-zero data before re-initializing * once initialization has failed, continue to refuse to initialize until the ccp module is unloaded Fixes: ceac7fb89e8d ("crypto: ccp - Ensure implicit SEV/SNP init and shutdown in ioctls") Reported-by: Sashiko Assisted-by: Gemini:gemini-3.1-pro-preview Link: https://sashiko.dev/#/patchset/20260324161301.1353976-1-tycho%40kernel.org CC: Signed-off-by: Tycho Andersen (AMD) Reviewed-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 92567ed9306d5a3d1b007eb4faeff30cc3ffc3e4 Author: Tycho Andersen (AMD) Date: Mon May 4 10:51:46 2026 -0600 crypto: ccp - Do not initialize SNP for ioctl(SNP_VLEK_LOAD) commit f91e9dbb5845d1e5abf1028e6df57dcf61583e1b upstream. Sashiko notes: > if SEV initialization fails and KVM is actively running normal VMs, could a > userspace process trigger this code path via /dev/sev ioctls (e.g., > SEV_PDH_GEN) and zero out MSR_VM_HSAVE_PA globally? Would the next VMRUN > execution for an active VM trigger a general protection fault and crash the > host? The SEV firmware docs for SNP_VLEK_LOAD note: > On SNP_SHUTDOWN, the VLEK is deleted. That is, the initialization/shutdown wrapper here is pointless, because the firmware immediately throws away the key anyway. Instead, refuse to do anything if SNP has not been previously initialized. This is an ABI break: before, this was a no-op and almost certainly a mistake by userspace, and now it returns -ENODEV. ABI compatibility could be maintained here by simply returning 0 in the check instead. Fixes: ceac7fb89e8d ("crypto: ccp - Ensure implicit SEV/SNP init and shutdown in ioctls") Reported-by: Sashiko Assisted-by: Gemini:gemini-3.1-pro-preview Link: https://sashiko.dev/#/patchset/20260324161301.1353976-1-tycho%40kernel.org CC: Signed-off-by: Tycho Andersen (AMD) Reviewed-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 7a361c74bb12f3398c388905f1d325be642cd36e Author: Tycho Andersen (AMD) Date: Mon May 4 10:51:45 2026 -0600 crypto: ccp - Do not initialize SNP for ioctl(SNP_COMMIT) commit 5a1364da2f04217a36e2fdfa2db4ee025b383a20 upstream. Sashiko notes: > if SEV initialization fails and KVM is actively running normal VMs, could a > userspace process trigger this code path via /dev/sev ioctls (e.g., > SEV_PDH_GEN) and zero out MSR_VM_HSAVE_PA globally? Would the next VMRUN > execution for an active VM trigger a general protection fault and crash the > host? The SNP_COMMIT command does not require the firmware to be in any particular state. Skip initializing it if it was previously uninitialized. The SEV-SNP firmware specification doc 56860 does not mention SNP_COMMIT in Table 5 as a command that is allowed in the UNINIT state, but it is in fact allowed and a future documentation update will reflect that. Fixes: ceac7fb89e8d ("crypto: ccp - Ensure implicit SEV/SNP init and shutdown in ioctls") Reported-by: Sashiko Assisted-by: Gemini:gemini-3.1-pro-preview Link: https://sashiko.dev/#/patchset/20260324161301.1353976-1-tycho%40kernel.org CC: Signed-off-by: Tycho Andersen (AMD) Reviewed-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 9e983d0a74a6a2348e4ce61647ec8a4dfbe198ac Author: Tycho Andersen (AMD) Date: Mon May 4 10:51:44 2026 -0600 crypto: ccp - Do not initialize SNP for SEV ioctls commit fb1758e74b8061aacfbce7bbb7a7cc650537e167 upstream. Sashiko notes: > if SEV initialization fails and KVM is actively running normal VMs, could a > userspace process trigger this code path via /dev/sev ioctls (e.g., > SEV_PDH_GEN) and zero out MSR_VM_HSAVE_PA globally? Would the next VMRUN > execution for an active VM trigger a general protection fault and crash the > host? sev_move_to_init_state() is called for ioctls requiring only SEV firmware: SEV_PEK_GEN, SEV_PDH_GEN, SEV_PEK_CSR, SEV_PEK_CERT_IMPORT, and SEV_PDH_CERT_EXPORT. After the firmware command, it does SEV_SHUTDOWN on the SEV firmware. Since these commands do not require SNP to be initialized, skip it by calling __sev_platform_init_locked() which only initializes the SEV firmware. This way SNP is not Initialized at all, and HSAVE_PA is not cleared. The previous code saved any SEV initialization firmware error to init_args.error and then threw it away and hardcoded the return value of INVALID_PLATFORM_STATE regardless of the real firmware error. This patch changes it to surface the underlying error, which is hopefully both more useful and doesn't cause any problems. Note that it is still safe to call __sev_firmware_shutdown() directly: it calls __sev_snp_shutdown_locked(), which skips SNP shutdown if SNP was not initialized. Fixes: ceac7fb89e8d ("crypto: ccp - Ensure implicit SEV/SNP init and shutdown in ioctls") Reported-by: Sashiko Assisted-by: Gemini:gemini-3.1-pro-preview Link: https://sashiko.dev/#/patchset/20260324161301.1353976-1-tycho%40kernel.org CC: Signed-off-by: Tycho Andersen (AMD) Reviewed-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 53b8fb85f332b71f9946c1216620e57f1bfde72d Author: Eric Biggers Date: Thu May 21 21:25:25 2026 -0500 crypto: loongson - Select CRYPTO_RNG commit 4c600ab0d8cfc9d75b92f3426dbcb2ad85eac91d upstream. This driver registers a rng_alg, so it requires CRYPTO_RNG. Fixes: 766b2d724c8d ("crypto: loongson - add Loongson RNG driver support") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202605201622.qWOiiZTV-lkp@intel.com/ Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Reviewed-by: Huacai Chen Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit cc4e42b3ee9fc53ba1a63106c2db46f17ffedd00 Author: Wentao Liang Date: Thu Jun 4 10:27:06 2026 +0000 crypto: tegra - fix refcount leak in tegra_se_host1x_submit() commit 6ea0ce3a19f9c37a014099e2b0a46b27fa164564 upstream. The timeout error path in tegra_se_host1x_submit() returns without calling host1x_job_put(), while all other paths (success, submit error, pin error) properly release the job reference through the job_put label. Since host1x_job_alloc() initializes the reference count and host1x_job_put() is required to drop it, omitting it on timeout causes a permanent refcount leak. Fix this by redirecting the timeout return to the existing job_put label, ensuring the job reference and any associated syncpt references are consistently released. Cc: stable@vger.kernel.org Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Wentao Liang Reviewed-by: Akhil R Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit c4bd2f4c35b0e15b6040c2f7e7e7986780c066cf Author: Ruijie Li Date: Mon May 25 19:45:21 2026 +0800 crypto: pcrypt - restore callback for non-parallel fallback commit ed459fe319376e876de433d12b6c6772e612ca36 upstream. pcrypt installs pcrypt_aead_done() on the child AEAD request before trying to submit it through padata. If padata_do_parallel() returns -EBUSY, pcrypt falls back to calling the child AEAD directly. That fallback must not keep the padata completion callback. Otherwise an asynchronous completion runs pcrypt_aead_done() even though the request was never enrolled in padata. Restore the original request callback and callback data before calling the child AEAD directly. This keeps the fallback path aligned with a direct AEAD request while leaving the parallel path unchanged. Fixes: 662f2f13e66d ("crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Zhengchuan Liang Reported-by: Xin Liu Assisted-by: Codex:gpt-5.4 Signed-off-by: Ruijie Li Signed-off-by: Ren Wei Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit ee6a2a25665c6b599091acac22dc28e6c0006e12 Author: Eric Biggers Date: Sat May 30 13:26:23 2026 -0700 crypto: hisi-trng - Remove crypto_rng interface commit 216a7795ec210bdabd5dad42323eee70bbfc8d90 upstream. drivers/crypto/hisilicon/trng/trng.c exposes the same hardware through two completely separate interfaces, crypto_rng and hwrng. However, the implementation of this is buggy because it permits generation operations from these interfaces to run concurrently with each other, accessing the same registers. That is, hisi_trng_generate() synchronizes with itself but not with hisi_trng_read(). This results in potential repetition of output from the RNG, output of non-random values, etc. Fortunately, there's actually no point in hardware RNG drivers implementing the crypto_rng interface. It's not actually used by anything besides the "rng" algorithm type of AF_ALG, which in turn is not actually used in practice. Other crypto_rng hardware drivers are likewise being phased out, leaving just the hwrng support. Thus, remove it to simplify the code and avoid conflict (and confusion) with the hwrng interface which is the one that actually matters. Fixes: e4d9d10ef4be ("crypto: hisilicon/trng - add support for PRNG") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 774ddddf5eb26eeca177350413e3e2bc50930ee9 Author: Anastasia Tishchenko Date: Wed May 13 13:57:40 2026 +0300 crypto: ecc - Fix carry overflow in vli multiplication commit 27b536a2ec8e2f85a0380c2d13c9ecbc7aaab406 upstream. The carry flag calculation fails when r01.m_high is saturated (0xFFFFFFFFFFFFFFFF) and addition of lower bits overflows. The condition (r01.m_high < product.m_high) doesn't handle the case where r01.m_high == product.m_high and an additional carry exists from lower-bit overflow. When commit 3c4b23901a0c ("crypto: ecdh - Add ECDH software support") introduced crypto/ecc.c, it split the muladd() function in the micro-ecc library into separate mul_64_64() and add_128_128() helpers. It seems the check got lost in translation. Add proper handling for this boundary by accounting for the carry from the lower addition. Fixes: 3c4b23901a0c ("crypto: ecdh - Add ECDH software support") Signed-off-by: Anastasia Tishchenko Cc: stable@vger.kernel.org # v4.8+ Reviewed-by: Lukas Wunner Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit ac667f9f18c6b36e02eef59ea46d647729b0805f Author: Eric Biggers Date: Fri May 29 15:04:30 2026 -0700 crypto: crypto4xx - Remove insecure and unused rng_alg commit 7811ec9e973d2c9e465083699f0c8240b98cb8c4 upstream. Remove crypto4xx_rng, as it is insecure and unused: - It has only a 64-bit security strength, which is highly inadequate. This can be seen by the fact that crypto4xx_hw_init() seeds it with only 64 bits of entropy, and the fact that the original commit mentions that it implements ANSI X9.17 Annex C. Another issue was that this driver didn't implement the crypto_rng API correctly, as crypto4xx_prng_generate() didn't return 0 on success. - 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.) Fixes: d072bfa48853 ("crypto: crypto4xx - add prng crypto support") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Acked-by: Christian Lamparter Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 0016d3c21c6ab60a20be7f565cefb5999f3adeb6 Author: Xiaonan Zhao Date: Tue May 26 18:11:43 2026 +0800 crypto: chacha20poly1305 - validate poly1305 template argument commit 265b861bece38318b8e0fc8fac0643d4ef906d31 upstream. chachapoly_create() still accepts the compatibility poly1305 parameter in the template name, but it assumes the second template argument is always present and immediately passes it to strcmp(). When the argument is missing, crypto_attr_alg_name() returns an error pointer. Check for that before comparing the name so malformed template instantiations fail with an error instead of dereferencing the error pointer in strcmp(). This matches the surrounding Crypto API template pattern where crypto_attr_alg_name() results are validated before string-specific use. Fixes: a298765e28ad ("crypto: chacha20poly1305 - Use lib/crypto poly1305") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Zhengchuan Liang Reported-by: Xin Liu Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Signed-off-by: Xiaonan Zhao Signed-off-by: Ren Wei Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit d0b8cafd529b4ec759190c6081f7a76efb563a8f Author: Thorsten Blum Date: Mon Apr 27 18:39:39 2026 +0200 crypto: caam - use print_hex_dump_devel to guard key hex dumps again commit 8005dc808bcce7d6cc2ae015a3cde1683bee602d upstream. Use print_hex_dump_devel() for dumping sensitive key material in *_setkey() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled. Fixes: 8d818c105501 ("crypto: caam/qi2 - add DPAA2-CAAM driver") Fixes: 226853ac3ebe ("crypto: caam/qi2 - add skcipher algorithms") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 6f7b8e0321f3a8fbbd267d2ac15c671ab59e919e Author: Thorsten Blum Date: Mon Apr 27 18:39:37 2026 +0200 crypto: caam - use print_hex_dump_devel to guard key hex dumps commit 3f57657b6ea23f933371f2c2846322f441773cee upstream. Use print_hex_dump_devel() for dumping sensitive key material in *_setkey() and gen_split_key() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled. Fixes: 6e005503199b ("crypto: caam - print debug messages at debug level") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 7465ed1524ace60c4794effbc94fd06c2a6c9fac Author: Eric Biggers Date: Mon May 4 15:53:28 2026 -0700 crypto: af_alg - Remove zero-copy support from skcipher and aead commit ffdd2bc378953b525aca61902534e753f1f8e734 upstream. The zero-copy support is one of the riskiest aspects of AF_ALG. It allows userspace to request cryptographic operations directly on pagecache pages of files like the 'su' binary. It also allows userspace to concurrently modify the memory which is being operated on, a recipe for TOCTOU vulnerabilities. While zero-copy support is more valuable in other areas of the kernel like the frequently used networking and file I/O code, it has far less value in AF_ALG, which is a niche UAPI. AF_ALG primarily just exists for backwards compatibility with a small set of userspace programs such as 'iwd' that haven't yet been fixed to use userspace crypto code. Originally AF_ALG was intended to be used to access hardware crypto accelerators. However, it isn't an efficient interface for that anyway, and it turned out to be rarely used in this way in practice. Thus, the risks of the zero-copy support in AF_ALG vastly outweigh its benefits. Let's just remove it. This commit removes it from the "skcipher" and "aead" algorithm types. "hash" will be handled separately. This is a soft break, not a hard break. Even after this commit, it still works to use splice() or sendfile() to transfer data to an AF_ALG request socket from a pipe or any file, respectively. What changes is just that the kernel now makes an internal, stable copy of the data before doing the crypto operation. So performance is slightly reduced, but the UAPI isn't broken. And, very importantly, it's much safer. Tested with libkcapi/test.sh. All its test cases still pass. I also verified that this would have prevented the copy.fail exploit as well. I also used a custom test program to verify that sendfile() still works. Fixes: 8ff590903d5f ("crypto: algif_skcipher - User-space interface for skcipher operations") Fixes: 400c40cf78da ("crypto: algif - add AEAD support") Reported-by: Taeyang Lee <0wn@theori.io> Link: https://copy.fail/ Reported-by: Feng Ning Closes: https://lore.kernel.org/r/afYcc-tZFwvZZo76@ans-MacBook-Pro.local Reviewed-by: Demi Marie Obenour Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit b5699642640d6cff357638738c5293985cd5a53d Author: Bryam Vargas Date: Sun Jun 7 01:18:27 2026 +0000 isofs: bound Rock Ridge symlink components to the SL record commit 5fa1d6a5ec2356d2107dead614437c66fa7138b1 upstream. get_symlink_chunk() and the SL handling in parse_rock_ridge_inode_internal() walk the variable-length components of a Rock Ridge "SL" (symbolic link) record. Each component is a two-byte header (flags, len) followed by len bytes of text, so it occupies slp->len + 2 bytes. Both loops read slp->len and advance to the next component, and get_symlink_chunk() additionally does memcpy(rpnt, slp->text, slp->len), but neither checks that the component lies within the SL record before dereferencing it. A crafted SL record whose component declares a len that runs past the record (rr->len) therefore triggers an out-of-bounds read of up to 255 bytes. When the record sits at the tail of its backing buffer - for example a small kmalloc()ed continuation block reached through a CE record - the read crosses the allocation; get_symlink_chunk() then copies the out-of-bounds bytes into the symlink body returned to user space by readlink(), disclosing adjacent kernel memory. ISO 9660 images are routinely mounted from untrusted removable media - desktop environments auto-mount them (e.g. via udisks2) without CAP_SYS_ADMIN - so the record contents are attacker-controlled. Reject any component that does not fit in the remaining record bytes before using it. In get_symlink_chunk() return NULL, like the existing output-buffer (plimit) checks, so a malformed record makes readlink() fail with -EIO rather than silently returning a truncated target; in parse_rock_ridge_inode_internal() stop the inode-size walk. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Suggested-by: Michael Bommarito Signed-off-by: Bryam Vargas Link: https://patch.msgid.link/20260607011823.217748-1-hexlabsecurity@proton.me Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit ce93228e2193a17d2c58b656e439bb39fe5c3af8 Author: Bryam Vargas Date: Sun Jun 7 06:41:43 2026 +0000 partitions: aix: bound the pp_count scan to the ppe array commit 2dc0bfd2fe355fb930de63c2f2eb8ced8570c579 upstream. aix_partition() reads the physical volume descriptor into a fixed-size struct pvd and then scans its physical-partition-extent array: int numpps = be16_to_cpu(pvd->pp_count); ... for (i = 0; i < numpps; i += 1) { struct ppe *p = pvd->ppe + i; ... lp_ix = be16_to_cpu(p->lp_ix); pvd points at a single kmalloc()'d struct pvd whose ppe[] member holds a fixed ARRAY_SIZE(pvd->ppe) (1016) entries, but the loop runs up to the on-disk pp_count. pp_count is an unvalidated __be16 read straight from the descriptor, so a crafted AIX image with pp_count larger than 1016 drives the loop to read pvd->ppe[i] past the end of the allocation (up to 65535 entries, ~2 MB out of bounds). The partition scan runs without mounting anything, when a block device with a crafted AIX/IBM partition table appears (an attacker-supplied image attached with losetup -P, or a device auto-scanned by udev), via msdos_partition() -> aix_partition(). Clamp the scan to the number of entries the ppe[] array can hold. Fixes: 6ceea22bbbc8 ("partitions: add aix lvm partition support files") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Acked-by: Philippe De Muyter Link: https://patch.msgid.link/20260607064137.302574-1-hexlabsecurity@proton.me Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 7a64521802997257b144e6edfb4e278dbeb972dd Author: Qu Wenruo Date: Tue Jun 2 13:34:46 2026 +0930 btrfs: do not trim a device which is not writeable commit 1b1937eb08f51319bf71575484cde2b8c517aedc upstream. [BUG] There is a bug report that btrfs/242 can randomly fail with the following NULL pointer dereference: run fstests btrfs/242 at 2026-06-01 10:25:08 BTRFS: device fsid d4d7f234-487c-4787-88e4-47a8b68c9874 devid 1 transid 9 /dev/sdc (8:32) scanned by mount (122609) BTRFS info (device sdc): first mount of filesystem d4d7f234-487c-4787-88e4-47a8b68c9874 BTRFS info (device sdc): using crc32c checksum algorithm BTRFS warning (device sdc): devid 2 uuid fbe72d72-3272-482d-80fb-ab88ed398192 is missing BTRFS warning (device sdc): devid 2 uuid fbe72d72-3272-482d-80fb-ab88ed398192 is missing BTRFS info (device sdc): allowing degraded mounts BTRFS info (device sdc): turning on async discard BTRFS info (device sdc): enabling free space tree Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 user pgtable: 4k pages, 48-bit VAs, pgdp=000000013fd6b000 CPU: 4 UID: 0 PID: 122625 Comm: fstrim Not tainted 7.0.10-2-default #1 PREEMPT(full) openSUSE Tumbleweed e9a5f6b24978fba3bf015a992f865837fdfff3dd Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250812-19.fc42 08/12/2025 pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : btrfs_trim_fs+0x34c/0xa00 [btrfs] lr : btrfs_trim_fs+0x1f0/0xa00 [btrfs] Call trace: btrfs_trim_fs+0x34c/0xa00 [btrfs f02c1d570ceea621c69d302ba75dd61868083840] (P) btrfs_ioctl_fitrim+0xe8/0x178 [btrfs f02c1d570ceea621c69d302ba75dd61868083840] btrfs_ioctl+0xdd4/0x2bd8 [btrfs f02c1d570ceea621c69d302ba75dd61868083840] __arm64_sys_ioctl+0xac/0x108 invoke_syscall.constprop.0+0x5c/0xd0 el0_svc_common.constprop.0+0x40/0xf0 do_el0_svc+0x24/0x40 el0_svc+0x40/0x1d0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1b0/0x1b8 Code: 17ffff83 f94017e0 f9002be0 f9402ea0 (f9400c00) ---[ end trace 0000000000000000 ]--- Also the reporter is very kind to test the following ASSERT() added to btrfs_trim_free_extents_throttle(): ASSERT(device->bdev, "devid=%llu path=%s dev_state=0x%lx\n", device->devid, btrfs_dev_name(device), device->dev_state); And it shows the following output: assertion failed: device->bdev, in extent-tree.c:6630 (devid=2 path=/dev/sdd dev_state=0x82) Which means the device->bdev is NULL, and the dev_state is BTRFS_DEV_STATE_IN_FS_METADATA | BTRFS_DEV_STATE_ITEM_FOUND, without BTRFS_DEV_STATE_WRITEABLE flag set. [CAUSE] The pc points to the following call chain: btrfs_trim_fs() |- btrfs_trim_free_extents() |- btrfs_trim_free_extents_throttle() |- bdev_max_discard_sectors(device->bdev) So the NULL pointer dereference is caused by device->bdev being NULL. This looks impossible by a quick glance, as just before calling btrfs_trim_free_extents_throttle(), we have skipped any device that has BTRFS_DEV_STATE_MISSING flag set. However in this particular case, there is a window where the missing device is later re-scanned, causing btrfs to remove the BTRFS_DEV_STATE_MISSING flag: btrfs_control_ioctl() |- btrfs_scan_one_device() |- device_list_add() |- rcu_assign_pointer(device->name, name); | This updates the missing device's path to the new good path. | |- clear_bit(BTRFS_DEV_STATE_MISSING, &device->dev_state) This removes the BTRFS_DEV_STATE_MISSING flag. This allows the missing device to re-appear and clear the BTRFS_DEV_STATE_MISSING flag. However the device still does not have the BTRFS_DEV_STATE_WRITEABLE flag set, nor is its bdev pointer updated. The bdev pointer remains NULL, triggering the crash later. [FIX] This is a big de-synchronization between BTRFS_DEV_STATE_MISSING and device->bdev pointer, and shows a gap in btrfs's re-appearing-device handling. The proper handling of re-appearing device will need quite some extra work, which is out of the context of this small fix. Thankfully the regular bbio submission path has already handled it well by checking if the device->bdev is NULL before submitting. So here we just fix the crash by checking if the device is writeable and has a bdev pointer before calling bdev_max_discard_sectors(). Reported-by: Su Yue Link: https://lore.kernel.org/linux-btrfs/wlwir19t.fsf@damenly.org/ Fixes: 499f377f49f0 ("btrfs: iterate over unused chunk space in FITRIM") CC: stable@vger.kernel.org # 5.10+ Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 0912b98151eea6acfa2a0e11b5f772b198d29ab7 Author: Qu Wenruo Date: Mon Apr 20 18:32:49 2026 +0930 btrfs: check and set EXTENT_DELALLOC_NEW before clearing EXTENT_DELALLOC commit 95ee2231896d5f2a31760411429075a99d6045a7 upstream. [WARNING] When running test cases with injected errors or shutdown, e.g. generic/388 or generic/475, there is a chance that the following kernel warning is triggered: BTRFS info (device dm-2): first mount of filesystem d8a19a28-3232-4809-b0df-38df83e71bff BTRFS info (device dm-2): using crc32c checksum algorithm BTRFS info (device dm-2): checking UUID tree BTRFS info (device dm-2): turning on async discard BTRFS info (device dm-2): enabling free space tree BTRFS critical (device dm-2 state E): emergency shutdown ------------[ cut here ]------------ WARNING: extent_io.c:1742 at extent_writepage_io+0x437/0x520 [btrfs], CPU#2: kworker/u43:2/651591 CPU: 2 UID: 0 PID: 651591 Comm: kworker/u43:2 Tainted: G W OE 7.0.0-rc6-custom+ #365 PREEMPT(full) 5804053f02137e627472d94b5128cc9fcb110e88 RIP: 0010:extent_writepage_io+0x437/0x520 [btrfs] Call Trace: extent_write_cache_pages+0x2a5/0x820 [btrfs 70299925d0856939e93b17d480651713b3cbba58] btrfs_writepages+0x74/0x130 [btrfs 70299925d0856939e93b17d480651713b3cbba58] do_writepages+0xd0/0x160 __writeback_single_inode+0x42/0x340 writeback_sb_inodes+0x22d/0x580 wb_writeback+0xc6/0x360 wb_workfn+0xbd/0x470 process_one_work+0x198/0x3b0 worker_thread+0x1c8/0x330 kthread+0xee/0x120 ret_from_fork+0x2a6/0x330 ret_from_fork_asm+0x11/0x20 ---[ end trace 0000000000000000 ]--- BTRFS error (device dm-2 state E): root 5 ino 259 folio 1323008 is marked dirty without notifying the fs BTRFS error (device dm-2 state E): failed to submit blocks, root=5 inode=259 folio=1323008 submit_bitmap=0: -117 BTRFS info (device dm-2 state E): last unmount of filesystem d8a19a28-3232-4809-b0df-38df83e71bff [CAUSE] Inside btrfs we have the following pattern in several locations, for example inside btrfs_dirty_folio(): btrfs_clear_extent_bit(&inode->io_tree, start_pos, end_of_last_block, EXTENT_DELALLOC | EXTENT_DO_ACCOUNTING | EXTENT_DEFRAG, cached); ret = btrfs_set_extent_delalloc(inode, start_pos, end_of_last_block, extra_bits, cached); if (ret) return ret; However btrfs_set_extent_delalloc() can return IO errors other than -ENOMEM through the following callchain: btrfs_set_extent_delalloc() \- btrfs_find_new_delalloc_bytes() \- btrfs_get_extent() \- btrfs_lookup_file_extent() \- btrfs_search_slot() When such IO error happened, the previous btrfs_clear_extent_bit() has cleared the EXTENT_DELALLOC for the range, and we're expecting btrfs_set_extent_delalloc() to re-set EXTENT_DELALLOC. But since btrfs_set_extent_delalloc() failed before btrfs_set_extent_bit(), EXTENT_DELALLOC flag is no longer present. And if the folio range is dirty before entering btrfs_set_extent_delalloc(), we got a dirty folio but no EXTENT_DELALLOC flag now. Then we hit the folio writeback: extent_writepage() |- writepage_delalloc() | No ordered extent is created, as there is no EXTENT_DELALLOC set | for the folio range. | This also means the folio has no ordered flag set. | |- extent_writepage_io() \- if (unlikely(!folio_test_ordered(folio)) Now we hit the warning. [FIX] Introduce a new helper, btrfs_reset_extent_delalloc() to replace the currently open-coded btrfs_clear_extent_bit() + btrfs_set_extent_delalloc() combination. Instead of calling btrfs_clear_extent_bit() first, update EXTENT_DELALLOC_NEW first, as that part can fail due to metadata IO, meanwhile btrfs_clear_extent_bit() and btrfs_set_extent_bit() won't return any error but retry memory allocation until succeeded. This allows us to fail early without clearing EXTENT_DELALLOC bit, so even if that new btrfs_reset_extent_delalloc() failed before touching EXTENT_DELALLOC, the existing dirty range will still have their old EXTENT_DELALLOC flag present, thus avoid the warning. CC: stable@vger.kernel.org # 6.1+ Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 6d7649c1231dac14d906985d2936967e23041c26 Author: Tianchu Chen Date: Fri May 29 14:18:39 2026 +0000 nvmet-auth: validate reply message payload bounds against transfer length commit 3a413ece2504c70aa34a20be4dafec04e8c741f9 upstream. nvmet_auth_reply() accesses the variable-length rval[] array using attacker-controlled hl (hash length) and dhvlen (DH value length) fields without verifying they fit within the allocated buffer of tl bytes. A malicious NVMe-oF initiator can craft a DHCHAP_REPLY message with a small transfer length but large hl/dhvlen values, causing out-of-bounds heap reads when the target processes the DH public key (rval + 2*hl) or performs the host response memcmp. With DH authentication configured, the OOB pointer is passed directly to sg_init_one() and read by crypto_kpp_compute_shared_secret(), reaching up to 526 bytes past the buffer. This is exploitable pre-authentication. Add bounds validation ensuring sizeof(*data) + 2*hl + dhvlen <= tl before any access to the variable-length fields. Discovered by Atuin - Automated Vulnerability Discovery Engine. Fixes: db1312dd9548 ("nvmet: implement basic In-Band Authentication") Cc: stable@vger.kernel.org Reviewed-by: Hannes Reinecke Signed-off-by: Tianchu Chen Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 56c021a0869260d04c4b65d1471936aaf9177114 Author: Bryam Vargas Date: Wed May 27 15:00:00 2026 -0500 nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page commit 53cd102a7a56079b11b897835bd9b94c14e6322c upstream. nvmet_execute_disc_get_log_page() validates only the dword alignment of the host-supplied Log Page Offset (lpo). The 64-bit offset is then added to a small kzalloc'd buffer that holds the discovery log page and the result is passed straight to nvmet_copy_to_sgl(), which memcpy()s data_len bytes out to the host with no source-side bound check: u64 offset = nvmet_get_log_page_offset(req->cmd); /* 64-bit host */ size_t data_len = nvmet_get_log_page_len(req->cmd); /* 32-bit host */ ... if (offset & 0x3) { ... } /* only check */ ... alloc_len = sizeof(*hdr) + entry_size * discovery_log_entries(req); buffer = kzalloc(alloc_len, GFP_KERNEL); ... status = nvmet_copy_to_sgl(req, 0, buffer + offset, data_len); The Discovery controller is unauthenticated -- nvmet_host_allowed() returns true unconditionally for the discovery subsystem -- so the call is reachable pre-authentication by any TCP/RDMA/FC peer that can reach the nvmet target. With a discovery log page of ~1 KiB, an attacker requesting up to 4 KiB starting at offset == alloc_len reads the next slab page out and gets its content returned over the fabric (an empirical run on a default nvmet-tcp loopback target leaked 81 canonical kernel pointers in one Get Log Page response). Pointing the offset at unmapped kernel memory faults the in-kernel memcpy and crashes (or panics, on panic_on_oops=1) the target host instead. The attacker-controlled source-side offset pattern "nvmet_copy_to_sgl(req, 0, buffer + ATTACKER_OFFSET, ...)" is unique to nvmet_execute_disc_get_log_page in the entire nvmet codebase: every other Get Log Page handler in admin-cmd.c either ignores lpo (and silently starts every response at offset 0) or tracks a local destination offset with a fixed source pointer. Validate the host-supplied offset against the log page size, cap the copy length to what is actually available, and zero-fill any remainder of the host transfer buffer. The zero-fill matches the existing short-response pattern in nvmet_execute_get_log_changed_ns() (admin-cmd.c) and prevents leaking transport SGL contents when the host asks for more bytes than the log page contains. Fixes: a07b4970f464 ("nvmet: add a generic NVMe target") Cc: stable@vger.kernel.org Reviewed-by: Chaitanya Kulkarni Reviewed-by: Christoph Hellwig Signed-off-by: Bryam Vargas Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 7a69463e9ad23650b07b9d166f0ddfafbfb8c530 Author: Achkinazi, Igor Date: Thu May 28 15:24:27 2026 +0000 nvme-multipath: set BIO_REMAPPED on bios remapped to per-path namespace disks commit 88bac2c1a72b8f4f71e9845699aa872df04e5850 upstream. When nvme_ns_head_submit_bio() remaps a bio from the multipath head to a per-path namespace, bio_set_dev() clears BIO_REMAPPED. The remapped bio is then resubmitted through submit_bio_noacct() which calls bio_check_eod() because BIO_REMAPPED is not set. This races with nvme_ns_remove() which zeroes the per-path capacity before synchronize_srcu(): CPU 0 (IO submission) --------------------- srcu_read_lock() nvme_find_path() -> ns [NVME_NS_READY is set] CPU 1 (namespace removal) ------------------------- clear_bit(NVME_NS_READY) set_capacity(ns->disk, 0) synchronize_srcu() <- blocks CPU 0 (IO submission) --------------------- bio_set_dev(bio, ns->disk->part0) [clears BIO_REMAPPED] submit_bio_noacct(bio) -> bio_check_eod() sees capacity=0 -> bio fails with IO error The SRCU read lock prevents synchronize_srcu() from completing, but does not prevent set_capacity(0) from executing. The bio fails the EOD check before it reaches the NVMe driver, so nvme_failover_req() never gets a chance to redirect it to another path of multipath. IO errors are reported to the application despite another path being available. On older kernels (before commit 0b64682e78f7 "block: skip unnecessary checks for split bio"), the same race was also reachable through split remainders resubmitted via submit_bio_noacct(). Fix this by setting BIO_REMAPPED after bio_set_dev() in nvme_ns_head_submit_bio(). This skips bio_check_eod() on the per-path device; the EOD check already passed on the multipath head. NVMe per-path namespace devices are always whole disks (bd_partno=0), so the blk_partition_remap() skip also gated by BIO_REMAPPED is a no-op. The flag does not persist across failover and cannot go stale if the namespace geometry changes between attempts: nvme_failover_req() calls bio_set_dev() to redirect the bio back to the multipath head, which clears BIO_REMAPPED. When nvme_requeue_work() resubmits through submit_bio_noacct(), bio_check_eod() runs normally against the current capacity. Same approach as commit 3a905c37c351 ("block: skip bio_check_eod for partition-remapped bios"). Fixes: a7c7f7b2b641 ("nvme: use bio_set_dev to assign ->bi_bdev") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Igor Achkinazi Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 13f2f5defb4d7f8fe9510e4ec1a42f9a862bc441 Author: Mikulas Patocka Date: Mon May 11 13:04:16 2026 +0200 dm-ioctl: report an error if a device has no table commit 457e32348d606a77f9b20e25e989734189834c07 upstream. When we send a message to a device that has no table, the return code was not set. The code would return "2", which is not considered a valid return value. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Reviewed-by: Benjamin Marzinski Signed-off-by: Greg Kroah-Hartman commit 427c82497e269579c95ce9142f07e88aa58f2b45 Author: Wentao Liang Date: Tue May 26 10:21:24 2026 +0000 block: partitions: fix of_node refcount leak in of_partition() commit 148cd4873115feb266c002d4d4618ea7f14342d9 upstream. of_partition() calls of_node_get() on the parent device node at the beginning of the function, storing the reference in 'partitions_np'. This reference is leaked in two paths: 1. The compatibility check at the top of the function returns 0 without releasing partitions_np when the node exists but is not "fixed-partitions" compatible. 2. The function returns 1 at the end after successfully processing all partitions without releasing partitions_np. Fix both leaks by adding of_node_put(partitions_np) on each path. Fixes: 2e3a191e89f9 ("block: add support for partition table defined in OF") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Md Haris Iqbal Link: https://patch.msgid.link/20260526102124.2283846-1-vulab@iscas.ac.cn Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit a8803c4f0ac3fa7df5551bbb5a8800c434a94357 Author: Wentao Liang Date: Wed May 27 08:45:44 2026 +0000 nvme: target: rdma: fix ndev refcount leak on queue connect commit badc53620fe813b3a9f727ef9526f98567c2c898 upstream. nvmet_rdma_queue_connect() calls nvmet_rdma_find_get_device() which acquires a reference on the returned ndev via kref_get(). On the path where the host queue backlog is exceeded and the function returns NVME_SC_CONNECT_CTRL_BUSY, reference of ndev is not released, leaking the kref. Fix this by adding a goto to the existing put_device label before the early return. Fixes: 31deaeb11ba7 ("nvmet-rdma: avoid circular locking dependency on install_queue()") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Wentao Liang Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit d161d47aba31dc99bbf6d1788c316a1b06ae89b0 Author: Thorsten Blum Date: Tue Apr 28 12:14:32 2026 +0200 crypto: atmel-sha204a - drop hwrng quality reduction for ATSHA204A commit ea5e57cc97185329dcc5ebdcaae7e1500bf0ad0b upstream. Commit 8006aff15516 ("crypto: atmel-sha204a - Set hwrng quality to lowest possible") reduced the hwrng quality to 1 based on a review by Bill Cox [1]. However, despite its title, the review only tested the ATSHA204, not the ATSHA204A. In the same thread, Atmel engineer Landon Cox wrote "this behavior has been eliminated entirely"[2] in the ATSHA204A and "this problem does not affect the ATECC108 or the ATECC108A (or the ATSHA204A)"[3]. According to the official ATSHA204A datasheet [4], the device contains a high-quality hardware RNG that combines its output with an internal seed value stored in EEPROM or SRAM to generate random numbers. The device also implements all security functions using SHA-256, and the driver uses the chip's Random command in seed-update mode. Keep 'quality = 1' for ATSHA204, but drop the explicit hwrng quality reduction for ATSHA204A and fall back to the hwrng core default. [1] https://www.metzdowd.com/pipermail/cryptography/2014-December/023858.html [2] https://www.metzdowd.com/pipermail/cryptography/2014-December/023852.html [3] https://www.metzdowd.com/pipermail/cryptography/2014-December/023886.html [4] https://ww1.microchip.com/downloads/en/DeviceDoc/ATSHA204A-Data-Sheet-40002025A.pdf Fixes: 8006aff15516 ("crypto: atmel-sha204a - Set hwrng quality to lowest possible") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Reviewed-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit c60932d6f8373268d0393053c45c522263feeed8 Author: Wentao Liang Date: Wed Jun 3 11:03:27 2026 +0000 hwrng: jh7110 - fix refcount leak in starfive_trng_read() commit 8d13f7a8450206e3f820cdb26e33e91d181071b4 upstream. The starfive_trng_read() function acquires a runtime PM reference via pm_runtime_get_sync() but fails to release it on two error paths. If starfive_trng_wait_idle() or starfive_trng_cmd() returns an error, the function exits without calling pm_runtime_put_sync_autosuspend(), leaving the runtime PM usage counter permanently elevated and preventing the device from entering runtime suspend. Refactor the function to use a unified error path that calls pm_runtime_put_sync_autosuspend() before returning. Cc: stable@vger.kernel.org Fixes: c388f458bc34 ("hwrng: starfive - Add TRNG driver for StarFive SoC") Signed-off-by: Wentao Liang Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 04f4599a9efb90992d072a814960edf0cd62805d Author: Bryam Vargas Date: Fri Jun 12 01:40:01 2026 -0500 udf: validate sparing table length as an entry count, not a byte count commit 3ec997bd5508e9b25210b5bbec89031629cdb093 upstream. udf_load_sparable_map() accepts a sparing table when sizeof(*st) + le16_to_cpu(st->reallocationTableLen) > sb->s_blocksize is false, i.e. it treats reallocationTableLen as a number of BYTES that must fit in the block. But the table is walked as an array of 8-byte sparingEntry elements: for (i = 0; i < le16_to_cpu(st->reallocationTableLen); i++) { struct sparingEntry *entry = &st->mapEntry[i]; ... entry->origLocation ... } in udf_get_pblock_spar15() and udf_relocate_blocks(). A reallocationTableLen of N therefore passes the check whenever sizeof(*st) + N <= blocksize, yet the consumers index sizeof(*st) + N * sizeof(struct sparingEntry) bytes -- up to ~8x the block. On a crafted UDF image this is an out-of-bounds read in udf_get_pblock_spar15(); udf_relocate_blocks() additionally feeds the same length to udf_update_tag(), whose crc_itu_t() reads far past the block, and its memmove() through st->mapEntry[] is an out-of-bounds write. Validate reallocationTableLen as the entry count it is, with struct_size(). Fixes: 1df2ae31c724 ("udf: Fortify loading of sparing table") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Link: https://patch.msgid.link/20260612-b4-disp-91780c4e-v1-1-f15112ff6882@proton.me Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit e610fb113cdfa8bf4247c9bf4f2337b81ad4ddad Author: Bryam Vargas Date: Fri Jun 12 02:53:31 2026 -0500 udf: validate VAT header length against the VAT inode size commit d8202786b3d75125c84ebc4de6d946f92fde0ee8 upstream. udf_load_vat() takes the virtual partition's start offset straight from the on-disk VAT 2.0 header without checking it against the VAT inode size: map->s_type_specific.s_virtual.s_start_offset = le16_to_cpu(vat20->lengthHeader); map->s_type_specific.s_virtual.s_num_entries = (sbi->s_vat_inode->i_size - map->s_type_specific.s_virtual.s_start_offset) >> 2; lengthHeader is a fully attacker-controlled 16-bit value. If it exceeds the VAT inode size, the s_num_entries subtraction underflows to a huge count, which defeats the "block > s_num_entries" bound in udf_get_pblock_virt15(); and on the ICB-inline path that function reads ((__le32 *)(iinfo->i_data + s_start_offset))[block] so a large s_start_offset indexes past the inode's in-ICB data. Mounting a crafted UDF image with a virtual (VAT) partition then triggers an out-of-bounds read. Reject a VAT whose header length does not leave room for at least one entry within the VAT inode. Fixes: fa5e08156335 ("udf: Handle VAT packed inside inode properly") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Link: https://patch.msgid.link/20260612-b4-disp-9a2317ee-v1-1-fefef5736154@proton.me Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 335202ab25b01fdd45889ff25eab70864686dea3 Author: Michael Bommarito Date: Fri May 15 10:23:27 2026 -0400 udf: validate free block extents against the partition length commit 5f0419457f89dce1a3f1c8e62a3adf2f39ab8168 upstream. udf_free_blocks() checks the logical block number and count against the partition length, but drops the extent offset from that final bound. A crafted extent can pass the guard while logicalBlockNum + offset + count points past the partition, which later indexes past the space bitmap array. A single ftruncate(2) on a file backed by such an extent reliably panics the kernel. This is a local availability issue. On desktop systems where UDisks/polkit allows the active user to mount removable UDF media without CAP_SYS_ADMIN, an unprivileged local user can supply the crafted filesystem and trigger the panic by truncating a writable file on it. Systems that require root or CAP_SYS_ADMIN to mount the image have a higher prerequisite. No confidentiality or integrity impact is claimed: the reproduced primitive is an out-of-bounds read of a bitmap pointer slot followed by a kernel panic. Use the already computed logicalBlockNum + offset + count value for the partition length check. Also make load_block_bitmap() reject an out-of-range block group before indexing s_block_bitmap[], so corrupted callers cannot walk past the flexible array. Fixes: 56e69e59751d ("udf: prevent integer overflow in udf_bitmap_free_blocks()") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260515142327.1120767-1-michael.bommarito@gmail.com Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit d944b8add331883d8e026e152356e7d9349a3bcf Author: Pawan Gupta Date: Mon Jul 13 18:12:53 2026 -0700 bpf: Prefer dirty packs for eBPF allocations commit b72e29e0f7ee329d89f86db8700c8ea99b4a370a upstream. The pack allocator only flushes predictors when reusing a dirty pack for cBPF, eBPF allocations never trigger a flush. Currently, eBPF picks the first free pack, which could be a clean pack. As an optimization, leaving a clean pack for cBPF can avoid flushes. Prefer dirty packs for eBPF and keep clean packs free for cBPF. This mirrors the existing cBPF preference for clean packs: each program kind prefers the pack that avoids an extra flush, and falls back to the other kind only when no preferred pack has room. eBPF reuse of a dirty pack is harmless since eBPF being privileged does not flush. Signed-off-by: Pawan Gupta Acked-by: Daniel Borkmann Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit 0229944ba7923a73f54e94e42139518bfff9124c Author: Pawan Gupta Date: Mon Jul 13 18:12:38 2026 -0700 bpf: Prefer packs that won't trigger an IBPB flush on allocation commit a9b1f19a6a673ba06820898d0f1ad02883ea1639 upstream. Currently BPF pack allocator picks the chunks from the first available pack. While this is okay, it naturally leads to more frequent flushes when there are multiple packs in the system that weren't used since the last flush. As an optimization prefer allocating the new programs from packs that are unused since last flush. When all packs are dirty, allocation forces a flush and marks all packs clean. Below are some future optimizations ideas: 1. Currently, the "dirty" tracking is only done at the pack-level. Flush frequency can further be reduced with chunk-level tracking. This requires a new bitmap per-pack to track the dirty state. 2. IBPB flush is done on all CPUs, even if only a single CPU ran the BPF program. On a system with hundreds of CPUs this could be a major bottleneck forcing hundreds of IPIs to deliver the flush. The solution is to track the CPUs where a BPF program ran, and issue IBPB only on those CPUs. 3. Avoid IBPB when flush is already done at other sources (e.g. context switch). Signed-off-by: Pawan Gupta Acked-by: Daniel Borkmann Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit f1f36bf9bb1173ef4ddb7fb917bbda75fb1db690 Author: Pawan Gupta Date: Mon Jul 13 18:12:23 2026 -0700 bpf: Skip redundant IBPB in pack allocator commit a23c1c5396a91680703360d1ee28a44657c503c4 upstream. bpf_prog_pack_alloc() issues IBPB on all CPUs on every cBPF allocation, even when reusing chunks from an existing pack where no new memory was touched since the last IBPB. Since IBPB on all CPUs is heavy, Dave Hansen suggested to track allocation since last IBPB, and only issue IBPB at reuse for the chunks that have not seen an IBPB since they were last freed. Track per-pack whether an IBPB is needed via arch_flush_needed. Set it when allocating a chunk, reset on IBPB flush. On reuse, conditionally issue the flush. Since IBPB invalidates all BTB entries, clear the flag on all packs after flushing. Signed-off-by: Pawan Gupta Acked-by: Daniel Borkmann Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit 666fc2e6e4d0a37592e5a3029deddc272e10df1e Author: Pawan Gupta Date: Mon Jul 13 18:12:07 2026 -0700 bpf: Restrict JIT predictor flush to cBPF commit 0bb99f2cfaae6822d734d69722de30af823efdf3 upstream. Currently predictor flush on memory reuse is done for all BPF JIT allocations, but only cBPF programs can be loaded by an unprivileged user. eBPF is privileged by default, and flushing predictors for all CPUs on every eBPF reuse penalizes the common case for no security benefit. eBPF allocations can be frequent on busy systems, only flush predictors for cBPF programs. Trampoline and dispatcher allocations also skip the flush as they are eBPF-only. [pawan: backport had various conflicts in arches bpf_int_jit_compile(). loongarch bpf_int_jit_compile() doesn't use pack allocator, dropped was_classic hunk. ] Signed-off-by: Pawan Gupta Acked-by: Daniel Borkmann Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit 8a4c8af9ae67eb072d90d1b339f14d27a82bd2a1 Author: Pawan Gupta Date: Mon Jul 13 18:11:52 2026 -0700 x86/bugs: Enable IBPB flush on BPF JIT allocation commit a3af84b0fa00ead01fcd0e28b5d773ff25990a0d upstream. Enable hardening against JIT spraying when Spectre-v2 mitigations are in use. Specifically, issue an IBPB flush on BPF JIT memory reuse. Skip enabling the IBPB flush if the BPF dispatcher is already using a retpoline sequence. This hardening applies only when BPF-JIT is in use. Guard the enabling under CONFIG_BPF_JIT so that bugs.c still builds with CONFIG_BPF_JIT=n. Signed-off-by: Pawan Gupta Acked-by: Daniel Borkmann Acked-by: Dave Hansen Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit 8ff183ee4d8c452960df58175a094828c0513b2e Author: Pawan Gupta Date: Mon Jul 13 18:11:37 2026 -0700 bpf: Support for hardening against JIT spraying commit 96cce16e26dd02a8678f1e87f88a4b5cdb63b995 upstream. The BPF JIT allocator packs many small programs into larger executable allocations and reuses space within those allocations as programs are loaded and freed. When fresh code is written into space that a previous program occupied, an indirect jump into the new program can reuse a branch prediction left behind by the old one. Flush the indirect branch predictors before reusing JIT memory so that indirect jumps into a newly written program don't reuse predictions from an old program that occupied the same space. Introduce bpf_arch_pred_flush_enabled static key and bpf_arch_pred_flush static call for flushing the branch predictors on JIT memory reuse. Architectures that need a flush, can update it to a predictor flush function. By default, its a NOP and does not emit any CALL. Allocations larger than a pack are not covered by this flush. That is safe because cBPF programs (the unprivileged attack surface) are bounded well below a pack size. Issue a warning if this assumption is ever violated while the flush is active. Signed-off-by: Pawan Gupta Acked-by: Daniel Borkmann Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit bd818dcf4783ef5b924732f0ec52d931b94459bf Author: Alice Ryhl Date: Tue Jul 14 06:45:54 2026 +0000 rust_binder: fix BINDER_GET_EXTENDED_ERROR [ Upstream commit 77bfebf110773f5a0d6b5ff8110896adb2c9c335 ] This code currently copies the ExtendedError struct to the stack, modifies the copy, and then doesn't modify the original. Thus, fix it. Furthermore, errors when replying must be delivered directly to the remote thread, so update deliver_reply() to take an extended error argument. Cc: stable Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver") Signed-off-by: Alice Ryhl Acked-by: Carlos Llamas Link: https://patch.msgid.link/20260605-set-extended-error-v3-1-d60b69a75f97@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Alice Ryhl Signed-off-by: Sasha Levin commit e5049526a7aacdb53aaaee2e21b0fd8c865f02b4 Author: Alice Ryhl Date: Tue Jul 14 06:45:53 2026 +0000 rust_binder: introduce TransactionInfo [ Upstream commit 5326a18e3e640061ca4b65c1b732feaeace61c39 ] Rust Binder exposes information about transactions that are sent in various ways: printing to the kernel log, tracepoints, files in binderfs, and the upcoming netlink support. Currently all these mechanisms use disparate ways of obtaining the same information, so let's introduce a single Info struct that collects all the required information in a single place, so that all of these different mechanisms can operate in a more uniform way. For now, the new info struct is only used to replace a few things: * The BinderTransactionDataSg struct that is passed as an argument to several methods is removed as the information is moved into the new info struct and passed down that way. * The oneway spam detection fields on Transaction and Allocation can be removed, as the information can be returned to the caller via the mutable info struct instead. But several other uses of the info struct are planned in follow-up patches. Signed-off-by: Alice Ryhl Link: https://patch.msgid.link/20260306-transaction-info-v1-1-fda58fca558b@google.com Signed-off-by: Greg Kroah-Hartman [aliceryhl: explicitly impl Zeroable for UserPtr instead of using derive] Signed-off-by: Alice Ryhl Signed-off-by: Sasha Levin commit be1567992417dc92133e74126de7a6066c825ac9 Author: Reinette Chatre Date: Mon Jul 13 15:17:37 2026 -0700 x86,fs/resctrl: Prevent out-of-bounds access while offlining CPU when SNC enabled commit fc16126cc11d9f507130bf84ab137ee0938c900e upstream. The architecture updates the cpu_mask in a domain's header to track which online CPUs are associated with the domain. When this mask becomes empty the architecture initiates offline of the domain that includes calling on resctrl fs to offline the domain. If it is a monitoring domain in which LLC occupancy is tracked resctrl fs forces the limbo handler to clear all busy RMID state associated with the domain. The limbo handler always reads the current event value associated with a busy RMID irrespective of it being checked as part of regular "is it still busy" check or whether it will be forced released anyway. When reading an RMID on a system with SNC enabled the "logical RMID" is converted to the "physical RMID" and this conversion requires the NUMA node ID of the resctrl monitoring domain that is in turn determined by querying the NUMA node ID of any CPU belonging to the monitoring domain. When the monitoring domain is going offline its cpu_mask is empty causing the NUMA node ID query via cpu_to_node() to be done with "nr_cpu_ids" as argument resulting in an out-of-bounds access. Refactor the limbo handler to skip reading the RMID when the RMID will just be forced to no longer be dirty in the domain anyway. Add a safety check to the architecture's RMID reader to protect against this scenario. Fixes: e13db55b5a0d ("x86/resctrl: Introduce snc_nodes_per_l3_cache") Closes: https://sashiko.dev/#/patchset/cover.1780456704.git.reinette.chatre%40intel.com?part=9 Reported-by: Sashiko Signed-off-by: Reinette Chatre Signed-off-by: Borislav Petkov (AMD) Cc: Link: https://patch.msgid.link/16137433df42f85013b2f7a53626795cbd6637b9.1781029125.git.reinette.chatre@intel.com Signed-off-by: Sasha Levin commit b7b2d2ccdbc4dce33a882d9c00484a3a2dc10866 Author: Baolin Wang Date: Fri Jul 10 10:09:22 2026 +0800 mm: shmem: fix potential livelock issue for shmem direct swapin When skipping swapcache for synchronous IO swap devices, swapcache_prepare() is used to prevent parallel swapin from proceeding with the swap cache flag. However, on PREEMPT kernels this can lead to a livelock, as reported by Chao[1]: Thread A starts direct swapin of a shmem folio and calls swapcache_prepare() to set SWAP_HAS_CACHE. It may then be preempted inside workingset_refault(). Meanwhile, a higher priority thread B also attempts direct swapin of the same shmem swap entry. Since swapcache_prepare() already marks the entry, thread B repeatedly gets -EEXIST and busy-loops waiting for thread A to finish. But as thread B runs at higher priority, thread A cannot preempt it, resulting in starvation and a livelock. Fix it by yielding the CPU with schedule_timeout_uninterruptible(1) when swapcache_prepare() fails, following the same approach used in commit 029c4628b2eb ("mm: swap: get rid of livelock in swapin readahead") and commit 13ddaf26be32 ("mm/swap: fix race when skipping swapcache"). However, commit 01626a1823 ("mm: avoid unconditional one-tick sleep when swapcache_prepare fails") found that the unconditional one-tick sleep can cause UI stuttering on latency-sensitive Android devices. So we can follow the same approach by adding a waitqueue to wake up tasks when needed, instead of always sleeping for a full tick. Note that mainline does not have this potential issue, which has already been resolved by Kairui's swap refactoring work[2]. [1] https://lore.kernel.org/all/700a2cbf90a2484f979aac858f08f5d4@xiaomi.com/ [2] https://lore.kernel.org/all/20260517-swap-table-p4-v5-0-88ae43e064c7@tencent.com/ Fixes: 1dd44c0af4fa ("mm: shmem: skip swapcache for swapin of synchronous swap device") Reported-by: Ma Chao Closes: https://lore.kernel.org/all/700a2cbf90a2484f979aac858f08f5d4@xiaomi.com/ Signed-off-by: Baolin Wang Signed-off-by: Sasha Levin commit 9818bcae3c0ca1dde4b9a334125c46676e0a9b29 Author: Chao Shi Date: Fri May 22 18:00:25 2026 -0400 block: skip sync_blockdev() on surprise removal in bdev_mark_dead() commit 49f06cff50a4ccf3b7a1a662ceb892b3b21a527a upstream. bdev_mark_dead()'s @surprise == true means the device is already gone. The filesystem callback fs_bdev_mark_dead() honours this and skips sync_filesystem(), but the bare block device path (no ->mark_dead op) lost its !surprise guard when the holder ->mark_dead callback was wired up (see Fixes), and now calls sync_blockdev() unconditionally, which can hang forever waiting on writeback that can no longer complete. syzkaller hit this via nvme_reset_work()'s "I/O queues lost" path: nvme_mark_namespaces_dead() -> blk_mark_disk_dead() -> bdev_mark_dead(bdev, true) -> sync_blockdev() blocks in folio_wait_writeback(), wedging the reset worker and every task waiting on it. Skip the sync on surprise removal, matching fs_bdev_mark_dead(); invalidate_bdev() still runs. Orderly removal (surprise == false) is unchanged. Found by FuzzNvme(Syzkaller with FEMU fuzzing framework). Fixes: d8530de5a6e8 ("block: call into the file system for bdev_mark_dead") Acked-by: Sungwoo Kim Acked-by: Dave Tian Acked-by: Weidong Zhu Signed-off-by: Chao Shi Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260522220025.1770388-1-coshi036@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit e086c16962a1b0142e2675610e9c06fcfcd4c3a8 Author: Paul Cercueil Date: Tue Jun 9 17:29:05 2026 +0200 usb: gadget: f_fs: Fix DMA fence leak commit baa6b6068a3f2bf2ed525a1cb37975905dadc658 upstream. In ffs_dmabuf_transfer(), a ffs_dma_fence object is kmalloc'd, with the underlying dma_fence later initialized by dma_fence_init(), which sets its kref counter to 1. Then, dma_resv_add_fence() gets a second reference, and a pointer to the ffs_dma_fence is passed as the usb_request's "context" field. The dma-resv mechanism will manage the second reference, but the first reference is never properly released; the ffs_dmabuf_cleanup() function decreases the reference count, but only to balance with the reference grab in ffs_dmabuf_signal_done(). The code will then slowly leak memory as more ffs_dma_fence objects are created without being ever freed. Address this issue by transferring ownership of the fence to the DMA reservation object, by calling dma_fence_put() right after dma_resv_add_fence(). The ffs_dma_fence then gets properly discarded after being signalled. Fixes: 7b07a2a7ca02 ("usb: gadget: functionfs: Add DMABUF import interface") Cc: stable Signed-off-by: Paul Cercueil Tested-by: Nuno Sá Reviewed-by: Nuno Sá Link: https://patch.msgid.link/20260609152905.729328-1-paul@crapouillou.net Signed-off-by: Greg Kroah-Hartman commit b45be66ed47d45d7d4af5c9c5bc8aebaada4e8aa Author: Paul Menzel Date: Fri Jul 3 13:07:37 2026 +0200 usb: typec: ucsi: cancel pending work on system suspend commit 7c4a234bd31a64a8dbd0140dc812da592c5e0787 upstream. On a Dell XPS 13 9360 (BIOS 2.21.0), entering system suspend (deep/S3) races a pending UCSI connector-change worker against the ACPI EC teardown. The worker evaluates the UCSI _DSM (GET_CONNECTOR_STATUS), whose AML accesses the Embedded Controller. By that point the ACPI EC has already been stopped for suspend, so the EC address space handler rejects the access with AE_BAD_PARAMETER, aborting the AML and failing the connector query: [22314.689495] ACPI: EC: interrupt blocked [22314.711981] ACPI: PM: Preparing to enter system sleep state S3 [22314.743260] ACPI: EC: event blocked [22314.743265] ACPI: EC: EC stopped [22314.743267] ACPI: PM: Saving platform NVS memory [22314.744241] ACPI Error: AE_BAD_PARAMETER, Returned by Handler for [EmbeddedControl] (20260408/evregion-303) [22314.744432] ACPI Error: Aborting method \_SB.PCI0.LPCB.ECDV.ECW1 due to previous error (AE_BAD_PARAMETER) (20260408/psparse-543) [22314.744673] ACPI Error: Aborting method \ECWB due to previous error (AE_BAD_PARAMETER) (20260408/psparse-543) [22314.745201] ACPI Error: Aborting method \_SB.UBTC._DSM due to previous error (AE_BAD_PARAMETER) (20260408/psparse-543) [22314.745394] ACPI: \_SB_.UBTC: failed to evaluate _DSM c298836f-a47c-e411-ad36-631042b5008f rev:1 func:1 (0x1001) [22314.745414] ucsi_acpi USBC000:00: ucsi_acpi_dsm: failed to evaluate _DSM 1 [22314.745424] ucsi_acpi USBC000:00: ucsi_handle_connector_change: GET_CONNECTOR_STATUS failed (-5) ucsi_acpi implements a resume callback but no suspend callback, so nothing cancels the connector-change work before the firmware/EC is torn down. Add a `ucsi_suspend()` core helper that cancels the pending init and connector-change work, and wire it into ucsi_acpi's PM ops. The connector state is re-read on resume by `ucsi_resume()`, so cancelling the work loses nothing. Fixes: 4e3a50293c2b ("usb: typec: ucsi: acpi: Implement resume callback") Cc: stable Signed-off-by: Paul Menzel Assisted-by: Claude Opus 4.8 Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260703110738.8457-2-pmenzel@molgen.mpg.de Signed-off-by: Greg Kroah-Hartman commit f5c772b76bbd95de8be51cf849c6098f6af6fcf9 Author: Fan Wu Date: Tue Jun 16 13:20:11 2026 +0000 usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove commit 1f0bdc2884b67de337215079bba166df0cdf4ac5 upstream. The threaded IRQ handler ccg_irq_handler() calls ucsi_notify_common(), which on a connector-change event calls ucsi_connector_change() and schedules connector work. In ucsi_ccg_remove(), ucsi_destroy() frees uc->ucsi (kfree) before free_irq() is called, so a handler invocation already in flight may access the freed object after ucsi_destroy(). CPU 0 (remove) | CPU 1 (threaded IRQ) ucsi_destroy(uc->ucsi) | ccg_irq_handler() kfree(ucsi) // FREE | ucsi_notify_common(uc->ucsi) // USE Move free_irq() before ucsi_destroy() in the remove path. It is kept after ucsi_unregister(): ucsi_unregister() cancels connector work whose handler issues GET_CONNECTOR_STATUS through ucsi_send_command_common(), which waits for a completion that is signalled from the IRQ handler, so the IRQ must stay active until that work has been cancelled. The probe error path already orders free_irq() before ucsi_destroy(). This bug was found by static analysis. Fixes: e32fd989ac1c ("usb: typec: ucsi: ccg: Move to the new API") Cc: stable Signed-off-by: Fan Wu Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260616132011.103279-1-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit b1dfdff51a865674cc43ce84256d2c85843e8c7e Author: Madhu M Date: Fri Jun 19 21:03:11 2026 +0530 usb: typec: ucsi: Pass full DP config payload in SET_NEW_CAM for DP alt mode commit 735a461d060d4eeb2f9732aba1295bc32a3982e2 upstream. In the UCSI Specification Revision 3.1 RC1, bits 32-63 of the SET_NEW_CAM command hold the 32-bit Alternate Mode Specific (AMSpecific) field. For DisplayPort Alternate Mode, this field must contain the full 32-bit DisplayPort configuration VDO payload that the OPM wants the connector to operate in, rather than just the pin assignment value. This AMSpecific value follows the DisplayPort Configurations defined in the DisplayPort Alt Mode on USB Type-C Specification v2.1a, Table 5-13: SOP DisplayPort Configurations. Fixes: af8622f6a585 ("usb: typec: ucsi: Support for DisplayPort alt mode") Cc: stable Signed-off-by: Madhu M Reviewed-by: Jameson Thies Reviewed-by: Andrei Kuchynski Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260619153311.3526083-1-madhu.m@intel.com Signed-off-by: Greg Kroah-Hartman commit 8c00aec752ce1d8b07bbf5db2193e8192cbd1a53 Author: Andrei Kuchynski Date: Mon Jun 1 14:28:37 2026 +0000 usb: typec: ucsi: Invert DisplayPort role assignment commit d092d7edf8faefa3e27b9fc7f0e7904b06c833a2 upstream. The existing implementation assigned these flags backwards, configuring the partner's DisplayPort role to match the port's role instead of complementing it. This prevents proper configuration during DP altmode activation, often causing `pin_assignment` to remain 0 in `dp_altmode_configure()` and resulting in VDM negotiation failures: [ 583.328246] typec port1.1: VDM 0xff01a150 failed Additionally, the fix ensures that the `pin_assignment` sysfs attribute displays the correct values. Cc: stable Fixes: af8622f6a585 ("usb: typec: ucsi: Support for DisplayPort alt mode") Signed-off-by: Andrei Kuchynski Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260601142837.3240207-1-akuchynski@chromium.org Signed-off-by: Greg Kroah-Hartman commit 3e1b1ac47e8163627f159f30d80d51b914620dd4 Author: Badhri Jagan Sridharan Date: Mon Jun 22 22:08:03 2026 +0000 usb: typec: tcpm: Validate SVID index in svdm_consume_modes() commit 7b681dd5fbf60b24a13c14661e5b7735759fb491 upstream. In svdm_consume_modes(), the SVID value is read from pmdata->svids using pmdata->svid_index as an array index without bounds validation: paltmode->svid = pmdata->svids[pmdata->svid_index]; If pmdata->svid_index is driven beyond SVID_DISCOVERY_MAX (16), it results in an out-of-bounds read of the pmdata->svids array. Because pd_mode_data is embedded inside struct tcpm_port, indexing past svids reads into adjacent fields. In particular: - At index 16, it reads the altmodes count. - At index 18 and beyond, it reads into altmode_desc[], which contains partner-supplied SVDM Discovery Modes VDOs. By injecting a chosen SVID into altmode_desc[0].vdo and driving svid_index to 20, the partner can force paltmode->svid to be loaded with an arbitrary, partner- chosen SVID, which is then registered via typec_partner_register_altmode(). Fix this by validating that pmdata->svid_index is non-negative and strictly less than pmdata->nsvids before accessing the pmdata->svids array inside svdm_consume_modes(). Assisted-by: Antigravity:gemini-3.5-flash Fixes: 4ab8c18d4d67 ("usb: typec: Register a device for every mode") Cc: stable Signed-off-by: Badhri Jagan Sridharan Reviewed-by: RD Babiera Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260622220803.305750-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman commit 0bc177820bd38a3ae77e53b55be770cce2dd0887 Author: Andy Yan Date: Thu Jun 4 18:50:24 2026 +0800 usb: typec: tcpm: Fix VDM type for Enter Mode commands commit 9cff680e47632b7723cb19f9c5e63669063c3417 upstream. VDO() second parameter is VDM type (bit 15): 1 for SVDM, 0 for UVDM. Using 'vdo ? 2 : 1' corrupts SVID low bit when vdo is non-NULL (2 << 15 = BIT(16)). Enter Mode is always SVDM, hardcode to 1. Fixes: 8face9aa57c8 ("usb: typec: Add parameter for the VDO to typec_altmode_enter()") Cc: stable Signed-off-by: Andy Yan Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260604105059.18750-1-andyshrk@163.com Signed-off-by: Greg Kroah-Hartman commit bf6aa6c0ce0db4a1cf1ac4194c6b3f450b9d710b Author: Shuangpeng Bai Date: Thu Jul 2 15:13:29 2026 -0400 usb: typec: class: drop PD lookup reference commit 43ae2f90b70cda374c487c1639a01d0f14e5d583 upstream. usb_power_delivery_find() wraps class_find_device_by_name(). That helper returns a device reference that must be released by the caller. select_usb_power_delivery_store() only needs this reference while calling the pd_set callback. Drop it once the callback returns. Otherwise the sysfs write can pin the selected USB Power Delivery object and prevent it from being released on unregister. Fixes: a7cff92f0635 ("usb: typec: USB Power Delivery helpers for ports and partners") Cc: stable Signed-off-by: Shuangpeng Bai Link: https://patch.msgid.link/20260702191329.2648043-1-shuangpeng.kernel@gmail.com Signed-off-by: Greg Kroah-Hartman commit 1126f1110b86c1f8146338b8b7df905438ea0747 Author: Myeonghun Pak Date: Wed Jul 1 20:40:06 2026 +0900 usb: typec: anx7411: use devm_pm_runtime_enable() commit 0ef7cc27da8b9e315a4a5a665c68c44206f5e559 upstream. anx7411_i2c_probe() enables runtime PM before returning successfully, but anx7411_i2c_remove() tears down the Type-C partner state, workqueue, dummy I2C device, mux, switch and port without disabling runtime PM. Use devm_pm_runtime_enable() so runtime PM is disabled automatically on driver detach. Since devres action registration can fail, route that failure through the existing probe unwind path. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: fe6d8a9c8e64 ("usb: typec: anx7411: Add Analogix PD ANX7411 support") Cc: stable Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260701114006.75738-1-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit 347b59e9f96719d89b6ef555d02a18ada1a5846f Author: Sam Day Date: Fri Jun 26 14:29:10 2026 +1000 usbip: vudc: fix NULL deref in vep_dequeue() commit c5371e0b91b24159a3ebaa61e70b0980bcf03c0a upstream. vep_alloc_request() wasn't initializing vrequest->udc, so cancellations on the FunctionFS AIO path were arriving in vep_dequeue without a valid UDC reference. Since vrequest->udc is never actually properly used anywhere, we opt to remove it, and update vep_dequeue to obtain a reference to the udc with ep_to_vudc(), consistent with the other vep_ ops. AFAICT this bug has existed for ~10 years. Seems that nobody has really stressed the FunctionFS AIO path on usbip's vudc. I tested this fix in a QEMU aarch64 guest driving FunctionFS endpoints via AIO. Before the fix, running `usbip attach` from the host would cause the guest to oops with the following backtrace: Call trace: vep_dequeue+0x1c/0xe4 (P) usb_ep_dequeue+0x14/0x20 ffs_aio_cancel+0x24/0x34 __arm64_sys_io_cancel+0xb0/0x124 do_el0_svc+0x68/0x100 el0_svc+0x18/0x5c el0t_64_sync_handler+0x98/0xdc el0t_64_sync+0x154/0x158 Assisted-by: opencode:openai/gpt-5.5 Cc: stable Fixes: b6a0ca111867 ("usbip: vudc: Add UDC specific ops") Reviewed-by: Igor Kotrasinski Signed-off-by: Sam Day Link: https://patch.msgid.link/20260626-usbip-vudc-deque-fix-v3-1-98c2dc4d6a48@samcday.com Signed-off-by: Greg Kroah-Hartman commit 6c7e8e2514374b0b1ea5897c227de5ebff7b06ec Author: Yichong Chen Date: Wed Jun 17 10:06:13 2026 +0800 usbip: tools: support SuperSpeedPlus devices commit 195e667c8719480c320cd48ac0fbf1cb81d6ffe0 upstream. USB devices running at SuperSpeedPlus report "10000" or "20000" in their sysfs speed attribute. usbip currently maps only "5000" to USB_SPEED_SUPER, so a SuperSpeedPlus device is imported as USB_SPEED_UNKNOWN. The attach request is then rejected by vhci_hcd: vhci_hcd: Failed attach request for unsupported USB speed: UNKNOWN Map the SuperSpeedPlus sysfs speed values to USB_SPEED_SUPER_PLUS, use the SuperSpeed VHCI hub for SuperSpeedPlus devices, and recognize the gadget current_speed string used by the kernel. Fixes: b2316645ca5e ("usb: show speed "10000" in sysfs for USB 3.1 SuperSpeedPlus devices") Cc: stable Signed-off-by: Yichong Chen Reviewed-by: Shuah Khan Link: https://patch.msgid.link/00C828F338E43447+20260617020613.199086-1-chenyichong@uniontech.com Signed-off-by: Greg Kroah-Hartman commit 2d84c8376f7aa7ca703010e79dec26a2183d0ec3 Author: Xu Rao Date: Fri Jun 26 15:06:07 2026 +0800 USB: usb-storage: ene_ub6250: restore media-ready check commit 5fc3f333c001f1e308bbcdeecdec0d054d24338b upstream. Commit 1892bf90677a ("USB: usb-storage: Fix use of bitfields for hardware data in ene_ub6250.c") converted the media status fields from bitfields to bit masks. The original ene_transport() test called ene_init() only when neither media type was ready: !(sd_ready || ms_ready) The converted test became: !sd_ready || ms_ready This is not equivalent. Restore the original semantics by testing that both ready bits are clear before calling ene_init(). Fixes: 1892bf90677a ("USB: usb-storage: Fix use of bitfields for hardware data in ene_ub6250.c") Cc: stable Signed-off-by: Xu Rao Reviewed-by: Alan Stern Link: https://patch.msgid.link/F42641386E32404F+20260626070607.4119527-1-raoxu@uniontech.com Signed-off-by: Greg Kroah-Hartman commit 1967a7f0cd5c08eb479196daa5aaa4b7b7a7bd04 Author: Johan Hovold Date: Mon Jun 8 16:58:03 2026 +0200 USB: ulpi: fix memory leak on registration failure commit 8af6812795869a66e9b26044f455b13deecdb69c upstream. The allocated device name is never freed on early ULPI device registration failures. Fix this by initialising the device structure earlier and releasing the initial reference whenever registration fails. Fixes: 289fcff4bcdb ("usb: add bus type for USB ULPI") Cc: stable Cc: Heikki Krogerus Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260608145803.69360-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 1243f120790042c2ac92e84e797dacc75fff4366 Author: Johan Hovold Date: Tue Jun 23 17:12:29 2026 +0200 USB: serial: digi_acceleport: fix write buffer corruption commit 24ca1fea8f2753bf33e1d458ec1ae5d9b7796a65 upstream. The digi_write_inb_command() is supposed to wait for the write urb to become available or return an error, but instead it updates the transfer buffer and tries to resubmit the urb on timeout. To make things worse, for commands like break control where no timeout is used, the driver would corrupt the urb immediately due to a broken jiffies comparison (on 32-bit machines this takes five minutes of uptime to trigger due to INITIAL_JIFFIES). Fix this by adding the missing return on timeout and waiting indefinitely when no timeout has been specified as intended. This issue was (sort of) flagged by Sashiko when reviewing an unrelated change to the driver. Link: https://sashiko.dev/#/patchset/20260610132232.356139-1-johan%40kernel.org?part=11 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 2b7dc482f859f2d027db07ff0efc1c5df5b3451a Author: Johan Hovold Date: Tue Jun 23 17:11:10 2026 +0200 USB: serial: digi_acceleport: fix hard lockup on disconnect commit 5c1ea24b53bf3bfb859f0a05573997487975da23 upstream. If submitting the OOB write urb fails persistently (e.g if the device is being disconnected) the driver would loop indefinitely with interrupts disabled. Check for urb submission errors when sending OOB commands to avoid hanging if, for example, open(), set_termios() or close() races with a physical disconnect. This is issue was flagged by Sashiko when reviewing an unrelated change to the driver. Link: https://sashiko.dev/#/patchset/20260610132232.356139-1-johan%40kernel.org?part=1 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit eab394781e9321c0c7e97a24fd092387cb262f40 Author: Johan Hovold Date: Tue Jun 23 17:08:15 2026 +0200 USB: serial: digi_acceleport: fix broken rx after throttle commit 83a3dfc018943b05b6daf3a6f891833e1aabfa1f upstream. If the port is closed while throttled, the read urb is never resubmitted and the port will not receive any further data until the device is reconnected (or the driver is rebound). Clear the throttle flags and submit the urb if needed when opening the port. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 4b147eb6ae6e0da5a214aa201b1a3c091827e40f Author: Fabio Porcedda Date: Fri Jun 12 13:39:16 2026 +0200 USB: serial: option: add Telit Cinterion FE990D50 compositions commit b33ab1dd80f5c1742f49eb6ec7b337c5ffcf3d32 upstream. Add support for Telit Cinterion FE990D50 compositions: 0x990: RNDIS + tty (AT/NMEA) + tty (AT) + tty (AT) + tty (AT) + tty (diag) + ADPL + adb T: Bus=01 Lev=01 Prnt=01 Port=06 Cnt=03 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1bc7 ProdID=0990 Rev=06.06 S: Manufacturer=Telit Cinterion S: Product=FE990 S: SerialNumber=90b6a3ed C: #Ifs=10 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=ef(misc ) Sub=04 Prot=01 Driver=rndis_host E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8a(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 7 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none) E: Ad=8c(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 8 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=70 Driver=(none) E: Ad=8d(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 9 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms 0x991: rmnet + tty (AT/NMEA) + tty (AT) + tty (AT) + tty (AT) + tty (diag) + ADPL + adb T: Bus=01 Lev=01 Prnt=01 Port=06 Cnt=03 Dev#= 9 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1bc7 ProdID=0991 Rev=06.06 S: Manufacturer=Telit Cinterion S: Product=FE990 S: SerialNumber=90b6a3ed C: #Ifs= 9 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=(none) E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8a(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 6 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none) E: Ad=8c(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 7 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=70 Driver=(none) E: Ad=8d(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms 0x992: MBIM + tty (AT/NMEA) + tty (AT) + tty (AT) + tty (AT) + tty (diag) + ADPL + adb T: Bus=01 Lev=01 Prnt=01 Port=06 Cnt=03 Dev#= 12 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1bc7 ProdID=0992 Rev=06.06 S: Manufacturer=Telit Cinterion S: Product=FE990 S: SerialNumber=90b6a3ed C: #Ifs=10 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=82(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8a(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 7 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none) E: Ad=8c(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 8 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=70 Driver=(none) E: Ad=8d(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 9 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms 0x993: ECM + tty (AT/NMEA) + tty (AT) + tty (AT) + tty (AT) + tty (diag) + ADPL + adb T: Bus=01 Lev=01 Prnt=01 Port=06 Cnt=03 Dev#= 15 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1bc7 ProdID=0993 Rev=06.06 S: Manufacturer=Telit Cinterion S: Product=FE990 S: SerialNumber=90b6a3ed C: #Ifs=10 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl=32ms I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8a(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 7 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none) E: Ad=8c(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 8 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=70 Driver=(none) E: Ad=8d(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 9 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms Cc: stable@vger.kernel.org Signed-off-by: Fabio Porcedda Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit cf6ca0aefae03958cfb5b189b0adbfb25c06bfac Author: Johan Hovold Date: Mon Jun 29 14:45:26 2026 +0200 USB: serial: keyspan_pda: fix information leak commit 6bfc8d01ac4068eced509f8fc74d0cd205e4dcec upstream. The write() callback is supposed to return the number of characters accepted or a negative errno. Since the addition of write fifo support the keyspan_pda implementation will however return the number characters submitted to the device if the write urb is not already in use. If this number is larger than the number of characters passed to write(), the line discipline continues writing data from beyond the tty write buffer. Fix the information leak by making sure that keyspan_pda_write_start() returns zero on success as intended. Fixes: 034e38e8f687 ("USB: serial: keyspan_pda: add write-fifo support") Cc: stable@vger.kernel.org # 5.11 Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 8c29d9cfab1c3cf0d0b7fcdf9255597be30aa3e1 Author: Haoxiang Li Date: Tue Jun 23 17:33:25 2026 +0800 usb: mtu3: unmap request DMA on queue failure commit 0bddda5a11665c210339de76d27ebbd1a2e0b43c upstream. mtu3_gadget_queue() maps the request before checking whether the QMU GPD ring can accept another transfer. the request is returned with -EAGAIN before it is linked on the endpoint request list if mtu3_prepare_transfer() fails. Normal completion and dequeue paths unmap requests from mtu3_req_complete(), but this error path never reaches that helper, so the DMA mapping is left active. Unmap the request before returning from the failed queue path. Fixes: df2069acb005 ("usb: Add MediaTek USB3 DRD driver") Cc: stable Signed-off-by: Haoxiang Li Link: https://patch.msgid.link/20260623093325.2105323-1-haoxiang_li2024@163.com Signed-off-by: Greg Kroah-Hartman commit 729b68a5bad71220ae0914c8bdab9488ad5be6c8 Author: Myeonghun Pak Date: Tue Jul 7 00:10:49 2026 +0900 USB: misc: uss720: unregister parport on probe failure commit b4ecbdc4f8830f5586c4a5cfc384c00f20f8f8b3 upstream. uss720_probe() registers a parport before reading the 1284 register used to detect unsupported Belkin F5U002 adapters. If get_1284_register() fails, the error path drops the driver private data and the USB device reference, but leaves the parport device registered. Leaving the port registered is more than a private allocation leak: parport_register_port() has already reserved a parport number and registered the parport bus device, while pp->private_data still points at the private data that the common error path is about to release. Undo the pre-announce registration in the get_1284_register() failure branch before jumping to the common private-data cleanup path. Clear priv->pp first, matching the disconnect path and avoiding a stale pointer in the private data. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 3295f1b866bf ("usb: misc: uss720: check for incompatible versions of the Belkin F5U002") Cc: stable Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Alex Henrie Link: https://patch.msgid.link/20260706151049.63470-1-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit 48394f94211cf8fe0ea8604fc441633abf90fc94 Author: HE WEI (ギカク) Date: Wed Jun 24 18:09:52 2026 +0900 usb: misc: usbio: bound bulk IN response length to the received transfer commit 8c6314489550fa81d41723a0ff33f655b5b6c7b6 upstream. usbio_bulk_msg() copies bpkt_len = le16_to_cpu(bpkt->len) bytes out of the bulk IN buffer (usbio->rxbuf, allocated with size usbio->rxbuf_len) into the caller's buffer. bpkt_len is fully controlled by the device and is only checked against ibuf_len; ibuf_len in turn is checked against usbio->txbuf_len, not against rxbuf_len: if ((obuf_len > (usbio->txbuf_len - sizeof(*bpkt))) || (ibuf_len > (usbio->txbuf_len - sizeof(*bpkt)))) return -EMSGSIZE; txbuf_len and rxbuf_len are taken independently from the bulk OUT and bulk IN endpoint wMaxPacketSize in usbio_probe(). A malicious or malfunctioning device that advertises a large bulk OUT endpoint and a small bulk IN endpoint (e.g. by claiming one of the quirk-free IDs such as the Lattice NX33U, 0x2ac1:0x20cb) therefore makes ibuf_len, and hence the device-supplied bpkt_len, exceed rxbuf_len. memcpy() then reads up to txbuf_len - rxbuf_len bytes past the end of the rxbuf slab object. The over-read bytes are handed back to the i2c layer and on to user space through i2c-dev, disclosing adjacent slab memory; with KASAN this is reported as a slab-out-of-bounds read. The number of bytes actually received is already known: act equals the URB actual_length and is bounded by rxbuf_len. Reject any response that claims more payload than was received, mirroring the existing "act < sizeof(*bpkt)" check just above. The control path (usbio_ctrl_msg()) is not affected: it uses a single buffer (ctrlbuf) for both directions, so its analogous copy can never leave the allocation. Found by code review. The out-of-bounds read was confirmed under AddressSanitizer with a faithful userspace model of usbio_bulk_msg()'s receive path (an rxbuf_len-sized buffer, the same act/ibuf_len/bpkt_len checks and the memcpy). A USB raw-gadget + dummy_hcd reproducer is also available. Fixes: 121a0f839dbb ("usb: misc: Add Intel USBIO bridge driver") Cc: stable Signed-off-by: HE WEI (ギカク) Link: https://patch.msgid.link/20260624090952.86439-1-skyexpoc@gmail.com Signed-off-by: Greg Kroah-Hartman commit 964d572b6c00902fe216f2e1832cce7136cac31d Author: Xu Rao Date: Tue Jun 2 13:38:42 2026 +0800 USB: storage: include US_FL_NO_SAME in quirks mask commit 2c00e09e3f9f06f8434f5ea2ee6179ce46692ee6 upstream. usb_stor_adjust_quirks() parses the usb-storage.quirks module parameter into a new flag set and then applies it with the quirk mask to override built-in flags. The mask is meant to cover the flags that can be overridden by the module parameter. The 'k' quirk character sets US_FL_NO_SAME, but US_FL_NO_SAME is not included in the mask. As a result, the module parameter can set US_FL_NO_SAME, but it cannot clear a built-in US_FL_NO_SAME flag by providing an override entry that omits 'k'. Add US_FL_NO_SAME to the mask so that the module parameter can override it in the same way as the other supported flags. Fixes: 8010622c86ca ("USB: UAS: introduce a quirk to set no_write_same") Cc: stable Signed-off-by: Xu Rao Reviewed-by: Alan Stern Link: https://patch.msgid.link/3BCE5880F9A45C2E+20260602053842.2920137-1-raoxu@uniontech.com Signed-off-by: Greg Kroah-Hartman commit e0886775952e3dd542b11ec54cb5476e62acc4f6 Author: Myeonghun Pak Date: Wed Jul 1 21:16:25 2026 +0900 usb: sl811-hcd: disable controller wakeup on remove commit 4e8ba83ac4d311992e6a4c21de5dd705010df06e upstream. sl811h_probe() enables the HCD controller device as a wakeup source after usb_add_hcd() succeeds, but sl811h_remove() removes the HCD and releases the driver resources without disabling that wakeup source. Disable controller wakeup after usb_remove_hcd() and before usb_put_hcd() so the wakeup source object is detached while the controller device pointer is still available. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 3c9740a117d4 ("usb: hcd: move controller wakeup setting initialization to individual driver") Cc: stable Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Link: https://patch.msgid.link/20260701121625.96815-1-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit 766738ecf2b819e54d38763c8d1c8ae6cff14b39 Author: Johan Hovold Date: Mon Jun 22 17:26:12 2026 +0200 USB: legousbtower: fix use-after-free on disconnect race commit 62fc8eb1b1481051f7bab4aa93d79809053dd09f upstream. mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2] Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect(). [1] a51749ab34d9 ("locking/mutex: Document that mutex_unlock() is non-atomic") [2] 2b9d9e0a9ba0 ("locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked") Fixes: 18bcbcfe9ca2 ("USB: misc: legousbtower: semaphore to mutex") Cc: stable Cc: Daniel Walker Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260622152612.116422-5-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 6af28345cbf8b9a5142353353871f73433f8dd9d Author: Erich E. Hoover Date: Tue Jun 2 14:45:08 2026 -0600 USB: quirks: add NO_LPM for the Samsung T5 EVO Portable SSD commit fc591787785b9709a0bb65a7df3ba2537d611c47 upstream. The Samsung T5 EVO Portable SSD (04e8:6200) exhibit two forms of link instability when USB Link Power Management is enabled: 1. The units fail to initialize properly on first detection, resulting in a lockup in the drive where it must be power cycled or the kernel will not recognize the presence of the device. 2. If used for sustained operations (small amounts of continuous data are transferred to the unit) then the unit will "hiccup" after roughly 8 hours of use and will disconnect and reconnect. This has a certain probability of triggering the first issue, but also causes mount points to become invalid since the device gets issued a new letter. Signed-off-by: Erich E. Hoover Cc: stable Link: https://patch.msgid.link/20260602204508.48856-1-erich.e.hoover@gmail.com Signed-off-by: Greg Kroah-Hartman commit b748f97aff339e7f08dca9cf38a05b980fb66fea Author: Johan Hovold Date: Sat May 23 19:05:23 2026 +0200 USB: iowarrior: fix use-after-free on disconnect commit bc0e4f16c44e50daa0b1ea729934baa3b4815dee upstream. Submitted write URBs are not stopped on close() and therefore need to be stopped unconditionally on disconnect() to avoid use-after-free in the completion handler. Fixes: b5f8d46867ca ("USB: iowarrior: fix use-after-free after driver unbind") Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.") Reported-by: syzbot+ad2aac2febc3bedf0962@syzkaller.appspotmail.com Link: https://lore.kernel.org/all/6a0ce39b.170a0220.39a13.0007.GAE@google.com/ Cc: stable Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260523170523.1074563-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 2107a4fc8ff1cf1d52f416c1e5cc8e97413a5915 Author: Johan Hovold Date: Mon Jun 22 17:26:11 2026 +0200 USB: ldusb: fix use-after-free on disconnect race commit 19bdfc7b3c179331eafa423d87e1336f43bbfeb8 upstream. mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2] Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect(). [1] a51749ab34d9 ("locking/mutex: Document that mutex_unlock() is non-atomic") [2] 2b9d9e0a9ba0 ("locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked") Fixes: ce0d7d3f575f ("usb: ldusb: ld_usb semaphore to mutex") Cc: stable Cc: Daniel Walker Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260622152612.116422-4-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 54c2b7356b4aeea467f9fb13b85e9e036bc428cb Author: Johan Hovold Date: Mon Jun 22 17:26:10 2026 +0200 USB: idmouse: fix use-after-free on disconnect race commit ff002c153f9722caece3983cc23dc4d9d4652cb4 upstream. mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2] Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect(). [1] a51749ab34d9 ("locking/mutex: Document that mutex_unlock() is non-atomic") [2] 2b9d9e0a9ba0 ("locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked") Fixes: 54d2bc068fd2 ("USB: fix locking in idmouse") Cc: stable@vger.kernel.org # 2.6.24 Cc: Oliver Neukum Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260622152612.116422-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 8a5eba992c862b0c94411eecf9b7121e8636db38 Author: Xu Rao Date: Fri Jun 26 14:46:17 2026 +0800 usb: gadget: f_printer: take kref only for successful open commit 30adce93d5c4a5a1ec29d9249e3fdfcc391d406b upstream. printer_open() returns -EBUSY when the character device is already open, but it increments dev->kref regardless of the return value. VFS does not call ->release() for a failed open, so every rejected second open permanently leaks one reference. Move kref_get() into the successful-open branch. Fixes: e8d5f92b8d30 ("usb: gadget: function: printer: fix use-after-free in __lock_acquire") Cc: stable Signed-off-by: Xu Rao Link: https://patch.msgid.link/80295742B820DA9B+20260626064617.4090626-1-raoxu@uniontech.com Signed-off-by: Greg Kroah-Hartman commit b52476a83d9e12df00765359d728a875b128bef1 Author: Jimmy Hu Date: Thu Jun 25 15:37:04 2026 +0800 usb: gadget: udc: Fix use-after-free in gadget_match_driver commit 67e511d2989eb1c8c588b599ce2fcc6bb8e6f7ea upstream. The udc structure acts as the management structure for the gadget, but their lifecycles are decoupled. A race condition exists where usb_del_gadget() frees the udc memory (e.g., via mode-switch work) while gadget_match_driver() concurrently accesses the freed udc memory (e.g., via configfs), causing a Use-After-Free (UAF) that triggers a NULL pointer dereference when the freed memory is zeroed: [39430.908615][ T1171] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [39430.911397][ T1171] pc : __pi_strcmp+0x20/0x140 [39430.911441][ T1171] lr : gadget_match_driver+0x34/0x60 ... [39430.911890][ T1171] usb_gadget_register_driver_owner+0x50/0xf8 [39430.911910][ T1171] gadget_dev_desc_UDC_store+0xf4/0x140 [39430.931308][ T1171] configfs_write_iter+0xec/0x134 [39430.957058][ T1171] Workqueue: events_freezable __dwc3_set_mode [39430.957287][ T1171] dwc3_gadget_exit+0x34/0x8c [39430.957304][ T1171] __dwc3_set_mode+0xc0/0x664 Fix this by ensuring the udc structure remains allocated until the gadget is released. To achieve this, introduce a new usb_gadget_release() routine to the core. When the gadget is added, usb_add_gadget() stores the gadget's release routine in the udc structure and takes a reference to the udc. When the gadget is released, usb_gadget_release() drops the reference to the udc and then calls the gadget's release routine. Suggested-by: Alan Stern Cc: stable Signed-off-by: Jimmy Hu Reviewed-by: Alan Stern Link: https://patch.msgid.link/20260625073705.803880-1-hhhuuu@google.com Signed-off-by: Greg Kroah-Hartman commit 01feaf024f29618d5ffa7ab0fd858e0579dcbf7b Author: Maoyi Xie Date: Wed May 27 23:08:32 2026 +0800 usb: gadget: composite: fix dead empty check in the USB_DT_OTG handler commit f8f680609c2b3ab795ffcd6f21585b6dfc46d395 upstream. The OTG branch of composite_setup() falls back to the first configuration when none is selected: if (cdev->config) config = cdev->config; else config = list_first_entry(&cdev->configs, struct usb_configuration, list); if (!config) goto done; ... memcpy(req->buf, config->descriptors[0], value); list_first_entry() never returns NULL. On an empty list it returns container_of() of the list head. So the "if (!config)" check is dead. When cdev->configs is empty, config points at the head inside struct usb_composite_dev. config->descriptors[0] reads whatever sits at that offset. The memcpy copies up to w_length bytes of it into the response buffer. cdev->configs can be empty in two cases. One is a teardown race on gadget unbind with a control transfer in flight. The other is a driver that sets is_otg before it adds a config. A reproducer that holds cdev->configs empty triggers a KASAN fault in this branch. Use list_first_entry_or_null() so the existing check does its job. Fixes: 53e6242db8d6 ("usb: gadget: composite: add USB_DT_OTG request handling") Cc: stable Signed-off-by: Maoyi Xie Link: https://patch.msgid.link/20260527150832.2943293-1-maoyixie.tju@gmail.com Signed-off-by: Greg Kroah-Hartman commit 6bc17a78a05671d303820224fb37ca339c1dc2cb Author: Dawei Feng Date: Tue Jun 30 15:14:19 2026 +0800 usb: free iso schedules on failed submit commit b9399d25fbb34a05bbe76eeedd730f62ff2670e9 upstream. EHCI and FOTG210 isochronous submits build an ehci_iso_sched before linking the URB to the endpoint queue, and keep the staged schedule in urb->hcpriv until iso_stream_schedule() and the link helpers consume it. If the controller is no longer accessible, or usb_hcd_link_urb_to_ep() fails, submit jumps to done_not_linked before that handoff happens and leaks the staged schedule still attached to urb->hcpriv. Free the staged schedule from done_not_linked when submit fails before the URB is linked and clear urb->hcpriv after the free. 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 EHCI host controller with a USB isochronous device to test with, no runtime testing was able to be performed. Fixes: 8de98402652c ("[PATCH] USB: Fix USB suspend/resume crasher (#2)") Fixes: e9df41c5c589 ("USB: make HCDs responsible for managing endpoint queues") Fixes: 7d50195f6c50 ("usb: host: Faraday fotg210-hcd driver") Cc: stable Signed-off-by: Dawei Feng Reviewed-by: Alan Stern Link: https://patch.msgid.link/20260630071419.349161-1-dawei.feng@seu.edu.cn Signed-off-by: Greg Kroah-Hartman commit 0bbab8882a319f74dbcd40fd30b8e072656eb360 Author: WenTao Liang Date: Thu Jun 11 21:11:21 2026 +0800 usb: dwc3: meson-g12a: fix refcount leak in dwc3_meson_g12a_resume() commit 692c354bef03b77b30e57e61934da502c8a12d45 upstream. If dwc3_meson_g12a_resume() succeeds in calling reset_control_reset(), an internal triggered_count reference is acquired. If any later step fails (usb_init, phy_init, phy_power_on, regulator_enable, or usb_post_init), the function returns the error without rearming the reset control. This leaks the reference and leaves the reset control in a triggered state, causing future reset_control_reset() calls to incorrectly return early as if already reset. Add an error path that calls reset_control_rearm() to balance the reference before returning the error. Cc: stable Fixes: 5b0ba0caaf3a ("usb: dwc3: meson-g12a: refactor usb init") Signed-off-by: WenTao Liang Link: https://patch.msgid.link/20260611131121.81784-1-vulab@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit 4b0779207e36d924bcfe5e34e8b817aecdea87a9 Author: Rodrigo Lugathe da Conceição Alves Date: Wed Jun 3 08:36:26 2026 -0300 USB: core: add USB_QUIRK_NO_LPM for VIA Labs USB 2.0 hub commit bd728c3d9b1cc0bb0fda6a7055c5c8b55d7477b2 upstream. The VIA Labs, Inc. USB 2.0 hub controller (2109:2817), found in a KVM switch, fails to enumerate high-power devices during cold boot and system restart. Applying the kernel parameter usbcore.quirks=2109:2817:k resolves the issue. Enumeration failure log: usb 1-1.2.3: device descriptor read/64, error -32 usb 1-1.2.3: Device not responding to setup address. usb 1-1.2.3: device not accepting address 11, error -71 usb 1-1.2-port3: unable to enumerate USB device Add USB_QUIRK_NO_LPM for this device. Signed-off-by: Rodrigo Lugathe da Conceição Alves Cc: stable Link: https://patch.msgid.link/20260603113626.395612-1-lugathe2@gmail.com Signed-off-by: Greg Kroah-Hartman commit c00826e87bb75e14e0381b05da5f18ffd0241ab6 Author: Haoxiang Li Date: Mon Jun 22 13:26:27 2026 +0800 usb: cdnsp: fix stream context array leak in cdnsp_alloc_stream_info() commit 3348f444a4ce43dd5c2d1aa41634cb6eff33aa64 upstream. cdnsp_alloc_stream_info() allocates stream_info->stream_ctx_array with cdnsp_alloc_stream_ctx(). If a later stream ring allocation or stream mapping update fails, the error path frees the allocated stream rings and stream_rings array, but leaves stream_ctx_array allocated. Free the stream context array before falling through to the stream_rings cleanup path. Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver") Cc: stable Signed-off-by: Haoxiang Li Acked-by: Peter Chen Link: https://patch.msgid.link/20260622052627.696373-1-haoxiang_li2024@163.com Signed-off-by: Greg Kroah-Hartman commit e22f044b0b20df5304e017912483d065047a12df Author: Jared Baldridge Date: Sat May 30 18:19:48 2026 -0400 usb: cdc_acm: Add quirk for Uniden BC125AT scanner commit 6eba58568f6cc3ff8515a00b05e258d8cfb72b72 upstream. Uniden BC125AT radio scanner has a USB interface which fails to work with the cdc_acm driver: usb 1-1: new full-speed USB device number 2 using uhci_hcd cdc_acm 1-1:1.0: Zero length descriptor references cdc_acm 1-1:1.0: probe with driver cdc_acm failed with error -22 usbcore: registered new interface driver cdc_acm Adding the NO_UNION_NORMAL quirk for the device fixes the issue: usb 1-1: new full-speed USB device number 2 using uhci_hcd cdc_acm 1-1:1.0: ttyACM0: USB ACM device usbcore: registered new interface driver cdc_acm `lsusb -v` of the device: Bus 001 Device 002: ID 1965:0017 Uniden Corporation BC125AT Negotiated speed: Full Speed (12Mbps) Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 2 Communications bDeviceSubClass 0 [unknown] bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x1965 Uniden Corporation idProduct 0x0017 BC125AT bcdDevice 0.01 iManufacturer 1 Uniden America Corp. iProduct 2 BC125AT iSerial 3 0001 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0030 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x87 EP 7 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 10 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 [unknown] bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x0000 (Bus Powered) Signed-off-by: Jared Baldridge Cc: stable Link: https://patch.msgid.link/20260530221959.612526-1-jrb@expunge.us Signed-off-by: Greg Kroah-Hartman commit e24eb271061db384a3c3ef6f107fe515e68ef222 Author: Maoyi Xie Date: Mon Jun 22 16:01:57 2026 +0800 net: usb: kalmia: bound RX frame length in kalmia_rx_fixup() commit 47b6bcef6e679593d2e86e04ee72c46a4e2f7139 upstream. kalmia_rx_fixup() computes usb_packet_length = skb->len - (2 * KALMIA_HEADER_LENGTH) as a u16, guarded only by a pre-loop check that skb->len is at least KALMIA_HEADER_LENGTH, which is 6. A device can deliver a short bulk-IN frame with skb->len in the 6 to 11 range, or leave a short trailing remainder on a later loop iteration. Either case underflows usb_packet_length to about 65530. That bypasses the usb_packet_length < ether_packet_length truncation path. The device-supplied ether_packet_length, a le16 up to 65535 read from header_start[2], then drives a memcmp() and the following skb_trim() and skb_pull() past the end of the rx buffer. The rx buffer is hard_mtu * 10, which is 14000 bytes. That is an out of bounds read. Require both the start and end framing headers to be present before subtracting them, on every loop iteration. Fixes: d40261236e8e ("net/usb: Add Samsung Kalmia driver for Samsung GT-B3730") Cc: stable@vger.kernel.org Signed-off-by: Maoyi Xie Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/178211531778.2216480.12637613349790980750@maoyixie.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit cd407de2ef5dc70f1970b343ffaa16186340fdfd Author: Paul Moses Date: Fri Jun 5 23:43:09 2026 +0000 bpf: Validate BTF repeated field counts before expansion commit b9452b594fd3aecbfd4aa0a6a1f741330a37dab7 upstream. btf_parse_struct_metas() walks user-supplied BTF during BPF_BTF_LOAD, and btf_repeat_fields() expands repeatable fields from array elements into the fixed BTF_FIELDS_MAX scratch array used by btf_parse_fields(). The remaining-capacity check performs the expanded field count calculation in u32. A malformed BTF can wrap that calculation, causing the check to pass even when the expanded field count exceeds the scratch array capacity. The following memcpy() can then write past the end of the array. Use checked addition and multiplication before copying repeated fields and reject impossible counts. Fixes: 797d73ee232d ("bpf: Check the remaining info_cnt before repeating btf fields") Cc: stable@vger.kernel.org Signed-off-by: Paul Moses Acked-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/20260605234301.1109063-1-p@1g4.org Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Greg Kroah-Hartman commit d94ab0e91d3ff7577cd0306a47270a6dcb82f76c Author: Dawei Feng Date: Wed Jun 3 18:53:17 2026 +0800 bpf: Restore sysctl new-value from 1 to 0 commit 2566c3b24219c5b30e35205cba029ff34ff7c78b upstream. Commit 4e63acdff864 ("bpf: Introduce bpf_sysctl_{get,set}_new_value helpers") changed the success return value to 0, but failed to update the corresponding check in __cgroup_bpf_run_filter_sysctl(). Since bpf_prog_run_array_cg() now returns 0 on success, the legacy ret == 1 condition is never satisfied. As a result, the modified value is ignored, and bpf_sysctl_set_new_value() fails to replace the write buffer. Fix this by checking for a return value of 0 instead, so cgroup/sysctl programs can correctly replace the pending sysctl buffer. This bug was discovered during a manual code review. Tested via a cgroup/sysctl BPF reproducer overriding writes to a target sysctl. Pre-fix, bpf_sysctl_set_new_value("foo") was silently ignored: the write returned 8192 and the value remained "600". Post-fix, the BPF replacement buffer properly propagates: the write returns 3 and the value updates to "foo". Fixes: f10d05966196 ("bpf: Make BPF_PROG_RUN_ARRAY return -err instead of allow boolean") Cc: stable@vger.kernel.org Acked-by: Yonghong Song Signed-off-by: Zilin Guan Signed-off-by: Dawei Feng Reviewed-by: Jiayuan Chen Acked-by: Xu Kuohai Link: https://lore.kernel.org/r/20260603105317.944304-4-dawei.feng@seu.edu.cn Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit a9bb2d9c798cb62a4050a991c27b752770c33afe Author: Zhao Zhang Date: Tue Jun 2 16:43:33 2026 +0800 bpf: Reject fragmented frames in devmap commit aa496720618f1a6054f1c870bf10b4f6c99bf656 upstream. Devmap broadcast redirects clone the packet for all but the last destination. For native XDP, that clone path copies only the linear xdp_frame data, while fragmented frames keep skb_shared_info in tailroom outside the linear area. Cloning such a frame leaves XDP_FLAGS_HAS_FRAGS set but without valid frag metadata, and the later free path can interpret uninitialized tail data as skb_shared_info, leading to an out-of-bounds access during frame return. Reject fragmented native XDP frames in dev_map_enqueue_clone(). Add the same restriction to the generic XDP clone path in dev_map_redirect_clone(). Generic XDP represents fragmented packets as nonlinear skbs, and rejecting them here keeps clone-based broadcast support aligned between native and generic XDP. Fixes: e624d4ed4aa8 ("xdp: Extend xdp_redirect_map with broadcast support") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Zhengchuan Liang Reported-by: Xin Liu Assisted-by: Codex:GPT-5.4 Signed-off-by: Zhao Zhang Signed-off-by: Ren Wei Reviewed-by: Emil Tsalapatis Reviewed-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/r/21c2d153dd25603d359069a02bf06779b51f6423.1780385378.git.zzhan461@ucr.edu Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit c3d3d2212c2966973dd7d603c6c6e6ed6fc7fbe1 Author: Dawei Feng Date: Sat Jun 27 14:04:02 2026 +0800 xfs: fix memory leak in xfs_dqinode_metadir_create() commit 45de375b25060edf46e20abb36521ba530336ceb upstream. If xfs_metadir_create() fails in xfs_dqinode_metadir_create(), the current code returns directly, leaking the allocated update and transaction state. If the subsequent commit fails, the caller-owned inode reference is left behind. Fix this memory leak by routing the create failure path through xfs_metadir_cancel(). For both create and commit failures, finish and release any inode returned to the caller, mirroring the unwind pattern in xfs_metadir_mkdir(). 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. Runtime validation used kprobe fault injection during `mount -o uquota` on a metadir XFS image. Injecting xfs_metadir_create() reproduced the old active-update path that left mount stuck later in mount setup; after this change, the same injection reported cancel_hits=1 and irele_hits=1. Injecting xfs_metadir_commit() exercised the old inode-reference leak path; after this change, it reported irele_hits=1. Fixes: e80fbe1ad8ef ("xfs: use metadir for quota inodes") Cc: stable@vger.kernel.org # v6.13 Signed-off-by: Dawei Feng Reviewed-by: "Darrick J. Wong" Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit a62ef2d13d6e7270dd5e88c6082bf2d0edcd5112 Author: Yingjie Gao Date: Thu Jun 4 20:03:17 2026 +0800 xfs: fix exchmaps reservation limit check commit 0a5213bbff62b51c7d4999ac8c7e11ea57d00d45 upstream. xfs_exchmaps_estimate_overhead() adds the bmbt and rmapbt overhead to a local resblks variable, but the final UINT_MAX check still tests req->resblks. That is the reservation value from before the overhead was added. The computed value is stored back in req->resblks and later passed to xfs_trans_alloc(), whose block reservation argument is unsigned int. Check the computed reservation so the existing limit applies to the value that will be used. Fixes: 966ceafc7a43 ("xfs: create deferred log items for file mapping exchanges") Cc: stable@vger.kernel.org # v6.10 Signed-off-by: Yingjie Gao Reviewed-by: "Darrick J. Wong" Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 55e4d8413fb5442c11fbbf484f1bfad9db3499e5 Author: Darrick J. Wong Date: Tue Jun 9 21:57:24 2026 -0700 xfs: fix pointer arithmetic error on 32-bit systems commit 84eec3f7fc73144d1a230c9e8ad92721e37dcaab upstream. The translation of the old XFS_BMBT_KEY_ADDR macro into a static function is not correct on 32-bit systems because the sizeof() argument went from being a xfs_bmbt_key_t (i.e. a struct) to a (struct xfs_bmbt_key *) (i.e. a pointer to the same struct). On 64-bit systems this turns out ok because they are the same size, but on 32-bit systems this is catastrophic because they are not the same size. So far there have been no complaints, most likely because the xfs developers urge against running it on 32-bit systems. But this needs fixing asap. Cc: stable@vger.kernel.org # v6.12 Fixes: 79124b37400635 ("xfs: replace shouty XFS_BM{BT,DR} macros") Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit dd8d0665cdabfc07543661fe6197c87ea5f1bdb1 Author: Alexey Nepomnyashih Date: Wed Jun 3 20:41:47 2026 +0000 xfs: fix unreachable BIGTIME check in dquot flush validation commit 03866d130ed33ab68cc7faaf4bf2c4abef96d42e upstream. The dqp->q_id == 0 check inside the XFS_DQTYPE_BIGTIME block is unreachable because root dquots return successfully earlier. Reject root dquots with XFS_DQTYPE_BIGTIME before that early return, preserving the intended validation and removing the unreachable condition. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 4ea1ff3b4968 ("xfs: widen ondisk quota expiration timestamps to handle y2038+") Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Alexey Nepomnyashih Reviewed-by: "Darrick J. Wong" Reviewed-by: Allison Henderson Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 936618643591c6e6f6a3e4f9dbbc9e44ac1d6dea Author: Yingjie Gao Date: Thu Jun 25 21:16:23 2026 +0800 xfs: release dquot buffer after dqflush failure commit 0c1b3a823a22af623d55f225fe2ac7e8b9052821 upstream. xfs_qm_dqpurge() gets a locked buffer from xfs_dquot_use_attached_buf(). If xfs_qm_dqflush() fails, the error path skips xfs_buf_relse() and then calls xfs_dquot_detach_buf(), which tries to lock the same buffer again. Release the buffer after xfs_qm_dqflush() returns so the error path drops the caller hold and unlocks the buffer before the dquot is detached, matching the other dqflush callers. Fixes: a40fe30868ba ("xfs: separate dquot buffer reads from xfs_dqflush") Cc: stable@vger.kernel.org # v6.13+ Signed-off-by: Yingjie Gao Reviewed-by: "Darrick J. Wong" Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 200794d0354cdcad9464c611b96e2e5b1fef09d8 Author: Yousef Alhouseen Date: Tue Jun 30 12:06:07 2026 +0200 xfs: use null daddr for unset first bad log block commit cc9af5e461ea5f6e37738f3f1e41c45a9b7f45d6 upstream. xlog_do_recovery_pass() may return before setting first_bad. The caller must distinguish that case from an error at a valid log block, including block zero after the log wraps. Initialize first_bad to XFS_BUF_DADDR_NULL and test it explicitly before treating the error as a torn write. Fixes: 7088c4136fa1 ("xfs: detect and trim torn writes during log recovery") Suggested-by: Darrick J. Wong Reported-by: syzbot+b7dfbed0c6c2b5e9fd34@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b7dfbed0c6c2b5e9fd34 Cc: stable@vger.kernel.org # v4.5 Signed-off-by: Yousef Alhouseen Reviewed-by: "Darrick J. Wong" Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 1cd54e217c6e2cdb794a897b2f855e13ffcee586 Author: Andy Shevchenko Date: Fri Jun 26 11:49:37 2026 +0200 serial: 8250_mid: Disable DMA for selected platforms commit b1b4efea05a56c0995e4702a86d6624b4fdff32f upstream. In accordance with Errata (specification updates) HSUART May Stop Functioning when DMA is Active. - Denverton document #572409, rev 3.4, DNV60 - Ice Lake Xeon D document #714070, ICXD65 - Snowridge document #731931, SNR44 For a quick fix just disable the respective callbacks during the device probe. Depending on the future development we might remove them completely. Reported-by: micas-opensource Closes: https://lore.kernel.org/linux-serial/20250625031409.2404219-1-opensource@ruijie.com.cn/ Fixes: 6ede6dcd87aa ("serial: 8250_mid: add support for DMA engine handling from UART MMIO") Cc: stable Signed-off-by: Andy Shevchenko Link: https://patch.msgid.link/20260626094937.561776-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 973408ceab14555a8548b97c8cc7b54208c3f251 Author: Louis-Alexis Eyraud Date: Wed Apr 1 11:44:15 2026 +0200 media: mtk-jpeg: cancel workqueue on release for supported platforms only commit b1845a227fda37b2fe5327df3ca0015d7e290235 upstream. Since a recent fix the mtk_jpeg_release function cancels any pending or running work present in the driver workqueue using cancel_work_sync function. Currently, only the multicore based variants use this workqueue and they have the jpeg_worker platform data field initialized with a workqueue callback function. For the others, this field value remain NULL by default. The cancel_work_sync function is unconditionally called in mtk_jpeg_release function, even for the variants that do not use the workqueue. This call generates a WARN_ON print in __flush_work because the workqueue callback function presence check fails in __flush_work function (used by cancel_work_sync). So, to avoid these warnings, call cancel_work_sync only if a workqueue callback is defined in platform data. Fixes: 34c519feef3e ("media: mtk-jpeg: fix use-after-free in release path due to uncancelled work") Cc: stable@vger.kernel.org Signed-off-by: Louis-Alexis Eyraud Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 223463c488b0554212a94de971ea538eb2805fc7 Author: Deepanshu Kartikey Date: Sun May 3 13:33:29 2026 +0900 nilfs2: reject CLEAN_SEGMENTS ioctl with out-of-range segment numbers commit 0e7a690fe435f8d5ea3feb7c1d8d73ba7e8b8aa9 upstream. Syzbot reported a hung task in nilfs_transaction_begin() where multiple tasks performing chmod() on a nilfs2 mount blocked for over 143 seconds waiting to acquire ns_segctor_sem for read: INFO: task syz.0.17:5918 blocked for more than 143 seconds. Call Trace: schedule+0x164/0x360 rwsem_down_read_slowpath+0x6d9/0x940 down_read+0x99/0x2e0 nilfs_transaction_begin+0x364/0x710 fs/nilfs2/segment.c:221 nilfs_setattr+0x124/0x2c0 fs/nilfs2/inode.c:921 notify_change+0xc1a/0xf40 chmod_common+0x273/0x4a0 do_fchmodat+0x12d/0x230 The writer holding ns_segctor_sem was a concurrent NILFS_IOCTL_CLEAN_SEGMENTS caller, stuck inside printk while emitting per-element warnings from nilfs_sufile_updatev(): __nilfs_msg+0x373/0x450 fs/nilfs2/super.c:78 nilfs_sufile_updatev+0x21c/0x6d0 fs/nilfs2/sufile.c:186 nilfs_sufile_freev fs/nilfs2/sufile.h:93 [inline] nilfs_free_segments fs/nilfs2/segment.c:1140 [inline] nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1261 [inline] nilfs_segctor_do_construct+0x1f55/0x76c0 nilfs_clean_segments+0x3bd/0xa50 nilfs_ioctl_clean_segments fs/nilfs2/ioctl.c:922 [inline] nilfs_ioctl+0x261f/0x2780 The root cause is that user-supplied segment numbers are not validated before nilfs_clean_segments() begins doing work; the range check on each segnum is performed deep inside the call chain by nilfs_sufile_updatev(), which emits a nilfs_warn() per invalid entry while still holding the segctor lock and the sufile mi_sem. Under load (repeated invocations across multiple mounts saturating the global printk path), the cumulative printk latency keeps ns_segctor_sem held long enough to trip the hung_task watchdog, blocking concurrent operations such as chmod() that need ns_segctor_sem for read. Fix by validating the contents of kbufs[4] in nilfs_clean_segments() immediately after acquiring ns_segctor_sem via nilfs_transaction_lock(). Holding ns_segctor_sem serializes the check against nilfs_ioctl_resize(), which can modify ns_nsegments, so the validation uses a consistent value. Out-of-range segment numbers are rejected with -EINVAL before any segment-cleaning work begins, so the bad entries never reach the per-element diagnostic path inside nilfs_sufile_updatev(). Reported-by: syzbot+62f0f99d2f2bb8e3bbd7@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=62f0f99d2f2bb8e3bbd7 Tested-by: syzbot+62f0f99d2f2bb8e3bbd7@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Deepanshu Kartikey Fixes: 071cb4b81987 ("nilfs2: eliminate removal list of segments") Signed-off-by: Ryusuke Konishi Signed-off-by: Viacheslav Dubeyko Signed-off-by: Greg Kroah-Hartman commit f3461b84a4865d9b5e70fbb71da72ae044a3bcd2 Author: Tristan Madani Date: Tue May 5 11:12:59 2026 +0000 hfs/hfsplus: zero-initialize buffer in hfs_bnode_read commit d67aadee19ffdf3cc8520c5a4f4d5b2916d30baf upstream. hfs_bnode_read() can return early without writing to the output buffer when is_bnode_offset_valid() fails or when check_and_correct_requested_ length() corrects the length to zero. Callers such as hfs_bnode_read_ u16() and hfs_bnode_read_u8() pass stack-allocated buffers and use the result unconditionally, leading to KMSAN uninit-value reports. Rather than initializing at each individual call site, zero the buffer at the start of hfs_bnode_read() before any validation checks. This ensures all callers in both hfs and hfsplus get a deterministic zero value regardless of which early-return path is taken. Reported-by: syzbot+217eb327242d08197efb@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=217eb327242d08197efb Tested-by: syzbot+217eb327242d08197efb@syzkaller.appspotmail.com Fixes: a431930c9bac ("hfs: fix slab-out-of-bounds in hfs_bnode_read()") Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Reviewed-by: Viacheslav Dubeyko Signed-off-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/20260505111300.3592757-3-tristmd@gmail.com Signed-off-by: Viacheslav Dubeyko Signed-off-by: Greg Kroah-Hartman commit c63bc6308da716098833fe3185481cb9905dde79 Author: Srinivas Pandruvada Date: Wed Jun 10 16:29:09 2026 +0800 HID: sensor-hub: Add sensor_hub_input_attr_read_values() for multi-byte reads commit f784fcea450617055d2d12eec5b2f6e0e38bf878 upstream. sensor_hub_input_attr_get_raw_value() is limited to returning a single 32-bit value, which is insufficient for sensors that report data larger than 32 bits, such as a quaternion with four s16 elements. Add sensor_hub_input_attr_read_values() that accepts a caller-provided buffer and accumulates incoming data until the buffer is full. The two paths are distinguished in sensor_hub_raw_event() by pending.max_raw_size being non-zero, preserving backward compatibility. Signed-off-by: Srinivas Pandruvada Co-developed-by: Zhang Lixu Signed-off-by: Zhang Lixu Acked-by: Jiri Kosina Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 4d0d51bc12d246accbfbb94de05d729c68c9b8fb Author: Maoyi Xie Date: Thu Jun 18 15:06:35 2026 +0800 HID: lg-g15: cancel pending work on remove to fix a use-after-free commit 7705b4140d188ce22656f6e541ae7ef834c7e11a upstream. lg_g15_data is allocated with devm and holds a work item. The report handlers schedule that work straight from device input. lg_g15_event() and lg_g15_v2_event() do it on the backlight cycle key, and lg_g510_leds_event() does it too. The worker dereferences the lg_g15_data back through container_of. The driver had no remove callback and never cancelled the work. So if a report scheduled the work and the keyboard was then unplugged, devres freed lg_g15_data while the work was still pending or running, and the worker touched freed memory. This is a use-after-free. It is reachable as a race on device unplug. Add a remove callback that cancels the work before devres frees the state. g15->work is only initialized for the models that schedule it (G15, G15 v2, G510). The G13 and Z-10 leave it zeroed, so guard the cancel on g15->work.func to avoid cancelling a work that was never set up. The g15 NULL test mirrors the one already in lg_g15_raw_event(). Fixes: 97b741aba918 ("HID: lg-g15: Add keyboard and LCD backlight control") Cc: stable@vger.kernel.org Suggested-by: Hans de Goede Signed-off-by: Maoyi Xie Reviewed-by: Hans de Goede Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit b363d964ca829c1761c9f04188dfa28f90b0f2d4 Author: Manish Khadka Date: Fri May 15 23:17:52 2026 +0545 HID: appleir: fix UAF on pending key_up_timer in remove() commit 75fe87e19d8aff81eb2c64d15d244ab8da4de945 upstream. appleir_remove() runs hid_hw_stop() before timer_delete_sync(). hid_hw_stop() synchronously unregisters the HID input device via hid_disconnect() -> hidinput_disconnect() -> input_unregister_device(), which drops the last reference and frees the underlying input_dev when no userspace handle holds it open. key_up_tick() reads appleir->input_dev and calls input_report_key() / input_sync() on it. The timer is armed from appleir_raw_event() with a HZ/8 (~125 ms) timeout on every keydown and key-repeat report. If a key was pressed shortly before the device is disconnected, the timer can fire after hid_hw_stop() has freed input_dev but before the teardown drains it. A simple reorder is not sufficient. Putting the timer drain first still leaves a window where a USB URB completion (raw_event) running during hid_hw_stop() can call mod_timer() and re-arm the timer, which then fires after hidinput_disconnect() has freed input_dev. The same URB-completion window also lets raw_event() reach key_up(), key_down() and battery_flat() directly, all of which dereference appleir->input_dev. Introduce a 'removing' flag on struct appleir, gated by the existing spinlock. appleir_remove() sets the flag under the lock and then shuts down the timer with timer_shutdown_sync(), which both drains any in-flight callback and permanently disables further mod_timer() calls. appleir_raw_event() and key_up_tick() bail out early if the flag is set, so no path can arm or run the timer, or dereference appleir->input_dev, after remove() has started tearing down. The keyrepeat and flatbattery branches of appleir_raw_event() previously called into the input layer without holding the spinlock; take it now so the flag check is well-defined. This incidentally closes a pre-existing read-side race on appleir->current_key in the keyrepeat branch. This bug is structurally a sibling of commit 4db2af929279 ("HID: appletb-kbd: fix UAF in inactivity-timer cleanup path") and has been present since the driver was introduced. Fixes: 9a4a5574ce42 ("HID: appleir: add support for Apple ir devices") Cc: stable@vger.kernel.org Signed-off-by: Manish Khadka Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 37daa8c96bd563d03150e23f094cb60703594a6d Author: Trung Nguyen Date: Thu Jul 2 00:13:19 2026 +0700 HID: multitouch: fix out-of-bounds bit access on mt_io_flags commit 8813b0612275cc61fe9e6603d0ee019247ade6be upstream. mt_io_flags is a single unsigned long, but mt_process_slot(), mt_release_pending_palms() and mt_release_contacts() use it as a per-slot bitmap indexed by the slot number. That slot number is only bounded by td->maxcontacts, which is taken from the device's ContactCountMaximum feature report and can be up to 255, not by BITS_PER_LONG. As a result, a multitouch device that advertises a large contact count makes set_bit()/clear_bit() operate past the mt_io_flags word and corrupt the adjacent members of struct mt_device. The sticky-fingers release timer is the easiest way to reach this. mt_release_contacts() runs for (i = 0; i < mt->num_slots; i++) clear_bit(i, &td->mt_io_flags); with num_slots == maxcontacts. For maxcontacts around 250 the loop clears the bits that overlap td->applications.next, zeroing that list head, and the list_for_each_entry() that immediately follows then dereferences NULL. The kernel panics from timer (softirq) context. On a KASAN build this shows up as a general protection fault in mt_release_contacts() with a null-ptr-deref at offset 0x58, which is offsetof(struct mt_application, num_received). The state is reachable from an untrusted USB or Bluetooth HID multitouch device; no local privileges are required. Store the per-slot active state in a separately allocated bitmap sized for maxcontacts, the same pattern already used for pending_palm_slots, and keep only MT_IO_FLAGS_RUNNING in mt_io_flags. The two "mt_io_flags & MT_IO_SLOTS_MASK" arming checks become bitmap_empty(td->active_slots, td->maxcontacts). Move MT_IO_FLAGS_RUNNING back to bit 0. It was bumped to bit 32 by the same commit to leave the low byte for the slot bits; with the slot bits gone it fits in bit 0 again, which also keeps it within the unsigned long on 32-bit. Fixes: 46f781e0d151 ("HID: multitouch: fix sticky fingers") Cc: stable@vger.kernel.org Signed-off-by: Trung Nguyen Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 3eca1a8165b5e7996e699e9df76cb4645e184d42 Author: Manish Khadka Date: Fri May 15 22:27:00 2026 +0545 HID: letsketch: fix UAF on inrange_timer at driver unbind commit 46c8beeccd8ab2c863827254a85ea877654a3534 upstream. letsketch_driver does not provide a .remove callback, but letsketch_probe() arms a per-device timer: timer_setup(&data->inrange_timer, letsketch_inrange_timeout, 0); The timer is re-armed from letsketch_raw_event() with a 100 ms timeout on every pen-in-range report, and its callback dereferences data->input_tablet to deliver a synthetic BTN_TOOL_PEN release. letsketch_data is allocated with devm_kzalloc(), and its input_dev fields are devm-allocated via letsketch_setup_input_tablet(). On device unbind (USB unplug or rmmod), the HID core runs its default teardown and devm cleanup frees both letsketch_data and the input devices. Because no .remove callback exists, nothing drains the timer first: if raw_event armed it within ~100 ms of the unbind, the pending timer fires on freed memory. This is a UAF read of data and of data->input_tablet, followed by input_report_key() / input_sync() into the freed input_dev. The same problem can occur on the probe error path: if hid_hw_start() enabled I/O on an always-poll-quirk device and then failed, raw_event may have armed the timer before devm releases data. Fix by adding a .remove callback that calls hid_hw_stop() first. hid_hw_stop() synchronously kills the URBs that deliver raw_event(), so once it returns no path can re-arm the timer. timer_shutdown_sync() then drains any in-flight callback and permanently disables further mod_timer() calls. Apply the same timer_shutdown_sync() in the probe error path so the timer is guaranteed not to outlive data. Fixes: 33a5c2793451 ("HID: Add new Letsketch tablet driver") Cc: stable@vger.kernel.org Signed-off-by: Manish Khadka Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit bbe1e55629bfaabd4b2e8125b48dd3503d74ac8b Author: Jinmo Yang Date: Mon Jun 1 22:41:23 2026 +0900 HID: wacom: use GFP_ATOMIC in wacom_wac_queue_flush() commit 55f1ad573e34abf9a0443c34bc5a63d74edba7d7 upstream. wacom_wac_queue_flush() is called via the .raw_event callback (wacom_raw_event → wacom_wac_pen_serial_enforce → wacom_wac_queue_flush). For USB HID devices, this callback is invoked from hid_irq_in(), which is a URB completion handler running in atomic context. Using GFP_KERNEL in this path can sleep, leading to a "scheduling while atomic" bug. Use GFP_ATOMIC instead. The existing code already handles allocation failure by skipping the fifo entry and continuing. Reported-by: Sashiko-bot Fixes: 5e013ad20689 ("HID: wacom: Remove static WACOM_PKGLEN_MAX limit") Cc: stable@vger.kernel.org Reviewed-by: Dmitry Torokhov Signed-off-by: Jinmo Yang Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit ca899a926c11a59211b764b0155d9a1cdcc32b81 Author: Jinmo Yang Date: Fri May 29 02:59:45 2026 +0900 HID: wacom: fix slab-out-of-bounds write in wacom_wac_queue_insert commit 6b3014ec0e9a390ca563030b2d7689921f0daef5 upstream. wacom_wac_queue_insert() calls kfifo_skip() in a loop when the kfifo doesn't have enough space for the incoming report. If the kfifo is empty, kfifo_skip() reads stale data left in the kmalloc'd buffer via __kfifo_peek_n() and interprets it as a record length, advancing fifo->out by that garbage value. This corrupts the internal kfifo state, causing kfifo_unused() to return a value much larger than the actual buffer size, which bypasses __kfifo_in_r()'s guard: if (len + recsize > kfifo_unused(fifo)) return 0; kfifo_copy_in() then performs an out-of-bounds memcpy, writing up to 3842 bytes past the 256-byte buffer. Add a !kfifo_is_empty() condition to the while loop so kfifo_skip() is never called on an empty fifo, and check the return value of kfifo_in() to reject reports that are too large for the fifo. Suggested-by: Dmitry Torokhov Fixes: 5e013ad20689 ("HID: wacom: Remove static WACOM_PKGLEN_MAX limit") Cc: stable@vger.kernel.org Signed-off-by: Jinmo Yang Reviewed-by: Dmitry Torokhov Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit cb90a01e478c220c7fa710fd883377750d0e1d9c Author: Oleg Makarenko Date: Tue Jun 9 19:00:27 2026 +0300 HID: pidff: Use correct effect type in effect update commit b251598b8bf37300510868f739a79e07800d41ce upstream. When updating an existing effect, the effect type from the last created effect was sent to the device instead of the updated one. This caused incorrect reports when a game creates multiple different effects and updates only one that is not the last created. Fixes FFB in multiple games that create multiple simultaneous effects (Forza Horizon 5/6). Fixes: 224ee88fe395 ("Input: add force feedback driver for PID devices") Cc: stable@vger.kernel.org Tested-by: Oliver Roundtree Co-developed-by: Ryno Kotzé Signed-off-by: Ryno Kotzé Signed-off-by: Oleg Makarenko Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 416095e9a6037b4b39fcadd0d2bd77a8852211ec Author: Myeonghun Pak Date: Thu Jun 4 13:56:58 2026 +0900 HID: wacom: stop hardware after post-start probe failures commit ec2612b8ad9e642596db011dd8b6568ef1edeaa1 upstream. wacom_parse_and_register() starts HID hardware before registering inputs and initializing pad LEDs/remotes. Those later steps can fail, but their error paths currently release Wacom resources without stopping the HID hardware. Route post-hid_hw_start() failures through hid_hw_stop() before releasing driver resources. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: c1d6708bf0d3 ("HID: wacom: Do not register input devices until after hid_hw_start") Cc: stable@vger.kernel.org Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Dmitry Torokhov Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 7ce2c7dd28ab8586cfa494e166ddb397f153562b Author: Carlos Llamas Date: Sat Jun 6 18:15:52 2026 +0000 HID: uhid: convert to hid_safe_input_report() commit 63a694c51bf120a37550890b8e7736b4888985e9 upstream. Commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()"), added a check in hid_report_raw_event() to reject reports if the received data size is smaller than expected. This was intended to prevent OOB errors by no longer allowing zeroing-out of shorter reports due to the lack of buffer size information. However, this leads to regressions in hid_report_raw_event(), where shorter than expected reports are rejected, even though their buffers are sufficiently large to be zero-padded. To solve this issue, Benjamin introduced a safer alternative in commit 206342541fc8 ("HID: core: introduce hid_safe_input_report()"), which forwards the buffer size and allows hid_report_raw_event() to safely zero-pad the data. Convert uhid to use hid_safe_input_report() and pass UHID_DATA_MAX as the buffer size. This prevents the reported regressions [1], allowing hid core to zero-pad the shorter reports safely as expected. Cc: stable@vger.kernel.org Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()") Closes: https://lore.kernel.org/all/ahsh0UtTX6e0ZeHa@google.com/ [1] Signed-off-by: Carlos Llamas Reviewed-by: Lee Jones Closes: https://lore.kernel.org/all/ahsh0UtTX6e0ZeHa@google.com/ Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit dae1d000ddfd5c2140b036e47fff0c497ae9c64b Author: Tianchu Chen Date: Fri May 29 13:42:47 2026 +0000 HID: hid-goodix-spi: validate report size to prevent stack buffer overflow commit db0a0768d09273aadadeb76730cd658d720333a4 upstream. goodix_hid_set_raw_report() builds a protocol frame in a 128-byte stack buffer (tmp_buf), writing an 11-12 byte header followed by the caller-supplied report data. The HID core caps report size at HID_MAX_BUFFER_SIZE (16384) by default, while the driver does not set hid_ll_driver.max_buffer_size and performs no bounds checking before copying the payload: memcpy(tmp_buf + tx_len, buf, len); A hidraw SET_REPORT ioctl with a report larger than ~116 bytes overflows the stack buffer. Add a size check after constructing the header, rejecting reports that would exceed the buffer capacity. Discovered by Atuin - Automated Vulnerability Discovery Engine. Fixes: 75e16c8ce283 ("HID: hid-goodix: Add Goodix HID-over-SPI driver") Cc: stable@vger.kernel.org Signed-off-by: Tianchu Chen Reviewed-by: Dmitry Torokhov Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit abf07f5c3584f453e81b3d85a3b2712a4319d373 Author: Yichong Chen Date: Fri Jun 12 15:13:59 2026 +0800 tools/mm/slabinfo: fix total_objects attribute name commit 892a7864730775c3dbee2a39e9ead4fa8d4256e7 upstream. SLUB exports the total_objects sysfs attribute, but slabinfo tries to read objects_total. As a result, the lookup fails and the field remains zero. Use the correct attribute name and rename the corresponding structure member to match. Fixes: 205ab99dd103 ("slub: Update statistics handling for variable order slabs") Signed-off-by: Yichong Chen Cc: Reviewed-by: SeongJae Park Link: https://patch.msgid.link/96556748872BB47E+20260612071359.649946-1-chenyichong@uniontech.com Signed-off-by: Vlastimil Babka (SUSE) Signed-off-by: Greg Kroah-Hartman commit e0eec7497bcc7f61d70cb37c69d1382f76e2db74 Author: Xuewen Wang Date: Mon May 18 14:21:57 2026 +0800 tools/mm/slabinfo: Fix trace disable logic inversion commit 235ab68d67eadbef1fdbfb771f21f5bacc77a2ae upstream. The disable trace path in slab_debug() had a logic error where it would set trace=1 instead of trace=0. This made trace functionality permanently enabled once turned on for any slab cache. Fixes: a87615b8f9e2 ("SLUB: slabinfo upgrade") Cc: stable@vger.kernel.org Reviewed-by: SeongJae Park Signed-off-by: Xuewen Wang WARNING: From:/Signed-off-by: email address mismatch: 'From: wangxuewen <18810879172@163.com>' != 'Signed-off-by: wangxuewen ' Link: https://patch.msgid.link/20260518062159.80664-2-wangxuewen@kylinos.cn Signed-off-by: Vlastimil Babka (SUSE) Signed-off-by: Greg Kroah-Hartman commit 2382971aaaef5bf85a651234c64906f59580b8be Author: Vlastimil Babka (SUSE) Date: Wed Jun 10 17:40:03 2026 +0200 mm/slab: do not limit zeroing to orig_size when only red zoning is enabled commit 648927ceb84021a25a0fbd5673740956f318d534 upstream. When init (zeroing) on allocation is requested, for kmalloc() we generally have to zero the full object size even if a smaller size is requested, in order to provide krealloc()'s __GFP_ZERO guarantees. But if we track the requested size, krealloc() uses that information to do the right thing, so we can zero only the requested size. With red zoning also enabled, any extra size became part of the red zone, so it must not be zeroed and thus we must zero only the requested size. However the current check is imprecise, and will trigger also when only SLAB_RED_ZONE is enabled without SLAB_STORE_USER (which enables tracking the requested size). This means enabling red zoning alone can compromise krealloc()'s __GFP_ZERO contract. Fix this by using slub_debug_orig_size() instead, which is the exact check for whether the requested size is tracked. We don't need to care if red zoning is also enabled or not. Also update and expand the comment accordingly. Fixes: 9ce67395f5a0 ("mm/slub: only zero requested size of buffer for kzalloc when debug enabled") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260610-slab_alloc_flags-v2-1-7190909db118@kernel.org Reviewed-by: Harry Yoo (Oracle) Reviewed-by: Hao Li Signed-off-by: Vlastimil Babka (SUSE) Signed-off-by: Greg Kroah-Hartman commit 18d90dc05d98bd5579ee38dba37c1e4132e765db Author: Lukas Wunner Date: Thu May 14 08:55:58 2026 +0200 X.509: Fix validation of ASN.1 certificate header commit 3b626ba431c4501512ad07549310685e07fe4706 upstream. x509_load_certificate_list() seeks to enforce that a certificate starts with 0x30 0x82 (ASN.1 SEQUENCE tag followed by a length of more than 256 and less than 65535 bytes). But it only enforces that *either* of those two byte values are present, instead of checking for the *conjunction* of the two values. Fix it. Fixes: 631cc66eb9ea ("MODSIGN: Provide module signing public keys to the kernel") Reported-by: Sashiko Closes: https://lore.kernel.org/r/20260508033917.B5873C2BCB0@smtp.kernel.org/ Signed-off-by: Lukas Wunner Cc: stable@vger.kernel.org # v3.7+ Reviewed-by: Ignat Korchagin Reviewed-by: Alistair Francis Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 28390912740a2d23119ae7d3ec60ce69e11d1778 Author: Robin Murphy Date: Fri May 29 15:33:45 2026 +0100 perf/arm-cmn: Fix DVM node events commit 5936245125f78d896fdb1bbc2ae79213e28a6579 upstream. The new DVM node events added in CMN-700 also apply to CMN S3; fix the model encoding so that we can expose the aliases and handle occupancy filtering on newer CMNs too. Cc: stable@vger.kernel.org Fixes: 0dc2f4963f7e ("perf/arm-cmn: Support CMN S3") Signed-off-by: Robin Murphy Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit be79d285bea70d0edd5015bd487311bfa8cbebc9 Author: Heiko Carstens Date: Thu Jun 11 17:37:46 2026 +0200 s390: Revert support for DCACHE_WORD_ACCESS commit 37540b8c287fc817bdbd0c62bb75ad6eab0e5d03 upstream. load_unaligned_zeropad() reads eight bytes from unaligned addresses and may cross page boundaries. It handles exceptions which may happen if reading from the second page results in an exception. For pages which are donated to the Ultravisor for secure execution purposes the do_secure_storage_access() exception handler however does not handle such exceptions correctly. Such an exception may result in an endless exception loop which will never be resolved. An attempt to fix this [1] turned out to be not sufficient. For now revert load_unaligned_zeropad() until this problem has been resolved in a proper way. Note that the implementation of load_unaligned_zeropad() itself is correct. The revert is just a temporary workaround until there is complete fix for secure storage access exceptions. [1] commit b00be77302d7 ("s390/mm: Add missing secure storage access fixups for donated memory") Fixes: 802ba53eefc5 ("s390: add support for DCACHE_WORD_ACCESS") Cc: stable@vger.kernel.org Acked-by: Christian Borntraeger Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Greg Kroah-Hartman commit 2421a7b24f9c8f3c3677fd5dacc9ddcfb3554637 Author: Kartik Rajput Date: Thu May 7 21:15:54 2026 +0530 clocksource/drivers/timer-tegra186: Fix support for multiple watchdog instances commit ca57bf46e7a94f8c53d05c376df9fcfdcb482100 upstream. Tegra SoCs support multiple watchdogs; currently only one (WDT0) is used. When multiple watchdogs are registered, tegra186_wdt_enable() overwrites the TKEIE(x) register, discarding any existing watchdog interrupt enable bits. As a result, enabling one watchdog inadvertently disables interrupts for the others. Fix this by preserving the existing TKEIE(x) value and updating it using a read-modify-write sequence. Fixes: 42cee19a9f83 ("clocksource: Add Tegra186 timers support") Cc: stable@vger.kernel.org Signed-off-by: Kartik Rajput Signed-off-by: Daniel Lezcano Reviewed-by: Jon Hunter Link: https://patch.msgid.link/20260507154557.2082697-2-kkartik@nvidia.com Signed-off-by: Greg Kroah-Hartman commit cd25e9819620aa1325897912cfb4dd89303325fe Author: Thomas Gleixner Date: Tue Jun 9 17:14:45 2026 +0200 time/jiffies: Register jiffies clocksource before usage commit f24df84cbe05e4471c04ac4b921fc0340bbc7752 upstream. Teddy reported that a XEN HVM has a long boot delay, which was bisected to the recent enhancements to the negative motion detection. It turned out that the jiffies clocksource is used in early boot before it is registered, which leaves the max_delta_raw field at zero. That causes the read out to be clamped to the max delta of 0, which means time is not making progress. Cure it by ensuring that it is initialized before its first usage in timekeeping_init(). Fixes: 76031d9536a0 ("clocksource: Make negative motion detection more robust") Reported-by: Teddy Astie Signed-off-by: Thomas Gleixner Tested-by: Teddy Astie Cc: stable@vger.kernel.org Link: https://patch.msgid.link/87y0gn3fve.ffs@fw13 Closes: https://lore.kernel.org/all/1780914594.8631fc262581453bbf619ec5b2062170.19ea6c8227b000701b@vates.tech Signed-off-by: Greg Kroah-Hartman commit 7776f9226e99eb49d97492b0b445027cfcb189da Author: WenTao Liang Date: Fri Jun 12 00:17:38 2026 +0800 posix-cpu-timers: Fix pid refcount leak in do_cpu_nanosleep() error path commit 87bd2ad568e15b90d5f7d4bcd70342d05dad649c upstream. In do_cpu_nanosleep(), posix_cpu_timer_create() takes a pid reference via get_pid() and stores it in timer.it.cpu.pid. If the subsequent posix_cpu_timer_set() call fails, the function returns immediately without calling posix_cpu_timer_del() to release the pid reference, causing a leak. Fix it by calling posix_cpu_timer_del() before the unlock-and-return on the error path, consistent with the other exit paths in the same function. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: WenTao Liang Signed-off-by: Thomas Gleixner Reviewed-by: Frederic Weisbecker Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260611161738.97043-1-vulab@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit 6ba6f6783be2ffeb2cbcdc9321c4b9f708f796f7 Author: Yuho Choi Date: Thu Apr 16 10:46:21 2026 -0400 cpufreq: pcc: fix use-after-free and double free in _OSC evaluation commit 266d3dd8b757b48a576e90f018b51f7b7563cc32 upstream. pcc_cpufreq_do_osc() calls acpi_evaluate_object() twice for the two-phase _OSC negotiation. Between the two calls it freed output.pointer but left output.length unchanged. Since acpi_evaluate_object() treats a non-zero length with a non-NULL pointer as an existing buffer to write into, the second call wrote into freed memory (use-after-free). The subsequent kfree(output.pointer) at out_free then freed the same pointer a second time (double free). Reset output.pointer to NULL and output.length to ACPI_ALLOCATE_BUFFER after freeing the first result, so ACPICA allocates a fresh buffer for each phase independently. Fixes: 0f1d683fb35d ("[CPUFREQ] Processor Clocking Control interface driver") Signed-off-by: Yuho Choi Reviewed-by: Zhongqiu Han Cc: All applicable Link: https://patch.msgid.link/20260416144621.93964-1-dbgh9129@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 6e175c00c62dca3d91b987015808b5d52e8db2b4 Author: Tianxiang Chen Date: Wed Apr 8 22:19:14 2026 +0800 cpufreq: Fix hotplug-suspend race during reboot commit a9029dd55696c651ee46912afa2a166fa456bb3e upstream. During system reboot, cpufreq_suspend() is called via the kernel_restart() -> device_shutdown() path. Unlike the normal system suspend path, the reboot path does not call freeze_processes(), so userspace processes and kernel threads remain active. This allows CPU hotplug operations to run concurrently with cpufreq_suspend(). The original code has no synchronization with CPU hotplug, leading to a race condition where governor_data can be freed by the hotplug path while cpufreq_suspend() is still accessing it, resulting in a null pointer dereference: Unable to handle kernel NULL pointer dereference Call Trace: do_kernel_fault+0x28/0x3c cpufreq_suspend+0xdc/0x160 device_shutdown+0x18/0x200 kernel_restart+0x40/0x80 arm64_sys_reboot+0x1b0/0x200 Fix this by adding cpus_read_lock()/cpus_read_unlock() to cpufreq_suspend() to block CPU hotplug operations while suspend is in progress. Fixes: 65650b35133f ("cpufreq: Avoid cpufreq_suspend() deadlock on system shutdown") Signed-off-by: Tianxiang Chen Reviewed-by: Zhongqiu Han Cc: All applicable [ rjw: Changelog edits ] Link: https://patch.msgid.link/20260408141914.35281-1-nanmu@xiaomi.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 4bd0da48fbc1dbef6774175129107fbbdd353e26 Author: Steven Rostedt Date: Fri May 15 10:37:40 2026 -0400 sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT commit dd29c017aed628076e915fe4cdfb5392fd4c5cab upstream. RT migration is done aggressively. When a CPU schedules out a high priority RT task for a lower priority task, it will look to see if there's any RT tasks that are waiting to run on another CPU that is of higher priority than the task this CPU is about to run. If it finds one, it will pull that task over to the CPU and allow it to run there instead. Normally, this pulling is done by looking at the RT overloaded mask (rto) which contains all the CPUs in the scheduler domain with RT tasks that are waiting to run due to a higher priority RT task currently running on their CPU. The CPU that is about to schedule a lower priority task will grab the rq lock of the overloaded CPU and move the RT task from that CPU's runqueue to the local one and schedule the higher priority RT task. This caused issues when a lot of CPUs would schedule a lower priority task at the same time. They would all try to grab the same runqueue lock of the CPU with the overloaded RT tasks. Only the first CPU that got in will get that task. All the others would wait until they got the runqueue lock and see there's nothing to pull and do nothing. On systems with lots of CPUs, this caused a large latency (up to 500us) which is beyond what PREEMPT_RT is to allow. The solution to that was to create an RT_PUSH_IPI logic. When any CPU wanted to pull a task, instead of grabbing the runqueue lock of the overloaded CPU, it would start by sending an IPI to the overloaded CPU, and that IPI handler would have the CPU with the waiting RT task do a push instead. Then that handler would send an IPI to the next CPU with overloaded RT tasks, and so on. Note, after the first CPU starts this process, if another CPU wanted to do a pull, it would see that the process has already begun and would only increment a counter to have the IPIs continue again. The RT_PUSH_IPI solved the latency problem with PREEMPT_RT but could cause a new issue with non PREEMPT_RT. Namely, softirqs run in a threaded context on PREEMPT_RT but they can run in an interrupt context in non-RT. If an IPI lands on a CPU that has just woken up multiple RT tasks and the current CPU is running a non RT or a low priority RT task, instead of doing a push, it would simply do a schedule on that CPU. But if a softirq was also executing on this CPU, the schedule would need to wait until the softirq finished. Until then, the CPU would still be considered overloaded as there are RT tasks still waiting to run on it. A live lock occurred on a workload that was doing heavy networking traffic on a large machine where the softirqs would run 500us out of 750us. And it would also be waking up RT tasks, causing the RT pull logic to be constantly executed. When a softirq triggered on a CPU with RT tasks queued but not running yet, and the other CPUs would see this CPU as being overloaded, they would send an IPI over to it. The CPU would notice that the waiting RT tasks are of higher priority than the currently running task and simply schedule that CPU instead. But because the softirq was executing, before it could schedule, it would receive another IPI to do the same. The amount of IPIs would slow down the currently running softirq so much that before it could return back to task context, it would execute another softirq never allowing the CPU to schedule. This live locked that CPU. As RT_PUSH_IPI was created to help PREEMPT_RT, make it default off if PREEMPT_RT is not enabled. Fixes: b6366f048e0c ("sched/rt: Use IPI to trigger RT task push migration instead of pulling") Closes: https://lore.kernel.org/all/20260506235716.2530720-1-tj@kernel.org/ Reported-by: Tejun Heo Signed-off-by: Steven Rostedt Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260515103740.25ccbed8@gandalf.local.home Signed-off-by: Greg Kroah-Hartman commit f77e55baeeb8c8bd63f8a6e3f4f9674d1c4a4e54 Author: Fushuai Wang Date: Wed May 20 11:21:19 2026 +0800 cpufreq: intel_pstate: Sync policy->cur during CPU offline commit bcbdaa1086c25a8a5d48e04e1b82fdfb0682b681 upstream. When a CPU goes offline with HWP disabled, intel_pstate_set_min_pstate() sets the MSR_IA32_PERF_CTL to minimum frequency to prevent SMT siblings from being restricted. However, the policy->cur value was not updated, leaving it at the previous value. When the CPU comes back online, governor->limits() checks if target_freq equals policy->cur and skips the frequency adjustment if they match. Since policy->cur still holds the previous value, the governor does not call cpufreq_driver->target to update MSR_IA32_PERF_CTL. Fix this by synchronizing policy->cur with the hardware state when setting minimum pstate during CPU offline. Fixes: bb18008f8086 ("intel_pstate: Set core to min P state during core offline") Cc: stable@vger.kernel.org # 3.15+ Suggested-by: Srinivas Pandruvada Signed-off-by: Fushuai Wang [ rjw: Subject refinement ] Link: https://patch.msgid.link/20260520032119.30615-1-fushuai.wang@linux.dev Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 59626d0d29217a5a0b89609725e7bc3453f6b802 Author: Zide Chen Date: Tue Jun 2 07:49:05 2026 -0700 perf/x86/intel/uncore: Defer ADL global PMON enable to enable_box() commit 9a0bb848a37150aeccc10088e141339917d995dc upstream. On some Raptor Cove CPUs, enabling uncore PMON globally at driver init may increase power consumption even when no perf events are in use. Drop adl_uncore_msr_init_box() and defer programming the global control register to enable_box(), so it is only set when a box is actually used. IMC and IMC freerunning counters use a separate control path and are unaffected. Fixes: 772ed05f3c5c ("perf/x86/intel/uncore: Add Alder Lake support") Signed-off-by: Zide Chen Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dapeng Mi Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260602144908.263680-5-zide.chen@intel.com Signed-off-by: Greg Kroah-Hartman commit b9d45d328fcda4f0d3d281b7d6f12d3f181d9381 Author: John Hubbard Date: Wed Jun 3 19:53:14 2026 -0700 libfs: set SB_I_NOEXEC and SB_I_NODEV by default in init_pseudo() commit 6de2aeffabaafaeda819e60ec8d04f199711e11a upstream. Since commit 1e7ab6f67824 ("anon_inode: rework assertions"), path_noexec() warns when an anonymous-inode file is mmap'd from a superblock that has not set SB_I_NOEXEC. dma-buf backs its files this way and never set the flag, so mmap of any exported buffer trips the warning on a CONFIG_DEBUG_VFS=y kernel: WARNING: CPU: 11 PID: 121813 at fs/exec.c:118 path_noexec+0x47/0x50 do_mmap+0x2b5/0x680 vm_mmap_pgoff+0x129/0x210 ksys_mmap_pgoff+0x177/0x240 __x64_sys_mmap+0x33/0x70 init_pseudo() sets up internal SB_NOUSER mounts that are never path-reachable. Set both flags here so every pseudo filesystem gets them by default instead of each caller setting them. SB_I_NODEV is inert for unreachable mounts. SB_I_NOEXEC has one visible effect: an executable mapping of a pseudo-fs fd, such as a dma-buf, now fails with -EPERM, which is the invariant the assertion enforces. No in-tree caller maps these executable. Reproduce on CONFIG_DEBUG_VFS=y: make -C tools/testing/selftests/dmabuf-heaps sudo ./tools/testing/selftests/dmabuf-heaps/dmabuf-heap -t system Fixes: 1e7ab6f67824 ("anon_inode: rework assertions") Suggested-by: Christoph Hellwig Cc: stable@vger.kernel.org Signed-off-by: John Hubbard Link: https://patch.msgid.link/20260604025315.245910-2-jhubbard@nvidia.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 92f41769e5fd16bcd9ba97500d0517332e0a5b45 Author: Guangshuo Li Date: Tue May 5 17:12:31 2026 +0800 firmware_loader: fix device reference leak in firmware_upload_register() commit 896df22ee57648b0c505bd76ddbc6b2341834696 upstream. firmware_upload_register() -> fw_create_instance() -> device_initialize() After fw_create_instance() succeeds, the lifetime of the embedded struct device is expected to be managed through the device core reference counting, since fw_create_instance() has already called device_initialize(). In firmware_upload_register(), if alloc_lookup_fw_priv() fails after fw_create_instance() succeeds, the code reaches free_fw_sysfs and frees fw_sysfs directly instead of releasing the device reference with put_device(). This may leave the reference count of the embedded struct device unbalanced, resulting in a refcount leak. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fix this by using put_device(fw_dev) in the failure path and letting fw_dev_release() handle the final cleanup, instead of freeing the instance directly from the error path. Fixes: 97730bbb242c ("firmware_loader: Add firmware-upload support") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260505091231.607089-1-lgs201920130244@gmail.com Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit e904961332801c87355f5d11c65bb433e717c489 Author: Guangshuo Li Date: Sat May 2 03:00:05 2026 +0800 cpufreq: qcom-cpufreq-hw: Fix possible double free commit bcb8889c4981fdde42d4fd2c29a77d510fe21da2 upstream. qcom_cpufreq.data is allocated with devm_kzalloc() in probe() as an array of per-domain data. qcom_cpufreq_hw_cpu_init() stores a pointer to one element of this array in policy->driver_data. qcom_cpufreq_hw_cpu_exit() currently calls kfree() on policy->driver_data. This is not valid because the memory is devm-managed. For the first domain, this can free the devm-managed allocation while the devres entry is still active, leading to a possible double free when the platform device is later detached. For other domains, the pointer may refer to an element inside the array rather than the allocation base. Remove the kfree(data) call and let devres release qcom_cpufreq.data. This issue was found by a static analysis tool I am developing. Fixes: 054a3ef683a1 ("cpufreq: qcom-hw: Allocate qcom_cpufreq_data during probe") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Zhongqiu Han Signed-off-by: Viresh Kumar Signed-off-by: Greg Kroah-Hartman commit a277489337c7d4630a277f125fd824d9a90b2500 Author: Abdun Nihaal Date: Mon May 11 12:12:11 2026 +0530 OPP: of: Fix potential memory leak in opp_parse_supplies() commit 69f888381d2ecbe18ed9f112c096f8fd3623db98 upstream. The memory allocated for microvolt, microamp and microwatt is not freed in one of the paths in opp_parse_supplies() which returns directly. Fix that by adding a goto to the error unwind ladder. Fixes: 2eedf62e66c2 ("OPP: decouple dt properties in opp_parse_supplies()") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Signed-off-by: Viresh Kumar Signed-off-by: Greg Kroah-Hartman commit 685fc15a410885b6d4dee64de0dce721b9428b12 Author: Baokun Li Date: Thu May 21 17:50:14 2026 +0800 writeback: fix race between cgroup_writeback_umount() and inode_switch_wbs() commit cba38ec4cbd3a7b8b942a8d52531a05be8a9ff0d upstream. When a container exits, the following BUG_ON() is occasionally triggered: ================================================================== VFS: Busy inodes after unmount of sdb (ext4) ------------[ cut here ]------------ kernel BUG at fs/super.c:695! CPU: 3 PID: 6 Comm: containerd-shim Tainted: G OE K 6.6 #1 pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : generic_shutdown_super+0xf0/0x100 lr : generic_shutdown_super+0xf0/0x100 Call trace: generic_shutdown_super+0xf0/0x100 kill_block_super+0x20/0x48 ext4_kill_sb+0x28/0x60 deactivate_locked_super+0x54/0x130 deactivate_super+0x84/0xa0 cleanup_mnt+0xa4/0x140 __cleanup_mnt+0x18/0x28 task_work_run+0x78/0xe0 do_notify_resume+0x204/0x240 ================================================================== The root cause is a race between cgroup_writeback_umount() and inode_switch_wbs()/cleanup_offline_cgwb(). There is a window between inode_prepare_wbs_switch() returning true and the subsequent wb_queue_isw() call. Following is the process that triggers the issue: CPU A (umount) | CPU B (writeback) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ inode_switch_wbs/cleanup_offline_cgwb atomic_inc(&isw_nr_in_flight) inode_prepare_wbs_switch -> passes SB_ACTIVE check __iget(inode) generic_shutdown_super sb->s_flags &= ~SB_ACTIVE cgroup_writeback_umount(sb) smp_mb() atomic_read(&isw_nr_in_flight) rcu_barrier() -> no pending RCU callbacks flush_workqueue(isw_wq) -> nothing queued, returns evict_inodes(sb) -> Inode skipped as isw still holds a ref. sop->put_super(sb) /* destroys percpu counters */ -> VFS: Busy inodes after unmount! wb_queue_isw() queue_work(isw_wq, ...) /* later in work function */ inode_switch_wbs_work_fn process_inode_switch_wbs iput() -> evict percpu_counter_dec() // UAF! Fix this by extending the RCU read-side critical section in inode_switch_wbs() and cleanup_offline_cgwb() to cover from inode_prepare_wbs_switch() through wb_queue_isw(). Since there is no sleep in this window, rcu_read_lock() can be used. Then add a synchronize_rcu() in cgroup_writeback_umount() before the existing rcu_barrier(), so that all in-flight switchers that have passed the SB_ACTIVE check have completed queue_work() before flush_workqueue() is called. The existing rcu_barrier() is intentionally retained so this fix can be backported unchanged to stable kernels (5.10.y, 6.6.y, ...) that still queue switches via queue_rcu_work(). It is a no-op on current mainline (since commit e1b849cfa6b6 ("writeback: Avoid contention on wb->list_lock when switching inodes")) and is removed in a follow-up patch. Fixes: a1a0e23e4903 ("writeback: flush inode cgroup wb switches instead of pinning super_block") Cc: stable@vger.kernel.org Suggested-by: Jan Kara Link: https://lore.kernel.org/all/mxnjq2l6guusfchvauxr3v7c4bwjasybxlleqbbh4efloeqspz@iqylk76ohufz Reviewed-by: Jan Kara Signed-off-by: Baokun Li Link: https://patch.msgid.link/20260521095016.2791354-2-libaokun@linux.alibaba.com Acked-by: Tejun Heo Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit c6c484a7d5bff6b929a86d7ed5130f29834c6a0d Author: Norbert Manthey Date: Thu Jul 9 15:54:39 2026 +0000 smb: client: mask server-provided mode to 07777 in modefromsid commit e3d9c7160d483fc8f9e225aafad8ecbbc43f3151 upstream. When modefromsid is active, parse_dacl() applies the server-provided sub_auth[2] value from the NFS mode SID to cf_mode without masking to 07777. Apply the correct masking, same as in the read path. Fixes: e2f8fbfb8d09c ("cifs: get mode bits from special sid on stat") Signed-off-by: Norbert Manthey Assisted-by: Kiro:claude-opus-4.6 Cc: stable@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 157c67a657a7da1a31ab22c1fd0b2d9e5968ebd5 Author: Xu Rao Date: Tue Jul 7 21:30:17 2026 +0800 smb: client: fix atime clamp check in read completion commit 0b043279e73880bee21d3b1f221bafda5af1b27e upstream. cifs_rreq_done() updates the inode atime to current_time(inode) after a netfs read. It then preserves the CIFS rule that atime should not be older than mtime, because some applications break if atime is less than mtime. That rule only requires clamping when atime < mtime. The current check uses the raw non-zero result of timespec64_compare(). It therefore takes the clamp path for both atime < mtime and atime > mtime. The latter is the normal case when reading an older file: the newly recorded atime is newer than the file mtime. The completion handler then immediately moves atime back to mtime, losing the access time that was just recorded. Userspace tools that rely on atime, such as stat, find -atime, backup tools or cold-data classifiers, can therefore see a recently read CIFS file as not recently accessed. This is easy to miss because the bug is silent: read I/O still succeeds, no error is reported, and many systems either do not check atime after reads or mount with policies such as relatime/noatime. It becomes visible when a CIFS file has an mtime older than the current time, the file is read, and the local inode atime is inspected before a later revalidation replaces the cached timestamps. Clamp only when atime is actually older than mtime. This matches the same atime/mtime rule used when applying CIFS inode attributes. Fixes: 69c3c023af25 ("cifs: Implement netfslib hooks") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 86c5d470f5d42e61123b2f4b4f0b91f4eee5b980 Author: Zihan Xi Date: Sun Jun 28 17:19:24 2026 +0800 smb: client: harden POSIX SID length parsing commit 7ad2bcf2441430bb2e918fb3ef9a90d775a6e422 upstream. posix_info_sid_size() reads sid[1] to obtain the subauthority count, but its existing boundary check still accepts buffers with only one remaining byte. Require two bytes before reading sid[1] so all client paths that reuse the helper reject truncated POSIX SIDs safely. Fixes: 349e13ad30b4 ("cifs: add smb2 POSIX info level") 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: Zihan Xi Signed-off-by: Ren Wei Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 3d89ae65ef78a7958ff5efab6ad7a46eb4b38333 Author: Zihan Xi Date: Wed Jul 1 18:23:21 2026 +0800 smb: client: use unaligned reads in parse_posix_ctxt() commit b86467cd2691192ad4809a5a6e922fc24b8e9839 upstream. The server controls create-context DataOffset, so the POSIX context data pointer may be misaligned on strict-alignment architectures. Use get_unaligned_le32() when reading nlink, reparse_tag, and mode. Fixes: 69dda3059e7a ("cifs: add SMB2_open() arg to return POSIX data") Cc: stable@vger.kernel.org Signed-off-by: Zihan Xi Signed-off-by: Ren Wei Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 297243e365fc9fe2f8e9b7dd535a65d922cd108b Author: Haoxiang Li Date: Tue Jun 23 09:45:38 2026 +0800 smb: client: Fix next buffer leak in receive_encrypted_standard() commit 1c6267a1d5cf4c73b656f8181b310cbbb3e4767b upstream. receive_encrypted_standard() allocates next_buffer before checking whether the number of compound PDUs already reached MAX_COMPOUND. If the limit check fails, the function returns immediately and the newly allocated next_buffer is not assigned to server->smallbuf/server->bigbuf, making it leaked. Move the MAX_COMPOUND check before allocating next_buffer. Fixes: b24df3e30cbf ("cifs: update receive_encrypted_standard to handle compounded responses") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit d15d83125007f673aec4323e1bbbaaffbe87ea13 Author: Henrique Carvalho Date: Thu Jun 18 17:34:35 2026 -0300 smb: client: fix double-free in SMB2_close() replay commit f96e1cdcb63ed3321142ff2fcdf784e32cda8fee upstream. A response-bearing attempt can return a replayable error and free its response buffer. If SMB2_close_init() fails before the next send, cleanup retains the previous buffer type and frees that response again. Reset response bookkeeping before each attempt to prevent the stale free. Fixes: 4f1fffa23769 ("cifs: commands that are retried should have replay flag set") Cc: stable@vger.kernel.org Signed-off-by: Henrique Carvalho Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 14498ff5ce0f272ce0ef988721413e06b7038972 Author: Henrique Carvalho Date: Thu Jun 18 17:34:33 2026 -0300 smb: client: fix double-free in SMB2_open() replay commit b55e182f2324bc6a604c21a47aa6c448f719a532 upstream. A response-bearing attempt can return a replayable error and free its response buffer. If SMB2_open_init() fails before the next send, cleanup retains the previous buffer type and frees that response again. Reset response bookkeeping before each attempt to prevent the stale free. Fixes: 4f1fffa23769 ("cifs: commands that are retried should have replay flag set") Cc: stable@vger.kernel.org Signed-off-by: Henrique Carvalho Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 3407240cde132a4b72d6429a2625a09a2f78adaf Author: Zhao Zhang Date: Thu Jun 18 23:28:05 2026 +0800 smb: client: fix double-free in SMB2_flush() replay commit 4be31c943a3a27a5a0251dbb8f5cb89059ec3d5a upstream. SMB2_flush() keeps its response buffer bookkeeping across replay attempts. If a replayable flush response is received and the retry then fails before cifs_send_recv() stores a replacement response, flush_exit will free the stale response pointer a second time. Reinitialize resp_buftype and rsp_iov at the top of the replay loop so cleanup only acts on response state produced by the current attempt. This fixes a double-free without changing replay handling for successful requests. Fixes: 4f1fffa23769 ("cifs: commands that are retried should have replay flag set") Cc: stable@vger.kernel.org Reported-by: Yuan Tan Reported-by: Zhengchuan Liang Reported-by: Xin Liu Assisted-by: Codex:GPT-5.4 Acked-by: Henrique Carvalho Signed-off-by: Zhao Zhang Signed-off-by: Ren Wei Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 52af1975f0dfae990c5a0e85872cc41be0e88a68 Author: Henrique Carvalho Date: Thu Jun 18 17:34:37 2026 -0300 smb: client: fix change notify replay double-free commit 145f820dcbb2cced374f2532f8a61a44dce4a615 upstream. A response-bearing attempt can return a replayable error and free its response buffer. If SMB2_notify_init() fails before the next send, cleanup retains the previous buffer type and frees that response again. Reset response bookkeeping before each attempt to prevent the stale free. Fixes: 4f1fffa23769 ("cifs: commands that are retried should have replay flag set") Cc: stable@vger.kernel.org Signed-off-by: Henrique Carvalho Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 276c8efbc49f9303ac76d0d4deab7128581b0f3b Author: Henrique Carvalho Date: Thu Jun 18 17:34:34 2026 -0300 smb: client: fix double-free in SMB2_ioctl() replay commit f9bbadb6c94583e3b4af1afc449bfceb1d1ddec9 upstream. A response-bearing attempt can return a replayable error and free its response buffer. If SMB2_ioctl_init() fails before the next send, cleanup retains the previous buffer type and frees that response again. Reset response bookkeeping before each attempt to prevent the stale free. Fixes: 4f1fffa23769 ("cifs: commands that are retried should have replay flag set") Cc: stable@vger.kernel.org Signed-off-by: Henrique Carvalho Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit f1add4acb656f5a82806a1ab0e63fed3d8b1bfca Author: Henrique Carvalho Date: Thu Jun 18 17:34:36 2026 -0300 smb: client: fix query_info() replay double-free commit 2a88561d66eb855813cf004a0abe648bbb17de5e upstream. A response-bearing attempt can return a replayable error and free its response buffer. If SMB2_query_info_init() fails before the next send, cleanup retains the previous buffer type and frees that response again. Reset response bookkeeping before each attempt to prevent the stale free. Fixes: 4f1fffa23769 ("cifs: commands that are retried should have replay flag set") Cc: stable@vger.kernel.org Signed-off-by: Henrique Carvalho Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 00b0fa425941438b664950a8ee65dfba2def4336 Author: Henrique Carvalho Date: Thu Jun 18 17:34:38 2026 -0300 smb: client: fix query directory replay double-free commit 9647492b5e41954be59d5157eddbcd4cdc1656f7 upstream. A response-bearing attempt can return a replayable error and free its response buffer. If SMB2_query_directory_init() fails before the next send, cleanup retains the previous buffer type and frees that response again. Reset response bookkeeping before each attempt to prevent the stale free. Fixes: 4f1fffa23769 ("cifs: commands that are retried should have replay flag set") Cc: stable@vger.kernel.org Signed-off-by: Henrique Carvalho Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 2b4592cea214683de0f2ce6f8c22c097fb0ea1ab Author: Namjae Jeon Date: Sat Jun 13 22:00:03 2026 +0900 ksmbd: use opener credentials for ADS I/O commit baa5e094886fffa7e6272edcb5e08be5ce28262c upstream. Alternate data streams are stored as xattrs. Unlike regular file I/O, their read and write paths therefore call VFS xattr helpers which recheck inode permissions and LSM policy using the current task credentials. Run ADS I/O with the credentials captured when the SMB handle was opened. Cc: stable@vger.kernel.org Reported-by: Musaab Khan Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit e72c15085b6d86f45d224d98aa75b5cace4aaab9 Author: Namjae Jeon Date: Sat Jun 13 22:00:00 2026 +0900 ksmbd: use opener credentials for delete-on-close commit 52e2f21911158ec961cd5aae19c56460db382af0 upstream. Delete-on-close can be completed by deferred or durable handle teardown, where no request work is available. Both the base-file unlink and the ADS xattr removal consequently run with the ksmbd worker credentials and can bypass filesystem permission checks. Run both operations with the credentials captured in struct file when the handle was opened. This preserves the authenticated user's fsuid, fsgid, supplementary groups and capability restrictions at final close. Cc: stable@vger.kernel.org Reported-by: Musaab Khan Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit df501c0f320b5e2446712f339e2729f750906ee7 Author: Gil Portnoy Date: Wed Jun 10 20:13:51 2026 +0900 ksmbd: add per-handle permission check to FILE_LINK_INFORMATION commit 13f3942f2bf45856bb751faed2f0c4618f41ca20 upstream. The FILE_LINK_INFORMATION arm of smb2_set_info_file() calls smb2_create_link() with no per-handle fp->daccess check. On the ReplaceIfExists path smb2_create_link() unlinks an existing file at the target name (ksmbd_vfs_remove_file) and creates a hardlink (ksmbd_vfs_link); neither helper checks daccess. A handle opened with FILE_READ_DATA only (no FILE_DELETE, no FILE_WRITE_DATA) can therefore delete an arbitrary file in the share and plant a hardlink over its name. The sibling delete/move arms in the same switch already gate: FILE_RENAME_INFORMATION and FILE_DISPOSITION_INFORMATION both require FILE_DELETE_LE; FILE_FULL_EA_INFORMATION requires FILE_WRITE_EA_LE. Gate the link arm the same way as its closest analogue (rename), since it mutates the namespace and, on replace, deletes an existing entry. This is a sibling of commit cc57232cae23 ("ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE"). Cc: stable@vger.kernel.org Signed-off-by: Gil Portnoy Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 2ca82bfff49c84709d8736fb5040e00867bf3028 Author: Gil Portnoy Date: Thu Jun 11 22:59:51 2026 +0900 ksmbd: enforce FILE_READ_ATTRIBUTES on SMB_FIND_FILE_POSIX_INFORMATION commit 20c8442dc1003f9f7bb522d3dcd81d09ea59a79e upstream. find_file_posix_info() in smb2_query_info() returns file metadata (owner uid, group gid, mode, inode, size, allocation size, hard-link count and all four timestamps) but performs no per-handle access check. Every sibling query handler gates on the handle's granted access first -- get_file_basic_info(), get_file_all_info(), get_file_network_open_info() and get_file_attribute_tag_info() all reject a handle lacking FILE_READ_ATTRIBUTES_LE with -EACCES. The POSIX handler is gated only by the connection-scoped tcon->posix_extensions flag, which is not a per-handle authorization, so a handle opened with only FILE_WRITE_DATA is correctly denied FileBasicInformation yet is allowed the strict-superset POSIX info. Mirror the FILE_READ_ATTRIBUTES_LE gate the sibling info handlers already use. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Signed-off-by: Gil Portnoy Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 20ee516a62989a8d505ee432f9e59525ea23984e Author: Namjae Jeon Date: Sat Jun 13 22:00:01 2026 +0900 ksmbd: run set info with opener credentials commit b383bcad3d2fe634b26efbce53e22bbb5753a520 upstream. SMB2 SET_INFO handlers call path-based VFS helpers after checking the access mask granted to the SMB handle. Those helpers perform their owner, inode permission and LSM checks using the current ksmbd worker credentials. Run the complete SET_INFO dispatch with the credentials captured when the handle was opened. This also removes the separate security information credential setup and keeps all SET_INFO classes under one credential scope. Direct override_creds() is used because it can nest with the request credential overrides already used by rename and link helpers. Cc: stable@vger.kernel.org Reported-by: Musaab Khan Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit f56535db508ead8dec1c481ad93d7d8acd8f8f1e Author: Gil Portnoy Date: Tue Jun 9 00:00:00 2026 +0000 ksmbd: add a WRITE_DAC/WRITE_OWNER check to SMB2 SET_INFO SECURITY commit 44df157a1183a7f746caa970c169255da5ac61f8 upstream. commit cc57232cae23 ("ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE") added a fp->daccess gate to fsctl_set_sparse and noted that "similar handle-level checks exist in other functions but are missing here." The SMB2 SET_INFO SECURITY arm is one of the missing ones, and the most security-relevant: smb2_set_info_sec() calls set_info_sec() with no per-handle access check. set_info_sec() (fs/smb/server/smbacl.c) re-permissions the file: it rewrites owner/group/mode via notify_change(), rewrites the POSIX ACL via set_posix_acl(), and on KSMBD_SHARE_FLAG_ACL_XATTR shares removes and rewrites the Windows security descriptor via ksmbd_vfs_set_sd_xattr(). Every other persistent-mutation arm of the sibling handler smb2_set_info_file() checks fp->daccess first (FILE_WRITE_DATA / FILE_DELETE / FILE_WRITE_EA / FILE_WRITE_ATTRIBUTES); the SECURITY arm — which mutates the access control itself — is the only one with no gate. A client can therefore open a handle with FILE_WRITE_ATTRIBUTES only (no FILE_WRITE_DAC / FILE_WRITE_OWNER) and use SMB2_SET_INFO with InfoType SMB2_O_INFO_SECURITY to rewrite the file's DACL and owner, granting itself access the handle's daccess never carried. Unlike the FSCTL data arms this is a metadata/xattr operation, so there is no FMODE_WRITE VFS backstop — the missing fp->daccess check is the entire gate. Setting a security descriptor is the WRITE_DAC / WRITE_OWNER operation, so require at least one of those on the handle before re-permissioning the file. -EACCES is mapped to STATUS_ACCESS_DENIED by smb2_set_info(). Cc: stable@vger.kernel.org Signed-off-by: Gil Portnoy Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit db231af842868268839f9f9619c68cb27830d8be Author: Namjae Jeon Date: Sat Jun 13 22:00:02 2026 +0900 ksmbd: require source read access for duplicate extents commit cedff600f1642aa982178503552f0d007bc829c8 upstream. FSCTL_DUPLICATE_EXTENTS_TO_FILE passes the source file directly to vfs_clone_file_range() or vfs_copy_file_range() without checking the SMB access mask granted to the source handle. A handle opened with attribute access can consequently be used to copy file contents into an attacker-readable destination. Require FILE_READ_DATA on the source handle before either VFS operation, matching other ksmbd data-copy paths. Cc: stable@vger.kernel.org Reported-by: Musaab Khan Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 5aa1cb01155f96824003baf7997cdf1f150caba3 Author: Davide Ornaghi Date: Sat Jun 6 16:11:04 2026 +0900 ksmbd: fix UAF of struct file_lock in SMB2_LOCK deferred-lock cancellation commit d20d1c8ba5765d1d12eefc0aee6385ab3f240e1e upstream. When a blocking byte-range lock request is deferred in the FILE_LOCK_DEFERRED path, ksmbd registers the asynchronous work into the connection's async_requests list via setup_async_work(). The cancel callback smb2_remove_blocked_lock() holds a reference to the flock. If the lock waiter is subsequently woken up but the work state is no longer KSMBD_WORK_ACTIVE (e.g., due to a concurrent cancellation), the cleanup path calls locks_free_lock(flock) without dequeuing the work from the async_requests list. Concurrently, smb2_cancel() walks the list under conn->request_lock and invokes the cancel callback, which then dereferences the already freed 'flock'. This leads to a slab-use-after-free inside __wake_up_common. Fix this by restructuring the cleanup logic after the worker returns from ksmbd_vfs_posix_lock_wait(). Move list_del(&smb_lock->llist) and release_async_work(work) to the top of the cleanup block. This guarantees that the async work is completely dequeued and serialized under conn->request_lock before locks_free_lock(flock) is called, rendering the flock unreachable for any concurrent smb2_cancel(). Cc: stable@vger.kernel.org Signed-off-by: Davide Ornaghi Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit a1d5d31cad593ea5e1b637f2f39c9ef6d09d1199 Author: Namjae Jeon Date: Fri Jun 12 08:00:00 2026 +0900 ksmbd: serialize QUERY_DIRECTORY requests per file commit be6d26bf27499977c746abc163659915082348d8 upstream. smb2_query_dir() stores a pointer to its stack-allocated private data in the ksmbd_file readdir_data. Concurrent QUERY_DIRECTORY requests using the same file handle can overwrite this pointer while an iterate_dir() callback is still using it, resulting in a stack use-after-free. Add a per-file mutex and hold it while accessing the shared directory enumeration state. The lock covers scan restart, dot entry state, readdir_data setup and iteration, and response construction. This prevents another request from replacing readdir_data.private before the current request has finished using it and also serializes the shared file position. Cc: stable@vger.kernel.org Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-30527 Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 57f2042fd87d7ce8fc3ac8b6c176e554df68b1a7 Author: Gil Portnoy Date: Wed Jun 10 20:07:04 2026 +0900 ksmbd: add a permission check for FSCTL_SET_ZERO_DATA commit 3320ba068198adc144c89d6661b805acce01735b upstream. FSCTL_SET_ZERO_DATA in smb2_ioctl() destroys file data via ksmbd_vfs_zero_data() -> vfs_fallocate(PUNCH_HOLE/ZERO_RANGE) after checking only the share-level KSMBD_TREE_CONN_FLAG_WRITABLE, with no per-handle access check. A handle opened with only FILE_WRITE_ATTRIBUTES still yields an FMODE_WRITE filp (FILE_WRITE_ATTRIBUTES is part of FILE_WRITE_DESIRE_ACCESS_LE, so smb2_create_open_flags() opens it O_WRONLY), so the vfs_fallocate FMODE_WRITE check does not stop it; only the missing fp->daccess gate would. Reproduced on mainline 7.1-rc7 with KASAN by an authenticated SMB client: a FILE_WRITE_ATTRIBUTES-only handle zeroed 4096 bytes of file data it had no FILE_WRITE_DATA right to (6/6; a FILE_READ_DATA-only handle was correctly denied). This is the unfixed sibling of commit cc57232cae23 ("ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE"). Because SET_ZERO_DATA writes data (not an attribute), require FILE_WRITE_DATA. Cc: stable@vger.kernel.org Signed-off-by: Gil Portnoy Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit baae7b39673ec21073a25e3d14f8feaada01d5df Author: Gil Portnoy Date: Fri Jun 12 07:15:38 2026 +0900 ksmbd: add permission checks for FSCTL_DUPLICATE_EXTENTS_TO_FILE commit 388e4139db27a9e3612c9d356b826f5b1ff6a9e3 upstream. The FSCTL_DUPLICATE_EXTENTS_TO_FILE arm of smb2_ioctl() overwrites the destination file's data via vfs_clone_file_range() with neither the share-level KSMBD_TREE_CONN_FLAG_WRITABLE check nor a per-handle fp->daccess check that the other write-bearing arms carry. A client can overwrite destination data on a read-only share, or from a handle opened with only FILE_WRITE_ATTRIBUTES (which still yields an FMODE_WRITE filp). FILE_WRITE_ATTRIBUTES-only destination handle overwrote the file's data via the clone. Add both checks, matching the FSCTL_SET_SPARSE permission fix; require FILE_WRITE_DATA since this writes data. Cc: stable@vger.kernel.org Signed-off-by: Gil Portnoy Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit a187883cc1dc784a4d32537f5d316f1b7b9ad76f Author: Dan Carpenter Date: Thu Jun 11 10:35:28 2026 +0300 smb/client: Fix error code in smb2_aead_req_alloc() commit 61f28012e5650c619223decdb7970e0d3162e949 upstream. The "*num_sgs" variable is a u32 so "ERR_PTR(*num_sgs)" doesn't work. We would have to do something similar to the previous line where it's cast to int and then long. However, it's simpler to store the return in an int ret variable. This bug would eventually result in a crash when dereference the invalid error pointer. Fixes: d08089f649a0 ("cifs: Change the I/O paths to use an iterator rather than a page list") Cc: stable@kernel.org Signed-off-by: Dan Carpenter Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 91b8a58c6ac15c7db6518f696389933282f88da7 Author: Michael Bommarito Date: Sun May 17 20:11:49 2026 -0400 smb: client: resolve SWN tcon from live registrations commit ec457f9afe5ae9538bdcd58fd4cb442b9787e183 upstream. cifs_swn_notify() looks up a witness registration by id under cifs_swnreg_idr_mutex, drops the mutex, and then uses the registration's cached tcon pointer. That pointer is not a lifetime reference, and it is not a stable representative once cifs_get_swn_reg() lets multiple tcons for the same net/share name share one registration id. A same-share second mount can keep the cifs_swn_reg alive after the first tcon unregisters and is freed. The registration then still points at the freed first tcon, so taking tc_lock or incrementing tc_count through swnreg->tcon only moves the use-after-free earlier. Taking tc_lock while holding cifs_swnreg_idr_mutex also violates the documented CIFS lock order. Fix this by making the registration store only the stable witness identity: id, net name, share name, and notify flags. When a notify arrives, copy that identity under cifs_swnreg_idr_mutex, drop the mutex, then find and pin a live witness tcon that currently matches the net/share pair under the normal cifs_tcp_ses_lock -> tc_lock order. The notification path uses that pinned tcon directly and drops the reference when done. Registration and unregister messages now use the live tcon passed by the caller instead of a cached tcon in the registration. The final unregister send is folded into cifs_swn_unregister() while the registration is still protected by cifs_swnreg_idr_mutex. This removes the previous find/drop/reacquire raw-pointer window. The release path only removes the idr entry and frees the stable identity strings. This preserves the intended one-registration/many-tcon behavior: a registration id represents a net/share pair, and notify handling acts on a live representative selected at use time. It also preserves CLIENT_MOVE ordering for the representative tcon because the old-IP unregister is sent before cifs_swn_register() sends the new-IP register. Fixes: fed979a7e082 ("cifs: Set witness notification handler for messages from userspace daemon") Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 661a019ac0413ecec9e5d1dfcc12fbca8e78d5fb Author: Junrui Luo Date: Thu Jun 4 15:34:25 2026 +0800 coresight: ultrasoc-smb: Fix OOB write in smb_sync_perf_buffer() commit 98495b5a4d77dd22e106f462b76e1093a55b29a7 upstream. When the SMB sink is used as a perf AUX sink, smb_update_buffer() calls smb_sync_perf_buffer() to copy hardware trace data into the perf AUX ring buffer pages. It derives pg_idx = head >> PAGE_SHIFT from @head, which is handle->head, and indexes dst_pages[pg_idx]. The pg_idx %= nr_pages normalization is only applied after the first loop iteration. This leaves the initial page index underived from the buffer size, which can result in an out-of-bounds write past dst_pages[] when head exceeds the AUX buffer size. Normalize head modulo the AUX buffer size before deriving the page index and offset, mirroring tmc_etr_sync_perf_buffer(). Fixes: 06f5c2926aaa ("drivers/coresight: Add UltraSoc System Memory Buffer driver") Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/SYBPR01MB788156B3380A36835DB22290AF102@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Greg Kroah-Hartman commit 08fad5d5a26cc55c0ecb68ac59ba3be5e31f4147 Author: Deepanshu Kartikey Date: Thu Mar 19 13:15:46 2026 +0530 fs/ntfs3: fix missing run load for vcn0 in attr_data_get_block_locked() [ Upstream commit d7ea8495fd307b58f8867acd81a1b40075b1d3ba ] When a compressed or sparse attribute has its clusters frame-aligned, vcn is rounded down to the frame start using cmask, which can result in vcn != vcn0. In this case, vcn and vcn0 may reside in different attribute segments. The code already handles the case where vcn is in a different segment by loading its runs before allocation. However, it fails to load runs for vcn0 when vcn0 resides in a different segment than vcn. This causes run_lookup_entry() to return SPARSE_LCN for vcn0 since its segment was never loaded into the in-memory run list, triggering the WARN_ON(1). Fix this by adding a missing check for vcn0 after the existing vcn segment check. If vcn0 falls outside the current segment range [svcn, evcn1), find and load the attribute segment containing vcn0 before performing the run lookup. The following scenario triggers the bug: attr_data_get_block_locked() vcn = vcn0 & cmask <- vcn != vcn0 after frame alignment load runs for vcn segment <- vcn0 segment not loaded! attr_allocate_clusters() <- allocation succeeds run_lookup_entry(vcn0) <- vcn0 not in run -> SPARSE_LCN WARN_ON(1) <- bug fires here! Reported-by: syzbot+c1e9aedbd913fadad617@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c1e9aedbd913fadad617 Fixes: c380b52f6c57 ("fs/ntfs3: Change new sparse cluster processing") Signed-off-by: Deepanshu Kartikey Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 6dd58c56ab864431eb292de1507615c4e19b5857 Author: Konstantin Komarov Date: Fri Dec 12 14:38:10 2025 +0300 fs/ntfs3: zero-fill folios beyond i_valid in ntfs_read_folio() [ Upstream commit 356fa248168be90109b66f32a61b8eaedc98424a ] Handle ntfs_read_folio() early when the folio offset is beyond i_valid by zero-filling the folio and marking it uptodate. This avoids needless I/O and locking, improves read performance. Signed-off-by: Konstantin Komarov Stable-dep-of: d7ea8495fd30 ("fs/ntfs3: fix missing run load for vcn0 in attr_data_get_block_locked()") Signed-off-by: Sasha Levin commit 764e6f76fdbd495bf383639495db50e604772139 Author: Konstantin Komarov Date: Fri Dec 12 14:12:18 2025 +0300 fs/ntfs3: fsync files by syncing parent inodes [ Upstream commit dcd9d6a47199565d83d61a11bbf91fa2ade4d676 ] Some xfstests expect fsync() on a file or directory to also persist directory metadata up the parent chain. Using generic_file_fsync() is not sufficient for ntfs, because parent directories are not explicitly written out. Signed-off-by: Konstantin Komarov Stable-dep-of: d7ea8495fd30 ("fs/ntfs3: fix missing run load for vcn0 in attr_data_get_block_locked()") Signed-off-by: Sasha Levin commit 38cbb1feebcf56ed67c8683e6746ed5cdd16bbac Author: Konstantin Komarov Date: Mon Dec 8 22:57:46 2025 +0300 fs/ntfs3: rename ni_readpage_cmpr into ni_read_folio_cmpr [ Upstream commit 4248f563f0b76f3fb74b2a28ee068bf66fcbbedf ] The old "readpage" naming is still used in ni_readpage_cmpr(), even though the vfs has transitioned to the folio-based read_folio() API. This patch performs a straightforward renaming of the helper: ni_readpage_cmpr() -> ni_read_folio_cmpr(). Signed-off-by: Konstantin Komarov Stable-dep-of: d7ea8495fd30 ("fs/ntfs3: fix missing run load for vcn0 in attr_data_get_block_locked()") Signed-off-by: Sasha Levin commit 4718007870547e1efebbdd6745d9fce58f008fef Author: Lu Baolu Date: Thu Jan 22 09:48:56 2026 +0800 iommu/vt-d: Fix race condition during PASID entry replacement commit c3b1edea3791fa91ab7032faa90355913ad9451b upstream. The Intel VT-d PASID table entry is 512 bits (64 bytes). When replacing an active PASID entry (e.g., during domain replacement), the current implementation calculates a new entry on the stack and copies it to the table using a single structure assignment. struct pasid_entry *pte, new_pte; pte = intel_pasid_get_entry(dev, pasid); pasid_pte_config_first_level(iommu, &new_pte, ...); *pte = new_pte; Because the hardware may fetch the 512-bit PASID entry in multiple 128-bit chunks, updating the entire entry while it is active (Present bit set) risks a "torn" read. In this scenario, the IOMMU hardware could observe an inconsistent state — partially new data and partially old data — leading to unpredictable behavior or spurious faults. Fix this by removing the unsafe "replace" helpers and following the "clear-then-update" flow, which ensures the Present bit is cleared and the required invalidation handshake is completed before the new configuration is applied. Fixes: 7543ee63e811 ("iommu/vt-d: Add pasid replace helpers") Signed-off-by: Lu Baolu Reviewed-by: Samiullah Khawaja Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20260120061816.2132558-4-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel [vineeth: adjusted for 6.18.y: the removed intel_pasid_replace_second_level() in 6.18 still computed pgd/pgd_val locally and used the older pasid_pte_config_second_level() signature; since the function is deleted entirely, the resolution only affects removed lines. The prerequisite "Clear Present bit" patches are already in 6.18.y. Built and tested on 6.18.38: PASID replace, iommufd RID replace and DMA sanity on QEMU VT-d in scalable mode (FS and SS), no regressions.] Signed-off-by: Vineeth Pillai (Google) Signed-off-by: Greg Kroah-Hartman commit 73abbaf91aa33da87c008fb62c148ade561bb606 Author: Muhammad Bilal Date: Sun Jun 21 00:56:35 2026 +0500 Bluetooth: L2CAP: validate option length before reading conf opt value commit 687617555cedfb74c9e3cb85d759b908dcb17856 upstream. l2cap_get_conf_opt() derives the option length from the attacker-controlled opt->len field and immediately dereferences opt->val (as u8, get_unaligned_le16() or get_unaligned_le32(), or a raw pointer for the default case) before any caller has confirmed that opt->len bytes are present in the buffer. The callers (l2cap_parse_conf_req(), l2cap_parse_conf_rsp() and l2cap_conf_rfc_get()) only detect a malformed option afterwards, once the running length has gone negative, by which point the out-of-bounds read has already executed. An existing post-hoc length check keeps the garbage value from being consumed, so this is not a data leak in the current control flow. It is still a validate-after-use ordering bug: up to 4 bytes are read past the end of the buffer before it is known to contain them, and it is fragile to future changes in the callers. Fix it at the source. Pass the end of the buffer into l2cap_get_conf_opt() and refuse to touch opt->val unless the full option (header + value) fits. Each caller computes an end pointer once before the loop and checks the return value directly instead of inferring the error from a negative length. Fixes: 7c9cbd0b5e38 ("Bluetooth: Verify that l2cap_get_conf_opt provides large enough buffer") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit d5616beb3355b5fca2280d796c1cf7ada4ee6551 Author: Runyu Xiao Date: Wed Jun 17 23:36:13 2026 +0800 Bluetooth: L2CAP: cancel pending_rx_work before taking conn->lock commit 2641a9e0a1dd4af2e21995470a21d55dd35e5203 upstream. l2cap_conn_del() takes conn->lock and then calls cancel_work_sync() for pending_rx_work. process_pending_rx() takes the same mutex, so teardown can deadlock against the worker it is flushing. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the l2cap_conn_ready() -> queue_work(..., &conn->pending_rx_work) submit path, the l2cap_conn_del() -> cancel_work_sync(&conn->pending_rx_work) teardown path, and the process_pending_rx() -> mutex_lock(&conn->lock) worker edge. Lockdep reported: WARNING: possible circular locking dependency detected process_pending_rx+0x21/0x2a [vuln_msv] l2cap_conn_del.constprop.0+0x3f/0x4e [vuln_msv] *** DEADLOCK *** Cancel pending_rx_work before taking conn->lock, matching the existing lock-before-drain ordering used for the two delayed works in the same teardown path. The pending_rx queue is still purged after the work has been cancelled and conn->lock has been acquired. Fixes: 7ab56c3a6ecc ("Bluetooth: Fix deadlock in l2cap_conn_del()") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit b84eeb7636d6962dd882d5e0b31475e4f404313c Author: Muhammad Bilal Date: Sun Jun 21 21:23:05 2026 +0500 Bluetooth: ISO: avoid NULL deref of conn in iso_conn_big_sync() commit d5541eb148da72d5e0a1bca8ecd171f9fc8b366f upstream. iso_conn_big_sync() drops the socket lock to call hci_get_route() and then re-acquires it, but dereferences iso_pi(sk)->conn->hcon afterwards without re-checking that conn is still valid. While the lock is dropped, the connection can be torn down under the same socket lock: iso_disconn_cfm() -> iso_conn_del() -> iso_chan_del() sets iso_pi(sk)->conn to NULL (and the broadcast teardown path can also clear conn->hcon on its own). When iso_conn_big_sync() re-acquires the lock and reads conn->hcon, conn may be NULL, causing a NULL pointer dereference (hcon is the first member of struct iso_conn). This path is reached from iso_sock_recvmsg() for a PA-sync broadcast sink socket (BT_SK_DEFER_SETUP | BT_SK_PA_SYNC), so the dropped-lock window can race with connection teardown driven by controller events. Re-validate iso_pi(sk)->conn and its hcon after re-acquiring the socket lock and bail out if the connection went away, as already done in the sibling iso_sock_rebind_bc(). Fixes: 7a17308c17880d ("Bluetooth: iso: Fix circular lock in iso_conn_big_sync") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit b9dd39cf1667e378b25a082ca796d495d578c5d3 Author: Pauli Virtanen Date: Sat Jun 13 21:43:37 2026 +0300 Bluetooth: hci_uart: clear HCI_UART_SENDING when write_work is canceled commit 1b0d946d6f08bd39211385bc703a440911b41e46 upstream. HCI_UART_SENDING bit in tx_state means write_work is pending and blocks queueing it again. Currently this bit is not cleared when canceling the work in hci_uart_close(), which blocks future writes when device is reopened later if write_work was pending. Fix by clearing HCI_UART_SENDING when canceling the work. Also make clearing of tx_skb safe by using disable_work_sync + enable_work instead of just cancel_work_sync. hci_uart_flush() purges the proto tx queue so we can cancel the pending write_work there, instead of doing it just in hci_uart_close(). Re-enable and possibly requeue the work after queue flush. Fixes: c1bb9336ae6b ("Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths") Link: https://lore.kernel.org/linux-bluetooth/07e0a28650773abec711ee492fdb1bf5d21a6c98.camel@iki.fi/ Cc: stable@vger.kernel.org Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 61701912c58a05f6a043f097cc177a964abef348 Author: Siwei Zhang Date: Mon Jun 15 11:33:05 2026 -0400 Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn() commit 12917f591cea1af36087dba5b9ec888652f0b42a upstream. hci_abort_conn() read hci_skb_event(hdev->sent_cmd) when a connection was pending, but hdev->sent_cmd can be NULL while req_status is still HCI_REQ_PEND, leading to a NULL pointer dereference and a general protection fault from the hci_rx_work() receive path. Instead of inspecting hdev->sent_cmd, track the in-flight create connection command with a new per-connection HCI_CONN_CREATE flag and route all cancellation through hci_cancel_connect_sync(), which dispatches to a dedicated per-type cancel function. The create command is in exactly one of two states: still queued, or in flight. The cancel function holds cmd_sync_work_lock across the whole decision: the worker takes this lock to dequeue every entry, so while it is held a queued command cannot start running and an in-flight command cannot complete and let the next command become pending. This keeps the flag test and hci_cmd_sync_cancel() atomic with respect to the worker, so a queued command is simply dequeued, and an in-flight command owned by this connection is cancelled without the risk of cancelling an unrelated command that became pending in the meantime. CIS uses the same flag mechanism via HCI_CONN_CREATE_CIS but cannot be dequeued per-connection. hci_acl_create_conn_sync() and hci_le_create_conn_sync() clear HCI_CONN_CREATE after the create command completes, but the command status handler can free conn via hci_conn_del() (for example when the controller rejects the connection) while the worker is still blocked on the connection complete event. Hold a reference on conn across the create command so the flag can be cleared without a use-after-free. Fixes: a13f316e90fd ("Bluetooth: hci_conn: Consolidate code for aborting connections") Cc: stable@vger.kernel.org Suggested-by: XIAO WU Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Siwei Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 26168db1ce5a9766cde021b18e590a101c056614 Author: Yousef Alhouseen Date: Sun Jun 28 02:23:05 2026 +0200 Bluetooth: fix UAF in bt_accept_dequeue() commit 4bd0b274054f2679f28b70222b607bb0afc3ab9a upstream. bt_accept_get() takes a temporary reference before dropping the accept queue lock. bt_accept_dequeue() currently drops that reference before bt_accept_unlink(), leaving only the queue reference. bt_accept_unlink() drops the queue reference. The subsequent sock_hold() therefore accesses freed memory if it was the final reference, as observed by KASAN during listening L2CAP socket cleanup. Retain the temporary queue-walk reference through unlink and hand it to the caller on success. Drop it explicitly on the closed and not-yet-connected paths. Fixes: ab1513597c6c ("Bluetooth: fix UAF in l2cap_sock_cleanup_listen() vs l2cap_conn_del()") Reported-by: syzbot+674ff7e4d7fdfd572afc@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=674ff7e4d7fdfd572afc Cc: stable@vger.kernel.org Signed-off-by: Yousef Alhouseen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 2a68a773089204af1c8581dc79668b775418c5ee Author: Maoyi Xie Date: Wed Jun 17 16:36:52 2026 +0800 Bluetooth: btnxpuart: Fix out-of-bounds firmware read in nxp_recv_fw_req_v3() commit badff6c3bed8923a1257a853f137d447976eec30 upstream. During the v3 firmware download the controller sends a v3_data_req with a 32 bit offset and a 16 bit len. nxp_recv_fw_req_v3() checks only the lower bound of the offset and then sends firmware from that offset. nxpdev->fw_dnld_v3_offset = offset - nxpdev->fw_v3_offset_correction; serdev_device_write_buf(nxpdev->serdev, nxpdev->fw->data + nxpdev->fw_dnld_v3_offset, len); Nothing checks that fw_dnld_v3_offset + len stays within nxpdev->fw->size, so a controller that asks for an offset or length past the firmware image makes the driver read past the end of nxpdev->fw->data and send that memory back over UART. nxp_recv_fw_req_v1() already bounds the same write. Add the equivalent check to the v3 path, reject the request when it falls outside the firmware image, and zero len on the error path so the fw_v3_prev_sent bookkeeping at free_skb stays consistent. Fixes: 689ca16e5232 ("Bluetooth: NXP: Add protocol support for NXP Bluetooth chipsets") Suggested-by: Neeraj Sanjay Kale Reviewed-by: Neeraj Sanjay Kale Cc: stable@vger.kernel.org Signed-off-by: Maoyi Xie Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit a6b22dbd80926556290ad2243be25218d6956a19 Author: Yousef Alhouseen Date: Sun Jun 28 02:50:58 2026 +0200 Bluetooth: bnep: pin L2CAP connection during netdev registration commit bb067a99a0356196c0b89a95721985485ebce5a5 upstream. bnep_add_connection() reads the L2CAP connection without holding the channel lock, then passes its HCI device to register_netdev(). Controller teardown can clear and release that connection concurrently, leaving the network device registration path to dereference a freed parent device. Take a reference to the L2CAP connection while holding the channel lock. Retain it until register_netdev() has taken the parent device reference. Fixes: 65f53e9802db ("Bluetooth: Access BNEP session addresses through L2CAP channel") Reported-by: syzbot+fed5dce4553262f3b35c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=fed5dce4553262f3b35c Cc: stable@vger.kernel.org Signed-off-by: Yousef Alhouseen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 0039bdde36b23ccf1196635f1d52c5490481544d Author: Sergey Senozhatsky Date: Tue Jun 9 21:10:06 2026 +0900 Bluetooth: btmtksdio: fix infinite loop in btmtksdio_txrx_work() commit a257407e2bbbb099ed427719a50563f67fa366d8 upstream. Every once in a while we see a hung btmtksdio_flush() task: INFO: task kworker/u17:0:189 blocked for more than 122 seconds. __cancel_work_timer+0x3f4/0x460 cancel_work_sync+0x1c/0x2c btmtksdio_flush+0x2c/0x40 hci_dev_open_sync+0x10c4/0x2190 [..] It all boils down to incorrect time_is_before_jiffies() usage in btmtksdio_txrx_work(). The btmtksdio_txrx_work() loop is expected to be terminated if running for longer than 5*HZ. However the timeout check is twisted: time_is_before_jiffies(old_jiffies + 5*HZ) evaluates to true when old_jiffies + 5*HZ is in the past i.e. when a timeout has occurred. Using OR with time_is_before_jiffies(txrx_timeout) means that: - before the 5-second timeout: the condition is `int_status || false`, so it loops as long as there are pending interrupts. - after the 5-second timeout: the condition becomes `int_status || true`, which is always true. When the loop becomes infinite btmtksdio_txrx_work() loop never terminates and never releases the SDIO host. Fix loop termination condition to actually enforce a 5*HZ timeout. Fixes: 26270bc189ea4 ("Bluetooth: btmtksdio: move interrupt service to work") Cc: stable@vger.kernel.org Signed-off-by: Sergey Senozhatsky Reviewed-by: Sean Wang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 81a5971cbe18b474b49c651e32f2194b2fb171fe Author: Adrian Bente Date: Thu May 28 10:08:51 2026 +0300 netfilter: flowtable: fix offloaded ct timeout never being extended commit 53b3e60edb674b442b2b3bbdba484667b0f47a5d upstream. OpenWrt has recently migrated many platforms to kernel 6.18. On the MediaTek platform, which supports hardware network offloading, WiFi connections accelerated via the WED path were observed to drop after roughly 300 seconds. After several debugging sessions, assisted by the Claude LLM, the problem was narrowed down as follows: nf_flow_table_extend_ct_timeout() extends ct->timeout for offloaded flows using: cmpxchg(&ct->timeout, expires, new_timeout); 'expires' comes from nf_ct_expires(ct) and is a relative value, while ct->timeout holds an absolute timestamp. The two are never equal, so the cmpxchg always fails and the timeout is never extended. This goes unnoticed for most flows, but a long-lived hardware (WED) offloaded flow on MediaTek MT7986 eventually has ct->timeout decay to zero, the conntrack entry is reaped and the connection breaks. Open-code the relative value from a single READ_ONCE(ct->timeout) snapshot and compare against that same absolute snapshot in the cmpxchg, so the timeout extension actually takes effect while the datapath remains authoritative if it updates ct->timeout concurrently. Fixes: 03428ca5cee9 ("netfilter: conntrack: rework offload nf_conn timeout extension logic") Cc: stable@vger.kernel.org Suggested-by: Florian Westphal Signed-off-by: Adrian Bente Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 6fe8d3cecd20bfaaaf440db3a06ba674d2f2e322 Author: Xiang Mei Date: Sun Jul 5 14:58:00 2026 -0700 netfilter: ebtables: terminate table name before find_table_lock() commit a622d2e9608c9dff47fc2e5759ac7aa3a836b45d upstream. update_counters() and compat_update_counters() forward a user-supplied 32-byte table name to find_table_lock() without NUL-terminating it. On a lookup miss, find_inlist_lock() calls try_then_request_module(..., "%s%s", "ebtable_", name), and vsnprintf() reads past the name field and the stack object until it hits a zero byte. BUG: KASAN: stack-out-of-bounds in string (lib/vsprintf.c:648 lib/vsprintf.c:730) Read of size 1 at addr ffff8880119dfb20 by task exploit/147 Call Trace: ... string (lib/vsprintf.c:648 lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) __request_module (kernel/module/kmod.c:150) do_update_counters.isra.0 (net/bridge/netfilter/ebtables.c:371 net/bridge/netfilter/ebtables.c:380) update_counters (net/bridge/netfilter/ebtables.c:1440) do_ebt_set_ctl (net/bridge/netfilter/ebtables.c:2573) nf_setsockopt (net/netfilter/nf_sockopt.c:101) ip_setsockopt (net/ipv4/ip_sockglue.c:1424) raw_setsockopt (net/ipv4/raw.c:847) __sys_setsockopt (net/socket.c:2393) ... compat_do_replace() shares the same unterminated name via compat_copy_ebt_replace_from_user(); terminate it there too so all find_table_lock() callers behave alike. The other callers already terminate the name after the copy. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Fixes: 81e675c227ec ("netfilter: ebtables: add CONFIG_COMPAT support") 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 13a5f532e3a4fc75c33060a026def1572c208643 Author: Florian Westphal Date: Sat Jul 4 12:05:15 2026 +0200 netfilter: ebtables: module names must be null-terminated commit 084d23f818321390509e9738a0b08bbf46df6425 upstream. We need to explicitly check the length, else we may pass non-null terminated string to request_module(). Cc: stable@vger.kernel.org Fixes: bcf493428840 ("netfilter: ebtables: Fix extension lookup with identical name") Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit 9f74d28e903fa4fdf82f870d0aeadddc8196e41c Author: Florian Westphal Date: Sat Jul 4 10:23:31 2026 +0200 netfilter: ebtables: zero chainstack array commit cbfe53599eebffd188938ab6774cc41794f6f9d5 upstream. sashiko reports: looking at ebtables table translation, could a sparse cpu_possible_mask lead to an uninitialized pointer free? If cpu_possible_mask is sparse (for example, CPU 0 and CPU 2 are possible, but CPU 1 is not), the allocation loop skips CPU 1. If vmalloc_node() fails at CPU 2, the cleanup loop will blindly decrement and call vfree() on newinfo->chainstack[1]. Not a real-world bug, such allocation isn't expected to fail in the first place. Cc: stable@vger.kernel.org Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit fc5bfe63bacf8a3ae307b62b34206406ca733354 Author: Florian Westphal Date: Sun Jul 5 15:29:13 2026 +0200 netfilter: handle unreadable frags commit da5b58478a9c1b85608c9e40a3b8432d071b409e upstream. sashiko reports: When an skb with unreadable fragments (such as from devmem TCP, where skb_frags_readable(skb) returns false) is processed by the u32 module, skb_copy_bits() will safely return a negative error code [..] xt_u32: bail out with hotdrop in this case. gather_frags: return -1, just as if we had no fragment header. nfnetlink_queue: restrict to the linear part. nfnetlink_log: restrict to the linear part. v2: - skb_zerocopy helpers don't copy readable flag, i.e. nfnetlink_queue is broken too xt_u32 shouldn't return true if hotdrop was set. Fixes: 65249feb6b3d ("net: add support for skbs with unreadable frags") Cc: stable@vger.kernel.org Acked-by: Mina Almasry Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit a8f03a3793289337eba31dba3a5f263f0d8ea3bf Author: Pratham Gupta Date: Mon May 4 22:11:57 2026 -0700 netfilter: ctnetlink: use nf_ct_exp_net() in expectation dump commit a7f57320bbbc67e347bf5fff4b4a9bab980d5956 upstream. Commit 02a3231b6d82 ("netfilter: nf_conntrack_expect: store netns and zone in expectation") introduced exp->net so RCU-only expectation paths no longer need to dereference exp->master for netns lookups. Commit 3db5647984de ("netfilter: nf_conntrack_expect: skip expectations in other netns via proc") updated the proc path accordingly, but ctnetlink_exp_dump_table() still compares against nf_ct_net(exp->master). Use nf_ct_exp_net(exp) here as well so the netlink dump path matches the rest of the March 2026 expectation netns/RCU cleanup. Fixes: 02a3231b6d82 ("netfilter: nf_conntrack_expect: store netns and zone in expectation") Cc: stable@vger.kernel.org Signed-off-by: Pratham Gupta Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit 69c0e6246575b780ae0d3f411c749bcf13c221f3 Author: Zijiang Huang Date: Wed May 6 21:09:19 2026 +0800 mm/swap: add cond_resched() in swap_reclaim_full_clusters to prevent softlockup commit 66366d291f666ddeda5f8c84f253e308de3e6b55 upstream. We hit a real softlockup in an internal stress test environment. The workload was LTP memory/swap stress on a large arm64 machine, with 320 CPUs, about 1TB memory and an 8.6GB swap device. The system was under heavy load and the swap device had a large number of full clusters. The softlockup was triggered during a stress test after about 3 days. So, add periodic cond_resched() calls during large full_clusters reclaim operations to prevent softlockup issues. Detailed call trace as follow: PID: 3817773 TASK: ffff0883bb28b780 CPU: 48 COMMAND: "kworker/48:7" #0 [ffff800080183d10] __crash_kexec at ffffa4c1361e5de4 #1 [ffff800080183d90] panic at ffffa4c1360d5e9c #2 [ffff800080183e20] watchdog_timer_fn at ffffa4c136231fa8 ... #16 [ffff8000c4ad3cb0] swap_cache_del_folio at ffffa4c1363e1614 #17 [ffff8000c4ad3ce0] __try_to_reclaim_swap at ffffa4c1363e4bfc #18 [ffff8000c4ad3d40] swap_reclaim_full_clusters at ffffa4c1363e5474 #19 [ffff8000c4ad3da0] swap_reclaim_work at ffffa4c1363e550c #20 [ffff8000c4ad3dc0] process_one_work at ffffa4c136102edc #21 [ffff8000c4ad3e10] worker_thread at ffffa4c136103398 #22 [ffff8000c4ad3e70] kthread at ffffa4c13610d95c Link: https://lore.kernel.org/20260506130919.2298807-1-kerayhuang@tencent.com Fixes: 5168a68eb78f ("mm, swap: avoid over reclaim of full clusters") Signed-off-by: Zijiang Huang Reviewed-by: Kairui Song Reviewed-by: Hao Peng Reviewed-by: albinwyang Reviewed-by: Baoquan He Acked-by: Chris Li Cc: Barry Song Cc: Kairui Song Cc: Kemeng Shi Cc: Nhat Pham Cc: Youngjun Park Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b415c00bf23df577a4a95673d00ae76687bcc1d4 Author: Jose Fernandez (Anthropic) Date: Mon May 4 12:55:17 2026 +0000 mm: swap_cgroup: fix NULL deref in lookup_swap_cgroup_id on swapless host commit 63b02a9409cb5180398491b093e48bcb5315f5fb upstream. lookup_swap_cgroup_id() passes swap_cgroup_ctrl[type].map to __swap_cgroup_id_lookup() without checking that the type was ever registered via swap_cgroup_swapon(). On a swapless host every ctrl->map is NULL, so __swap_cgroup_id_lookup() dereferences NULL + a scaled swp_offset(). Since commit bea67dcc5eea ("mm: attempt to batch free swap entries for zap_pte_range()"), zap_pte_range() -> swap_pte_batch() calls lookup_swap_cgroup_id() on any non-present, non-none PTE that decodes as a real swap entry, without first validating it against swap_info[]. A single PTE corrupted into a type-0 swap entry takes the host down at process exit. We hit this in production on a swapless 6.12.58 host: ~1s of "get_swap_device: Bad swap file entry 3f800204222bb" (do_swap_page() being correctly defensive about the same entry) followed by BUG: unable to handle page fault for address: 000003f800204220 RIP: 0010:lookup_swap_cgroup_id+0x2b/0x60 Call Trace: swap_pte_batch+0xbf/0x230 zap_pte_range+0x4c8/0x780 unmap_page_range+0x190/0x3e0 exit_mmap+0xd9/0x3c0 do_exit+0x20c/0x4b0 syzbot has reported the identical stack. The source of the PTE corruption is a separate bug; this change makes the teardown path as robust as the fault path already is. Every other caller of lookup_swap_cgroup_id() is downstream of a get_swap_device() that has already validated the entry, so the new branch is cold. Link: https://lore.kernel.org/20260504-swap-cgroup-fix-7-0-v1-1-f53ff41ee553@linux.dev Fixes: bea67dcc5eea ("mm: attempt to batch free swap entries for zap_pte_range()") Signed-off-by: Jose Fernandez (Anthropic) Reported-by: syzbot+e12bd9ca48157add237a@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/69859728.050a0220.3b3015.0033.GAE@google.com Assisted-by: Claude:unspecified Cc: Barry Song Cc: David Hildenbrand Cc: Hugh Dickins Cc: Johannes Weiner Cc: Kairui Song Cc: Michal Hocko Cc: Muchun Song Cc: Roman Gushchin Cc: Shakeel Butt Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 006467ab932698612398f853344a7405164541f4 Author: Qi Zheng Date: Wed Jun 17 17:00:52 2026 +0800 mm: shrinker: fix NULL pointer dereference in debugfs commit e30453c61e185e914fde83c650e268067b140218 upstream. shrinker_debugfs_add() creates both "count" and "scan" debugfs files unconditionally. That assumes every shrinker implements both count_objects() and scan_objects(), which is not guaranteed. For example, the xen-backend shrinker sets count_objects() but leaves scan_objects() NULL, so writing to its scan file calls through a NULL function pointer and panics the kernel: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. Call Trace: shrinker_debugfs_scan_write+0x12e/0x270 full_proxy_write+0x5f/0x90 vfs_write+0xde/0x420 ? filp_flush+0x75/0x90 ? filp_close+0x1d/0x30 ? do_dup2+0xb8/0x120 ksys_write+0x68/0xf0 ? filp_flush+0x75/0x90 do_syscall_64+0xb3/0x5b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The count path has the same issue in principle if a shrinker omits count_objects(). To fix it, only create "count" and "scan" debugfs files when the corresponding callbacks are present. Link: https://lore.kernel.org/20260617090052.27325-1-qi.zheng@linux.dev Fixes: bbf535fd6f06 ("mm: shrinkers: add scan interface for shrinker debugfs") Signed-off-by: Qi Zheng Reviewed-by: Muchun Song Cc: Dave Chinner Cc: Qi Zheng Cc: Roman Gushchin Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 6465ff3ce65131c774a312d450abe10f4b9f3875 Author: Qi Zheng Date: Wed Jun 17 16:56:58 2026 +0800 mm: shrinker: fix shrinker_info teardown race with expansion commit 65476d31d8056e859c48580f82295ce159196ffe upstream. expand_shrinker_info() iterates all visible memcgs under shrinker_mutex, including memcgs that have not finished ->css_online() yet. Once pn->shrinker_info has been published, teardown must stay serialized with expand_shrinker_info() until that memcg is either fully online or no longer visible to iteration. Today alloc_shrinker_info() breaks that rule by dropping shrinker_mutex before freeing a partially initialized shrinker_info array, which may cause the following race: CPU0 CPU1 ==== ==== css_create --> list_add_tail_rcu(&css->sibling, &parent_css->children); online_css --> mem_cgroup_css_online --> alloc_shrinker_info --> alloc node0 info rcu_assign_pointer(C->node0->shrinker_info, old0) alloc node1 info -> FAIL -> goto err mutex_unlock(shrinker_mutex) shrinker_alloc() --> shrinker_memcg_alloc --> mutex_lock(shrinker_mutex) expand_shrinker_info --> mem_cgroup_iter see the memcg expand_one_shrinker_info --> old0 = C->node0->shrinker_info memcpy(new->unit, old0->unit, ...); free_shrinker_info --> kvfree(old0); /* double free !! */ kvfree_rcu(old0, rcu); The same problem exists later in mem_cgroup_css_online(). If alloc_shrinker_info() succeeds but a subsequent objcg allocation fails, the free_objcg -> free_shrinker_info() unwind path tears down the already published pn->shrinker_info arrays without shrinker_mutex. The expand_one_shrinker_info() can race with that teardown in the same way, leading to use-after-free or double-free of the old shrinker_info. Fix this by serializing shrinker_info teardown with shrinker_mutex, and by keeping alloc_shrinker_info() error cleanup inside the locked section. Link: https://lore.kernel.org/20260617085658.27096-1-qi.zheng@linux.dev Fixes: 307bececcd12 ("mm: shrinker: add a secondary array for shrinker_info::{map, nr_deferred}") Signed-off-by: Qi Zheng Acked-by: Muchun Song Cc: Dave Chinner Cc: Qi Zheng Cc: Roman Gushchin Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 560e21e8ccff813e84d05f6500907c549a3d6985 Author: Shakeel Butt Date: Wed Jun 10 16:20:48 2026 -0700 mm/shrinker: do not hold RCU lock in shrinker_debugfs_count_show() commit b902890c62d200b3509cb5e09cf1e0a66553c128 upstream. Reading the debugfs "count" file of a memcg-aware shrinker can sleep inside an RCU read-side critical section: BUG: sleeping function called from invalid context at kernel/cgroup/rstat.c:421 RCU nest depth: 1, expected: 0 css_rstat_flush mem_cgroup_flush_stats zswap_shrinker_count shrinker_debugfs_count_show shrinker_debugfs_count_show() invokes the ->count_objects() callback under rcu_read_lock(). The zswap callback flushes memcg stats via css_rstat_flush(), which may sleep, so it must not run under RCU. The RCU lock is not needed here. mem_cgroup_iter() takes RCU internally and returns a memcg holding a css reference (dropped on the next iteration or by mem_cgroup_iter_break()), so the memcg stays alive without it. The shrinker is kept alive by the open debugfs file: shrinker_free() removes the debugfs entries via debugfs_remove_recursive(), which waits for in-flight readers to drain, before call_rcu(..., shrinker_free_rcu_cb). The sibling "scan" handler already invokes the sleeping ->scan_objects() callback with no RCU section. Drop the rcu_read_lock()/rcu_read_unlock(). Link: https://lore.kernel.org/20260610232048.62930-1-shakeel.butt@linux.dev Fixes: 5035ebc644ae ("mm: shrinkers: introduce debugfs interface for memory shrinkers") Signed-off-by: Shakeel Butt Reported-by: Zenghui Yu Closes: https://lore.kernel.org/all/c052a064-cddb-494f-a0d8-f8a10b4b1c4d@linux.dev/ Suggested-by: Nhat Pham Reviewed-by: SeongJae Park Reviewed-by: Qi Zheng Tested-by: Zenghui Yu (Huawei) Reviewed-by: Nhat Pham Acked-by: Muchun Song Reviewed-by: Roman Gushchin Cc: Dave Chinner Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b5f41d5bf08e7b1b14fa0bd640975e6d78dc006d Author: Andrei Kuchynski Date: Mon Apr 27 13:17:21 2026 +0000 mfd: cros_ec: Delay dev_set_drvdata() until probe success commit 8b2c1d41bc36c100b38ce5ee6def246c527eaf8a upstream. If ec_device_probe() fails, cros_ec_class_release releases memory for the cros_ec_dev structure. However, because the drvdata was already set, sub-drivers like cros_ec_typec can still retrieve the stale pointer via the platform device. This leads to a use-after-free when cros_ec_typec attempts to access &typec->ec->ec->dev on a device that has already been released. Move dev_set_drvdata() to ensure that the pointer is only made available once all initialization steps have succeeded. sysfs: cannot create duplicate filename '/class/chromeos/cros_ec' Call trace: sysfs_do_create_link_sd+0x94/0xdc sysfs_create_link+0x30/0x44 device_add_class_symlinks+0x90/0x13c device_add+0xf0/0x50c ec_device_probe+0x150/0x4f0 platform_probe+0xa0/0xe0 ... BUG: KASAN: invalid-access in __memcpy+0x44/0x230 Write at addr f5ffff809e2d33ac by task kworker/u32:5/125 Pointer tag: [f5], memory tag: [fe] Tainted : [W]=WARN, [O]=OOT_MODULE Hardware name: Google Navi unprovisioned 0x7FFFFFFF/sku0 board/sku3 Workqueue: events_unbound deferred_probe_work_func Call trace: __memcpy+0x44/0x230 cros_ec_check_features+0x60/0xcc [cros_ec_proto] cros_typec_probe+0xe8/0x6e0 [cros_ec_typec] platform_probe+0xa0/0xe0 Cc: stable@vger.kernel.org Fixes: 1c1d152cc5ac ("platform/chrome: cros_ec_dev - utilize new cdev_device_add helper function") Co-developed-by: Sergey Senozhatsky Signed-off-by: Sergey Senozhatsky Signed-off-by: Andrei Kuchynski Reviewed-by: Benson Leung Link: https://patch.msgid.link/20260427131721.1165078-1-akuchynski@chromium.org Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit bbae351c0f32f7c200249e4aa6561b2b419dcf69 Author: Wyatt Feng Date: Mon Jun 15 18:31:18 2026 +0800 net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes commit efb8763d7bbb40cff4cc55a6b62c3095a038149c upstream. Reject invalid `net.ipv4.tcp_reordering` values before they reach TCP socket state. The sysctl is stored as an `int` but copied into the `u32` `tp->reordering` field for new sockets, so negative writes wrap to large values. With `tcp_mtu_probing=2`, the wrapped value can overflow the `tcp_mtu_probe()` size calculation and drive the MTU probing path into an out-of-bounds read. Route `tcp_reordering` writes through `proc_dointvec_minmax()` and require it to be at least 1. Also require `tcp_max_reordering` to be at least 1 so the configured maximum cannot become negative either. When registering the table for a non-init network namespace, relocate `extra2` pointers that refer into `init_net.ipv4` so the `tcp_reordering` upper bound follows that namespace's `tcp_max_reordering`. Harden `tcp_mtu_probe()` itself by computing `size_needed` as `u64`. This keeps the send queue and window checks from being bypassed through signed integer overflow. Fixes: 91cc17c0e5e5 ("[TCP]: MTUprobe: receiver window & data available checks fixed") Cc: stable@vger.kernel.org Reported-by: Yuan Tan Reported-by: Zhengchuan Liang Reported-by: Xin Liu Suggested-by: Eric Dumazet Signed-off-by: Wyatt Feng Signed-off-by: Ren Wei Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/1a5b7e1ef4d70fbad8c8ee0b82d8405f3c964a3d.1781395200.git.bronzed_45_vested@icloud.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2ca18df1c2611f70eb3eb487e02ae85eb703b284 Author: Yuyang Huang Date: Thu Jul 2 08:50:14 2026 +0900 ipv4: igmp: remove multicast group from hash table on device destruction commit 7993211bde166471dffac074dc965489f86531f8 upstream. When a device is destroyed under RTNL, ip_mc_destroy_dev() iterates through the multicast list and calls ip_ma_put() on each membership, scheduling them for RCU reclamation. However, they are not unlinked from the device's multicast hash table (mc_hash). Since the device remains published in dev->ip_ptr until after ip_mc_destroy_dev() completes, concurrent RCU readers traversing mc_hash can still locate and access the multicast group after its refcount is decremented. If the RCU callback runs and frees the group while a reader is accessing it, a use-after-free occurs. Fix this by unlinking the multicast group from mc_hash using ip_mc_hash_remove() before scheduling it for reclamation. BUG: KASAN: slab-use-after-free in ip_check_mc_rcu+0x149/0x3f0 Read of size 4 at addr ffff888009bf1408 by task mausezahn/2276 Call Trace: dump_stack_lvl+0x67/0x90 print_report+0x175/0x7c0 kasan_report+0x147/0x180 ip_check_mc_rcu+0x149/0x3f0 udp_v4_early_demux+0x36d/0x12d0 ip_rcv_finish_core+0xb8b/0x1390 ip_rcv_finish+0x54/0x120 NF_HOOK+0x213/0x2b0 __netif_receive_skb+0x126/0x340 process_backlog+0x4f2/0xf00 __napi_poll+0x92/0x2c0 net_rx_action+0x583/0xc60 handle_softirqs+0x236/0x7f0 do_softirq+0x57/0x80 Allocated by task 2239: kasan_save_track+0x3e/0x80 __kasan_kmalloc+0x72/0x90 ____ip_mc_inc_group+0x31a/0xa40 __ip_mc_join_group+0x334/0x3f0 do_ip_setsockopt+0x16fa/0x2010 ip_setsockopt+0x3f/0x90 do_sock_setsockopt+0x1ad/0x300 Freed by task 0: kasan_save_track+0x3e/0x80 kasan_save_free_info+0x40/0x50 __kasan_slab_free+0x3a/0x60 __rcu_free_sheaf_prepare+0xd4/0x220 rcu_free_sheaf+0x36/0x190 rcu_core+0x8d9/0x12f0 handle_softirqs+0x236/0x7f0 Fixes: e9897071350b ("igmp: hash a hash table to speedup ip_check_mc_rcu()") Cc: stable@vger.kernel.org Signed-off-by: Yuyang Huang Reviewed-by: Kuniyuki Iwashima Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260701235014.73505-1-yuyanghuang@google.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit a33f37f8d079da7236ed7b7e2aed2a34ab81e7cf Author: Breno Leitao Date: Thu Jun 25 05:03:18 2026 -0700 netpoll: fix a use-after-free on shutdown path commit 45f1458a85017a023f138b22ac5c76abd477db42 upstream. There is a use-after-free error on netpoll, which is clearly detected by KASAN. BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0x3b/0x80 Read of size 1 at addr ... by task kworker/9:1 Workqueue: events queue_process Call Trace: skb_dequeue+0x1e/0xb0 queue_process+0x2c/0x600 process_scheduled_works+0x4b6/0x850 worker_thread+0x414/0x5a0 Allocated by task 242: __netpoll_setup+0x201/0x4a0 netpoll_setup+0x249/0x550 enabled_store+0x32f/0x380 Freed by task 0: kfree+0x1b7/0x540 rcu_core+0x3f8/0x7a0 The problem happens when there is a pending TX worker running in parallel with the cleanup path. This is what happens on netpoll shutdown path: 1) __netpoll_cleanup() is called 2) set dev->npinfo to NULL 3) call_rcu() with rcu_cleanup_netpoll_info() 3.1) rcu_cleanup_netpoll_info() tries to cancel all workers with cancel_delayed_work(), but doesn't wait for the worker to finish 4) and kfree(npinfo); Because 3.1) doesn't really cancel the work, as the comment says "we can't call cancel_delayed_work_sync here, as we are in softirq", the TX worker can run after 4). Tl;DR: queue_process() is not an RCU reader, it reaches npinfo through the work item via container_of(). Use disable_delayed_work_sync() to ensure the worker is completely stopped and prevent any future re-arming attempts. Once npinfo is set to NULL, senders will bail out and not queue new work. The disable flag ensures any in-flight re-arming attempts also fail silently. In the future, we can do the cleanup inline here without needing the npinfo->rcu rcu_head, but that is net-next material. Cc: stable@vger.kernel.org Fixes: 38e6bc185d95 ("netpoll: make __netpoll_cleanup non-block") Reviewed-by: Pavan Chebbi Signed-off-by: Breno Leitao Link: https://patch.msgid.link/20260625-netpoll_rcu_fix-v2-1-0748ffac1e98@debian.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f090acf881a262a51a3347f7e98991011c329ec4 Author: Michael Wigham Date: Sat Jun 13 23:52:16 2026 +0100 io_uring/rw: preserve partial result for iopoll commit c554246ff4c68abf71b61a89c6e39d3cf94f523e upstream. A partial read will store the completed byte count in io->bytes_done. The regular completion path applies io_fixup_rw_res() so that, when the following operation reaches EOF, the number of bytes already read is returned. The iopoll completion path does not apply this fixup to the return value and can return zero instead. Use the fixup result when updating the CQE, and the raw result for the reissue check. Cc: stable@vger.kernel.org Fixes: 4d9cb92ca41d ("io_uring/rw: fix short rw error handling") Signed-off-by: Michael Wigham Link: https://patch.msgid.link/20260613225240.34032-1-michael@wigham.net Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 1636d85dc139b07c0449308f2bb5e0c7a2e0da99 Author: Runyu Xiao Date: Thu May 28 01:22:03 2026 +0800 io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item commit 29bef9934b2521f787bb15dd1985d4c0d12ae02a upstream. commit 10dc95939817 ("io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop") fixed the obvious case where io_worker_handle_work() took one exit-bit snapshot before draining pending work, but the fix stops one level too early. io_worker_handle_work() now re-checks IO_WQ_BIT_EXIT in its outer work run loop, yet it still snapshots that bit once before processing a whole dependent linked-work chain. If io_wq_exit_start() sets IO_WQ_BIT_EXIT after the first linked item has started, the remaining linked items can still reuse stale do_kill = false, skip IO_WQ_WORK_CANCEL, and continue running after exit has begun. Move the check further inside, so it covers linked items too. Note: this is a syzbot special as it loves setting up tons of slow linked work on weird devices like msr that take forever to read, and immediately close the ring. Exit then takes a long time. Fixes: 10dc95939817 ("io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260527172203.2043962-1-runyu.xiao@seu.edu.cn Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 722869fcff598fad20d5ab79c305897a7534708b Author: Vasileios Almpanis Date: Mon Jun 15 16:45:57 2026 +0200 io_uring/nop: fix file reference leak with IOSQE_FIXED_FILE commit 2564ca2e31bd8ee8348362941af2ee4671e487ca upstream. NOP file-acquisition support choses between a fixed (registered) file and a normal fget()'d file based on its own IORING_NOP_FIXED_FILE flag in sqe->nop_flags. However, a request's REQ_F_FIXED_FILE is set independently from the generic IOSQE_FIXED_FILE sqe flag during request init, before the issue handler runs. If a NOP is submitted with IOSQE_FIXED_FILE set (so REQ_F_FIXED_FILE is set) but without IORING_NOP_FIXED_FILE, io_nop() takes the normal path and grabs a real reference via io_file_get_normal(). On completion, io_put_file() only drops the reference when REQ_F_FIXED_FILE is clear, so the fget()'d file is never released and leaks: BUG: memory leak unreferenced object 0xffff88800f42c240 (size 176): kmem_cache_alloc_noprof+0x358/0x440 alloc_empty_file+0x57/0x180 path_openat+0x44/0x1e50 do_file_open+0x121/0x200 do_sys_openat2+0xa7/0x150 __x64_sys_openat+0x82/0xf0 Decide between fixed and normal file acquisition from REQ_F_FIXED_FILE, the same way io_assign_file() does for every other opcode, and fold IORING_NOP_FIXED_FILE into REQ_F_FIXED_FILE at prep time. Cc: stable@vger.kernel.org Fixes: a85f31052bce ("io_uring/nop: add support for testing registered files and buffers") Reported-by: syzbot+2cd473471e77bda12b0e@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?id=879092631b98f73a28ea405adacfa5bb34a14a25 Signed-off-by: Vasileios Almpanis Link: https://patch.msgid.link/20260615144619.482749-1-vasilisalmpanis@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 4508366ab7dd0c2917a51a9c2e23cc1b9d35157a Author: Runyu Xiao Date: Wed Jun 17 23:40:34 2026 +0800 gpio: sch: use raw_spinlock_t in the irq startup path commit 286533cb14a3c8a8bd39ff64ea2fc8e1aa0f638b upstream. sch_irq_unmask() enables the GPIO IRQ and then updates the controller state through sch_irq_mask_unmask(), which takes sch->lock with spin_lock_irqsave(). The callback can be reached from irq_startup() while setting up a requested IRQ. That path is not sleepable, but on PREEMPT_RT a regular spinlock_t becomes a sleeping lock. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the request_threaded_irq() -> __setup_irq() -> irq_startup() -> sch_irq_unmask() -> sch_irq_mask_unmask() carrier and used the original spin_lock_irqsave(&sch->lock) edge. Lockdep reported: BUG: sleeping function called from invalid context hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv] sch_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv] sch_irq_mask_unmask.constprop.0+0x31/0x70 [vuln_msv] __setup_irq.constprop.0+0xd/0x30 [vuln_msv] Convert the SCH controller lock to raw_spinlock_t. The same lock is also used by the GPIO direction and value callbacks, but those critical sections only update MMIO-backed GPIO registers and do not contain sleepable operations. Keeping this register lock non-sleeping is therefore appropriate for the irqchip callbacks and does not change the GPIO-side locking contract. Fixes: 7a81638485c1 ("gpio: sch: Add edge event support") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Reviewed-by: Sebastian Andrzej Siewior Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20260617154035.1199948-2-runyu.xiao@seu.edu.cn Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 4750909a40da9016185e0ac991510a278cecb1e7 Author: Runyu Xiao Date: Wed Jun 17 23:40:35 2026 +0800 gpio: eic-sprd: use raw_spinlock_t in the irq startup path commit 90f0109019e6817eb40a486671b7722d1544ae29 upstream. sprd_eic_irq_unmask() enables the GPIO IRQ and then updates controller state through sprd_eic_update(), which takes sprd_eic->lock with spin_lock_irqsave(). The callback can be reached from irq_startup() while setting up a requested IRQ. That path is not sleepable, but on PREEMPT_RT a regular spinlock_t becomes a sleeping lock. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the request_threaded_irq() -> __setup_irq() -> irq_startup() -> sprd_eic_irq_unmask() -> sprd_eic_update() carrier and used the original spin_lock_irqsave(&sprd_eic->lock) edge. Lockdep reported: BUG: sleeping function called from invalid context hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv] sprd_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv] sprd_eic_update.constprop.0+0x48/0x90 [vuln_msv] sprd_eic_irq_unmask.constprop.0+0x35/0x50 [vuln_msv] __setup_irq.constprop.0+0xd/0x30 [vuln_msv] Convert the Spreadtrum EIC controller lock to raw_spinlock_t. The locked section only serializes MMIO register updates and does not contain sleepable operations, so keeping it non-sleeping is appropriate for the irqchip callbacks. Fixes: 25518e024e3a ("gpio: Add Spreadtrum EIC driver support") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Reviewed-by: Sebastian Andrzej Siewior Link: https://patch.msgid.link/20260617154035.1199948-3-runyu.xiao@seu.edu.cn Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit f71e8d9875069fa73e335f63f02ec6e52e3aaa51 Author: Koichiro Den Date: Wed Mar 4 17:30:28 2026 +0900 NTB: epf: Avoid calling pci_irq_vector() from hardirq context commit 4dcddc1c794d1c65eda68f1f8dd04a0fecc0870f upstream. ntb_epf_vec_isr() calls pci_irq_vector() in hardirq context to derive the vector number. pci_irq_vector() calls msi_get_virq() that takes a mutex and can therefore trigger "scheduling while atomic" splats: BUG: scheduling while atomic: kworker/u33:0/55/0x00010001 ... Call trace: ... schedule+0x38/0x110 schedule_preempt_disabled+0x28/0x50 __mutex_lock.constprop.0+0x848/0x908 __mutex_lock_slowpath+0x18/0x30 mutex_lock+0x4c/0x60 msi_domain_get_virq+0xe8/0x138 pci_irq_vector+0x2c/0x60 ntb_epf_vec_isr+0x28/0x120 [ntb_hw_epf] __handle_irq_event_percpu+0x70/0x3a8 handle_irq_event+0x48/0x100 handle_edge_irq+0x100/0x1c8 ... Cache the Linux IRQ number for vector 0 when vectors are allocated and use it as a base in the ISR. Running the ISR in a threaded IRQ handler would also avoid the problem, but that would be unnecessary here. 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: Dave Jiang Cc: stable@vger.kernel.org # v5.12+ Link: https://patch.msgid.link/20260304083028.1391068-3-den@valinux.co.jp Signed-off-by: Greg Kroah-Hartman commit cf28fc1658463d768657cf1c27a83980d4ba7ef2 Author: Yunpeng Tian Date: Mon May 4 07:19:43 2026 -0700 fs/ntfs3: validate Dirty Page Table capacity in log_replay copy_lcns commit 57382ec6ac63b63dce2789e835fded28b698ae79 upstream. In the analysis pass of $LogFile journal replay, log_replay() copies LCNs from each action log record into an existing Dirty Page Table (DPT) entry without bounding the destination index. A crafted NTFS image with DPT entry lcns_follow=1 and an action log record with lcns_follow=2 produces a kernel slab out-of-bounds write at mount time: BUG: KASAN: slab-out-of-bounds in log_replay+0x654c/0xdb60 Write of size 8 at addr ffff8880095e1040 by task mount Two attacker-controlled fields can drive j+i past the allocated page_lcns[] array: 1. dp->lcns_follow (capacity) can be smaller than lrh->lcns_follow. 2. lrh->target_vcn may be smaller than dp->vcn, making the u64 subtraction wrap to a huge size_t. Validate target VCN delta and per-record LCN count against the DPT entry capacity, bail via the existing out: cleanup label with -EINVAL. This mirrors the bounds-check pattern added in commit b2bc7c44ed17 ("fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot") and commit 0ca0485e4b2e ("fs/ntfs3: validate rec->used in journal-replay file record check"). Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Reported-by: Yunpeng Tian Reported-by: Mingda Zhang Reported-by: Gongming Wang Reported-by: Peiyuan Xu Reported-by: Qinrun Dai Cc: stable@vger.kernel.org Signed-off-by: Yunpeng Tian Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit c00164c9e7fa6145886ad666806cb5347895de5c Author: Thomas Gleixner Date: Sun Jun 21 16:47:44 2026 +0200 debugobjects: Plug race against a concurrent OOM disable commit b81dde13cc163450dcb402dcc915ef13ba241e01 upstream. syzbot reported a puzzling splat: WARNING: kernel/time/hrtimer.c:443 at stub_timer+0xa/0x20 stub_timer() is installed as timer callback function in hrtimer_fixup_assert_init(), which is invoked when debug_object_assert_init() can't find a shadow object. In that case debug objects emits a warning about it before invoking the fixup. Though the provided console log lacks this warning and instead has the following a few seconds before the splat: ODEBUG: Out of memory. ODEBUG disabled So the object was looked up in debug_object_assert_init() and the lookup failed due a concurrent out of memory situation which disabled debug objects and freed the shadow objects: debug_object_assert_init() if (!debug_objects_enabled) return; obj = alloc(); if (!obj) { // Out of memory debug_objects_enabled = false; free_objects(); obj = lookup_or_alloc(); // The lookup failed because the other side // removed the objects, so this returns // an error code as the object in question // is not statically initialized if (!IS_ERR_OR_NULL(obj)) return; if (!obj) { debug_oom(); return; } print(...) if (!debug_objects_enabled) return; fixup(...) The debug object splat is skipped because debug_objects_enabled is false, but the fixup callback is invoked unconditionally, which makes the timer disfunctional. This is only a problem in debug_object_assert_init() and debug_object_activate() as both have to handle statically initialized objects and therefore must handle the error pointer return case gracefully. All other places only handle the found/not found case and the NULL pointer return is a signal for OOM. Otherwise they get a valid shadow object. Plug the hole by checking whether debug objects are still enabled before invoking the print and fixup function in those two places. Fixes: b84d435cc228 ("debugobjects: Extend to assert that an object is initialized") Reported-by: syzbot+5e8dda76ca21dae314b6@syzkaller.appspotmail.com Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/874iiwlzlb.ffs@fw13 Signed-off-by: Greg Kroah-Hartman commit cbb684ef39e9f292464da133be622f9734bb6f49 Author: Runyu Xiao Date: Fri May 29 00:52:01 2026 +0800 coresight: etb10: restore atomic_t for shared reading state commit fa09f08ede3db3050ae16ae1ed92c902d0cada23 upstream. The etb10 miscdevice uses drvdata->reading as a shared exclusivity gate for userspace buffer access. etb_open() claims that gate with local_cmpxchg(), and etb_release() clears it with local_set(). That gate is shared per-device state rather than CPU-local state. A running system can reach it whenever /dev/ is opened, closed, and reopened by different tasks while the device remains registered, so the same drvdata->reading variable may be claimed on one CPU and later cleared on another. This code used to use atomic_t for the same gate, but commit 27b10da8fff2 ("coresight: etb10: moving to local atomic operations") changed it to local_t even though the access pattern remained cross-task and cross-CPU. Restore atomic_t together with atomic_cmpxchg() and atomic_set() so the exclusivity gate again uses a primitive intended for shared state. The issue was found on Linux v6.18.21 by our static analysis tool while scanning surviving local_t-on-shared-state sites, and then manually reviewed against the live etb10 file-op path. It was runtime-validated with a reproducible QEMU no-device KCSAN PoC that kept the same report-local contract: 1. use one shared struct etb_drvdata carrier and its drvdata->reading gate; 2. call etb_open() and etb_release() sequentially on that gate to confirm the original claim/clear path; 3. bind the open side to CPU0 and the release side to CPU1 for the same gate to show cross-CPU ownership; 4. run bound workers that repeatedly race etb_open() and etb_release() on the same gate until KCSAN reports a target hit. The harness recorded: L1 passed open=1 release=1 reading_after_open=1 reading_after_release=0 L2 passed open_cpu=0 release_cpu=1 cross_cpu_release=1 reading_after=0 open_ret=0 Representative KCSAN excerpt from the no-device validation run: BUG: KCSAN: data-race in etb_open.constprop.0.isra.0 [vuln_msv] write to 0xffffffffc0003810 of 4 bytes by task 216 on cpu 1: etb_open.constprop.0.isra.0+0x38/0x80 [vuln_msv] l3_worker_thread_fn+0x4f/0xf0 [vuln_msv] kthread+0x17e/0x1c0 ret_from_fork+0x22/0x30 read to 0xffffffffc0003810 of 4 bytes by task 215 on cpu 0: etb_open.constprop.0.isra.0+0x18/0x80 [vuln_msv] l3_worker_thread_fn+0x4f/0xf0 [vuln_msv] kthread+0x17e/0x1c0 ret_from_fork+0x22/0x30 value changed: 0x00000000 -> 0x00000001 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 215 Comm: etb10_l3_a Tainted: G O 6.1.66 #2 This no-device harness is not a real ETB10 hardware end-to-end run, but it preserves the same shared drvdata->reading gate and the same etb_open()/etb_release() claim/clear contract. No real ETB10 hardware was available for runtime testing. Build-tested with: make olddefconfig make -j"$(nproc)" drivers/hwtracing/coresight/coresight-etb10.o Fixes: 27b10da8fff2 ("coresight: etb10: moving to local atomic operations") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Reviewed-by: James Clark Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20260528165201.319452-1-runyu.xiao@seu.edu.cn Signed-off-by: Greg Kroah-Hartman commit b346efa825b5e4386f19bc63f81141652d496ec4 Author: Samuel Page Date: Mon Jun 15 16:09:22 2026 +0100 Bluetooth: MGMT: Fix UAF of hci_conn_params in add_device_complete commit fa85d985f614bc3feb343000f14a1072e99b0df1 upstream. add_device_complete() runs from the hci_cmd_sync_work kworker, which holds only hci_req_sync_lock and *not* hci_dev_lock. It calls hci_conn_params_lookup() and then dereferences the returned object (params->flags) without taking hci_dev_lock: params = hci_conn_params_lookup(hdev, &cp->addr.bdaddr, le_addr_type(cp->addr.type)); ... device_flags_changed(NULL, hdev, &cp->addr.bdaddr, cp->addr.type, hdev->conn_flags, params ? params->flags : 0); hci_conn_params_lookup() walks hdev->le_conn_params and is documented to require hdev->lock. A concurrent MGMT_OP_REMOVE_DEVICE (remove_device()), which does run under hci_dev_lock, can call hci_conn_params_free() to list_del() and kfree() the very object the lookup returned, so the subsequent params->flags read touches freed memory [0]. Hold hci_dev_lock() across the hci_conn_params_lookup() and the read of params->flags (and the matching event emission) so the lookup result cannot be freed by a concurrent remove_device() before it is used, honouring the locking contract of hci_conn_params_lookup(). [0]: (trailing page/memory-state dump trimmed) BUG: KASAN: slab-use-after-free in add_device_complete+0x358/0x3d8 net/bluetooth/mgmt.c:7671 Read of size 1 at addr ffff000017ab26c1 by task kworker/u9:8/388 CPU: 1 UID: 0 PID: 388 Comm: kworker/u9:8 Not tainted 7.0.11 #20 PREEMPT Hardware name: linux,dummy-virt (DT) Workqueue: hci0 hci_cmd_sync_work Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:499 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xb4/0xd4 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x118/0x5d8 mm/kasan/report.c:482 kasan_report+0xb0/0xf4 mm/kasan/report.c:595 __asan_report_load1_noabort+0x20/0x2c mm/kasan/report_generic.c:378 add_device_complete+0x358/0x3d8 net/bluetooth/mgmt.c:7671 hci_cmd_sync_work+0x14c/0x240 net/bluetooth/hci_sync.c:334 process_one_work+0x628/0xd38 kernel/workqueue.c:3289 process_scheduled_works kernel/workqueue.c:3372 [inline] worker_thread+0x7a8/0xac0 kernel/workqueue.c:3453 kthread+0x39c/0x444 kernel/kthread.c:436 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860 Allocated by task 3401: kasan_save_stack+0x3c/0x64 mm/kasan/common.c:57 kasan_save_track+0x20/0x3c mm/kasan/common.c:78 kasan_save_alloc_info+0x40/0x54 mm/kasan/generic.c:570 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xd4/0xd8 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __kmalloc_cache_noprof+0x1b0/0x458 mm/slub.c:5385 kmalloc_noprof include/linux/slab.h:950 [inline] kzalloc_noprof include/linux/slab.h:1188 [inline] hci_conn_params_add+0x10c/0x4b0 net/bluetooth/hci_core.c:2279 hci_conn_params_set net/bluetooth/mgmt.c:5162 [inline] add_device+0x5b4/0xa54 net/bluetooth/mgmt.c:7755 hci_mgmt_cmd net/bluetooth/hci_sock.c:1721 [inline] hci_sock_sendmsg+0x10b4/0x1dd0 net/bluetooth/hci_sock.c:1841 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0xe0/0x128 net/socket.c:742 sock_write_iter+0x250/0x390 net/socket.c:1195 new_sync_write fs/read_write.c:595 [inline] vfs_write+0x66c/0xab0 fs/read_write.c:688 ksys_write+0x1fc/0x24c fs/read_write.c:740 __do_sys_write fs/read_write.c:751 [inline] __se_sys_write fs/read_write.c:748 [inline] __arm64_sys_write+0x70/0xa4 fs/read_write.c:748 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x84/0x2a8 arch/arm64/kernel/syscall.c:49 el0_svc_common.constprop.0+0xe4/0x294 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x44/0x5c arch/arm64/kernel/syscall.c:151 el0_svc+0x38/0xac arch/arm64/kernel/entry-common.c:724 el0t_64_sync_handler+0xa0/0xe4 arch/arm64/kernel/entry-common.c:743 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:596 Freed by task 3740: kasan_save_stack+0x3c/0x64 mm/kasan/common.c:57 kasan_save_track+0x20/0x3c mm/kasan/common.c:78 kasan_save_free_info+0x4c/0x74 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 [inline] __kasan_slab_free+0x88/0xb8 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 [inline] slab_free_hook mm/slub.c:2685 [inline] slab_free mm/slub.c:6170 [inline] kfree+0x14c/0x458 mm/slub.c:6488 hci_conn_params_free+0x288/0x484 net/bluetooth/hci_core.c:2312 remove_device+0x4b0/0x968 net/bluetooth/mgmt.c:7919 hci_mgmt_cmd net/bluetooth/hci_sock.c:1721 [inline] hci_sock_sendmsg+0x10b4/0x1dd0 net/bluetooth/hci_sock.c:1841 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0xe0/0x128 net/socket.c:742 sock_write_iter+0x250/0x390 net/socket.c:1195 new_sync_write fs/read_write.c:595 [inline] vfs_write+0x66c/0xab0 fs/read_write.c:688 ksys_write+0x1fc/0x24c fs/read_write.c:740 __do_sys_write fs/read_write.c:751 [inline] __se_sys_write fs/read_write.c:748 [inline] __arm64_sys_write+0x70/0xa4 fs/read_write.c:748 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x84/0x2a8 arch/arm64/kernel/syscall.c:49 el0_svc_common.constprop.0+0xe4/0x294 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x44/0x5c arch/arm64/kernel/syscall.c:151 el0_svc+0x38/0xac arch/arm64/kernel/entry-common.c:724 el0t_64_sync_handler+0xa0/0xe4 arch/arm64/kernel/entry-common.c:743 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:596 Fixes: 1e2e3044c1bc ("Bluetooth: MGMT: Fix MGMT_OP_ADD_DEVICE invalid device flags") Cc: stable@vger.kernel.org Assisted-by: Bynario AI Signed-off-by: Samuel Page Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit d3b739db5dc6f688a60d56da872fabaf65246032 Author: Marco Elver Date: Fri Jun 5 16:23:35 2026 +0200 Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref commit b66774b48dd98f07254951f74ea6f513efe7ff8b upstream. l2cap_chan_timeout() runs asynchronously and accesses chan->conn. If the connection is torn down while the timer is running or pending, chan->conn can be freed, leading to a use-after-free when the timer worker attempts to lock conn->lock: | BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 [inline] | BUG: KASAN: slab-use-after-free in atomic_long_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h:4456 [inline] | BUG: KASAN: slab-use-after-free in __mutex_trylock_fast kernel/locking/mutex.c:161 [inline] | BUG: KASAN: slab-use-after-free in mutex_lock+0x4f/0xa0 kernel/locking/mutex.c:318 | Write of size 8 at addr ffff8881298d9550 by task kworker/2:1/83 | | CPU: 2 UID: 0 PID: 83 Comm: kworker/2:1 Not tainted 7.1.0-rc6-next-20260601-dirty #6 PREEMPT(full) | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 | Workqueue: events l2cap_chan_timeout | Call Trace: | | instrument_atomic_read_write include/linux/instrumented.h:112 [inline] | atomic_long_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h:4456 [inline] | __mutex_trylock_fast kernel/locking/mutex.c:161 [inline] | mutex_lock+0x4f/0xa0 kernel/locking/mutex.c:318 | l2cap_chan_timeout+0x5d/0x1b0 net/bluetooth/l2cap_core.c:422 | process_one_work kernel/workqueue.c:3326 [inline] | process_scheduled_works+0x7c8/0xfb0 kernel/workqueue.c:3409 | worker_thread+0x8a9/0xcf0 kernel/workqueue.c:3490 | kthread+0x346/0x430 kernel/kthread.c:436 | ret_from_fork+0x1a3/0x470 arch/x86/kernel/process.c:158 | ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 | | | Allocated by task 320: | l2cap_conn_add+0xa7/0x820 net/bluetooth/l2cap_core.c:7075 | l2cap_connect_cfm+0xdb/0xd70 net/bluetooth/l2cap_core.c:7452 | hci_connect_cfm include/net/bluetooth/hci_core.h:2139 [inline] | hci_remote_features_evt+0x52f/0x9f0 net/bluetooth/hci_event.c:3760 | hci_event_func net/bluetooth/hci_event.c:7796 [inline] | hci_event_packet+0x561/0xa70 net/bluetooth/hci_event.c:7847 | hci_rx_work+0x370/0x890 net/bluetooth/hci_core.c:4040 | process_one_work kernel/workqueue.c:3326 [inline] | process_scheduled_works+0x7c8/0xfb0 kernel/workqueue.c:3409 | worker_thread+0x8a9/0xcf0 kernel/workqueue.c:3490 | kthread+0x346/0x430 kernel/kthread.c:436 | ret_from_fork+0x1a3/0x470 arch/x86/kernel/process.c:158 | ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 | | Freed by task 322: | hci_disconn_cfm include/net/bluetooth/hci_core.h:2154 [inline] | hci_conn_hash_flush+0x101/0x1f0 net/bluetooth/hci_conn.c:2736 | hci_dev_close_sync+0x889/0xde0 net/bluetooth/hci_sync.c:5405 | hci_dev_do_close net/bluetooth/hci_core.c:502 [inline] | hci_unregister_dev+0x1f7/0x370 net/bluetooth/hci_core.c:2679 | vhci_release+0x12a/0x180 drivers/bluetooth/hci_vhci.c:690 | __fput+0x369/0x890 fs/file_table.c:510 | task_work_run+0x160/0x1d0 kernel/task_work.c:233 | get_signal+0xf5b/0x1120 kernel/signal.c:2810 | arch_do_signal_or_restart+0x4d/0x600 arch/x86/kernel/signal.c:337 | __exit_to_user_mode_loop kernel/entry/common.c:64 [inline] | exit_to_user_mode_loop+0x85/0x510 kernel/entry/common.c:98 | do_syscall_64+0x263/0x3d0 arch/x86/entry/syscall_64.c:100 | entry_SYSCALL_64_after_hwframe+0x77/0x7f | | The buggy address belongs to the object at ffff8881298d9400 | which belongs to the cache kmalloc-512 of size 512 | The buggy address is located 336 bytes inside of | freed 512-byte region [ffff8881298d9400, ffff8881298d9600) Fix it by having chan->conn hold a reference to l2cap_conn (via l2cap_conn_get) when the channel is added to the connection, and releasing it in the channel destructor. This ensures the l2cap_conn remains alive as long as the channel exists. A new FLAG_DEL channel flag is introduced to indicate that the channel has been deleted from its connection. l2cap_chan_del() atomically sets this flag using test_and_set_bit() instead of setting chan->conn to NULL. All asynchronous workers (l2cap_chan_timeout, l2cap_ack_timeout, l2cap_monitor_timeout, l2cap_retrans_timeout) and l2cap_chan_send() check FLAG_DEL to determine whether the channel has been torn down, rather than testing chan->conn for NULL. Fixes: 8c8e620467a7 ("Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()") Cc: Cc: Siwei Zhang Cc: Luiz Augusto von Dentz Assisted-by: Gemini:gemini-3.1-pro-preview Reported-by: https://sashiko.dev/#/patchset/20260521021249.3258069-1-oss%40fourdim.xyz Signed-off-by: Marco Elver Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit fe997a84a385f840b593ead92e575503a5046cee Author: Chi Wang Date: Fri Jun 19 15:42:44 2026 +0800 audit: Fix data races of skb_queue_len() readers on audit_queue commit c9a71daaecb2fb1d8c704545cc0b1c920b9bf5d7 upstream. Multiple readers access audit_queue.qlen via skb_queue_len() without holding the queue lock or using READ_ONCE(), while kauditd writes to this field via the skb_dequeue() → __skb_unlink() path with WRITE_ONCE() protected by a spinlock. This constitutes data races. All affected skb_queue_len(&audit_queue) call sites: - kauditd_thread() wait_event_freezable() condition - audit_receive_msg() AUDIT_GET handler (s.backlog assignment) - audit_receive() backlog check - audit_log_start() backlog check and pr_warn() KCSAN reports the following conflicting access pattern (one example): ================================================================== BUG: KCSAN: data-race in audit_log_start / skb_dequeue write (marked) to 0xffffffff8512ee20 of 4 bytes by task 661 on cpu 57: skb_dequeue+0x70/0xf0 kauditd_send_queue+0x71/0x220 kauditd_thread+0x1cb/0x430 kthread+0x1c2/0x210 ret_from_fork+0x162/0x1a0 ret_from_fork_asm+0x1a/0x30 read to 0xffffffff8512ee20 of 4 bytes by task 36586 on cpu 1: audit_log_start+0x2a0/0x6b0 audit_core_dumps+0x64/0xa0 do_coredump+0x14b/0x1260 get_signal+0xeb2/0xf70 arch_do_signal_or_restart+0x41/0x170 exit_to_user_mode_loop+0xa2/0x1c0 do_syscall_64+0x1a3/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0xe0 value changed: 0x00000001 -> 0x00000000 ================================================================== Resolve the race by switching to lockless helper skb_queue_len_lockless(), which internally uses READ_ONCE() and properly pairs with the WRITE_ONCE() write accesses already present on the writer side. Cc: stable@vger.kernel.org Fixes: 3197542482df ("audit: rework audit_log_start()") Signed-off-by: Chi Wang Reviewed-by: Ricardo Robaina [PM: line length tweak] Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit e8417353cbd078d10531ba3928e609c84ab09e6b Author: Zijing Yin Date: Mon Jun 8 07:44:41 2026 -0700 net: af_key: initialize alg_key_len for IPComp states commit d129c3177d7b1138fd5066fcc63a698b3ba415b0 upstream. pfkey_msg2xfrm_state() handles the IPComp (SADB_X_SATYPE_IPCOMP) case by allocating x->calg and copying only the algorithm name: x->calg = kmalloc_obj(*x->calg); if (!x->calg) { err = -ENOMEM; goto out; } strcpy(x->calg->alg_name, a->name); x->props.calgo = sa->sadb_sa_encrypt; Unlike the authentication (x->aalg) and encryption (x->ealg) branches of the same function, the compression branch never initializes calg->alg_key_len. IPComp carries no key and the allocation only reserves sizeof(struct xfrm_algo) (i.e. no room for a key), so the field is left containing uninitialized slab data. calg->alg_key_len is later used as a length by xfrm_algo_clone() when an IPComp state is cloned during XFRM_MSG_MIGRATE: xfrm_state_migrate() xfrm_state_clone_and_setup() x->calg = xfrm_algo_clone(orig->calg); kmemdup(orig, xfrm_alg_len(orig)); where xfrm_alg_len() returns sizeof(*alg) + (alg_key_len + 7) / 8. With a non-zero garbage alg_key_len, kmemdup() reads past the end of the 68-byte calg object. Adding an IPComp SA via PF_KEY and then migrating it triggers (net-next, KASAN, init_on_alloc=0): BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x44/0x60 Read of size 4164 at addr ff11000025a74980 by task diag2/9287 CPU: 3 UID: 0 PID: 9287 Comm: diag2 7.1.0-rc6-g903db046d557 #1 Call Trace: dump_stack_lvl+0x10e/0x1f0 print_report+0xf7/0x600 kasan_report+0xe4/0x120 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x23/0x60 kmemdup_noprof+0x44/0x60 xfrm_state_migrate+0x70a/0x1da0 xfrm_migrate+0x753/0x18a0 xfrm_do_migrate+0xb47/0xf10 xfrm_user_rcv_msg+0x411/0xb50 netlink_rcv_skb+0x158/0x420 xfrm_netlink_rcv+0x71/0x90 netlink_unicast+0x584/0x850 netlink_sendmsg+0x8b0/0xdc0 ____sys_sendmsg+0x9f7/0xb90 ___sys_sendmsg+0x134/0x1d0 __sys_sendmsg+0x16d/0x220 do_syscall_64+0x116/0x7d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 9287: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 pfkey_add+0x2652/0x2ea0 pfkey_process+0x6d0/0x830 pfkey_sendmsg+0x42c/0x850 __sys_sendto+0x461/0x4b0 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0x116/0x7d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The buggy address belongs to the object at ff11000025a74980 which belongs to the cache kmalloc-96 of size 96 The buggy address is located 0 bytes inside of allocated 68-byte region [ff11000025a74980, ff11000025a749c4) Depending on the uninitialized value the same field can instead request an oversized kmemdup() allocation and make the migration clone fail. The XFRM netlink path is not affected: verify_one_alg() rejects an XFRMA_ALG_COMP attribute shorter than xfrm_alg_len(), so a calg added via XFRM_MSG_NEWSA is always self-consistent. Initialize calg->alg_key_len to 0, matching the aalg/ealg branches. Fixes: 80c9abaabf42 ("[XFRM]: Extension for dynamic update of endpoint address(es)") Cc: stable@vger.kernel.org Signed-off-by: Zijing Yin Reviewed-by: Sabrina Dubroca Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 94083db751930b1540ddff2b54d4677549c57f81 Author: Gil Portnoy Date: Wed Jun 10 19:53:14 2026 +0900 ksmbd: fix use-after-free of a deferred file_lock on SMB2_CLOSE then SMB2_CANCEL commit 10f293a07f9e10e988b0ae44e2e99c631f5a68e0 upstream. Commit f580d27e8928 ("ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL") made smb2_cancel() skip a work whose state is KSMBD_WORK_CANCELLED, so its cancel_fn cannot be fired a second time. But KSMBD_WORK has three states (ACTIVE, CANCELLED, CLOSED), and the same freeing producer path is reached for CLOSED too: SMB2_CLOSE on the locking handle -> set_close_state_blocked_works() sets the deferred work's state to KSMBD_WORK_CLOSED and wakes the smb2_lock() worker. The worker takes the non-ACTIVE early-exit, locks_free_lock()s the file_lock and, because the state is not KSMBD_WORK_CANCELLED, takes the STATUS_RANGE_NOT_LOCKED branch with "goto out2" -- which, like the cancelled branch, skips release_async_work(). The work stays on conn->async_requests with a live cancel_fn = smb2_remove_blocked_lock pointing at the freed file_lock. A subsequent SMB2_CANCEL for the same AsyncId then passes the KSMBD_WORK_CANCELLED-only guard (its state is KSMBD_WORK_CLOSED), so smb2_cancel() fires cancel_fn again over the freed file_lock -- the same use-after-free fixed, via SMB2_CLOSE instead of a first SMB2_CANCEL: BUG: KASAN: slab-use-after-free in __locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- 2nd SMB2_CANCEL fires cancel_fn handle_ksmbd_work Allocated by ...: locks_alloc_lock <- smb2_lock Freed by ...: locks_free_lock <- smb2_lock (non-ACTIVE early-exit) ... cache file_lock_cache of size 192 Reproduced on mainline 7.1-rc7 (which already contains f580d27e8928) with KASAN by an authenticated SMB client; the double-SMB2_CANCEL control is silent on that kernel, so the splat is attributable to the CLOSE trigger. Only an ACTIVE deferred work may have its cancel_fn fired: both terminal states (CANCELLED and CLOSED) reach the smb2_lock() early-exit that frees the file_lock and skips release_async_work(). Guard on KSMBD_WORK_ACTIVE so any non-active work is skipped. Fixes: f580d27e8928 ("ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL") Cc: stable@vger.kernel.org Signed-off-by: Gil Portnoy Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit ef6feb77e2d91761427c5b773edc9c97e1b706ad Author: Michael Bommarito Date: Sun May 10 19:24:55 2026 -0400 crypto: krb5 - filter out async aead implementations at alloc commit 6c9dddeb582fde005360f4fe02c760d45ca05fb5 upstream. krb5_aead_encrypt(), krb5_aead_decrypt() in rfc3961_simplified.c and rfc8009_encrypt(), rfc8009_decrypt() in rfc8009_aes2.c set a NULL completion callback and treat any negative return from crypto_aead_{encrypt,decrypt}() as terminal, falling through to kfree_sensitive(buffer). When the encrypt_name resolves to an async AEAD instance the request returns -EINPROGRESS, the buffer is freed while the backend's worker still holds a pointer, and the worker dereferences the freed slab on completion. KASAN report under UML+SLUB with a synthetic async aead backend bound to krb5->encrypt_name: BUG: KASAN: slab-use-after-free in t5_stub_complete+0x7d/0xc7 The helpers were written synchronously, so filter the async instances out at allocation time instead of plumbing crypto_wait_req() through every call site. Reachable via net/rxrpc/rxgk.c, fs/afs/cm_security.c and net/ceph/crypto.c on systems with an async AEAD provider bound to the krb5 enctype name. Fixes: 00244da40f78 ("crypto/krb5: Implement the Kerberos5 rfc3961 encrypt and decrypt functions") Fixes: 6c3c0e86c2ac ("crypto/krb5: Implement the AES enctypes from rfc8009") Cc: stable@vger.kernel.org Suggested-by: Herbert Xu Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 84a00be9b736aa5dce902a290f62cbbbdcfab9ed Author: Dawei Feng Date: Fri May 8 12:24:16 2026 +0800 crypto: amlogic - avoid double cleanup in meson_crypto_probe() commit 6d827ade51a24e18d81afb9f32756d339520a14c upstream. When meson_allocate_chanlist() fails after a partial allocation, it already unwinds the allocated chanlist state through its local error path. meson_crypto_probe() then jump to error_flow and calls meson_free_chanlist() again, causing the same per-flow resources to be torn down twice. In the reproduced failure path, the second teardown re-entered crypto_engine_exit() on an already destroyed worker and KASAN reported a slab-use-after-free in kthread_destroy_worker(). Prevent double-free by handling partial allocation failures locally within meson_allocate_chanlist() and skipping the outer cleanup 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. The bug was reproduced in a QEMU x86_64 guest booted with KASAN on v7.1, using the reproducer under tools/testing/meson_crypto_probe. The reproducer forces the second dma_alloc_attrs() call in the gxl-crypto probe path to return NULL, making meson_allocate_chanlist() fail after partial initialization. On the unpatched kernel this reliably triggered a slab-use-after-free. With this fix applied, the same reproducer no longer emits any KASAN report and the probe fails cleanly with -ENOMEM. ================================================================== BUG: KASAN: slab-use-after-free in kthread_destroy_worker+0xb2/0xd0 Read of size 8 at addr ff1100010c057a68 by task insmod/265 CPU: 1 UID: 0 PID: 265 Comm: insmod Tainted: G O 7.1.0-rc2-00376-g810af9adc907-dirty #10 PREEMPT(lazy) Tainted: [O]=OOT_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x68/0xa0 print_report+0xcb/0x5e0 ? __virt_addr_valid+0x21d/0x3f0 ? kthread_destroy_worker+0xb2/0xd0 ? kthread_destroy_worker+0xb2/0xd0 kasan_report+0xca/0x100 ? kthread_destroy_worker+0xb2/0xd0 kthread_destroy_worker+0xb2/0xd0 meson_crypto_probe+0x4d0/0xc10 [amlogic_gxl_crypto] platform_probe+0x99/0x140 really_probe+0x1c6/0x6a0 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x248/0x310 ? acpi_driver_match_device+0xb0/0x100 driver_probe_device+0x48/0x210 ? __pfx___device_attach_driver+0x10/0x10 __device_attach_driver+0x160/0x320 bus_for_each_drv+0x104/0x190 ? __pfx_bus_for_each_drv+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x2c/0x50 __device_attach+0x19d/0x3b0 ? __pfx___device_attach+0x10/0x10 ? do_raw_spin_unlock+0x53/0x220 device_initial_probe+0x78/0xa0 bus_probe_device+0x5b/0x130 device_add+0xcfd/0x1430 ? __pfx_device_add+0x10/0x10 ? insert_resource+0x34/0x50 ? lock_release+0xc9/0x290 platform_device_add+0x24e/0x590 ? __pfx_meson_crypto_probe_repro_init+0x10/0x10 [meson_crypto_probe_repro] meson_crypto_probe_repro_init+0x330/0xff0 [meson_crypto_probe_repro] do_one_initcall+0xc0/0x450 ? __pfx_do_one_initcall+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x2c/0x50 ? __create_object+0x59/0x80 ? kasan_unpoison+0x27/0x60 do_init_module+0x27b/0x7d0 ? __pfx_do_init_module+0x10/0x10 ? kasan_quarantine_put+0x84/0x1d0 ? kfree+0x32c/0x510 ? load_module+0x561e/0x5ff0 load_module+0x54fe/0x5ff0 ? __pfx_load_module+0x10/0x10 ? security_file_permission+0x20/0x40 ? kernel_read_file+0x23d/0x6e0 ? mmap_region+0x235/0x4a0 ? __pfx_kernel_read_file+0x10/0x10 ? __file_has_perm+0x2c0/0x3e0 init_module_from_file+0x158/0x180 ? __pfx_init_module_from_file+0x10/0x10 ? __lock_acquire+0x45a/0x1ba0 ? idempotent_init_module+0x315/0x610 ? lock_release+0xc9/0x290 ? lockdep_init_map_type+0x4b/0x220 ? do_raw_spin_unlock+0x53/0x220 idempotent_init_module+0x330/0x610 ? __pfx_idempotent_init_module+0x10/0x10 ? __pfx_cred_has_capability.isra.0+0x10/0x10 ? ksys_mmap_pgoff+0x385/0x520 __x64_sys_finit_module+0xbe/0x120 do_syscall_64+0x115/0x690 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f7d6d31690d Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f3 b4 0f 00 f7 d8 > RSP: 002b:00007fffc027ac68 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 000055f7b81967c0 RCX: 00007f7d6d31690d RDX: 0000000000000000 RSI: 000055f79a0d6cd2 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000003 R11: 0000000000000246 R12: 000055f79a0d6cd2 R13: 000055f7b8196790 R14: 000055f79a0d5888 R15: 000055f7b81968e0 Fixes: 48fe583fe541 ("crypto: amlogic - Add crypto accelerator for amlogic GXL") Cc: stable@vger.kernel.org Signed-off-by: Zilin Guan Signed-off-by: Dawei Feng Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 6f91621fc45025ad3c0be796b70e6e4cee22fc69 Author: Alexandru Hossu Date: Fri May 22 02:45:28 2026 +0200 staging: rtl8723bs: fix OOB write in HT_caps_handler() commit f8001e1a516ba3b495728c65b61f799cbfad6bd0 upstream. HT_caps_handler() iterates pIE->length bytes and writes into HT_caps.u.HT_cap[], which is a fixed 26-byte array (sizeof struct HT_caps_element). Because pIE->length is a raw u8 from an over-the-air 802.11 AssocResponse frame and is never validated, a malicious AP can set it up to 255, causing up to 229 bytes of out-of-bounds writes into adjacent fields of struct mlme_ext_info. Truncate the iteration count to the size of HT_caps.u.HT_cap using umin() so that data from a longer-than-expected IE is silently ignored rather than written out of bounds, preserving interoperability with APs that pad the element. An early return on oversized IEs was considered but rejected: it would bypass the pmlmeinfo->HT_caps_enable = 1 assignment that precedes the loop, silently disabling HT mode for APs that append extra bytes to the HT Capabilities IE. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable Signed-off-by: Alexandru Hossu Reviewed-by: Luka Gejak Link: https://patch.msgid.link/20260522004531.1038924-5-hossu.alexandru@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit a6105ea8ca6ebbc04beaf3bcbf7dbb5985f5d395 Author: Alexandru Hossu Date: Fri May 22 02:45:30 2026 +0200 staging: rtl8723bs: fix OOB reads in is_ap_in_tkip() IE loop commit 3bf39f711ff27c64be8680a8938bcc5001982e81 upstream. The loop in is_ap_in_tkip() iterates over IEs without verifying that enough bytes remain before dereferencing the IE header or its payload: - pIE->element_id and pIE->length are read without checking that i + sizeof(*pIE) <= ie_length, so a truncated IE at the end of the buffer causes an OOB read. - For WLAN_EID_VENDOR_SPECIFIC the code compares pIE->data + 12, which requires pIE->length >= 16. For WLAN_EID_RSN it compares pIE->data + 8, requiring pIE->length >= 12. Neither requirement is checked. Add the missing IE header and payload bounds checks and guard each data access with an explicit pIE->length minimum, matching the pattern established in update_beacon_info(). Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable Signed-off-by: Alexandru Hossu Link: https://patch.msgid.link/20260522004531.1038924-7-hossu.alexandru@gmail.com Signed-off-by: Greg Kroah-Hartman commit c38d16b1ffac385c9e4b38447cd5c46af1114b58 Author: Alexandru Hossu Date: Fri May 22 02:45:26 2026 +0200 staging: rtl8723bs: fix OOB reads in IE loops in issue_assocreq() and join_cmd_hdl() commit ef61d628dfad38fead1fd2e08979ae9126d011d5 upstream. Two IE parsing loops are missing the header bounds checks before they dereference pIE->length: - issue_assocreq() walks pmlmeinfo->network.ies to build the association request. If the stored IE data ends with only an element_id byte and no length byte, pIE->length is read one byte past the end of the buffer. - join_cmd_hdl() walks pnetwork->ies during station join and has the same problem under the same conditions. Both buffers are filled from AP beacon and probe-response frames, so a malicious AP that sends a truncated final IE can trigger the issue. Apply the two-guard pattern established in update_beacon_info(): 1. Break if fewer than sizeof(*pIE) bytes remain. 2. Break if the IE's declared data extends past the buffer end. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable Reviewed-by: Luka Gejak Signed-off-by: Alexandru Hossu Link: https://patch.msgid.link/20260522004531.1038924-3-hossu.alexandru@gmail.com Signed-off-by: Greg Kroah-Hartman commit 69f174a0673b6b7a29b851adb60bc450cdc0ecc4 Author: Alexandru Hossu Date: Fri May 22 02:45:25 2026 +0200 staging: rtl8723bs: fix OOB read in update_beacon_info() IE loop commit ed51de4a86e173c3b0ef78e039c2e49e08b11f16 upstream. The IE parsing loop in update_beacon_info() advances by (pIE->length + 2) each iteration but only guards on i < len. When a malicious AP sends a Beacon whose last IE has only one byte remaining in the frame (the element_id byte lands at len-1), the loop reads pIE->length from one byte past the allocated receive buffer. Additionally, even when the header bytes are in bounds, pIE->length itself can extend the data window beyond len, passing a truncated IE to the handler functions. Add two guards at the top of the loop body: 1. Break if fewer than sizeof(*pIE) bytes remain (can't read header). 2. Break if the IE's declared data extends past len. Also replace i += (pIE->length + 2) with i += sizeof(*pIE) + pIE->length for consistency with the sizeof(*pIE) guards added above. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable Reviewed-by: Luka Gejak Signed-off-by: Alexandru Hossu Link: https://patch.msgid.link/20260522004531.1038924-2-hossu.alexandru@gmail.com Signed-off-by: Greg Kroah-Hartman commit 04f612dc03427e0b1ac80a2611b5ac0ba93ac446 Author: Alexandru Hossu Date: Fri May 22 02:45:29 2026 +0200 staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop commit f9654207e92283e0acac5d64fe5f8835383b5a23 upstream. The IE parsing loop in OnAssocRsp() advances by (pIE->length + 2) each iteration but only guards on i < pkt_len. When a malicious AP sends an AssocResponse whose last IE has only one byte remaining in the frame (the element_id byte lands at pkt_len-1), the loop reads pIE->length from pframe[pkt_len], which is one byte past the allocated receive buffer. Additionally, even when the header bytes are in bounds, pIE->length itself can extend the data window beyond pkt_len, silently passing a truncated IE to the handler functions. Add two guards at the top of the loop body: 1. Break if fewer than sizeof(*pIE) bytes remain (can't read header). 2. Break if the IE's declared data extends past pkt_len. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable Signed-off-by: Alexandru Hossu Reviewed-by: Luka Gejak Link: https://patch.msgid.link/20260522004531.1038924-6-hossu.alexandru@gmail.com Signed-off-by: Greg Kroah-Hartman commit 64ec4192d9c10e96922245d4a6747304cc76b19d Author: Alexandru Hossu Date: Fri May 22 02:46:05 2026 +0200 staging: rtl8723bs: fix WEP length underflow and OOB read in OnAuth() commit a1fc19d61f661d47204f095b593de507884849f7 upstream. OnAuth() has two bugs in the shared-key authentication path. When the Privacy bit is set, rtw_wep_decrypt() is called without verifying that the frame is long enough to contain a valid WEP IV and ICV. Inside rtw_wep_decrypt(), length is computed as: length = len - WLAN_HDR_A3_LEN - iv_len and then passed as (length - 4) to crc32_le(). If len is less than WLAN_HDR_A3_LEN + iv_len + icv_len (32 bytes), length - 4 is negative and, after the implicit cast to size_t, causes crc32_le() to read far beyond the frame buffer. Add a minimum length check before accessing the IV field and calling the decryption path. When processing a seq=3 response, rtw_get_ie() stores the Challenge Text IE length in ie_len, but the subsequent memcmp() always reads 128 bytes regardless of ie_len. IEEE 802.11 mandates a challenge text of exactly 128 bytes; reject any IE whose length field differs, matching the check already applied to OnAuthClient(). Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable Signed-off-by: Alexandru Hossu Link: https://patch.msgid.link/20260522004605.1039209-1-hossu.alexandru@gmail.com Signed-off-by: Greg Kroah-Hartman commit b9c4bf133c3c47e23baf4f5403b98a953bf58606 Author: Alexandru Hossu Date: Fri May 22 02:45:27 2026 +0200 staging: rtl8723bs: fix heap buffer overflow in rtw_cfg80211_set_wpa_ie() commit 5a752a616e756844388a1a45404db9fc29fec655 upstream. supplicant_ie is a 256-byte array in struct security_priv. The WPA and WPA2 IE copy paths use: memcpy(padapter->securitypriv.supplicant_ie, &pwpa[0], wpa_ielen + 2); where wpa_ielen is the raw IE length field (u8, 0-255). When a local user supplies a connect request via nl80211 with a crafted WPA IE of length 255, wpa_ielen + 2 equals 257, overflowing the 256-byte buffer by one byte into the adjacent last_mic_err_time field. rtw_parse_wpa_ie() does not prevent this: its length consistency check compares *(wpa_ie+1) against (u8)(wpa_ie_len-2), which is (u8)(255) == 255 when wpa_ie_len = 257, so the check passes silently. Add explicit bounds checks for both the WPA and WPA2 paths before the memcpy, rejecting any IE whose total size (wpa_ielen + 2) exceeds the supplicant_ie buffer. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable Reviewed-by: Luka Gejak Signed-off-by: Alexandru Hossu Link: https://patch.msgid.link/20260522004531.1038924-4-hossu.alexandru@gmail.com Signed-off-by: Greg Kroah-Hartman commit b5ddc7257bee71f5b8cf9083e2b0ac0427e9fbb3 Author: Alexandru Hossu Date: Mon Apr 13 17:12:44 2026 +0200 staging: media: ipu7: fix double-free and use-after-free in error paths commit d3a9a8cf2d7fd61a2f63df61f6cbc0a9bb007cc0 upstream. In both ipu7_isys_init() and ipu7_psys_init(), pdata is allocated and then passed to ipu7_bus_initialize_device(), which stores it in adev->pdata. The ipu7_bus_release() function frees adev->pdata when the device's reference count drops to zero. Two error paths incorrectly call kfree(pdata) after the device teardown has already freed it: 1. When ipu7_mmu_init() fails: put_device() is called, which drops the reference count to zero and triggers ipu7_bus_release() -> kfree(pdata). The subsequent kfree(pdata) is a double-free. 2. When ipu7_bus_add_device() fails: it calls auxiliary_device_uninit() internally, which calls put_device() -> ipu7_bus_release() -> kfree(pdata). The subsequent kfree(pdata) is again a double-free. Note that the kfree(pdata) when ipu7_bus_initialize_device() itself fails is correct, because in that case auxiliary_device_init() failed and the release function was never set up, so pdata must be freed manually. Additionally, the error code was not saved before calling put_device(), causing ERR_CAST() to dereference the already-freed adev pointer when constructing the return value. Fix this by saving the error from dev_err_probe() before put_device() and returning ERR_PTR() instead. Remove the redundant kfree(pdata) calls and fix the use-after-free in the return values of the two affected error paths. Fixes: b7fe4c0019b1 ("media: staging/ipu7: add Intel IPU7 PCI device driver") Cc: stable@vger.kernel.org Reviewed-by: Dan Carpenter Signed-off-by: Alexandru Hossu Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 1ca4f310c6b1fba9ac1fc791323d073a3b961ba8 Author: Arnd Bergmann Date: Wed Mar 25 13:59:43 2026 +0100 staging: media: atomisp: reduce load_primary_binaries() stack usage commit f4d51e55dd47ef467fbe37d8575e20eee41b092d upstream. The load_primary_binaries() function is overly complex and has som large variables on the stack, which can cause warnings depending on CONFIG_FRAME_WARN setting: drivers/staging/media/atomisp/pci/sh_css.c: In function 'load_primary_binaries': drivers/staging/media/atomisp/pci/sh_css.c:5260:1: error: the frame size of 1560 bytes is larger than 1536 bytes [-Werror=frame-larger-than=] Half of the stack usage is for the prim_descr[] array, but only one member of the array is used at any given time. Reduce the stack usage by turning the array into a single structure. Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2") Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann Reviewed-by: Andy Shevchenko Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit b4ba13dafa13ca54d8a5ca8ce6f9ee95ce59c6c5 Author: Ricardo Ribalda Date: Thu May 7 20:58:10 2026 +0000 media: staging: ipu3-imgu: Add range check for imgu_css_cfg_acc_stripe commit c32fe4c4918c9aa49f61359e3b42619c4d8686de upstream. If the driver's stripe information is invalid it can result in an integer underflow. Add a range check to avoid this kind of error. This patch fixes the following smatch error: drivers/staging/media/ipu3/ipu3-css-params.c:1792 imgu_css_cfg_acc_stripe() warn: 'acc->stripe.bds_out_stripes[0]->width - 2 * f' 4294967168 can't fit into 65535 'acc->stripe.bds_out_stripes[1]->offset' Cc: stable@vger.kernel.org Fixes: e11110a5b744 ("media: staging/intel-ipu3: css: Compute and program ccs") Signed-off-by: Ricardo Ribalda Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit e3ceafa6d8ee6b3a0f7fabe7a551fda909edbd46 Author: Hao-Qun Huang Date: Sat Jul 4 14:58:16 2026 +0800 staging: vme_user: fix location monitor leak in tsi148 bridge commit 151edde741f8bc7f2931c5f44ab376d32b0c8beb upstream. tsi148_probe() allocates a location monitor resource and links it into tsi148_bridge->lm_resources. The probe error path frees this list, but tsi148_remove() only frees the dma, slave and master resource lists, so the location monitor resource is leaked on device unbind or module unload. Free the lm_resources list in tsi148_remove() as well, before tsi148_bridge is freed. Fixes: d22b8ed9a3b0 ("Staging: vme: add Tundra TSI148 VME-PCI Bridge driver") Cc: stable Cc: Martyn Welch Assisted-by: Claude:claude-fable-5 Signed-off-by: Hao-Qun Huang Link: https://patch.msgid.link/20260704065817.403111-2-alvinhuang0603@gmail.com Signed-off-by: Greg Kroah-Hartman commit a9214863139751c291f691a64161cd11b1d8af0b Author: Hao-Qun Huang Date: Sat Jul 4 14:58:15 2026 +0800 staging: vme_user: fix location monitor leak in fake bridge commit e8422d89e8af41d87f0e9db564be8e2634f4c602 upstream. fake_init() allocates a location monitor resource and links it into fake_bridge->lm_resources. The init error path frees this list, but fake_exit() only frees the slave and master resource lists. Loading and unloading the module therefore triggers a kmemleak warning: unreferenced object 0xffff8b8b82aebe40 (size 64): comm "init", pid 1, jiffies 4294894572 backtrace (crc c1e013ef): kmemleak_alloc+0x4e/0x90 __kmalloc_cache_noprof+0x338/0x430 0xffffffffc0602246 do_one_initcall+0x4f/0x320 do_init_module+0x68/0x270 load_module+0x2a3b/0x2d90 Free the lm_resources list in fake_exit() as well, before fake_bridge is freed. Fixes: 658bcdae9c67 ("vme: Adding Fake VME driver") Cc: stable Cc: Martyn Welch Assisted-by: Claude:claude-fable-5 Signed-off-by: Hao-Qun Huang Link: https://patch.msgid.link/20260704065817.403111-1-alvinhuang0603@gmail.com Signed-off-by: Greg Kroah-Hartman commit ceb875a375dedbf51c9425c1d13a2d7a8435c08c Author: Shoichiro Miyamoto Date: Tue Jul 7 20:23:58 2026 +0900 smb: client: restrict implied bcc[0] exemption to responses without data area commit 53b7c271f06be4dd5cfc8c6ef552a8355c891a7f upstream. smb2_check_message() has a long-standing quirk that accepts a response whose calculated length is one byte larger than the bytes actually received ("server can return one byte more due to implied bcc[0]"). This was introduced to accommodate servers that omit the trailing bcc[0] overlap byte when no data area is present. However, the exemption is applied unconditionally, regardless of whether the command actually carries a data area (has_smb2_data_area[]). When a response with a data area is subject to the +1 exemption, the reported data can extend one byte beyond the bytes actually received, yet smb2_check_message() still accepts it. The subsequent decoder then reads past the end of the receive buffer. This is reachable during NEGOTIATE and SESSION_SETUP, before the session is established. The resulting out-of-bounds reads are visible under KASAN when mounting against a non-conforming server; both the SPNEGO/negTokenInit and the NTLMSSP challenge decoders are affected: BUG: KASAN: slab-out-of-bounds in asn1_ber_decoder+0x16a7/0x1b00 Read of size 1 at addr ffff8880084d67c0 by task mount.cifs/81 CPU: 1 UID: 0 PID: 81 Comm: mount.cifs Not tainted 7.1.0-rc6 #1 Call Trace: dump_stack_lvl+0x4e/0x70 print_report+0x157/0x4c9 kasan_report+0xce/0x100 asn1_ber_decoder+0x16a7/0x1b00 decode_negTokenInit+0x19/0x30 SMB2_negotiate+0x31d9/0x4c90 cifs_negotiate_protocol+0x1f2/0x3f0 cifs_get_smb_ses+0x93f/0x17e0 cifs_mount_get_session+0x7f/0x3a0 cifs_mount+0xb4/0xcf0 cifs_smb3_do_mount+0x23a/0x1500 smb3_get_tree+0x3b0/0x630 vfs_get_tree+0x82/0x2d0 fc_mount+0x10/0x1b0 path_mount+0x50d/0x1de0 __x64_sys_mount+0x20b/0x270 do_syscall_64+0xee/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 85: kmem_cache_alloc_noprof+0x106/0x380 mempool_alloc_noprof+0x116/0x1e0 cifs_small_buf_get+0x31/0x80 allocate_buffers+0x10d/0x2b0 cifs_demultiplex_thread+0x1d5/0x1d50 kthread+0x2c6/0x390 ret_from_fork+0x36e/0x5a0 ret_from_fork_asm+0x1a/0x30 The buggy address is located 0 bytes to the right of allocated 448-byte region [ffff8880084d6600, ffff8880084d67c0) which belongs to the cache cifs_small_rq of size 448 BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x36/0x50 Read of size 329 at addr ffff88800726c678 by task mount.cifs/89 CPU: 0 UID: 0 PID: 89 Comm: mount.cifs Tainted: G B 7.1.0-rc6 #1 Call Trace: dump_stack_lvl+0x4e/0x70 print_report+0x157/0x4c9 kasan_report+0xce/0x100 kasan_check_range+0x10f/0x1e0 __asan_memcpy+0x23/0x60 kmemdup_noprof+0x36/0x50 decode_ntlmssp_challenge+0x457/0x680 SMB2_sess_auth_rawntlmssp_negotiate+0x6f0/0xcb0 SMB2_sess_setup+0x219/0x4f0 cifs_setup_session+0x248/0xaf0 cifs_get_smb_ses+0xf79/0x17e0 cifs_mount_get_session+0x7f/0x3a0 cifs_mount+0xb4/0xcf0 cifs_smb3_do_mount+0x23a/0x1500 smb3_get_tree+0x3b0/0x630 vfs_get_tree+0x82/0x2d0 fc_mount+0x10/0x1b0 path_mount+0x50d/0x1de0 __x64_sys_mount+0x20b/0x270 do_syscall_64+0xee/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 93: kmem_cache_alloc_noprof+0x106/0x380 mempool_alloc_noprof+0x116/0x1e0 cifs_small_buf_get+0x31/0x80 allocate_buffers+0x10d/0x2b0 cifs_demultiplex_thread+0x1d5/0x1d50 kthread+0x2c6/0x390 ret_from_fork+0x36e/0x5a0 ret_from_fork_asm+0x1a/0x30 The buggy address is located 120 bytes inside of allocated 448-byte region [ffff88800726c600, ffff88800726c7c0) which belongs to the cache cifs_small_rq of size 448 Restrict the +1 exemption to responses that have no data area, so that it still covers the bcc[0] omission it was meant for. When a data area is present, the +1 discrepancy instead means the reported data length overruns the received buffer, so the response must be rejected. Fixes: 093b2bdad322 ("CIFS: Make demultiplex_thread work with SMB2 code") Cc: stable@vger.kernel.org Signed-off-by: Shoichiro Miyamoto Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit e99f2df433c63c86c93de1e5f08f16e404388756 Author: Michael Tautschnig Date: Thu Jun 18 13:47:09 2026 +0200 staging: vme_user: bound slave read/write to the kern_buf size commit 9f32f38265014fac7f5dc9490fb01a638ce6e121 upstream. The SLAVE-path helpers buffer_to_user() and buffer_from_user() copy 'count' bytes into/out of the fixed-size kern_buf (size_buf == PCI_BUF_SIZE == 0x20000, 128 KiB) using *ppos as the offset, without bounding *ppos + count against size_buf. vme_user_write()/vme_user_read() only clamp count to the VME window size (image_size = vme_get_size(resource)), which VME_SET_SLAVE sets from the user-supplied slave.size -- validated against the VME address space (up to VME_A32_MAX = 4 GiB), not against PCI_BUF_SIZE. When the window exceeds 128 KiB, a write()/read() copies past the kern_buf allocation. Clamp count against size_buf in both helpers, with an early return when *ppos is already at/after the buffer end. *ppos is >= 0 here (the caller rejects negative offsets), so size_buf - *ppos cannot wrap. This mirrors the existing clamp in the MASTER-path helpers resource_to_user() / resource_from_user(), and matches the read()/write() convention of a short transfer at end-of-buffer. Found by static analysis (CodeQL taint tracking + CBMC bounded model checking) and confirmed dynamically under KASAN with the vme_fake bridge: BUG: KASAN: slab-out-of-bounds in _copy_from_user+0x2d/0x80 Write of size 262144 at addr ffff888004100000 by task trigger/68 _copy_from_user+0x2d/0x80 vme_user_write+0x13e/0x240 [vme_user] vfs_write+0x1b8/0x7a0 ksys_write+0xb8/0x150 Fixes: f00a86d98a1e ("Staging: vme: add VME userspace driver") Cc: stable Signed-off-by: Michael Tautschnig Link: https://patch.msgid.link/20260618114709.72499-1-tautschn@amazon.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 2de42e268174766cb2e2b90721afdfdff70e0d8d Author: Samuel Page Date: Thu Jun 25 15:38:15 2026 +0100 tipc: fix out-of-bounds read in broadcast Gap ACK blocks commit 2b66974a1b6134a4bbc3bfed181f7418f688eb54 upstream. A broadcast PROTOCOL/STATE_MSG can carry a Gap ACK blocks record in its data area. tipc_get_gap_ack_blks() only verifies that the record's len field is self-consistent with its ugack_cnt/bgack_cnt counts (sz == struct_size(p, gacks, ugack_cnt + bgack_cnt)); it does not check that the record actually fits in the message data area, msg_data_sz(). The unicast caller tipc_link_proto_rcv() bounds it ("if (glen > dlen) break;"), but the broadcast caller tipc_bcast_sync_rcv() discards the returned size, so tipc_link_advance_transmq() copies the record off the receive skb with an attacker-controlled count: this_ga = kmemdup(ga, struct_size(ga, gacks, ga->bgack_cnt), GFP_ATOMIC); A TIPC neighbour that negotiated TIPC_GAP_ACK_BLOCK triggers it with one ordinary broadcast STATE_MSG (msg_bc_ack_invalid() clear), sized so its data area is short, carrying a Gap ACK record with len = 0x400, bgack_cnt = 0xff and ugack_cnt = 0. len then equals struct_size(p, gacks, 255), so the consistency check passes and ga is non-NULL; kmemdup() reads struct_size(ga, gacks, 255) = 1024 bytes out of the much smaller skb: BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x48/0x60 Read of size 1024 at addr ffff0000c7030d38 by task poc864/69 Call trace: kmemdup_noprof+0x48/0x60 tipc_link_advance_transmq+0x86c/0xb80 tipc_link_bc_ack_rcv+0x19c/0x1e0 tipc_bcast_sync_rcv+0x1c4/0x2c4 tipc_rcv+0x85c/0x1340 tipc_l2_rcv_msg+0xac/0x104 The buggy address belongs to the object at ffff0000c7030d00 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 56 bytes inside of allocated 704-byte region [ffff0000c7030d00, ffff0000c7030fc0) The copied-out bytes are subsequently consumed as gap/ack values, but the read is already out of bounds at the kmemdup() regardless of how they are used. The unicast STATE path drops such a message: "if (glen > dlen) break;" skips the rest of STATE_MSG handling and the skb is freed. Make the broadcast path drop it too. tipc_bcast_sync_rcv() now bounds the record against msg_data_sz() and, when it does not fit, reports it back through tipc_node_bc_sync_rcv() to tipc_rcv() so the skb is discarded rather than processed. ga is not cleared on this path: ga == NULL already means "legacy peer without Selective ACK", a distinct legitimate state. Fixes: d7626b5acff9 ("tipc: introduce Gap ACK blocks for broadcast link") Cc: stable@vger.kernel.org Signed-off-by: Samuel Page Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20260625143815.1525412-1-sam@bynar.io Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0beccbcf50de125be5520d0ffc59af4bb8655482 Author: Yizhou Zhao Date: Tue Jun 9 16:00:52 2026 +0800 6lowpan: fix NHC entry use-after-free on error path commit 1720db928e5a58ca7d75ac1d514c3b73fd7061a7 upstream. lowpan_nhc_do_uncompression() looks up an NHC descriptor while holding lowpan_nhc_lock. If the descriptor has no uncompress callback, the error path drops the lock before printing nhc->name. lowpan_nhc_del() removes descriptors under the same lock and then relies on synchronize_net() before the owning module can be unloaded. That only waits for net RX RCU readers. lowpan_header_decompress() is also exported and can be reached from callers that are not necessarily covered by the net core RX critical section, for example the Bluetooth 6LoWPAN L2CAP receive path. This leaves a race where one task drops lowpan_nhc_lock in the error path, another task unregisters and frees the matching descriptor after synchronize_net() returns, and the first task then dereferences nhc->name for the warning. With the post-unlock window widened, KASAN reports: BUG: KASAN: slab-use-after-free in lowpan_nhc_do_uncompression+0x1f4/0x220 Read of size 8 lowpan_nhc_do_uncompression lowpan_header_decompress Fix this by printing the warning before dropping lowpan_nhc_lock, so the descriptor name is read while unregister is still excluded. The malformed packet is still rejected with -ENOTSUPP. Fixes: 92aa7c65d295 ("6lowpan: add generic nhc layer interface") 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 Signed-off-by: Yizhou Zhao Acked-by: Alexander Aring Link: https://patch.msgid.link/20260609080054.4541-1-zhaoyz24@mails.tsinghua.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c40090f8d19b415e2925b22be964b5d1f695666f Author: Cen Zhang Date: Thu Jun 18 20:40:29 2026 +0800 usb: misc: usbio: fix disconnect UAF in client teardown commit 0bfeec21984fedd32987f4e4c0cde34b445af404 upstream. usbio_disconnect() walks usbio->cli_list in reverse and uninitializes each auxiliary device. auxiliary_device_uninit() drops the device reference, and for an unbound child that can run usbio_auxdev_release() and free the containing struct usbio_client. list_for_each_entry_reverse() advances after the loop body by reading client->link.prev. If the current client is freed by auxiliary_device_uninit(), the iterator dereferences freed memory. Use list_for_each_entry_safe_reverse() so the previous client is cached before the body can drop the final reference. This preserves reverse teardown order while keeping the next iterator cursor independent of the current client's lifetime. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in usbio_disconnect+0x12e/0x150 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ? usbio_disconnect+0x12e/0x150 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x188/0x320 ? usbio_disconnect+0x12e/0x150 kasan_report+0xe0/0x110 ? usbio_disconnect+0x12e/0x150 usbio_disconnect+0x12e/0x150 usb_unbind_interface+0xf3/0x400 really_probe+0x316/0x660 __driver_probe_device+0x106/0x240 driver_probe_device+0x4a/0x110 __device_attach_driver+0xf1/0x1a0 ? __pfx___device_attach_driver+0x10/0x10 bus_for_each_drv+0xf9/0x160 ? __pfx_bus_for_each_drv+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? trace_hardirqs_on+0x18/0x130 ? srso_alias_return_thunk+0x5/0xfbef5 ? _raw_spin_unlock_irqrestore+0x44/0x60 __device_attach+0x133/0x2a0 ? __pfx___device_attach+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_raw_spin_unlock+0x9a/0x100 ? srso_alias_return_thunk+0x5/0xfbef5 device_initial_probe+0x55/0x70 bus_probe_device+0x4a/0xd0 device_add+0x9b9/0xc10 ? __pfx_device_add+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x44/0x60 ? srso_alias_return_thunk+0x5/0xfbef5 ? lockdep_hardirqs_on_prepare+0xea/0x1a0 ? srso_alias_return_thunk+0x5/0xfbef5 ? usb_enable_lpm+0x3c/0x260 usb_set_configuration+0xb64/0xf20 usb_generic_driver_probe+0x5f/0x90 usb_probe_device+0x71/0x1b0 really_probe+0x46b/0x660 __driver_probe_device+0x106/0x240 driver_probe_device+0x4a/0x110 __device_attach_driver+0xf1/0x1a0 ? __pfx___device_attach_driver+0x10/0x10 bus_for_each_drv+0xf9/0x160 ? __pfx_bus_for_each_drv+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? trace_hardirqs_on+0x18/0x130 ? srso_alias_return_thunk+0x5/0xfbef5 ? _raw_spin_unlock_irqrestore+0x44/0x60 __device_attach+0x133/0x2a0 ? __pfx___device_attach+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_raw_spin_unlock+0x9a/0x100 ? srso_alias_return_thunk+0x5/0xfbef5 device_initial_probe+0x55/0x70 bus_probe_device+0x4a/0xd0 device_add+0x9b9/0xc10 ? __pfx_device_add+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? add_device_randomness+0xb7/0xf0 usb_new_device+0x492/0x870 hub_event+0x1b10/0x29c0 ? __pfx_hub_event+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_acquire+0x187/0x300 ? process_one_work+0x475/0xb90 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_release+0xc8/0x290 ? srso_alias_return_thunk+0x5/0xfbef5 process_one_work+0x4d7/0xb90 ? __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_hub_event+0x10/0x10 ? 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 Fixes: 121a0f839dbb ("usb: misc: Add Intel USBIO bridge driver") Cc: stable Assisted-by: Codex:gpt-5.5 Signed-off-by: Cen Zhang Reviewed-by: Hans de Goede Acked-by: Sakari Ailus Link: https://patch.msgid.link/20260618124029.3704089-1-zzzccc427@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit c4e232bd07fe2b69a6e5c380db41dd36b95e0524 Author: Runyu Xiao Date: Fri Jun 12 13:20:05 2026 +0800 usb: dwc3: run gadget disconnect from sleepable suspend context commit 010382937fb69892b3469ac4d30af072262f59e8 upstream. dwc3_gadget_suspend() takes dwc->lock with IRQs disabled and then calls dwc3_disconnect_gadget(). For async callbacks that helper only uses plain spin_unlock()/spin_lock(), so the gadget ->disconnect() callback still runs with IRQs disabled and any sleepable callback trips Lockdep. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the dwc3_gadget_suspend() -> dwc3_disconnect_gadget() -> gadget_driver->disconnect() chain, and Lockdep reported: BUG: sleeping function called from invalid context gadget_disconnect+0x21/0x39 [vuln_msv] dwc3_gadget_suspend.constprop.0+0x2b/0x42 [vuln_msv] Keep the disconnect callback selection in one common helper, but add a sleepable suspend-side wrapper which snapshots the callback under dwc->lock and then runs it after spin_unlock_irqrestore(). The regular event path still uses the existing spin_unlock()/spin_lock() window. Fixes: c8540870af4c ("usb: dwc3: gadget: Improve dwc3_gadget_suspend() and dwc3_gadget_resume()") Cc: stable Signed-off-by: Runyu Xiao Acked-by: Thinh Nguyen Link: https://patch.msgid.link/20260612052005.3849659-1-runyu.xiao@seu.edu.cn Signed-off-by: Greg Kroah-Hartman commit 2a52d55c86a429dac47886b8424e67f90b001e67 Author: Alan Stern Date: Tue Jun 9 13:37:36 2026 -0400 USB: chaoskey: Fix slab-use-after-free in chaoskey_release() commit abf76d3239dee97b66e7241ad04811f1ce562e28 upstream. The chaoskey driver has a use-after-free bug in its release routine. If the user closes the device file after the USB device has been unplugged, a debugging log statement will try to access the usb_interface structure after it has been deallocated: BUG: KASAN: slab-use-after-free in dev_driver_string (drivers/base/core.c:2406) Read of size 8 at addr ffff888168e8a0b8 by task chaoskey_raw_re/10106 Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) dev_driver_string (drivers/base/core.c:2406) __dynamic_dev_dbg (lib/dynamic_debug.c:906) chaoskey_release (drivers/usb/misc/chaoskey.c:323) __fput (fs/file_table.c:510) fput_close_sync (fs/file_table.c:615) __x64_sys_close (fs/open.c:1507 fs/open.c:1492 fs/open.c:1492) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The driver's last reference to the interface structure is dropped in the chaoskey_free() routine, so the code must not use the interface -- even in a debugging statement -- after that routine returns. (Exception: If we know that another reference is held by someone else, such as the device core while the disconnect routine runs, there's no problem. Thanks to Johan Hovold for pointing this out.) Since the bad access is part of an unimportant debugging statement, we can fix the problem simply by removing the whole statement. Reported-by: Shuangpeng Bai Closes: https://lore.kernel.org/linux-usb/20EC9664-054E-438B-B411-2145D347F97B@gmail.com/ Tested-by: Shuangpeng Bai Signed-off-by: Alan Stern Fixes: 66e3e591891d ("usb: Add driver for Altus Metrum ChaosKey device (v2)") Cc: stable Reviewed-by: Johan Hovold Link: https://patch.msgid.link/bb5b1dc6-eb59-43e1-8d26-51e658e88bbe@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman commit 285e17c44e3873a73460f294acbd64018ff64385 Author: Michael Bommarito Date: Sun May 31 10:22:51 2026 -0400 hwrng: virtio: clamp device-reported used.len at copy_data() commit e3046eeada299f917a8ad883af4434bfb86556b1 upstream. random_recv_done() stores the device-reported used.len directly into vi->data_avail. copy_data() then indexes vi->data[] using vi->data_idx (advanced by previous copy_data() calls) and issues a memcpy() without re-validating either value against the posted buffer size sizeof(vi->data) (SMP_CACHE_BYTES bytes, typically 32 or 64). A malicious or buggy virtio-rng backend can set used.len beyond sizeof(vi->data), steering the memcpy() past the end of the inline array into adjacent kmalloc-1k slab bytes. hwrng_fillfn() mixes those bytes into the guest RNG, and guest root can also observe them directly via /dev/hwrng. Concrete impact is inside the guest: - Memory-safety / hardening: any virtio-rng backend that over-reports used.len causes the driver to read past vi->data into unrelated slab contents. hwrng_fillfn() is a kernel thread that runs as soon as the device is probed; no guest userspace interaction is required to first-trigger the OOB. - Cross-boundary leak (confidential-compute threat model): a malicious hypervisor cooperating with a malicious or compromised guest root userspace can use /dev/hwrng as a leak channel for guest-kernel heap data. The host sets a large used.len, guest root reads /dev/hwrng, and the returned bytes contain guest kernel slab contents that were adjacent to vi->data. In practice, confidential-compute guests (SEV-SNP, TDX) usually disable virtio-rng entirely, so this path is narrow, but the fix is still worth carrying because the underlying memory-safety bug contaminates the guest RNG on any host. KASAN confirms the OOB on a 7.1-rc4 guest whose virtio-rng backend has been patched to report used.len = 0x10000: BUG: KASAN: slab-out-of-bounds in virtio_read+0x394/0x5d0 Read of size 64 at addr ffff88800ae0ba20 by task hwrng/52 Call Trace: __asan_memcpy+0x23/0x60 virtio_read+0x394/0x5d0 hwrng_fillfn+0xb2/0x470 kthread+0x2cc/0x3a0 Allocated by task 1: probe_common+0xa5/0x660 virtio_dev_probe+0x549/0xbc0 The buggy address belongs to the object at ffff88800ae0b800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 0 bytes to the right of allocated 544-byte region [ffff88800ae0b800, ffff88800ae0ba20) Same class of bug as commit c04db81cd028 ("net/9p: Fix buffer overflow in USB transport layer"), which hardened usb9pfs_rx_complete() against unchecked device-reported length in the USB 9p transport. With the clamp at point of use and array_index_nospec() in place, the same harness boots cleanly: copy_data() returns zero for the bogus report, the device-supplied bytes after data_idx are discarded, and the driver issues a fresh request. Fixes: f7f510ec1957 ("virtio: An entropy device, as suggested by hpa.") Cc: stable@vger.kernel.org Suggested-by: Michael S. Tsirkin Signed-off-by: Michael Bommarito Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael S. Tsirkin Message-ID: <20260531142251.2792061-1-michael.bommarito@gmail.com> Signed-off-by: Greg Kroah-Hartman commit 65e93ec592f5b1eb0e9dec47d44011c3fd4938e6 Author: Johan Hovold Date: Mon Apr 27 16:37:10 2026 +0200 virtio-mmio: fix device release warning on module unload commit c687bc35694698ec4c7f92bf929c3d659f0cecb8 upstream. Driver core expects devices to be allocated dynamically and complains loudly when a device that lacks a release function is freed. Use __root_device_register() to allocate and register the root device instead of open coding using a static device. Note that root_device_register(), which also creates a link to the module, cannot be used as the device is registered when parsing the module parameters which happens before the module kobject has been set up. Fixes: 81a054ce0b46 ("virtio-mmio: Devices parameter parsing") Cc: stable@vger.kernel.org # 3.5 Cc: Pawel Moll Signed-off-by: Johan Hovold Signed-off-by: Michael S. Tsirkin Message-ID: <20260427143710.14702-1-johan@kernel.org> Signed-off-by: Greg Kroah-Hartman commit 075bc3c779e1ea7294afabdcb7e0a49536959b28 Author: Ammar Faizi Date: Sun Mar 15 21:18:08 2026 +0700 virtio_pci: fix vq info pointer lookup via wrong index commit f7d380fb525c13bdd114369a1979c80c346e6abc upstream. Unbinding a virtio balloon device: echo virtio0 > /sys/bus/virtio/drivers/virtio_balloon/unbind triggers a NULL pointer dereference. The dmesg says: BUG: kernel NULL pointer dereference, address: 0000000000000008 [...] RIP: 0010:__list_del_entry_valid_or_report+0x5/0xf0 Call Trace: vp_del_vqs+0x121/0x230 remove_common+0x135/0x150 virtballoon_remove+0xee/0x100 virtio_dev_remove+0x3b/0x80 device_release_driver_internal+0x187/0x2c0 unbind_store+0xb9/0xe0 kernfs_fop_write_iter.llvm.11660790530567441834+0xf6/0x180 vfs_write+0x2a9/0x3b0 ksys_write+0x5c/0xd0 do_syscall_64+0x54/0x230 entry_SYSCALL_64_after_hwframe+0x29/0x31 [...] The virtio_balloon device registers 5 queues (inflate, deflate, stats, free_page, reporting) but only the first two are unconditional. The stats, free_page and reporting queues are each conditional on their respective feature bits. When any of these features are absent, the corresponding vqs_info entry has name == NULL, creating holes in the array. The root cause is an indexing mismatch introduced when vq info storage was changed to be passed as an argument. vp_find_vqs_msix() and vp_find_vqs_intx() store the info pointer at vp_dev->vqs[i], where 'i' is the caller's sparse array index. However, the virtqueue itself gets vq->index assigned from queue_idx, a dense index that skips NULL entries. When holes exist, 'i' and queue_idx diverge. Later, vp_del_vqs() looks up info via vp_dev->vqs[vq->index] using the dense index into the sparsely-populated array, and hits NULL. Fix this by storing info at vp_dev->vqs[queue_idx] instead of vp_dev->vqs[i], so the store index matches the lookup index (vq->index). Apply the fix to both the MSIX and INTX paths. Cc: Yichun Zhang Cc: Jiri Pirko Cc: stable@vger.kernel.org # v6.11+ Tested-by: Yuka Fixes: 89a1c435aec2 ("virtio_pci: pass vq info as an argument to vp_setup_vq()") Signed-off-by: Ammar Faizi Message-Id: <20260315141808.547081-1-ammarfaizi2@openresty.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit 81d54c766337b923eec26da0a13406760b091093 Author: Xiang Mei Date: Wed Jun 24 18:00:06 2026 -0700 netfilter: ipset: fix race between dump and ip_set_list resize commit 7cd9103283b26b917360ec99d7d2f2d761bcf1ab upstream. The release path of ip_set_dump_do() and ip_set_dump_done() read inst->ip_set_list via ip_set_ref_netlink(), a plain rcu_dereference_raw() of the array pointer. These run from netlink_recvmsg() without the nfnl mutex and without an RCU read-side critical section. A concurrent ip_set_create() can grow the array: it publishes the new array, calls synchronize_net() and then kvfree()s the old one. Since the dump paths read the array outside any RCU reader, synchronize_net() does not wait for them and the old array can be freed while they still index into it, causing a use-after-free. The dumped set itself stays pinned via set->ref_netlink, so only the array load needs protecting. Take rcu_read_lock() around it, matching ip_set_get_byname() and __ip_set_put_byindex(). BUG: KASAN: slab-use-after-free in ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697) Read of size 8 at addr ffff88800b5c4018 by task exploit/150 Call Trace: ... kasan_report (mm/kasan/report.c:595) ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697) netlink_dump (net/netlink/af_netlink.c:2325) netlink_recvmsg (net/netlink/af_netlink.c:1976) sock_recvmsg (net/socket.c:1159) __sys_recvfrom (net/socket.c:2315) ... Oops: general protection fault, probably for non-canonical address ... KASAN NOPTI KASAN: maybe wild-memory-access in range [0x02d6...d0-0x02d6...d7] RIP: 0010:ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1698) Kernel panic - not syncing: Fatal exception Fixes: 8a02bdd50b2e ("netfilter: ipset: Fix calling ip_set() macro at dumping") Cc: stable@vger.kernel.org Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Acked-by: Jozsef Kadlecsik Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit 9c8f31eaae6140ecadec0c07320498a944556de2 Author: SeongJae Park Date: Tue Jun 23 06:58:31 2026 -0700 mm/damon/ops-common: handle extreme intervals in damon_hot_score() commit 35d4a3cf70a855b50e53189ac2f8463e20a02046 upstream. Fix three issues in damon_hot_score() that comes from wrong handling of extreme (zero or too high) monitoring intervals user setup. When the user sets sampling interval zero, damon_max_nr_accesses(), which is called from damon_hot_score(), causes a divide-by-zero. Needless to say, it is a problem. When the user sets the aggregation interval zero, the function returns zero. It is wrong, since the real maximum nr_acceses in the setup should be one. Worse yet, it can cause another divide-by-zero from its caller, damon_hot_score(), since it uses damon_max_nr_accesses() return value as a denominator. When the user sets the aggregation interval very high, damon_hot_score() could return a value out of [0, DAMOS_MAX_SCORE] range. Since the return value is used as an index to the regions_score_histogram array, which is DAMOS_MAX_SCORE+1 size, it causes out of bounds array access. The issues can be relatively easily reproduced like below. The sysfs write permission is required, though. # ./damo start --damos_action lru_prio --damos_quota_space 100M \ --damos_quota_interval 1s # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/monitoring_attrs/intervals/sample_us # echo 0 > contexts/0/monitoring_attrs/intervals/aggr_us # echo commit > state # dmesg [...] [ 131.329762] Oops: divide error: 0000 [#1] SMP NOPTI [...] [ 131.336089] RIP: 0010:damon_hot_score+0x27/0xd0 [...] Fix the divide-by-zero intervals problems by explicitly handling the zero intervals in damon_max_nr_accesses(). Fix the out-of-bound array access by applying [0, DAMOS_MAX_SCORE] bounds before returning from damon_hot_score(). The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260623135834.67189-1-sj@kernel.org Link: https://lore.kernel.org/20260619202459.145010-1-sj@kernel.org [1] Fixes: 198f0f4c58b9 ("mm/damon/vaddr,paddr: support pageout prioritization") Signed-off-by: SeongJae Park Cc: # 5.16.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 657646c08c94ef7b9dbe468fe7828032216f9841 Author: Michael Bommarito Date: Thu Jun 25 19:21:39 2026 +0100 tcp: restore RCU grace period in tcp_ao_destroy_sock commit 8bc4d43bccbd60efe85d0a44d5bf41762f2f0c30 upstream. Commit 51e547e8c89c ("tcp: Free TCP-AO/TCP-MD5 info/keys without RCU") removed the call_rcu() callback from tcp_ao_destroy_sock(), arguing that "the destruction of info/keys is delayed until the socket destructor" and therefore "no one can discover it anymore". That argument does not hold for the call site in tcp_connect() (net/ipv4/tcp_output.c:4327-4332). At that point the socket is in TCP_SYN_SENT, has already been inserted into the inet ehash by inet_hash_connect() in tcp_v4_connect(), and is therefore very much discoverable: any softirq running tcp_v4_rcv() on another CPU can take the socket out of the ehash, walk into tcp_inbound_hash(), and load tp->ao_info via implicit RCU before bh_lock_sock_nested() is taken on the destroying CPU. The reader path then enters __tcp_ao_do_lookup() (net/ipv4/tcp_ao.c:208) which re-loads tp->ao_info via rcu_dereference_check(); the re-load can still observe the (about-to-be-freed) pointer because there is no synchronize_rcu() between rcu_assign_pointer(tp->ao_info, NULL) and tcp_ao_info_free() in tcp_ao_destroy_sock(). The captured pointer is then walked at line 223: hlist_for_each_entry_rcu(key, &ao->head, node, ...) The writer's synchronous kfree() is free to complete between the line 218 re-fetch and the line 223 hlist iteration. The slab is reused (or simply LIST_POISON1-stamped if not yet reused) and the iteration walks attacker-controlled or poison memory in softirq context. Reproducer (no debug shim, stock x86_64 v7.1-rc2 SMP+KASAN, QEMU+KVM): an unprivileged uid=1000 process inside CLONE_NEWUSER|CLONE_NEWNET installs TCP_MD5SIG + TCP_AO_ADD_KEY on a TCP socket, sprays forged TCP-AO segments toward its eventual 4-tuple via raw sockets, then calls connect(). The md5-wins reconciliation in tcp_connect() fires tcp_ao_destroy_sock(); the softirq backlog reader on the loopback NAPI path crashes on the freed ao->head.first walk: Oops: general protection fault, probably for non-canonical address 0xfbd59c000000002f KASAN: maybe wild-memory-access in range [0xdead000000000178-0xdead00000000017f] CPU: 0 UID: 1000 PID: 100 Comm: repro_userns RIP: 0010:__tcp_ao_do_lookup+0x107/0x1c0 Call Trace: __tcp_ao_do_lookup+0x107/0x1c0 tcp_ao_inbound_lookup.constprop.0+0x12a/0x200 tcp_inbound_ao_hash+0x5ea/0x1520 tcp_inbound_hash+0x7ce/0x1240 tcp_v4_rcv+0x1e7a/0x3e10 ... Restore the RCU grace period: re-add struct rcu_head to tcp_ao_info and replace the synchronous tcp_ao_info_free() with a call_rcu() callback. Readers that captured tp->ao_info before rcu_assign_pointer NULLed it now see the object remain valid until rcu_read_unlock(). With the patch applied the reproducer runs cleanly for 2000 iterations on the same kernel build. Fixes: 51e547e8c89c ("tcp: Free TCP-AO/TCP-MD5 info/keys without RCU") Cc: stable@vger.kernel.org # v6.18+ Reviewed-by: Dmitry Safonov Signed-off-by: Michael Bommarito Reviewed-by: Eric Dumazet Signed-off-by: Dmitry Safonov <0x7f454c46@gmail.com> Link: https://patch.msgid.link/20260625-tcp-md5-connect-v3-1-1fd313d6c1e0@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b77524621250407386f44c6eea7e5e4619ada1ce Author: Marco Nenciarini Date: Fri Apr 17 15:24:37 2026 +0200 PCI/IOV: Skip VF Resizable BAR restore on read error commit f34f1712229d71ce4286440fef12526fd4590b37 upstream. sriov_restore_vf_rebar_state() uses the VF Resizable BAR Control register to decide how many VF BARs to restore (nbars) and which VF BAR each iteration addresses (bar_idx). bar_idx indexes into dev->sriov->barsz[], which has only PCI_SRIOV_NUM_BARS (6) entries. When a device does not respond, config reads typically return PCI_ERROR_RESPONSE (~0). Both fields are 3 bits wide, so nbars and bar_idx both evaluate to 7. The barsz[] access then goes out of bounds. UBSAN reports this as: UBSAN: array-index-out-of-bounds in drivers/pci/iov.c:948:51 index 7 is out of range for type 'resource_size_t [6]' Observed on an NVIDIA RTX PRO 1000 GPU (GB207GLM) that stopped responding during a failed GC6 power state exit. The subsequent pci_restore_state() invoked sriov_restore_vf_rebar_state() while config reads returned 0xffffffff, triggering the splat. Bail out if any VF Resizable BAR Control read returns PCI_ERROR_RESPONSE. No further VF BARs are touched, which is safe because a config read that returns PCI_ERROR_RESPONSE indicates the device is unreachable and restoration is pointless. This mirrors the guard in pci_restore_rebar_state(). Fixes: 5a8f77e24a30 ("PCI/IOV: Restore VF resizable BAR state after reset") Signed-off-by: Marco Nenciarini Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/44a4ae53ec2825816b816c85cd378430d9a95cc6.1776429882.git.mnencia@kcore.it Signed-off-by: Greg Kroah-Hartman commit 1115680bca1d748ce887ec4b0ad1012714231479 Author: Yadu M G Date: Thu Jun 4 17:54:18 2026 +0530 PCI: qcom: Initialize DWC MSI lock for firmware-managed ECAM hosts commit e0779713a1e2f891aeec53e629dbbd33f423c629 upstream. A lockdep warning is observed during boot on a Qcom firmware-managed platform: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. ... Call trace: register_lock_class+0x128/0x4d8 __lock_acquire+0x110/0x1db0 lock_acquire+0x278/0x3d8 _raw_spin_lock_irq+0x6c/0xc0 dw_pcie_irq_domain_alloc+0x48/0x190 irq_domain_alloc_irqs_parent+0x2c/0x48 msi_domain_alloc+0x90/0x160 ... dw_pcie_irq_domain_alloc() takes pp->lock while allocating MSI interrupts. pp->lock is normally initialized by dw_pcie_host_init(), but Qcom firmware-managed hosts use the ECAM init path instead: pci_host_common_ecam_create() pci_ecam_create() qcom_pcie_ecam_host_init() dw_pcie_msi_host_init() dw_pcie_allocate_domains() That path constructs a fresh struct dw_pcie_rp and calls dw_pcie_msi_host_init() directly, without going through dw_pcie_host_init(). As a result, pp->lock was not initialized, which triggers the warning. Initialize pp->lock in qcom_pcie_ecam_host_init() before registering the MSI domains so the firmware-managed ECAM path matches the normal DWC host initialization sequence. Fixes: 7d944c0f1469 ("PCI: qcom: Add support for Qualcomm SA8255p based PCIe Root Complex") Signed-off-by: Yadu M G [mani: added fixes tag and CCed stable] Signed-off-by: Manivannan Sadhasivam Cc: stable@kernel.org Link: https://patch.msgid.link/20260604122418.727274-1-yadu.mg@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit 6e6a529d6f779413379b4404c9ef6a36c0337225 Author: Manivannan Sadhasivam Date: Thu May 21 23:16:17 2026 +0530 PCI: mediatek: Fix IRQ domain leak when port fails to enable commit f865a57896bd92d7662eb2818d8f48872e2cbbc7 upstream. When mtk_pcie_enable_port() fails, mtk_pcie_port_free() removes the port from pcie->ports and frees the port structure. However, the IRQ domains set up earlier by mtk_pcie_init_irq_domain() are never freed. Fix this by refactoring mtk_pcie_irq_teardown() into a per-port helper, mtk_pcie_irq_teardown_port(), and calling it from mtk_pcie_setup() when mtk_pcie_enable_port() fails. Since the IRQ teardown must only happen in the probe error path (during resume, child devices may have active MSI mappings and the NOIRQ context prohibits sleeping locks), mtk_pcie_enable_port() is changed to return an error code so callers can distinguish the two paths and act accordingly. This issue was reported by Sashiko while reviewing the EcoNet EN7528 SoC support series. Fixes: b099631df160 ("PCI: mediatek: Add controller support for MT2712 and MT7622") Signed-off-by: Manivannan Sadhasivam Signed-off-by: Manivannan Sadhasivam Cc: stable@vger.kernel.org # 5.10 Cc: Caleb James DeLisle Link: https://patch.msgid.link/20260521174617.17692-1-mani@kernel.org Signed-off-by: Greg Kroah-Hartman commit 69416a5308675ab6d4e22a83f14048a5cc02e9bb Author: Richard Zhu Date: Thu Mar 19 17:08:44 2026 +0800 PCI: imx6: Fix IMX6SX_GPR12_PCIE_TEST_POWERDOWN handling commit aad953fb4eed0df5486cd54ccad80ac197678e01 upstream. The IMX6SX_GPR12_PCIE_TEST_POWERDOWN bit does not control the PCIe reference clock on i.MX6SX. Instead, it is part of i.MX6SX PCIe core reset sequence. Move the IMX6SX_GPR12_PCIE_TEST_POWERDOWN assertion/deassertion into the core reset functions to properly reflect its purpose. Remove the .enable_ref_clk() callback for i.MX6SX since it was incorrectly manipulating this bit. Fixes: e3c06cd063d6 ("PCI: imx6: Add initial imx6sx support") Signed-off-by: Richard Zhu Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Frank Li Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260319090844.444987-1-hongxing.zhu@nxp.com Signed-off-by: Greg Kroah-Hartman commit 1d2e66a4bc0dd6c1f6f2f28247450e4d4ce7f5ba Author: Ratheesh Kannoth Date: Tue Apr 14 13:47:30 2026 +0530 PCI: host-common: Request bus reassignment when not probe-only commit fda8749ba73638f5bbca3ffb39bc6861eb3b23fa upstream. pci_host_common_init() is used by several generic ECAM host drivers. After PCI core changes around pci_flags and preserve_config, these hosts no longer opted into full bus number reassignment the way they did before, which broke enumeration of devices on a Marvell CN106XX board. When PCI_PROBE_ONLY is not set, add PCI_REASSIGN_ALL_BUS so pci_scan_bridge_extend() takes the reassignment path: bus numbers can be assigned from firmware EA data (e.g. pci_ea_fixed_busnrs()). Skip the flag in probe-only mode so existing assignments are not overridden. Fixes: 7246a4520b4b ("PCI: Use preserve_config in place of pci_flags") Closes: https://lore.kernel.org/all/abkqm_LCd9zAM8cW@rkannoth-OptiPlex-7090/ Signed-off-by: Ratheesh Kannoth [mani: added stable tag] Signed-off-by: Manivannan Sadhasivam [bhelgaas: add problem report link] Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Cc: Vidya Sagar Link: https://patch.msgid.link/20260414081730.3864372-1-rkannoth@marvell.com Signed-off-by: Greg Kroah-Hartman commit 9c698af5c2a12035d093244ca37e3c0971fd05e4 Author: Maciej W. Rozycki Date: Mon Dec 8 19:24:29 2025 +0000 PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining commit 72780f7964684939d7d2f69c348876213b184484 upstream. Discard Vendor:Device ID matching in the PCIe failed link retraining quirk and ignore the link status for the removal of the 2.5GT/s speed clamp, whether applied by the quirk itself or the firmware earlier on. Revert to the original target link speed if this final link retraining has failed. This is so that link training noise in hot-plug scenarios does not make a link remain clamped to the 2.5GT/s speed where an event race has led the quirk to apply the speed clamp for one device, only to leave it in place for a subsequent device to be plugged in. Refer to the Link Capabilities register directly for the maximum link speed determination so as to streamline backporting. Fixes: a89c82249c37 ("PCI: Work around PCIe link training failures") Signed-off-by: Maciej W. Rozycki Signed-off-by: Bjorn Helgaas Tested-by: Alok Tiwari Cc: stable@vger.kernel.org # v6.5+ Link: https://patch.msgid.link/alpine.DEB.2.21.2512080331530.49654@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman commit 09c43b7b7d29c6fadb27f32cdf7f3bb6598befa9 Author: Mahesh Vaidya Date: Thu Apr 30 13:43:30 2026 -0700 PCI: altera: Fix resource leaks on probe failure commit 7a94138caeb27f3c49c1dbd93bf422098925bb28 upstream. The chained IRQ handler is set during probe, but is only removed during the driver remove(). If pci_host_probe() fails, the handler and INTx IRQ domain remain set even though the devm-managed host bridge storage containing struct altera_pcie will be released, leaving the handler with a stale data pointer. Interrupts are also enabled before pci_host_probe() is called. If probe fails after that point, the controller interrupt source should be disabled before the chained handler and INTx domain are removed. So set the chained handler only after the INTx domain has been created. Disable controller interrupts during IRQ teardown, and tear the IRQ setup down if pci_host_probe() fails. Fixes: c63aed7334c2 ("PCI: altera: Use pci_host_probe() to register host") Signed-off-by: Mahesh Vaidya [mani: commit log] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Subhransu S. Prusty Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260430204330.3121003-3-mahesh.vaidya@altera.com Signed-off-by: Greg Kroah-Hartman commit 5e42a981887d24580c19bee1ba99a5292e572713 Author: Mahesh Vaidya Date: Thu Apr 30 13:43:29 2026 -0700 PCI: altera: Do not dispose parent IRQ mapping commit 5ef4bac02189bee0b7c170e352d7a38e13fe9678 upstream. altera_pcie_irq_teardown() calls irq_dispose_mapping() on pcie->irq. However, pcie->irq is the parent IRQ returned by platform_get_irq(), not the mapping created by Altera INTx irq_domain. The Altera driver only sets the chained handler on the parent IRQ. It should detach that handler during teardown, but it should not dispose the parent IRQ mapping, which belongs to the parent interrupt controller's irq_domain. Drop irq_dispose_mapping(pcie->irq) from the teardown path. Note that during irqchip remove(), the child IRQs should've disposed. But since the chained handler itself is removed, there is no way the stale child IRQs (if exists) could fire. So it is safe here. Fixes: ec15c4d0d5d2 ("PCI: altera: Allow building as module") Signed-off-by: Mahesh Vaidya [mani: added a note about IRQ disposal] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Subhransu S. Prusty Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260430204330.3121003-2-mahesh.vaidya@altera.com Signed-off-by: Greg Kroah-Hartman commit d666c5aec822d42e8a26dce29eddfdf6d154b169 Author: Ziyao Li Date: Sun Apr 12 18:17:31 2026 +0800 PCI: loongson: Override PCIe bridge supported speeds for Loongson-3C6000 series commit e373c789bac0ad73b472d8b44714df3bd18a4edf upstream. Older steppings of the Loongson-3C6000 series incorrectly report the supported link speeds on their PCIe bridges (device IDs 0x3c19, 0x3c29) as only 2.5 GT/s, despite the upstream bus supporting speeds from 2.5 GT/s up to 16 GT/s. As a result, since commit 774c71c52aa4 ("PCI/bwctrl: Enable only if more than one speed is supported"), bwctrl will be disabled if there's only one 2.5 GT/s value in vector 'supported_speeds'. Manually override the 'supported_speeds' field for affected PCIe bridges with those found on the upstream bus to correctly reflect the supported link speeds. Updating the speeds to reflect what the hardware actually supports avoids quirks in drivers consuming the speed information. This commit was originally found from AOSC OS[1]. Fixes: cd89edda4002 ("PCI: loongson: Add ACPI init support") Signed-off-by: Ayden Meng Signed-off-by: Mingcong Bai [Ziyao Li: move from drivers/pci/quirks.c to drivers/pci/controller/pci-loongson.c] Signed-off-by: Ziyao Li [Xi Ruoyao: Fixed falling through logic, added debug log, Fixes tag and rebased to 7.0-rc7] Signed-off-by: Xi Ruoyao Signed-off-by: Manivannan Sadhasivam [bhelgaas: commit log, https://lore.kernel.org/all/9d815df3b33a63223112b97440c01247935363c1.camel@xry111.site] Signed-off-by: Bjorn Helgaas Tested-by: Lain Fearyncess Yang Tested-by: Ayden Meng Tested-by: Mingcong Bai Reviewed-by: Huacai Chen Cc: stable@vger.kernel.org Link: https://github.com/AOSC-Tracking/linux/commit/4392f441363abdf6fa0a0433d73175a17f493454 Link: https://github.com/AOSC-Tracking/linux/pull/2 #1 Link: https://patch.msgid.link/20260412101731.107059-1-xry111@xry111.site Signed-off-by: Greg Kroah-Hartman commit e5406c8fb71cd2f89a46300a746f6e7972e621e8 Author: Myeonghun Pak Date: Mon Jul 6 23:53:12 2026 +0900 usb: typec: tcpci_rt1711h: unregister TCPCI port with devres commit e8da46d99d3710106e7c44db14566bf9b57386b5 upstream. rt1711h_probe() registers the TCPCI port before requesting the interrupt and enabling alert interrupts. If either of those later steps fails, the probe function returns without unregistering the TCPCI port. The explicit unregister currently only happens from the remove callback. Register a devres action immediately after tcpci_register_port() succeeds, so tcpci_unregister_port() runs on later probe failures and on driver detach. Drop the remove callback to avoid unregistering the same port twice. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 302c570bf36e ("usb: typec: tcpci_rt1711h: avoid screaming irq causing boot hangs") Cc: stable Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Link: https://patch.msgid.link/20260706145312.37260-1-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit 99d00a9e35e311a91d258029d5bb584377296c34 Author: Xu Rao Date: Fri Jul 3 17:40:32 2026 +0300 xhci: sideband: fix ring sg table pages leak commit 49f6e3c3ef19f04f6657ed8dce550e36c763abb8 upstream. xhci_ring_to_sgtable() allocates a temporary pages array and uses it to build the returned sg_table with sg_alloc_table_from_pages(). The error paths free the pages array, but the success path returns the sg_table without freeing it. This leaks the temporary array every time a sideband client gets an endpoint or event ring buffer. Free the pages array after sg_alloc_table_from_pages() succeeds. The returned sg_table has its own scatterlist entries and does not depend on the temporary array after construction. Fixes: de66754e9f80 ("xhci: sideband: add initial api to register a secondary interrupter entity") Cc: stable Signed-off-by: Xu Rao Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20260703144033.483286-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit f90586129cf9e1fbdb718ef602eea3f15dc1c31c Author: 胡连勤 Date: Fri Jul 3 17:40:33 2026 +0300 usb: xhci: Fix sleep in atomic context in xhci_free_streams() commit 42c37c4b75d38b51d84f31a8e29427f5e06a7c2a upstream. When a USB device with active stream endpoints is disconnected, xhci_free_streams() is called from the hub_event workqueue to free the stream resources. It calls xhci_free_stream_info() while holding xhci->lock with irqs disabled. xhci_free_stream_info() invokes xhci_free_stream_ctx(), which calls dma_free_coherent() for large stream context arrays. dma_free_coherent() can sleep (e.g. via vunmap), triggering a BUG when called from atomic context. Call trace: dma_free_attrs+0x174/0x220 xhci_free_stream_info+0xd0/0x11c xhci_free_streams+0x278/0x37c usb_free_streams+0x98/0xc0 usb_unbind_interface+0x1b8/0x2f8 device_release_driver_internal+0x1d4/0x2cc device_release_driver+0x18/0x28 bus_remove_device+0x160/0x1a4 device_del+0x1ec/0x350 usb_disable_device+0x98/0x214 usb_disconnect+0xf0/0x35c hub_event+0xab4/0x19ec process_one_work+0x278/0x63c Fix this by saving the stream_info pointers and clearing the ep references under the lock, then calling xhci_free_stream_info() outside the lock where sleeping is allowed. Fixes: 8df75f42f8e6 ("USB: xhci: Add memory allocation for USB3 bulk streams.") Cc: stable Signed-off-by: Lianqin Hu Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20260703144033.483286-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 91b27f8172cdbf265240104772fd042a461a7767 Author: Alice Ryhl Date: Fri Jul 3 11:25:12 2026 +0000 rust_binder: clear freeze listener on node removal commit bc4a9828897871ff3e5a1f8a1d346decbf4ee95e upstream. Generally userspace is supposed to explicitly clear freeze listeners before they drop the refcount on the node ref to zero, but there's nothing forcing that. Currently, in this scenario the freeze listener remains in the freeze_listeners rbtree and in the remote node's freeze listener list, even though the ref for which the listener is registered is gone. This could potentially lead to a memory leak due to a refcount cycle. Thus, remove the freeze listener in this scenario. Cc: stable Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver") Signed-off-by: Alice Ryhl Link: https://patch.msgid.link/20260703-remove-freeze-on-remove-node-v3-1-6e0c4547af46@google.com Signed-off-by: Greg Kroah-Hartman commit 281335996ab21e0849047a9e20cf04aacce990ac Author: Keshav Verma Date: Tue Jun 16 02:47:43 2026 +0530 rust_binder: synchronize Rust Binder stats with freeze commands commit eb1645bf10190e71f6f0316e37ff70755d719b53 upstream. Rust Binder stats use BC_COUNT and BR_COUNT to size the command and return counters, and use event string tables when printing debug statistics. The Binder protocol includes freeze-related commands and return codes, but the Rust Binder statistics code was not updated to cover them. As a result, those commands and return codes are not accounted for or printed by the stats debug output. Update the counts and event string tables so these commands and return codes are included in the debug statistics output. Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver") Cc: stable Acked-by: Carlos Llamas Reviewed-by: Alice Ryhl Signed-off-by: Keshav Verma Link: https://patch.msgid.link/20260615211743.734-1-iganschel@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 08e21d86d272243d54c6413cb19d1dcefe792272 Author: Keshav Verma Date: Thu Jun 25 16:09:57 2026 +0530 rust_binder: reject context manager self-transaction commit 6849cabfd30fb5727cfd31e8241e15801e17ebf9 upstream. Rust binder resolved handle 0 to the context manager node, but it does not reject the case where the caller owns the same node. The C binder driver rejects transactions from the context-manager process to handle 0 after resolving the target node. Match that behavior in Rust Binder by rejecting handle 0 transactions when the resolved context-manager node is owned by the calling process. This applies to both synchronous and oneway transactions because both paths resolve the target through Process::get_transaction_node(). Cc: stable Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver") Signed-off-by: Keshav Verma Reviewed-by: Alice Ryhl Link: https://patch.msgid.link/20260625103957.730-1-iganschel@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 89b8cc948dce661af87527623b3a41cdd115e2f9 Author: Hyunwoo Kim Date: Sun May 31 22:29:24 2026 +0900 rust_binder: use a u64 stride when cleaning up the offsets array commit 803c8a9502e9b97cd6ae937618ef4a8fd6274343 upstream. Allocation's Drop walks the offsets array (binder_size_t = u64 entries), cleaning up the objects, but it used usize instead of u64 for both the stride and the per-entry read. On 64-bit kernels (usize == u64) this is harmless, but on 32-bit kernels it walks the 8-byte entries in 4-byte steps, iterating an N-entry array 2N times, and reads the always-zero high word as offset 0, cleaning up the object at offset 0 N extra times. As a result the referenced node or handle ends up with a lower reference count than it actually has (a refcount over-decrement), and binder's reference accounting is corrupted; for example, the owner can be notified of a strong reference release (BR_RELEASE) even though references still remain. Change the stride to u64, and read each entry as a u64, narrowing it to usize with try_into(). On 32-bit ARM, when this over-decrement would drive a count below zero, the driver's existing refcount guard refuses it and fires: rust_binder: Failure: refcount underflow! Cc: stable Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver") Signed-off-by: Hyunwoo Kim Acked-by: Carlos Llamas Reviewed-by: Alice Ryhl Link: https://patch.msgid.link/ahw3tFhLz9bMMJAO@v4bel Signed-off-by: Greg Kroah-Hartman commit 328ccf32acb87e8bbb1fe2b065068c574e4db2bf Author: Carlos Llamas Date: Fri Jun 19 18:52:31 2026 +0000 binder: fix UAF in binder_free_transaction() commit f223d27a546c1e1f48d38fd67760e78f068fe8c4 upstream. In binder_free_transaction(), the t->to_proc is read under the t->lock. However, once the t->lock is dropped, the to_proc can die in parallel. This leads to a use-after-free error when we attempt to acquire its inner lock right afterwards: ================================================================== BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x1a0 Write of size 4 at addr ffff00001125da70 by task B/672 CPU: 20 UID: 0 PID: 672 Comm: B Not tainted 7.1.0-rc6-00284-g8e65320d91cd #4 PREEMPT Hardware name: linux,dummy-virt (DT) Call trace: _raw_spin_lock+0xe4/0x1a0 binder_free_transaction+0x8c/0x320 binder_send_failed_reply+0x21c/0x2f8 binder_thread_release+0x488/0x7e0 binder_ioctl+0x12c0/0x29a0 [...] Allocated by task 675: __kmalloc_cache_noprof+0x174/0x444 binder_open+0x118/0xb70 do_dentry_open+0x374/0x1040 vfs_open+0x58/0x3bc [...] Freed by task 212: __kasan_slab_free+0x58/0x80 kfree+0x1a0/0x4a4 binder_proc_dec_tmpref+0x32c/0x5e0 binder_deferred_func+0xc48/0x104c process_one_work+0x53c/0xbc0 [...] ================================================================== To prevent this, pin the target thread (t->to_thread) to guarantee the target process remains alive. Undelivered transactions without a target thread are already safe, as the target process can only be the current context in those paths. Cc: stable Reported-by: Alice Ryhl Closes: https://lore.kernel.org/all/aikJKVuny_eOivwN@google.com/ Fixes: a370003cc301 ("binder: fix possible UAF when freeing buffer") Signed-off-by: Carlos Llamas Reviewed-by: Alice Ryhl Link: https://patch.msgid.link/20260619185233.2194678-2-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit ea02df466df60ecd758eb3b4df3f0cadc5c886ce Author: Carlos Llamas Date: Fri Jun 19 18:52:30 2026 +0000 binder: fix UAF in binder_thread_release() commit 114a116aaa5f0295376cdf12da743c5bce3b20ce upstream. When a thread exits, binder_thread_release() walks its transaction stack to clear the t->from and t->to_proc that correspond with the exiting thread. However, a process dying in parallel might attempt to kfree some of these transactions. And if one of them has no associated t->to_proc, the t->to_proc->inner_lock will not be acquired. This means that transaction accesses in binder_thread_release() after t->to_proc has been cleared might race with binder_free_transaction() and cause a use-after-free error as reported by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in binder_thread_release+0x5d0/0x798 Write of size 8 at addr ffff000016627500 by task X/715 CPU: 17 UID: 0 PID: 715 Comm: X Not tainted 7.1.0-rc5-00149-g8fde5d1d47f6 #30 PREEMPT Hardware name: linux,dummy-virt (DT) Call trace: binder_thread_release+0x5d0/0x798 binder_ioctl+0x12c0/0x299c [...] Allocated by task 717 on cpu 18 at 67.267803s: __kasan_kmalloc+0xa0/0xbc __kmalloc_cache_noprof+0x174/0x444 binder_transaction+0x554/0x8150 binder_thread_write+0xa30/0x4354 binder_ioctl+0x20f0/0x299c [...] Freed by task 202 on cpu 18 at 90.416221s: __kasan_slab_free+0x58/0x80 kfree+0x1a0/0x4a4 binder_free_transaction+0x150/0x294 binder_send_failed_reply+0x398/0x6d8 binder_release_work+0x3e4/0x4ec binder_deferred_func+0xbd8/0x104c [...] ================================================================== In order to avoid this, make sure that binder_free_transaction() reads the t->to_proc under the transaction lock. This will serialize the transaction release with the accesses in binder_thread_release(). Plus, it matches the documented locking rules for @to_proc. Cc: stable Fixes: 7a4408c6bd3e ("binder: make sure accesses to proc/thread are safe") Reviewed-by: Alice Ryhl Signed-off-by: Carlos Llamas Link: https://patch.msgid.link/20260619185233.2194678-1-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 17a2d3f903455f6b95539a58ef8ca5fa5a76e7cc Author: Johan Hovold Date: Thu Jun 4 08:37:38 2026 +0200 Bluetooth: btusb: fix wakeup source leak on probe failure commit 3d93e1bb0fb881fe3ef961d1120556658e9cac4d upstream. Make sure to disable wakeup on probe failure to avoid leaking the wakeup source. Fixes: fd913ef7ce61 ("Bluetooth: btusb: Add out-of-band wakeup support") Cc: stable@vger.kernel.org # 4.11 Cc: Rajat Jain Signed-off-by: Johan Hovold Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit a7e941a395711791c7e98d9870c6562c2c9e9ef2 Author: Johan Hovold Date: Thu Jun 4 08:37:37 2026 +0200 Bluetooth: btusb: fix use-after-free on marvell probe failure commit c5b600a3c05b1a7a110d558df935a8fc8a471c79 upstream. Make sure to stop any TX URBs submitted during Marvell OOB wakeup configuration on later probe failures to avoid use-after-free in the completion callback. This issue was reported by Sashiko while reviewing a fix for a wakeup source leak in the btusb probe errors paths. Link: https://sashiko.dev/#/patchset/20260402092704.2346710-1-johan%40kernel.org Fixes: a4ccc9e33d2f ("Bluetooth: btusb: Configure Marvell to use one of the pins for oob wakeup") Cc: stable@vger.kernel.org # 4.11 Cc: Rajat Jain Signed-off-by: Johan Hovold Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 8db0ce3de78367f61c2970c0f16d9adee8830a23 Author: Johan Hovold Date: Thu Jun 4 08:37:36 2026 +0200 Bluetooth: btusb: fix use-after-free on registration failure commit eedc6867ebad73edbfaf9a0a65fbef7115cc4753 upstream. Make sure to release the sibling interfaces in case controller registration fails to avoid use-after-free and double-free when they are eventually disconnected. This issue was reported by Sashiko while reviewing a fix for a wakeup source leak in the btusb probe errors paths. Link: https://sashiko.dev/#/patchset/20260402092704.2346710-1-johan%40kernel.org Fixes: 9bfa35fe422c ("[Bluetooth] Add SCO support to btusb driver") Fixes: 9d08f50401ac ("Bluetooth: btusb: Add support for Broadcom LM_DIAG interface") Cc: stable@vger.kernel.org # 2.6.27 Reviewed-by: Paul Menzel Signed-off-by: Johan Hovold Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 79f9e221dddecb86c982eed525960295c36c17b3 Author: Zenm Chen Date: Tue May 26 00:19:42 2026 +0800 Bluetooth: btusb: Add USB ID 2c4e:0128 for Mercusys MA60XNB commit 88b4d528eda4ac71c2952b3458f2abbc80a91cd2 upstream. Add USB ID 2c4e:0128 for Mercusys MA60XNB, an RTL8851BU-based Wi-Fi + Bluetooth adapter. The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below: T: Bus=03 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2c4e ProdID=0128 Rev= 0.00 S: Manufacturer=Realtek S: Product=802.11ax WLAN Adapter S: SerialNumber=00e04c000001 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=500mA A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 8 Cls=ff(vend.) Sub=ff Prot=ff Driver=rtw89_8851bu E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=09(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0a(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0b(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0c(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Cc: stable@vger.kernel.org # 6.6.x Signed-off-by: Zenm Chen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit a53109ffb6b5148e11a27fb7670355b92db12dd3 Author: Alex Williamson Date: Mon Jun 15 14:47:00 2026 -0600 vfio: Remove device debugfs before releasing devres commit dc7fe87de492ea7f33a72b78d26650b75bf37f4f upstream. VFIO device debugfs files created with debugfs_create_devm_seqfile() store a devres allocated debugfs_devm_entry as inode private data. vfio_unregister_group_dev() currently calls vfio_device_del() before vfio_device_debugfs_exit(), but device_del() releases devres. This can leave debugfs entries visible with stale inode private data while unregister waits for userspace references to drain. Remove the per-device debugfs tree before vfio_device_del(). The debugfs view is diagnostic only, so losing it at the start of unregister is preferable to preserving entries whose backing storage may already have been released. Complete the teardown by clearing the per-device debugfs root after removal. This matches the global debugfs root cleanup and prevents future users from mistaking a removed dentry for a live debugfs tree during the remainder of unregister. Fixes: 2202844e4468 ("vfio/migration: Add debugfs to live migration driver") Reported-by: Sashiko AI Review Link: https://lore.kernel.org/r/20260615192725.6A2221F000E9@smtp.kernel.org Cc: stable@vger.kernel.org Cc: Longfang Liu Assisted-by: OpenAI Codex:gpt-5 Signed-off-by: Alex Williamson Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20260615204717.735302-1-alex.williamson@nvidia.com Signed-off-by: Alex Williamson Signed-off-by: Greg Kroah-Hartman commit 7f2d6b31089e48db4653df832c9a6afdde9a1c29 Author: Junrui Luo Date: Tue Jun 2 16:58:48 2026 +0800 vfio: prevent infinite loop in vfio_mig_get_next_state() on blocked arc commit a26b499b757cfc8bbff1088bb1b844639e250893 upstream. vfio_mig_get_next_state() walks vfio_from_fsm_table[] one step at a time, looping to skip optional states the device does not support until *next_fsm is supported. A blocked transition is encoded as VFIO_DEVICE_STATE_ERROR, which the trailing return reports as -EINVAL. The skip loop does not account for the ERROR sentinel. state_flags_table[ERROR] is ~0U and vfio_from_fsm_table[ERROR][*] is ERROR, so once *next_fsm becomes ERROR the loop condition stays true and *next_fsm never changes. The blocked arcs STOP_COPY -> PRE_COPY and STOP_COPY -> PRE_COPY_P2P map to ERROR yet pass the support check on a precopy-capable device, causing the loop to spin forever while holding the driver state mutex. This can result in a soft lockup, and a panic with softlockup_panic set. Terminate the skip loop on the ERROR sentinel so a blocked transition falls through to the existing return and reports -EINVAL. Fixes: 4db52602a607 ("vfio: Extend the device migration protocol with PRE_COPY") Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Reviewed-by: Kevin Tian Reviewed-by: Jason Gunthorpe Link: https://lore.kernel.org/r/SYBPR01MB7881290BBDE79B61AE6A017FAF122@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Alex Williamson Signed-off-by: Greg Kroah-Hartman commit ba96666d991e6d6111f5dbdb7faad878485ceb22 Author: Alex Williamson Date: Mon Jun 15 13:12:31 2026 -0600 vfio/pci: Fix racy bitfields and tighten struct layout commit e73638e55f861758d49f14d7bb5dba3035981cd7 upstream. Bitfield operations are not atomic, they use a read-modify-write pattern, therefore we should be careful not to pack bitfields that can be concurrently updated into the same storage unit. This split takes a binary approach: flags that are only modified pre/post open/close remain bitfields, flags modified from user action, including actions that reach across to another device (ex. reset) use dedicated storage units. Note that the virq_disabled and bardirty flags are relocated to fill an existing hole in the structure. Bitfield justifications: has_dyn_msix: written only in vfio_pci_core_enable() pci_2_3: written only in vfio_pci_core_enable() reset_works: written only in vfio_pci_core_enable() extended_caps: written only in vfio_cap_len() under vfio_config_init() has_vga: written only in vfio_pci_core_enable() nointx: written only in vfio_pci_core_enable() needs_pm_restore: written only in vfio_pci_probe_power_state() disable_idle_d3: written only at .init in vfio_pci_core_init_dev() Dedicated storage units: virq_disabled: written by guest INTx command writes in vfio_basic_config_write() while the device is open bardirty: written by guest BAR writes in vfio_basic_config_write() while the device is open pm_intx_masked: written in the runtime-PM suspend path. pm_runtime_engaged: written by low-power feature entry/exit paths needs_reset: set in vfio_pci_core_disable() and cleared for devices in the set by vfio_pci_dev_set_try_reset() sriov_active: written by vfio_pci_core_sriov_configure() via sysfs sriov_numvfs while bound. Fixes: 9cd0f6d5cbb6 ("vfio/pci: Use bitfield for struct vfio_pci_core_device flags") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Alex Williamson Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20260615191241.688297-4-alex.williamson@nvidia.com Signed-off-by: Alex Williamson Signed-off-by: Greg Kroah-Hartman commit 52adb2dff7ce3d8430e2bdc5988b618a430def85 Author: Alex Williamson Date: Mon Jun 15 13:12:30 2026 -0600 vfio/pci: Release the VGA arbiter client on register_device() failure commit daedde7f024ecf88bc8e832ed40cf2c795f0796a upstream. The re-order in the Fixes commit below displaced vfio_pci_vga_init() as the last failure point of what is now vfio_pci_core_register_device() without introducing an unwind for the VGA arbiter registration. In current kernels this is mostly benign because vfio_pci_set_decode() only uses pci_dev state, but the original failure path could leave a callback with a freed vdev cookie. The stale registration also becomes unsafe again once the callback follows drvdata to the vfio device. Add the required VGA unwind callout. Fixes: 4aeec3984ddc ("vfio/pci: Re-order vfio_pci_probe()") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Alex Williamson Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20260615191241.688297-3-alex.williamson@nvidia.com Signed-off-by: Alex Williamson Signed-off-by: Greg Kroah-Hartman commit f6c67cf0051f96ba61d186731d3d9409b9927db2 Author: Alex Williamson Date: Mon Jun 15 13:12:29 2026 -0600 vfio/pci: Latch disable_idle_d3 per device commit 4575e9aac5336d1365138c0284773bf8da4b1fa3 upstream. When disable_idle_d3 was introduced in vfio-pci, it directly manipulated the device power state with pci_set_power_state(). There were no refcounts to maintain or balanced operations, we could unconditionally bring the device to D0 and conditionally move it to D3hot. Therefore the module parameter was made writable. Later, in commit c61302aa48f7 ("vfio/pci: Move module parameters to vfio_pci.c"), as part of the vfio-pci-core split, the writable aspect of the module parameter was nullified. The parameter value could still be changed through sysfs, but the vfio-pci driver latched the values into vfio-pci-core globals at module init. Loading the vfio-pci module, or unloading and reloading, with non-default or different values could change the globals relative to existing devices bound to vfio-pci variant drivers. Runtime PM was introduced in commit 7ab5e10eda02 ("vfio/pci: Move the unused device into low power state with runtime PM"), which marks the point where power states became refcounted. PM get and put operations need to be balanced, but the same module operations noted above can change the global variables relative to those devices already bound to vfio-pci variant drivers. This introduces a window where PM operations can now become unbalanced. To resolve this with a narrow footprint for stable backports, the disable_idle_d3 flag is latched into the vfio_pci_core_device at the time of initialization, such that the device always operates with a consistent value. NB. vfio_pci_dev_set_try_reset() now unconditionally raises the runtime PM usage count around bus reset to account for disable_idle_d3 becoming a per-device rather than global flag. When this flag is set, the additional get/put pair is harmless and allows continued use of the shared vfio_pci_dev_set_pm_runtime_get() helper. Fixes: 7ab5e10eda02 ("vfio/pci: Move the unused device into low power state with runtime PM") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Alex Williamson Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20260615191241.688297-2-alex.williamson@nvidia.com Signed-off-by: Alex Williamson Signed-off-by: Greg Kroah-Hartman commit a385d3435a7af36c4ac18e9536981b99d5d1c2a0 Author: Raghavendra Rao Ananta Date: Thu May 14 17:34:49 2026 +0000 vfio/pci: Use a private flag to prevent power state change with VFs commit 40ef3edf151e184d021917a5c4c771cc0870844a upstream. The current implementation uses pci_num_vf() while holding the memory_lock to prevent changing the power state of a PF when VFs are enabled. This creates a lockdep circular dependency warning because memory_lock is held during device probing. [ 286.997167] ====================================================== [ 287.003363] WARNING: possible circular locking dependency detected [ 287.009562] 7.0.0-dbg-DEV #3 Tainted: G S [ 287.015074] ------------------------------------------------------ [ 287.021270] vfio_pci_sriov_/18636 is trying to acquire lock: [ 287.026942] ff45bea2294d4968 (&vdev->memory_lock){+.+.}-{4:4}, at: vfio_pci_core_runtime_resume+0x1f/0xa0 [ 287.036530] [ 287.036530] but task is already holding lock: [ 287.042383] ff45bea3a96b8230 (&new_dev_set->lock){+.+.}-{4:4}, at: vfio_group_fops_unl_ioctl+0x44d/0x7b0 [ 287.051879] [ 287.051879] which lock already depends on the new lock. [ 287.051879] [ 287.060070] [ 287.060070] the existing dependency chain (in reverse order) is: [ 287.067568] [ 287.067568] -> #2 (&new_dev_set->lock){+.+.}-{4:4}: [ 287.073941] __mutex_lock+0x92/0xb80 [ 287.078058] vfio_assign_device_set+0x66/0x1b0 [ 287.083042] vfio_pci_core_register_device+0xd1/0x2a0 [ 287.088638] vfio_pci_probe+0xd2/0x100 [ 287.092933] local_pci_probe_callback+0x4d/0xa0 [ 287.098001] process_scheduled_works+0x2ca/0x680 [ 287.103158] worker_thread+0x1e8/0x2f0 [ 287.107452] kthread+0x10c/0x140 [ 287.111230] ret_from_fork+0x18e/0x360 [ 287.115519] ret_from_fork_asm+0x1a/0x30 [ 287.119983] [ 287.119983] -> #1 ((work_completion)(&arg.work)){+.+.}-{0:0}: [ 287.127219] __flush_work+0x345/0x490 [ 287.131429] pci_device_probe+0x2e3/0x490 [ 287.135979] really_probe+0x1f9/0x4e0 [ 287.140180] __driver_probe_device+0x77/0x100 [ 287.145079] driver_probe_device+0x1e/0x110 [ 287.149803] __device_attach_driver+0xe3/0x170 [ 287.154789] bus_for_each_drv+0x125/0x150 [ 287.159346] __device_attach+0xca/0x1a0 [ 287.163720] device_initial_probe+0x34/0x50 [ 287.168445] pci_bus_add_device+0x6e/0x90 [ 287.172995] pci_iov_add_virtfn+0x3c9/0x3e0 [ 287.177719] sriov_add_vfs+0x2c/0x60 [ 287.181838] sriov_enable+0x306/0x4a0 [ 287.186038] vfio_pci_core_sriov_configure+0x184/0x220 [ 287.191715] sriov_numvfs_store+0xd9/0x1c0 [ 287.196351] kernfs_fop_write_iter+0x13f/0x1d0 [ 287.201338] vfs_write+0x2be/0x3b0 [ 287.205286] ksys_write+0x73/0x100 [ 287.209233] do_syscall_64+0x14d/0x750 [ 287.213529] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 287.219120] [ 287.219120] -> #0 (&vdev->memory_lock){+.+.}-{4:4}: [ 287.225491] __lock_acquire+0x14c6/0x2800 [ 287.230048] lock_acquire+0xd3/0x2f0 [ 287.234168] down_write+0x3a/0xc0 [ 287.238019] vfio_pci_core_runtime_resume+0x1f/0xa0 [ 287.243436] __rpm_callback+0x8c/0x310 [ 287.247730] rpm_resume+0x529/0x6f0 [ 287.251765] __pm_runtime_resume+0x68/0x90 [ 287.256402] vfio_pci_core_enable+0x44/0x310 [ 287.261216] vfio_pci_open_device+0x1c/0x80 [ 287.265947] vfio_df_open+0x10f/0x150 [ 287.270148] vfio_group_fops_unl_ioctl+0x4a4/0x7b0 [ 287.275476] __se_sys_ioctl+0x71/0xc0 [ 287.279679] do_syscall_64+0x14d/0x750 [ 287.283975] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 287.289559] [ 287.289559] other info that might help us debug this: [ 287.289559] [ 287.297582] Chain exists of: [ 287.297582] &vdev->memory_lock --> (work_completion)(&arg.work) --> &new_dev_set->lock [ 287.297582] [ 287.310023] Possible unsafe locking scenario: [ 287.310023] [ 287.315961] CPU0 CPU1 [ 287.320510] ---- ---- [ 287.325059] lock(&new_dev_set->lock); [ 287.328917] lock((work_completion)(&arg.work)); [ 287.336153] lock(&new_dev_set->lock); [ 287.342523] lock(&vdev->memory_lock); [ 287.346382] [ 287.346382] *** DEADLOCK *** [ 287.346382] [ 287.352315] 2 locks held by vfio_pci_sriov_/18636: [ 287.357125] #0: ff45bea208ed3e18 (&group->group_lock){+.+.}-{4:4}, at: vfio_group_fops_unl_ioctl+0x3e3/0x7b0 [ 287.367048] #1: ff45bea3a96b8230 (&new_dev_set->lock){+.+.}-{4:4}, at: vfio_group_fops_unl_ioctl+0x44d/0x7b0 [ 287.376976] [ 287.376976] stack backtrace: [ 287.381353] CPU: 191 UID: 0 PID: 18636 Comm: vfio_pci_sriov_ Tainted: G S 7.0.0-dbg-DEV #3 PREEMPTLAZY [ 287.381355] Tainted: [S]=CPU_OUT_OF_SPEC [ 287.381356] Call Trace: [ 287.381357] [ 287.381358] dump_stack_lvl+0x54/0x70 [ 287.381361] print_circular_bug+0x2e1/0x300 [ 287.381363] check_noncircular+0xf9/0x120 [ 287.381364] ? __lock_acquire+0x5b4/0x2800 [ 287.381366] __lock_acquire+0x14c6/0x2800 [ 287.381368] ? pci_mmcfg_read+0x4f/0x220 [ 287.381370] ? pci_mmcfg_write+0x57/0x220 [ 287.381371] ? lock_acquire+0xd3/0x2f0 [ 287.381373] ? pci_mmcfg_write+0x57/0x220 [ 287.381374] ? lock_release+0xef/0x360 [ 287.381376] ? vfio_pci_core_runtime_resume+0x1f/0xa0 [ 287.381377] lock_acquire+0xd3/0x2f0 [ 287.381378] ? vfio_pci_core_runtime_resume+0x1f/0xa0 [ 287.381379] ? lock_is_held_type+0x76/0x100 [ 287.381382] down_write+0x3a/0xc0 [ 287.381382] ? vfio_pci_core_runtime_resume+0x1f/0xa0 [ 287.381383] vfio_pci_core_runtime_resume+0x1f/0xa0 [ 287.381384] ? __pfx_pci_pm_runtime_resume+0x10/0x10 [ 287.381385] __rpm_callback+0x8c/0x310 [ 287.381386] ? ktime_get_mono_fast_ns+0x3d/0xb0 [ 287.381389] ? __pfx_pci_pm_runtime_resume+0x10/0x10 [ 287.381390] rpm_resume+0x529/0x6f0 [ 287.381392] ? lock_is_held_type+0x76/0x100 [ 287.381394] __pm_runtime_resume+0x68/0x90 [ 287.381396] vfio_pci_core_enable+0x44/0x310 [ 287.381398] vfio_pci_open_device+0x1c/0x80 [ 287.381399] vfio_df_open+0x10f/0x150 [ 287.381401] vfio_group_fops_unl_ioctl+0x4a4/0x7b0 [ 287.381402] __se_sys_ioctl+0x71/0xc0 [ 287.381404] do_syscall_64+0x14d/0x750 [ 287.381405] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 287.381406] ? trace_irq_disable+0x25/0xd0 [ 287.381409] entry_SYSCALL_64_after_hwframe+0x77/0x7f Introduce a private flag 'sriov_active' in the vfio_pci_core_device struct. This allows the driver to track the SR-IOV power state requirement without relying on pci_num_vf() while holding the memory_lock. The lock is now only held to set the flag and ensure the device is in D0, after which pci_enable_sriov() can be called without the lock. Fixes: f4162eb1e2fc ("vfio/pci: Change the PF power state to D0 before enabling VFs") Cc: stable@vger.kernel.org Suggested-by: Jason Gunthorpe Suggested-by: Alex Williamson Signed-off-by: Raghavendra Rao Ananta Link: https://lore.kernel.org/r/20260514173449.3282188-1-rananta@google.com [promote bitfield to plain bool to avoid storage-unit races] Signed-off-by: Alex Williamson Signed-off-by: Greg Kroah-Hartman commit afc90150551dd0d97a012dd51be2cdd7e0235eec Author: Cássio Gabriel Date: Sun Apr 19 17:30:32 2026 -0300 ALSA: usb-audio: Update US-16x08 EQ/comp shadow state after successful writes commit a440c17869ecd71da0f295b62868fc742d09a8ba upstream. snd_us16x08_comp_put() and snd_us16x08_eq_put() update their software stores before sending the USB write. If the transfer fails, later get callbacks report a value the hardware never accepted. Build the outgoing message from the current store plus the pending value, then commit the store only after a successful write. Fixes: d2bb390a2081 ("ALSA: usb-audio: Tascam US-16x08 DSP mixer quirk") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260419-usb-write-error-propagation-v1-4-5a3bd4a673ae@gmail.com Signed-off-by: Greg Kroah-Hartman commit 54c448e4f26a7c86552d83edf715c5ca5ab31dbe Author: Cássio Gabriel Date: Wed Apr 29 10:20:02 2026 -0300 ALSA: usb-audio: Update Babyface Pro control caches only after successful writes commit d8f802ccf1fdbeb89d62748d6a0d0fbd442c8127 upstream. snd_bbfpro_ctl_put() and snd_bbfpro_vol_put() cache the requested packed control state in kcontrol->private_value before issuing the USB write. Their get and resume paths use that cached value directly, so a failed write can leave the driver reporting and later replaying a setting the hardware never accepted. Update the cached state only after a successful USB write. Fixes: 3e8f3bd04716 ("ALSA: usb-audio: RME Babyface Pro mixer patch") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260429-alsa-usb-quirks-cache-rollback-v1-2-01b35c688b80@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f3e8a6cca15b8b4cc7bf04282d57deff28defe85 Author: Cássio Gabriel Date: Wed Apr 29 10:20:01 2026 -0300 ALSA: usb-audio: Roll back quirk control caches on write errors commit 6380957fa24251856a532e48a46a4dc3d1ae26b6 upstream. Several mixer quirk callbacks cache the requested control value in kcontrol->private_value before issuing a single vendor or class write. Their paired get and resume paths consume that cache directly, so a failed write currently leaves software state changed even though the update did not succeed. That can make later reads report a value the device never accepted and can replay the stale cache on resume. Restore the previous cached value on failure in the Audigy2NX LED, Emu0204 channel switch, Xonar U1 output switch, Native Instruments controls, FTU effect program switch, and Sound Blaster E1 input source switch. Fixes: 9cf3689bfe07 ("ALSA: usb-audio: Add audigy2nx resume support") Fixes: 5f503ee9e270 ("ALSA: usb-audio: Add Emu0204 channel switch resume support") Fixes: 2bfb14c3b8fb ("ALSA: usb-audio: Add Xonar U1 resume support") Fixes: da6d276957ea ("ALSA: usb-audio: Add resume support for Native Instruments controls") Fixes: 0b4e9cfcef05 ("ALSA: usb-audio: Add resume support for FTU controls") Fixes: 388fdb8f882a ("ALSA: usb-audio: Support changing input on Sound Blaster E1") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260429-alsa-usb-quirks-cache-rollback-v1-1-01b35c688b80@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3061b6c114458d3570a1c48634a27d420a47c2ab Author: Cássio Gabriel Date: Sun Apr 19 17:30:31 2026 -0300 ALSA: usb-audio: Propagate US-16x08 write errors in route/mix EQ-switch put callbacks commit 3c06aec8abda6ba068b58a8b7119cdb2a48456b1 upstream. Several US-16x08 mixer put callbacks log failed control URBs but still return success to userspace. That hides device write failures even though the requested value was not applied. Return the negative write error instead in the route, master, bus, channel, and EQ switch put callbacks. Fixes: d2bb390a2081 ("ALSA: usb-audio: Tascam US-16x08 DSP mixer quirk") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260419-usb-write-error-propagation-v1-3-5a3bd4a673ae@gmail.com Signed-off-by: Greg Kroah-Hartman commit bfd28b07541e510d64b937d28f3459e3e2500da5 Author: Cássio Gabriel Date: Sun Apr 19 17:30:30 2026 -0300 ALSA: usb-audio: Propagate errors in scarlett_ctl_enum_put() commit 0f25cf1f02e3dba626791d949c759a48c0a44996 upstream. scarlett_ctl_enum_put() ignores the return value from snd_usb_set_cur_mix_value() and reports success whenever the requested enum value differs from the current one. If the SET_CUR request fails, the callback still returns success even though neither the hardware state nor the cached mixer value changed. Fixes: 76b188c4b370 ("ALSA: usb-audio: Scarlett mixer interface for 6i6, 18i6, 18i8 and 18i20") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260419-usb-write-error-propagation-v1-2-5a3bd4a673ae@gmail.com Signed-off-by: Greg Kroah-Hartman commit a263eb12cbe2e208e6e637df0f9b0be9a484158e Author: Darvell Long Date: Wed Jun 24 07:37:23 2026 -0700 ALSA: usb-audio: avoid kobject path lookup in DualSense match commit 7693c0cc415f3a16a7a3355f245474a5e661be4e upstream. The DualSense jack-detection input handler verifies that a matching input device belongs to the same physical controller by building kobject path strings for both the input device and the USB audio device, then comparing the path prefix. This was observed when a weak physical connection caused the controller to rapidly disconnect and reconnect. During that repeated hotplug, snd_dualsense_ih_match() can run while the controller's USB device is being disconnected. kobject_get_path() walks ancestor kobjects and dereferences their names; if the USB device kobject name is no longer valid, this can fault in strlen(): RIP: 0010:strlen+0x10/0x30 Call Trace: kobject_get_path+0x34/0x150 snd_dualsense_ih_match+0x49/0xd0 [snd_usb_audio] input_register_device+0x566/0x6a0 ps_probe+0xb89/0x1590 [hid_playstation] The same ownership check can be done without building kobject path strings. The input device is parented below the HID device, USB interface and USB device, so walking the input device parent chain and comparing against the mixer USB device preserves the check without dereferencing kobject names during disconnect. Fixes: 79d561c4ec04 ("ALSA: usb-audio: Add mixer quirk for Sony DualSense PS5") Cc: Assisted-by: Cute:gpt-5.5 Signed-off-by: Darvell Long Link: https://patch.msgid.link/20260624143723.2986353-1-contact@darvell.me Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 16f14f55141d4c55c3f321f93c328fff7cd6860a Author: WenTao Liang Date: Sat Jun 27 12:29:49 2026 +0800 ALSA: us144mkii: capture_urb_complete: redundant usb_anchor_urb corrupts anchor list on each resubmission commit 5cff1529a2f9b3461a7f5a6e36a86682fc290534 upstream. In capture_urb_complete(), usb_anchor_urb() is called on every completion callback, but the URB is already anchored from the initial submission in tascam_trigger_start(). Each redundant call corrupts the anchor's doubly-linked list and inflates the URB refcount. When usb_kill_anchored_urbs() traverses the list during stream stop / suspend / disconnect, the corrupted list leads to use-after-free. Remove the redundant usb_anchor_urb() from the resubmit path. Cc: stable@vger.kernel.org Fixes: c1bb0c13e430 ("ALSA: usb-audio: us144mkii: Implement audio capture and decoding") Signed-off-by: WenTao Liang Link: https://patch.msgid.link/20260627042949.61767-1-vulab@iscas.ac.cn Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 651ba82fe2a144bc7356d940bfd235c3810b0549 Author: HyeongJun An Date: Wed Jun 24 08:38:40 2026 +0900 ALSA: seq: Fix uninitialised heap leak in snd_seq_event_dup() commit 435990e25bf1f4af3e6df12a6fbfd1f7ba4a97d4 upstream. snd_seq_event_dup() copies an incoming event into a pool cell and, in the UMP-enabled build, clears the trailing cell->ump.raw.extra word that the memcpy() did not cover. The guard deciding whether to clear it compares the copied size against sizeof(cell->event): memcpy(&cell->ump, event, size); if (size < sizeof(cell->event)) cell->ump.raw.extra = 0; For a legacy (non-UMP) event, size == sizeof(struct snd_seq_event) == sizeof(cell->event), so the condition is false and the extra word keeps stale data. The cell pool is allocated with kvmalloc() (not zeroed) and cells are reused via a free list, so that word holds uninitialised heap or leftover event data. When such a cell is delivered to a UMP client (client->midi_version > 0) that set SNDRV_SEQ_FILTER_NO_CONVERT -- so the legacy event reaches it unconverted -- snd_seq_read() reads it out as the larger struct snd_seq_ump_event and copies the stale word to user space, a 4-byte kernel heap infoleak to an unprivileged /dev/snd/seq client. Compare against sizeof(cell->ump) instead, so the trailing word is zeroed for every event shorter than the UMP cell. Fixes: 46397622a3fa ("ALSA: seq: Add UMP support") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260623233841.853326-1-sammiee5311@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 71b87108ad93d433cdb20704a8dc8852304cf2c2 Author: Zhao Dongdong Date: Wed May 27 20:09:11 2026 +0800 ALSA: ice1712: check snd_ctl_new1() return value commit 2b929b91b0f3bc6de8a844370049cd99ee8e31ff upstream. snd_ctl_new1() can return NULL when memory allocation fails. The ice1712 driver calls snd_ctl_new1() without checking the return value before dereferencing the pointer in multiple places (ice1712.c, ice1724.c, aureon.c), which can lead to NULL pointer dereferences. Add NULL checks after snd_ctl_new1() calls and return -ENOMEM if any fails. Assisted-by: Opencode:DeepSeek-V4-Flash Cc: stable@vger.kernel.org Fixes: b9a4efd61b6b ("ALSA: ice1712,ice1724: fix the kcontrol->id initialization") Signed-off-by: Zhao Dongdong Link: https://patch.msgid.link/tencent_42E5E2AB1B6A5101F7EE8C2117F1F687BB07@qq.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 04dd2101805758fe9e443f3f0933a12b2000b167 Author: Aaron Erhardt Date: Tue May 19 17:49:48 2026 +0200 ALSA: hda/realtek: Fix noisy mic for Clevo V6xxAW commit 493765b8e922a506e09e22e80b6cc9ff05e8295b upstream. Add a PCI quirk to reduce the volume of the internal microphone to prevent extremely noisy signal. Signed-off-by: Aaron Erhardt Signed-off-by: Werner Sembach Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260519155047.106096-1-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1933e6ee136b1dba697755b1be28453a7ae4671f Author: Huacai Chen Date: Wed May 27 22:08:41 2026 +0800 ALSA: hda/hdmi: Use 'AC_PINSENSE_ELDV' to detect pinsense for Loongson commit 958e4450e961d75bd9d8f5bfe245fb15bc78e02a upstream. Due to a hardware defect, for Loongson PCI HDMI devices with a reversion ID of 2, the pin sense status must be determined via the ELD. Add a codec flag, eld_jack_detect, to indicate this case, and do special handlings in read_pin_sense(). Cc: stable@vger.kernel.org Signed-off-by: Baoqi Zhang Signed-off-by: Haowei Zheng Signed-off-by: Huacai Chen Link: https://patch.msgid.link/20260527140841.3407183-1-chenhuacai@loongson.cn Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4dd2552e559bd448c04b7474c69360954398c5cc Author: Cameron Graham Date: Fri Jun 12 21:46:01 2026 +1200 ALSA: hda/hdmi: Add force-connect quirk for HP EliteDesk 800 G5 Mini commit 0ec17ee704615125c0b6e100c38129393a346bcc upstream. The HP EliteDesk 800 G5 Mini (PCI subsystem 103c:8595) uses Cannon Lake PCH cAVS HDA with DisplayPort audio pins 0x05 and 0x06 set to AC_JACK_PORT_NONE (N/A) in BIOS defaults, causing hdmi_add_pin() to skip them and the DP audio device to not appear in ALSA. Add the board to the existing force_connect_list alongside the similar HP EliteDesk 800 G4 entries. Signed-off-by: Cameron Graham Cc: Link: https://patch.msgid.link/20260612094601.1209845-1-cam.graham@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ce0a903d0591e3e2c790c5b628802b08d1b287cc Author: Cássio Gabriel Date: Mon May 11 01:29:34 2026 -0300 ALSA: hda/cs35l41: Fix firmware load work teardown commit b65020d5398f499c09498c9786dba6d67ae57664 upstream. cs35l41_hda creates ALSA controls whose private data points at the cs35l41_hda object. The firmware load control can also queue fw_load_work. Those controls are not removed on component unbind, and device remove only cancels fw_load_work through cs35l41_remove_dsp(). That helper is skipped when halo_initialized is false. With firmware_autostart disabled, a firmware load can be requested before the DSP has been initialized. If the component or device is removed before the queued work runs, the worker can run after teardown and dereference driver state that is no longer valid. Track the created controls and remove them on unbind so no new control callback can reach the driver data or queue more work. Then cancel fw_load_work to drain any request that was already queued. Also cancel the work unconditionally during device remove before runtime PM teardown. Fixes: 47ceabd99a28 ("ALSA: hda: cs35l41: Support Firmware switching and reloading") Fixes: 4c870513fbb0 ("ALSA: hda: cs35l41: Add read-only ALSA control for forced mute") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Reviewed-by: Stefan Binding Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260511-alsa-hda-cs35l41-fw-work-teardown-v1-1-1184e9bc4f25@gmail.com Signed-off-by: Greg Kroah-Hartman commit 5e74e5e8cb7cc25f7a89f59abaf3489bf0c6f4a0 Author: Zhao Dongdong Date: Wed May 27 20:09:10 2026 +0800 ALSA: gus: check snd_ctl_new1() return value commit c7fa99d30c7a166a5e5db5a585ce7501ff68326b upstream. snd_ctl_new1() can return NULL when memory allocation fails. snd_gf1_pcm_volume_control() does not check the return value before dereferencing kctl->id.index, which can lead to a NULL pointer dereference. Add a NULL check after snd_ctl_new1() and return -ENOMEM if it fails. Assisted-by: Opencode:DeepSeek-V4-Flash Cc: stable@vger.kernel.org Fixes: c5ae57b1bb99 ("ALSA: gus: Fix kctl->id initialization") Signed-off-by: Zhao Dongdong Link: https://patch.msgid.link/tencent_F644A3DCAD32945D62DB2FEEBE8A996F6809@qq.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8e48a29813df8dd71503800b7acf69c12c035045 Author: Maoyi Xie Date: Sun Jun 21 23:09:07 2026 +0800 ALSA: firewire: isight: bound the sample count to the packet payload commit 29b9667982e4df2ed7744f86b1144f8bb58eb698 upstream. isight_packet() takes the frame count from the device iso packet and checks it only against the device claimed iso length. count = be32_to_cpu(payload->sample_count); if (likely(count <= (length - 16) / 4)) isight_samples(isight, payload->samples, count); length is the iso header data_length. It can be up to 0xffff. So the gate allows a count up to about 16379. isight_samples() then copies count frames out of payload->samples into the PCM DMA buffer. payload->samples holds only 2 * MAX_FRAMES_PER_PACKET values. The device multiplexes two samples per frame. A count past MAX_FRAMES_PER_PACKET reads past the payload. A count past the buffer size writes past runtime->dma_area. The smallest PCM buffer is larger than MAX_FRAMES_PER_PACKET. Bounding the count to MAX_FRAMES_PER_PACKET keeps both the read and the write in range. A malicious or faulty Apple iSight on the FireWire bus reaches this during a normal capture. Add the MAX_FRAMES_PER_PACKET bound to the gate. Fixes: 3a691b28a0ca ("ALSA: add Apple iSight microphone driver") Suggested-by: Takashi Sakamoto Cc: stable@vger.kernel.org Signed-off-by: Maoyi Xie Link: https://patch.msgid.link/178205454729.1900991.7807310178296762772@maoyixie.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit db25755e7629da9093f248f6a43a384ec1009b3e Author: Geoffrey D. Bennett Date: Tue Jun 23 02:59:04 2026 +0930 ALSA: FCP: Add Focusrite ISA C8X support commit e0ecb324246be9cf3a0689346a658e48a38546b2 upstream. Add USB PID 0x821e to the list of devices handled by the Focusrite Control Protocol (FCP) driver. Cc: stable@vger.kernel.org Signed-off-by: Geoffrey D. Bennett Link: https://patch.msgid.link/ajlw4HK+2RSW3nUl@m.b4.vu Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9e53e99b6fa3cd82992d963cbff58dbbd1df8651 Author: Zhao Dongdong Date: Wed May 27 20:09:09 2026 +0800 ALSA: es1938: check snd_ctl_new1() return value commit 1edd1f02dddd20aeb6066ded41017615766ea42f upstream. snd_ctl_new1() can return NULL when memory allocation fails. snd_es1938_mixer() does not check the return value before dereferencing the pointer, which can lead to a NULL pointer dereference. Add a NULL check after snd_ctl_new1() and return -ENOMEM if it fails. Assisted-by: Opencode:DeepSeek-V4-Flash Cc: stable@vger.kernel.org Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Zhao Dongdong Link: https://patch.msgid.link/tencent_E0DC65165FDF2C8982BAFB6794B854B53B0A@qq.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b27a75d42044d9d4709095617730b91b1c4af423 Author: Cássio Gabriel Date: Mon Jun 15 10:37:26 2026 -0300 ALSA: compress: Fix task creation error unwind commit 4a60127debb9e370d6c0e22a307326b624a141f3 upstream. snd_compr_task_new() allocates the driver task before validating the returned DMA buffers and reserving file descriptors. When either of those later steps fails, the core frees its task wrapper and DMA-buffer references without calling the driver's task_free() callback. Any driver resources allocated by task_create() are therefore leaked. The dual-fd allocation path also jumps to cleanup without storing the negative get_unused_fd_flags() result in retval. Since retval still contains the successful task_create() return value, TASK_CREATE can incorrectly report success although the task was discarded. Preserve the fd allocation errors and call task_free() when failure occurs after a successful task_create() callback. Fixes: 04177158cf98 ("ALSA: compress_offload: introduce accel operation mode") Fixes: 3d3f43fab4cf ("ALSA: compress_offload: improve file descriptors installation for dma-buf") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260615-alsa-compress-task-unwind-v1-1-39e8ad3ddb27@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit af2b009b773bc42995546507963e5e78970dc3ed Author: Zhao Dongdong Date: Wed May 27 20:09:13 2026 +0800 ALSA: cmipci: check snd_ctl_new1() return value commit c205bd1b28fb7e5f1061a4e78813fad7d315cb3e upstream. snd_ctl_new1() can return NULL when memory allocation fails. snd_cmipci_spdif_controls() does not check the return value before dereferencing kctl->id.device, which can lead to a NULL pointer dereference. Add NULL checks after snd_ctl_new1() calls and return -ENOMEM if any fails. Assisted-by: Opencode:DeepSeek-V4-Flash Cc: stable@vger.kernel.org Fixes: f2f312ad88c6 ("ALSA: cmipci: Fix kctl->id initialization") Signed-off-by: Zhao Dongdong Link: https://patch.msgid.link/tencent_964433DCD132125D5EDA79EE068A2D6EFA09@qq.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a5fd3122283bf75c04f6414bf610100beb0565b0 Author: Maoyi Xie Date: Thu Jun 18 14:03:15 2026 +0800 ALSA: caiaq: fix out-of-bounds read in the Traktor Kontrol S4 input parser commit f7f3f9fd81e7adbaa12c2e62ee07f0e094a543fd upstream. snd_usb_caiaq_tks4_dispatch() decodes the Traktor Kontrol S4 input stream in fixed 16-byte (TKS4_MSGBLOCK_SIZE) message blocks. On every iteration it advances buf and subtracts the block size while looping on "while (len)". len is urb->actual_length. That value is supplied by the device and is not guaranteed to be a multiple of 16. When a final short block leaves len between 1 and 15, the loop runs once more, reads up to buf[15], and then does "len -= TKS4_MSGBLOCK_SIZE". As len is unsigned this underflows to a huge value. The loop then keeps iterating and walking buf far past the end of the 512-byte ep4_in_buf, reading out of bounds until a bogus block id happens to be hit. Iterate only while a full message block is available. This stops the unsigned underflow and silently drops any trailing partial block, which carries no complete control value anyway. The sibling endpoint-4 parsers are not affected. The Traktor Kontrol X1 and Maschine arms in snd_usb_caiaq_ep4_reply_dispatch() floor urb->actual_length before dispatching. Fixes: 15c5ab607045 ("ALSA: snd-usb-caiaq: Add support for Traktor Kontrol S4") Cc: stable@vger.kernel.org Signed-off-by: Maoyi Xie Link: https://patch.msgid.link/178176259547.3343534.2724779296835237429@maoyixie.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit fd786466889e4a6e6de0f4462bd0068edea63960 Author: Zhao Dongdong Date: Wed May 27 20:09:14 2026 +0800 ALSA: aoa: check snd_ctl_new1() return value commit 8df560fefe6fed6a20b7e06720eeaeccec349ac0 upstream. snd_ctl_new1() can return NULL when memory allocation fails. In layout.c, the function does not check the return value before dereferencing ctl->id.name or passing to aoa_snd_ctl_add(), which can lead to a NULL pointer dereference. Add NULL checks after snd_ctl_new1() calls and return early if any fails. Assisted-by: Opencode:DeepSeek-V4-Flash Cc: stable@vger.kernel.org Fixes: f3d9478b2ce4 ("[ALSA] snd-aoa: add snd-aoa") Signed-off-by: Zhao Dongdong Link: https://patch.msgid.link/tencent_35F3A25FEEBF190A2E15ED787754C57E3708@qq.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f6538a318947b627710b08a268bc80a48c23bde7 Author: Zhao Dongdong Date: Wed May 27 20:09:12 2026 +0800 ALSA: ymfpci: check snd_ctl_new1() return value commit e64d170346d00b580c0043de3e5ccb3e331c47d4 upstream. snd_ctl_new1() can return NULL when memory allocation fails. snd_ymfpci_create_spdif_controls() does not check the return value before dereferencing kctl->id.device, which can lead to a NULL pointer dereference. Add NULL checks after snd_ctl_new1() calls and return -ENOMEM if any fails. Assisted-by: Opencode:DeepSeek-V4-Flash Cc: stable@vger.kernel.org Fixes: c9b83ae4a160 ("ALSA: ymfpci: Fix kctl->id initialization") Signed-off-by: Zhao Dongdong Link: https://patch.msgid.link/tencent_4745C5DC2333325C0EDAB1EFC88A136E6809@qq.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5da9742de22db0dbaa8d414214ab5e1bedde00f9 Author: Cássio Gabriel Date: Thu May 7 11:28:30 2026 -0300 ALSA: virtio: Validate control metadata from the device commit c77a6cbb36ff8cbc1f084d94f8dcda5250935271 upstream. virtio-snd control handling trusts the device-provided control type and value count returned by the device. That metadata is then used directly to index g_v2a_type_map[] in virtsnd_kctl_info(), and to size loops and memcpy() operations in virtsnd_kctl_get() and virtsnd_kctl_put() against fixed-size virtio_snd_ctl_value and snd_ctl_elem_value arrays. A buggy or malicious device can therefore trigger out-of-bounds access by advertising an invalid control type or an oversized value count. Validate control type and count once in virtsnd_kctl_parse_cfg(), before querying enumerated items or exposing the control to ALSA. Fixes: d6568e3de42d ("ALSA: virtio: add support for audio controls") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260507-alsa-virtio-validate-kctl-info-v1-1-7404fb12ec37@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit df0fe53a7104bc61e47775804bec289f29bcc277 Author: Cássio Gabriel Date: Fri May 15 10:32:25 2026 -0300 ALSA: virtio: Add missing 384 kHz PCM rate mapping commit 83fbbcb7935ec6d2c8ba3bc133e8a0ead2ab0b2d upstream. The VirtIO sound UAPI defines VIRTIO_SND_PCM_RATE_384000, and ALSA has SNDRV_PCM_RATE_384000. However, virtio-snd's rate conversion tables stop at 192 kHz. A device advertising only 384 kHz is rejected as having no supported PCM frame rates. A device advertising 384 kHz together with lower rates does not expose 384 kHz through the ALSA hardware constraints. The selected ALSA rate also needs a reverse mapping for SET_PARAMS. Add the missing 384 kHz entries to both conversion tables. Fixes: 29b96bf50ba9 ("ALSA: virtio: build PCM devices and substream hardware descriptors") Fixes: da76e9f3e43a ("ALSA: virtio: PCM substream operators") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260515-alsa-virtio-384k-rate-v1-1-35ecb5df835c@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c071df05bcda0e47aac581d4b564b2bebcb1ff60 Author: HyeongJun An Date: Wed Jul 1 18:52:31 2026 +0900 ALSA: usx2y: us144mkii: fix work UAF on disconnect commit 147996e7e7c9e8339c0e04f6fa7ccb3e4d448ff7 upstream. tascam_disconnect() cancels capture_work and midi_in_work before usb_kill_anchored_urbs() kills the capture/MIDI-in URBs. Those URBs self-resubmit, and their completion handlers reschedule the work. A URB that completes in the small window between cancel_work_sync() and usb_kill_anchored_urbs() therefore re-arms the work after its only cancel. Nothing cancels it again before snd_card_free() frees the card-private tascam structure, so the work handler then runs on freed memory. Kill the anchored URBs before cancelling the work; once the work is cancelled no remaining URB can complete to re-arm it. Fixes: c1bb0c13e430 ("ALSA: usb-audio: us144mkii: Implement audio capture and decoding") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260701095231.1020811-1-sammiee5311@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a4f8491da9563ba6eb77969ac26fc7052114c476 Author: Stepan Ionichev Date: Sun May 17 23:26:13 2026 +0500 iio: temperature: tmp006: use devm_iio_trigger_register commit 3c5eed894efd93d68d7f6a359a81ddef0e928774 upstream. tmp006_probe() allocates the DRDY trigger with devm_iio_trigger_alloc() but registers it with plain iio_trigger_register(). The driver has no .remove() callback, so on module unload the trigger stays in the global trigger list while its memory is freed by devm, leaving a dangling entry. Switch to devm_iio_trigger_register() so the registration is undone in the same devm scope as the allocation. Fixes: 91f75ccf9f03 ("iio: temperature: tmp006: add triggered buffer support") Cc: stable@vger.kernel.org Signed-off-by: Stepan Ionichev Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 62a0d75bedd4bce3c55b45fa360d4a5a2e8f2edd Author: Liviu Stan Date: Mon May 25 19:39:29 2026 +0300 iio: temperature: ltc2983: Fix reinit_completion() called after conversion start commit 5cb9fdb446bfc3ae0524496f53fb68e67051701b upstream. reinit_completion() was called after regmap_write() initiated the hardware conversion, creating a race window where the interrupt could fire and call complete() before reinit_completion() reset the completion. Move reinit_completion() before the regmap_write() to close the race. ltc2983_eeprom_cmd() already does it in the correct order. Fixes: f110f3188e56 ("iio: temperature: Add support for LTC2983") Signed-off-by: Liviu Stan Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit e16258913be6a15e542410e894ab5976d64ef2ea Author: Liviu Stan Date: Mon May 25 19:39:28 2026 +0300 iio: temperature: ltc2983: Fix n_wires default bypassing rotation check commit 434c150752675f44dc52c384a7fa22e5176bc35a upstream. When adi,number-of-wires is absent, n_wires is left at 0. The binding documents a default of 2 wires, matching the hardware default. However the current-rotate validation checks n_wires == 2 || n_wires == 3, so with n_wires = 0 the guard is bypassed and adi,current-rotate is accepted for a 2-wire RTD. Initialize n_wires = 2 to match the binding default and ensure the rotation check fires correctly when the property is absent. Fixes: f110f3188e56 ("iio: temperature: Add support for LTC2983") Signed-off-by: Liviu Stan Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit b50344ab202f353231898fde9127aafc4f634588 Author: Pengpeng Hou Date: Thu Jun 25 13:42:59 2026 +0800 iio: temperature: Build mlx90635 with CONFIG_MLX90635 commit 63a76e3a587c4143e8e24e8a6b0c232fa0676034 upstream. drivers/iio/temperature/Kconfig has a dedicated MLX90635 option, but the Makefile currently builds mlx90635.o under CONFIG_MLX90632. This means enabling CONFIG_MLX90635 alone does not carry its provider object into the build, while enabling CONFIG_MLX90632 unexpectedly also builds mlx90635.o. Gate mlx90635.o on the matching generated Kconfig symbol. Fixes: a1d1ba5e1c28 ("iio: temperature: mlx90635 MLX90635 IR Temperature sensor") Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou Reviewed-by: Andy Shevchenko Acked-by: Crt Mori Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 7d4d60f7c0541862f64df79d09cc978c4ec78049 Author: Stepan Ionichev Date: Fri May 15 18:31:38 2026 +0500 iio: resolver: ad2s1210: notify trigger and clear state on fault read error commit 70247658d0e783c93b48fcbc3b81d99e992ff478 upstream. ad2s1210_trigger_handler() walks several scan-mask branches and uses "goto error_ret" to land on the iio_trigger_notify_done() teardown at the bottom of the function for every I/O error -- except the MOD_CONFIG fault-register read, which uses a bare "return ret": if (st->fixed_mode == MOD_CONFIG) { unsigned int reg_val; ret = regmap_read(st->regmap, AD2S1210_REG_FAULT, ®_val); if (ret < 0) return ret; ... } Two problems on that path: - the handler returns a negative errno where the prototype expects an irqreturn_t (IRQ_HANDLED / IRQ_NONE), so the caller in the IIO core sees a value outside the enum; - iio_trigger_notify_done() is skipped, leaving the trigger busy-flag set. A single transient SPI/regmap error on the fault read then wedges the trigger so subsequent samples are dropped until the consumer is detached. Convert the error path to "goto error_ret" so the failure path goes through the same notify_done() teardown as every other error in the handler. Fixes: f9b9ff95be8c ("iio: resolver: ad2s1210: add support for adi,fixed-mode") Signed-off-by: Stepan Ionichev Reviewed-by: David Lechner Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit c6ca87c7bbb3f6d45413d35da0446a080269ca36 Author: Stepan Ionichev Date: Thu May 14 19:37:10 2026 +0500 iio: proximity: vl53l0x: notify trigger and clear IRQ on error paths commit be843b0579f872ec7590d825e2c9a656d4790c4b upstream. vl53l0x_trigger_handler() returns directly on the I2C read failure paths without calling iio_trigger_notify_done() or vl53l0x_clear_irq(). A single transient i2c_smbus_read_i2c_block_data() failure (negative errno or a short read) therefore leaves two pieces of state behind: - iio_trigger_notify_done() never decrements the trigger's use_count, so iio_trigger_poll_nested() silently drops further dispatches (see industrialio-trigger.c, the !atomic_read(&trig->use_count) guard); - vl53l0x_clear_irq() never writes SYSTEM_INTERRUPT_CLEAR, so the chip keeps the DRDY interrupt asserted. The sensor's buffer mode stays wedged from then on, recoverable only by re-binding the driver. The sibling driver vl53l1x-i2c.c handles exactly the same case correctly by jumping to a "notify_and_clear_irq" label that always calls both helpers; mirror that here. The bogus negative-int return value cast to irqreturn_t also goes away as a side effect. Fixes: 762186c6e7b1 ("iio: proximity: vl53l0x-i2c: Added continuous mode support") Signed-off-by: Stepan Ionichev Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit b3f1af4ba8e9cf33aa08c4cdcaa5a17b140521ec Author: Biren Pandya Date: Sun Jun 14 12:45:48 2026 +0530 iio: pressure: mpl115: fix runtime PM leak on read error commit fbe67ff37a6fd855a6c097f84f3738bd13d0a898 upstream. mpl115_read_raw() takes a runtime PM reference with pm_runtime_get_sync() before reading the processed pressure or raw temperature, but on the read error path it returns without calling pm_runtime_put_autosuspend(). Each failed read therefore leaks a runtime PM reference and prevents the device from autosuspending. Drop the reference before checking the return value so both the success and error paths are balanced. Fixes: 0c3a333524a3 ("iio: pressure: mpl115: Implementing low power mode by shutdown gpio") Signed-off-by: Biren Pandya Assisted-by: Claude:claude-opus-4-8 coccinelle Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit e2d5b9673bf712836186664dc18df6e63a5048e5 Author: David Carlier Date: Tue May 5 18:34:55 2026 +0100 iio: pressure: bmp280: zero-init bmp580 trigger handler buffer commit 1172160f2a2de7bade3bec64b8c5ecf945cde5ed upstream. bmp580_trigger_handler() builds an on-stack scan buffer containing two __le32 fields and an aligned_s64 timestamp, and pushes it to userspace via iio_push_to_buffers_with_ts(). However, only the low 3 bytes of each __le32 field are populated by the device data: memcpy(&buffer.comp_press, &data->buf[3], 3); memcpy(&buffer.comp_temp, &data->buf[0], 3); The high byte of each field is left uninitialised on the stack. The bmp580 channels declare storagebits = 32, so the IIO core transports all four bytes per sample to userspace as part of the scan element, leaking two bytes of kernel stack per scan. Zero-initialise the buffer before populating it, mirroring the fix applied to bme280_trigger_handler() in commit 018f50909e66 ("iio: bmp280: zero-init buffer"). Fixes: 872c8014e05e ("iio: pressure: bmp280: drop sensor_data array") Cc: stable@vger.kernel.org Signed-off-by: David Carlier Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit f829d6c32f31bee77a1a3a0e368cab0b841d40b4 Author: Andy Shevchenko Date: Wed May 6 10:27:55 2026 +0200 iio: magnetometer: ak8975: Add missed pm_runtime_put_autosuspend() call commit e94944d7364d3ddb273539492f9bd9c9a622549a upstream. On the failure in the ak8975_read_axis() the PM runtime gets unbalanced. Balance it by calling pm_runtime_put_autosuspend() on error path as well. Fixes: cde4cb5dd422 ("iio: magn: ak8975: deploy runtime and system PM") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260505-magnetometer-fixes-v5-0-831b9b5550fc%40gmail.com Signed-off-by: Andy Shevchenko Reviewed-by: Joshua Crofts Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 0975e013179d30b87c4f0beabdf750565f5e345a Author: Javier Carrasco Date: Thu May 14 14:01:11 2026 +1300 iio: light: veml6030: fix channel type when pushing events commit c52bb33b641ebaae3e209f97714cb1758206f7d9 upstream. The events are registered for IIO_LIGHT and not for IIO_INTENSITY. Use the correct channel type. When at it, fix minor checkpatch code style warning (alignment). Cc: stable@vger.kernel.org Fixes: 7b779f573c48 ("iio: light: add driver for veml6030 ambient light sensor") Signed-off-by: Javier Carrasco Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit ef6c2a521454fdd9aedba24fdce89f434283a304 Author: Stepan Ionichev Date: Mon May 18 14:43:11 2026 +0500 iio: light: tsl2591: return actual error from probe IRQ failure commit a00ffd15674bfaf8b906503c1600e3d8709af56c upstream. When devm_request_threaded_irq() fails, probe logs the error and then returns -EINVAL, dropping the real error code and breaking the deferred-probe flow for -EPROBE_DEFER. Return ret directly; the IRQ subsystem already prints on failure. Fixes: 2335f0d7c790 ("iio: light: Added AMS tsl2591 driver implementation") Cc: stable@vger.kernel.org Signed-off-by: Stepan Ionichev Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 9d421c2827ea176dab1ca472921510eadd74afdb Author: Joshua Crofts Date: Tue May 26 13:15:29 2026 +0200 iio: light: opt3001: fix missing state reset on timeout commit c123ca6ee26ad98f70a866ff428b08145c5a24fe upstream. Currently in the function opt3001_get_processed(), there is a check that directly returns -ETIMEDOUT if the conversion IRQ times out, completely bypassing the err label, leaving ok_to_ignore_lock permanently true, potentially breaking the device's falling threshold interrupt detection. Assign -ETIMEDOUT to the return variable and jump to the error label to ensure ok_to_ignore_lock is properly reset. Fixes: 26d90b559057 ("iio: light: opt3001: Fixed timeout error when 0 lux") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260525-opt3001-cleanup-v4-0-65b36a174f78%40gmail.com?part=1 Signed-off-by: Joshua Crofts Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 0c655d067ac69ee24e2e9d706c54179ea58a43db Author: Biren Pandya Date: Sun Jun 14 12:45:49 2026 +0530 iio: light: gp2ap002: fix runtime PM leak on read error commit 38b72267b7e22768a1f26d9935de4e1752a1dc85 upstream. gp2ap002_read_raw() calls pm_runtime_get_sync() before reading the lux value, but if gp2ap002_get_lux() fails, it returns directly. This skips the pm_runtime_put_autosuspend() call at the "out" label, permanently leaking a runtime PM reference and preventing the device from autosuspending. Replace the direct return with a "goto out" to ensure the reference is properly dropped on the error path. Fixes: f6dbf83c17cb ("iio: light: gp2ap002: Take runtime PM reference on light read") Signed-off-by: Biren Pandya Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit a60bf629a760d176e22182302284f1314db8c76b Author: Alexander A. Klimov Date: Sat May 23 13:44:58 2026 +0200 iio: light: al3320a: read both ALS ADC registers again commit 744bccc2647c6b2206290e8e40890a23812116b3 upstream. al3320a_read_raw() used to read two adjacent registers until the driver was modernized using the regmap framework. That cleanup accidentally replaced the 16-bit word read with a single byte read. I'm reverting latter. Fixes: 1850e6ae7f91 ("iio: light: al3320a: Implement regmap support") Signed-off-by: Alexander A. Klimov Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit a1dafc918d793274fd5b14cdf2eae65371dd1f2a Author: Joshua Crofts Date: Thu Jun 25 21:38:10 2026 +0200 iio: light: al3320a: add missing REGMAP_I2C to Kconfig commit 9efcc9ba9b2e940cc01e63d132ae741e4c5d09c7 upstream. The Kconfig entry for the al3320a is missing a `select REGMAP_I2C`, causing build failures. Fixes: 1850e6ae7f91 ("iio: light: al3320a: Implement regmap support") Signed-off-by: Joshua Crofts Reviewed-by: Andy Shevchenko Reviewed-by: David Heidelberg Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit a00d471cf3580d033bdabc196b09c4ccabff64aa Author: Alexander A. Klimov Date: Sat May 23 13:44:57 2026 +0200 iio: light: al3010: read both ALS ADC registers again commit ee78fae068f52a5582aaf448d9414f826855c106 upstream. al3010_read_raw() used to read two adjacent registers until the driver was modernized using the regmap framework. That cleanup accidentally replaced the 16-bit word read with a single byte read. I'm reverting latter. Fixes: 0e5e21e23dd6 ("iio: light: al3010: Implement regmap support") Signed-off-by: Alexander A. Klimov Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit cd278561640c716b2eff0b0143fd02cc9ee8b437 Author: Vidhu Sarwal Date: Sat Jul 4 17:22:45 2026 +0530 iio: light: al3010: fix incorrect scale for the highest gain range commit aa411adc6ce40ad1a55ebc965f255a4cfc0005f8 upstream. al3010_scales[] encodes the highest gain range as {0, 1187200}. For IIO_VAL_INT_PLUS_MICRO, the fractional part must be less than 1000000, so the scale 1.1872 should instead be represented as { 1, 187200 }. Since write_raw() compares the value from userspace against this table, writing the advertised 1.1872 scale never matches the malformed entry and returns -EINVAL. As a result, the highest gain range cannot be selected. Reading the scale in that state also reports the malformed value. Fixes: c36b5195ab70 ("iio: light: add Dyna-Image AL3010 driver") Signed-off-by: Vidhu Sarwal Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 9fb4ff07d97e33eab5dd33dcb8188156215cff6b Author: Joshua Crofts Date: Thu Jun 25 21:38:09 2026 +0200 iio: light: al3010: add missing REGMAP_I2C to Kconfig commit 84486e3bbda18a2df1ed74ca78e1e14bde9a941b upstream. The KConfig entry for the AL3010 is missing a `select REGMAP_I2C`, causing build failures. Fixes: 0e5e21e23dd6 ("iio: light: al3010: Implement regmap support") Signed-off-by: Joshua Crofts Reviewed-by: Andy Shevchenko Reviewed-by: David Heidelberg Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 6afb69bb969ed1ea22612bf6cd44f16fe68e1d47 Author: Joshua Crofts Date: Thu Jun 25 21:38:08 2026 +0200 iio: light: al3000a: add missing REGMAP_I2C to Kconfig commit a2d30022b7c316ad845d1b696e724058b88e5a4e upstream. The KConfig entry for the al3000a is missing a `select REGMAP_I2C`, causing build failures. Fixes: d531b9f78949 ("iio: light: Add support for AL3000a illuminance sensor") Signed-off-by: Joshua Crofts Reviewed-by: Andy Shevchenko Reviewed-by: David Heidelberg Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 482b24660ec3b4b4a0991472508e5549410b5c08 Author: Andreas Kempe Date: Thu Jul 2 10:41:23 2026 +0000 iio: imu: st_lsm6dsx: deselect shub page before reading whoami commit aede83625ff5d9539508582036df30c809d51058 upstream. As part of driver initialization, e.g. st_lsm6dsx_init_shub() selects the shub register page using st_lsm6dsx_set_page(). Selecting the shub register page shadows the regular register space so whoami, among other registers, is no longer accessible. In applications where the IMU is permanently powered separately from the processor, there is a window where a reset of the CPU leaves the IMU in the shub register page. Once this occurs, any subsequent probe attempt fails because of the register shadowing. Using the ism330dlc, the error typically looks like st_lsm6dsx_i2c 3-006a: unsupported whoami [10] with the unknown whoami read from a reserved register in the shub page. The reset register is also shadowed by the page select, preventing a reset from recovering the chip. Unconditionally clear the shub page before the whoami readout to ensure normal register access and allow the initialization to proceed. Place the fix in st_lsm6dsx_check_whoami() before the whoami check because hw->settings, which st_lsm6dsx_set_page() relies on, is first assigned in that function. Placing the fix in a more logical place than the whoami check would require a bigger restructuring of the code. Fixes: c91c1c844ebd ("iio: imu: st_lsm6dsx: add i2c embedded controller support") Signed-off-by: Andreas Kempe Acked-by: Lorenzo Bianconi Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 76e12a71ac0538560e1e497e1dc9bbf4b4451e9c Author: Jean-Baptiste Maneyrol Date: Mon Jun 29 21:51:55 2026 +0200 iio: imu: inv_icm42600: fix timestamping by limiting FIFO reading commit affe3f077d7a4eeb25937f5323ff059a54b4712c upstream. Timestamps are made by measuring the chip clock using the watermark interrupts. If we read more than watermark samples as done today, we are reducing the period between interrupts and distort the time measurement. Fix that by reading only watermark samples in the interrupt case. Fixes: 7f85e42a6c54 ("iio: imu: inv_icm42600: add buffer support in iio devices") Cc: stable@vger.kernel.org Signed-off-by: Jean-Baptiste Maneyrol Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 34656a59322e5951bb346728adf4e53ff9e74740 Author: Jean-Baptiste Maneyrol Date: Tue Jun 23 16:22:15 2026 +0200 iio: imu: inv_icm42600: fix timestamp clock period by using lower value commit 8b0b864c11a2e2ada470f9d5010e1c2bf1eceef2 upstream. Clock period value is used for computing periods of sampling. There is no need for it to be higher than the maximum odr, otherwise we are losing precision in the computation for nothing. Switch clock period value to maximum odr period (8kHz). Fixes: 0ecc363ccea7 ("iio: make invensense timestamp module generic") Cc: stable@vger.kernel.org Signed-off-by: Jean-Baptiste Maneyrol Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 0522819228284eab9ec91fa4258c37fa8eb160a2 Author: Runyu Xiao Date: Thu Jun 4 09:42:47 2026 +0800 iio: imu: bmi160: add IRQF_NO_THREAD to data-ready trigger IRQ commit cd5a6a5096b246e10600da3ac47a1274ce9573c8 upstream. bmi160_probe_trigger() registers iio_trigger_generic_data_rdy_poll() through devm_request_irq(), but it passes only irq_type and does not add IRQF_NO_THREAD. When the kernel is booted with forced IRQ threading, the parent IRQ can otherwise be threaded by the IRQ core and the subsequent IIO trigger child IRQ is dispatched from irq/... thread context instead of hardirq context. Because the handler immediately pushes the event into iio_trigger_poll(), this violates the hardirq-only IIO trigger helper contract and can drive downstream trigger consumers through the wrong execution context. Add IRQF_NO_THREAD on top of irq_type when registering the BMI160 data- ready trigger handler. Fixes: 895bf81e6bbf ("iio:bmi160: add drdy interrupt support") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit bdafd53ae671ed38ff2c1a4c88ce0fbc60e92f6f Author: Runyu Xiao Date: Thu Jun 4 09:42:46 2026 +0800 iio: imu: adis: add IRQF_NO_THREAD to non-FIFO trigger IRQ commit 6e1b9bff1202da55c464e36bd34a2b6863d7fe30 upstream. devm_adis_probe_trigger() registers iio_trigger_generic_data_rdy_poll() through devm_request_irq() on the non-FIFO path, but it does not add IRQF_NO_THREAD to the IRQ flags. When the kernel is booted with forced IRQ threading, the parent IRQ can otherwise be threaded by the IRQ core and the subsequent IIO trigger child IRQ is then dispatched from irq/... thread context instead of hardirq context. Because iio_trigger_generic_data_rdy_poll() immediately drives iio_trigger_poll(), this violates the hardirq-only IIO trigger helper contract and can push downstream trigger consumers through the wrong execution context. Add IRQF_NO_THREAD on top of the existing adis->irq_flag value for the non-FIFO request_irq() path, while preserving the current trigger polarity and IRQF_NO_AUTOEN behavior. Fixes: fec86c6b8369 ("iio: imu: adis: Add Managed device functions") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 001527e2382e31d948415818f425b2d4b7da012e Author: Stepan Ionichev Date: Mon May 11 11:40:20 2026 +0500 iio: gyro: bmg160: wait full startup time after mode change at probe commit 088fcb9b567f8723074ad9eb1bf5cb46f8a0096b upstream. bmg160_chip_init() calls bmg160_set_mode(BMG160_MODE_NORMAL) and then waits only 500-1000 us. Per the BMG160 datasheet (BST-BMG160-DS000-07 Rev. 1.0, May 2013), the start-up and wake-up times (tsu, twusm) are 30 ms. The same file already waits BMG160_MAX_STARTUP_TIME_MS (80 ms) in bmg160_runtime_resume() after the same set_mode(NORMAL) operation. The 500 us value at probe was likely a unit mix-up; the old comment said "500 ms" while the code used microseconds. Reuse the same constant via msleep() and add a code comment explaining the datasheet basis for the wait. Without this, register writes that follow the mode change can hit the chip before it is ready. Fixes: 22b46c45fb9b ("iio:gyro:bmg160 Gyro Sensor driver") Signed-off-by: Stepan Ionichev Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 7bbf02b63961fc1768c9c654392c11f2077d4c59 Author: Stepan Ionichev Date: Sun May 10 07:35:00 2026 +0500 iio: gyro: bmg160: bail out when bandwidth/filter is not in table commit 8320c77e67382d5d55d77043a5f60a867d408a2b upstream. bmg160_get_filter() walks bmg160_samp_freq_table[] looking for the entry matching the bw_bits value read from the chip: for (i = 0; i < ARRAY_SIZE(bmg160_samp_freq_table); ++i) { if (bmg160_samp_freq_table[i].bw_bits == bw_bits) break; } *val = bmg160_samp_freq_table[i].filter; If no entry matches, i ends up equal to the array size and the next line reads one slot past the end. bmg160_set_filter() has the same shape, driven by 'val' instead of bw_bits. smatch flags both: drivers/iio/gyro/bmg160_core.c:204 bmg160_get_filter() error: buffer overflow 'bmg160_samp_freq_table' 7 <= 7 drivers/iio/gyro/bmg160_core.c:222 bmg160_set_filter() error: buffer overflow 'bmg160_samp_freq_table' 7 <= 7 Return -EINVAL when no entry matches. The set_filter() path is reachable from userspace via the sysfs in_anglvel_filter_low_pass_3db_frequency interface, so userspace can trivially trigger the out-of-bounds read with a value that is not in bmg160_samp_freq_table[].filter. Fixes: 22b46c45fb9b ("iio:gyro:bmg160 Gyro Sensor driver") Signed-off-by: Stepan Ionichev Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 9edefd4c56bee3fe331e0355d1f10a533134999d Author: Lars-Peter Clausen Date: Mon Jul 6 21:48:26 2026 -0700 iio: event: Fix event FIFO reset race commit af791d295737ea6b6ff2c8d8488462a49c14af01 upstream. `iio_event_getfd()` creates the event file descriptor with `anon_inode_getfd()`, which allocates a new fd, creates the anonymous file and installs it in the process fd table before returning to the caller. The IIO code resets the event FIFO after `anon_inode_getfd()` has returned, but before `IIO_GET_EVENT_FD_IOCTL` has copied the fd number to userspace. But since fd tables are shared between threads, another thread can guess the newly allocated fd number and issue a `read()` on it as soon as the fd has been installed. This means the `kfifo_to_user()` in `iio_event_chrdev_read()` can run in parallel with the `kfifo_reset_out()` in `iio_event_getfd()`. The kfifo documentation says that `kfifo_reset_out()` is only safe when it is called from the reader thread and there is only one concurrent reader. Otherwise it is dangerous and must be handled in the same way as `kfifo_reset()`. If that happens, `kfifo_to_user()` can advance the FIFO `out` index based on state from before the reset, after the reset has already moved the `out` index to the current `in` index. That can leave the FIFO with an `out` index past the `in` index. A later `read()` can then see an underflowed FIFO length and copy more data than the event FIFO buffer contains. This can result in an out-of-bounds read and leak adjacent kernel memory to userspace. Move the FIFO reset before `anon_inode_getfd()`. At that point the event fd is marked busy, but the new fd has not been installed yet, so userspace cannot access it while the FIFO is reset. Fixes: b91accafbb10 ("iio:event: Fix and cleanup locking") Reported-by: Codex:gpt-5.5 Signed-off-by: Lars-Peter Clausen Reviewed-by: Nuno Sá Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 2358da87315d117e9e5134afc1d2a18fa2da72f8 Author: Dan Carpenter Date: Mon May 25 10:15:46 2026 +0300 iio: dac: ad3552r-hs: fix uninitialized data ni ad3552r_hs_write_data_source() commit eaaa7eef181892ef7ba56c6295b81f0ae4492c13 upstream. If the *ppos value is non-zero then the simple_write_to_buffer() function won't initialized the start of the buf[] buffer. Non-zero values for *ppos won't work here generally, so just test for them and return -ENOSPC at the start of the function. Fixes: b1c5d68ea66e ("iio: dac: ad3552r-hs: add support for internal ramp") Signed-off-by: Dan Carpenter Reviewed-by: Angelo Dureghello Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit e166a8cfb28a3d0da260dd70cae274eb8c7cec8d Author: Dan Carpenter Date: Mon May 25 10:16:27 2026 +0300 iio: core: fix uninitialized data in debugfs commit ab92ed206d41fd171ebd37bc46360d9f2140d043 upstream. If *ppos is non-zero then simple_write_to_buffer() will not initialize the start of buf[]. Non zero values for *ppos aren't going to work anyway. Test for them at the start of the function and return -EINVAL. Fixes: 6d5dd486c715 ("iio: core: make use of simple_write_to_buffer()") Signed-off-by: Dan Carpenter Reviewed-by: Maxwell Doose Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit b947bde73461ff523da014462f8de043e2cbd4e5 Author: Herman van Hazendonk Date: Tue Jun 16 15:02:04 2026 +0200 iio: common: st_sensors: honour channel endianness in read_axis_data commit 55052184ac9011db2ea983e54d6c21f0b1079a12 upstream. st_sensors_read_axis_data() unconditionally decoded multi-byte results with get_unaligned_le16() / get_unaligned_le24() regardless of the channel's declared scan_type.endianness. For every ST sensor that has used this helper since it was introduced this happened to be fine because the ST IMU/accel/gyro/pressure families publish their data registers as little-endian and the channel specs in those drivers declare IIO_LE accordingly. The LSM303DLH magnetometer however publishes its X/Y/Z output as a pair of big-endian bytes (the H register sits at the lower address, 0x03/0x05/0x07, and the L register immediately after), and its channel specs in st_magn_core.c correctly declare IIO_BE -- but read_axis_data() ignored that and decoded as little-endian, swapping the high and low bytes of every magnetometer sample. The LSM303DLHC and LSM303DLM share the same st_magn_16bit_channels (IIO_BE) and were therefore byte-swapped by the same bug; users of those parts will see different in_magn_*_raw values after this fix lands. The bug is most visible on a stationary chip: in earth's field the true X reading is small and the high byte sits at 0x00, so swapping the bytes pins sysfs X at exactly the low byte's pattern (e.g. 0x00F0 = 240). Y and Z still appear "to vary" because their magnitudes are larger and the noise in the low byte produces big swings in the swapped high byte: before (LSM303DLH flat, sysfs in_magn_*_raw): X=240 (stuck), Y= 12032..23296, Z=-16128..-9728 after (direct i2c-dev big-endian decode, same chip same orientation): X≈-4096, Y≈210, Z≈80 (sensible values reflecting earth's ambient field at low gauss range) Fix read_axis_data() to dispatch on ch->scan_type.endianness and call get_unaligned_be16() / get_unaligned_be24() when the channel declares IIO_BE. Existing IIO_LE consumers (st_accel, st_gyro, st_pressure, st_lsm6dsx and others) are unaffected because their channel specs already declare IIO_LE and the LE path is unchanged. While restructuring the branches, replace the previously implicit silent-success-with-uninitialised-*data fall-through for byte_for_channel outside 1..3 with an explicit return -EINVAL. No in-tree ST sensor publishes such a channel, but the new behaviour is strictly safer than handing userspace garbage. Fixes: 23491b513bcd ("iio:common: Add STMicroelectronics common library") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 sparse smatch clang-analyzer coccinelle checkpatch Assisted-by: Sashiko:claude-opus-4-7 Signed-off-by: Herman van Hazendonk Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 82accdd57404399eddf3d56fd9beda7c61307388 Author: Maxwell Doose Date: Tue May 26 17:55:24 2026 -0500 iio: chemical: scd30: Cleanup initializations and fix sign-extension bug commit 60d877910a43c305b5165131b258a17b1d772d57 upstream. Include linux/bitfield.h for FIELD_GET(). Create new macros for bit manipulation in combination with manual bit manipulation being replaced with FIELD_GET(). The current variable declaration and initializations are barely readable and use comma separations across multiple lines. Refactor the initializations so that mantissa and exp have separate declarations and sign gets initialized later. In addition (and due to the nature of the cleanup), fix a sign-extension bug where, float32 would get bitwise anded with ~BIT(31) (which is 0xFFFFFFFF7FFFFFFF) which corrupted the exponent. Fixes: 64b3d8b1b0f5c ("iio: chemical: scd30: add core driver") Reported-by: sashiko Closes: https://sashiko.dev/#/patchset/20260524020309.18618-1-m32285159%40gmail.com Signed-off-by: Maxwell Doose Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit c28835b8618ecb288605ba139c7d192f6d239cc4 Author: Dan Carpenter Date: Mon May 25 10:16:11 2026 +0300 iio: backend: fix uninitialized data in debugfs commit a6e8b14a4897d0b6df9744f33d0a30e6b92368eb upstream. If the *ppos value is non-zero then simple_write_to_buffer() will not initialize the start of the buf[] buffer. Non-zero ppos values aren't going to work at all. Check for that at the start of the function and return -ENOSPC. Fixes: cdf01e0809a4 ("iio: backend: add debugFs interface") Signed-off-by: Dan Carpenter Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 0f30e68dd6c1f5c6451de7e0f0b3bc79f9d12ba4 Author: Pengpeng Hou Date: Thu Jun 25 13:44:07 2026 +0800 iio: adc: ti-ads124s08: Return reset GPIO lookup errors commit 7dc4de2aa6316f1d044cde21f5acfec5f3ec6b47 upstream. devm_gpiod_get_optional() returns NULL when the optional GPIO is absent, but returns an ERR_PTR when the GPIO provider lookup fails, including probe deferral. Probe currently logs the ERR_PTR case as if the reset GPIO were simply absent and keeps the error pointer in reset_gpio. Later ads124s_reset() treats any non-NULL reset_gpio as a valid descriptor and passes it to gpiod_set_value_cansleep(). Return the lookup error instead of retaining the ERR_PTR. Fixes: e717f8c6dfec ("iio: adc: Add the TI ads124s08 ADC code") Cc: stable@vger.kernel.org Reviewed-by: Joshua Crofts Signed-off-by: Pengpeng Hou Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit ffb2195921c3d629194b9807de589578df9f9cb8 Author: Guangshuo Li Date: Wed Jun 3 20:16:40 2026 +0800 iio: adc: ti-ads1119: fix PM reference leak in buffer preenable commit adf4bc07f814da8329278d32600147f5a150938c upstream. ads1119_triggered_buffer_preenable() resumes the device with pm_runtime_resume_and_get() before starting a conversion. If i2c_smbus_write_byte() fails, the function returns the error directly and leaves the runtime PM usage counter elevated. The matching postdisable callback is not called when preenable fails, so the reference is leaked and the device may remain runtime-active indefinitely. Store the I2C transfer result in ret and drop the runtime PM reference on failure before returning the error. Fixes: a9306887eba41 ("iio: adc: ti-ads1119: Add driver") Signed-off-by: Guangshuo Li Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit bbfebae473ac2c8a194523b29ccb9b45f02f134c Author: Maxwell Doose Date: Fri Jun 12 19:58:11 2026 -0500 iio: adc: spear: Initialize completion before requesting IRQ commit 3ee2128b6f0eb0be7b6cb8f6e0f1f113a65201a0 upstream. In the report from Jaeyoung Chung: "spear_adc_probe() in drivers/iio/adc/spear_adc.c registers its interrupt handler with devm_request_irq() before it initializes st->completion with init_completion(). If an interrupt arrives after devm_request_irq() and before init_completion(), the handler calls complete() on an uninitialized completion, causing a kernel panic. The probe path, in spear_adc_probe(): iodev = devm_iio_device_alloc(&pdev->dev, sizeof(*st)); /* st kzalloc-zeroed */ ... retval = devm_request_irq(&pdev->dev, irq, spear_adc_isr, 0, LPC32XXAD_NAME, st); /* register handler */ ... init_completion(&st->completion); /* initialize completion */ spear_adc_isr() calls complete(): complete(&st->completion); If the device raises an interrupt before init_completion() runs, complete() acquires the uninitialized wait.lock and walks the zeroed task_list in swake_up_locked(). The zeroed task_list makes list_empty() return false, so swake_up_locked() dereferences a NULL list entry, triggering a KASAN wild-memory-access." Fix the chance of a spurious IRQ causing an uninitialized pointer dereference by moving init_completion() above devm_request_irq(). Fixes: b586e5d9eee0 ("staging:iio:adc:spear rename device specific state structure to _state") Reported-by: Sangyun Kim Reported-by: Kyungwook Boo Reported-by: Jaeyoung Chung Closes: https://lore.kernel.org/linux-iio/20260610115700.774689-1-jjy600901@snu.ac.kr/ Signed-off-by: Maxwell Doose Reviewed-by: Vladimir Zapolskiy Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 9e2e8b8cdfd37ae7c7a8a5c96c59e98a768731c4 Author: Maxwell Doose Date: Fri Jun 12 19:58:10 2026 -0500 iio: adc: lpc32xx: Initialize completion before requesting IRQ commit e561b35633f450ee607e87a6401d97f156a0cd54 upstream. In the report from Jaeyoung Chung: "lpc32xx_adc_probe() in drivers/iio/adc/lpc32xx_adc.c registers its interrupt handler with devm_request_irq() before it initializes st->completion with init_completion(). If an interrupt arrives after devm_request_irq() and before init_completion(), the handler calls complete() on an uninitialized completion, causing a kernel panic. The probe path, in lpc32xx_adc_probe(): iodev = devm_iio_device_alloc(&pdev->dev, sizeof(*st)); /* st kzalloc-zeroed */ ... retval = devm_request_irq(&pdev->dev, irq, lpc32xx_adc_isr, 0, LPC32XXAD_NAME, st); /* register handler */ ... init_completion(&st->completion); /* initialize completion */ lpc32xx_adc_isr() calls complete(): complete(&st->completion); If the device raises an interrupt before init_completion() runs, complete() acquires the uninitialized wait.lock and walks the zeroed task_list in swake_up_locked(). The zeroed task_list makes list_empty() return false, so swake_up_locked() dereferences a NULL list entry, triggering a KASAN wild-memory-access." Fix the chance of a spurious IRQ causing an uninitialized pointer dereference by moving init_completion() above devm_request_irq(). Fixes: 7901b2a1453e ("staging:iio:adc:lpc32xx rename local state structure to _state") Reported-by: Sangyun Kim Reported-by: Kyungwook Boo Reported-by: Jaeyoung Chung Closes: https://lore.kernel.org/linux-iio/20260610115700.774689-1-jjy600901@snu.ac.kr/ Signed-off-by: Maxwell Doose Reviewed-by: Vladimir Zapolskiy Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit c313bb7c38855e94ceef939d152dd75e5a904b5f Author: Radu Sabau Date: Wed May 27 12:38:38 2026 +0300 iio: adc: ad_sigma_delta: fix CS held asserted and state leaks commit c72da0688575e5ef39c36bb44fed53aa18f8ae65 upstream. In ad_sigma_delta_single_conversion(), set_mode(AD_SD_MODE_IDLE) and disable_one() were called from the out: block while keep_cs_asserted was still true. This caused any SPI transfer issued by those callbacks to carry cs_change=1, leaving CS permanently asserted after the conversion. Fix by moving both calls into the out_unlock: block, after keep_cs_asserted is cleared, matching the pattern already used in ad_sd_calibrate(). In the error path of ad_sd_buffer_postenable(), if an operation fails after set_mode(AD_SD_MODE_CONTINUOUS) has already succeeded (e.g. spi_offload_trigger_enable()), the device is left in continuous conversion mode with CS physically asserted. Additionally, bus_locked remaining true after spi_bus_unlock() causes subsequent SPI operations to call spi_sync_locked() without the bus lock actually held, allowing concurrent SPI access. Fix the error path by clearing keep_cs_asserted first, then calling set_mode(AD_SD_MODE_IDLE) to revert the device mode and deassert CS, then clearing bus_locked before releasing the bus. For devices that implement neither set_mode nor disable_one (such as MAX11205, which has no physical CS pin), no SPI transfer is issued during cleanup and the cs_change flag has no effect on any physical line. Fixes: 132d44dc6966 ("iio: adc: ad_sigma_delta: Check for previous ready signals") Signed-off-by: Radu Sabau Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 3394e0b3328422431cadaf314fa58d3717ed4936 Author: Radu Sabau Date: Wed May 27 12:38:39 2026 +0300 iio: adc: ad_sigma_delta: fix clear_pending_event for registerless devices commit 91bc6767a4f55dc470d8a56b55b9f2ea09094efe upstream. ad_sigma_delta_clear_pending_event() falls through to the status register read path for devices with has_registers = false and no rdy_gpiod. For such devices, ad_sd_read_reg() skips the address byte entirely and clocks raw MISO bytes with no address phase — making it byte-for-byte identical to reading conversion data. If a pending conversion result is present, this partially consumes it and corrupts the data stream for the subsequent ad_sd_read_reg() call in ad_sigma_delta_single_conversion(). Furthermore, with num_resetclks = 0 on these devices, data_read_len evaluates to 0. If the clocked byte has bit 7 clear, pending_event is set and the code attempts memset(data + 2, 0xff, 0 - 1), overflowing to SIZE_MAX and corrupting the heap. Fix by returning 0 immediately when neither rdy_gpiod nor has_registers is set. This is safe for all current registerless devices: ad7191 and ad7780 (with powerdown GPIO) are reset between conversions by CS deassertion, so there is no stale result to drain; ad7780 (without powerdown GPIO) and max11205 are continuously-converting and cycle ~DRDY at the output data rate regardless of whether the previous result was read, so the next falling edge fires naturally. A future registerless device that holds ~DRDY asserted until data is read would be broken by this early return and would require either num_resetclks set or a rdy-gpio. The same heap corruption is reachable on any device with rdy_gpiod set but num_resetclks = 0: if the GPIO indicates a pending event, the drain path executes memset(data + 2, 0xff, 0 - 1) regardless of has_registers. Add an explicit data_read_len == 0 guard after the pending event check; the stale result is then consumed by the first ad_sd_read_reg() call in ad_sigma_delta_single_conversion(). Fixes: 132d44dc6966 ("iio: adc: ad_sigma_delta: Check for previous ready signals") Signed-off-by: Radu Sabau Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 46e93fcbe7c2caa80c83da260158c71ec915bc88 Author: Joshua Crofts Date: Wed Jul 1 21:21:47 2026 +0200 iio: adc: ad7779: add missing 'select IIO_TRIGGERED_BUFFER' to Kconfig commit fd354554af1d2b33232ca6c8a3d79ed82413d715 upstream. The Kconfig entry for the AD7779 is missing a 'select IIO_TRIGGERED_BUFFER' parameter, causing build failures. Fixes: c9a3f8c7bfcb ("drivers: iio: adc: add support for ad777x family") Cc: stable@vger.kernel.org Signed-off-by: Joshua Crofts Tested-by: Andy Shevchenko Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 24a9514b606e76499ec85e7cba95d3f146dfe5d0 Author: Jonathan Cameron Date: Sun Jan 11 16:55:28 2026 +0000 iio: adc: ad7768-1: Select GPIOLIB commit 5a9c90350be4f6f175bdd193e8bd60a7aedfb4d2 upstream. This driver provides a gpio chip a some related functions are not stubbed if GPIOLIB is not built. ad7768-1.c:420: undefined reference to `gpiochip_get_data' ad7768-1.c:498: undefined reference to `devm_gpiochip_add_data_with_key' Dual sign off reflects change of affiliation whilst this was under review. Fixes: d569ae0f052e ("iio: adc: ad7768-1: Add GPIO controller support") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202512271235.WwAmAbOa-lkp@intel.com/ Signed-off-by: Jonathan Cameron Cc: Stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit e6ade81631d7621b9e95c3f8596b62ae90c89395 Author: Samuel Moelius Date: Tue Jun 2 16:45:39 2026 +0000 iio: adc: ad7380: select REGMAP commit 6697091b386a4e2830bdd38512c87a4befff2b32 upstream. The AD7380 driver uses generic regmap types and APIs. However, its Kconfig entry does not select REGMAP. As a result, AD7380 can be enabled from an allnoconfig-derived config with SPI_MASTER=y while REGMAP remains unset, causing ad7380.o to fail to build. Fixes: b095217c104b ("iio: adc: ad7380: new driver for AD7380 ADCs") Signed-off-by: Samuel Moelius Reviewed-by: Andy Shevchenko Reviewed-by: Nuno Sá Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 6293211d142605bec435229ef0aa3668b8964164 Author: Biren Pandya Date: Sun Jun 14 12:45:46 2026 +0530 iio: accel: kxsd9: fix runtime PM imbalance on write_raw() error commit 44a5fd874bb6873bdaec59f722c1d57832fbc9df upstream. kxsd9_write_raw() takes a runtime PM reference with pm_runtime_get_sync() but returns -EINVAL directly when a scale with a non-zero integer part is requested, skipping the matching pm_runtime_put_autosuspend(). This leaks a runtime PM usage-counter reference on every such write, after which the device can no longer autosuspend. Set the error code and fall through to the existing put instead of returning early. Fixes: 9a9a369d6178 ("iio: accel: kxsd9: Deploy system and runtime PM") Signed-off-by: Biren Pandya Assisted-by: Claude:claude-opus-4-8 coccinelle Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 3e766526827acd542bcd36c20c4d5f397e0f6521 Author: Bryam Vargas Date: Sat Jun 13 02:18:39 2026 -0500 iio: accel: bmc150: clamp the device-reported FIFO frame count commit ce0e1cae26096fe959a0da5563a6d6d5a801d5fb upstream. __bmc150_accel_fifo_flush() copies the number of samples the device reports in its hardware FIFO into an on-stack buffer u16 buffer[BMC150_ACCEL_FIFO_LENGTH * 3]; which is sized for at most BMC150_ACCEL_FIFO_LENGTH (32) samples. The frame count is read from the FIFO_STATUS register and only masked to its 7 valid bits: count = val & 0x7F; so it can be 0..127. The only other limit applied to it is the optional caller-supplied sample budget: if (samples && count > samples) count = samples; which does not constrain count on the flush-all path (samples == 0), and leaves it well above 32 whenever samples is larger. count samples are then transferred into buffer[]: bmc150_accel_fifo_transfer(data, (u8 *)buffer, count); bmc150_accel_fifo_transfer() reads count * 6 bytes through regmap, so a malfunctioning, malicious or counterfeit accelerometer (or an attacker tampering with the I2C/SPI bus) that reports up to 127 frames writes up to 762 bytes into the 192-byte buffer: a stack out-of-bounds write of up to 570 bytes that clobbers the stack canary, saved registers and the return address. Clamp count to BMC150_ACCEL_FIFO_LENGTH, the number of samples buffer[] is sized for, before the transfer, mirroring the watermark clamp already done in bmc150_accel_set_watermark(). A well-formed flush reports at most BMC150_ACCEL_FIFO_LENGTH frames, so legitimate devices are unaffected. Fixes: 3bbec9773389 ("iio: bmc150_accel: add support for hardware fifo") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 7515a6d4a9e9e4838b833825882efa00e85f8901 Author: Griffin Kroah-Hartman Date: Wed Jul 8 13:08:59 2026 +0200 usb: gadget: function: rndis: add length check for header commit 21b5bf155435008e0fb0736795289788e63d426f upstream. Add a length check for the rndis header in rndis_rm_hdr, to ensure that MessageType, MessageLength, DataOffset, and DataLength fields are present before they are accessed. Assisted-by: gkh_clanker_2000 Cc: stable Signed-off-by: Griffin Kroah-Hartman Link: https://patch.msgid.link/20260708-usb-gadget-rndis-v1-2-e77e026dcc6a@kroah.com Signed-off-by: Greg Kroah-Hartman commit e01e7814b4223560eab0513b7c15b8c82bdc83f3 Author: Griffin Kroah-Hartman Date: Wed Jul 8 13:08:58 2026 +0200 usb: gadget: function: rndis: add length check to response query commit 95f90eea070837f7c72207d5520f805bdefc3bc5 upstream. Add variable representations for BufLength and BufOffset in rndis_query_response(), and perform a length check on them. This is identical to how rndis_set_response() handles these parameters. Assisted-by: gkh_clanker_2000 Cc: stable Signed-off-by: Griffin Kroah-Hartman Link: https://patch.msgid.link/20260708-usb-gadget-rndis-v1-1-e77e026dcc6a@kroah.com Signed-off-by: Greg Kroah-Hartman commit 9d1dc507b99ceb1c15036c9382fb001b919a614b Author: Eric Biggers Date: Thu Jun 18 15:19:21 2026 -0700 fscrypt: Replace mk_users keyring with simple list [ Upstream commit 696c030e1e3438955aba443b308ee8b6faa3983e ] 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: Sasha Levin commit 85f8b440a09bad8d8f75156c89f72ac37c9d0d48 Author: Eric Biggers Date: Thu Jun 18 11:06:51 2026 -0700 fscrypt: Fix key setup in edge case with multiple data unit sizes [ Upstream commit dd015b566d505d698386103e9c80b739c7336eb8 ] The addition of support for customizable data unit sizes introduced an edge case where a file's contents can be en/decrypted with the wrong data unit size. It occurs when there are multiple v2 policies that: - Have *different* data unit sizes, via the log2_data_unit_size field - Share the same master_key_identifier, contents_encryption_mode, and either FSCRYPT_POLICY_FLAG_DIRECT_KEY, FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32, or FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64 - Are being used on the same filesystem, which also must be mounted with the "inlinecrypt" mount option. Fortunately this edge case doesn't actually occur in practice. I just found it via code review. But it needs to be fixed regardless. The bug is caused by the data unit size not being fully considered when blk_crypto_keys are cached in mk_direct_keys, mk_iv_ino_lblk_32_keys, and mk_iv_ino_lblk_64_keys. They're differentiated only by master key, encryption mode, and flag. However, each one actually has a data unit size too. Only the first data unit size that is cached is used. To fix this, start using the data unit size to differentiate the cached keys. For several reasons, including avoiding increasing the size of struct fscrypt_master_key, just replace all three arrays with a single linked list instead of changing them into two-dimensional arrays. This works well when considering that in practice at most 2 entries are used across all three arrays, so it was already mostly wasted space. For simplicity, make the list also take over the publish/subscribe of the prepared key itself. That is, create separate list nodes for blk_crypto_keys vs crypto_skciphers, and add nodes to the list only when their key is actually prepared. (Note that the legacy fscrypt_direct_keys table in fs/crypto/keysetup_v1.c already works this way.) This eliminates the need for the additional memory barriers when reading and writing the fields of struct fscrypt_prepared_key. Note that I technically should have included the data unit size in the HKDF info string as well. But it's too late to change that. Fixes: 5b1188847180 ("fscrypt: support crypto data unit size less than filesystem block size") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260618180652.52742-1-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Sasha Levin commit 20133754d46fe42dac8a56f590ea742645e6ba64 Author: Alice Ryhl Date: Thu Jul 9 19:59:43 2026 +0200 rust: kasan: KASAN+RUST requires clang [ Upstream commit 5b271543d0f08e9733d4732721e960e285f6448f ] Kernel KASAN involves passing various llvm/gcc specific arguments to the C and Rust compiler. Since these arguments differ between llvm and gcc, it's not safe to mix an llvm-based rustc with a gcc build when kasan is enabled. Signed-off-by: Alice Ryhl Reviewed-by: Gary Guo Cc: stable@vger.kernel.org Fixes: e3117404b411 ("kbuild: rust: Enable KASAN support") Link: https://patch.msgid.link/20260408-kasan-rust-sw-tags-v3-1-e07964d14363@google.com Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit a2d5d3ee7b6e3953114726b1521e62123ab5b043 Author: Taeyang Lee <0wn@theori.io> Date: Sun Jun 14 23:22:18 2026 +0900 perf/core: Detach event groups during remove_on_exec [ Upstream commit 037a3c43edfb597665dd34457cd22b14692f2ba3 ] perf_event_remove_on_exec() removes events by calling perf_event_exit_event(). For top-level events, this removes the event from the context with DETACH_EXIT only. This can leave inconsistent group state when a removed event is a group leader and the group contains siblings without remove_on_exec. If the group was active, the surviving siblings can remain active and attached to the removed leader's sibling list, but are no longer represented by a valid group leader on the PMU context active lists. A later close of the removed leader uses DETACH_GROUP and can promote the still-active siblings from this stale group state. The next schedule-in can then add an already-linked active_list entry again, corrupting the PMU context active list. With DEBUG_LIST enabled, this is caught as a list_add double-add in merge_sched_in(). Fix this by detaching group relationships when remove_on_exec removes an event. This preserves the existing task-exit and revoke behavior, while ensuring surviving siblings are ungrouped before the removed event leaves the context. Fixes: 2e498d0a74e5 ("perf: Add support for event removal on exec") Signed-off-by: Taeyang Lee <0wn@theori.io> Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/ai65GgZcC0LAlWLG@Taeyangs-MacBook-Pro.local Signed-off-by: Sasha Levin commit 94396fd93226a3e7ade1399f029841b2e8a1386e Author: Sebastian Andrzej Siewior Date: Wed Jul 1 15:11:50 2026 +0200 futex/requeue: Revert "Prevent NULL pointer dereference in remove_waiter() on self-deadlock"" commit 39def6d250d370298f86c116f4ac60093cefadaa upstream. The commit cited below should not have been merged. It attemted to fix an existing problem ansd thereby introduced new problems by keeping the pi_state in state Q_REQUEUE_PI_IN_PROGRESS and leaking it. Based on the commit description the intention was to handle the case when task_blocks_on_rt_mutex() returns -EDEADLK and the following remove_waiter() dereferences the NULL pointer in waiter->task. That is already handled by Davidlohr in commit 40a25d59e85b3 ("locking/rtmutex: Skip remove_waiter() when waiter is not enqueued") and requires no further acting. Revert the commit breaking the "waiter == owner" case again. Fixes: 74e144274af39 ("futex/requeue: Prevent NULL pointer dereference in remove_waiter() on self-deadlock") Reported-by: Michael Bommarito Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260701131150.0Ijhq4Dw@linutronix.de Closes: https://lore.kernel.org/all/20260629020049.2082397-1-michael.bommarito@gmail.com Signed-off-by: Greg Kroah-Hartman commit 1cc8f512cd90581d3ef9f743766a5cba34d454ff Author: Alice Ryhl Date: Tue Jun 16 12:30:38 2026 +0000 rust: Kbuild: set frame-pointer llvm module flag for CONFIG_FRAME_POINTER commit 191f49f1e38b1c10eb44b0f967c6175c884ef7db upstream. Due to a rustc bug, the -Cforce-frame-pointers=y flag only emits the frame-pointer annotation for functions, but not for the module. This means that functions generated by the LLVM backend such as 'asan.module_ctor' do not receive the frame-pointer annotation. This is likely to lead to broken backtraces and may also cause issues with ftrace if these features are used with functions generated by the LLVM backend. Thus, use -Zllvm_module_flag to work around this rustc bug if using a rustc without the fix. [ The fix [1] has landed for Rust 1.98.0 (expected release on 2026-08-20). - Miguel ] Cc: stable@vger.kernel.org # 6.12.y and later (flag not available in pinned Rust in older LTSs). Fixes: 2f7ab1267dc9 ("Kbuild: add Rust support") Link: https://github.com/rust-lang/rust/pull/156980 [1] Signed-off-by: Alice Ryhl Link: https://patch.msgid.link/20260616-frame-ptr-fix-v1-1-dc6b29a631d9@google.com [ - Adjusted Cc: stable@ as discussed. - Added comment with link to the PR, similar to what we did in commit ac35b5580ace ("rust: arm64: set uwtable llvm module flag for CONFIG_UNWIND_TABLES"). - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 70fe1ac8647b0f872b22bdb508f0e177abab25e0 Author: Gary Guo Date: Tue Jun 16 14:25:56 2026 +0100 rust: doctest: fix incorrect pattern in replacement commit ac4d1caa82d487e7ed46d0597da1adc9c1a51c70 upstream. The `-> Result<(), impl core::fmt::Debug>` string is generated by rustdoc and by adding "::" into the string it no longer finds anything, making the line useless. Remove the "::" in the pattern. Omit it in the replacement too, for consistency with upstream rustdoc. Fixes: de7cd3e4d638 ("rust: use absolute paths in macros referencing core and kernel") Signed-off-by: Gary Guo Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260616132559.2245814-1-gary@kernel.org [ Added link in code comment to `rustdoc`'s 1.87 PR that fully qualified it for context. Improved comments for consistency. Reworded to drop changelog and to fix typo. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit e7636f26f77070a529c26d65afd217514ce85ce4 Author: Haoze Xie Date: Sat May 30 14:11:54 2026 +0800 rust: block: fix GenDisk cleanup paths commit 2957771379fa335103a4b539db57bb2271e12142 upstream. GenDiskBuilder::build() still has fallible work after __blk_mq_alloc_disk(), but its error path only recovers the foreign queue data. That leaks the temporary gendisk and request_queue until later teardown. If the caller moved the last Arc> into build(), the leaked queue can retain blk-mq state after the tag set is dropped. Fix the pre-registration failure path by dropping the temporary gendisk reference with put_disk() before recovering queue_data, so disk_release() can tear down the owned queue. Also pair GenDisk::drop() with put_disk() after del_gendisk(). Once a Rust GenDisk has been added with device_add_disk(), del_gendisk() only unregisters it; the final gendisk reference still has to be dropped to complete the release path. Fixes: 3253aba3408a ("rust: block: introduce `kernel::block::mq` module") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Xin Liu Reviewed-by: Andreas Hindborg Signed-off-by: Haoze Xie Signed-off-by: Ren Wei Link: https://patch.msgid.link/b70aff9a920cc42110fe5cf454c3099561863519.1780063368.git.royenheart@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c1dd0b10710041b748fac58e29e91bbb0838375c Author: Miguel Ojeda Date: Sat May 30 11:58:09 2026 +0200 rust: cpufreq: clean new `clippy::map_or_identity` lint for Rust 1.98.0 commit 3473e0a219fdb2cb013da0a5d917e66fef052325 upstream. Starting with Rust 1.98.0 (expected 2026-08-20), Clippy is likely introducing a new lint `clippy::map_or_identity` [1][2], which currently triggers in a single case: warning: expression can be simplified using `Result::unwrap_or()` --> rust/kernel/cpufreq.rs:1326:60 | 1326 | PolicyCpu::from_cpu(cpu_id).map_or(0, |mut policy| T::get(&mut policy).map_or(0, |f| f)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#map_or_identity = note: `-W clippy::map-or-identity` implied by `-W clippy::all` = help: to override `-W clippy::all` add `#[allow(clippy::map_or_identity)]` help: consider using `unwrap_or` | 1326 - PolicyCpu::from_cpu(cpu_id).map_or(0, |mut policy| T::get(&mut policy).map_or(0, |f| f)) 1326 + PolicyCpu::from_cpu(cpu_id).map_or(0, |mut policy| T::get(&mut policy).unwrap_or(0)) | The suggestion is valid, thus clean it up. Cc: stable@vger.kernel.org # Needed in 6.18.y and later. Link: https://github.com/rust-lang/rust-clippy/issues/15801 [1] Link: https://github.com/rust-lang/rust-clippy/pull/16052 [2] Reviewed-by: Zhongqiu Han Reviewed-by: Gary Guo Reviewed-by: Alexandre Courbot Acked-by: Viresh Kumar Link: https://patch.msgid.link/20260530095809.213611-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 30d5d4eef35a9edf00d0ec005710c785594eeca2 Author: Huacai Chen Date: Thu Jun 25 13:03:47 2026 +0800 LoongArch: Add PIO for early access before ACPI PCI root register commit 6061e65f95713b01f4313cda6637dfe3aa5412b4 upstream. For ACPI system we suppose the ISA/LPC PIO range is registered together with PCI root bridge. But the fact is there may be some early access to the ISA/LPC PIO range before ACPI PCI root register (most of them are due to abnormal BIOS). Unconditionally register the ISA/LPC PIO range usually causes ACPI PCI root register fail because of the address range confliction. So we add a pair of helpers: acpi_add_early_pio() to add PIO for early access, and acpi_remove_early_pio() to remove PIO before PCI root register. Since acpi_remove_early_pio() may be called multiple times, we add an acpi_pio flag to ensure PIO be removed only once. Cc: Tested-by: Yuanzhen Gan Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 86df6499dfd232fbc1c82c0d6eb9322ca67b8cd0 Author: HyeongJun An Date: Sat Jun 6 02:49:05 2026 +0900 platform/x86: intel-hid: Protect ACPI notify handler against recursion commit c085d82613d5618814b84406c8b2d64f1bc305e7 upstream. Since commit e2ffcda16290 ("ACPI: OSL: Allow Notify () handlers to run on all CPUs") ACPI notify handlers like the intel-hid notify_handler() may run on multiple CPU cores racing with themselves. On convertibles and detachables (matched by DMI chassis-type 31 and 32 in dmi_auto_add_switch[]) the SW_TABLET_MODE input device is registered lazily from notify_handler() on the first tablet-mode event, via intel_hid_switches_setup(). When two such events race on different CPUs both can pass the !priv->switches check and register the priv->switches input device twice, resulting in a duplicate sysfs entry and a subsequent NULL pointer dereference. This is the same class of bug fixed by commit e075c3b13a0a ("platform/x86: intel-vbtn: Protect ACPI notify handler against recursion") for the sibling intel-vbtn driver. Protect intel-hid notify_handler() from racing with itself with a mutex to fix this. Fixes: e2ffcda16290 ("ACPI: OSL: Allow Notify () handlers to run on all CPUs") Cc: stable@vger.kernel.org Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260605174905.131095-1-sammiee5311@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 452945662fd8e9862a2d2043239c7ee1815d1ac4 Author: Rafael J. Wysocki Date: Wed Jun 3 19:56:21 2026 +0200 ACPI: NFIT: core: Fix possible NULL pointer dereference commit 027e128abb82788189d6d45b68e3e8e7329b67be upstream. After commit 9b311b7313d6 ("ACPI: NFIT: Install Notify() handler before getting NFIT table"), acpi_nfit_probe() installs an ACPI notify handler for the NFIT device before checking the presence of the NFIT table. If that table is not there, 0 is returned without allocating the acpi_desc object and setting the driver data pointer of the NFIT device. If the platform firmware triggers an NFIT_NOTIFY_UC_MEMORY_ERROR notification on the NFIT device at that point, acpi_nfit_uc_error_notify() will dereference a NULL pointer. Prevent that from occurring by adding an acpi_desc check against NULL to acpi_nfit_uc_error_notify(). Fixes: 9b311b7313d6 ("ACPI: NFIT: Install Notify() handler before getting NFIT table") Signed-off-by: Rafael J. Wysocki Cc: All applicable Reviewed-by: Dave Jiang Link: https://patch.msgid.link/2418508.ElGaqSPkdT@rafael.j.wysocki Signed-off-by: Greg Kroah-Hartman commit f29dc6132d4968e39d8fa575d1a12e2c718ce57b Author: Jeremy Linton Date: Mon Jun 1 18:58:08 2026 -0500 ACPI: CPPC: Suppress UBSAN warning caused by field misuse commit 1b1acf2dada0cc3931bb2cb9ff8832edfbee46a1 upstream. The definition of reg->access_width changes depending on the reg->space_id type. Type ACPI_ADR_SPACE_PLATFORM_COMM uses access_width to indicate the PCC region, which can result in a UBSAN if the value is greater than 4. For example: UBSAN: shift-out-of-bounds in drivers/acpi/cppc_acpi.c:1090:9 shift exponent 32 is too large for 32-bit type 'int' CPU: 61 UID: 0 PID: 1220 Comm: (udev-worker) Not tainted 7.0.10-201.fc44.aarch64 #1 PREEMPT(lazy) Hardware name: To be filled by O.E.M. Call trace: ...(trimming) ubsan_epilogue+0x10/0x48 __ubsan_handle_shift_out_of_bounds+0xdc/0x1e0 cpc_write+0x4d0/0x670 cppc_set_perf+0x18c/0x490 cppc_cpufreq_cpu_init+0x1c8/0x380 [cppc_cpufreq] ... (trimming) Lets fix this by validating the region type, as well as whether access_width has a value. Then since we are returning bit_width directly for ACPI_ADR_SPACE_PLATFORM_COMM, drop the code correcting the size. Fixes: 2f4a4d63a193 ("ACPI: CPPC: Use access_width over bit_width for system memory accesses") Signed-off-by: Jeremy Linton Tested-by: Jarred White Reviewed-by: Jarred White Reviewed-by: Easwar Hariharan Cc: All applicable Link: https://patch.msgid.link/20260601235808.1113137-1-jeremy.linton@arm.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit ff9c4c6428883182960cfe5c78928f0896d80ebc Author: Carlos López Date: Thu Jul 9 09:22:47 2026 +0200 KVM: x86: Unconditionally recompute CR8 intercept on PPR update [ Upstream commit bb365a506b1e6fb050c0fceaad354fe395385ef0 ] The TPR_THRESHOLD field in the VMCS is used by VMX to induce VM exits when the guest's virtual TPR falls under the specified threshold, allowing KVM to inject previously masked interrupts. KVM handles these VM exits in handle_tpr_below_threshold(). Commit eb90f3417a0c ("KVM: vmx: speed up TPR below threshold vmexits") optimized this function by calling apic_update_ppr() instead of raising KVM_REQ_EVENT. apic_update_ppr() then raises KVM_REQ_EVENT if there is a pending, deliverable interrupt. However, if there are no new interrupts pending, apic_update_ppr() does not issue the request. Thus, kvm_lapic_update_cr8_intercept() and vmx_update_cr8_intercept() are not called before VM entry, which results in a high, stale TPR_THRESHOLD. This is problematic due to the following sentence in 28.2.1.1 "VM-Execution Control Fields" in the SDM: The following check is performed if the “use TPR shadow” VM-execution control is 1 and the “virtualize APIC accesses” and “virtual-interrupt delivery” VM-execution controls are both 0: the value of bits 3:0 of the TPR threshold VM-execution control field should not be greater than the value of bits 7:4 of VTPR. This error condition is typically not observed when KVM runs on a bare metal system because modern processors support APICv, which enables virtual-interrupt delivery, and which KVM uses when possible. This causes the processor to no longer generate TPR-below-threshold exits and to no longer check TPR_THRESHOLD on entry. However, when running on older platforms, or under nested virtualization on a hypervisor that does not support virtual-interrupt delivery and enforces this check (like Hyper-V) this can cause a VM entry failure with hardware error 0x7, as seen in [1]. Call kvm_lapic_update_cr8_intercept() if apic_update_ppr() does not find a deliverable interrupt (and thus does not raise KVM_REQ_EVENT). Remove calls to kvm_lapic_update_cr8_intercept() on paths that end up in apic_update_ppr(), as they now become redundant. This ensures that any path that updates the guest's PPR also figures out if KVM needs to wait for a TPR change (using TPR_THRESHOLD on VMX or CR8 intercepts on SVM). Link: https://github.com/coconut-svsm/svsm/issues/1081 [1] Tested-by: Stefano Garzarella Cc: stable@vger.kernel.org Fixes: eb90f3417a0c ("KVM: vmx: speed up TPR below threshold vmexits") Signed-off-by: Carlos López Signed-off-by: Sean Christopherson Message-ID: <20260618174347.1981064-3-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 3dcfb04dd43b16fa1240fc6487fff578ad57264c Author: Sean Christopherson Date: Thu Jul 9 09:22:46 2026 +0200 KVM: VMX: Grab vmcs12 on CR8 interception update iff vCPU is in guest mode [ Upstream commit 7ef78d71ca713d8c00f7c34ddcf276c808143f77 ] When updating CR8 intercepts, get vmcs12 if and only if the vCPU is in guest mode so that a future change can have update CR8 intercepts during vCPU creation, without running afoul of get_vmcs12()'s lockdep assertion. ------------[ cut here ]------------ debug_locks && !(lock_is_held(&(&vcpu->mutex)->dep_map) || !refcount_read(&vcpu->kvm->users_count)) WARNING: arch/x86/kvm/vmx/nested.h:61 at get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline], CPU#0: syz.2.19/5879 WARNING: arch/x86/kvm/vmx/nested.h:61 at vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879, CPU#0: syz.2.19/5879 Modules linked in: CPU: 0 UID: 0 PID: 5879 Comm: syz.2.19 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline] RIP: 0010:vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879 Call Trace: apic_update_ppr arch/x86/kvm/lapic.c:984 [inline] kvm_lapic_reset+0x1c24/0x2980 arch/x86/kvm/lapic.c:3023 kvm_vcpu_reset+0x44c/0x1bf0 arch/x86/kvm/x86.c:12986 kvm_arch_vcpu_create+0x746/0x8b0 arch/x86/kvm/x86.c:12847 kvm_vm_ioctl_create_vcpu+0x428/0x930 virt/kvm/kvm_main.c:4201 kvm_vm_ioctl+0x893/0xd50 virt/kvm/kvm_main.c:5159 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f No functional change intended. Reported-by: syzbot ci Closes: https://lore.kernel.org/all/6a2adf3b.3b0a2d4e.8c8d1.0012.GAE@google.com Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-ID: <20260618174347.1981064-2-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Carlos López Signed-off-by: Greg Kroah-Hartman commit 0d0187a46b16efc00e4a6bf682e8423814ee693f Author: Sean Christopherson Date: Thu Jul 9 09:22:45 2026 +0200 KVM: x86: Move update_cr8_intercept() to lapic.c [ Upstream Commit c7722e5e1daeeabbd9f969554d52bb7158120b27 ] Move update_cr8_intercept() to lapic.c so that it's globally visible in anticipation of extracting most of the register-specific code out of x86.c and into a new compilation unit. Opportunistically prefix the helper kvm_lapic_ to make its role/scope more obvious. No functional change intended. Reviewed-by: Kai Huang Reviewed-by: Yosry Ahmed Link: https://patch.msgid.link/20260529222223.870923-14-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Carlos López Signed-off-by: Greg Kroah-Hartman commit 9baa2833e6bc83180da22c532b56555e1034b2d1 Author: Florian Fainelli Date: Wed May 13 12:23:46 2026 -0700 perf trace beauty fcntl: Fix build with older kernel headers commit 7ee7f48413c42b90230de4a8e40898b757bc8e82 upstream. Toolchains with older kernel headers that do not include upstream commit c75b1d9421f80f41 ("fs: add fcntl() interface for setting/getting write life time hints") will now fail to build perf due to missing definitions for F_GET_RW_HINT/F_SET_RW_HINT/F_GET_FILE_RW_HINT/F_SET_FILE_RW_HINT. Provide a fallback definition for these when they are not already defined. Fixes: 9c47f66748381ecb ("perf trace beauty fcntl: Basic 'arg' beautifier") Reviewed-by: Ian Rogers Signed-off-by: Florian Fainelli Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Mark Rutland Cc: Markus Mayer Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 47e4c6e06e78ec7b38bcba41ef52fe08d1952b38 Author: Randy Dunlap Date: Wed Jun 17 09:31:25 2026 -0700 slab: recognize @GFP parameter as optional in kernel-doc commit 7b5f5865fb11e60edd03c5e063e2d228b7062317 upstream. Since the @GFP parameter in kmalloc_obj() etc. is now optional, change the kernel-doc to indicate that it is optional. This avoids kernel-doc warnings: WARNING: include/linux/slab.h:1101 Excess function parameter 'GFP' description in 'kmalloc_obj' WARNING: include/linux/slab.h:1113 Excess function parameter 'GFP' description in 'kmalloc_objs' WARNING: include/linux/slab.h:1128 Excess function parameter 'GFP' description in 'kmalloc_flex' Fixes: e19e1b480ac7 ("add default_gfp() helper macro and use it in the new *alloc_obj() helpers") Signed-off-by: Randy Dunlap Acked-by: Harry Yoo (Oracle) Link: https://patch.msgid.link/20260617163125.2716279-1-rdunlap@infradead.org Signed-off-by: Vlastimil Babka (SUSE) Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 1776f29327a136aed6c80c720740489d0b6d015c Author: Linus Torvalds Date: Mon Feb 23 09:33:08 2026 -0800 default_gfp(): avoid using the "newfangled" __VA_OPT__ trick commit 551d44200152cb26f75d2ef990aeb6185b7e37fd upstream. The default_gfp() helper that I added is not wrong, but it turns out that it causes unnecessary headaches for 'sparse' which doesn't support the use of __VA_OPT__ (introduced in C++20 and C23, and supported by gcc and clang for a long time). We do already use __VA_OPT__ in some other cases in the kernel (drm/xe and btrfs), but it has been fairly limited. Now it triggers for pretty much everything, and sparse ends up not working at all. We can use the traditional gcc ',##__VA_ARGS__' syntax instead: it may not be the "C standard" way and is slightly less natural in this context, but it is the traditional model for this and avoids the sparse problem. Reported-and-tested-by: Ricardo Ribalda Reported-and-tested-by: Richard Fitzgerald Reported-by: Ben Dooks Fixes: e19e1b480ac7 ("add default_gfp() helper macro and use it in the new *alloc_obj() helpers") Signed-off-by: Linus Torvalds Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 50c26b461b8e7b547c7ee71deca9db3ecf4d1036 Author: Linus Torvalds Date: Sat Feb 21 16:14:11 2026 -0800 add default_gfp() helper macro and use it in the new *alloc_obj() helpers commit e19e1b480ac73c3e62ffebbca1174f0f511f43e7 upstream. Most simple allocations use GFP_KERNEL, and with the new allocation helpers being introduced, let's just take advantage of that to simplify that default case. It's a numbers game: git grep 'alloc_obj(' | sed 's/.*\(GFP_[_A-Z]*\).*/\1/' | sort | uniq -c | sort -n | tail shows that about 90% of all those new allocator instances just use that standard GFP_KERNEL. Those helpers are already macros, and we can easily just make it be the default case when the gfp argument is missing. And yes, we could do that for all the legacy interfaces too, but let's keep it to just the new ones at least for now, since those all got converted recently anyway, so this is not any "extra" noise outside of that limited conversion. And, in fact, I want to do this before doing the -rc1 release, exactly so that we don't get extra merge conflicts. Signed-off-by: Linus Torvalds Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 2dca62902eb3501432ee9bd098fce878cfbb2c1a Author: Kees Cook Date: Wed Dec 3 15:30:34 2025 -0800 slab: Introduce kmalloc_flex() and family commit e4c8b46b924eb8de66c6f0accc9cdd0c2e8fa23b upstream. As done for kmalloc_obj*(), introduce a type-aware allocator for flexible arrays, which may also have "counted_by" annotations: ptr = kmalloc(struct_size(ptr, flex_member, count), gfp); becomes: ptr = kmalloc_flex(*ptr, flex_member, count, gfp); The internal use of __flex_counter() allows for automatically setting the counter member of a struct's flexible array member when it has been annotated with __counted_by(), avoiding any missed early size initializations while __counted_by() annotations are added to the kernel. Additionally, this also checks for "too large" allocations based on the type size of the counter variable. For example: if (count > type_max(ptr->flex_counter)) fail...; size = struct_size(ptr, flex_member, count); ptr = kmalloc(size, gfp); if (!ptr) fail...; ptr->flex_counter = count; becomes (n.b. unchanged from earlier example): ptr = kmalloc_flex(*ptr, flex_member, count, gfp); if (!ptr) fail...; ptr->flex_counter = count; Note that manual initialization of the flexible array counter is still required (at some point) after allocation as not all compiler versions support the __counted_by annotation yet. But doing it internally makes sure they cannot be missed when __counted_by _is_ available, meaning that the bounds checker will not trip due to the lack of "early enough" initializations that used to work before enabling the stricter bounds checking. For example: ptr = kmalloc_flex(*ptr, flex_member, count, gfp); fill(ptr->flex, count); ptr->flex_count = count; This works correctly before adding a __counted_by annotation (since nothing is checking ptr->flex accesses against ptr->flex_count). After adding the annotation, the bounds sanitizer would trip during fill() because ptr->flex_count wasn't set yet. But with kmalloc_flex() setting ptr->flex_count internally at allocation time, the existing code works without needing to move the ptr->flex_count assignment before the call to fill(). (This has been a stumbling block for __counted_by adoption.) Link: https://patch.msgid.link/20251203233036.3212363-4-kees@kernel.org Acked-by: Vlastimil Babka Signed-off-by: Kees Cook [Backport-notes: Removed the actual flex counter handling. That's a new feature, which isn't necessary for just adding the new allocation APIs to get backports to apply cleanly. Also, the allocation-time overflow check in the upstream commit was reverted upstream.] Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 1c2672781b1b30533bdd7d4f50e4573256c9e7ff Author: Pedro Falcato Date: Wed Jul 8 16:13:57 2026 +0100 mm/khugepaged: write all dirty file folios when collapsing [There is no upstream commit, as this code was removed by upstream commit 044925f9b565 ("mm: fs: remove filemap_nr_thps*() functions and their users")] As-is, khugepaged and writable-file opening exclude each other. A file cannot be open writeable and have THPs (because the filesystem is not aware of them). khugepaged will never collapse file pages for files that are opened writeable. On an open(O_RDWR/O_WRONLY), the page cache for that particular file is dropped. This is fine because nothing could've been dirtied. However, there is an edge-case: collapse_file() might not be able to coexist with concurrent writers, but it can coexist with dirty folios (from previous writers). Therefore, the following can happen: open(file, O_RDWR) write(file) close(file) madvise(file_mapping, MADV_COLLAPSE, some non-dirty range) open(file, O_RDWR) nr_thps > 0 truncate_inode_pages() /* THPs are cleared out, but so are the dirty folios */ When this edge-case happens, there is data loss, as the dirty folios are fully discarded. Fix it by fully writing back the page cache (and waiting) when collapsing file THPs. Doing so provides the guarantee that no dirty folio will be observed while there are active THPs. To fully ensure this is safe, the invalidate_lock needs to be held while doing the writeout, so that do_dentry_open()'s page cache truncation excludes this write-and-wait. As a side effect, move the nr_thps counter bumping outside the i_pages lock. This is correct since the counter itself is an atomic_t and the producer <-> consumer correctness is provided by a full memory barrier: smp_mb() in collapse_file()/memory barrier implied by full ordering in get_write_access() -> atomic_inc_unless_negative(). Cc: stable@vger.kernel.org Cc: Alexander Viro Cc: Christian Brauner Cc: Jan Kara Cc: Matthew Wilcox Cc: Song Liu Cc: Eric Hagberg Cc: Zi Yan Fixes: 99cb0dbd47a1 ("mm,thp: add read-only THP support for (non-shmem) FS") Reported-by: Gregg Leventhal Closes: https://lore.kernel.org/linux-mm/CAFN_u7H_0ECF3jixP=T=U7AH5=Q3wQNvJMo8an3VqUDMerQfUw@mail.gmail.com/ Tested-by: Zi Yan Tested-by: Lance Yang Signed-off-by: Pedro Falcato Acked-by: David Hildenbrand (Arm) Reviewed-by: Matthew Wilcox (Oracle) Signed-off-by: Sasha Levin commit 2539f67b75461f21cb0ff66127b910988f97dc51 Author: NeilBrown Date: Mon Sep 8 11:38:33 2025 +1000 nfsd: change nfs4_client_to_reclaim() to allocate data [ Upstream commit 4552f4e3f2c96597914f07b060d5c5db84420ddd ] The calling convention for nfs4_client_to_reclaim() is clumsy in that the caller needs to free memory if the function fails. It is much cleaner if the function frees its own memory. This patch changes nfs4_client_to_reclaim() to re-allocate the .data fields to be stored in the newly allocated struct nfs4_client_reclaim, and to free everything on failure. __cld_pipe_inprogress_downcall() needs to allocate the data anyway to copy it from user-space, so now that data is allocated twice. I think that is a small price to pay for a cleaner interface. Signed-off-by: NeilBrown Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 05e48af3bf58d0a73ab3e20a16c1a25a0546f379 Author: NeilBrown Date: Mon Sep 15 12:55:13 2025 +1000 nfsd: move name lookup out of nfsd4_list_rec_dir() [ Upstream commit 89bd77cf436bf25e448817a662ebf76515f22863 ] nfsd4_list_rec_dir() is called with two different callbacks. One of the callbacks uses vfs_rmdir() to remove the directory. The other doesn't use the dentry at all, just the name. As only one callback needs the dentry, this patch moves the lookup into that callback. This prepares of changes to how directory operations are locked. Signed-off-by: NeilBrown Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Stable-dep-of: 4552f4e3f2c9 ("nfsd: change nfs4_client_to_reclaim() to allocate data") Signed-off-by: Sasha Levin commit c4b70c1512b8f9f33f23c2c8196dfd1210207681 Author: Xingquan Liu Date: Fri Jun 19 11:13:47 2026 -0400 net/sched: dualpi2: fix GSO backlog accounting commit 05ed733b65ab977dd931e7f7ac0f62fdb81205c2 upstream. When DualPI2 splits a GSO skb into N segments, it propagates N additional packets to its parent before returning NET_XMIT_SUCCESS. The parent then accounts for the original skb once more, leaving its qlen one larger than the number of packets actually queued. With QFQ as the parent, after all real packets are dequeued, QFQ still has a non-zero qlen while its in-service aggregate has no active classes. qfq_choose_next_agg() returns NULL and qfq_dequeue() passes the result to qfq_peek_skb(), causing a NULL pointer dereference. Follow the same pattern used by tbf_segment() and taprio: count only successfully queued segments, propagate the difference between the original skb and those segments, and return NET_XMIT_SUCCESS whenever at least one segment was queued. Fixes: 8f9516daedd6 ("sched: Add enqueue/dequeue of dualpi2 qdisc") Cc: stable@vger.kernel.org Signed-off-by: Xingquan Liu Acked-by: Jamal Hadi Salim Reviewed-by: Victor Nogueira Link: https://patch.msgid.link/20260619151447.223640-1-b1n@b1n.io Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 076b1aa65f77a49bce5a48a4a55a397cfcafa2b8 Author: Mingyu Wang <25181214217@stu.xidian.edu.cn> Date: Sat Jul 4 11:19:43 2026 -0400 fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font() [ Upstream commit 8fdc8c2057eea08d40ce2c8eed41ff9e451c65c2 ] When fbcon_do_set_font() fails (e.g., due to a memory allocation failure inside vc_resize() under heavy memory pressure), it jumps to the `err_out` label to roll back the console state. However, the current rollback logic forgets to restore the `hi_font` state, leading to a severe state machine corruption. Earlier in the function, `set_vc_hi_font()` might be called to change `vc->vc_hi_font_mask` and mutate the screen buffer. If `vc_resize()` subsequently fails, the `err_out` path restores `vc_font.charcount` but entirely skips rolling back the `vc_hi_font_mask` and the screen buffer. This mismatch leaves the terminal in a desynchronized state. Because `vc_hi_font_mask` remains set, the VT subsystem will still accept character indices greater than 255 from userspace and write them to the screen buffer. Subsequent rendering calls (e.g., `fbcon_putcs()`) will then use these inflated indices to access the reverted, 256-character font array, leading to a deterministic out-of-bounds read and potential kernel memory disclosure. Fix this by adding the missing rollback logic for the `hi_font` mask and screen buffer in the error path. Fixes: a5a923038d70 ("fbdev: fbcon: Properly revert changes when vc_resize() failed") Cc: stable@vger.kernel.org Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> Reviewed-by: Thomas Zimmermann Signed-off-by: Helge Deller [ Adjust context ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 406c28af75123432d38cf9bbaa6f1476f7b14770 Author: Chao Yu Date: Sat Jul 4 09:01:06 2026 -0400 f2fs: fix to do sanity check on f2fs_get_node_folio_ra() [ Upstream commit 8712353ed80f87271d732297567dcdbe4b84e8c7 ] kernel BUG at fs/f2fs/file.c:845! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 5336 Comm: syz.0.0 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:f2fs_do_truncate_blocks+0x1115/0x1140 fs/f2fs/file.c:845 Code: fc fc 90 0f 0b e8 8b 9d 9a fd 90 0f 0b e8 83 9d 9a fd 48 89 df 48 c7 c6 60 d1 1a 8c e8 54 f1 fc fc 90 0f 0b e8 6c 9d 9a fd 90 <0f> 0b e8 64 9d 9a fd 90 0f 0b 90 e9 93 fd ff ff e8 56 9d 9a fd 90 RSP: 0018:ffffc9000e4474c0 EFLAGS: 00010283 RAX: ffffffff842b1d34 RBX: 0000000000000003 RCX: 0000000000100000 RDX: ffffc9000f03a000 RSI: 0000000000035503 RDI: 0000000000035504 RBP: ffffc9000e447608 R08: ffff8880123b0000 R09: 0000000000000002 R10: 00000000fffffffe R11: 0000000000000002 R12: 0000000000000001 R13: 0000000000000000 R14: 1ffff92001c88ea0 R15: 00000000ffff039c FS: 00007f7e02ee36c0(0000) GS:ffff88808c887000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff0305c4000 CR3: 0000000012d4c000 CR4: 0000000000352ef0 Call Trace: f2fs_truncate_blocks+0x10a/0x300 fs/f2fs/file.c:882 f2fs_truncate+0x471/0x7c0 fs/f2fs/file.c:940 f2fs_evict_inode+0xa3f/0x1ac0 fs/f2fs/inode.c:907 evict+0x61e/0xb10 fs/inode.c:841 f2fs_fill_super+0x5f43/0x78f0 fs/f2fs/super.c:5224 get_tree_bdev_flags+0x431/0x4f0 fs/super.c:1694 vfs_get_tree+0x92/0x2a0 fs/super.c:1754 fc_mount fs/namespace.c:1193 [inline] do_new_mount_fc fs/namespace.c:3758 [inline] do_new_mount+0x341/0xd30 fs/namespace.c:3834 do_mount fs/namespace.c:4167 [inline] __do_sys_mount fs/namespace.c:4383 [inline] __se_sys_mount+0x31d/0x420 fs/namespace.c:4360 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f count = ADDRS_PER_PAGE(dn.node_folio, inode); count -= dn.ofs_in_node; f2fs_bug_on(sbi, count < 0); The fuzz test will trigger above bug_on in f2fs. The root cause should be: in the corrupted inode, there is a direct node which has the same ino and nid in its footer, so in f2fs_do_truncate_blocks(), after f2fs_get_dnode_of_data() finds such dnode: 1) ADDRS_PER_PAGE(dn.node_folio, inode) will return 923 2) once dn.ofs_in_node points to addr[923, 1017] Then it will trigger the system panic. Let's introduce NODE_TYPE_NON_IXNODE to indicate current node should not be an inode or xattr node, and then use it in below path to detect inconsistent node chain in inode mapping table: - f2fs_do_truncate_blocks - f2fs_get_dnode_of_data - f2fs_get_node_folio_ra - __get_node_folio - f2fs_sanity_check_node_footer - case NODE_TYPE_NON_IXNODE -> check whether it is inode|xnode Cc: stable@kernel.org Reported-by: syzbot+2488d8d751b27f7ce268@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/69fa3697.170a0220.59368.0018.GAE@google.com Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3f42fbd3c891dc05de20301903b85a181b5309f1 Author: Chao Yu Date: Sat Jul 4 09:01:05 2026 -0400 f2fs: detect more inconsistent cases in sanity_check_node_footer() [ Upstream commit 93ffb6c28ff180560d2d7313ac106efcd9e012b8 ] Let's enhance sanity_check_node_footer() to detect more inconsistent cases as below: Node Type Node Footer Info =================== ============================= NODE_TYPE_REGULAR inode = true and xnode = true NODE_TYPE_INODE inode = false or xnode = true NODE_TYPE_XATTR inode = true or xnode = false NODE_TYPE_NON_INODE inode = false Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Stable-dep-of: 8712353ed80f ("f2fs: fix to do sanity check on f2fs_get_node_folio_ra()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ed87e57558dc573439503da8247cd3a14f1d07f2 Author: YH Lin Date: Sat Jul 4 09:01:04 2026 -0400 f2fs: optimize trace_f2fs_write_checkpoint with enums [ Upstream commit 8d1cb17aca466b361cca17834b8bb1cf3e3d1818 ] This patch optimizes the tracepoint by replacing these hardcoded strings with a new enumeration f2fs_cp_phase. 1.Defines enum f2fs_cp_phase with values for each checkpoint phase. 2.Updates trace_f2fs_write_checkpoint to accept a u16 phase argument instead of a string pointer. 3.Uses __print_symbolic in TP_printk to convert the enum values back to their corresponding strings for human-readable trace output. This change reduces the storage overhead for each trace event by replacing a variable-length string with a 2-byte integer, while maintaining the same readable output in ftrace. Signed-off-by: YH Lin Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Stable-dep-of: 8712353ed80f ("f2fs: fix to do sanity check on f2fs_get_node_folio_ra()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8dbc4c56868205bf41b0a3f0eb7e856017349b9c Author: Chao Yu Date: Sat Jul 4 09:01:03 2026 -0400 f2fs: introduce f2fs_schedule_timeout() [ Upstream commit 76e780d88c771921ea643fb8a6c8d0b08c17cb7b ] In f2fs retry logic, we will call f2fs_io_schedule_timeout() to sleep as uninterruptible state (waiting for IO) for a while, however, in several paths below, we are not blocked by IO: - f2fs_write_single_data_page() return -EAGAIN due to racing on cp_rwsem. - f2fs_flush_device_cache() failed to submit preflush command. - __issue_discard_cmd_range() sleeps periodically in between two in batch discard submissions. So, in order to reveal state of task more accurate, let's introduce f2fs_schedule_timeout() and call it in above paths in where we are waiting for non-IO reasons. Then we can get real reason of uninterruptible sleep for a thread in tracepoint, perfetto, etc. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Stable-dep-of: 8712353ed80f ("f2fs: fix to do sanity check on f2fs_get_node_folio_ra()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 599d7d82eeecc0c2f0704831ed16055e8b8e9603 Author: Chao Yu Date: Sat Jul 4 09:01:02 2026 -0400 f2fs: use memalloc_retry_wait() as much as possible [ Upstream commit 30a8496694f1a93328e5d7f19206380346918b5a ] memalloc_retry_wait() is recommended in memory allocation retry logic, use it as much as possible. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Stable-dep-of: 8712353ed80f ("f2fs: fix to do sanity check on f2fs_get_node_folio_ra()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ec9f79c8d5b28a928e65b67cd138c841571cf502 Author: Keshav Verma Date: Fri Jul 3 14:39:41 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 89479a27fa4e1e11f378b3724944eabceb84f114 Author: Chao Yu Date: Fri Jul 3 14:03:17 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 998536c96b6ad9d99cd85dea11452ab83dc7c88d Author: Ruipeng Qi Date: Fri Jul 3 14:03:16 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 4ce2d52f680c1d8bfdad7cce05b815ea7ca9790d Author: Bryam Vargas Date: Fri Jul 3 10:09:34 2026 -0400 f2fs: bound i_inline_xattr_size for non-inline-xattr inodes [ Upstream commit 378acf3cf19b6af6cba55e8dd1154c4e1504bae8 ] When the flexible_inline_xattr feature is enabled, do_read_inode() loads the on-disk i_inline_xattr_size unconditionally: if (f2fs_sb_has_flexible_inline_xattr(sbi)) fi->i_inline_xattr_size = le16_to_cpu(ri->i_inline_xattr_size); but sanity_check_inode() only range-checks it when the inode also has the FI_INLINE_XATTR flag set. An inode that carries an inline dentry or inline data but not FI_INLINE_XATTR -- the normal layout for an inline directory -- therefore keeps a fully attacker-controlled i_inline_xattr_size from a crafted image. get_inline_xattr_addrs() returns that value with no flag gating, so it feeds the inode geometry: MAX_INLINE_DATA() = 4 * (CUR_ADDRS_PER_INODE - i_inline_xattr_size - 1) NR_INLINE_DENTRY() = MAX_INLINE_DATA() * BITS_PER_BYTE / (...) addrs_per_page() = CUR_ADDRS_PER_INODE - i_inline_xattr_size A large i_inline_xattr_size drives MAX_INLINE_DATA() and NR_INLINE_DENTRY() negative, so make_dentry_ptr_inline() sets d->max (int) to a negative value. The inline directory walk then compares an unsigned long bit_pos against that negative d->max, which is promoted to a huge unsigned bound, and reads far past the inline area: while (bit_pos < d->max) /* fs/f2fs/dir.c */ ... test_bit_le(bit_pos, d->bitmap) / d->dentry[bit_pos] ... Mounting a crafted image and reading such a directory triggers an out-of-bounds read in f2fs_fill_dentries(); the same underflow also corrupts ADDRS_PER_INODE for regular files. Validate i_inline_xattr_size against MAX_INLINE_XATTR_SIZE whenever the flexible_inline_xattr feature is enabled -- i.e. whenever the value is loaded from disk and consumed -- and keep the lower MIN_INLINE_XATTR_SIZE bound gated on inodes that actually carry an inline xattr, so legitimate inodes with i_inline_xattr_size == 0 are still accepted. Cc: stable@vger.kernel.org Fixes: 6afc662e68b5 ("f2fs: support flexible inline xattr size") Signed-off-by: Bryam Vargas Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a499f77c06050a28c897bdbd86cd2f0721ae0743 Author: Chao Yu Date: Fri Jul 3 08:33:30 2026 -0400 f2fs: atomic: fix UAF issue on f2fs_inode_info.atomic_inode [ Upstream commit e0288584baa5dc41df4a829a023c4c1b33fe53d7 ] - ioctl(F2FS_IOC_GARBAGE_COLLECT_RANGE) - shrink - f2fs_gc - gc_data_segment - ra_data_block(cow_inode) - mapping = F2FS_I(inode)->atomic_inode->i_mapping : f2fs_is_cow_file(cow_inode) is true - f2fs_evict_inode(atomic_inode) - clear_inode_flag(fi->cow_inode, FI_COW_FILE) - F2FS_I(fi->cow_inode)->atomic_inode = NULL ... - truncate_inode_pages_final(atomic_inode) - f2fs_grab_cache_folio(mapping) : create folio in atomic_inode->mapping - clear_inode(atomic_inode) - BUG_ON(atomic_inode->i_data.nrpages) We need to add a reference on fi->atomic_inode before using its mapping field during garbage collection, otherwise, it will cause UAF issue. Cc: stable@kernel.org Cc: Daeho Jeong Cc: Sunmin Jeong Fixes: 3db1de0e582c ("f2fs: change the current atomic write way") Fixes: f18d00769336 ("f2fs: use meta inode for GC of COW file") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5a4d3968cf820686400fc757a4512dcaddd84846 Author: Yongpeng Yang Date: Fri Jul 3 08:33:29 2026 -0400 f2fs: remove non-uptodate folio from the page cache in move_data_block [ Upstream commit 9609dd704725a40cd63d915f2ab6c44248a44598 ] During data movement, move_data_block acquires file folio without triggering a file read. Such folio are typically not uptodate, they need to be removed from the page cache after gc complete. This patch marks folio with the PG_dropbehind flag and uses folio_end_dropbehind to remove folio from the page cache. Signed-off-by: Yunlei He Signed-off-by: Yongpeng Yang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Stable-dep-of: e0288584baa5 ("f2fs: atomic: fix UAF issue on f2fs_inode_info.atomic_inode") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9c86a1f930bb2ddb85f867b4736716e82a4a4683 Author: Bartosz Golaszewski Date: Thu Jul 2 11:40:11 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 60d696a037eeeedfb57756dfe7ec08a1587c8631 Author: Kiryl Shutsemau Date: Thu Jul 2 16:49:07 2026 +0100 userfaultfd: gate must_wait writability check on pte_present() [ Upstream commit 8e80af52db652fbc41320eee45a4f73bc029faf2 ] userfaultfd_must_wait() and userfaultfd_huge_must_wait() read the PTE without taking the page table lock and then apply pte_write() / huge_pte_write() to it. Those accessors decode bits from the present encoding only; on a swap or migration entry they read the offset bits that happen to share the same position and return an undefined result. The intent of the check is "is this fault still WP-blocked?". A non-marker swap entry means the page is in transit -- the userfault context the original fault delivered against is no longer the same, and the swap-in or migration completion path will re-deliver a fresh fault if userspace still needs to handle it. Worst case under the current code the garbage write bit says "wait", and the thread stays asleep until a UFFDIO_WAKE that may never arrive. Gate the writability check on pte_present() so the lockless re-check only inspects present-PTE bits when the entry is actually present. The non-present, non-marker case returns "don't wait" and lets the fault path retry. Link: https://lore.kernel.org/20260529172331.356655-6-kas@kernel.org Fixes: 369cd2121be4 ("userfaultfd: hugetlbfs: userfaultfd_huge_must_wait for hugepmd ranges") Fixes: 63b2d4174c4a ("userfaultfd: wp: add the writeprotect API to userfaultfd ioctl") Signed-off-by: Kiryl Shutsemau Reported-by: Sashiko AI review Reviewed-by: Lorenzo Stoakes 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 [ kas: apply to fs/userfaultfd.c and fold the pte_present()/ huge_pte_present() gate into the existing writability checks; this tree predates the marker/return-style refactor of these functions ] Signed-off-by: Kiryl Shutsemau Signed-off-by: Sasha Levin commit 3436a7dd067c5109c98a2da3b25ec91c6825a4eb Author: Miguel Ojeda Date: Tue Jun 9 12:41:52 2026 +0200 rust: str: clean unused import for Rust >= 1.98 [ Upstream commit 3fff4271809b57182c4011811e96556bdd4cb2f9 ] Starting with Rust 1.98.0 (expected 2026-08-20), the compiler has changed how the resolution algorithm works [1] in upstream commit c4d84db5f184 ("Resolver: Batched import resolution."), and it now spots: error: unused import: `flags::*` --> rust/kernel/str.rs:7:9 | 7 | flags::*, | ^^^^^^^^ | = note: `-D unused-imports` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(unused_imports)]` It happens to not be needed because the `prelude::*` already provides the flags. Thus clean it up. Cc: stable@vger.kernel.org # Needed in 6.18.y and later (prelude added to `str`). Link: https://github.com/rust-lang/rust/pull/145108 [1] Reviewed-by: Gary Guo Reviewed-by: Alice Ryhl Link: https://patch.msgid.link/20260609104152.261145-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit 3603500c868a1af34283bfa64cf207c940beb033 Author: Miguel Ojeda Date: Tue Jun 9 12:41:51 2026 +0200 rust: str: use the "kernel vertical" imports style [ Upstream commit 724a93a9f6033800b02a3530dbcb464638448e7f ] Convert the imports to use the "kernel vertical" imports style [1]. No functional changes intended. Link: https://docs.kernel.org/rust/coding-guidelines.html#imports [1] Reviewed-by: Gary Guo Link: https://patch.msgid.link/20260609104152.261145-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda Stable-dep-of: 3fff4271809b ("rust: str: clean unused import for Rust >= 1.98") Signed-off-by: Sasha Levin commit 8dee7c278f1c2b5bb80e17a6281c3812fc8b0cdd Author: Chris Mason Date: Thu Jul 2 16:24:09 2026 -0400 nfsd: release layout stid on setlease failure commit 30d55c8aabb261bc3f427d6b9aae7ef6206063f9 upstream. nfs4_alloc_stid() publishes the new stid into cl->cl_stateids via idr_alloc_cyclic() under cl_lock before returning to nfsd4_alloc_layout_stateid(). When nfsd4_layout_setlease() then fails, the error path frees the layout stateid directly with kmem_cache_free() without ever calling idr_remove(), leaving the IDR slot pointing at freed slab memory. Any subsequent IDR walker (states_show, client teardown) dereferences the dangling pointer. The correct teardown for an IDR-published stid is nfs4_put_stid(), which removes the IDR slot under cl_lock, dispatches sc_free (nfsd4_free_layout_stateid) to release ls->ls_file via nfsd4_close_layout(), and drops the nfs4_file reference in its tail. A second issue blocks that switch: nfsd4_free_layout_stateid() unconditionally inspects ls->ls_fence_work via delayed_work_pending() under ls_lock, but INIT_DELAYED_WORK(&ls->ls_fence_work, ...) currently runs only after the setlease call. On the setlease-failure path the destructor would touch an uninitialized delayed_work. nfsd4_alloc_layout_stateid() nfs4_alloc_stid() /* idr_alloc_cyclic under cl_lock */ nfsd4_layout_setlease() /* fails */ nfs4_put_stid() nfsd4_free_layout_stateid() delayed_work_pending(&ls->ls_fence_work) /* needs INIT */ nfsd4_close_layout() /* nfsd_file_put(ls->ls_file) */ put_nfs4_file() Fix by hoisting the ls_fenced / ls_fence_delay / INIT_DELAYED_WORK initialization above the nfsd4_layout_setlease() call, and replace the manual nfsd_file_put + put_nfs4_file + kmem_cache_free cleanup with a single nfs4_put_stid(stp). Fixes: c5c707f96fc9 ("nfsd: implement pNFS layout recalls") Cc: stable@vger.kernel.org Assisted-by: kres (claude-opus-4-7) Signed-off-by: Chris Mason Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever [ cel: drop fence_work init hoist absent from 6.18.y ] Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 6f88ca186a984da0c1bfdc5163b949b96a707cc7 Author: Olga Kornievskaia Date: Thu Jul 2 16:24:08 2026 -0400 nfsd: update mtime/ctime on COPY in presence of delegated attributes commit 4183cf383b6faec17a0882b84cd2d901dba62b16 upstream. When delegated attributes are given on open, the file is opened with NOCMTIME and modifying operations do not update mtime/ctime as to not get out-of-sync with the client's delegated view. However, for COPY operation, the server should update its view of mtime/ctime and reflect that in any GETATTR queries. Fixes: e5e9b24ab8fa ("nfsd: freeze c/mtime updates with outstanding WRITE_ATTRS delegation") Cc: stable@vger.kernel.org Signed-off-by: Olga Kornievskaia Signed-off-by: Chuck Lever Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 7c702bb4f8d83cc11ffcd01141b0cc2ea6e3a298 Author: Olga Kornievskaia Date: Thu Jul 2 16:24:07 2026 -0400 nfsd: update mtime/ctime on CLONE in presense of delegated attributes commit 2863bac7f49c4acd80a048ce52506a2b9c8db015 upstream. When delegated attributes are given on open, the file is opened with NOCMTIME and modifying operations do not update mtime/ctime as to not get out-of-sync with the client's delegated view. However, for CLONE operation, the server should update its view of mtime/ctime and reflect that in any GETATTR queries. Fixes: e5e9b24ab8fa ("nfsd: freeze c/mtime updates with outstanding WRITE_ATTRS delegation") Cc: stable@vger.kernel.org Signed-off-by: Olga Kornievskaia Signed-off-by: Chuck Lever [ cel: 9be4b7e74eb7 and 3daab3112f03 are missing from linux-6.18.y ] Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 501543207378f69778c66213759e5085ee023302 Author: Daniel Borkmann Date: Thu Jul 2 16:07:56 2026 +0800 bpf, arm64: Reject out-of-range B.cond targets commit 48d83d94930eb4db4c93d2de44838b9455cff626 upstream. aarch64_insn_gen_cond_branch_imm() calls label_imm_common() to compute a 19-bit signed byte offset for a conditional branch, but unlike its siblings aarch64_insn_gen_branch_imm() and aarch64_insn_gen_comp_branch_imm(), it does not check whether label_imm_common() returned its out-of-range sentinel (range) before feeding the value to aarch64_insn_encode_immediate(). aarch64_insn_encode_immediate() unconditionally masks the value with the 19-bit field mask, so an offset that was rejected by label_imm_common() gets silently truncated. With the sentinel value SZ_1M, the resulting field ends up with bit 18 (the sign bit of the 19-bit signed displacement) set, and the CPU decodes it as a ~1 MiB *backward* branch, producing an incorrectly targeted B.cond instruction. For code-gen locations like the emit_bpf_tail_call() this function is the only barrier between an overflowing displacement and a silently miscompiled branch. Fix it by returning AARCH64_BREAK_FAULT when the offset is out of range, so callers see a loud failure instead of a silently misencoded branch. validate_code() scans the generated image for any AARCH64_BREAK_FAULT and then lets the JIT fail. Fixes: 345e0d35ecdd ("arm64: introduce aarch64_insn_gen_cond_branch_imm()") Fixes: c94ae4f7c5ec ("arm64: insn: remove BUG_ON from codegen") Signed-off-by: Daniel Borkmann Reviewed-by: Puranjay Mohan Link: https://lore.kernel.org/r/20260415121403.639619-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Shung-Hsi Yu Signed-off-by: Sasha Levin commit 4b8d52e3d2330e092f4121a562e8f9f973416042 Author: Alexandre Frade Date: Sat Jul 4 17:53:42 2026 +0000 Linux 6.18.38-rt-xanmod1 Signed-off-by: Alexandre Frade commit 0b987ae8e20a5a8202df28a00154c3afb7e53a75 Merge: b0ffe362d9f8 e67923a55781 Author: Alexandre Frade Date: Sat Jul 4 17:53:08 2026 +0000 Merge branch '6.18' into 6.18-rt commit e67923a557816bfc36cf1428ab84ea1883c8097d Author: Alexandre Frade Date: Sat Jul 4 17:48:12 2026 +0000 Linux 6.18.38-xanmod1 Signed-off-by: Alexandre Frade commit 82e2790add0666401418e8f657b90592d2d8f8da Merge: 6e2cd08aa3e8 e46dc0adfe39 Author: Alexandre Frade Date: Sat Jul 4 17:43:57 2026 +0000 Merge tag 'v6.18.38' into 6.18 This is the 6.18.38 stable release commit e46dc0adfe39724bcf52cea47b8f9c9aed86a394 Author: Greg Kroah-Hartman Date: Sat Jul 4 13:44:22 2026 +0200 Linux 6.18.38 Link: https://lore.kernel.org/r/20260702155112.110058792@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Peter Schneider Tested-by: Miguel Ojeda Tested-by: Shung-Hsi Yu Link: https://lore.kernel.org/r/20260703072816.644513463@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Mark Brown Tested-by: Ron Economos Tested-by: Wentao Guan Tested-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 92c63a5ef3c7a2136ee71324c28f1799769206a2 Author: John Johansen Date: Mon Jun 22 16:34:13 2026 -0700 apparmor: advertise the tcp fast open fix is applied commit 2f6701a5ce6257ae7a64ddc6d89d0a08d2a034f8 upstream. The fix for tcp-fast-open ensures that the connect permission is being mediated correctly but it didn't add an artifact to the feature set to advertise the fix is available. Add an artifact so that the test suite can identify if the fix has not been properly applied or a new unexpected regression has occurred. Fixes: 4d587cd8a7215 ("apparmor: mediate the implicit connect of TCP fast open sendmsg") Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit e77fbefd1269b5c123e7c651a1ebdce1b87d19a0 Author: HanQuan Date: Tue Jun 23 01:52:08 2026 +0000 net/tcp-ao: fix use-after-free of key in del_async path commit 5ba9950bc9078e19b69cca1e56d1553b125c6857 upstream. In tcp_ao_delete_key(), the del_async path skips the current_key and rnext_key validity checks present in the synchronous path, assuming these pointers are always NULL on LISTEN sockets. However, if a key was added with set_current=1/set_rnext=1 while the socket was in CLOSE state, current_key and rnext_key will be non-NULL after listen() transitions the socket to LISTEN. When such a key is deleted with del_async=1, hlist_del_rcu() and call_rcu() free the key without clearing the dangling pointers. After the RCU grace period, getsockopt(TCP_AO_INFO) dereferences current_key->sndid and rnext_key->rcvid from freed slab memory. Clear current_key and rnext_key in the del_async path when they reference the key being deleted. Fixes: d6732b95b6fb ("net/tcp: Allow asynchronous delete for TCP-AO keys (MKTs)") Signed-off-by: HanQuan Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260623015208.1191687-1-eilaimemedsnaimel@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3d205fe80f2181f0109150ad1fa06ee5bc046935 Author: Stepan Ionichev Date: Thu May 14 19:37:45 2026 +0500 serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails commit 10fc708b4de7f86002d2d735a2dbf3b5b7f65692 upstream. dw8250_probe() registers the 8250 port via serial8250_register_8250_port() and then, if the device has a clock, registers a clock notifier. If clk_notifier_register() fails, probe returns the error but leaves the 8250 port registered. The matching serial8250_unregister_port() lives in dw8250_remove(), which is not called when probe fails, so the port slot stays occupied until the device is rebound or the system is rebooted. The devm-allocated driver data is freed while the port still references it (via the saved private_data and serial_in/serial_out callbacks), so any access to that port slot before a rebind is a use-after-free hazard. Unregister the port on the clk_notifier_register() error path. Fixes: cc816969d7b5 ("serial: 8250_dw: Fix common clocks usage race condition") Cc: stable@vger.kernel.org Signed-off-by: Stepan Ionichev Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20260514143746.23671-2-sozdayvek@gmail.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7627ff8c4f9919f14de562b0160ab4ec9d80b1f7 Author: Hem Parekh Date: Tue Jun 2 16:56:46 2026 -0700 ksmbd: fix out-of-bounds read in smb_check_perm_dacl() commit 1ef06004ed4bd6d3ed8c840d9d1a376b66d4935b upstream. The permission-check ACE walk in smb_check_perm_dacl() validates the ACE header size and caps sid.num_subauth at SID_MAX_SUB_AUTHORITIES, but it never checks that ace->size is actually large enough to contain num_subauth sub-authorities before compare_sids() dereferences them. CIFS_SID_BASE_SIZE covers the SID header up to but excluding the sub_auth[] array, and offsetof(struct smb_ace, sid) is the ACE header, so the existing guards only guarantee the 8-byte SID base, i.e. zero sub-authorities. compare_sids() then reads ace->sid.sub_auth[i] for i < min(local_sid->num_subauth, ace->sid.num_subauth). The local comparison SIDs (sid_everyone, sid_unix_NFS_mode, and the id_to_sid() result) always have at least one sub-authority, and an attacker controls the ACE revision and authority bytes (which lie within the in-bounds SID base), so they can match one of those SIDs and force the sub_auth read. A crafted ACE with size == 16 and num_subauth >= 1 placed at the tail of the security descriptor therefore causes a heap out-of-bounds read of up to SID_MAX_SUB_AUTHORITIES * sizeof(__le32) bytes past the pntsd allocation. The security descriptor is loaded by ksmbd_vfs_get_sd_xattr() into a buffer sized exactly to the on-disk data (kzalloc(sd_size) in ndr_decode_v4_ntacl()), so the read lands past the allocation. The malformed descriptor can be stored verbatim via SMB2_SET_INFO (the DACL is not normalised before being written to the security.NTACL xattr) and the read fires on a subsequent SMB2_CREATE access check, making this reachable by an authenticated client on a share that uses ACL xattrs. Add the missing num_subauth-versus-ace_size check, mirroring the identical guards already present in the sibling parsers parse_dacl() and smb_inherit_dacl(). Fixes: d07b26f39246 ("ksmbd: require minimum ACE size in smb_check_perm_dacl()") Cc: stable@vger.kernel.org Signed-off-by: Hem Parekh Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 62c26720121bfcb565f136d99bc40a7378a66fa0 Author: Markus Elfring Date: Sun Jun 14 09:56:35 2026 +0200 NFS: Prevent resource leak in nfs_alloc_server() commit d189f224308c8ac3feeea8e442c99922bd18f1b2 upstream. It was overlooked to call ida_free() after a failed nfs_alloc_iostats() call. Thus add the missed function call in an if branch. Fixes: 1c7251187dc067a6d460cf33ca67da9c1dd87807 ("NFS: add superblock sysfs entries") Cc: stable@vger.kernel.org Reported-by: Christophe Jaillet Closes: https://lore.kernel.org/linux-nfs/1c8e10c9-def7-4f0d-8aa1-23c8035a38c8@wanadoo.fr/ Signed-off-by: Markus Elfring Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 6919eb549e8f3caaef16d918749bf2b68d18532d Author: Igor Raits Date: Wed Apr 29 12:49:38 2026 +0200 NFSv4: clear exception state on successful mkdir retry commit 238e9b51aa29f48b6243212a3b75c8e48d6b96fd upstream. After a server returns NFS4ERR_DELAY for an NFSv4 CREATE issued by mkdir(2), the client correctly waits and retries. When the retry succeeds, however, mkdir(2) can still surface -EEXIST to userspace even though the directory was just created on the server. Reproducer (random 16-hex names so collisions are not the cause) against an in-kernel Linux nfsd; reproduces under both NFSv4.0 and NFSv4.2: N=2000000; base=/var/gdc/export for ((i=1; i<=N; i++)); do d=$base/$(openssl rand -hex 8) mkdir "$d" 2>/dev/null || echo "$(date +%T) failed loop=$i $d" rmdir "$d" 2>/dev/null done Failures cluster at the cadence at which the server-side auth/export cache refresh path causes nfsd to return NFS4ERR_DELAY for CREATE. A wire trace of one failure (the three CREATE RPCs all come from a single mkdir(2), generated by the do-while in nfs4_proc_mkdir()): client -> server CREATE name=... -> NFS4ERR_DELAY ~100 ms later client -> server CREATE name=... -> NFS4_OK (dir created) ~80 us later client -> server CREATE name=... -> NFS4ERR_EXIST (correct) Since commit dd862da61e91 ("nfs: fix incorrect handling of large-number NFS errors in nfs4_do_mkdir()"), nfs4_handle_exception() is called only when _nfs4_proc_mkdir() returned an error. That gate breaks retry-state hygiene: nfs4_do_handle_exception() resets exception.{delay,recovering, retry} to 0 on entry, so calling it on success is what previously cleared the retry flag set by the preceding NFS4ERR_DELAY iteration. With the gate in place, exception.retry stays at 1 after the successful retry, the loop runs once more, and the resulting CREATE for an already-created name yields NFS4ERR_EXIST -> -EEXIST to userspace. Drop the conditional and call nfs4_handle_exception() unconditionally, matching every other do-while in fs/nfs/nfs4proc.c (nfs4_proc_symlink(), nfs4_proc_link(), etc.). The dentry/status separation introduced by that commit is preserved. Fixes: dd862da61e91 ("nfs: fix incorrect handling of large-number NFS errors in nfs4_do_mkdir()") Reported-and-tested-by: Jan Čípa Closes: https://lore.kernel.org/linux-nfs/CA+9S74hSp_tJu2Ffe2BPNC2T25gfkhgjjDkdgSsF5c2rnJq_wA@mail.gmail.com/ Reviewed-by: NeilBrown Cc: stable@vger.kernel.org Signed-off-by: Igor Raits Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 012d37a568bfbb2c9686f03ade75560bc7139956 Author: Michael Bommarito Date: Wed May 27 12:30:35 2026 -0400 NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr commit 41fe0f7b84f0cb822ae10ab08592996a592b2a25 upstream. nfs4_decode_mp_ds_addr() decodes the r_netid and r_addr opaques of a netaddr4 from a GETDEVICEINFO multipath-DS body, then immediately calls strrchr(buf, '.') to locate the port separator. Both decodes use xdr_stream_decode_string_dup(), and the current code checks only "nlen < 0" / "rlen < 0" before dereferencing the returned string. When the on-wire opaque has length zero, xdr_stream_decode_opaque_inline() returns 0 and xdr_stream_decode_string_dup() falls through to its "*str = NULL; return ret" tail, leaving buf NULL with a return value of 0. The "< 0" check does not catch this, and the next line is strrchr(NULL, '.'), a kernel NULL pointer dereference reachable from any pNFS-flexfile client mounted against a malicious or compromised metadata server. Reject the zero-length cases explicitly so the decoder fails with -EBADMSG (treated as a malformed GETDEVICEINFO body) instead of panicking the client. Cc: stable@vger.kernel.org Fixes: 6b7f3cf96364 ("nfs41: pull decode_ds_addr from file layout to generic pnfs") Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit d8c90c7cc061265d5f2813a1f5c82ef2f4707e67 Author: Michael Bommarito Date: Wed May 13 12:26:56 2026 -0400 NFSv4/flexfiles: reject zero filehandle version count commit 2c6bb3c40bc24f6aa8dfbe6fe98c3ad6389203f2 upstream. ff_layout_alloc_lseg() decodes the filehandle-version array count from the flexfiles layout body. The value is used as the count for kzalloc_objs(), and the current code only rejects NULL. A zero count yields ZERO_SIZE_PTR, which can be stored in dss_info->fh_versions even though later flexfiles paths assume that at least one filehandle version exists. Reject fh_count == 0 before the allocation, matching the existing zero version_count validation in the flexfiles GETDEVICEINFO parser. A QEMU/KASAN run with a malformed flexfiles layout hit: KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:ff_layout_encode_ff_layoutupdate.isra.0+0x15f/0x750 ff_layout_encode_layoutreturn+0x683/0x970 nfs4_xdr_enc_layoutreturn+0x278/0x3a0 Kernel panic - not syncing: Fatal exception The patched kernel rejects the malformed layout without KASAN/oops/panic, and a valid fh_count=1 regression still opens, reads, and unmounts cleanly. Cc: stable@vger.kernel.org Fixes: d67ae825a59d ("pnfs/flexfiles: Add the FlexFile Layout Driver") Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 4367afc119c51e17a616f6908772b7e2c2c4013f Author: Jeff Layton Date: Fri May 22 12:44:19 2026 -0400 nfsd: reset write verifier on deferred writeback errors commit 2090b05803faab8a9fa62fbff871007862cac1b7 upstream. nfsd_vfs_write() and nfsd_commit() both call filemap_check_wb_err() to detect deferred writeback errors, but neither rotates the server's write verifier (nn->writeverf) when this check fails. Every other durable-storage-failure path in these functions calls commit_reset_write_verifier() before returning an error. The missing rotation means clients holding UNSTABLE write data under the current verifier will COMMIT, receive the unchanged verifier back, and conclude their data is durable — silently dropping data that failed writeback. This violates the UNSTABLE+COMMIT durability contract (RFC 1813 §3.3.7, RFC 8881 §18.32). Add commit_reset_write_verifier() calls at both filemap_check_wb_err() error sites, matching the pattern used by adjacent error paths in the same functions. The helper already filters -EAGAIN and -ESTALE internally, so the calls are unconditionally safe. Reported-by: Chris Mason Fixes: 555dbf1a9aac ("nfsd: Replace use of rwsem with errseq_t") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-6 Signed-off-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 017a6150106b054cc84d1b0582d97bd3a74d4281 Author: Jeff Layton Date: Fri May 22 10:36:14 2026 -0400 nfsd: avoid leaking pre-allocated openowner on unconfirmed retry race commit 57aee7a35bb12753057c5b65d72d1f46c0e95b07 upstream. When find_or_alloc_open_stateowner() encounters an unconfirmed owner, it calls release_openowner() and sets oo = NULL. Control then falls through past the `if (oo)` guard -- which would have freed any pre-allocated `new` -- and unconditionally executes `new = alloc_stateowner(...)`. If `new` was already allocated on a prior iteration, the pointer is silently overwritten and the previous allocation (slab object + owner name buffer) is leaked. This requires a race: two NFSv4.0 OPEN threads with the same owner string, where a concurrent thread inserts a new unconfirmed owner into the hash between retry iterations. The window is narrow but repeatable under adversarial conditions. Fix by adding `goto retry` after `oo = NULL` so the already-allocated `new` is reused on the next iteration rather than overwritten. Reported-by: Chris Mason Fixes: 23df17788c62 ("nfsd: perform all find_openstateowner_str calls in the one place.") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-6 Signed-off-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 0f28337f54cfb7f9777bbc2018be52b7c76c620e Author: Dominik Woźniak Date: Thu May 21 17:46:56 2026 +0200 nfsd: check get_user() return when reading princhashlen commit e186fa1c057f5eccb22afb1e83e34c0627085868 upstream. In __cld_pipe_inprogress_downcall(), the get_user() that reads princhashlen from the userspace cld_msg_v2 buffer does not check its return value. A failing copy leaves princhashlen with uninitialised stack contents, which are then used to drive memdup_user() and stored as princhash.len on the resulting reclaim record. The other get_user() calls in this function all check the return; only this one is missed, which is most likely a copy-paste oversight from when v2 upcalls were introduced. Mirror the existing pattern used a few lines above for namelen. namecopy is declared with __free(kfree) so the early return cleans up the already-allocated buffer automatically. Fixes: 6ee95d1c8991 ("nfsd: add support for upcall version 2") Cc: stable@vger.kernel.org Signed-off-by: Dominik Woźniak Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit dba7da4835de7b17259fa23797d7dbfd36304bf0 Author: Jeff Layton Date: Thu May 21 09:25:40 2026 -0400 nfsd: fix inverted cp_ttl check in async copy reaper commit 0150459b05490b88b7e7378a31550a9e07b5517c upstream. nfsd4_async_copy_reaper() is supposed to keep completed async copy state around for NFSD_COPY_INITIAL_TTL (10) laundromat ticks so that OFFLOAD_STATUS can report the result, then reap the state once the countdown expires. The TTL predicate is inverted: `if (--copy->cp_ttl)` is true while ticks remain and false when the counter reaches zero. This causes the copy to be reaped on the very first tick (cp_ttl goes from 10 to 9, which is non-zero) instead of after all 10 ticks elapse. Once reaped, OFFLOAD_STATUS returns NFS4ERR_BAD_STATEID because the copy state has already been freed. Fix by negating the test so that cleanup runs when the TTL expires. Fixes: aa0ebd21df9c ("NFSD: Add nfsd4_copy time-to-live") Cc: stable@vger.kernel.org Reported-by: Chris Mason Assisted-by: kres:claude-opus-4-6 Signed-off-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 136b416593f1349cf6f72c8e3d18f0f204ee8545 Author: Jeff Layton Date: Thu May 21 13:51:43 2026 -0400 nfsd: fix posix_acl leak on SETACL decode failure commit 0853ac544c590880d797b04daa33fcb72b6be0e1 upstream. nfsaclsvc_decode_setaclargs() and nfs3svc_decode_setaclargs() each call nfs_stream_decode_acl() twice, first for NFS_ACL and then for NFS_DFACL. Each successful call transfers ownership of a freshly allocated posix_acl into argp->acl_access or argp->acl_default. If the first call succeeds but the second fails, the decoder returns false and argp->acl_access is left dangling. ACLPROC2_SETACL.pc_release was wired to nfssvc_release_attrstat and ACLPROC3_SETACL.pc_release was wired to nfs3svc_release_fhandle. Both only call fh_put() and have no knowledge of the ACL fields on argp. The posix_acl_release() pairs sat at the out: labels inside nfsacld_proc_setacl() and nfsd3_proc_setacl(), but svc_process() skips pc_func when pc_decode returns false, so that cleanup is unreachable on decode failure: svc_process_common() pc_decode() /* decode_setaclargs: false */ /* pc_func skipped */ pc_release() /* fh_put only -- ACLs leaked */ The orphaned posix_acl is leaked for the lifetime of the server. Fix by adding nfsaclsvc_release_setacl() and nfs3svc_release_setacl(), which release both argp->acl_access and argp->acl_default in addition to fh_put(), and wiring them as pc_release for their respective SETACL procedures. pc_release runs on every path svc_process() takes after decode, including decode failure, so the posix_acl_release() pairs are removed from the proc functions' out: labels to keep ownership in one place. This matches the existing release_getacl() pattern used by the sibling GETACL procedures. Fixes: a257cdd0e217 ("[PATCH] NFSD: Add server support for NFSv3 ACLs.") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-7 Signed-off-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit c8a24effd96d4779e2ad779654682304491c55a5 Author: Guannan Wang Date: Thu May 21 16:03:32 2026 +0800 NFSD: Fix SECINFO_NO_NAME decode error cleanup commit 9e18e83b8846a5c3fe13fc8a464b4865d33996c6 upstream. nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 ("NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo(). Fixes: 3fdc54646234 ("NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing") Cc: stable@vger.kernel.org Signed-off-by: Guannan Wang Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 6a946038f2a5a8c29048c6af369d4e391448a5c5 Author: Johan Hovold Date: Mon May 11 16:37:12 2026 +0200 i2c: core: fix adapter registration race commit ba14d7cf2fe7284610a29854bdff22b2537d3ce6 upstream. Adapters can be looked up based on their id using i2c_get_adapter() which takes a reference to the embedded struct device. Make sure that the adapter (including its struct device) has been initialised before adding it to the IDR to avoid accessing uninitialised data which could, for example, lead to NULL-pointer dereferences or use-after-free. Note that the i2c-dev chardev, which is registered from a bus notifier, currently uses i2c_get_adapter() so the adapter needs to be added to the IDR before registration. Fixes: 6e13e6418418 ("i2c: Add i2c_add_numbered_adapter()") Cc: stable@vger.kernel.org # 2.6.22 Signed-off-by: Johan Hovold Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit fc6aa9bdbae60cdd8ae2358c7ee87c6fdb1132a4 Author: Steffen Persvold Date: Fri Jun 12 18:40:41 2026 +0200 fbdev: modedb: Fix misaligned fields in the 1920x1080-60 mode commit d894c48a57d78206e4df9c90d4acfaf39394806a upstream. The 1920x1080@60 modedb entry has one too many initializers before its sync field: a stray "0" occupies the sync slot, which shifts the remaining values by one field. The entry therefore decodes as sync = 0, vmode = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT (0x3, i.e. FB_VMODE_INTERLACED | FB_VMODE_DOUBLE), and flag = FB_VMODE_NONINTERLACED, instead of the intended sync = positive H/V, vmode = non-interlaced. fb_find_mode() then returns a 1920x1080 mode flagged as interlaced + doublescan with active-low syncs. Drivers that honour var->vmode and var->sync when programming display timing enable doublescan and the wrong sync polarity, corrupting the output. Drop the stray initializer so sync and vmode hold their intended values (positive H/V sync, non-interlaced), matching the adjacent 1920x1200 entry. Fixes: c8902258b2b8 ("fbdev: modedb: Add 1920x1080 at 60 Hz video mode") Cc: stable@vger.kernel.org Signed-off-by: Steffen Persvold Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 4d418cf8daf57e454b4d855bf9b2419fd8e6a540 Author: Tuo Li Date: Wed Jun 10 10:50:14 2026 +0800 fbdev: modedb: fix a possible UAF in fb_find_mode() commit 85b6256469cebdac395e7447147e06b2e151014f upstream. If mode_option is NULL, it is assigned from mode_option_buf: if (!mode_option) { fb_get_options(NULL, &mode_option_buf); mode_option = mode_option_buf; } Later, name is assigned from mode_option: const char *name = mode_option; However, mode_option_buf is freed before name is no longer used: kfree(mode_option_buf); while name is still accessed by: if ((name_matches(db[i], name, namelen) || Since name aliases mode_option_buf, this may result in a use-after-free. Fix this by extending the lifetime of mode_option_buf until the end of the function by using scope-based resource management for cleanup. Signed-off-by: Tuo Li Cc: stable@vger.kernel.org # v6.5+ Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit eea16b6f805c0b1fb2f72f0f771088ea45356956 Author: Ian Bridges Date: Wed Jun 24 23:13:12 2026 -0500 fbdev: Fix fb_new_modelist to prevent null-ptr-deref in fb_videomode_to_var commit 7f08fc10fa3d3366dc3af723970bd03d7d6d10e3 upstream. info->var, a framebuffer's current mode, is expected to have a matching entry in info->modelist. var_to_display() relies on this and treats a failed fb_match_mode() as "This should not happen". fb_set_var() keeps it true by adding the mode to the list on every change, and do_register_framebuffer() does the same at registration. store_modes() replaces the modelist from userspace. fb_new_modelist() validates the new modes but does not check that info->var still has a match. It relies on fbcon_new_modelist() to re-point consoles, but that only handles consoles mapped to the framebuffer. With fbcon unbound there are none, so info->var is left describing a mode that is no longer in the list. A later console takeover runs var_to_display(), where fb_match_mode() returns NULL and leaves fb_display[i].mode NULL. fbcon_switch() passes it to display_to_var(), and fb_videomode_to_var() dereferences the NULL mode. Keep the current mode in the list in fb_new_modelist(), the same way fb_set_var() does. 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 7643e5622994f9b207445f9cd89a02223ce6a99f Author: Vivian Wang Date: Tue Mar 3 13:29:46 2026 +0800 riscv: kfence: Call mark_new_valid_map() for kfence_unprotect() commit 8d6c8c40e733b3fcaf92fed0a078bba2f6941a3b upstream. In kfence_protect_page(), which kfence_unprotect() calls, we cannot send IPIs to other CPUs to ask them to flush TLB. This may lead to those CPUs spuriously faulting on a recently allocated kfence object despite it being valid, leading to false positive use-after-free reports. Fix this by calling mark_new_valid_map() so that the page fault handling code path notices the spurious fault and flushes TLB then retries the access. Update the comment in handle_exception to indicate that new_valid_map_cpus_check also handles kfence_unprotect() spurious faults. Note that kfence_protect() has the same stale TLB entries problem, but that leads to false negatives, which is fine with kfence. Cc: stable@vger.kernel.org Reported-by: Yanko Kaneti Fixes: b3431a8bb336 ("riscv: Fix IPIs usage in kfence_protect_page()") Signed-off-by: Vivian Wang Link: https://patch.msgid.link/20260303-handle-kfence-protect-spurious-fault-v2-2-f80d8354d79d@iscas.ac.cn Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit 3b33dbb43e21a8d1248dbe906d9e27f640a6001a Author: Vivian Wang Date: Tue Mar 3 13:29:45 2026 +0800 riscv: mm: Extract helper mark_new_valid_map() commit 9ee25d0a70ff4494b4e1d266b962d0a574ef318a upstream. In preparation of a future patch using the same mechanism for non-vmalloc addresses, extract the mark_new_valid_map() helper from flush_cache_vmap(). No functional change intended. Cc: stable@vger.kernel.org Signed-off-by: Vivian Wang Link: https://patch.msgid.link/20260303-handle-kfence-protect-spurious-fault-v2-1-f80d8354d79d@iscas.ac.cn Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit 2205275be9be981e70ff29610b0117d8853fac70 Author: Wentao Liang Date: Tue Apr 7 07:30:25 2026 +0000 power: reset: linkstation-poweroff: fix use-after-free in the linkstation_poweroff_init() commit 8eec545cde69e46e9a1d2b7d915ce4f5df85b3bd upstream. Move of_node_put(dn) after the of_match_node() call, which still needs the node pointer. The node reference is correctly released after use. Fixes: e2f471efe1d6 ("power: reset: linkstation-poweroff: prepare for new devices") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260407073025.271865-1-vulab@iscas.ac.cn Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 720949ed666f34ff28ffdfe1471a5861d1e41fdf Author: Ashutosh Desai Date: Fri May 1 13:35:32 2026 -0700 KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path commit 78ee2d50185a037b3d2452a97f3dad69c3f7f389 upstream. In sev_dbg_crypt(), the per-iteration transfer length is bounded by the source page offset (PAGE_SIZE - s_off) but not by the destination page offset (PAGE_SIZE - d_off). When d_off > s_off, the encrypt path (__sev_dbg_encrypt_user) performs a read-modify-write using a single-page intermediate buffer (dst_tpage): 1. __sev_dbg_decrypt() expands the size to round_up(len + (d_off & 15), 16) before issuing the PSP command. If len + (d_off & 15) > PAGE_SIZE, the PSP writes beyond the end of the 4096-byte dst_tpage allocation. 2. The subsequent memcpy()/copy_from_user() into page_address(dst_tpage) + (d_off & 15) of 'len' bytes overflows by up to 15 bytes under the same condition. Trigger example: s_off = 0, d_off = 1, debug.len = PAGE_SIZE - the PSP is instructed to write round_up(4097, 16) = 4112 bytes to a 4096-byte buffer. Fix by also bounding len by (PAGE_SIZE - d_off), the same check that sev_send_update_data() already performs for its single-page guest region. ================================================================== BUG: KASAN: slab-use-after-free in sev_dbg_crypt+0x993/0xd10 [kvm_amd] Write of size 4095 at addr ff110062293bb009 by task sev_dbg_test/228214 CPU: 96 UID: 0 PID: 228214 Comm: sev_dbg_test Tainted: G U W 7.0.0-smp--5ce9b0c48211-dbg #156 PREEMPTLAZY Tainted: [U]=USER, [W]=WARN Hardware name: Google Astoria/astoria, BIOS 0.20250817.1-0 08/25/2025 Call Trace: dump_stack_lvl+0x54/0x70 print_report+0xbc/0x260 kasan_report+0xa2/0xd0 kasan_check_range+0x25f/0x2c0 __asan_memcpy+0x40/0x70 sev_dbg_crypt+0x993/0xd10 [kvm_amd] sev_mem_enc_ioctl+0x33c/0x450 [kvm_amd] kvm_vm_ioctl+0x65d/0x6d0 [kvm] __se_sys_ioctl+0xb2/0x100 do_syscall_64+0xe8/0x870 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7fe72b6a0 pfn:0x62293bb memcg:ff11000112827d82 flags: 0x1400000000000000(node=1|zone=1) raw: 1400000000000000 0000000000000000 dead000000000122 0000000000000000 raw: 00000007fe72b6a0 0000000000000000 00000001ffffffff ff11000112827d82 page dumped because: kasan: bad access detected Memory state around the buggy address: ff110062293bbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff110062293bbf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ff110062293bc000: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ^ ff110062293bc080: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ff110062293bc100: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint Fixes: 24f41fb23a39 ("KVM: SVM: Add support for SEV DEBUG_DECRYPT command") Fixes: 7d1594f5d94b ("KVM: SVM: Add support for SEV DEBUG_ENCRYPT command") Cc: stable@vger.kernel.org Signed-off-by: Ashutosh Desai [sean: add sample KASAN splat, Fixes, and stable@] Link: https://patch.msgid.link/20260501203537.2120074-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit e36095d8d922bb26ce860231aacf0cd14edea07c Author: Hyunwoo Kim Date: Sat Jun 6 23:44:52 2026 +0900 KVM: x86: hyper-v: Bound the bank index when querying sparse banks commit 4721f8160f17554b003e8928bb61e6c9b2fe92a3 upstream. When checking if a VP ID is included in a sparse bank set, explicitly check that the ID can actually be contained in a sparse bank (the TLFS allows for a maximum of 64 banks of 64 vCPUs each). When handling a paravirtual TLB flush for L2, the VP ID is copied verbatim from the enlightened VMCS, without any bounds check, i.e. isn't guaranteed to be under the limit of 4096. Failure to check the bounds of the VP ID leads to an out-of-bounds read when testing the sparse bank, and super strictly speaking could lead to KVM performing an unnecessary TLB flush for an L2 vCPU. ================================================================== BUG: KASAN: use-after-free in hv_is_vp_in_sparse_set+0x85/0x100 [kvm] Read of size 8 at addr ffff88811ba5f598 by task hyperv_evmcs/2802 CPU: 12 UID: 1000 PID: 2802 Comm: hyperv_evmcs Not tainted 7.1.0-rc2 #7 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xcb/0x5d0 kasan_report+0xb4/0xe0 kasan_check_range+0x35/0x1b0 hv_is_vp_in_sparse_set+0x85/0x100 [kvm] kvm_hv_flush_tlb+0xe9e/0x16c0 [kvm] kvm_hv_hypercall+0xe6b/0x1e60 [kvm] vmx_handle_exit+0x485/0x1b60 [kvm_intel] kvm_arch_vcpu_ioctl_run+0x22e3/0x5070 [kvm] kvm_vcpu_ioctl+0x5d0/0x10c0 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0xb9/0xcf0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f0e62d1a9bf The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffffffffffffff pfn:0x11ba5f flags: 0x4000000000000000(zone=1) raw: 4000000000000000 0000000000000000 00000000ffffffff 0000000000000000 raw: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88811ba5f480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88811ba5f580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88811ba5f600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint Opportunistically add a compile time assertion to ensure the maximum number of sparse banks exactly matches the number of possible bits in the passed in mask. Cc: stable@vger.kernel.org Fixes: c58a318f6090 ("KVM: x86: hyper-v: L2 TLB flush") Signed-off-by: Hyunwoo Kim Reviewed-by: Vitaly Kuznetsov Link: https://patch.msgid.link/aiQyZIJtO-2Aj_xN@v4bel [sean: add KASAN splat, drop comment, add assert, massage changelog] Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit f9b57a0015c241274651f4b36627f56b1b5a8651 Author: Jonas Jelonek Date: Mon Jun 8 09:37:29 2026 +0000 MIPS: smp: report dying CPU to RCU in stop_this_cpu() commit 9f3f3bdc6d9dac1a5a8262ee7ad0f2ff1527a7e7 upstream. smp_send_stop() parks all secondary CPUs in stop_this_cpu(). The function marks the CPU offline for the scheduler via set_cpu_online(false) but never informs RCU, so RCU keeps expecting a quiescent state from CPUs that are now spinning forever with interrupts disabled. As long as nothing waits for an RCU grace period after smp_send_stop() this is harmless, which is why it went unnoticed. Since commit 91840be8f710 ("irq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT") however, irq_work_sync() calls synchronize_rcu() on architectures without an irq_work self-IPI, i.e. where arch_irq_work_has_interrupt() returns false. That is the asm-generic default used by MIPS. Any irq_work_sync() issued in the reboot/shutdown path after smp_send_stop() then blocks on a grace period that can never complete, hanging the reboot: WARNING: CPU: 0 PID: 15 at kernel/irq_work.c:144 irq_work_queue_on ... rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: Offline CPU 1 blocking current GP. rcu: Offline CPU 2 blocking current GP. rcu: Offline CPU 3 blocking current GP. This issue was noticed on several Realtek MIPS switch SoCs (MIPS interAptiv) and came up during kernel bump downstream in OpenWrt from 6.18.33 to 6.18.34, after the backport of the patch to the 6.18 stable branch. The patch also has been backported all the way back to 6.1. Call rcutree_report_cpu_dead() once interrupts are disabled, mirroring the generic CPU-hotplug offline path, so RCU stops waiting on the parked CPUs and grace periods can still complete. MIPS shuts down all CPUs here without going through the CPU-hotplug mechanism, so this report is not otherwise issued. Reporting a dying CPU to RCU outside the regular hotplug offline path is not unprecedented: arm64 does the same in cpu_die_early(). There it is an exception for a CPU that was coming online and is aborting bringup, rather than the default shutdown action as on MIPS. Fixes: 91840be8f710 ("irq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT") CC: stable@vger.kernel.org Signed-off-by: Jonas Jelonek Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 6dbe9443d9f5f7fb6d319a7b77108853ae6c6bea Author: Yizhou Zhao Date: Thu May 28 13:39:16 2026 +0800 9p: avoid putting oldfid in p9_client_walk() error path commit 1a3860d46e3eb47dbd60339783cdad7904486b9f upstream. When p9_client_walk() is called with clone set to false, fid aliases oldfid. If the walk subsequently fails after the request has been sent, the error path jumps to clunk_fid, which currently calls p9_fid_put(fid) unconditionally. This drops a reference to oldfid even though ownership of oldfid remains with the caller. If this is the last reference, oldfid can be clunked and destroyed while the caller still expects it to be valid. A later use or put of oldfid can then trigger a use-after-free or refcount underflow. Fix this by only putting fid in the clunk_fid error path when it does not alias oldfid, matching the existing guard in the error path below. This can be triggered when a multi-component walk is split into multiple p9_client_walk() calls and a later non-cloning walk fails. A reproducer and refcount warning logs are available on request. Fixes: b48dbb998d70 ("9p fid refcount: add p9_fid_get/put wrappers") Cc: stable@vger.kernel.org Reported-by: Yuxiang Yang Reported-by: Ao Wang Reported-by: Xuewei Feng Reported-by: Qi Li Reported-by: Ke Xu Assisted-by: GLM 5.1 Signed-off-by: Yizhou Zhao Message-ID: <20260528053918.53550-1-zhaoyz24@mails.tsinghua.edu.cn> Signed-off-by: Dominique Martinet Signed-off-by: Greg Kroah-Hartman commit 4cd57ebee395041099fcdfcabb00749ce38d8b27 Author: Zhang Cen Date: Sun May 24 19:12:48 2026 +0800 ocfs2: reject oversized group bitmap descriptors commit 9bd541e09dffff27e5bec0f9f45b0228173a5375 upstream. ocfs2_validate_gd_parent() only bounds bg_bits against the parent allocator's chain geometry. A malicious descriptor can still claim a bg_size/bg_bits pair that exceeds the bitmap bytes that physically fit in the group descriptor block, so later bitmap scans and bit updates can run past bg_bitmap. Add a physical-cap check based on ocfs2_group_bitmap_size() for the parent allocator type and reject descriptors whose bg_size or bg_bits exceed that capacity. Keep the existing chain geometry check so both the on-disk bitmap layout and the allocator metadata must agree before the descriptor is used. Validation reproduced this kernel report: KASAN use-after-free in _find_next_bit+0x7f/0xc0 Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xd0/0x630 (?:?) _find_next_bit+0x7f/0xc0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x188/0x2f0 (?:?) kasan_report+0xe4/0x120 (?:?) ocfs2_find_max_contig_free_bits+0x35/0x70 (fs/ocfs2/suballoc.c:1375) ocfs2_block_group_set_bits+0x472/0x4b0 (fs/ocfs2/suballoc.c:1457) ocfs2_cluster_group_search+0x16b/0x440 (fs/ocfs2/suballoc.c:86) ocfs2_bg_discontig_fix_result+0x1ef/0x230 (fs/ocfs2/suballoc.c:1786) ocfs2_search_chain+0x8f8/0x10a0 (fs/ocfs2/suballoc.c:1886) get_page_from_freelist+0x70e/0x2370 (?:?) lock_release+0xc6/0x290 (?:?) do_raw_spin_unlock+0x9a/0x100 (?:?) kasan_unpoison+0x27/0x60 (?:?) __bfs+0x147/0x240 (?:?) get_page_from_freelist+0x83d/0x2370 (?:?) ocfs2_claim_suballoc_bits+0x38c/0xe70 (fs/ocfs2/suballoc.c:96) sched_domains_numa_masks_clear+0x70/0xd0 (?:?) check_irq_usage+0xe8/0xb70 (?:?) __ocfs2_claim_clusters+0x18d/0x4c0 (fs/ocfs2/suballoc.c:2497) check_path+0x24/0x50 (?:?) rcu_is_watching+0x20/0x50 (?:?) check_prev_add+0xfd/0xd00 (?:?) ocfs2_add_clusters_in_btree+0x17d/0x810 (fs/ocfs2/suballoc.c:?) __folio_batch_add_and_move+0x1f5/0x3d0 (?:?) ocfs2_add_inode_data+0xd9/0x120 (fs/ocfs2/suballoc.c:?) filemap_add_folio+0x105/0x1f0 (?:?) ocfs2_write_begin_nolock+0x29f7/0x2f80 (fs/ocfs2/suballoc.c:3043) ocfs2_read_inode_block+0xb5/0x110 (fs/ocfs2/suballoc.c:?) down_write+0xf5/0x180 (?:?) ocfs2_write_begin+0x180/0x240 (fs/ocfs2/suballoc.c:?) __mark_inode_dirty+0x758/0x9a0 (?:?) inode_to_bdi+0x41/0x90 (?:?) balance_dirty_pages_ratelimited_flags+0xf8/0x1d0 (?:?) generic_perform_write+0x252/0x440 (?:?) mnt_put_write_access_file+0x16/0x70 (?:?) file_update_time_flags+0xe4/0x200 (?:?) ocfs2_file_write_iter+0x80a/0x1320 (fs/ocfs2/suballoc.c:?) lock_acquire+0x184/0x2f0 (?:?) ksys_write+0xd2/0x170 (?:?) apparmor_file_permission+0xf5/0x310 (?:?) read_zero+0x8d/0x140 (?:?) lock_is_held_type+0x8f/0x100 (?:?) Link: https://lore.kernel.org/20260524111248.1429884-1-rollkingzzc@gmail.com Fixes: ccd979bdbce9 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem") 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 Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 104d100212396801f1d9d388282f746e23e2bfd6 Author: Yuho Choi Date: Mon Jun 1 14:32:47 2026 -0400 rpmsg: char: Fix use-after-free on probe error path commit 1ff3f528e67d20e2b1483dcaba899dc7832b2e6b upstream. rpmsg_chrdev_probe() stores the newly allocated eptdev in the default endpoint's priv pointer before calling rpmsg_chrdev_eptdev_add(). If rpmsg_chrdev_eptdev_add() then fails, its error path frees eptdev while the default endpoint may still dispatch callbacks with the stale priv pointer. Avoid publishing eptdev through the default endpoint until rpmsg_chrdev_eptdev_add() succeeds. Messages received before the priv pointer is published should be ignored by rpmsg_ept_cb(). Flow-control updates can hit rpmsg_ept_flow_cb() in the same window, so make both callbacks return success when priv is NULL. Fixes: bc69d1066569 ("rpmsg: char: Introduce the "rpmsg-raw" channel") Signed-off-by: Yuho Choi Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20260601183247.1962010-1-dbgh9129@gmail.com Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit 369496d885b4cf6e8647cf4dc5cf3ac68fdf37a1 Author: Wentao Liang Date: Wed Apr 8 15:45:34 2026 +0000 fpga: region: fix use-after-free in child_regions_with_firmware() commit 54f3c5643ec523a04b6ec0e7c19eb10f5ebebdd3 upstream. Move of_node_put(child_region) after the error print to avoid accessing freed memory when pr_err() references child_region. Fixes: 0fa20cdfcc1f ("fpga: fpga-region: device tree control for FPGA") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang [ Yilun: Fix the Fixes tag ] Reviewed-by: Xu Yilun Link: https://lore.kernel.org/r/20260408154534.404327-1-vulab@iscas.ac.cn Signed-off-by: Xu Yilun Signed-off-by: Greg Kroah-Hartman commit b3a3831b2eb884641906fc5e46207b205b6aea13 Author: Qingshuang Fu Date: Thu Jun 18 10:13:52 2026 +0800 irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup on remove commit 37738fdf2ab1e504d1c63ce5bc0aeb6452d8f057 upstream. The driver allocates domain generic chips using irq_alloc_domain_generic_chips() during probe and sets up chained handlers using irq_set_chained_handler_and_data(). However, on driver removal, the generic chips are not freed and the chained handlers are not removed. The generic chips remain on the global gc_list and may later be accessed by generic interrupt chip suspend, resume, or shutdown callbacks after the driver has been removed, potentially resulting in a use-after-free and kernel crash. The chained handlers that were installed in probe for peripheral and syswake interrupts are also left dangling, which can lead to spurious interrupts accessing freed memory. Fix these issues by: - Setting IRQ_DOMAIN_FLAG_DESTROY_GC flag in domain->flags, so the core code automatically removes generic chips when irq_domain_remove() is called - Clearing all chained handlers with NULL in pdc_intc_remove() Fixes: b6ef9161e43a ("irq-imgpdc: add ImgTec PDC irqchip driver") Signed-off-by: Qingshuang Fu Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260618021352.661773-1-fffsqian@163.com Signed-off-by: Greg Kroah-Hartman commit 200e7637f4d6a1342987045eea72641524f909dc Author: Wentao Liang Date: Mon May 18 13:10:36 2026 +0000 pNFS: Fix use-after-free in pnfs_update_layout() commit 13e198a90ca4050f4bee8a3f23680389a6563ccc upstream. When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo). Fixes: 2c8d5fc37fe2 ("pNFS: Stricter ordering of layoutget and layoutreturn") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 90e254f18b8c224460082329dd5c42fd30995c2f Author: Huacai Chen Date: Thu Jun 25 13:03:49 2026 +0800 LoongArch: Report dying CPU to RCU in stop_this_cpu() commit f2539c56c74691e7a88af6372ba2b48c06ed2fe4 upstream. This is a port of MIPS commit 9f3f3bdc6d9dac1 ("MIPS: smp: report dying CPU to RCU in stop_this_cpu()"). smp_send_stop() parks all secondary CPUs in stop_this_cpu(). And the function marks the CPU offline for the scheduler via set_cpu_online(false) but never informs RCU, so RCU keeps expecting a quiescent state from CPUs that are now spinning forever with interrupts disabled. As long as nothing waits for an RCU grace period after smp_send_stop() this is harmless, which is why it went unnoticed. However, since commit 91840be8f710370 ("irq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT"), irq_work_sync() calls synchronize_rcu() on architectures without an irq_work self-IPI, i.e. where arch_irq_work_has_interrupt() returns false. Any irq_work_sync() issued in the reboot/shutdown/halt path after smp_send_stop() then blocks on a grace period that can never complete, hanging the reboot: WARNING: CPU: 0 PID: 15 at kernel/irq_work.c:144 irq_work_queue_on ... rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: Offline CPU 1 blocking current GP. rcu: Offline CPU 2 blocking current GP. rcu: Offline CPU 3 blocking current GP. This issue needs some hacks to reproduce, and it was not noticed on LoongArch because arch_irq_work_has_interrupt() usually returns true. Call rcutree_report_cpu_dead() once interrupts are disabled, mirroring the generic CPU-hotplug offline path, so RCU stops waiting on the parked CPUs and grace periods can still complete. LoongArch shuts down all CPUs here without going through the CPU-hotplug mechanism, so this report is not otherwise issued. Cc: Fixes: 91840be8f710 ("irq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT") Reviewed-by: Guo Ren Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit e18769616fd5a90ec1e12aabbba544c488284292 Author: Doruk Tan Ozturk Date: Wed Jun 17 09:58:18 2026 +0200 tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done commit bda3348872a2ef0d19f2df6aa8cb5025adce2f20 upstream. tipc_aead_decrypt() goes straight from tipc_bearer_hold(b) to crypto_aead_decrypt(req) without taking a reference on the netns, unlike the encrypt path. When crypto_aead_decrypt() is offloaded asynchronously (e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs tipc_aead_decrypt_done() later. If the bearer's netns is torn down in the meantime, cleanup_net() -> tipc_exit_net() -> tipc_crypto_stop() frees the per-netns tipc_crypto, and the completion then reads it: tipc_aead_decrypt_done() dereferences aead->crypto->stats and aead->crypto->net, and tipc_crypto_rcv_complete() dereferences aead->crypto->aead[] and the node table -- reading freed memory. Decoded KASAN splat (v7.1-rc7, CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO): BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done (net/tipc/crypto.c:999) Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51 Workqueue: events_unbound Call Trace: tipc_aead_decrypt_done (net/tipc/crypto.c:999) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Allocated by task 169: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) tipc_crypto_start (net/tipc/crypto.c:1502) tipc_init_net (net/tipc/core.c:72) ops_init (net/core/net_namespace.c:137) setup_net (net/core/net_namespace.c:446) copy_net_ns (net/core/net_namespace.c:579) create_new_namespaces (kernel/nsproxy.c:132) __x64_sys_unshare (kernel/fork.c:3316) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Freed by task 8: kfree (mm/slub.c:6566) tipc_exit_net (net/tipc/core.c:119) cleanup_net (net/core/net_namespace.c:704) process_one_work (kernel/workqueue.c:3314) kthread (kernel/kthread.c:436) This is the same class of bug that commit e279024617134 ("net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done") fixed for the encrypt side. The encrypt path takes maybe_get_net(aead->crypto->net) before crypto_aead_encrypt() and drops it with put_net() on the synchronous return paths and in tipc_aead_encrypt_done(); the -EINPROGRESS/-EBUSY return keeps the reference for the async callback to release. The decrypt path was left without the equivalent guard. Mirror the encrypt-side fix on the decrypt path: take a net reference before crypto_aead_decrypt() (failing with -ENODEV and the matching bearer put if it cannot be acquired), keep it across the -EINPROGRESS/-EBUSY async return, and drop it with put_net() on the synchronous success/error return and at the end of tipc_aead_decrypt_done(). Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is flooded with crafted encrypted frames from an unknown peer (driving the cluster-key decrypt path) while the bearer's netns is repeatedly torn down. The completion must run asynchronously to outlive tipc_crypto_stop(); on x86 the stock aesni gcm(aes) now decrypts synchronously, so the async path was exercised via cryptd offload. The unguarded aead->crypto dereference in tipc_aead_decrypt_done() is the unpatched upstream path; tipc_aead_decrypt() still lacks maybe_get_net(aead->crypto->net), so the completion can outlive the free on any config where crypto_aead_decrypt() goes async. Found by 0sec automated security-research tooling (https://0sec.ai). Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication") Cc: stable@vger.kernel.org Signed-off-by: Doruk Tan Ozturk Reviewed-by: Alexander Lobakin Reviewed-by: Tung Nguyen Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260617075818.37431-1-doruk@0sec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5e5b7f2ef854936e95dceb6a2fdfefcb7152d2c6 Author: Michal Koutný Date: Thu Feb 5 23:54:23 2026 +0800 blk-cgroup: fix UAF in __blkcg_rstat_flush() commit 0ab5ee5a1badb58cbb2242617cb01a4972b1f2a2 upstream. When multiple blkgs in the same blkcg are released concurrently, a use-after-free can occur. The race happens when one blkg's __blkcg_rstat_flush() removes another blkg's iostat entries via llist_del_all(). The second blkg sees an empty list and proceeds to free itself while the first is still iterating over its entries. Move the flush from __blkg_release() (RCU callback) to blkg_release() (before call_rcu). This ensures the RCU grace period waits for any concurrent flush's rcu_read_lock() section to complete before freeing. Cc: stable@vger.kernel.org Cc: Jay Shin Cc: Tejun Heo Cc: Waiman Long Fixes: 20cb1c2fb756 ("blk-cgroup: Flush stats before releasing blkcg_gq") Reported-by: coregee2000@gmail.com Closes: https://lore.kernel.org/linux-block/CAHPqNmwT9oRpem3J3erS_W0uSQND47LGGSBsNxP8E6uSUish1w@mail.gmail.com/ Signed-off-by: Ming Lei Tested-by: Jose Fernandez (Anthropic) Link: https://patch.msgid.link/20260205155425.342084-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 5a84398101bf9f11e84b176343e4e3ba83e668c0 Author: Fan Wu Date: Wed Jun 17 02:05:18 2026 +0000 hdlc_ppp: sync per-proto timers before freeing hdlc state commit c78a4e41ab5ead6193ad8a2dd92e8906bae659fa upstream. Each PPP control protocol (LCP/IPCP/IPV6CP) embedded in struct ppp registers a timer via timer_setup(). That struct ppp is the hdlc->state allocation, which detach_hdlc_protocol() frees with kfree() in both teardown paths: unregister_hdlc_device() and the re-attach inside attach_hdlc_protocol(). The ppp proto never registered a .detach callback, so detach_hdlc_protocol() performs no timer synchronization before the kfree(). The only cancel, timer_delete(&proto->timer) in ppp_cp_event(), is partial (it does not wait for a running callback) and only runs on the ->CLOSED transition; ppp_stop()/ppp_close() do not sync either. A ppp_timer callback already executing (blocked on ppp->lock) survives the kfree and then dereferences proto->state / ppp->lock in freed memory, leading to a use-after-free. Fix this by adding a .detach helper that calls timer_shutdown_sync() on every per-proto timer. detach_hdlc_protocol() invokes proto->detach(dev) before kfree(hdlc->state), so timer_shutdown_sync() now runs on both free paths. timer_shutdown_sync() is used instead of timer_delete_sync() because the keepalive path re-arms the timer through add_timer()/mod_timer() and shutdown blocks any re-activation during teardown. Initialize the per-protocol timers in ppp_ioctl() when the protocol is attached, and remove the now-redundant timer_setup() from ppp_start(), so that the timers are initialized exactly once at attach time and ppp_timer_release() never operates on uninitialized timer_list structures. attach_hdlc_protocol() uses kmalloc() (not kzalloc), so struct ppp's protos[i].timer is uninitialized garbage until the first timer_setup(); without this init-at-attach, attaching the PPP protocol without ever bringing the device up would leave timer_shutdown_sync() operating on uninitialized memory in .detach. Moving the init out of ppp_start() (which only runs on NETDEV_UP) into the attach path makes the initialization unconditional and avoids initializing the same timer_list twice. This bug was found by static analysis. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260617020518.116319-1-fanwu01@zju.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e91df6d273445c03f5aa302bfe147eda33d45794 Author: Wentao Liang Date: Tue Jun 16 15:10:49 2026 +0000 pwrseq: core: fix use-after-free in pwrseq_debugfs_seq_next() commit 257595adf9dac15ae1edd9d07753fbc576a7583d upstream. pwrseq_debugfs_seq_next() declares 'next' with __free(put_device), which causes put_device() to be called on the returned pointer when the variable goes out of scope. This results in a use-after-free since the seq_file framework receives a pointer whose reference has already been dropped. Simply removing __free(put_device) would fix the UAF but would leak the reference acquired by bus_find_next_device(), as stop() only calls up_read(&pwrseq_sem) and never releases the device reference. Fix this by making the reference counting consistent across all seq_file callbacks, matching the standard pattern used by PCI and SCSI: - start(): use get_device() so it returns a referenced pointer. - next(): explicitly put_device(curr) to release the previous device's reference (no NULL check needed - the seq_file framework only calls next() while the previous return was non-NULL). - stop(): put_device(data) to release the last iterated device's reference, with a NULL guard since stop() may be called with NULL when start() returned NULL or next() reached end-of-sequence. Cc: stable@vger.kernel.org Fixes: 249ebf3f65f8 ("power: sequencing: implement the pwrseq core") Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260616151049.1705503-1-vulab@iscas.ac.cn Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit b85ef03f726b15047a6fa6d11b639bdf6c0ee4f0 Author: Tristan Madani Date: Fri May 1 11:02:03 2026 +0000 gfs2: fix use-after-free in gfs2_qd_dealloc commit f9c9ec2c319f843b70ecdf939d48b52d189bc081 upstream. gfs2_qd_dealloc(), called as an RCU callback from gfs2_qd_dispose(), accesses the superblock object sdp through qd->qd_sbd after freeing qd. It does so to decrement sd_quota_count and wake up sd_kill_wait. However, by the time the RCU callback runs, gfs2_put_super() may have already freed sdp via free_sbd(). This can happen when gfs2_quota_cleanup() is called during unmount: it disposes of quota objects via call_rcu() and then waits on sd_kill_wait with a 60-second timeout. If the timeout expires, or if gfs2_gl_hash_clear() triggers additional qd_put() calls that schedule more RCU callbacks after the wait completes, gfs2_put_super() will proceed to free the superblock while RCU callbacks referencing it are still pending. Add an rcu_barrier() before free_sbd() in gfs2_put_super() to ensure all pending RCU callbacks (including gfs2_qd_dealloc) have completed before the superblock is freed. Fixes: a475c5dd16e5 ("gfs2: Free quota data objects synchronously") Reported-by: syzbot+42a37bf8045847d8f9d2@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=42a37bf8045847d8f9d2 Tested-by: syzbot+42a37bf8045847d8f9d2@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Signed-off-by: Andreas Gruenbacher Signed-off-by: Greg Kroah-Hartman commit 8d8507a457667f23477a15496b91908a5b5b7cf3 Author: Sam James Date: Mon May 25 08:56:19 2026 +0100 crypto: nx - fix nx_crypto_ctx_exit argument commit 4e67f504ee9ded15e256b64f4fde150e917381d7 upstream. nx_crypto_ctx_shash_exit calls nx_crypto_ctx_exit with crypto_shash_ctx(...) but crypto_shash_ctx gives a nx_crypto_ctx *, not a crypto_tfm *. Fix the type in nx_crypto_ctx_exit and drop the bogus crypto_tfm_ctx call. This fixes the following oops: BUG: Unable to handle kernel data access at 0xc0403effffffffc8 Faulting instruction address: 0xc000000000396cb4 Oops: Kernel access of bad area, sig: 11 [#15] Call Trace: nx_crypto_ctx_shash_exit+0x24/0x60 crypto_shash_exit_tfm+0x28/0x40 crypto_destroy_tfm+0x98/0x140 crypto_exit_ahash_using_shash+0x20/0x40 crypto_destroy_tfm+0x98/0x140 hash_release+0x1c/0x30 alg_sock_destruct+0x38/0x60 __sk_destruct+0x48/0x2b0 af_alg_release+0x58/0xb0 __sock_release+0x68/0x150 sock_close+0x20/0x40 __fput+0x110/0x3a0 sys_close+0x48/0xa0 system_call_exception+0x140/0x2d0 system_call_common+0xf4/0x258 .. which came from hardlink(1) opportunistically using AF_ALG. The same problem exists with nx_crypto_ctx_skcipher_exit getting a context it wasn't expecting, but apparently nobody hit that for years. Cc: Eric Biggers Cc: stable@vger.kernel.org Fixes: bfd9efddf990 ("crypto: nx - convert AES-ECB to skcipher API") Fixes: 9420e628e7d8 ("crypto: nx - Use API partial block handling") Acked-by: Breno Leitao Reviewed-by: Eric Biggers Reported-by: Calvin Buckley Tested-by: Calvin Buckley Suggested-by: Brad Spengler Signed-off-by: Sam James Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 5da9b1a87ec7cc3489c27016313524769f12d9e0 Author: Sean Christopherson Date: Fri Jun 12 15:52:41 2026 -0700 KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned() commit f1edbed787ba67988ed34e0132ca128b052b6ce8 upstream. Drop a BUG_ON() that has been reachable since it was first added, way back in 2009, and instead use get_unaligned() to perform potentially-unaligned accesses. For a given store, KVM x86's emulator tracks the entire value in the destination operand, x86_emulate_ctxt.dst. If the destination is memory, and the target splits multiple pages and/or is emulated MMIO, then KVM handles each fragment independently. E.g. on a page split starting at page offset 0xffc, KVM writes 4 bytes to the first page, then the remaining bytes to the second page, using ctxt->dst as the source for both (with appropriate offsets). If the destination splits a page *and* hits emulated MMIO on the second page, then KVM will complete the write to the first page, then emulate the MMIO access to the second page. If there is a datamatch-enabled ioeventfd at offset 0 of the second page, then KVM will process the remainder of the store as a potential ioeventfd signal. Putting it all together, if the guest emits a store that splits a page starting at page offset N, and the second page has a datamatch-enabled ioeventfd at offset 0, then KVM will check for datamatch using &dst.valptr[N] as the source. Due to dst (and thus dst.valptr) being 32-byte aligned, if N is not aligned to @len, the BUG_ON() fires. E.g. with a 16-byte store at page offset 0xffc, to an ioeventfd of len 8, all initial checks in ioeventfd_in_range() will succeed, and the BUG_ON() fires due to @val being 4-byte aligned, but not 8-byte aligned. ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783! Oops: invalid opcode: 0000 [#1] SMP CPU: 0 UID: 1000 PID: 615 Comm: repro Not tainted 7.1.0-rc2-ff238429d1ea #365 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:ioeventfd_write+0x6c/0x70 [kvm] Call Trace: __kvm_io_bus_write+0x85/0xb0 [kvm] kvm_io_bus_write+0x53/0x80 [kvm] vcpu_mmio_write+0x66/0xf0 [kvm] emulator_read_write_onepage+0x12a/0x540 [kvm] emulator_read_write+0x109/0x2b0 [kvm] x86_emulate_insn+0x4f8/0xfb0 [kvm] x86_emulate_instruction+0x181/0x790 [kvm] kvm_mmu_page_fault+0x313/0x630 [kvm] vmx_handle_exit+0x18a/0x590 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm] kvm_vcpu_ioctl+0x2d5/0x970 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0x890 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f19c931a9bf Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- In a perfect world, the fix would be to simply delete the BUG_ON(), as KVM x86 doesn't perform alignment checks on "normal" memory accesses at CPL0. Sadly, C99 ruins all the fun; while the x86 architecture plays nice, dereferencing an unaligned pointer directly is undefined behavior in C, e.g. triggers splats when running with CONFIG_UBSAN_ALIGNMENT=y. Fixes: d34e6b175e61 ("KVM: add ioeventfd support") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-ID: <20260612225241.678509-1-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 18587f9831612e24cd8f24be1ec15478feff7abc Author: Sean Christopherson Date: Wed Apr 29 09:34:01 2026 -0700 KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level commit ef057cbf825e03b63f6edf5980f96abf3c53089d upstream. When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, *before* querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends "below" the bounds of a memslot. When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a "direct" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage. But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds. BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm] Call Trace: kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm] kvm_set_memslot+0x1ee/0x590 [kvm] kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm] kvm_vm_ioctl+0x9bf/0x15d0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvm_mmu_max_mapping_level() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization. Fixes: 9eba50f8d7fc ("KVM: x86/mmu: Consult max mapping level when zapping collapsible SPTEs") Cc: stable@vger.kernel.org Cc: David Matlack Cc: James Houghton Cc: Alexander Bulekov Cc: Fred Griffoul Cc: Alexander Graf Cc: David Woodhouse Cc: Filippo Sironi Cc: Ivan Orlov Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit adfacfbaeae2cb760f492357cc36b41f84ef7f86 Author: Michael Bommarito Date: Wed Apr 22 11:58:44 2026 -0400 exfat: fix potential use-after-free in exfat_find_dir_entry() commit 3f5f8ee9917cc2b9076ac533492d8a200edcabb8 upstream. In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): brelse(bh); if (entry_type == TYPE_EXTEND) { ... len = exfat_extract_uni_name(ep, entry_uniname); ... } After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd ("exfat: Fix potential use after free in exfat_load_upcase_table()"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim. Fixes: ca06197382bd ("exfat: add directory operations") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 6e61fc2e06e44b6d30248cc5bc47a58e75c2b43e Author: Maciej W. Rozycki Date: Wed May 6 23:42:27 2026 +0100 MIPS: DEC: Prevent initial console buffer from landing in XKPHYS commit 7fb13fd35110ebe95eb053faf79d018f51144d85 upstream. In 64-bit configurations calling the initial console output handler 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 and consequently so has been the buffer allocated there that is used as the argument corresponding to the `%s' output conversion specifier for the firmware's printf() entry point. This 64-bit address will then be truncated by 32-bit firmware, resulting in an attempt to access the wrong memory location, which in turn will cause all kinds of unpredictable behaviour, such as a kernel crash: Console: colour dummy device 160x64 Calibrating delay loop... 49.36 BogoMIPS (lpj=192512) pid_max: default: 32768 minimum: 301 CPU 0 Unable to handle kernel paging request at virtual address 000000000203bd00, epc == ffffffffbfc08364, ra == ffffffffbfc08800 Oops[#1]: CPU: 0 PID: 0 Comm: swapper Not tainted 5.18.0-rc2-00254-gfb649bda6f56-dirty #121 $ 0 : 0000000000000000 0000000000000001 0000000000000023 ffffffff80684ba0 $ 4 : 000000000203bd00 ffffffffbfc0f3b4 ffffffffffffffff 0000000000000073 $ 8 : 0a303d7469000000 0000000000000000 0000000000000073 ffffffffbfc0f473 $12 : 0000000000000002 0000000000000000 ffffffff80684c1c 0000000000000000 $16 : 0000000000000000 ffffffff80596dc9 0000000000000000 ffffffffbfc09240 $20 : ffffffff80684c40 ffffffffbfc0f400 000000000000002d 000000000000002b $24 : ffffffffffffffbf 000000000203bd00 $28 : ffffffff805f0000 ffffffff80684b58 0000000000000030 ffffffffbfc08800 Hi : 0000000000000000 Lo : 0000000000000aa8 epc : ffffffffbfc08364 0xffffffffbfc08364 ra : ffffffffbfc08800 0xffffffffbfc08800 Status: 140120e2 KX SX UX KERNEL EXL Cause : 00000008 (ExcCode 02) BadVA : 000000000203bd00 PrId : 00000430 (R4000SC) Modules linked in: Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____), tls=0000000000000000) Stack : 0000000000000000 0000000000000000 0000000000000000 0000004d0000004d 80684cc0806a2a40 80596dc80000004d 8061000000000000 bfc0850c80684c38 0000000000000000 000000000203bd00 0000000000000000 0000000000000000 0000000000000000 00000000bfc0f3b4 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000002500000000 0000000000000000 0000000000000000 802c1a7400000000 0203bd0080596dc8 0203bd4d69000000 6c61632000000018 5f746567646e6172 6c616320625f6d6f 5f736e5f6d6f7266 206361323778302b 303d74696e726320 806a0a38806b0000 806a0a38806b0000 00000000806b0000 80683c58806b0000 ... Call Trace: Code: a082ffff 03e00008 00601021 <80820000> 00001821 10400005 24840001 80820000 24630001 ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception in interrupt KN04 V2.1k (PC: 0xa0026768, SP: 0x806848e8) >> In this case the pointer in $4 was truncated from 0x980000000203bd00 to 0x000000000203bd00. 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. Fix the issue by making the buffer static and initdata, and therefore placed in the CKSEG0 32-bit compatibility segment, observing that the console output handler is called with the console lock held, implying no need for this code to be reentrant. Add an assertion to verify the buffer actually has been placed in a compatibility segment. 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 65bd0c0afb0e1bf3287458e342429b069624f7d4 Author: Dawei Feng Date: Wed Jun 3 18:53:16 2026 +0800 bpf: use kvfree() for replaced sysctl write buffer commit 4c21b5927d4364bfe7365f2700da5fea0ed0d004 upstream. proc_sys_call_handler() allocates its temporary sysctl buffer with kvzalloc() and passes it to __cgroup_bpf_run_filter_sysctl(). Since kvzalloc() may fall back to vmalloc() for large allocations, freeing that buffer with kfree() is wrong and can corrupt memory. Use kvfree() to safely handle both kmalloc and kvzalloc()/vmalloc allocations. 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-rc5. Reproduced the bug based on v7.1-rc4 in a QEMU x86_64 guest booted with KASAN and CONFIG_FAILSLAB enabled. To exercise the replacement path, the test tree also included the accompanying fix for the stale ret == 1 check in __cgroup_bpf_run_filter_sysctl(). The reproducer confines failslab injections to the proc_sys_call_handler() range, uses stacktrace-depth=32, and injects fail-nth=1 while writing 8191 bytes to /proc/sys/kernel/domainname from a task in the target cgroup. Under that setup, fail-nth=1 triggered the fault: BUG: unable to handle page fault for address: ffffeb0200024d48 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 SMP KASAN NOPTI CPU: 2 UID: 0 PID: 209 Comm: repro_proc_sys_ Not tainted 7.1.0-rc4-00686-g97625979a5d4 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:kfree+0x6e/0x510 ... Call Trace: ? __cgroup_bpf_run_filter_sysctl+0x626/0xc30 __cgroup_bpf_run_filter_sysctl+0x74d/0xc30 ? __pfx___cgroup_bpf_run_filter_sysctl+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? __kvmalloc_node_noprof+0x345/0x870 ? proc_sys_call_handler+0x250/0x480 ? srso_return_thunk+0x5/0x5f proc_sys_call_handler+0x3a2/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? selinux_file_permission+0x39f/0x500 ? srso_return_thunk+0x5/0x5f ? lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ... With this fix applied on top of the same test setup, rerunning the reproducer with fail-nth=1 yields no corresponding Oops reports. Fixes: 4508943794ef ("proc: use kvzalloc for our kernel buffer") Cc: stable@vger.kernel.org Reviewed-by: Emil Tsalapatis Reviewed-by: Jiayuan Chen Acked-by: Yonghong Song Signed-off-by: Zilin Guan Signed-off-by: Dawei Feng Link: https://lore.kernel.org/r/20260603105317.944304-3-dawei.feng@seu.edu.cn Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit 3804e6de30ae7b053d53341d9d6944356cf23b40 Author: Denis Arefev Date: Thu May 21 10:28:56 2026 +0300 block: Avoid mounting the bdev pseudo-filesystem in userspace commit f73aa66dffcb8e61e78f01b56163ec16a15d06d2 upstream. The bdev pseudo-filesystem is an internal kernel filesystem with which userspace should not interfere. Unregister it so that userspace cannot even attempt to mount it. This fixes a bug [1] that occurs when attempting to access files, because the system call move_mount() uses pointers declared in the inode_operations structure, which for the bdev pseudo-filesystem are always equal to 0. `inode->i_op = &empty_iops;` [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 23380067 P4D 23380067 PUD 23381067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN NOPTI CPU: 2 PID: 17125 Comm: syz-executor.0 Not tainted 6.1.155-syzkaller-00350-g84221fde2681 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:0x0 Call Trace: lookup_open.isra.0+0x700/0x1180 fs/namei.c:3460 open_last_lookups fs/namei.c:3550 [inline] path_openat+0x953/0x2700 fs/namei.c:3780 do_filp_open+0x1c5/0x410 fs/namei.c:3810 do_sys_openat2+0x171/0x4d0 fs/open.c:1318 do_sys_open fs/open.c:1334 [inline] __do_sys_openat fs/open.c:1350 [inline] __se_sys_openat fs/open.c:1345 [inline] __x64_sys_openat+0x13c/0x1f0 fs/open.c:1345 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Link: https://lore.kernel.org/all/20131010004732.GJ13318@ZenIV.linux.org.uk/T/# Cc: stable@vger.kernel.org Signed-off-by: Denis Arefev Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260521072857.5078-1-arefev@swemel.ru Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit db2c5b9fb908715cab9976ee5966c8493ead34bd Author: Wenjie Qi Date: Wed May 27 20:06:28 2026 +0800 f2fs: keep atomic write retry from zeroing original data commit 6d874b65aadce56ac78f76129dbcfc2599b638f8 upstream. A partial atomic write reserves a block in the COW inode before reading the original data page for the untouched bytes in that page. If that read fails, write_begin returns an error but leaves the COW inode entry as NEW_ADDR. A retry of the same partial write then finds the COW entry, treats it as existing COW data, and f2fs_write_begin() zeroes the whole folio because blkaddr is NEW_ADDR. If the retry is committed, the bytes outside the retried write range are committed as zeroes instead of preserving the original file contents. Only use the COW inode as the read source when it already has a real data block. If the COW entry is still NEW_ADDR, treat it as a reservation to reuse: keep reading the old data from the original inode and avoid reserving or accounting the same atomic block again. Cc: stable@kernel.org Fixes: 3db1de0e582c ("f2fs: change the current atomic write way") Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 20190e498057997532c7f186d081011f18e0a462 Author: Yongpeng Yang Date: Mon Apr 27 21:10:51 2026 +0800 f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node() commit 1f70ddb28a3c71df124da5fa4040c808116d6bb9 upstream. When __destroy_extent_node() sets the inode flag FI_NO_EXTENT, it does not reset the length of the largest extent to 0 and update the inode folio. Since modifications to the extent tree are disallowed afterward, the cached largest extent may become stale. This can trigger the following error in xfstests generic/388: F2FS-fs (dm-0): sanity_check_extent_cache: inode (ino=1761) extent info [220057, 57, 6] is incorrect, run fsck to fix In the f2fs_drop_inode path, __destroy_extent_node() does not need to guarantee that et->node_cnt is 0, because concurrency with writeback is expected in this path, and writeback may update the extent cache. This patch reverts commit ed78aeebef05 ("f2fs: fix node_cnt race between extent node destroy and writeback"), and remove the unnecessary zero check of et->node_cnt. Fixes: ed78aeebef05 ("f2fs: fix node_cnt race between extent node destroy and writeback") Cc: stable@vger.kernel.org Reported-by: Chao Yu Suggested-by: Chao Yu Signed-off-by: Yongpeng Yang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit ff83de56882cb8466184d322abece2589258ca56 Author: Zhang Cen Date: Mon Jun 15 15:19:54 2026 +0800 f2fs: validate ACL entry sizes in f2fs_acl_from_disk() commit c4810ada31e80cbe4011467c4f3b1e93f94134f3 upstream. f2fs_acl_count() only validates the aggregate ACL xattr length. A malformed ACL can still place ACL_USER or ACL_GROUP in a slot that only contains struct f2fs_acl_entry_short bytes, and f2fs_acl_from_disk() then reads entry->e_id before verifying that a full entry fits. Require a short entry before reading e_tag and e_perm, and require a full entry before reading e_id for ACL_USER and ACL_GROUP. Return -EFSCORRUPTED from these new truncated-entry checks, while keeping the pre-existing -EINVAL paths unchanged. Validation reproduced this kernel report: KASAN slab-out-of-bounds in __f2fs_get_acl+0x6fb/0x7e0 RIP: 0033:0x7f4b835ea7aa The buggy address belongs to the object at ffff888114589960 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888114589960, ffff888114589968) Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) __f2fs_get_acl+0x6fb/0x7e0 (fs/f2fs/acl.c:169) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x224/0x430 (?:?) kasan_report+0xe0/0x110 (?:?) __f2fs_get_acl+0x5/0x7e0 (fs/f2fs/acl.c:169) __get_acl+0x281/0x380 (?:?) vfs_get_acl+0x10b/0x190 (?:?) do_get_acl+0x2a/0x410 (?:?) do_get_acl+0x9/0x410 (?:?) do_getxattr+0xe8/0x260 (?:?) filename_getxattr+0xd1/0x140 (?:?) do_getname+0x2d/0x2d0 (?:?) path_getxattrat+0x16c/0x200 (?:?) lock_release+0xc8/0x290 (?:?) cgroup_update_frozen+0x9d/0x320 (?:?) lockdep_hardirqs_on_prepare+0xea/0x1a0 (?:?) trace_hardirqs_on+0x1a/0x170 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?) Cc: stable@kernel.org Fixes: af48b85b8cd3 ("f2fs: add xattr and acl functionalities") Assisted-by: Codex:gpt-5.5 Signed-off-by: Zhang Cen Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 888d94cc9afbf1b81b76be1c783c3d9f8f338904 Author: Sunmin Jeong Date: Mon Jun 22 14:28:17 2026 +0900 f2fs: fix to round down start offset of fallocate for pin file commit 4275b59673eb60b02eec3997816c83f1f4b909c4 upstream. Currently, the length of fallocate for pin file is section-aligned to keep allocated sections from being selected as victims of GC. However, for the case that the start offset of fallocate is not aligned in section, the allocated sections can't be fully utilized. It's because a new section is allocated by f2fs_allocate_pinning_section() after using blks_per_sec blocks regardless of the start offset. As a result, several unexpected dirty segments may be created, including blocks assigned to the pinned file. To address this issue, let's round down the start offset of fallocate to the length of section. The reproducing scenario is as below chunk=$(((2<<20)+4096)) # 2MB + 4KB touch test f2fs_io pinfile set test f2fs_io fallocate 0 0 $chunk test f2fs_io fallocate 0 $chunk $chunk test f2fs_io fallocate 0 $((chunk*2)) $chunk test f2fs_io fiemap 0 $((chunk*3)) test Fiemap: offset = 0 len = 12288 logical addr. physical addr. length flags 0 0000000000000000 000000068c600000 0000000000400000 00001088 1 0000000000400000 000000003d400000 0000000000001000 00001088 2 0000000000401000 00000003eb200000 0000000000200000 00001088 3 0000000000601000 00000005e4200000 0000000000001000 00001088 4 0000000000602000 0000000605400000 0000000000200000 00001089 Cc: stable@vger.kernel.org Fixes: f5a53edcf01e ("f2fs: support aligned pinned file") Reviewed-by: Yunji Kang Reviewed-by: Yeongjin Gil Reviewed-by: Sungjong Seo Signed-off-by: Sunmin Jeong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 77f216ff9ce5cde8eed9f6d12707e906dffdc9f7 Author: Wenjie Qi Date: Thu May 21 11:16:18 2026 +0800 f2fs: validate compress cache inode only when enabled commit 5073c66a96a9c23c0c2533ed4ed06e42f9021208 upstream. F2FS_COMPRESS_INO() uses NM_I(sbi)->max_nid as the synthetic inode number for the compressed page cache inode. That inode only exists when the compress_cache mount option is enabled. When compress_cache is disabled, max_nid is outside the valid inode range. A corrupted directory entry that points to ino == max_nid should therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino() currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally, so f2fs_iget() bypasses do_read_inode() and its nid range check, and instantiates a fake internal inode instead. Gate the compressed cache inode case on COMPRESS_CACHE, matching f2fs_init_compress_inode(). With compress_cache disabled, ino == max_nid now follows the normal inode path and is rejected as an out-of-range nid. Cc: stable@kernel.org Fixes: 6ce19aff0b8c ("f2fs: compress: add compress_inode to cache compressed blocks") Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 8aad54746c251f2c2370118df766c0c82e2d2091 Author: Wenjie Qi Date: Tue May 26 13:35:57 2026 +0800 f2fs: validate orphan inode entry count commit 846c499a65816d13f1186e3090e825e8bb8bcb8b upstream. f2fs_recover_orphan_inodes() trusts the orphan block entry_count when replaying orphan inodes from the checkpoint pack. A corrupted entry_count larger than F2FS_ORPHANS_PER_BLOCK makes the recovery loop read past the ino[] array and interpret footer or following data as inode numbers. On a crafted image, mounting an unpatched kernel can drive orphan recovery into f2fs_bug_on() and panic the kernel. Validate entry_count before consuming entries so corrupted checkpoint data fails the mount with -EFSCORRUPTED and requests fsck instead. Set ERROR_INCONSISTENT_ORPHAN as well, so the corruption reason can be recorded in the superblock s_errors[] field. This gives fsck a persistent hint even though mount-time orphan recovery failure may leave no chance to persist SBI_NEED_FSCK through a checkpoint. Cc: stable@kernel.org Fixes: 127e670abfa7 ("f2fs: add checkpoint operations") Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 1e48fefac682c5ee133add84d1f06d458fedf635 Author: Wenjie Qi Date: Wed May 20 20:07:05 2026 +0800 f2fs: pass correct iostat type for single node writes commit fcb05c26c2a67953b420739b85f49386efc9b6c0 upstream. f2fs_write_single_node_folio() takes an io_type argument, but still passes FS_GC_NODE_IO to __write_node_folio() unconditionally. This was harmless while the helper was only used by f2fs_move_node_folio(), whose caller passes FS_GC_NODE_IO. However, commit fe9b8b30b971 ("f2fs: fix inline data not being written to disk in writeback path") made f2fs_inline_data_fiemap() call the helper with FS_NODE_IO for FIEMAP_FLAG_SYNC. Honor the caller supplied io_type so inline-data FIEMAP sync writeback is accounted as normal node IO instead of GC node IO, while the GC path continues to pass FS_GC_NODE_IO explicitly. Cc: stable@kernel.org Fixes: fe9b8b30b971 ("f2fs: fix inline data not being written to disk in writeback path") Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 1de92789ce31e46fa7e7d8e89c90b19cdb1c103b Author: Junrui Luo Date: Thu Apr 2 14:48:07 2026 +0800 wifi: iwlwifi: mld: validate sta_mask before ffs() in BA session handlers commit f056fc2b927448d37eca6b6cacc3d1b0f67b20d2 upstream. Three BA session handlers use ffs(ba_data->sta_mask) - 1 to derive a station ID without checking that sta_mask is non-zero. When sta_mask is zero, ffs() returns 0 and the subtraction wraps to 0xFFFFFFFF, causing an out-of-bounds access on fw_id_to_link_sta[]. Add WARN_ON_ONCE(!ba_data->sta_mask) guards before each ffs() call, consistent with the existing check in iwl_mld_ampdu_rx_start(). Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Link: https://patch.msgid.link/SYBPR01MB788115C6CE873271A9A15A25AF51A@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Miri Korenblit Signed-off-by: Greg Kroah-Hartman commit b0b07e04f0c7219bd1a3eb15e22bdf9109f0d393 Author: Junjie Cao Date: Thu Feb 12 20:50:35 2026 +0800 wifi: iwlwifi: mld: fix race condition in PTP removal commit e1fc08598aa34b28359831e768076f56632720c1 upstream. iwl_mld_ptp_remove() calls cancel_delayed_work_sync() only after ptp_clock_unregister() and clearing ptp_data state (ptp_clock, last_gp2, wrap_counter). This creates a race where the delayed work iwl_mld_ptp_work() can execute between ptp_clock_unregister() and cancel_delayed_work_sync(), observing partially cleared PTP state. Move cancel_delayed_work_sync() before ptp_clock_unregister() to ensure the delayed work is fully stopped before any PTP cleanup begins. Cc: stable@vger.kernel.org Reviewed-by: Simon Horman Reviewed-by: Vadim Fedorenko Signed-off-by: Junjie Cao Link: https://patch.msgid.link/20260212125035.1345718-2-junjie.cao@intel.com Signed-off-by: Miri Korenblit Signed-off-by: Greg Kroah-Hartman commit df626f284cb90b2566bd296d04e134a55c8d3012 Author: Junjie Cao Date: Thu Feb 12 20:50:34 2026 +0800 wifi: iwlwifi: mvm: fix race condition in PTP removal commit 65150c9cc3e06ab54bc4e8134a47f6f5d095a4e3 upstream. iwl_mvm_ptp_remove() calls cancel_delayed_work_sync() only after ptp_clock_unregister() and clearing ptp_data state (ptp_clock, ptp_clock_info, last_gp2). This creates a race where the delayed work iwl_mvm_ptp_work() can execute between ptp_clock_unregister() and cancel_delayed_work_sync(), observing partially cleared PTP state. Move cancel_delayed_work_sync() before ptp_clock_unregister() to ensure the delayed work is fully stopped before any PTP cleanup begins. Cc: stable@vger.kernel.org Reviewed-by: Simon Horman Reviewed-by: Vadim Fedorenko Signed-off-by: Junjie Cao Link: https://patch.msgid.link/20260212125035.1345718-1-junjie.cao@intel.com Signed-off-by: Miri Korenblit Signed-off-by: Greg Kroah-Hartman commit 200d58c851b8f63f77a05570072dd20f79bc3681 Author: Luka Gejak Date: Mon May 18 16:23:11 2026 +0200 wifi: rtw88: usb: fix memory leaks on USB write failures commit 6b964941bbfe6e0f18b1a5e008486dbb62df440a upstream. When rtw_usb_write_port() fails to submit a USB Request Block (URB) (e.g., due to device disconnect or ENOMEM), the completion callback is never executed. Currently, the driver ignores the return value of rtw_usb_write_port() in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these functions rely on the completion callback to free the socket buffers (skbs) and the transaction control block (txcb), a submission failure results in: 1. A memory leak of the allocated skb in rtw_usb_write_data(). 2. A memory leak of the txcb structure and all aggregated skbs in rtw_usb_tx_agg_skb(). Fix this by checking the return value of rtw_usb_write_port(). If it fails, explicitly free the skb in rtw_usb_write_data(), and properly purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb(). The issue was discovered in practice during device disconnect/reconnect scenarios and memory pressure conditions. Tested by verifying normal TX operation continues after the fix without regressions. Fixes: a82dfd33d123 ("wifi: rtw88: Add common USB chip support") Cc: stable@vger.kernel.org Acked-by: Ping-Ke Shih Tested-by: Luka Gejak Signed-off-by: Luka Gejak Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260518142311.10328-2-luka.gejak@linux.dev Signed-off-by: Greg Kroah-Hartman commit 73d427d271f7af6a738feab3368460331821ab6d Author: Luka Gejak Date: Mon May 18 16:23:10 2026 +0200 wifi: rtw88: increase TX report timeout to fix race condition commit c80788f7c5aed8d420366b821f867a8a353d83a5 upstream. The driver expects the firmware to report TX status within 500ms. However, a timeout can be triggered when the hardware performs background scans while under TX load. During these scans, the firmware stays off-channel for periods exceeding 500ms, delaying the delivery of TX reports back to the driver. When this occurs, the purge timer fires prematurely and drops the tracking skbs from the queue. This results in the host stack interpreting the missing status as packet loss, leading to TCP window collapse. In testing with iperf3, this causes throughput to drop from ~90 Mbps to near-zero for approximately 2 seconds until the connection recovers. Increase RTW_TX_PROBE_TIMEOUT to 2500ms for RTL8723DU. This duration is sufficient to accommodate off-channel dwell time during full background scans, ensuring the purge timer only trips during genuine firmware lockups and preventing unnecessary TCP retransmission cycles. Fixes: a82dfd33d123 ("wifi: rtw88: Add common USB chip support") Cc: stable@vger.kernel.org Acked-by: Ping-Ke Shih Tested-by: Luka Gejak Signed-off-by: Luka Gejak Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260518142311.10328-1-luka.gejak@linux.dev Signed-off-by: Greg Kroah-Hartman commit 0aeb4d3ff6ced464b342bca5c772e7502f3cad32 Author: Bitterblue Smith Date: Sat Apr 25 22:32:58 2026 +0300 wifi: rtlwifi: rtl8821ae: Fix C2H bit location in RX descriptor commit 83d38df6929118c3f996b9e3351c2d5014073d87 upstream. Bit 28 of double word 2 in the RX descriptor indicates if the packet is a normal 802.11 frame, or a message from the wifi firmware to the driver (Card 2 Host). Commit f5678bfe1cdc ("rtlwifi: rtl8821ae: Replace local bit manipulation macros") mistakenly made the driver look for this bit in double word 1, causing packet loss and Bluetooth coexistence problems. Fixes: f5678bfe1cdc ("rtlwifi: rtl8821ae: Replace local bit manipulation macros") Cc: Signed-off-by: Bitterblue Smith Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/04da7398-cedb-425a-a810-5772ab10139d@gmail.com Signed-off-by: Greg Kroah-Hartman commit 40aa3c2b0cb8e34e0576fc94cc70e4e33db03c0a Author: Jose Ignacio Tornos Martinez Date: Mon Apr 20 13:01:29 2026 +0200 wifi: ath11k: fix warning when unbinding commit 8b7a26b6681922a38cd5a7829ace61f8e54df9b7 upstream. If there is an error during some initialization related to firmware, the buffers dp->tx_ring[i].tx_status are released. However this is released again when the device is unbinded (ath11k_pci), and we get: WARNING: CPU: 0 PID: 6231 at mm/slub.c:4368 free_large_kmalloc+0x57/0x90 Call Trace: free_large_kmalloc ath11k_dp_free ath11k_core_deinit ath11k_pci_remove ... The issue is always reproducible from a VM because the MSI addressing initialization is failing. In order to fix the issue, just set the buffers to NULL after releasing in order to avoid the double free. Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Cc: stable@vger.kernel.org Signed-off-by: Jose Ignacio Tornos Martinez Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260420110130.509670-1-jtornosm@redhat.com Signed-off-by: Jeff Johnson Signed-off-by: Greg Kroah-Hartman commit a7cdc384c9c57506df62e7ff04058eff61bd1d0f Author: ElXreno Date: Wed May 6 04:39:16 2026 +0300 wifi: mt76: mt7925: don't disable AP BSS when removing TDLS peer commit 37d65384aa6f9cbe45f4052b13b378af1aab3e95 upstream. On a STATION vif, removing a TDLS peer takes the mt7925_mac_sta_remove -> mt7925_mac_sta_remove_links path. The first loop in that function calls mt7925_mcu_add_bss_info(..., enable=false) for every link of the station being removed. For a non-MLO STATION vif there is exactly one link, link 0, whose bss_conf is the AP's. TDLS peers do not have their own bss_conf - they share the AP's BSS. The result is that every TDLS peer teardown sends a BSS_INFO_UPDATE with enable=0 for the AP's BSS to the firmware, which wipes the AP-side rate-control context. The connection stays associated and TX from the host still works at the negotiated rate, but the AP's downlink to us collapses to the lowest mandatory OFDM rate (HE-MCS 0 / 6 Mbit/s OFDM) and only slowly recovers as rate adaptation re-learns under sustained traffic. With brief or bursty traffic the link can stay at 6-72 Mbit/s indefinitely, requiring a manual reconnect. mt7925_mac_link_sta_remove() already guards its own mt7925_mcu_add_bss_info(..., false) call with "vif->type == NL80211_IFTYPE_STATION && !link_sta->sta->tdls". Add the equivalent guard at the top of the cleanup loop in mt7925_mac_sta_remove_links(), above the link_sta / link_conf / mlink / mconf lookups, so TDLS peer teardown skips the loop body entirely without doing the per-link work that would just be thrown away. Verified on mt7925e by triggering Samsung-S938B auto-TDLS via iperf3 and watching iw rx bitrate after teardown: Before: rx bitrate collapses to 6.0-72.0 Mbit/s, oscillates 17/72/ 137/288/432 Mbit/s for 30+ seconds, no full recovery without a manual reassoc. After: rx bitrate stays at 1200.9 Mbit/s HE-MCS 11 NSS 2 80 MHz across the entire TDLS lifecycle. bpftrace confirms a single mt7925_mcu_add_bss_info(enable=0) call per teardown before the fix; zero such calls after. Fixes: 3878b4333602 ("wifi: mt76: mt7925: update mt7925_mac_link_sta_[add, assoc, remove] for MLO") Cc: stable@vger.kernel.org Signed-off-by: ElXreno Assisted-by: Claude:claude-opus-4-7 bpftrace Link: https://patch.msgid.link/20260506-mt7925-tdls-fixes-v2-2-46aa826ba8bb@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 7e25b5e22c1f43f0d47ff487360e6aebd55d033a Author: Zenm Chen Date: Tue Apr 7 23:44:30 2026 +0800 wifi: mt76: mt76x2u: Add support for ELECOM WDC-867SU3S commit f4ce0664e9f0387873b181777891741c33e19465 upstream. Add the ID 056e:400a to the table to support an additional MT7612U adapter: ELECOM WDC-867SU3S. Compile tested only. Cc: stable@vger.kernel.org # 5.10.x Signed-off-by: Zenm Chen Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260407154430.9184-1-zenmchen@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit ec1c9e8962555b1766d059dc02760645c2ff62ff Author: Mike Rapoport (Microsoft) Date: Wed May 13 11:14:16 2026 +0300 userfaultfd: ensure mremap_userfaultfd_fail() releases mmap_changing commit 0496a59745b0723ea74274db16fd5c8b1379b9a9 upstream. Sashiko says: mremap_userfaultfd_prep() increments ctx->mmap_changing to stall concurrent operations, but mremap_userfaultfd_fail() does not decrement it before dropping the context reference. If an mremap operation fails, ctx->mmap_changing remains elevated. This will causes subsequent userfaultfd operations like a UFFDIO_COPY to fail with -EAGAIN. Decrement ctx->mmap_changing in mremap_userfaultfd_fail(). Link: https://sashiko.dev/#/patchset/20260430113512.115938-1-rppt@kernel.org Link: https://lore.kernel.org/20260513081416.495963-1-rppt@kernel.org Fixes: df2cc96e7701 ("userfaultfd: prevent non-cooperative events vs mcopy_atomic races") Signed-off-by: Mike Rapoport (Microsoft) Reviewed-by: David Hildenbrand (Arm) Cc: Al Viro Cc: Christian Brauner Cc: Jan Kara Cc: Peter Xu Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 7216ce8cb12fee44e309503955bb83806b106129 Author: Shaomin Chen Date: Wed Jun 10 13:10:05 2026 +0300 keys: Pin request_key_auth payload in instantiate paths commit fd15b457a86939c38aa12116adabd8ff686c5e51 upstream. A: request_key() B: KEYCTL_INSTANTIATE_IOV ================ ========================= create auth key store rka in auth key wait for helper get auth key load rka from auth key copy user payload sleep on #PF helper completed detach and free rka destroy auth key wake up use rka->target_key **USE-AFTER-FREE** Give request_key_auth payloads a refcount. Take a payload reference while authkey->sem stabilizes the payload and revocation state. Hold that reference across the instantiate and reject paths. Drop the auth key owning reference from revoke and destroy. [jarkko: Replaced the first two paragraphs of text with an actual concurrency scenario.] Cc: stable@vger.kernel.org # v5.10+ Fixes: b5f545c880a2 ("[PATCH] keys: Permit running process to instantiate keys") Reported-by: Shaomin Chen Closes: https://lore.kernel.org/r/20260519144403.436694-1-eeesssooo020@gmail.com Signed-off-by: Shaomin Chen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit b11c1fa32667692a2c0566e10163758e786e430c Author: Jarkko Sakkinen Date: Mon Jun 1 23:11:54 2026 +0300 KEYS: fix overflow in keyctl_pkey_params_get_2() commit cb481e59ea6cae3b7796ac1d7a22b6b24c3f3c0b upstream. The length for the internal output buffer is calculated incorrectly, which can result overflow when a too small buffer is provided. Fix the bug by allocating internal output with the size of the maximum length of the cryptographic primitive instead of caller provided size. Link: https://lore.kernel.org/keyrings/20260531024914.3712130-1-jarkko@kernel.org/ Cc: stable@vger.kernel.org # v4.20+ Fixes: 00d60fd3b932 ("KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver #2]") Reported-by: Alessandro Groppo Tested-by: Alessandro Groppo Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 49d893b9cbcfc5802a32e53a64c6c6956670d65b Author: Konstantin Khorenko Date: Mon May 11 12:50:52 2026 +0200 gcov: use atomic counter updates to fix concurrent access crashes commit 56cb9b7d96b28a1173a510ab25354b6599ad3a33 upstream. GCC's GCOV instrumentation can merge global branch counters with loop induction variables as an optimization. In inflate_fast(), the inner copy loops get transformed so that the GCOV counter value is loaded multiple times to compute the loop base address, start index, and end bound. Since GCOV counters are global (not per-CPU), concurrent execution on different CPUs causes the counter to change between loads, producing inconsistent values and out-of-bounds memory writes. The crash manifests during IPComp (IP Payload Compression) processing when inflate_fast() runs concurrently on multiple CPUs: BUG: unable to handle page fault for address: ffffd0a3c0902ffa RIP: inflate_fast+1431 Call Trace: zlib_inflate __deflate_decompress crypto_comp_decompress ipcomp_decompress [xfrm_ipcomp] ipcomp_input [xfrm_ipcomp] xfrm_input At the crash point, the compiler generated three loads from the same global GCOV counter (__gcov0.inflate_fast+216) to compute base, start, and end for an indexed loop. Another CPU modified the counter between loads, making the values inconsistent - the write went 3.4 MB past a 65 KB buffer. Add -fprofile-update=prefer-atomic to CFLAGS_GCOV at the global level in the top-level Makefile, guarded by a try-run compile test. The test compiles a minimal program with and without -fprofile-update=prefer-atomic using the full KBUILD_CFLAGS, then compares undefined symbols in the resulting object files. If prefer-atomic introduces new undefined references (such as __atomic_fetch_add_8 on i386 or __aarch64_ldadd8_relax on arm64 with outline-atomics), the flag is not added -- the kernel does not link against libatomic. On architectures where GCC inlines 64-bit atomic counter updates (x86_64, s390, ...) the test passes and the flag is enabled, preventing the compiler from merging counters with loop induction variables and fixing the observed concurrent-access crash. On architectures where the flag would introduce libatomic dependencies, it is silently omitted and behaviour is no worse than before this patch. Move the CFLAGS_GCOV block from its original position (before the arch Makefile include) to after the core KBUILD_CFLAGS assignments but before the scripts/Makefile.gcc-plugins include. This placement ensures the try-run test sees arch-specific flags (-m32, -march=, -mno-outline-atomics) while avoiding GCC plugin flags (-fplugin=) that would break the test on clean builds when plugin shared objects do not yet exist. Link: https://lore.kernel.org/20260511105052.417187-2-khorenko@virtuozzo.com Signed-off-by: Konstantin Khorenko Tested-by: Arnd Bergmann Tested-by: Peter Oberparleiter Reviewed-by: Peter Oberparleiter Cc: Masahiro Yamada Cc: Miguel Ojeda Cc: Mikhail Zaslonko Cc: Nathan Chancellor Cc: Pavel Tikhomirov Cc: Thomas Weißschuh Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 2b7ec72786094a4f4abd9bade1170021f026c5ff Author: Arnd Bergmann Date: Tue May 26 12:18:41 2026 +0200 err.h: use __always_inline on all error pointer helpers commit 94bfc7f3b0c7c33331ba4ff6cc64ff309dfcbce8 upstream. While testing randconfig builds on s390, I came across a link failure with CONFIG_DMA_SHARED_BUFFER disabled: ERROR: modpost: "dma_buf_put" [drivers/iommu/iommufd/iommufd.ko] undefined! The problem here is that IS_ERR() is not inlined and dead code elimination fails as a consequence. The err.h helpers all turn into a trivial assignment of a bit mask and should never result in a function call, so force them to always be inline. This should generally result in better object code aside from avoiding the link failure above. Link: https://lore.kernel.org/20260526101851.2495110-1-arnd@kernel.org Signed-off-by: Arnd Bergmann Reviewed-by: Alexander Lobakin Reviewed-by: Nathan Chancellor Tested-by: Tamir Duberstein Cc: Alexander Gordeev Cc: Andriy Shevchenko Cc: Ansuel Smith Cc: Bjorn Andersson Cc: Heiko Carstens Cc: Vasily Gorbik Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 1fcca1260c6e74e2279661511cdaa0aa232e4f7e Author: Ard Biesheuvel Date: Thu Jun 4 17:11:56 2026 +0200 KVM: arm64: Omit tag sync on stage-2 mappings of the zero page commit 2986a625740599fe6e7635b0586fed2a95bcd1f7 upstream. Commit f620d66af316 ("arm64: mte: Do not flag the zero page as PG_mte_tagged") removed the PG_mte_tagged flag from the zero page, but missed a KVM code path that may set this flag on the zero page when it is used in a stage-2 CoW mapping of anonymous memory. So disregard the zero page explicitly in sanitise_mte_tags(). Fixes: f620d66af316 ("arm64: mte: Do not flag the zero page as PG_mte_tagged") Cc: stable@vger.kernel.org # 5.10.x Suggested-by: Catalin Marinas Signed-off-by: Ard Biesheuvel Reviewed-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 97e1044e79c5d6bdbc435e33980f52e6e1f5d65f Author: Usama Arif Date: Tue Jun 16 07:15:18 2026 -0700 block: invalidate cached plug timestamp after task switch commit fad156c2af227f42ca796cbb20ddc354a6dd9932 upstream. blk_time_get_ns() caches ktime_get_ns() in current->plug->cur_ktime and marks the task with PF_BLOCK_TS. That cache is only valid while the task keeps running; if the task is switched out, wall-clock time advances and the cached value must not be reused when the task runs again. The existing invalidation covers explicit plug flushes through __blk_flush_plug(), and the schedule() / rtmutex paths through sched_update_worker(). It does not cover in-kernel preemption paths such as preempt_schedule(), preempt_schedule_notrace(), and preempt_schedule_irq(), which enter __schedule(SM_PREEMPT) directly and return without calling sched_update_worker(). As a result, a task preempted while holding a plug with PF_BLOCK_TS set can reuse a stale plug->cur_ktime after it is scheduled back in. blk-iocost then consumes that stale timestamp through ioc_now(), producing stale vnow values for throttle decisions, and through ioc_rqos_done(), inflating on-queue time and feeding false missed-QoS samples into vrate adjustment. Move the schedule-side invalidation to finish_task_switch(), which runs for the scheduled-in task after every actual context switch regardless of which schedule entry point was used. Keep __blk_flush_plug() as the explicit flush/finish-plug invalidation path, and remove only the PF_BLOCK_TS handling from sched_update_worker(). Fixes: 06b23f92af87 ("block: update cached timestamp post schedule/preemption") Cc: stable@vger.kernel.org Signed-off-by: Usama Arif Link: https://patch.msgid.link/20260616141604.328820-3-usama.arif@linux.dev Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 99e6c712cc300883b8cbf03347d5359ec1a4d6dd Author: Usama Arif Date: Tue Jun 16 07:15:17 2026 -0700 kernel/fork: clear PF_BLOCK_TS in copy_process() commit fd38b75c4b43295b10d69772a46d1c74dbd6fc81 upstream. PF_BLOCK_TS is only set in blk_time_get_ns() when current->plug is non-NULL, and blk_finish_plug() clears it via __blk_flush_plug() before NULLing the plug pointer. copy_process() breaks the invariant by inheriting PF_BLOCK_TS from the parent while resetting the child's plug to NULL. Clear PF_BLOCK_TS alongside that assignment so callers can rely on "PF_BLOCK_TS set implies current->plug != NULL" and dereference current->plug unguarded. Fixes: 06b23f92af87 ("block: update cached timestamp post schedule/preemption") Cc: stable@vger.kernel.org Signed-off-by: Usama Arif Link: https://patch.msgid.link/20260616141604.328820-2-usama.arif@linux.dev Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 0d35f9f194a858567a21017d69318a51e3a822b9 Author: Ian Bridges Date: Thu Jun 25 23:50:48 2026 -0500 fbdev: fix use-after-free in store_modes() commit 2c1c805c65fb7dc7524e20376d6987721e73a0b1 upstream. store_modes() replaces a framebuffer's modelist with modes from userspace. On success it frees the old modelist with fb_destroy_modelist(). Two fields still point into that freed list. One pointer is fb_display[i].mode, the mode a console is using. fbcon_new_modelist() moves these pointers to the new list. It only does so for consoles still mapped to the framebuffer. An unmapped console is skipped and keeps its stale pointer. Unbinding fbcon, for example, sets con2fb_map[i] to -1 but leaves fb_display[i].mode set. An FBIOPUT_VSCREENINFO ioctl with FB_ACTIVATE_INV_MODE later reaches fbcon_mode_deleted(). That function reads the stale fb_display[i].mode through fb_mode_is_equal(). The read is a use-after-free. The other pointer is fb_info->mode, the current mode. It is set through the mode sysfs attribute. store_modes() does not update fb_info->mode, so it is left pointing into the freed list. show_mode(), the attribute's read handler, dereferences the stale fb_info->mode through mode_string(). The read is a use-after-free. Clear both pointers before freeing the list. Commit a1f305893074 ("fbcon: Set fb_display[i]->mode to NULL when the mode is released") added the helper fbcon_delete_modelist(). It clears every fb_display[i].mode that points into a given list. So far it is called only from the unregister path. Call it from store_modes() too, and set fb_info->mode to NULL. Reported-by: syzbot+81c7c6b52649fd07299d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=81c7c6b52649fd07299d Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/ajjoDhAi2y4ArSlz@dev/ Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Ian Bridges Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 81371dbd23601f67f01372817fdbab42c5601e43 Author: Koichiro Den Date: Wed Mar 4 11:05:27 2026 +0900 NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG share BAR commit d876153680e3d721d385e554def919bce3d18c74 upstream. When BAR_PEER_SPAD and BAR_CONFIG share one PCI BAR, the module teardown path ends up calling pci_iounmap() on the same iomem with some offset, which is unnecessary and triggers a kernel warning like the following: Trying to vunmap() nonexistent vm area (0000000069a5ffe8) WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937 [...] Call trace: vunmap+0x58/0x68 (P) iounmap+0x34/0x48 pci_iounmap+0x2c/0x40 ntb_epf_pci_remove+0x44/0x80 [ntb_hw_epf] pci_device_remove+0x48/0xf8 device_remove+0x50/0x88 device_release_driver_internal+0x1c8/0x228 driver_detach+0x50/0xb0 bus_remove_driver+0x74/0x100 driver_unregister+0x34/0x68 pci_unregister_driver+0x34/0xa0 ntb_epf_pci_driver_exit+0x14/0xfe0 [ntb_hw_epf] [...] Fix it by unmapping only when PEER_SPAD and CONFIG use difference bars. Cc: stable@vger.kernel.org Fixes: e75d5ae8ab88 ("NTB: epf: Allow more flexibility in the memory BAR map method") Reviewed-by: Frank Li Signed-off-by: Koichiro Den Reviewed-by: Dave Jiang Signed-off-by: Jon Mason Signed-off-by: Greg Kroah-Hartman commit c3ca2631073b2cef06824fd2bfc452ff7a1023de Author: Ruslan Valiyev Date: Tue May 26 00:04:46 2026 +0200 apparmor: fix use-after-free in rawdata dedup loop commit 6f060496d03e4dc560a40f73770bd08335cb7a27 upstream. aa_replace_profiles() walks ns->rawdata_list to dedup the incoming policy blob against entries already attached to existing profiles. Per the kernel-doc on struct aa_loaddata, list membership does not hold a reference: profiles hold pcount, and when the last pcount drops, do_ploaddata_rmfs() is queued on a workqueue that takes ns->lock and removes the entry. Between dropping the last pcount and the workqueue running, an entry remains on the list with pcount == 0. aa_get_profile_loaddata() is an unconditional kref_get() on pcount, so when the dedup loop hits such an entry, refcount hardening reports refcount_t: addition on 0; use-after-free. inside aa_replace_profiles(), and the poisoned counter then trips "saturated" and "underflow" warnings on the subsequent uses of the same loaddata. Before commit a0b7091c4de4 ("apparmor: fix race on rawdata dereference") the dedup path used a get_unless_zero-style helper on a single counter, so the existing "if (tmp)" guard was meaningful. The split-refcount refactor introduced aa_get_profile_loaddata(), which has plain kref_get() semantics, and the guard quietly became a no-op. Introduce aa_get_profile_loaddata_not0(), matching the existing _not0 convention used by aa_get_profile_not0(), and use it for the rawdata_list dedup lookup so dying entries are skipped. Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu 24.04 + stress-ng 0.17.06: stress-ng --apparmor 1 --klog-check --timeout 60s Without this patch the three refcount_t warnings fire within a few seconds. With it the same 60 s run is clean. Coverage is a smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN and CONFIG_PROVE_LOCKING would be welcome from anyone with the cycles. Fixes: a0b7091c4de4 ("apparmor: fix race on rawdata dereference") Reported-by: Colin Ian King Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221513 Cc: stable@vger.kernel.org Signed-off-by: Ruslan Valiyev Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit 4a69b83045d3195d5b9a9b053ad840ddb2998b4e Author: Bryam Vargas Date: Mon Jun 22 15:57:38 2026 -0500 apparmor: mediate the implicit connect of TCP fast open sendmsg commit 4d587cd8a72155089a627130bbd4716ec0856e21 upstream. sendmsg()/sendto() with MSG_FASTOPEN is a combination of connect(2) and write(2): it opens the connection in the SYN. apparmor_socket_sendmsg() only checks AA_MAY_SEND, so a profile that grants send but denies connect lets a confined task open an outbound TCP/MPTCP connection that connect(2) would have refused, bypassing connect mediation. Mediate the implicit connect when MSG_FASTOPEN is set and a destination is supplied. Add it to apparmor_socket_sendmsg() (not the shared aa_sock_msg_perm() helper, which recvmsg also uses) and call aa_sk_perm() directly, mirroring the selinux and tomoyo fixes. sk_is_tcp() does not cover MPTCP fast open, so the SOCK_STREAM/IPPROTO_MPTCP arm is explicit. Fixes: cf60af03ca4e ("net-tcp: Fast Open client - sendmsg(MSG_FASTOPEN)") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit 1697957eb0971d420dde42862b88eb43506a1105 Author: Maoyi Xie Date: Fri Jun 12 16:59:35 2026 +0800 net: ip_gre: require CAP_NET_ADMIN in the device netns for changelink commit 8165f7ff57d9667d2bb477ef6af83ede7fed4ad7 upstream. A tunnel 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. Add rtnl_dev_link_net_capable() next to rtnl_get_net_ns_capable() in net/core/rtnetlink.c. It requires CAP_NET_ADMIN in the link netns and is skipped when the link netns is dev_net(dev), where the rtnl path already checked it. The other patches in this series use the same helper. Gate ipgre_changelink() and erspan_changelink() with it, at the top of the op before any attribute is parsed, because the parsers update live tunnel fields first. ipgre_netlink_parms() sets t->collect_md before ip_tunnel_changelink() runs. Commit 8b484efd5cb4 ("ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().") added the same check on the ioctl path. This adds it on RTM_NEWLINK. Reported-by: Xiao Liang Closes: https://lore.kernel.org/netdev/CABAhCOSzP1vaThGV35_VnsRCb=87_CPjPVsTHbq905k8A+BuUg@mail.gmail.com/ Fixes: b57708add314 ("gre: 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-2-maoyixie.tju@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1acdd14c0990dd1cd4b6534f00366d2e6dfce05f Author: Yiming Qian Date: Wed Jun 10 06:21:36 2026 +0000 net: skmsg: preserve sg.copy across SG transforms commit 406e8a651a7b854c41fecd5117bb282b3a6c2c6b upstream. The sk_msg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells sk_msg_compute_data_pointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the sk_msg, such as splice-backed file page-cache pages. Several sk_msg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SK_MSG verdict can then expose sg_virt(sge) as writable ctx->data and BPF stores can modify the original page cache. Keep sg.copy synchronized with sg.data[] whenever entries are transferred, shifted, split, or copied into a new sk_msg. Clear the bit when an entry is replaced by a newly allocated private page or freed. This covers the BPF pull/push/pop helpers, sk_msg_shift_left/right(), sk_msg_xfer(), and tls_split_open_record(), including the partial tail entry created during TLS open-record splitting. Fixes: d3b18ad31f93 ("tls: add bpf support to sk_msg handling") Cc: stable@vger.kernel.org Reported-by: Yiming Qian Reported-by: Keenan Dong Signed-off-by: Yiming Qian Link: https://patch.msgid.link/20260610062137.49075-1-yimingqian591@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit bd968bdd568beacfdf98ec537a87527e85f1d0cf Author: Doruk Tan Ozturk Date: Tue May 26 20:37:26 2026 +0200 mac802154: llsec: add skb_cow_data() before in-place crypto commit 84a04eb5b210643bd67aab81ff805d32f62aa865 upstream. llsec_do_encrypt_unauth(), llsec_do_encrypt_auth(), llsec_do_decrypt_unauth(), and llsec_do_decrypt_auth() all perform in-place cryptographic transformations on skb data. They build a scatterlist with sg_init_one() pointing into the skb's linear data area and then pass the same scatterlist as both src and dst to the crypto API (e.g. crypto_skcipher_encrypt/decrypt, crypto_aead_encrypt/decrypt). On the RX path, __ieee802154_rx_handle_packet() clones the received skb before handing it to each subscriber via ieee802154_subif_frame(). The cloned skb shares the same underlying data buffer via reference counting. When llsec_do_decrypt() subsequently modifies this shared buffer in place, it corrupts data that other clones -- potentially belonging to other sockets or subsystems -- still reference. On the TX path, similar data sharing can occur when an skb's head has been cloned (skb_cloned() returns true). The fix is to call skb_cow_data() before performing any in-place crypto operation. skb_cow_data() ensures that the skb's data area is not shared: if the skb head is cloned or the data spans multiple fragments, it copies the data into a private buffer that can be safely modified in place. This is the same pattern used by: - ESP (net/ipv4/esp4.c, net/ipv6/esp6.c) - MACsec (drivers/net/macsec.c) - WireGuard (drivers/net/wireguard/receive.c) - TIPC (net/tipc/crypto.c) Without this guard, in-place crypto on shared skb data leads to: - Silent data corruption of other skb clones - Use-after-free when the crypto API scatterwalk writes through a page that has already been freed by another clone's kfree_skb() - Kernel crashes under concurrent 802.15.4 traffic with security enabled (KASAN/KMSAN reports slab-use-after-free) Found by 0sec (https://0sec.ai) using automated source analysis. Fixes: 4c14a2fb5d14 ("mac802154: add llsec decryption method") Fixes: 03556e4d0dbb ("mac802154: add llsec encryption method") Cc: stable@vger.kernel.org Reported-by: Doruk Tan Ozturk Closes: https://lore.kernel.org/linux-wpan/20260525161806.96158-1-doruk@0sec.ai/ Reviewed-by: Alexander Lobakin Signed-off-by: Doruk Tan Ozturk Closes: Link: https://lore.kernel.org/20260526183726.56100-1-doruk@0sec.ai Signed-off-by: Stefan Schmidt Signed-off-by: Greg Kroah-Hartman commit 0cfa78c050662784fc8e3ab26dbfd1dc632b2082 Author: Kuniyuki Iwashima Date: Wed Jul 1 09:53:06 2026 +0300 af_unix: Set gc_in_progress to true in unix_gc(). [ Upstream commit d82ba05263c69fa2437fe93e4e561cc40f4c03af ] Igor Ushakov reported that unix_gc() could run with gc_in_progress being false if the work is scheduled while running: Thread 1 Thread 2 Thread 3 -------- -------- -------- unix_schedule_gc() unix_schedule_gc() `- if (!gc_in_progress) `- if (!gc_in_progress) |- gc_in_progress = true | `- queue_work() | unix_gc() <----------------/ | | |- gc_in_progress = true ... `- queue_work() | | `- gc_in_progress = false | | unix_gc() <---------------------------------------------' | ... /* gc_in_progress == false */ | `- gc_in_progress = false unix_peek_fpl() relies on gc_in_progress not to confuse GC by MSG_PEEK. Let's set gc_in_progress to true in unix_gc(). Fixes: 8b90a9f819dc ("af_unix: Run GC on only one CPU.") Reported-by: Igor Ushakov Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260501073945.1884564-1-kuniyu@google.com Signed-off-by: Jakub Kicinski [ Add setting gc_in_progress in __unix_gc(). Keep the existing set in unix_gc() for wait_for_unix_gc() over-limit throttling. ] Signed-off-by: Igor Ushakov Signed-off-by: Sasha Levin commit 3c499851753a24d2e148d4e9ca51764c0c51554e Author: Jiajia Liu Date: Thu May 28 11:38:14 2026 +0800 wifi: mt76: add wcid publish check in mt76_sta_add commit 20b126920a259df4d7dcae19fcfe2c57a74d6b2e upstream. Since mt7925_mac_sta_add publishes wcid, add publish check in mt76_sta_add to avoid reinitializing the wcid->poll_list. Found dev->sta_poll_list corruption when using mt7925 and 7.1-rc4. According to the corruption information, prev->next was changed to itself. wlan0: disconnect from AP 90:fb:5d:94:8b:e3 for new auth to 90:fb:5d:94:8b:e2 wlan0: authenticate with 90:fb:5d:94:8b:e2 (local address=84:9e:56:9c:7e:6b) wlan0: send auth to 90:fb:5d:94:8b:e2 (try 1/3) slab kmalloc-8k start ffff8c80958a6000 pointer offset 4160 size 8192 list_add corruption. prev->next should be next (ffff8c808a7488f8), but was ffff8c80958a7040. (prev=ffff8c80958a7040). mt76_wcid_add_poll+0x95/0xd0 [mt76] mt7925_mac_add_txs.part.0+0xa5/0xe0 [mt7925_common] mt7925_rx_check+0xa7/0xc0 [mt7925_common] mt76_dma_rx_poll+0x50d/0x790 [mt76] mt792x_poll_rx+0x52/0xe0 [mt792x_lib] Signed-off-by: Jiajia Liu Link: https://patch.msgid.link/20260528033814.46418-1-liujiajia@kylinos.cn Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 5e658b9245a52d838ef93729a7bc07de8e19deb7 Author: Konstantin Komarov Date: Wed Jun 10 12:31:01 2026 +0200 ntfs3: reject direct userspace writes to reserved $LX* xattrs commit 5b08dccecf825cbf905f348bc6ccb497507e28e2 upstream. NTFS3 uses $LXUID, $LXGID, $LXMOD and $LXDEV as internal WSL permission metadata and reloads them into i_uid, i_gid and i_mode from ntfs_get_wsl_perm(). Because the empty-prefix xattr handler also lets file owners call setxattr() on these names directly, an unprivileged writer on a writable ntfs3 mount can plant root ownership and S_ISUID on their own file and gain euid 0 after inode reload. Reject direct userspace writes to the reserved $LX* names. Internal ntfs3 metadata updates are unchanged because ntfs_save_wsl_perm() writes them via ntfs_set_ea() directly. Signed-off-by: Zhen Yan [almaz.alexandrovich@paragon-software.com: added an additional check for non privileged users] Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit 77798d7be6ef71e72fb6fc8a2901bf74ebc9706f Author: Wongi Lee Date: Tue Jun 16 22:38:29 2026 +0900 ipv4: account for fraggap on the paged allocation path [ Upstream commit eca856950f7cb1a221e02b99d758409f2c5cec42 ] In __ip_append_data(), when the paged-allocation branch is taken, alloclen and pagedlen are computed as alloclen = fragheaderlen + transhdrlen; pagedlen = datalen - transhdrlen; datalen already includes fraggap, but the fraggap bytes carried over from the previous skb are copied into the new skb's linear area at offset transhdrlen by the subsequent skb_copy_and_csum_bits(). The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Fixes: 8eb77cc73977 ("ipv4: avoid partial copy for zc") Signed-off-by: Jungwoo Lee Signed-off-by: Wongi Lee Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/ajFR1eLAIs42TN3g@DESKTOP-19IMU7U.localdomain Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6374fb9edf72c67a118a2c214a0dddd04c921e0a Author: Wongi Lee Date: Tue Jun 16 22:46:17 2026 +0900 ipv6: account for fraggap on the paged allocation path commit 736b380e28d0480c7bc3e022f1950f31fe53a7c5 upstream. In __ip6_append_data(), when the paged-allocation branch is taken (MSG_MORE / NETIF_F_SG / large fraglen), alloclen and pagedlen are computed as alloclen = fragheaderlen + transhdrlen; pagedlen = datalen - transhdrlen; datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skb_shared_info. An unprivileged user can trigger this via a UDPv6 socket using MSG_MORE together with MSG_SPLICE_PAGES. The bad accounting was introduced by commit 773ba4fe9104 ("ipv6: avoid partial copy for zc"). Before commit ce650a166335 ("udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSG_SPLICE_PAGES to proceed in this case, making the corruption triggerable. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Since a negative copy is no longer expected for a valid MSG_SPLICE_PAGES case, remove the MSG_SPLICE_PAGES exception from the negative copy check. Fixes: 773ba4fe9104 ("ipv6: avoid partial copy for zc") Signed-off-by: Jungwoo Lee Signed-off-by: Wongi Lee Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/ajFTqRljatR17fFy@DESKTOP-19IMU7U.localdomain Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 565ab66005b14e4d40f2ef7d36cc6baaf9725fb2 Author: Sven Eckelmann Date: Fri Jun 26 18:12:10 2026 +0200 batman-adv: tvlv: avoid race of cifsnotfound handler state commit edb557b2ba38fea2c5eb710cf366c797e187218c upstream. TVLV handlers can have the flag BATADV_TVLV_HANDLER_OGM_CIFNOTFND set to signal that the OGM handler should be called (with NULL for data) when the specific TVLV container was not found in the OGM. This is used by: * DAT * GW * Multicast (OGM + Tracker) The state whether the handler was executed was stored in the struct batadv_tvlv_handler. But the TVLV processing is started without any lock. Multiple parallel contexts processing TVLVs would therefore overwrite each others BATADV_TVLV_HANDLER_OGM_CALLED flag in the shared batadv_tvlv_handler. Drop the shared BATADV_TVLV_HANDLER_OGM_CALLED flag and instead determine, per TVLV buffer, whether a matching container was present by scanning the packet's buffer. Cc: stable@kernel.org Fixes: ef26157747d4 ("batman-adv: tvlv - basic infrastructure") Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit 4cc9f7711bb898f7af34eef26f615e9465ae250c Author: Sven Eckelmann Date: Fri Jun 26 18:12:09 2026 +0200 batman-adv: tvlv: enforce 2-byte alignment commit 32a6799255525d6ea4da0f7e9e0e521ad9560a46 upstream. The fields of an aggregated OGM(v2) are accessed assuming (at least) 2-byte alignment, so a following OGM must start at an even offset. As the header length is even, an odd tvlv_len would misalign it and trigger unaligned accesses on strict-alignment architectures. Such a misaligned TVLV/OGM/OGMv2 is not created by a normal participant in the mesh. Therefore, reject such malformed packets. Cc: stable@kernel.org Fixes: ef26157747d4 ("batman-adv: tvlv - basic infrastructure") Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit 04e1a6557fbf8ad9385563ae79c5437cb5bf94c3 Author: Sven Eckelmann Date: Fri Jun 26 18:12:08 2026 +0200 batman-adv: dat: prevent false sharing between VLANs commit 20d7658b74169f86d4ac01b9185b3eadddf71f28 upstream. The local hash of DAT entries is supposed to be VLAN (VID) aware. But the adding to the hash and the search in the hash were not checking the VID information of the hash entries. The entries would therefore only be correctly separated when batadv_hash_dat() didn't select the same buckets for different VIDs. Cc: stable@kernel.org Fixes: be1db4f6615b ("batman-adv: make the Distributed ARP Table vlan aware") Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit 3f82fc92cf523a007a423c21b04613acf32aeaa3 Author: Sven Eckelmann Date: Fri Jun 26 18:12:07 2026 +0200 batman-adv: tt: track roam count per VID commit 12407d5f61c2653a64f2ff4b22f3c267f8420ef1 upstream. batadv_tt_check_roam_count() is supposed to track roaming of a TT entry. But TT entries are for a MAC + VID. The VID was completely missed and thus leads to incorrect detection of ROAM counts when a client MAC exists in multiple VLANs. Cc: stable@kernel.org Fixes: c018ad3de61a ("batman-adv: add the VLAN ID attribute to the TT entry") Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit 3470d583fc652c40db2bfd350e981e0e4716e189 Author: Sven Eckelmann Date: Fri Jun 26 18:12:06 2026 +0200 batman-adv: tt: don't merge change entries with different VIDs commit f08e06c2d5c3e2434e7c773f2213f4a7dce6bc1e upstream. batadv_tt_local_event() merges/cancels events for the same client which would conflict or be duplicates. The matching of the queued events only compares the MAC address - the VLAN ID stored in each event is ignored. If a MAC would now appear on multiple VID, the two ADD change events (for VID 1 and VID 2) would be merged to a single vid event. The remote can therefore not calculate the correct TT table and desync. A full translation table exchange is required to recover from this state. A check of VID is therefore necessary to avoid such wrong merges/cancels. Cc: stable@kernel.org Fixes: c018ad3de61a ("batman-adv: add the VLAN ID attribute to the TT entry") Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit af5a069805f67957340cde27e349374be676e6d4 Author: Sven Eckelmann Date: Fri Jun 26 18:12:05 2026 +0200 batman-adv: tp_meter: handle overlapping packets commit cbde75c38b21f022891525078622587ad557b7c1 upstream. If the size of the packets would change during the transmission, it could happen that some retries of packets are overlapping. In this case, precise comparisons of sequence numbers by the receiver would be wrong. It is then necessary to check if the start sequence number to the end sequence number ("seqno + length") would contain a new range. If this is the case then this is enough to accept this packet. In all other cases, the packet still has to be dropped (and not acked). Cc: stable@kernel.org Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation") [ Switch to pre-splitted tp_vars structure names ] Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit d511c72a83dd55adf90f318f4471285e605264f8 Author: Sven Eckelmann Date: Fri Jun 26 18:12:04 2026 +0200 batman-adv: tp_meter: prevent parallel modifications of last_recv commit 6dde0cfcb36e4d5b3de35b75696937478441eed4 upstream. When last_recv is updated to store the last receive sequence number, it is assuming that nothing is modifying in parallel while: * check for outdated packets is done * out of order check is performed (and packets are stored in out-of-order queue) * the out-of-order queue was searched for closed gaps * sequence number for next ack is calculated Nothing of that was actually protected. It could therefore happen that the last_recv was updated multiple times in parallel and the final sequence number was calculated with deltas which had no connection to the sequence number they were added to. Lock this whole region with the same lock which was already used to protect the unacked (out-of-order) list. Cc: stable@kernel.org Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation") [ Switch to pre-splitted tp_vars structure names ] Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit 1dafdd0794be1a63d2c45f9a32e0a9cd89f68478 Author: Sven Eckelmann Date: Fri Jun 26 18:12:03 2026 +0200 batman-adv: tp_meter: annotate last_recv_time access with READ/WRITE_ONCE commit d67c728f07fca2ee6ffdc6dd4421cf2e8691f4d1 upstream. The last_recv_time field for batadv_tp_receiver tracks the jiffies value of the most recent activity and is used to detect timeouts. These accesses are not consistently protected by a lock, so READ_ONCE/WRITE_ONCE must be used to prevent data races caused by compiler optimizations. Cc: stable@kernel.org Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation") Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit 2233787658db859f0a9b83cb397cf783bb8be865 Author: Sven Eckelmann Date: Fri Jun 26 18:12:02 2026 +0200 batman-adv: tp_meter: restrict number of unacked list entries commit e7c775110e1858e5a7471a23a9c9658c0af9df89 upstream. When the unacked_list is unbound, an attacker could send messages with small lengths and appropriated seqno + gaps to force the receiver to allocate more and more unacked_list entries. And the end either causing an out-of-memory situation or increase the management overhead for the (large) list that significant portions of CPU cycles are wasted in searching through the list. When limiting the list to a specific number, it is important to still correctly add a new entry to the list. But if the list became larger than the limit, the last entry of the list (with the highest seqno) must be dropped to still allow the earlier seqnos to finish and therefore to continue the process. Otherwise, the process might get stuck with too high seqnos which are not handled by batadv_tp_ack_unordered(). Cc: stable@kernel.org Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation") [ Switch to pre-splitted tp_vars structure names ] Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit 3d4548c96d6f21ac1a9b06c5f82f3ef439c87023 Author: Sven Eckelmann Date: Fri Jun 26 18:12:01 2026 +0200 batman-adv: v: prevent OGM aggregation on disabled hardif commit d11c00b95b2a3b3934007fc003dccc6fdcc061ad upstream. When an interface gets disabled, the worker is correctly disabled by batadv_hardif_disable_interface() -> ... -> batadv_v_ogm_iface_disable(). In this process, the skb aggr_list is also freed. But batadv_v_ogm_send_meshif() can still queue new skbs (via batadv_v_ogm_queue_on_if()) to the aggr_list. This will only stop after all cores can no longer find the RCU protected list of hard interfaces. These queued skbs will never be freed or consumed by batadv_v_ogm_aggr_work. The batadv_v_ogm_iface_disable() function must block batadv_v_ogm_queue_on_if() to avoid leak of skbs. Cc: stable@kernel.org Fixes: f89255a02f1d ("batman-adv: BATMAN_V: introduce per hard-iface OGMv2 queues") [ Context ] Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit 44ae137a2aceff08cd226718ef077adca2638012 Author: Sven Eckelmann Date: Fri Jun 26 18:12:00 2026 +0200 batman-adv: frag: avoid underflow of TTL commit 493d9d2528e1a09b090e4b37f0f553def7bd5ce9 upstream. Packets with a TTL are using it to limit the amount of time this packet can be forwarded. But for batadv_frag_packet, the TTL was always only reduced but it was never evaluated. It could even underflow without any effect. Check the TTL in batadv_frag_skb_fwd() before attempting to prepare it for forwarding. This keeps it in sync with the not fragmented unicast packet. Cc: stable@kernel.org Fixes: 610bfc6bc99b ("batman-adv: Receive fragmented packets and merge") Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit 116e94025f0f48cbcfc167b6dc925551fad1b2bd Author: Sven Eckelmann Date: Fri Jun 26 18:11:59 2026 +0200 batman-adv: frag: ensure fragment is writable before modifying TTL commit b7293c6e8c15b2db77809b25cf8389e35331b27a upstream. Before batman-adv is allowed to write to an skb, it either has to have its own copy of the skb or use skb_cow() to ensure that the data part is not shared. But batadv_frag_skb_fwd() modifies the TTL even when it is shared. Adding a skb_cow() right before this operation avoids this and can at the same time prepare it for the modifications required to forward the fragment. Cc: stable@kernel.org Fixes: 610bfc6bc99b ("batman-adv: Receive fragmented packets and merge") Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit 0473ae882624ae309399c3fff10cedc6d0cffbfd Author: Sven Eckelmann Date: Fri Jun 26 18:11:58 2026 +0200 batman-adv: fix (m|b)cast csum after decrementing TTL commit e728bbdf32660c8f32b8f5e8d09427a2c131ad60 upstream. The broadcast and multicast packets can be received at the same time by the local system and forwarded to other nodes. Both are simply decrementing the TTL at the beginning of the receive path - independent of chosen paths (receive/forward). But such a modification of the data conflicts with the hw csum. This is not a problem when the packet is directly forwarded but can cause errors in the local receive path. Such a problem can then trigger a "hw csum failure". The receiver path must therefore ensure that the csum is fixed for each modification of the payload before batadv_interface_rx() is reached. Since all batman-adv packet types with a ttl have it as u8 at offset 2, a helper can be used for all of them. But it is only used at the moment for batadv_bcast_packet and batadv_mcast_packet because they are the only ones which deliver the packet locally but unconditionally modify the TTL. Cc: stable@kernel.org Fixes: 3f69339068f9 ("batman-adv: bcast: queue per interface, if needed") Fixes: 07afe1ba288c ("batman-adv: mcast: implement multicast packet reception and forwarding") Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit 49bf27fcd7ee4cf643d766fc91fffbf2b0134363 Author: Sven Eckelmann Date: Fri Jun 26 18:11:57 2026 +0200 batman-adv: ensure bcast is writable before modifying TTL commit 4cd6d3a4b96a8576f1fed8f9f9f17c2dc2978e0c upstream. Before batman-adv is allowed to write to an skb, it either has to have its own copy of the skb or used skb_cow() to ensure that the data part is not shared. The old implementation used a shared queue and created copies before attempting to write to it. But with the new implementation, the broadcast packet is already modified when it gets received. Potentially writing to shared buffers in this process. Adding a skb_cow() right before this operation avoids this and can at the same time prepare it for the modifications required to rebroadcast the packet. Cc: stable@kernel.org Fixes: 3f69339068f9 ("batman-adv: bcast: queue per interface, if needed") Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit 646b68639c06bc44593216fd7e9433d48d5e96eb Author: Sven Eckelmann Date: Fri Jun 26 18:11:56 2026 +0200 batman-adv: gw: don't deselect gateway with active hardif commit df97a7107b16375a10a36d7a63e9b4291a8ac680 upstream. The batadv_hardif_cnt() was previously checking if there is an batadv_hard_iface->mesh_iface which is has the same mesh_iface. And since batadv_hardif_disable_interface() was resetting the batadv_hard_iface->mesh_iface after this check, it had to verify whether *1* interface was still part of the mesh_iface before it started the gateway deselection. But after batadv_hardif_cnt() is now checking the lower interfaces of mesh_iface and batadv_hardif_disable_interface() already removed the interface via netdev_upper_dev_unlink() earlier in this function, the check must now make sure that *0* interfaces can be found by batadv_hardif_cnt() before selected gateway must be deselected. Otherwise the deselection would already happen one batadv_hard_iface too early. Because a 0 hardif count from batadv_hardif_cnt() is equal to an empty list, it is possible to replace the counting with a simple list_empty(). Cc: stable@kernel.org Fixes: 7dc284702bcd ("batman-adv: store hard_iface as iflink private data") Reviewed-by: Nora Schiffer Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit 95a061f587b76a519ee17e3d406a37bc4eb63a50 Author: Sven Eckelmann Date: Fri Jun 26 18:11:55 2026 +0200 batman-adv: tp_meter: initialize last_recv_time during init commit 811cb00fa8cdc3f0a7f6eefc000a6888367c8c8f upstream. The last_recv_time is the most important indicator for a receiver session to figure out whether a session timed out or not. But this information was only initialized after the session was added to the tp_receiver_list and after the timer was started. In the worst case, the timer (function) could have tried to access this information before the actual initialization was reached. Like rest of the variables of the tp_meter receiver session, this field has to be filled out before any other (parallel running) context has the chance to access it. Cc: stable@kernel.org Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation") [ Context ] Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit 75612c100a9e2fe9df718056b03f544ec5b0623e Author: Sven Eckelmann Date: Fri Jun 26 18:11:54 2026 +0200 batman-adv: prevent ELP transmission interval underflow commit 5e50d4b8ae3ea622122d3c6a38d7f6fe68dfddca upstream. batadv_v_elp_start_timer() enqeues a delayed work. The time when it starts is randomly chosen between (elp_interval - BATADV_JITTER) and (elp_interval + BATADV_JITTER). The configured elp_interval must therefore be larger or equal to BATADV_JITTER to avoid that it causes an underflow of the unsigned integer. If this would happen, then a "fast" ELP interval would turn into a "day long" delay. At the same time, it must not be larger than the maximum value the variable can store. Cc: stable@kernel.org Fixes: a10800829040 ("batman-adv: Add elp_interval hardif genl configuration") [ Context ] Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit 43733e5b525fbee8e60903b57d1a8cf6498e762d Author: Sven Eckelmann Date: Fri Jun 26 18:11:53 2026 +0200 batman-adv: bla: annotate lasttime access with READ/WRITE_ONCE commit 98b0fb191c878a64cbaebfe231d96d57576acf8c upstream. The lasttime field for claim, backbone_gw, and loopdetect tracks the jiffies value of the most recent activity and is used to detect timeouts. These accesses are not consistently protected by a lock, so READ_ONCE/WRITE_ONCE must be used to prevent data races caused by compiler optimizations. Cc: stable@kernel.org Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code") Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit 23d085bd63086457ae82ab92e9e2d8ec895e2774 Author: Sven Eckelmann Date: Fri Jun 26 18:11:52 2026 +0200 batman-adv: tp_meter: add only finished tp_vars to lists commit 15ccbf685222274f5add1387af58c2a41a95f81e upstream. When the receiver variables (aka "session") are initialized, then they are added to the list of sessions before the timer is set up. A RCU protected reader could therefore find the entry and run mod_setup before batadv_tp_init_recv() finished the timer initialization. The same is true for batadv_tp_start(), which must first initialize the finish_work and the test_length to avoid a similar problem. Cc: stable@kernel.org Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation") Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit b8bf8400e50cbab595843241f63be3355deb1ca8 Author: Sven Eckelmann Date: Fri Jun 26 18:11:51 2026 +0200 batman-adv: tp_meter: handle seqno wrap-around for fast recovery detection commit f54c85ed42a1b27a516cf2a4728f5a612b799e07 upstream. The recover variable and the last_sent sequence number are initialized on purpose as a really high value which will wrap-around after the first 2000 bytes. The fast recovery precondition must therefore not use simple integer comparisons but use helpers which are aware of the sequence number wrap-arounds. Cc: stable@kernel.org Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation") Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit 1db02f3e315da800720e2e14b4a9c8ffe14e8cbd Author: Sven Eckelmann Date: Fri Jun 26 18:11:50 2026 +0200 batman-adv: tp_meter: fix fast recovery precondition commit 2b0d08f08ed3b2174f05c43089ec65f3543a025b upstream. The fast recovery precondition checks if the recover (initialized to BATADV_TP_FIRST_SEQ) is bigger than the received ack. But since recover is only updated when this check is successful, it will never enter the fast recovery mode. According to RFC6582 Section 3.2 step 2, the check should actually be different: > When the third duplicate ACK is received, the TCP sender first > checks the value of recover to see if the Cumulative > Acknowledgment field covers more than recover The precondition must therefore check if recover is smaller than the received ack - basically swapping the operands of the current check. Cc: stable@kernel.org Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation") Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit 7d2a44bc6bbe39aed03c68864aa0e54e04a50278 Author: Sven Eckelmann Date: Fri Jun 26 18:11:49 2026 +0200 batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd commit 33ccd52f3cc9ed46ce395199f89aa3234dc83314 upstream. The cwnd is always MSS <= cwnd <= 0x20000000. But the calculation in batadv_tp_update_cwnd() assumes unsigned 32 bit arithmetics. ((mss * 8) ** 2) / (cwnd * 8) In case cwnd is actually 0x20000000, it will be shifted by 3 bit to the left end up at 0x100000000 or U32_MAX + 1. It will therefore wrap around and be 0 - resulting in: ((mss * 8) ** 2) / 0 This is of course invalid and cannot be calculated. The calculation should must be simplified to avoid this overflow: (mss ** 2) * 8 / cwnd It will keep the precision enhancement from the scaling (by 8) but avoid the overflow in the divisor. In theory, there could still be an overflow in the dividend. It is at the moment fixed to BATADV_TP_PLEN in batadv_tp_recv_ack() - so it is not an imminent problem. But allowing it to use the whole u32 bit range, would mean that it can still use up to 67 bits. To keep this calculation safe for 32 bit arithmetic, mss must never use more than floor((32 - 3) / 2) bits - or in other words: must never be larger than 16383. Cc: stable@kernel.org Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation") Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit 8e77fe0414f5c7c956ea82615975d43eab018c25 Author: Sven Eckelmann Date: Fri Jun 26 18:11:48 2026 +0200 batman-adv: tp_meter: avoid window underflow commit 765947b81fb54b6ebb0bc1cfe55c0fa399e002b8 upstream. In batadv_tp_avail(), win_left is calculated with 32-bit unsigned arithmetic: win_left = win_limit - tp_vars->last_sent; During Fast Recovery, cwnd is inflated and last_sent advances rapidly. When Fast Recovery ends, cwnd drops abruptly back to ss_threshold. If the newly shrunk win_limit is less than last_sent, the unsigned subtraction will underflow, wrapping to a massive positive value. Instead of returning that the window is full (unavailable), it returns that the sender can continue sending. To handle this situation, it must be checked whether the windows end sequence number (win_limit) has to be compared with the last sent sequence number. If it would be before the last sent sequence number, then more acks are needed before the transmission can be started again. Cc: stable@kernel.org Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation") Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit 7cb88d91d5f9f9a2842e0ec0622d01bdfaa0511a Author: Sven Eckelmann Date: Fri Jun 26 18:11:47 2026 +0200 batman-adv: tp_meter: initialize dec_cwnd explicitly commit febfb1b86224489535312296ecfa3d4bf467f339 upstream. When batadv_tp_update_cwnd() is called, dec_cwnd is increased. But dec_cwnd is only initialixed (to 0) when a duplicate Ack was received or when cwnd is below the ss_threshold. Just initialize the cwnd during the initialization to avoid any potential access of uninitialized data. Cc: stable@kernel.org Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation") Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit 696c4cae872cca59f51b1b5a0f8888d22ccb47a2 Author: Sven Eckelmann Date: Fri Jun 26 18:11:46 2026 +0200 batman-adv: tp_meter: initialize dup_acks explicitly commit b2b68b32a715e0328662801576974aa37b942b00 upstream. When an ack with a sequence number equal to the last_acked is received, the dup_acks counter is increased to decide whether fast retransmit should be performed. Only when the sequence numbers are not equal, the dup_acks is set to the initial value (0). But if the initial packet would have the sequence number BATADV_TP_FIRST_SEQ, dup_acks would not be initialized and atomic_inc would operate on an undefined starting value. It is therefore required to have it explicitly initialized during the start of the sender session. Cc: stable@kernel.org Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation") Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit 1c5a1268418e8a2e5ab652a3adafac6c1e5e96b8 Author: Sven Eckelmann Date: Fri Jun 26 18:11:45 2026 +0200 batman-adv: tp_meter: keep unacked list in ascending ordered commit 5aa8651527ea0b610e7a09fb3b8204c1398b9525 upstream. When batadv_tp_handle_out_of_order inserts a new entry in the list of unacked (out of order) packets, it searches from the entry with the newest sequence number towards oldest sequence number. If an entry is found which is older than the newly entry, the new entry has to be added after the found one to keep the ascending order. But for this operation list_add_tail() was used. But this function adds an entry _before_ another one. As result, the list would contain a lot of swapped sequence numbers. The consumer of this list (batadv_tp_ack_unordered()) would then fail to correctly ack packets. Cc: stable@kernel.org Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation") Signed-off-by: Sven Eckelmann Signed-off-by: Sasha Levin commit e055e74b80eb8858f98c736aa565173a917dcab5 Author: NeilBrown Date: Fri Jun 26 10:31:22 2026 -0400 lockd: fix TEST handling when not all permissions are available. [ Upstream commit 0b474240327cebeff08ad429e8ed3cfc6c8ee816 ] The F_GETLK fcntl can work with either read access or write access or both. It can query F_RDLCK and F_WRLCK locks in either case. However lockd currently treats F_GETLK similar to F_SETLK in that read access is required to query an F_RDLCK lock and write access is required to query a F_WRLCK lock. This is wrong and can cause problems - e.g. when qemu accesses a read-only (e.g. iso) filesystem image over NFS (though why it queries if it can get a write lock - I don't know. But it does, and this works with local filesystems). So we need TEST requests to be handled differently. To do this: - change nlm_do_fopen() to accept O_RDWR as a mode and in that case succeed if either a O_RDONLY or O_WRONLY file can be opened. - change nlm_lookup_file() to accept a mode argument from caller, instead of deducing base on lock time, and pass that on to nlm_do_fopen() - change nlm4svc_retrieve_args() and nlmsvc_retrieve_args() to detect TEST requests and pass O_RDWR as a mode to nlm_lookup_file, passing the same mode as before for other requests. Also set lock->fl.c.flc_file to whichever file is available for TEST requests. - change nlmsvc_testlock() to also not calculate the mode, but to use whatever was stored in lock->fl.c.flc_file. This behaviour of lockd - requesting O_WRONLY access to TEST for exclusive locks - has been present at least since git history began. However it was hidden until recently because knfsd ignored the access requested by lockd and required only READ access for all locking requests (unless the underlying filesystem provided an f_op->open function which checked access permissions). The commit mentioned in Fixes: below changed nfsd_permission() to NOT override the access request for LOCK requests and this exposed the bug that we are now fixing. Note that there is another issue that this patch does not address. The flock(.., LOCK_EX) call is permitted on a read-only file descriptor. Linux NFS maps this to NLM locking as whole-file byte-range locks. nfsd will see this as though it were fcntl( F_SETLK (F_WRLCK)) and will now require write access, which it might not be able to get. It is not clear if this is a problem in practice, or what the best solution might be. So no attempt is made to address it. Reported-by: Tj Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1128861 Fixes: 4cc9b9f2bf4d ("nfsd: refine and rename NFSD_MAY_LOCK") Reviewed-by: Jeff Layton Signed-off-by: NeilBrown Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 671ec2eabb874fcb593297c4dd885fc3dae54f32 Author: Sasha Levin Date: Sat Jun 27 10:53:39 2026 -0400 Revert "PCI: qcom: Advertise Hotplug Slot Capability with no Command Completion support" This reverts commit f176c47683bf6365e2f6d580d557fae49169a703. Signed-off-by: Sasha Levin commit d844702198395d3f80222777030f69db6be6b709 Author: Paul Moore Date: Fri Jun 26 15:50:35 2026 +0800 selinux: fix overlayfs mmap() and mprotect() access checks [ Upstream commit 82544d36b1729153c8aeb179e84750f0c085d3b1 ] The existing SELinux security model for overlayfs is to allow access if the current task is able to access the top level file (the "user" file) and the mounter's credentials are sufficient to access the lower level file (the "backing" file). Unfortunately, the current code does not properly enforce these access controls for both mmap() and mprotect() operations on overlayfs filesystems. This patch makes use of the newly created security_mmap_backing_file() LSM hook to provide the missing backing file enforcement for mmap() operations, and leverages the backing file API and new LSM blob to provide the necessary information to properly enforce the mprotect() access controls. Cc: stable@vger.kernel.org Acked-by: Amir Goldstein Signed-off-by: Paul Moore Signed-off-by: Cai Xinchen Signed-off-by: Sasha Levin commit 5dfcb15974e7d0f96aca278dd9f1b85df91523ef Author: Paul Moore Date: Fri Jun 26 15:50:34 2026 +0800 lsm: add backing_file LSM hooks [ Upstream commit 6af36aeb147a06dea47c49859cd6ca5659aeb987 ] Stacked filesystems such as overlayfs do not currently provide the necessary mechanisms for LSMs to properly enforce access controls on the mmap() and mprotect() operations. In order to resolve this gap, a LSM security blob is being added to the backing_file struct and the following new LSM hooks are being created: security_backing_file_alloc() security_backing_file_free() security_mmap_backing_file() The first two hooks are to manage the lifecycle of the LSM security blob in the backing_file struct, while the third provides a new mmap() access control point for the underlying backing file. It is also expected that LSMs will likely want to update their security_file_mprotect() callback to address issues with their mprotect() controls, but that does not require a change to the security_file_mprotect() LSM hook. There are a three other small changes to support these new LSM hooks: * Pass the user file associated with a backing file down to alloc_empty_backing_file() so it can be included in the security_backing_file_alloc() hook. * Add getter and setter functions for the backing_file struct LSM blob as the backing_file struct remains private to fs/file_table.c. * Constify the file struct field in the LSM common_audit_data struct to better support LSMs that need to pass a const file struct pointer into the common LSM audit code. Thanks to Arnd Bergmann for identifying the missing EXPORT_SYMBOL_GPL() and supplying a fixup. Cc: stable@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org Cc: linux-unionfs@vger.kernel.org Cc: linux-erofs@lists.ozlabs.org Reviewed-by: Amir Goldstein Reviewed-by: Serge Hallyn Reviewed-by: Christian Brauner Signed-off-by: Paul Moore [Mainline declares lsm_backing_file_cache in security/lsm.h. Linux 6.18.y does not have security/lsm_init.c or security/lsm.h; the cache variable is defined locally as static struct kmem_cache *lsm_backing_file_cache in security/security.c.] Signed-off-by: Cai Xinchen Signed-off-by: Sasha Levin commit 5e470998a23e4c3d89ed24e8172cb22747e61efa Author: Paolo Bonzini Date: Fri Jun 26 13:23:15 2026 +0200 KVM: x86: Fix shadow paging use-after-free due to unexpected role commit 81ccda30b4e83d8f5cc4fd50503c44e3a33abfeb upstream. Commit 0cb2af2ea66ad ("KVM: x86: Fix shadow paging use-after-free due to unexpected GFN") fixed a shadow paging mismatch between stored and computed GFNs; the bug could be triggered by changing a PDE mapping from outside the guest, and then deleting a memslot. The rmap_remove() call would miss entries created after the PDE change because the GFN of the leaf SPTE does not match the GFN of the struct kvm_mmu_page. A similar hole however remains if the modified PDE points to a non-leaf page. In this case the gfn can be made to match, but the role does not match: the original large 2MB page creates a kvm_mmu_page with direct=1, while the new 4KB needs a kvm_mmu_page with direct=0. However, kvm_mmu_get_child_sp() does not compare the role, and therefore reuses the page. The next step is installing a leaf (4KB) SPTE on the new path which records an rmap entry under the gfn resolved by the walk. But when that child is zapped its parent kvm_mmu_page has direct=1 and kvm_mmu_page_get_gfn() computes the gfn for the 4KB page as sp->gfn + index instead of using sp->shadowed_translation[] (or sp->gfns[] in older kernels). It therefore fails to remove the recorded entry. When the memslot is dropped the shadow page is freed but the rmap entry survives, as in the scenario that was already fixed. Code that later walks that gfn (dirty logging, MMU notifier invalidation, and so on) dereferences an sptep that lies in the freed page, causing the use-after-free. Fixes: 2032a93d66fa ("KVM: MMU: Don't allocate gfns page for direct mmu pages") Reported-by: Hyunwoo Kim Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 6e2cd08aa3e85c1a4f14973e931dccade1485228 Author: Alexandre Frade Date: Sat Jun 27 19:49:19 2026 +0000 Linux 6.18.37-xanmod1 Signed-off-by: Alexandre Frade commit 0d25ba9b7110887735f68ac55982cd0451ed804e Merge: e5609e8d8cac 0c503cf3dde2 Author: Alexandre Frade Date: Sat Jun 27 19:47:40 2026 +0000 Merge tag 'v6.18.37' into 6.18 This is the 6.18.37 stable release commit 0c503cf3dde2e53614f05261ece12f9d3d4c3c20 Author: Greg Kroah-Hartman Date: Sat Jun 27 11:06:50 2026 +0100 Linux 6.18.37 Link: https://lore.kernel.org/r/20260625125645.554579168@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Brett A C Sheffield Tested-by: Peter Schneider Tested-by: Shuah Khan Tested-by: Ron Economos Tested-by: Miguel Ojeda Tested-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 71003a32bef546b6e31aaa40db621846dbc98582 Author: Lorenzo Stoakes Date: Wed Jan 14 11:00:06 2026 +0000 mm: do not copy page tables unnecessarily for VM_UFFD_WP commit 35e247032606f06c2f19d90a6562bc315206b7a7 upstream. Commit ab04b530e7e8 ("mm: introduce copy-on-fork VMAs and make VM_MAYBE_GUARD one") aggregates flags checks in vma_needs_copy(), including VM_UFFD_WP. However in doing so, it incorrectly performed this check against src_vma. This check was done on the assumption that all relevant flags are copied upon fork. However the userfaultfd logic is very innovative in that it implements custom logic on fork in dup_userfaultfd(), including a rather well hidden case where lacking UFFD_FEATURE_EVENT_FORK causes VM_UFFD_WP to not be propagated to the destination VMA. And indeed, vma_needs_copy(), prior to this patch, did check this property on dst_vma, not src_vma. Since all the other relevant flags are copied on fork, we can simply fix this by checking against dst_vma. While we're here, we fix a comment against VM_COPY_ON_FORK (noting that it did indeed already reference dst_vma) to make it abundantly clear that we must check against the destination VMA. Link: https://lkml.kernel.org/r/20260114110006.1047071-1-lorenzo.stoakes@oracle.com Fixes: ab04b530e7e8 ("mm: introduce copy-on-fork VMAs and make VM_MAYBE_GUARD one") Signed-off-by: Lorenzo Stoakes Reported-by: Chris Mason Closes: https://lore.kernel.org/all/20260113231257.3002271-1-clm@meta.com/ Acked-by: David Hildenbrand (Red Hat) Acked-by: Pedro Falcato Cc: Liam Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 2abfd3ffbd9452f72535d96ff3982b3ab1f8f2f9 Author: Miklos Szeredi Date: Thu May 28 10:58:24 2026 +0200 virtiofs: fix UAF on submount umount commit 06b41351779e9289e8785694ade9042ae85e41ea upstream. iput() called from fuse_release_end() can Oops if the super block has already been destroyed. Normally this is prevented by waiting for num_waiting to go down to zero before commencing with super block shutdown. This only works, however, for the last submount instance, as the wait counter is per connection, not per superblock. Revert to using synchronous release requests for the auto_submounts case, which is virtiofs only at this time. Reported-by: Aurélien Bombo Reported-by: Zhihao Cheng Cc: Greg Kurz Closes: https://github.com/kata-containers/kata-containers/issues/12589 Fixes: 26e5c67deb2e ("fuse: fix livelock in synchronous file put from fuseblk workers") Cc: stable@vger.kernel.org Reviewed-by: Greg Kurz Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit f965cf22dda7f512f4922415894c3e528269a4ae Author: Ruslan Valiyev Date: Tue Mar 17 17:05:44 2026 +0000 media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si commit 7d8bf3d8f91073f4db347ed3aa6302b56107499c upstream. syzbot reported a general protection fault in vidtv_psi_ts_psi_write_into [1]. vidtv_mux_get_pid_ctx() can return NULL, but vidtv_mux_push_si() does not check for this before dereferencing the returned pointer to access the continuity counter. This leads to a general protection fault when accessing a near-NULL address. The root cause is that vidtv_mux_pid_ctx_init() does not check the return value of vidtv_mux_create_pid_ctx_once() for PMT section PIDs. If the allocation fails, the PID context is never created, but init returns success. The subsequent vidtv_mux_push_si() call then gets NULL from vidtv_mux_get_pid_ctx() and crashes. Fix both the root cause (add error check in vidtv_mux_pid_ctx_init for PMT PIDs) and add defensive NULL checks in vidtv_mux_push_si for all vidtv_mux_get_pid_ctx() calls. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events vidtv_mux_tick RIP: 0010:vidtv_psi_ts_psi_write_into+0x54a/0xbc0 drivers/media/test-drivers/vidtv/vidtv_psi.c:197 Call Trace: vidtv_psi_table_header_write_into drivers/media/test-drivers/vidtv/vidtv_psi.c:799 [inline] vidtv_psi_pmt_write_into+0x3b2/0xa70 drivers/media/test-drivers/vidtv/vidtv_psi.c:1231 vidtv_mux_push_si+0x932/0xe80 drivers/media/test-drivers/vidtv/vidtv_mux.c:196 vidtv_mux_tick+0xe9b/0x1480 drivers/media/test-drivers/vidtv/vidtv_mux.c:408 Fixes: f90cf6079bf67 ("media: vidtv: add a bridge driver") Cc: stable@vger.kernel.org Reported-by: syzbot+814c351d094f4f1a1b86@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=814c351d094f4f1a1b86 Signed-off-by: Ruslan Valiyev Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 7cad3ceaf679c55bc9946685dacafce78ce6b51a Author: Gil Portnoy Date: Thu Jun 11 22:59:19 2026 +0900 ksmbd: reject non-VALID session in compound request branch commit 609ca17d869d04ba249e32cdcbf13c0b1c66f43c upstream. smb2_check_user_session() takes a shortcut for any operation that is not the first in a COMPOUND request: it reuses work->sess (the session bound by the first operation) and validates only the SessionId, then returns "valid". It never re-checks work->sess->state == SMB2_SESSION_VALID, and a SessionId of 0xFFFFFFFFFFFFFFFF (ULLONG_MAX, the MS-SMB2 related-operation value) skips even the id comparison. The standalone path (ksmbd_session_lookup_all() plus the SESSION_SETUP state machine) does enforce the VALID state; the compound branch bypasses all of it. A SESSION_SETUP carrying only an NTLM Type-1 (NtLmNegotiate) blob publishes a fresh SMB2_SESSION_IN_PROGRESS session whose sess->user is still NULL (->user is assigned later, by ntlm_authenticate()). Used as operation 1 of a COMPOUND with operation 2 = TREE_CONNECT (related, SessionId=ULLONG_MAX, \\host\IPC$), the tree-connect then runs on that IN_PROGRESS session and reaches ksmbd_ipc_tree_connect_request(), which dereferences user_name(sess->user) with sess->user == NULL (transport_ipc.c:687/701/704) -> remote NULL-pointer dereference and a kernel Oops that wedges the ksmbd worker for all clients. Reject any non-first compound operation that lands on a session which is not SMB2_SESSION_VALID, mirroring the validity the standalone lookup path enforces. SESSION_SETUP itself legitimately runs on an IN_PROGRESS session, but it is never carried as a non-first compound operation, so multi-leg authentication is unaffected by this check. Fixes: 5005bcb42191 ("ksmbd: validate session id and tree id in the compound request") Cc: stable@vger.kernel.org Signed-off-by: Gil Portnoy Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 6c25bf4e44a2b6a14332f952bba0974521f5b72d Author: Georgi Djakov Date: Thu May 14 02:26:57 2026 -0700 drivers/base/memory: set mem->altmap after successful device registration commit a2b8d7827f48ee54a686cb80e4a1d0ff954ec42a upstream. If __add_memory_block() fails at xa_store() (under memory pressure for example), device_unregister() is called, which eventually triggers memory_block_release() with mem->altmap still set, causing a WARN_ON(mem->altmap). This was triggered by modifying virtio-mem driver. Fix this by delaying the assignment of mem->altmap until after __add_memory_block() has succeeded. Link: https://lore.kernel.org/20260514092657.3057141-1-georgi.djakov@oss.qualcomm.com Fixes: 1a8c64e11043 ("mm/memory_hotplug: embed vmem_altmap details in memory block") Signed-off-by: Georgi Djakov Acked-by: Oscar Salvador (SUSE) Cc: Vishal Verma Cc: Mike Rapoport Cc: Richard Cheng Cc: David Hildenbrand Cc: Georgi Djakov Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 50b72074c5e8d6fe7d8c39c71277dba6d3ac225c Author: Viken Dadhaniya Date: Thu May 28 22:48:07 2026 +0530 serial: qcom_geni: Fix RX DMA stall when SE_DMA_RX_LEN_IN is zero commit b93062b6d8a1b2d9bad235cac25558a909819026 upstream. In qcom_geni_serial_handle_rx_dma(), geni_se_rx_dma_unprep() clears port->rx_dma_addr before SE_DMA_RX_LEN_IN is read. If the register is zero, for example when the RX stale counter fires on an idle line, the handler returns without calling geni_se_rx_dma_prep(). The next RX DMA interrupt then hits the !port->rx_dma_addr guard and returns immediately, so the RX DMA buffer is never rearmed and later input is lost. Keep the handler on the rearm path when rx_in is zero. Warn about the unexpected zero-length DMA completion, skip received-data handling, and always call geni_se_rx_dma_prep(). Fixes: 2aaa43c70778 ("tty: serial: qcom-geni-serial: add support for serial engine DMA") Cc: stable@vger.kernel.org Reviewed-by: Bartosz Golaszewski Signed-off-by: Viken Dadhaniya Link: https://patch.msgid.link/20260528-serial-rx-0-byte-fix-v2-1-b4195cfe342f@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit 7cc3dd79777f6ae4625ec37e84dd18a26dc88bde Author: Yi Yang Date: Thu Jun 4 06:07:34 2026 +0000 vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write commit a287620312dc6dcb9a093417a0e589bf30fcf38a upstream. A KASAN null-ptr-deref was observed in vcs_notifier(): BUG: KASAN: null-ptr-deref in vcs_notifier+0x98/0x130 Read of size 2 at addr qmp_cmd_name: qmp_capabilities, arguments: {} The issue is a race condition in vcs_write(). When the console_lock is temporarily dropped (to copy data from userspace), the vc_data pointer obtained from vcs_vc() may become stale. After re-acquiring the lock, vcs_vc() is called again to re-validate the pointer. If the vc has been deallocated in the meantime, vcs_vc() returns NULL, and the while loop breaks (with written > 0). However, after the loop, vcs_scr_updated(vc) is still called with the now-NULL vc pointer, leading to a null pointer dereference in the notifier chain (vcs_notifier dereferences param->vc). Fix this by adding a NULL check for vc before calling vcs_scr_updated(). Fixes: 8fb9ea65c9d1 ("vc_screen: reload load of struct vc_data pointer in vcs_write() to avoid UAF") Cc: stable@vger.kernel.org Signed-off-by: Yi Yang Reviewed-by: Jiri Slaby Link: https://patch.msgid.link/20260604060734.2914976-1-yiyang13@huawei.com Signed-off-by: Greg Kroah-Hartman commit b8ebf008696de1ec08c90d51f94d7e40bd448be1 Author: Giovanni Cabiddu Date: Mon May 11 11:04:08 2026 +0100 crypto: qat - remove unused character device and IOCTLs commit d237230728c567297f2f98b425d63156ab2ed17f upstream. The QAT driver exposes a character device (qat_adf_ctl) with IOCTLs for device configuration, start, stop, status query and enumeration. These IOCTLs are not part of any public uAPI header and have no known in-tree or out-of-tree users. Device lifecycle is already managed via sysfs. The ioctl interface also increases the attack surface and is the subject of a number of bug reports. Remove the character device, the IOCTL definitions, and the related data structures (adf_dev_status_info, adf_user_cfg_key_val, adf_user_cfg_section, adf_user_cfg_ctl_data). Drop the now-unused adf_cfg_user.h header and strip adf_ctl_drv.c down to the minimal module_init/module_exit hooks for workqueue, AER, and crypto/compression algorithm registration. Clean up leftover dead code that was only reachable from the removed IOCTL paths: adf_cfg_del_all(), adf_devmgr_verify_id(), adf_devmgr_get_num_dev(), adf_devmgr_get_dev_by_id(), adf_get_vf_real_id() and the unused ADF_CFG macros. Additionally, drop the entry associated to QAT IOCTLs in ioctl-number.rst. Cc: stable@vger.kernel.org Fixes: d8cba25d2c68 ("crypto: qat - Intel(R) QAT driver framework") Reported-by: Zhi Wang Reported-by: Bin Yu Reported-by: MingYu Wang Closes: https://lore.kernel.org/all/61d6d499.ab89.19b9b7f3186.Coremail.wangzhi_xd@stu.xidian.edu.cn/ Link: https://lore.kernel.org/all/20260508034841.256794-1-w15303746062@163.com/ Link: https://lore.kernel.org/all/20260508023542.256299-1-w15303746062@163.com/ Link: https://lore.kernel.org/all/20260504025120.98242-1-w15303746062@163.com/ Signed-off-by: Giovanni Cabiddu Reviewed-by: Ahsan Atta Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit d08d82d83ed45fd8c001a9df66ad7ebb86c9d6c6 Author: Sam Daly Date: Thu May 14 18:23:20 2026 +0200 iio: adc: ti-ads1298: add bounds check to pga_settings index commit 95e8a48d7a85d4226934020e57815a3316d3a14b upstream. ads1298_pga_settings has 7 elements but ADS1298_MASK_CH_PGA can yield values 0-7. If it yields a value >= 7, this causes an out-of-bounds array access. Add a bounds check and return -EINVAL if the index is out of range. Note that the remaining value b111 is reserved so should not be seen in a correctly functioning system. Assisted-by: gkh_clanker_2000 Cc: stable Cc: Jonathan Cameron Cc: David Lechner Cc: "Nuno Sá" Cc: Andy Shevchenko Signed-off-by: Sam Daly Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 0a89002737ee34decc20fa232204dbe5fe83e0de Author: Sam Daly Date: Thu May 14 18:23:21 2026 +0200 iio: light: veml6075: add bounds check to veml6075_it_ms index commit 307dc4240bd41852d9e0912921e298160db1c109 upstream. veml6075_it_ms has 5 elements but VEML6075_CONF_IT can yield values 0-7. If it returns a value >= 5, this causes an out-of-bounds array access. Add a bounds check and return -EINVAL if the index is out of range. The problem values are reserved so should never be read from the register. Hence this is hardening against fault device, missprogramming or bus corruption. Assisted-by: gkh_clanker_2000 Cc: stable Signed-off-by: Sam Daly Signed-off-by: Greg Kroah-Hartman Reviewed-by: Javier Carrasco Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 76db05493184641855d3236e694fb5e455d18d0f Author: Faicker Mo Date: Mon May 11 22:05:51 2026 +0800 net: net_failover: Fix the deadlock in slave register commit b84c5632c7b31f8910167075a8128cfb9e50fcfe upstream. There is netdev_lock_ops() before the NETDEV_REGISTER notifier in register_netdevice(), so use the non-locking functions in net_failover_slave_register(). failover_slave_register() in failover_existing_slave_register() adds lock and unlock ops too. Call Trace: __schedule+0x30d/0x7a0 schedule+0x27/0x90 schedule_preempt_disabled+0x15/0x30 __mutex_lock.constprop.0+0x538/0x9e0 __mutex_lock_slowpath+0x13/0x20 mutex_lock+0x3b/0x50 dev_set_mtu+0x40/0xe0 net_failover_slave_register+0x24/0x280 failover_slave_register+0x103/0x1b0 failover_event+0x15e/0x210 ? dropmon_net_event+0xac/0xe0 notifier_call_chain+0x5e/0xe0 raw_notifier_call_chain+0x16/0x30 call_netdevice_notifiers_info+0x52/0xa0 register_netdevice+0x5f4/0x7c0 register_netdev+0x1e/0x40 _mlx5e_probe+0xe2/0x370 [mlx5_core] mlx5e_probe+0x59/0x70 [mlx5_core] ? __pfx_mlx5e_probe+0x10/0x10 [mlx5_core] Fixes: 4c975fd70002 ("net: hold instance lock during NETDEV_REGISTER/UP") Signed-off-by: Faicker Mo Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c5b3871b567c24642c3a0408794c29783e986207 Author: Mike Marciniszyn (Meta) Date: Sat Mar 7 05:58:43 2026 -0500 net: export netif_open for self_test usage commit 3fdd33697c2be9184668c89ba4f24a5ecbc8ec51 upstream. dev_open() already is exported, but drivers which use the netdev instance lock need to use netif_open() instead. netif_close() is also already exported [1] so this completes the pairing. This export is required for the following fbnic self tests to avoid calling ndo_stop() and ndo_open() in favor of the more appropriate netif_open() and netif_close() that notifies any listeners that the interface went down to test and is now coming back up. Link: https://patch.msgid.link/20250309215851.2003708-1-sdf@fomichev.me [1] Signed-off-by: Mike Marciniszyn (Meta) Link: https://patch.msgid.link/20260307105847.1438-2-mike.marciniszyn@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit cc1494fd6c65de588d6478811ffc05445ee81ee8 Author: Lorenzo Stoakes Date: Fri May 15 15:42:19 2026 +0300 testing/selftests/mm: add soft-dirty merge self-test commit c7ba92bcfea34f6b4afc744c3b65c8f7420fefe0 upstream. Assert that we correctly merge VMAs containing VM_SOFTDIRTY flags now that we correctly handle these as sticky. In order to do so, we have to account for the fact the pagemap interface checks soft dirty PTEs and additionally that newly merged VMAs are marked VM_SOFTDIRTY. We do this by using use unfaulted anon VMAs, establishing one and clearing references on that one, before establishing another and merging the two before checking that soft-dirty is propagated as expected. We check that this functions correctly with mremap() and mprotect() as sample cases, because VMA merge of adjacent newly mapped VMAs will automatically be made soft-dirty due to existing logic which does so. We are therefore exercising other means of merging VMAs. Link: https://lkml.kernel.org/r/d5a0f735783fb4f30a604f570ede02ccc5e29be9.1763399675.git.ljs@kernel.org Signed-off-by: Lorenzo Stoakes Cc: Andrey Vagin Cc: David Hildenbrand (Red Hat) Cc: Jann Horn Cc: Liam Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Pedro Falcato Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Cyrill Gorcunov Signed-off-by: Andrew Morton Signed-off-by: Ahmed Elaidy Signed-off-by: Greg Kroah-Hartman commit f563ce913a8315bd722c1540a8743a0d12d95d4d Author: Lorenzo Stoakes Date: Fri May 15 15:42:18 2026 +0300 mm: propagate VM_SOFTDIRTY on merge commit 6707915e030a3258868355f989b80140c1a45bbe upstream. Patch series "make VM_SOFTDIRTY a sticky VMA flag", v2. Currently we set VM_SOFTDIRTY when a new mapping is set up (whether by establishing a new VMA, or via merge) as implemented in __mmap_complete() and do_brk_flags(). However, when performing a merge of existing mappings such as when performing mprotect(), we may lose the VM_SOFTDIRTY flag. Now we have the concept of making VMA flags 'sticky', that is that they both don't prevent merge and, importantly, are propagated to merged VMAs, this seems a sensible alternative to the existing special-casing of VM_SOFTDIRTY. We additionally add a self-test that demonstrates that this logic behaves as expected. This patch (of 2): Currently we set VM_SOFTDIRTY when a new mapping is set up (whether by establishing a new VMA, or via merge) as implemented in __mmap_complete() and do_brk_flags(). However, when performing a merge of existing mappings such as when performing mprotect(), we may lose the VM_SOFTDIRTY flag. This is because currently we simply ignore VM_SOFTDIRTY for the purposes of merge, so one VMA may possess the flag and another not, and whichever happens to be the target VMA will be the one upon which the merge is performed which may or may not have VM_SOFTDIRTY set. Now we have the concept of 'sticky' VMA flags, let's make VM_SOFTDIRTY one which solves this issue. Additionally update VMA userland tests to propagate changes. [akpm@linux-foundation.org: update comments, per Lorenzo] Link: https://lkml.kernel.org/r/0019e0b8-ee1e-4359-b5ee-94225cbe5588@lucifer.local Link: https://lkml.kernel.org/r/cover.1763399675.git.ljs@kernel.org Link: https://lkml.kernel.org/r/955478b5170715c895d1ef3b7f68e0cd77f76868.1763399675.git.ljs@kernel.org Signed-off-by: Lorenzo Stoakes Suggested-by: Vlastimil Babka Acked-by: David Hildenbrand (Red Hat) Reviewed-by: Pedro Falcato Acked-by: Andrey Vagin Reviewed-by: Vlastimil Babka Acked-by: Cyrill Gorcunov Cc: Jann Horn Cc: Liam Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Signed-off-by: Andrew Morton Signed-off-by: Ahmed Elaidy Fixes: 34228d473efe ("mm: ignore VM_SOFTDIRTY on VMA merging") Signed-off-by: Greg Kroah-Hartman commit b836839c1fd94f9fc7ccdce153844fa26116ccc0 Author: Lorenzo Stoakes Date: Fri May 15 15:42:16 2026 +0300 mm: set the VM_MAYBE_GUARD flag on guard region install commit 49e14dabed7a294427588d4b315f57fbfcab9990 upstream. Now we have established the VM_MAYBE_GUARD flag and added the capacity to set it atomically, do so upon MADV_GUARD_INSTALL. The places where this flag is used currently and matter are: * VMA merge - performed under mmap/VMA write lock, therefore excluding racing writes. * /proc/$pid/smaps - can race the write, however this isn't meaningful as the flag write is performed at the point of the guard region being established, and thus an smaps reader can't reasonably expect to avoid races. Due to atomicity, a reader will observe either the flag being set or not. Therefore consistency will be maintained. In all other cases the flag being set is irrelevant and atomicity guarantees other flags will be read correctly. Note that non-atomic updates of unrelated flags do not cause an issue with this flag being set atomically, as writes of other flags are performed under mmap/VMA write lock, and these atomic writes are performed under mmap/VMA read lock, which excludes the write, avoiding RMW races. Note that we do not encounter issues with KCSAN by adjusting this flag atomically, as we are only updating a single bit in the flag bitmap and therefore we do not need to annotate these changes. We intentionally set this flag in advance of actually updating the page tables, to ensure that any racing atomic read of this flag will only return false prior to page tables being updated, to allow for serialisation via page table locks. Note that we set vma->anon_vma for anonymous mappings. This is because the expectation for anonymous mappings is that an anon_vma is established should they possess any page table mappings. This is also consistent with what we were doing prior to this patch (unconditionally setting anon_vma on guard region installation). We also need to update retract_page_tables() to ensure that madvise(..., MADV_COLLAPSE) doesn't incorrectly collapse file-backed ranges contain guard regions. This was previously guarded by anon_vma being set to catch MAP_PRIVATE cases, but the introduction of VM_MAYBE_GUARD necessitates that we check this flag instead. We utilise vma_flag_test_atomic() to do so - we first perform an optimistic check, then after the PTE page table lock is held, we can check again safely, as upon guard marker install the flag is set atomically prior to the page table lock being taken to actually apply it. So if the initial check fails either: * Page table retraction acquires page table lock prior to VM_MAYBE_GUARD being set - guard marker installation will be blocked until page table retraction is complete. OR: * Guard marker installation acquires page table lock after setting VM_MAYBE_GUARD, which raced and didn't pick this up in the initial optimistic check, blocking page table retraction until the guard regions are installed - the second VM_MAYBE_GUARD check will prevent page table retraction. Either way we're safe. We refactor the retraction checks into a single file_backed_vma_is_retractable(), there doesn't seem to be any reason that the checks were separated as before. Note that VM_MAYBE_GUARD being set atomically remains correct as vma_needs_copy() is invoked with the mmap and VMA write locks held, excluding any race with madvise_guard_install(). Link: https://lkml.kernel.org/r/e9e9ce95b6ac17497de7f60fc110c7dd9e489e8d.1763460113.git.ljs@kernel.org Signed-off-by: Lorenzo Stoakes Reviewed-by: Vlastimil Babka Cc: Andrei Vagin Cc: Baolin Wang Cc: Barry Song Cc: David Hildenbrand (Red Hat) Cc: Dev Jain Cc: Jann Horn Cc: Jonathan Corbet Cc: Lance Yang Cc: Liam Howlett Cc: "Masami Hiramatsu (Google)" Cc: Mathieu Desnoyers Cc: Michal Hocko Cc: Mike Rapoport Cc: Nico Pache Cc: Pedro Falcato Cc: Ryan Roberts Cc: Steven Rostedt Cc: Suren Baghdasaryan Cc: Zi Yan Signed-off-by: Andrew Morton Signed-off-by: Ahmed Elaidy Signed-off-by: Greg Kroah-Hartman commit 3d6cb2ed06f7f3c7b3d05a7d77e4b2c4a3dd930b Author: Lorenzo Stoakes Date: Fri May 15 15:42:15 2026 +0300 mm: introduce copy-on-fork VMAs and make VM_MAYBE_GUARD one commit ab04b530e7e8bd5cf9fb0c1ad20e0deee8f569ec upstream. Gather all the VMA flags whose presence implies that page tables must be copied on fork into a single bitmap - VM_COPY_ON_FORK - and use this rather than specifying individual flags in vma_needs_copy(). We also add VM_MAYBE_GUARD to this list, as it being set on a VMA implies that there may be metadata contained in the page tables (that is - guard markers) which would will not and cannot be propagated upon fork. This was already being done manually previously in vma_needs_copy(), but this makes it very explicit, alongside VM_PFNMAP, VM_MIXEDMAP and VM_UFFD_WP all of which imply the same. Note that VM_STICKY flags ought generally to be marked VM_COPY_ON_FORK too - because equally a flag being VM_STICKY indicates that the VMA contains metadat that is not propagated by being faulted in - i.e. that the VMA metadata does not fully describe the VMA alone, and thus we must propagate whatever metadata there is on a fork. However, for maximum flexibility, we do not make this necessarily the case here. Link: https://lkml.kernel.org/r/5d41b24e7bc622cda0af92b6d558d7f4c0d1bc8c.1763460113.git.ljs@kernel.org Signed-off-by: Lorenzo Stoakes Reviewed-by: Pedro Falcato Reviewed-by: Vlastimil Babka Acked-by: David Hildenbrand (Red Hat) Cc: Andrei Vagin Cc: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Jann Horn Cc: Jonathan Corbet Cc: Lance Yang Cc: Liam Howlett Cc: "Masami Hiramatsu (Google)" Cc: Mathieu Desnoyers Cc: Michal Hocko Cc: Mike Rapoport Cc: Nico Pache Cc: Ryan Roberts Cc: Steven Rostedt Cc: Suren Baghdasaryan Cc: Zi Yan Signed-off-by: Andrew Morton Signed-off-by: Ahmed Elaidy Signed-off-by: Greg Kroah-Hartman commit 05cdec24a858967c7dc768f6b66a71f61f5ed1ee Author: Lorenzo Stoakes Date: Fri May 15 15:42:14 2026 +0300 mm: implement sticky VMA flags commit 64212ba02e66e705cabce188453ba4e61e9d7325 upstream. It is useful to be able to designate that certain flags are 'sticky', that is, if two VMAs are merged one with a flag of this nature and one without, the merged VMA sets this flag. As a result we ignore these flags for the purposes of determining VMA flag differences between VMAs being considered for merge. This patch therefore updates the VMA merge logic to perform this action, with flags possessing this property being described in the VM_STICKY bitmap. Those flags which ought to be ignored for the purposes of VMA merge are described in the VM_IGNORE_MERGE bitmap, which the VMA merge logic is also updated to use. As part of this change we place VM_SOFTDIRTY in VM_IGNORE_MERGE as it already had this behaviour, alongside VM_STICKY as sticky flags by implication must not disallow merge. Ultimately it seems that we should make VM_SOFTDIRTY a sticky flag in its own right, but this change is out of scope for this series. The only sticky flag designated as such is VM_MAYBE_GUARD, so as a result of this change, once the VMA flag is set upon guard region installation, VMAs with guard ranges will now not have their merge behaviour impacted as a result and can be freely merged with other VMAs without VM_MAYBE_GUARD set. Also update the comments for vma_modify_flags() to directly reference sticky flags now we have established the concept. We also update the VMA userland tests to account for the changes. Link: https://lkml.kernel.org/r/22ad5269f7669d62afb42ce0c79bad70b994c58d.1763460113.git.ljs@kernel.org Signed-off-by: Lorenzo Stoakes Reviewed-by: Pedro Falcato Reviewed-by: Vlastimil Babka Cc: Andrei Vagin Cc: Baolin Wang Cc: Barry Song Cc: David Hildenbrand (Red Hat) Cc: Dev Jain Cc: Jann Horn Cc: Jonathan Corbet Cc: Lance Yang Cc: Liam Howlett Cc: "Masami Hiramatsu (Google)" Cc: Mathieu Desnoyers Cc: Michal Hocko Cc: Mike Rapoport Cc: Nico Pache Cc: Ryan Roberts Cc: Steven Rostedt Cc: Suren Baghdasaryan Cc: Zi Yan Signed-off-by: Andrew Morton Signed-off-by: Ahmed Elaidy Signed-off-by: Greg Kroah-Hartman commit a093c80a1f139425c7cf186b91e5ed5c7b27d98e Author: Lorenzo Stoakes Date: Fri May 15 15:42:13 2026 +0300 mm: update vma_modify_flags() to handle residual flags, document commit 9119d6c2095bb20292cb9812dd70d37f17e3bd37 upstream. The vma_modify_*() family of functions each either perform splits, a merge or no changes at all in preparation for the requested modification to occur. When doing so for a VMA flags change, we currently don't account for any flags which may remain (for instance, VM_SOFTDIRTY) despite the requested change in the case that a merge succeeded. This is made more important by subsequent patches which will introduce the concept of sticky VMA flags which rely on this behaviour. This patch fixes this by passing the VMA flags parameter as a pointer and updating it accordingly on merge and updating callers to accommodate for this. Additionally, while we are here, we add kdocs for each of the vma_modify_*() functions, as the fact that the requested modification is not performed is confusing so it is useful to make this abundantly clear. We also update the VMA userland tests to account for this change. Link: https://lkml.kernel.org/r/23b5b549b0eaefb2922625626e58c2a352f3e93c.1763460113.git.ljs@kernel.org Signed-off-by: Lorenzo Stoakes Reviewed-by: Pedro Falcato Reviewed-by: Vlastimil Babka Cc: Andrei Vagin Cc: Baolin Wang Cc: Barry Song Cc: David Hildenbrand (Red Hat) Cc: Dev Jain Cc: Jann Horn Cc: Jonathan Corbet Cc: Lance Yang Cc: Liam Howlett Cc: "Masami Hiramatsu (Google)" Cc: Mathieu Desnoyers Cc: Michal Hocko Cc: Mike Rapoport Cc: Nico Pache Cc: Ryan Roberts Cc: Steven Rostedt Cc: Suren Baghdasaryan Cc: Zi Yan Signed-off-by: Andrew Morton Signed-off-by: Ahmed Elaidy Signed-off-by: Greg Kroah-Hartman commit bdeadba743375699b580dff218611d50dab07ba8 Author: Lorenzo Stoakes Date: Fri May 15 15:42:12 2026 +0300 mm: add atomic VMA flags and set VM_MAYBE_GUARD as such commit 568822502383acd57d7cc1c72ee43932c45a9524 upstream. This patch adds the ability to atomically set VMA flags with only the mmap read/VMA read lock held. As this could be hugely problematic for VMA flags in general given that all other accesses are non-atomic and serialised by the mmap/VMA locks, we implement this with a strict allow-list - that is, only designated flags are allowed to do this. We make VM_MAYBE_GUARD one of these flags. Link: https://lkml.kernel.org/r/97e57abed09f2663077ed7a36fb8206e243171a9.1763460113.git.ljs@kernel.org Signed-off-by: Lorenzo Stoakes Reviewed-by: Pedro Falcato Reviewed-by: Vlastimil Babka Acked-by: David Hildenbrand (Red Hat) Reviewed-by: Lance Yang Cc: Andrei Vagin Cc: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Jann Horn Cc: Jonathan Corbet Cc: Liam Howlett Cc: "Masami Hiramatsu (Google)" Cc: Mathieu Desnoyers Cc: Michal Hocko Cc: Mike Rapoport Cc: Nico Pache Cc: Ryan Roberts Cc: Steven Rostedt Cc: Suren Baghdasaryan Cc: Zi Yan Signed-off-by: Andrew Morton Signed-off-by: Ahmed Elaidy Signed-off-by: Greg Kroah-Hartman commit efce8a486bffcbad9897b059f05a01b8f25197ea Author: Lorenzo Stoakes Date: Fri May 15 15:42:11 2026 +0300 mm: introduce VM_MAYBE_GUARD and make visible in /proc/$pid/smaps commit 5dba5cc2e0ffa76f2f6c8922a04469dc9602c396 upstream. Patch series "introduce VM_MAYBE_GUARD and make it sticky", v4. Currently, guard regions are not visible to users except through /proc/$pid/pagemap, with no explicit visibility at the VMA level. This makes the feature less useful, as it isn't entirely apparent which VMAs may have these entries present, especially when performing actions which walk through memory regions such as those performed by CRIU. This series addresses this issue by introducing the VM_MAYBE_GUARD flag which fulfils this role, updating the smaps logic to display an entry for these. The semantics of this flag are that a guard region MAY be present if set (we cannot be sure, as we can't efficiently track whether an MADV_GUARD_REMOVE finally removes all the guard regions in a VMA) - but if not set the VMA definitely does NOT have any guard regions present. It's problematic to establish this flag without further action, because that means that VMAs with guard regions in them become non-mergeable with adjacent VMAs for no especially good reason. To work around this, this series also introduces the concept of 'sticky' VMA flags - that is flags which: a. if set in one VMA and not in another still permit those VMAs to be merged (if otherwise compatible). b. When they are merged, the resultant VMA must have the flag set. The VMA logic is updated to propagate these flags correctly. Additionally, VM_MAYBE_GUARD being an explicit VMA flag allows us to solve an issue with file-backed guard regions - previously these established an anon_vma object for file-backed mappings solely to have vma_needs_copy() correctly propagate guard region mappings to child processes. We introduce a new flag alias VM_COPY_ON_FORK (which currently only specifies VM_MAYBE_GUARD) and update vma_needs_copy() to check explicitly for this flag and to copy page tables if it is present, which resolves this issue. Additionally, we add the ability for allow-listed VMA flags to be atomically writable with only mmap/VMA read locks held. The only flag we allow so far is VM_MAYBE_GUARD, which we carefully ensure does not cause any races by being allowed to do so. This allows us to maintain guard region installation as a read-locked operation and not endure the overhead of obtaining a write lock here. Finally we introduce extensive VMA userland tests to assert that the sticky VMA logic behaves correctly as well as guard region self tests to assert that smaps visibility is correctly implemented. This patch (of 9): Currently, if a user needs to determine if guard regions are present in a range, they have to scan all VMAs (or have knowledge of which ones might have guard regions). Since commit 8e2f2aeb8b48 ("fs/proc/task_mmu: add guard region bit to pagemap") and the related commit a516403787e0 ("fs/proc: extend the PAGEMAP_SCAN ioctl to report guard regions"), users can use either /proc/$pid/pagemap or the PAGEMAP_SCAN functionality to perform this operation at a virtual address level. This is not ideal, and it gives no visibility at a /proc/$pid/smaps level that guard regions exist in ranges. This patch remedies the situation by establishing a new VMA flag, VM_MAYBE_GUARD, to indicate that a VMA may contain guard regions (it is uncertain because we cannot reasonably determine whether a MADV_GUARD_REMOVE call has removed all of the guard regions in a VMA, and additionally VMAs may change across merge/split). We utilise 0x800 for this flag which makes it available to 32-bit architectures also, a flag that was previously used by VM_DENYWRITE, which was removed in commit 8d0920bde5eb ("mm: remove VM_DENYWRITE") and hasn't bee reused yet. We also update the smaps logic and documentation to identify these VMAs. Another major use of this functionality is that we can use it to identify that we ought to copy page tables on fork. We do not actually implement usage of this flag in mm/madvise.c yet as we need to allow some VMA flags to be applied atomically under mmap/VMA read lock in order to avoid the need to acquire a write lock for this purpose. Link: https://lkml.kernel.org/r/cover.1763460113.git.ljs@kernel.org Link: https://lkml.kernel.org/r/cf8ef821eba29b6c5b5e138fffe95d6dcabdedb9.1763460113.git.ljs@kernel.org Signed-off-by: Lorenzo Stoakes Reviewed-by: Pedro Falcato Reviewed-by: Vlastimil Babka Acked-by: David Hildenbrand (Red Hat) Reviewed-by: Lance Yang Cc: Andrei Vagin Cc: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Jann Horn Cc: Jonathan Corbet Cc: Liam Howlett Cc: "Masami Hiramatsu (Google)" Cc: Mathieu Desnoyers Cc: Michal Hocko Cc: Mike Rapoport Cc: Nico Pache Cc: Ryan Roberts Cc: Steven Rostedt Cc: Suren Baghdasaryan Cc: Zi Yan Signed-off-by: Andrew Morton Signed-off-by: Ahmed Elaidy Signed-off-by: Greg Kroah-Hartman commit 0de7db2eb27e82b983157016fa604b1ba664ae5f Author: Xin Long Date: Thu Jun 25 10:43:46 2026 +0300 sctp: disable BH before calling udp_tunnel_xmit_skb() commit 2cd7e6971fc2787408ceef17906ea152791448cf upstream. udp_tunnel_xmit_skb() / udp_tunnel6_xmit_skb() are expected to run with BH disabled. After commit 6f1a9140ecda ("add xmit recursion limit to tunnel xmit functions"), on the path: udp(6)_tunnel_xmit_skb() -> ip(6)tunnel_xmit() dev_xmit_recursion_inc()/dec() must stay balanced on the same CPU. Without local_bh_disable(), the context may move between CPUs, which can break the inc/dec pairing. This may lead to incorrect recursion level detection and cause packets to be dropped in ip(6)_tunnel_xmit() or __dev_queue_xmit(). Fix it by disabling BH around both IPv4 and IPv6 SCTP UDP xmit paths. In my testing, after enabling the SCTP over UDP: # ip net exec ha sysctl -w net.sctp.udp_port=9899 # ip net exec ha sysctl -w net.sctp.encap_port=9899 # ip net exec hb sysctl -w net.sctp.udp_port=9899 # ip net exec hb sysctl -w net.sctp.encap_port=9899 # ip net exec ha iperf3 -s - without this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 37.2 MBytes 31.2 Mbits/sec sender [ 5] 0.00-10.00 sec 37.1 MBytes 31.1 Mbits/sec receiver - with this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec sender [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec receiver Fixes: 6f1a9140ecda ("net: add xmit recursion limit to tunnel xmit functions") Fixes: 046c052b475e ("sctp: enable udp tunneling socks") Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner Link: https://patch.msgid.link/c874a8548221dcd56ff03c65ba75a74e6cf99119.1776017727.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Alexander Martyniuk Signed-off-by: Greg Kroah-Hartman commit eee6be6ab63755f7847ce22288f7d722fda419d1 Author: Tudor Ambarus Date: Tue Jun 16 21:47:19 2026 -0400 firmware: samsung: acpm: Fix cross-thread RX length corruption [ Upstream commit f133bd4b5daf71bccdde0ad1a4f47fac76a6bfb1 ] Sashiko identified a cross-thread RX length corruption bug when reviewing the thermal addition to ACPM [1]. When multiple threads concurrently send IPC requests, the ACPM polling mechanism can encounter responses belonging to other threads. To drain the queue, the driver saves these concurrent responses into an internal cache (`rx_data->cmd`) to be retrieved later by the owning thread. Previously, the driver incorrectly used `xfer->rxcnt` (the expected receive length of the *current* polling thread) when copying data for *other* threads into this cache. If the threads expected responses of different lengths, this resulted in buffer underflows (leading to reads of uninitialized memory) or potential buffer overflows. Fix this by replacing the boolean `response` flag in `struct acpm_rx_data` with `rxcnt`, caching the exact expected receive length for each specific transaction during transfer preparation. Use this cached length when saving concurrent responses. Consequently, ensure that `xfer->rxcnt` is explicitly zeroed in driver helpers (e.g., `acpm_dvfs_set_xfer`) for fire-and-forget messages to prevent uninitialized stack garbage from being interpreted as a massive expected receive length. Cc: stable@vger.kernel.org Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver") Closes: https://sashiko.dev/#/patchset/20260420-acpm-tmu-v3-0-3dc8e93f0b26%40linaro.org [1] Reported-by: Titouan Ameline de Cadeville Closes: https://lore.kernel.org/r/20260426210255.73674-1-titouan.ameline@gmail.com/ Signed-off-by: Tudor Ambarus Link: https://patch.msgid.link/20260505-acpm-fixes-sashiko-reports-v5-1-43b5ee7f1674@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 02ac3ba41628ab0c454b7d05b4bc20c011b32783 Author: Dexuan Cui Date: Tue Jun 16 12:56:09 2026 -0400 Drivers: hv: vmbus: Improve the logic of reserving fb_mmio on Gen2 VMs [ Upstream commit 016a25e4b0df4d77e7c258edee4aaf982e4ee809 ] If vmbus_reserve_fb() in the kdump/kexec kernel fails to properly reserve the framebuffer MMIO range (which is below 4GB) due to a Gen2 VM's screen.lfb_base being zero [1], there is an MMIO conflict between the drivers hyperv-drm and pci-hyperv: when the driver pci-hyperv's hv_allocate_config_window() calls vmbus_allocate_mmio() to get an MMIO range, typically it gets a 32-bit MMIO range that overlaps with the framebuffer MMIO range, and later hv_pci_enter_d0() fails with an error message "PCI Pass-through VSP failed D0 Entry with status" since the host thinks that PCI devices must not use MMIO space that the host has assigned to the framebuffer. This is especially an issue if pci-hyperv is built-in and hyperv-drm is built as a module. Consequently, the kdump/kexec kernel fails to detect PCI devices via pci-hyperv, and may fail to mount the root file system, which may reside in a NVMe disk. The issue described here has existed for SR-IOV VF NICs since day one of the pci-hyperv driver, and has been worked around on x64 when possible. With the recent introduction of ARM64 VMs that boot from NVMe, there is no workaround, so we need a formal fix. On Gen2 VMs, if the screen.lfb_base is 0 in the kdump/kexec kernel [1], fall back to the low MMIO base, which should be equal to the framebuffer MMIO base [2] (the statement is true according to my testing on x64 Windows Server 2016, and on x64 and ARM64 Windows Server 2025 and on Azure. I checked with the Hyper-V team and they said the statement should continue to be true for Gen2 VMs). In the first kernel, screen.lfb_base is not 0; if the user specifies a very high resolution, it's not enough to only reserve 8MB: let's always reserve half of the space below 4GB, but cap the reservation to 128MB, which is the required framebuffer size of the highest resolution 7680*4320 supported by Hyper-V. While at it, fix the comparison "end > VTPM_BASE_ADDRESS" by changing the > to >=. Here the 'end' is an inclusive end (typically, it's 0xFFFF_FFFF for the low MMIO range). Note: vmbus_reserve_fb() now also reserves an MMIO range at the beginning of the low MMIO range on CVMs, which have no framebuffers (the 'screen.lfb_base' in vmbus_reserve_fb() is 0 for CVMs), just in case the host might treat the beginning of the low MMIO range specially [3]. BTW, the OpenHCL kernel is not affected by the change, because that kernel boots with DeviceTree rather than ACPI (so vmbus_reserve_fb() won't run there), and there is no framebuffer device for that kernel. Note: normally Gen1 VMs don't have the MMIO conflict issue because the framebuffer MMIO range (which is hardcoded to base=4GB-128MB and size=64MB for Gen1 VMs by the host) is always reported via the legacy PCI graphics device's BAR, so the kdump/kexec kernel can reserve the 64MB MMIO range; however, if the VM is configured to use a very high resolution and the required framebuffer size exceeds 64MB (AFAIK, in practice, this isn't a typical configuration by users), the hyperv-drm driver may need to allocate an MMIO range above 4GB and change the framebuffer MMIO location to the allocated MMIO range -- in this case, there can still be issues [4] which can't be easily fixed: any possible affected Gen1 users would have to use a resolution whose framebuffer size is <= 64MB, or switch to Gen2 VMs. [1] https://lore.kernel.org/all/SA1PR21MB692176C1BC53BFC9EAE5CF8EBF51A@SA1PR21MB6921.namprd21.prod.outlook.com/ [2] https://lore.kernel.org/all/SA1PR21MB69218F955B62DFF62E3E88D2BF222@SA1PR21MB6921.namprd21.prod.outlook.com/ [3] https://lore.kernel.org/all/SN6PR02MB415726B17D5A6027CD1717E8D4342@SN6PR02MB4157.namprd02.prod.outlook.com/ [4] https://lore.kernel.org/all/SA1PR21MB69213486F821CA5A2C793C81BF342@SA1PR21MB6921.namprd21.prod.outlook.com/ Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs") CC: stable@vger.kernel.org Reviewed-by: Michael Kelley Tested-by: Krister Johansen Tested-by: Matthew Ruffell Signed-off-by: Dexuan Cui Signed-off-by: Wei Liu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 072bbd2846d1b7f1c9c95d10ae142b9b786a60e9 Author: Thorsten Blum Date: Tue Jun 16 12:55:57 2026 -0400 hv: utils: handle and propagate errors in kvp_register [ Upstream commit 3fcf923302a8f5c0dc3af3d2ca2657cb5fae4297 ] Make kvp_register() return an error code instead of silently ignoring failures, and propagate the error from kvp_handle_handshake() instead of returning success. This propagates both kzalloc_obj() and hvutil_transport_send() failures to kvp_handle_handshake() and thus to kvp_on_msg(). Fixes: 245ba56a52a3 ("Staging: hv: Implement key/value pair (KVP)") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Reviewed-by: Long Li Signed-off-by: Wei Liu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bde74af8d4466213007bdd42cc85fa72c861dea7 Author: André Draszik Date: Fri Jan 9 08:38:38 2026 +0000 regulator: core: fix locking in regulator_resolve_supply() error path commit 497330b203d2c59c5ff3fa4c34d14494d7203bc3 upstream. If late enabling of a supply regulator fails in regulator_resolve_supply(), the code currently triggers a lockdep warning: WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596 ... Call trace: _regulator_put+0x80/0xa0 (P) regulator_resolve_supply+0x7cc/0xbe0 regulator_register_resolve_supply+0x28/0xb8 as the regulator_list_mutex must be held when calling _regulator_put(). To solve this, simply switch to using regulator_put(). While at it, we should also make sure that no concurrent access happens to our rdev while we clear out the supply pointer. Add appropriate locking to ensure that. While the code in question will be removed altogether in a follow-up commit, I believe it is still beneficial to have this corrected before removal for future reference. Fixes: 36a1f1b6ddc6 ("regulator: core: Fix memory leak in regulator_resolve_supply()") Fixes: 8e5356a73604 ("regulator: core: Clear the supply pointer if enabling fails") Signed-off-by: André Draszik Link: https://patch.msgid.link/20260109-regulators-defer-v2-2-1a25dc968e60@linaro.org Signed-off-by: Mark Brown Signed-off-by: Nazar Kalashnikov Signed-off-by: Greg Kroah-Hartman commit 9477cbc5107a8dc31d54f199338449358621d569 Author: Bernard Pidoux Date: Sun May 31 15:41:45 2026 +0200 rose: don't free fd-owned sockets when reaping in the heartbeat commit 56576518920edd7b6c3479477d8d490fe2ebdaaa upstream. The heartbeat reaps orphaned ROSE sockets after their bound device goes down. A socket still attached to a struct socket (sk->sk_socket != NULL -- e.g. an incoming connection an fpad client has accepted and kept open) is owned by that userspace fd: rose_release() frees it on close(). Freeing it from the heartbeat left the fd dangling, so the eventual close() touched freed memory -- slab-use-after-free in rose_release(). Reap only sockets with sk->sk_socket == NULL (unaccepted incoming connections and post-close orphans). For an fd-owned socket whose device went down, disconnect it and fall through to the switch so close() does the teardown. Also release the neighbour reference held by orphaned incoming sockets before tearing them down. Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit 395b6573b389f44473b68285a36020a37a4025c2 Author: Bernard Pidoux Date: Sun May 31 15:41:45 2026 +0200 rose: clear neighbour pointer in rose_kill_by_device() commit 606e42d195b467480d4d405f8814c48d1651a76a upstream. rose_kill_by_device() drops the neighbour reference but leaves rose->neighbour pointing at it, unlike every other rose_neigh_put() site (see "rose: clear neighbour pointer after rose_neigh_put() in state machines"). The heartbeat STATE_0 reaping path then puts the same neighbour a second time, causing a rose_neigh refcount underflow and a use-after-free. Set rose->neighbour = NULL after the put, restoring the invariant. Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit 9e8fc2195f8b5a79af184a4dc3d22c84395a8ce9 Author: Bernard Pidoux Date: Sun May 31 15:41:45 2026 +0200 rose: cancel neighbour timers in rose_neigh_put() before freeing commit 9b222cb1d23ff210975e9df5ebab7b011acb6fad upstream. rose_neigh_put() kfree()s the neighbour but never cancels its ftimer and t0timer. Until now every caller that dropped the final reference first called rose_remove_neigh(), which deletes those timers. The socket heartbeat reaping path drops the last reference directly, so a neighbour could be freed with t0timer still armed -- it re-arms itself in rose_t0timer_expiry() -- leading to a use-after-free write in enqueue_timer(). Cancel both timers with timer_delete_sync() (the synchronous variant, to wait out a concurrently running, self-rearming handler) in the refcount-zero branch of rose_neigh_put(). Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit c31a0fa15a4b4c07130ca5bd1ac222b2541ab011 Author: Bernard Pidoux Date: Thu May 28 20:20:55 2026 +0200 rose: drop CALL_REQUEST in loopback timer when device is not running commit cf5567a2652e44866eae8987dff4c1ea507680df upstream. When ax25stop brings down rose0 while the loopback timer has pending CALL_REQUEST frames, rose_loopback_timer() calls rose_dev_get() and finds the device still registered (unregister_netdevice waits for refs to drop), then calls rose_rx_call_request() which takes a netdev_hold() for the new socket. But NETDEV_DOWN fires only once: rose_kill_by_device() already ran before this timer tick, so the new socket is never cleaned up. The stuck reference prevents unregister_netdevice from completing, and the orphan socket's timers eventually fire on freed memory (KASAN slab-use-after-free in __run_timers). The kernel clears IFF_UP via dev_close() before sending NETDEV_DOWN, so checking netif_running() after rose_dev_get() is sufficient: if the device is no longer running, the CALL_REQUEST is silently dropped and no socket is created. This closes the race without touching the module-exit path (which already stops the timer via loopback_stopping). Tested: unregister_netdevice completes immediately after ax25stop with active loopback connections; no ref_tracker warnings, no KASAN. Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit 74cbe94c913a4a3e069c0a82d8185586f0c37976 Author: Bernard Pidoux Date: Thu May 28 19:38:31 2026 +0200 rose: release netdev ref and destroy orphaned incoming sockets commit df12be096302d2c947388acc25764456c7f18cc1 upstream. Two related cleanup gaps left the module unremovable after a loopback session: 1. rose_destroy_socket() did not release the device reference. When an unaccepted incoming socket (created by rose_rx_call_request()) is destroyed via rose_heartbeat_expiry(), it is removed from rose_list before rose_kill_by_device() can find it, so the netdev_hold() taken in rose_rx_call_request() was never matched by netdev_put(). Add the release at the top of rose_destroy_socket() guarded by a NULL check so that rose_release() and rose_kill_by_device(), which already call netdev_put() and set device = NULL, are not affected. 2. rose_heartbeat_expiry() STATE_0 cleanup required TCP_LISTEN in addition to SOCK_DEAD. Unaccepted incoming sockets are TCP_ESTABLISHED, so the condition was never true and those sockets lingered forever, holding the module use count above zero and blocking rmmod. Drop the TCP_LISTEN restriction: any STATE_0 + SOCK_DEAD socket is orphaned and should be destroyed. Together with the earlier rose_make_new() double-hold fix these three patches allow clean rmmod after loopback sessions. Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit c794d35f73a7bc3d77224ccc6395c26f49f51752 Author: Bernard Pidoux Date: Thu May 28 19:11:55 2026 +0200 rose: fix netdev double-hold in rose_make_new() commit b9fb21ceb4f0d043767a1eba60786ec84809033b upstream. rose_make_new() copies orose->device from the listener socket and calls netdev_hold(), storing the tracker in rose->dev_tracker. The only caller, rose_rx_call_request(), then overwrites both make_rose->device and make_rose->dev_tracker with a fresh netdev_hold() for the actual incoming-call device. This orphans the tracker allocated by rose_make_new(): it remains in the device's refcount_tracker list but no pointer exists to free it via netdev_put(). The result is one spurious outstanding reference per accepted CALL_REQUEST, visible at rmmod time as: ref_tracker: netdev@X has 2/2 users at rose_rx_call_request+0xba3/0x1d50 [rose] rose_loopback_timer+0x3eb/0x670 [rose] The second entry is the orphaned tracker from rose_make_new(); the first is the correctly-managed socket reference from rose_rx_call_request(). Fix: initialise rose->device to NULL in rose_make_new() and let rose_rx_call_request() -- the sole caller -- assign the correct device and take the sole netdev_hold() as it already does. Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit ce27bcdd857a98c9069703a209cbe7fc4c2587ba Author: Bernard Pidoux Date: Thu May 28 17:38:18 2026 +0200 rose: disconnect orphaned STATE_2 sockets when device is gone commit d4f4cf9f09a3f5fafa8f09110a7c1b5d10f2f261 upstream. When ax25stop brings down ROSE interfaces, sockets in ROSE_STATE_2 (awaiting CLEAR CONFIRM) whose device pointer is already NULL are not reached by rose_kill_by_device() and wait for T3 (up to 180s) before self-cleaning via rose_timer_expiry(). This keeps the rose module usecount at 1, blocking rmmod for the full T3 duration. In rose_heartbeat_expiry(), detect ROSE_STATE_2 sockets with no device, cancel T3, release the neighbour reference, and call rose_disconnect() + sock_set_flag(SOCK_DESTROY). The next heartbeat tick (<=5s) then destroys the socket via the existing ROSE_STATE_0/SOCK_DESTROY path, allowing clean module unload within 10s instead of up to 180s. Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit ab849a6972c99e8a83ca92fbe463d782118e39f8 Author: Bernard Pidoux Date: Wed May 27 14:11:21 2026 +0200 rose: set SOCK_DESTROY in rose_kill_by_device() for prompt cleanup commit 741a4863ad570889c75f7a8e404567d8f3e46335 upstream. When rose_kill_by_device() is called (via NETDEV_DOWN on module exit or interface removal), it calls rose_disconnect() which transitions sockets to ROSE_STATE_0 and sets SOCK_DEAD. However, rose_heartbeat_expiry() only calls rose_destroy_socket() at ROSE_STATE_0 if SOCK_DESTROY is set -- the SOCK_DEAD path is reserved for TCP_LISTEN sockets. Without SOCK_DESTROY, orphaned sockets in ROSE_STATE_2 (clearing) loop indefinitely in the heartbeat without ever being freed, keeping the module use-count elevated and blocking modprobe -r rose until the T1 timer (up to 200 s) expires. Set SOCK_DESTROY immediately after rose_disconnect() so the heartbeat destroys the socket at its next tick (within 5 s), allowing clean module unload. Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit c98cc00c2d3b17d849e0ba806e5740c7e0b6b138 Author: Bernard Pidoux Date: Tue May 26 15:57:47 2026 +0200 rose: fix notifier unregistered too early in rose_exit() commit f71a8a1edc14dba746edde38adddd654ba202b4d upstream. rose_exit() called unregister_netdevice_notifier() before the loop that calls unregister_netdev() on each ROSE virtual device. As a result, the NETDEV_DOWN event fired by unregister_netdev() was never delivered to rose_device_event(), so rose_kill_by_device() never ran. Every socket whose rose->device pointed at a ROSE device therefore kept its netdev_tracker entry live until free_netdev() destroyed the ref_tracker_dir, at which point the kernel reported all of them as leaked references (165 entries in a typical FPAC setup). Worse, those sockets retained stale device pointers and live timers that could fire into freed module text after module unload, causing a silent system freeze with no kernel panic logged. Fix by moving unregister_netdevice_notifier() to after the device- unregistration loop. unregister_netdev() then delivers NETDEV_DOWN while the notifier is still registered, rose_kill_by_device() runs for each device, releases all netdev references held by open sockets, and calls rose_disconnect() which stops the per-socket timers. Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit 19139026dc1c0a958798fe7b1c26f4cd479b706e Author: Bernard Pidoux Date: Tue May 26 15:57:04 2026 +0200 rose: fix netdev double-hold in rose_rx_call_request() commit c675277c3ba0d2310e0825577d58308c39931e14 upstream. rose_rx_call_request() used netdev_tracker_alloc() after assigning make_rose->device, intending to take ownership of the reference passed by the caller. But every caller -- rose_route_frame() and rose_loopback_timer() -- already calls dev_put() for its own hold after the function returns, so the socket ended up with a tracker entry pointing at a reference that had already been released. The result was spurious refcount_t warnings ("saturated", "decrement hit 0") on every incoming CALL_REQUEST, leading to refcount corruption and eventual silent freeze. Replace netdev_tracker_alloc() with netdev_hold() so that rose_rx_call_request() acquires its own independent reference. Each caller retains its own hold from rose_dev_get() and releases it via dev_put() as before; socket cleanup releases the socket's separate hold via netdev_put(). Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit 1d94857c11d607ff68496866c5c90604f1aa1d8a Author: Bernard Pidoux Date: Sat May 16 12:10:55 2026 +0200 rose: guard rose_neigh_put() against NULL in timer expiry commit 2b67342c6ff899a0b83359517146a5b7b243af97 upstream. In rose_timer_expiry(), the ROSE_STATE_2 branch calls rose_neigh_put(rose->neighbour) without first checking whether the pointer is NULL. After commit 5de7665e0a07 ("net: rose: fix timer races against user threads") the timer is re-armed when the socket is owned by a user thread; between the re-arm and the next firing, a device-down event or concurrent teardown via rose_kill_by_device() can set rose->neighbour to NULL, leading to a NULL-pointer dereference inside rose_neigh_put(). Add a NULL check before the put and clear the pointer afterwards. Fixes: 5de7665e0a07 ("net: rose: fix timer races against user threads") Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit 270ef709257eb65c415973b7d7f40daca363ec13 Author: Bernard Pidoux Date: Sat May 16 12:10:38 2026 +0200 rose: clear neighbour pointer after rose_neigh_put() in state machines commit e8eb0c6faa8849ba7769516c1a8c84d9f612acf6 upstream. After calling rose_neigh_put() in rose_state1_machine() through rose_state5_machine(), rose->neighbour was left pointing at the potentially freed neighbour structure. A subsequent timer expiry or concurrent teardown path could dereference the stale pointer, causing a use-after-free. Set rose->neighbour to NULL immediately after each rose_neigh_put() call in the state machine functions. Fixes: d860d1faa6b2 ("net: rose: convert 'use' field to refcount_t") Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit 940f39e153323589b3b55026f7b2dc221b6c44d8 Author: Bernard Pidoux Date: Sat May 16 12:10:20 2026 +0200 rose: fix race between loopback timer and module removal commit 47dd6ec1a77d77895afb00aa2e68373a48289108 upstream. rose_loopback_clear() called timer_delete() which returns immediately without waiting for any running callback to complete. If the timer fired concurrently with module removal, rose_loopback_timer() could re-arm the timer after timer_delete() returned and then access rose_loopback_neigh after it was freed. Two complementary changes close the race: 1. Add a loopback_stopping atomic flag. rose_loopback_timer() checks it at entry (before acquiring a reference) and again inside the loop; when set it drains the queue and exits without re-arming the timer. 2. Switch rose_loopback_clear() to timer_delete_sync() so it blocks until any in-flight callback has returned before freeing resources. The smp_mb() between setting the flag and calling timer_delete_sync() ensures the flag is visible to any callback that is about to run. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit fe8cbcc3e79d458d7867009247645a50ea988191 Author: Bernard Pidoux Date: Sat May 16 12:10:03 2026 +0200 rose: hold loopback neighbour reference across timer callback commit d270a7a5793af84555c40dd1eb80f1d497fdf53c upstream. rose_loopback_timer() dereferences rose_loopback_neigh throughout its body but holds no reference on it. A concurrent rose_loopback_clear() followed by rose_add_loopback_neigh() could free and reallocate the neighbour while the timer body is running, causing a use-after-free. Take a reference with rose_neigh_hold() at the start of the callback (bailing out if the pointer is already NULL) and release it with rose_neigh_put() at the single exit point. The neigh cannot be freed while the callback holds a reference. Fixes: d860d1faa6b2 ("net: rose: convert 'use' field to refcount_t") Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit 7dac298524b415dc26e07f603caf67ac4eaec1fb Author: Bernard Pidoux Date: Sat May 16 12:09:33 2026 +0200 rose: fix dev_put() leak in rose_loopback_timer() commit ff91adc54db2b62c7cdf063ff761eceb5adf2215 upstream. rose_rx_call_request() always consumes or returns the skb but never releases the device reference obtained from rose_dev_get(). When rose_rx_call_request() succeeds (returns non-zero) dev_put() was never called, leaking one reference per loopback CALL_REQUEST. Move dev_put() outside the conditional so it is called unconditionally after rose_rx_call_request() in all cases. Also remove the dead check (!rose_loopback_neigh->dev && !rose_loopback_neigh->loopback) that immediately precedes it: the loopback neighbour always has loopback=1 so this condition can never be true. Fixes: 0453c6824595 ("net/rose: fix unbound loop in rose_loopback_timer()") Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman commit 19b3691ec94023aa9953376c48ac84f9aca2c7c1 Author: Yicong Yang Date: Wed Jun 24 14:38:16 2026 +0800 ACPI: scan: Use async schedule function in acpi_scan_clear_dep_fn() [ Upstream commit 7cf28b3797a81b616bb7eb3e90cf131afc452919 ] The device object rescan in acpi_scan_clear_dep_fn() is scheduled on a system workqueue which is not guaranteed to be finished before entering userspace. This may cause some key devices to be missing when userspace init task tries to find them. Two issues observed on RISCV platforms: - Kernel panic due to userspace init cannot have an opened console. The console device scanning is queued by acpi_scan_clear_dep_queue() and not finished by the time userspace init process running, thus by the time userspace init runs, no console is present. - Entering rescue shell due to the lack of root devices (PCIe nvme in our case). Same reason as above, the PCIe host bridge scanning is queued on a system workqueue and finished after init process runs. The reason is because both devices (console, PCIe host bridge) depend on riscv-aplic irqchip to serve their interrupts (console's wired interrupt and PCI's INTx interrupts). In order to keep the dependency, these devices are scanned and created after initializing riscv-aplic. The riscv-aplic is initialized in device_initcall() and a device scan work is queued via acpi_scan_clear_dep_queue(), which is close to the time userspace init process is run. Since system_dfl_wq is used in acpi_scan_clear_dep_queue() with no synchronization, the issues will happen if userspace init runs before these devices are ready. The solution is to wait for the queued work to complete before entering userspace init. One possible way would be to use a dedicated workqueue instead of system_dfl_wq, and explicitly flush it somewhere in the initcall stage before entering userspace. Another way is to use async_schedule_dev_nocall() for scanning these devices. It's designed for asynchronous initialization and will work in the same way as before because it's using a dedicated unbound workqueue as well, but the kernel init code calls async_synchronize_full() right before entering userspace init which will wait for the work to complete. Compared to a dedicated workqueue, the second approach is simpler because the async schedule framework takes care of all of the details. The ACPI code only needs to focus on its job. A dedicated workqueue for this could also be redundant because some platforms don't need acpi_scan_clear_dep_queue() for their device scanning. Signed-off-by: Yicong Yang [ rjw: Subject adjustment, changelog edits ] Link: https://patch.msgid.link/20260128132848.93638-1-yang.yicong@picoheart.com Signed-off-by: Rafael J. Wysocki [ Vivian: Adjust system_dfl_wq -> system_unbound_wq in removed lines ] Signed-off-by: Vivian Wang Signed-off-by: Sasha Levin commit 53483a9f4ee9eeb18aa866ec16cce79e136987e1 Author: Mingyu Wang <25181214217@stu.xidian.edu.cn> Date: Mon May 4 15:48:23 2026 +0800 agp/amd64: Fix broken error propagation in agp_amd64_probe() commit b08472db93b1ccff84a7adec5779d47f0e9d3a30 upstream. A NULL pointer dereference was observed in the AMD64 AGP driver when running in a virtualized environment (e.g. qemu/kvm) without a physical AMD northbridge. The crash occurs in amd64_fetch_size() when attempting to dereference the pointer returned by node_to_amd_nb(0). The root cause of this crash is broken error propagation in agp_amd64_probe(): When no AMD northbridges are found, cache_nbs() correctly returns -ENODEV. However, the probe function erroneously checks the return value against exactly -1, rather than < 0. As a result, the hardware absence error is masked, allowing the driver to improperly proceed with initialization. It eventually calls agp_add_bridge(), which invokes amd64_fetch_size(). Since the hardware does not exist, node_to_amd_nb(0) returns NULL, leading to a General Protection Fault (GPF) when accessing its ->misc member. Fix the issue by correcting the error check in agp_amd64_probe() to abort properly when cache_nbs() returns any negative error code. This prevents the driver from erroneously proceeding without hardware, thereby avoiding the subsequent NULL pointer dereference at its source. Fixes: a32073bffc65 ("[PATCH] x86_64: Clean and enhance up K8 northbridge access code") Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> Signed-off-by: Lukas Wunner Reviewed-by: Lukas Wunner Cc: stable@vger.kernel.org # v2.6.18+ Link: https://patch.msgid.link/20260504074823.99377-1-w15303746062@163.com Signed-off-by: Greg Kroah-Hartman commit 8b17adf6d4fb6bf61fa4c3f58366a7c082799a71 Author: Weiming Shi Date: Thu May 14 05:25:12 2026 -0700 net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink() commit d00c953a8f69921f484b629801766da68f27f658 upstream. rmnet_dellink() removes the endpoint from the hash table with hlist_del_init_rcu() and then immediately frees it with kfree(). However, RCU readers on the receive path (rmnet_rx_handler -> __rmnet_map_ingress_handler) may still hold a reference to the endpoint and dereference ep->egress_dev after the memory has been freed. The endpoint is a kmalloc-32 object, and the stale read at offset 8 corresponds to the egress_dev pointer. BUG: unable to handle page fault for address: ffffffffde942eef Oops: 0002 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 137 Comm: poc_write Not tainted 7.0.0+ #4 PREEMPTLAZY RIP: 0010:rmnet_vnd_rx_fixup (rmnet_vnd.c:27) Call Trace: __rmnet_map_ingress_handler (rmnet_handlers.c:48 rmnet_handlers.c:101) rmnet_rx_handler (rmnet_handlers.c:129 rmnet_handlers.c:235) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6096) __netif_receive_skb_one_core (net/core/dev.c:6208) netif_receive_skb (net/core/dev.c:6467) tun_get_user (drivers/net/tun.c:1955) tun_chr_write_iter (drivers/net/tun.c:2003) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) Add an rcu_head field to struct rmnet_endpoint and replace kfree() with kfree_rcu() so the endpoint memory remains valid through the RCU grace period. Also remove the rmnet_vnd_dellink() call and inline only the nr_rmnet_devs decrement, since rmnet_vnd_dellink() would set ep->egress_dev to NULL during the grace period, creating a data race with lockless readers. Fixes: ceed73a2cf4a ("drivers: net: ethernet: qualcomm: rmnet: Initial implementation") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Link: https://patch.msgid.link/20260514122511.3083479-2-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5f4d2bd028ebb6e4c09a9d64842546022321d4a7 Author: Weiming Shi Date: Wed Apr 15 01:23:39 2026 +0800 i2c: stub: Reject I2C block transfers with invalid length commit 6036b5067a8199ba7a2dc7b377d4b9dd276d5f9e upstream. The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer (34 bytes total). The driver is a development/test tool (CONFIG_I2C_STUB=m, not built by default) that must be loaded with a chip_addr= parameter. A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer: BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: stub_xfer (drivers/i2c/i2c-stub.c:223) __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536) i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391) i2cdev_ioctl (drivers/i2c/i2c-dev.c:478) __x64_sys_ioctl (fs/ioctl.c:583) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) The bug exists because i2c-stub implements .smbus_xfer directly, bypassing the I2C_SMBUS_BLOCK_MAX validation in i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same function correctly validates against I2C_SMBUS_BLOCK_MAX, but the I2C_SMBUS_I2C_BLOCK_DATA case does not. Fix by rejecting transfers with data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with both the I2C_SMBUS_BLOCK_DATA case in the same function and the I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated(). Fixes: 4710317891e4 ("i2c-stub: Implement I2C block support") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Reviewed-by: Jean Delvare Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit e2b143df29003d2704b51f62e9297006953dbacb Author: Lord Ulf Henrik Holmberg Date: Sat May 9 10:40:11 2026 +0200 RDMA/bnxt_re: zero shared page before exposing to userspace commit f6b079629becfa977f9c51fe53ad2e6dcc55ef44 upstream. bnxt_re_alloc_ucontext() allocates uctx->shpg via __get_free_page(GFP_KERNEL). The buddy allocator does not zero pages without __GFP_ZERO, so the page contains stale kernel data from whatever object most recently freed it. The page is then mapped into userspace via vm_insert_page() under BNXT_RE_MMAP_SH_PAGE in bnxt_re_mmap(). The driver only ever writes 4 bytes (a u32 AVID) at offset BNXT_RE_AVID_OFFT (0x10) inside bnxt_re_create_ah(); the remaining 4092 bytes of the page are exposed to userspace unsanitised, leaking kernel memory contents. Any user with access to /dev/infiniband/uverbsX on a host with a bnxt_re device (typically rdma group membership) can read this data via a single mmap() at pgoff 0 after IB_USER_VERBS_CMD_GET_CONTEXT. Other shared pages in the same file already use get_zeroed_page() correctly: drivers/infiniband/hw/bnxt_re/ib_verbs.c srq->uctx_srq_page = (void *)get_zeroed_page(GFP_KERNEL); cq->uctx_cq_page = (void *)get_zeroed_page(GFP_KERNEL); uctx->shpg is the only outlier. Bring it in line with the existing convention by switching to get_zeroed_page(). Fixes: 1ac5a4047975 ("RDMA/bnxt_re: Add bnxt_re RoCE driver") Signed-off-by: Lord Ulf Henrik Holmberg Link: https://patch.msgid.link/20260509084011.11971-1-pomzm67@gmail.com Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman commit 44b8b03a9fb5c575548fc72c674653d6baba142a Author: Waiman Long Date: Mon Jun 22 11:54:51 2026 +0200 debugobjects: Dont call fill_pool() in early boot hardirq context commit 0d046ae106255cba5eb83b23f78ee93f3620247d upstream. When booting a debug PREEMPT_RT kernel on an ARM64 system, a "inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage" lockdep warning message was reported to the console. During early boot, interrupts are enabled before the scheduler is enabled. In this window (before SYSTEM_SCHEDULING is set) interrupts can fire and in the hard interrupt context handler attempt to fill the pool This can lead to a deadlock when the interrupt occurred when the interrupt hits a region which holds a lock that is required to be taken in the allocation path. Add a new can_fill_pool() helper and reorder the exception rule and forbid this scenario by excluding allocations from hard interrupt context. Fixes: 06e0ae988f6e ("debugobjects: Allow to refill the pool before SYSTEM_SCHEDULING") Suggested-by: Sebastian Andrzej Siewior Suggested-by: Thomas Gleixner Signed-off-by: Waiman Long Signed-off-by: Thomas Gleixner Reviewed-by: Sebastian Andrzej Siewior Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260605173038.495075-1-longman@redhat.com Signed-off-by: Sasha Levin commit 3a408cae608d9c075dd3a9e5cfc03b3cb0726863 Author: Helen Koike Date: Mon Jun 22 11:54:46 2026 +0200 debugobjects: Do not fill_pool() if pi_blocked_on commit 5f41161059fd0f1bbf18c90f3180e38cc45a14eb upstream. On RT enabled kernels, fill_pool() ends up calling rtlock_lock(), which asserts if current::pi_blocked_on is set, because a task can obviously only block on one lock as otherwise the priority inheritenace chain gets corrupted. Prevent this by expanding the conditional to take current::pi_blocked_on into account. Fixes: 4bedcc28469a ("debugobjects: Make them PREEMPT_RT aware") Reported-by: syzbot+b8ca586b9fc235f0c0df@syzkaller.appspotmail.com Signed-off-by: Helen Koike Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260511215359.3351259-1-koike@igalia.com Closes: https://syzkaller.appspot.com/bug?extid=b8ca586b9fc235f0c0df Signed-off-by: Sasha Levin commit 9cd2087cd7026995c8a8e2c768198ed1de6eb011 Author: Sebastian Andrzej Siewior Date: Mon Jun 22 11:54:42 2026 +0200 debugobjects: Use LD_WAIT_CONFIG instead of LD_WAIT_SLEEP commit 37de2dbc318ee10577c1c2704de5a803e75e55a2 upstream. fill_pool_map is used to suppress nesting violations caused by acquiring a spinlock_t (from within the memory allocator) while holding a raw_spinlock_t. The used annotation is wrong. LD_WAIT_SLEEP is for always sleeping lock types such as mutex_t. LD_WAIT_CONFIG is for lock type which are sleeping while spinning on PREEMPT_RT such as spinlock_t. Use LD_WAIT_CONFIG as override. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20251127153652.291697-3-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit a460935022f512e167b4c5d4c12d85f89ba6aabd Author: Sebastian Andrzej Siewior Date: Mon Jun 22 11:54:38 2026 +0200 debugobjects: Allow to refill the pool before SYSTEM_SCHEDULING commit 06e0ae988f6e3499785c407429953ade19c1096b upstream. The pool of free objects is refilled on several occasions such as object initialisation. On PREEMPT_RT refilling is limited to preemptible sections due to sleeping locks used by the memory allocator. The system boots with disabled interrupts so the pool can not be refilled. If too many objects are initialized and the pool gets empty then debugobjects disables itself. Refiling can also happen early in the boot with disabled interrupts as long as the scheduler is not operational. If the scheduler can not preempt a task then a sleeping lock can not be contended. Allow to additionally refill the pool if the scheduler is not operational. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20251127153652.291697-2-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit 95f9eb19d5e65f7c32276f2bd77265c3f60727a6 Author: Yang Erkun Date: Wed May 13 10:42:52 2026 +0800 Revert "NFSD: Defer sub-object cleanup in export put callbacks" commit 516403d4d85607fdef3ca41d4a56b54e5566fa9a upstream. This reverts commit 48db892356d6cb80f6942885545de4a6dd8d2a29. Commit 48db892356d6 ("NFSD: Defer sub-object cleanup in export put callbacks") moved path_put() and auth_domain_put() out of svc_export_put() and expkey_put() and behind queue_rcu_work() to close a claimed use-after-free in e_show() and c_show() against ex_path and ex_client->name. Discussion in [1] shows neither the diagnosis nor the remedy survives review. The downstream teardown of both sub-objects is already RCU-deferred. auth_domain_put() reaches svcauth_unix_domain_release(), which frees the unix_domain and its ->name through call_rcu(). path_put() reaches dentry_free(), which frees the dentry through call_rcu(), and prepend_path() is already structured to tolerate concurrent dentry teardown. A reader in cache_seq_start_rcu() therefore observes both sub-objects through the next grace period regardless of whether svc_export_put() runs synchronously, so the synchronous form was never unsafe. The crash signature in the report cited by commit 48db892356d6 ("NFSD: Defer sub-object cleanup in export put callbacks") has a different root cause: a /proc/net/rpc cache file held open across network-namespace exit lets cache_destroy_net() free cd->hash_table while a reader is still walking it. The correct fix pins cd->net for the open fd's lifetime and does not require any deferral inside svc_export_put(). Meanwhile, deferring path_put() out of svc_export_put() reintroduces the regression that commit 69d803c40ede ("nfsd: Revert "nfsd: release svc_expkey/svc_export with rcu_work"") repaired: after "exportfs -r" drops the last cache reference, the mount reference held through ex_path lingers in the workqueue, so a subsequent umount fails with EBUSY. Restore the synchronous path_put() and auth_domain_put() in svc_export_put() and expkey_put() and the call_rcu()/kfree_rcu() free of the containing structures. The unrelated fix for ex_uuid/ex_stats from commit 2530766492ec ("nfsd: fix UAF when access ex_uuid or ex_stats") is preserved. Link: https://lore.kernel.org/all/10019b42-4589-4f9f-8d5b-d8197db1ce3c@huawei.com/ [1] Fixes: 48db892356d6 ("NFSD: Defer sub-object cleanup in export put callbacks") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Tested-by: Alexandr Alexandrov Signed-off-by: Yang Erkun Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit af2892249d982a1c036ca456cc135374e68b6677 Author: Joanne Koong Date: Mon May 18 22:28:06 2026 -0700 fuse: re-lock request before replacing page cache folio commit a078484921052d0badd827fcc2770b5cfc1d4120 upstream. fuse_try_move_folio() unlocks the request on entry but does not re-lock it on the success path. This means fuse_chan_abort() can end the request and free the fuse_io_args (eg fuse_readpages_end()) while the subsequent copy chain logic after fuse_try_move_folio() accesses the fuse_io_args, leading to use-after-free issues. Fix this by calling lock_request() before replace_page_cache_folio(). This ensures the request is locked on the success path which will prevent the fuse_io_args from being freed while the later copying logic runs, and also ensures that the ap->folios[i]->mapping is never null since ap->folios[i] will always point to the newfolio after replace_page_cache_folio(). Fixes: ce534fb05292 ("fuse: allow splice to move pages") Cc: stable@vger.kernel.org Reported-by: Lei Lu Signed-off-by: Joanne Koong Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 29706ac73f93b72f84deea32dd48aa88f5615538 Author: Russell King (Oracle) Date: Fri Jan 30 20:04:57 2026 +0000 net: stmmac: fix stm32 (and potentially others) resume regression [ Upstream commit dbbec8c5a79f4c7aa8d07da8c0b5a34d76c50699 ] Marek reported that suspending stm32 causes the following errors when the interface is administratively down: $ echo devices > /sys/power/pm_test $ echo mem > /sys/power/state ... ck_ker_eth2stp already disabled ... ck_ker_eth2stp already unprepared ... On suspend, stm32 starts the eth2stp clock in its suspend method, and stops it in the resume method. This is because the blamed commit omits the call to the platform glue ->suspend() method, but does make the call to the platform glue ->resume() method. This problem affects all other converted drivers as well - e.g. looking at the PCIe drivers, pci_save_state() will not be called, but pci_restore_state() will be. Similar issues affect all other drivers. Fix this by always calling the ->suspend() method, even when the network interface is down. This fixes all the conversions to the platform glue ->suspend() and ->resume() methods. Link: https://lore.kernel.org/r/20260114081809.12758-1-marex@nabladev.com Fixes: 07bbbfe7addf ("net: stmmac: add suspend()/resume() platform ops") Reported-by: Marek Vasut Tested-by: Marek Vasut Signed-off-by: Russell King (Oracle) Link: https://patch.msgid.link/E1vlujh-00000007Hkw-2p6r@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b6099150949f822999b5e989db1ad66e7850d925 Author: Gabriel Krisman Bertazi Date: Wed Jun 17 15:27:22 2026 -0400 io_uring/net: Avoid msghdr on op_connect/op_bind async data [ Upstream commit 3979840cd858f30f43ea9f4e7f7f1f56de82d698 ] This fixes a memory leak due to the lack of the cleanup hook for the iovec. The stable backport differs from upstream by dropping the io_connect_bpf_populate hunk, which didn't exist at the time and by fixing the merge conflict due to the introduction of io_bind_file_create. Both IORING_OP_CONNECT and IORING_OP_BIND reuse the msghdr object just to store the sockaddr. Beyond allocating a much larger object than needed, msghdr can also wrap an iovec, which will be recycled unnecessarily. This uses the sockaddr directly. Cc: stable@vger.kernel.org Signed-off-by: Gabriel Krisman Bertazi Link: https://patch.msgid.link/20260602215327.1885109-2-krisman@suse.de Signed-off-by: Jens Axboe Signed-off-by: Gabriel Krisman Bertazi Signed-off-by: Sasha Levin commit e5609e8d8caceff77ad93729152bb824b1bb3a9c Author: Alexandre Frade Date: Fri Jun 19 13:10:28 2026 +0000 Linux 6.18.36-xanmod1 Signed-off-by: Alexandre Frade commit a240262f0bf008dfef9072265b58e2c3d0d13130 Merge: da2d87f71ae2 275d294b2b24 Author: Alexandre Frade Date: Fri Jun 19 13:07:52 2026 +0000 Merge tag 'v6.18.36' into 6.18 This is the 6.18.36 stable release commit 275d294b2b24abcd65452198551cd8a5b8d4f775 Author: Greg Kroah-Hartman Date: Fri Jun 19 13:44:16 2026 +0200 Linux 6.18.36 Link: https://lore.kernel.org/r/20260616145057.827196531@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Shung-Hsi Yu Tested-by: Wentao Guan Tested-by: Miguel Ojeda Tested-by: Mark Brown Tested-by: Shuah Khan Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Pavel Machek (CIP) Tested-by: Florian Fainelli Tested-by: Willy Tarreau Signed-off-by: Greg Kroah-Hartman commit 5d634afb8b83b49de562792fd0d047416a43bd4d Author: Zhengchuan Liang Date: Sat Apr 4 17:39:48 2026 +0800 netfilter: require Ethernet MAC header before using eth_hdr() [ Upstream commit 62443dc21114c0bbc476fa62973db89743f2f137 ] `ip6t_eui64`, `xt_mac`, the `bitmap:ip,mac`, `hash:ip,mac`, and `hash:mac` ipset types, and `nf_log_syslog` access `eth_hdr(skb)` after either assuming that the skb is associated with an Ethernet device or checking only that the `ETH_HLEN` bytes at `skb_mac_header(skb)` lie between `skb->head` and `skb->data`. Make these paths first verify that the skb is associated with an Ethernet device, that the MAC header was set, and that it spans at least a full Ethernet header before accessing `eth_hdr(skb)`. Suggested-by: Florian Westphal Tested-by: Ren Wei Signed-off-by: Zhengchuan Liang Signed-off-by: Ren Wei Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit bf7a9cacd95e72bf1b48767474c31324c39982f9 Author: Nathan Chancellor Date: Thu Jun 4 17:33:21 2026 -0700 cfi: Include uaccess.h for get_kernel_nofault() commit 979c294509f9248fe1e7c358d582fb37dd5ca12d upstream. After commit 0652a3daa787 ("tracing: Fix CFI violation in probestub being called by tprobes"), there are many build errors when building ARCH=arm multi_v7_defconfig + CONFIG_CFI=y like: In file included from drivers/base/devres.c:17: In file included from drivers/base/trace.h:16: In file included from include/linux/tracepoint.h:23: include/linux/cfi.h:44:6: error: call to undeclared function 'get_kernel_nofault'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 44 | if (get_kernel_nofault(hash, func - cfi_get_offset())) | ^ 1 error generated. get_kernel_nofault() is called in the generic version of cfi_get_func_hash() but nothing ensures uaccess.h is always included for a proper expansion and prototype. Include uaccess.h in cfi.h to clear up the errors. Cc: stable@vger.kernel.org Fixes: 0652a3daa787 ("tracing: Fix CFI violation in probestub being called by tprobes") Signed-off-by: Nathan Chancellor Acked-by: Masami Hiramatsu (Google) Reviewed-by: Sami Tolvanen Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f455405e320773a88ef23df89eceea2433d6cc99 Author: Stefano Garzarella Date: Thu May 21 14:47:32 2026 +0200 vsock/virtio: fix skb overhead overflow on 32-bit builds commit 4157501b9a8ff1bbe32ff5a7d8aece7ab18eff40 upstream. On 32-bit architectures, both skb_queue_len() and SKB_TRUESIZE(0) evaluate to 32-bit values. The multiplication can overflow before being assigned to the u64 skb_overhead variable, making the skb overhead check ineffective. Cast skb_queue_len() to u64 so the multiplication is always performed in 64-bit arithmetic. This issue was reported by Sashiko while reviewing another patch. Fixes: 059b7dbd20a6 ("vsock/virtio: fix potential unbounded skb queue") Closes: https://sashiko.dev/#/patchset/20260518090656.134588-1-sgarzare%40redhat.com Cc: stable@vger.kernel.org Signed-off-by: Stefano Garzarella Acked-by: Michael S. Tsirkin Link: https://patch.msgid.link/20260521124732.125771-1-sgarzare@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 36a0faaa4e3d2dc15cf98ac9467542c64ed85b4c Author: Damien Le Moal Date: Wed May 13 20:11:29 2026 +0900 block: fix handling of dead zone write plugs commit 836efd35c472d89c838d7b17ef339ddb3286ffc5 upstream. Shin'ichiro reported hard to reproduce unaligned write errors with zoned block devices. Under normal operation conditions (e.g. running XFS on an SMR disk), these errors are nearly impossible to trigger. But using a "slow" kernel with many debug options enables and some specific use cases (e.g. fio zbd test case 46), the errors can be reproduced fairly easily. The unaligned write errors come from mishandling a valid reference counting pattern of zone write plugs. Such pattern triggers for instance if a process A writes a zone (not necessarilly to the full state), another process B immediately resets the zone and immediately following the completion of the zone reset, starts issuing writes to the zone. With such pattern, in some cases, the zone write plugs worker thread of the device may still be holding a reference to the zone write plug of the zone taken when process A was writing to the zone. The following zone reset from process B marks the zone as dead but does not remove the zone write plug from the device hash table as a reference to the plug still exist. Once process B starts issuing new writes, the zone write plug is seen as dead and the writes from process B are immediately failed, despite this write pattern being perfectly legal. Fix this by allowing restoring a dead zone write plug to a live state if a write is issued to the zone when the zone is: marked as dead, empty and the write sector corresponds to the first sector of the zone (that is, the write is aligned to the zone write pointer). This is done with the new helper function disk_check_zone_wplug_dead(), which restores a dead zone write plug to a live state by clearing the BLK_ZONE_WPLUG_DEAD flag and restoring the initial reference to the zone write plug taken when the plug was added to the device hash table. Reported-by: Shin'ichiro Kawasaki Fixes: b7d4ffb51037 ("block: fix zone write plug removal") Signed-off-by: Damien Le Moal Tested-by: Shin'ichiro Kawasaki Link: https://patch.msgid.link/20260513111129.108809-1-dlemoal@kernel.org Signed-off-by: Jens Axboe [ context conflict due to different line offsets in blk-zoned.c ] Signed-off-by: Gyokhan Kochmarla Signed-off-by: Greg Kroah-Hartman commit 7b569b3a2f295db7b76ad85cd14aeea1cb0704cb Author: Will Deacon Date: Tue Jun 16 06:13:29 2026 +0100 arm64: errata: Mitigate TLBI errata on Microsoft Azure Cobalt 100 CPU commit 1940e70a8144bf75e6df26bf6f600862ea7f7ea1 upstream. Commit fb091ff39479 ("arm64: Subscribe Microsoft Azure Cobalt 100 to ARM Neoverse N2 errata") states that Microsoft Azure Cobalt 100 CPU "is a Microsoft implemented CPU based on r0p0 of the ARM Neoverse N2 CPU, and therefore suffers from all the same errata.". So enable the workaround for the latest broadcast TLB invalidation bug on these parts. Signed-off-by: Will Deacon [Mark: backport to v6.18.y] Signed-off-by: Mark Rutland Signed-off-by: Greg Kroah-Hartman commit 99abe00c605ea9217225806c23ad8b89633c32b7 Author: Shanker Donthineni Date: Tue Jun 16 06:13:28 2026 +0100 arm64: errata: Mitigate TLBI errata on NVIDIA Olympus CPU commit ec7216f92e4ebd485b1c6dc6aa3f6064b71a5768 upstream. NVIDIA Olympus cores are affected by the TLBI completion issue tracked as CVE-2025-10263. The existing ARM64_ERRATUM_4118414 handling already uses ARM64_WORKAROUND_REPEAT_TLBI to issue an additional broadcast TLBI;DSB sequence and ensure affected memory write effects are globally observed. Add MIDR_NVIDIA_OLYMPUS to the repeat-TLBI match list so the same mitigation is enabled on affected Olympus systems. Also document the NVIDIA Olympus erratum in the arm64 silicon errata table and list it in the Kconfig help text. Signed-off-by: Shanker Donthineni Cc: Catalin Marinas Cc: Will Deacon Cc: Mark Rutland Acked-by: Mark Rutland Signed-off-by: Will Deacon [Mark: backport to v6.18.y] Signed-off-by: Shanker Donthineni Signed-off-by: Greg Kroah-Hartman commit d4fd4282204044fdedd1e42abbe70a9206f74ec0 Author: Mark Rutland Date: Tue Jun 16 06:13:27 2026 +0100 arm64: errata: Mitigate TLBI errata on various Arm CPUs commit cfd391e74134db664feb499d43af286380b10ba8 upstream. A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number. Signed-off-by: Mark Rutland Cc: Catalin Marinas Cc: Will Deacon Signed-off-by: Will Deacon [Mark: backport to v6.18.y] Signed-off-by: Mark Rutland Signed-off-by: Greg Kroah-Hartman commit 8097f93f9b773cd7f5e8f75625870f17bdf17452 Author: Mark Rutland Date: Tue Jun 16 06:13:26 2026 +0100 arm64: cputype: Add C1-Premium definitions commit d28413bfc5a255957241f1df5d7fd0c2cd74fe18 upstream. Add cputype definitions for C1-Premium. These will be used for errata detection in subsequent patches. These values can be found in the C1-Premium TRM: https://developer.arm.com/documentation/109416/0100/ ... in section A.5.1 ("MIDR_EL1, Main ID Register"). Signed-off-by: Mark Rutland Cc: Catalin Marinas Cc: Will Deacon Signed-off-by: Will Deacon [Mark: backport to v6.18.y] Signed-off-by: Mark Rutland Signed-off-by: Greg Kroah-Hartman commit e9ea7cb17677ce4ad60863c98e4bb8655fb1b903 Author: Mark Rutland Date: Tue Jun 16 06:13:25 2026 +0100 arm64: cputype: Add C1-Ultra definitions commit 60349e64a6c65f9f0aa118af711b3c7e137f07ff upstream. Add cputype definitions for C1-Ultra. These will be used for errata detection in subsequent patches. These values can be found in the C1-Ultra TRM: https://developer.arm.com/documentation/108014/0100/ ... in section A.5.1 ("MIDR_EL1, Main ID Register"). Signed-off-by: Mark Rutland Cc: Catalin Marinas Cc: Will Deacon Signed-off-by: Will Deacon [Mark: backport to v6.18.y] Signed-off-by: Mark Rutland Signed-off-by: Greg Kroah-Hartman commit eca6743b148a8c67c9352d578b3df14bd51fa8a1 Author: Stefano Garzarella Date: Mon May 18 11:06:56 2026 +0200 vsock/virtio: fix skb overhead accounting to preserve full buf_alloc commit c6087c5aaad6d1b8be1a1a641e0a422218ade911 upstream. After commit 059b7dbd20a6 ("vsock/virtio: fix potential unbounded skb queue"), virtio_transport_inc_rx_pkt() subtracts per-skb overhead from buf_alloc when checking whether a new packet fits. This reduces the effective receive buffer below what the user configured via SO_VM_SOCKETS_BUFFER_SIZE, causing legitimate data packets to be silently dropped and applications that rely on the full buffer size to deadlock. Also, the reduced space is not communicated to the remote peer, so its credit calculation accounts more credit than the receiver will actually accept, causing data loss (there is no retransmission). With this approach we currently have failures in tools/testing/vsock/vsock_test.c. Test 18 sometimes fails, while test 22 always fails in this way: 18 - SOCK_STREAM MSG_ZEROCOPY...hash mismatch 22 - SOCK_STREAM virtio credit update + SO_RCVLOWAT...send failed: Resource temporarily unavailable Fix by allowing at most `buf_alloc * 2` as the total budget for payload plus skb overhead in virtio_transport_inc_rx_pkt(), similar to how SO_RCVBUF is doubled to reserve space for sk_buff metadata. This preserves the full buf_alloc for payload under normal operation, while still bounding the skb queue growth. With this patch, all tests in tools/testing/vsock/vsock_test.c are now passing again. Fixes: 059b7dbd20a6 ("vsock/virtio: fix potential unbounded skb queue") Cc: stable@vger.kernel.org Signed-off-by: Stefano Garzarella Link: https://patch.msgid.link/20260518090656.134588-3-sgarzare@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 9bdc637fde66b63d6cad0caacd034888bb7bf5f5 Author: Eric Dumazet Date: Thu Apr 30 12:26:52 2026 +0000 vsock/virtio: fix potential unbounded skb queue commit 059b7dbd20a6f0c539a45ddff1573cb8946685b5 upstream. virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc. virtio_transport_recv_enqueue() skips coalescing for packets with VIRTIO_VSOCK_SEQ_EOM. If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM, a very large number of packets can be queued because vvs->rx_bytes stays at 0. Fix this by estimating the skb metadata size: (Number of skbs in the queue) * SKB_TRUESIZE(0) Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit") Signed-off-by: Eric Dumazet Cc: Arseniy Krasnov Cc: Stefan Hajnoczi Cc: Stefano Garzarella Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Xuan Zhuo Cc: "Eugenio Pérez" Cc: virtualization@lists.linux.dev Link: https://patch.msgid.link/20260430122653.554058-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit cdce1e797addab72393c0dfee31aaca41ef7d937 Author: Julian Anastasov Date: Sat Feb 14 16:58:49 2026 +0200 ipvs: skip ipv6 extension headers for csum checks commit 05cfe9863ef049d98141dc2969eefde72fb07625 upstream. Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem. Fixes: 2906f66a5682 ("ipvs: SCTP Trasport Loadbalancing Support") Fixes: 0bbdd42b7efa ("IPVS: Extend protocol DNAT/SNAT and state handlers") Signed-off-by: Julian Anastasov Signed-off-by: Florian Westphal Signed-off-by: Nazar Kalashnikov Signed-off-by: Greg Kroah-Hartman commit afd35fec9297195b759078745549c2671223f24f Author: Jason Gunthorpe Date: Mon Jun 15 17:29:08 2026 -0400 RDMA/umem: Fix truncation for block sizes >= 4G [ Upstream commit 15fe76e23615f502d051ef0768f86babaf08746c ] When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses. Link: https://patch.msgid.link/r/1-v1-88303e9e509f+f7-ib_umem_types_jgg@nvidia.com Cc: stable@vger.kernel.org Fixes: a808273a495c ("RDMA/verbs: Add a DMA iterator to return aligned contiguous memory blocks") Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cd26d54bfbc2ff093a28dcbde5ff044d9086e4db Author: Leon Romanovsky Date: Mon Jun 15 17:29:07 2026 -0400 RDMA: Move DMA block iterator logic into dedicated files [ Upstream commit 6094ea64c69520ed1e770e7c79c43412de202bfa ] The DMA iterator logic was mixed into verbs and umem-specific code, forcing all users to include rdma/ib_umem.h. Move the block iterator logic into iter.c and rdma/iter.h so that rdma/ib_umem.h and rdma/ib_verbs.h can be separated in a follow-up patch. Link: https://patch.msgid.link/20260213-refactor-umem-v1-1-f3be85847922@nvidia.com Signed-off-by: Leon Romanovsky Stable-dep-of: 15fe76e23615 ("RDMA/umem: Fix truncation for block sizes >= 4G") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ebf22feff4921af7ac21d191396455283adb7dc2 Author: Randy Dunlap Date: Mon Jun 15 17:29:06 2026 -0400 RDMA/umem: fix kernel-doc warnings [ Upstream commit ff46d1392750444fab5ae5a0194764ffdc4ac0d2 ] Add or correct kernel-doc comments to eliminate warnings: Warning: include/rdma/ib_umem.h:104 function parameter 'biter' not described in 'rdma_umem_for_each_dma_block' Warning: include/rdma/ib_umem.h:140 function parameter 'pgsz_bitmap' not described in 'ib_umem_find_best_pgoff' Warning: include/rdma/ib_umem.h:141 No description found for return value of 'ib_umem_find_best_pgoff' Signed-off-by: Randy Dunlap Link: https://patch.msgid.link/20260224003120.3173892-1-rdunlap@infradead.org Signed-off-by: Leon Romanovsky Stable-dep-of: 15fe76e23615 ("RDMA/umem: Fix truncation for block sizes >= 4G") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 84d8f58cf28a0415413f43ba7148f7bacd4c1b6e Author: Davide Ornaghi Date: Mon Jun 15 09:28:01 2026 -0400 netfilter: nft_fib: fix stale stack leak via the OIFNAME register [ Upstream commit ab185e0c4fb82dfba6fb86f8271e06f931d9c64c ] For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via "*dest = 0". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare "*dest = 0" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes. Fixes: f6d0cbcf09c5 ("netfilter: nf_tables: add fib expression") Suggested-by: Florian Westphal Cc: stable@vger.kernel.org Signed-off-by: Davide Ornaghi Signed-off-by: Pablo Neira Ayuso [ kept the tree's older `ip6_route_lookup()`/`rt6_info` IPv6 context and changed only `*dest = 0;` to `nft_fib_store_result(dest, priv, NULL);` ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2904e985a2917b5dac65df82733065e78a65fc9d Author: Jason Gunthorpe Date: Mon Jun 15 17:16:16 2026 -0400 RDMA: During rereg_mr ensure that REREG_ACCESS is compatible [ Upstream commit badad6fad60def1b9805559dd81dbab3d97b82aa ] If IB_MR_REREG_ACCESS changes from RO to RW then the umem has to be re-evaluated to ensure it is properly pinned as RW. Since the umem is hidden inside each driver's mr struct add a ib_umem_check_rereg() function that each driver has to call before processing IB_MR_REREG_ACCESS. mlx4 has to retain its duplicate ib_access_writable check because it implements IB_MR_REREG_ACCESS | IB_MR_REREG_TRANS by changing both items in place sequentially while the MR is live, so it will continue to not support this combination. Cc: stable@vger.kernel.org Fixes: b40656aa7d55 ("RDMA/umem: remove FOLL_FORCE usage") Link: https://patch.msgid.link/r/0-v1-06fb1a2d6cf5+107-rereg_access_jgg@nvidia.com Reported-by: Philip Tsukerman Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f58efaf9fcf7cb48d87356ef45331274a8a1c10c Author: Jacob Moroni Date: Mon Jun 15 17:16:15 2026 -0400 RDMA/umem: Add helpers for umem dmabuf revoke lock [ Upstream commit 3a0b171302eea1732a168e26db3b8461f51cc1f9 ] Added helpers to acquire and release the umem dmabuf revoke lock. The intent is to avoid the need for drivers to peek into the ib_umem_dmabuf internals to get the dma_resv_lock and bring us one step closer to abstracting ib_umem_dmabuf away from drivers in general. Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20260305170826.3803155-5-jmoroni@google.com Signed-off-by: Leon Romanovsky Stable-dep-of: badad6fad60d ("RDMA: During rereg_mr ensure that REREG_ACCESS is compatible") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5f3286ca5fbb3579135c5d9ec73a6a819feec140 Author: Jacob Moroni Date: Mon Jun 15 17:16:14 2026 -0400 RDMA/umem: Move umem dmabuf revoke logic into helper function [ Upstream commit 797291a66ce346c96114b72222fc290d402da005 ] This same logic will eventually be reused from within the invalidate_mappings callback which already has the dma_resv_lock held, so break it out into a separate function so it can be reused. Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20260305170826.3803155-3-jmoroni@google.com Signed-off-by: Leon Romanovsky Stable-dep-of: badad6fad60d ("RDMA: During rereg_mr ensure that REREG_ACCESS is compatible") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ceddd32231dd1f7473f4a4ce96bce04f6db59333 Author: Jacob Moroni Date: Mon Jun 15 17:16:13 2026 -0400 RDMA/umem: Add ib_umem_dmabuf_get_pinned_and_lock helper [ Upstream commit 553dfa8cbd0c6d36adae042d9738ddf8f8765ac7 ] Move the inner logic of ib_umem_dmabuf_get_pinned_with_dma_device() to a new static function that returns with the lock held upon success. The intent is to allow reuse for the future get_pinned_revocable_and_lock function. Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20260305170826.3803155-2-jmoroni@google.com Signed-off-by: Leon Romanovsky Stable-dep-of: badad6fad60d ("RDMA: During rereg_mr ensure that REREG_ACCESS is compatible") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0ffcad63b19a1cadb475c9f405a93607fdcd0d7c Author: Tejun Heo Date: Mon Jun 15 13:47:03 2026 +0100 sched_ext: Don't warn on NULL cgrp_moving_from in scx_cgroup_move_task() commit 02e545c4297a26dbbc41df81b831e7f605bcd306 upstream. A WARN fires when systemd's user manager writes "+cpu +memory +pids" to its own subtree_control while a sched_ext scheduler is loaded: WARNING: at kernel/sched/ext.c:3227 scx_cgroup_move_task+0xa8/0xb0 scx_cgroup_move_task+0xa8/0xb0 sched_move_task+0x134/0x290 cpu_cgroup_attach+0x39/0x70 cgroup_migrate_execute+0x37d/0x450 cgroup_update_dfl_csses+0x1e3/0x270 cgroup_subtree_control_write+0x3e7/0x440 scx_cgroup_can_attach() arms cgrp_moving_from only when a task's cpu cgroup changes. It can still be NULL when scx_cgroup_move_task() runs, through this sequence: Step Result --------------------------------- ---------------------------------- 1. cpu enabled on cgroup G cpu css = A 2. cpu toggled off then on for G A killed, B created (same cgroup) 3. an exiting task keeps A alive migration skips it, A now stale 4. +memory migrates G stale A vs current B pulls cpu in 5. cpu attach runs for all tasks hits a live, cpu-unchanged task 6. scx_cgroup_move_task() on it cgrp_moving_from NULL -> WARN The mismatch is that scx_cgroup_can_attach() keys on cgroup identity while migration drives the move on css identity, so a NULL cgrp_moving_from here is a legitimate css-only migration, not a missing prep. The call is already gated on cgrp_moving_from, so just drop the warning. ops.cgroup_prep_move() and ops.cgroup_move() stay paired. Fixes: 819513666966 ("sched_ext: Add cgroup support") Cc: stable@vger.kernel.org # v6.12+ Reported-by: Matt Fleming Closes: https://lore.kernel.org/all/20260601124156.2205704-1-mfleming@cloudflare.com/ Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi [ mfleming: keep the 6.18.y SCX_KF_REST argument in the SCX_CALL_OP_TASK() call. ] Signed-off-by: Matt Fleming Signed-off-by: Sasha Levin commit 37c059d4d92ff0a0160845e5cbe528ab2361c5f6 Author: Johannes Berg Date: Mon May 4 08:54:27 2026 +0200 wifi: mac80211: tests: mark HT check strict commit 0cfff13c94cb5fa818bb374945ff280e08dc1bb9 upstream. The HT check now only applies in strict mode since APs were found to be broken. Mark it as such. Fixes: 711a9c018ad2 ("wifi: mac80211: skip ieee80211_verify_sta_ht_mcs_support check in non-strict mode") Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 4dac39a4db146921e1d466e58d4349767945e4c5 Author: Rio Liu Date: Wed Apr 15 16:57:13 2026 +0000 wifi: mac80211: skip ieee80211_verify_sta_ht_mcs_support check in non-strict mode commit 711a9c018ad252b2807f85d44e1267b595644f9b upstream. Some Xfinity XB8 firmware advertises >1 spatial stream MCS indexes in their basic HT-MCS set. On cards with lower spatial streams, the check would fail, and we'd be stuck with no HT when in fact work fine with its own supported rate. This change makes it so the check is only performed in strict mode. Fixes: 574faa0e936d ("wifi: mac80211: add HT and VHT basic set verification") Signed-off-by: Rio Liu Link: https://patch.msgid.link/99Mv9QEceyPrQhSP52MtAVmz0_kWJmzqotJjD9YW6LGLqk-AZloAueUyHCURilFkuqOh6Ecv8i2KKdSE1ujP3AnbU5QEouVisT1w_V3xdfc=@r26.me Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 17faa39ba9808fbfcc86de55703cd8b16e58e8a6 Author: Johan Hovold Date: Thu Apr 30 11:17:18 2026 +0200 driver core: reject devices with unregistered buses commit 36f35b8df6972167102a1c3d4361e0afb6a84534 upstream. Trying to register a device on a bus which has not yet been registered used to trigger a NULL-pointer dereference, but since the const bus structure rework registration instead succeeds without the device being added to the bus. This specifically means that the device will never bind to a driver and that the bus sysfs attributes are not created (i.e. as if the device had no bus). Reject devices with unregistered buses to catch any callers that get the ordering wrong and to handle bus registration failures more gracefully. Fixes: 5221b82d46f2 ("driver core: bus: bus_add/probe/remove_device() cleanups") Cc: stable@vger.kernel.org # 6.3 Cc: Greg Kroah-Hartman Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260430091718.230228-1-johan@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 20a93e397abe850c49b6fa0e8cc827b5f634a8f5 Author: Mingyu Wang <25181214217@stu.xidian.edu.cn> Date: Sat May 23 21:52:10 2026 +0800 fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling commit 00633c4683828acd5256fa8d5163f440d74bbe71 upstream. A SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur in send_sigio() and send_sigurg() when a process group receives a signal. When FASYNC is configured for a process group (PIDTYPE_PGID), both functions use read_lock(&tasklist_lock) to traverse the task list. However, they are frequently called from softirq context: - send_sigio() via input_inject_event -> kill_fasync - send_sigurg() via tcp_check_urg -> sk_send_sigurg (NET_RX_SOFTIRQ) The deadlock is caused by the rwlock writer fairness mechanism: 1. CPU 0 (process context) holds read_lock(&tasklist_lock) in do_wait(). 2. CPU 1 (process context) attempts write_lock(&tasklist_lock) in fork() or exit() and spins, which blocks all new readers. 3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception). 4. The softirq calls send_sigurg() and attempts to acquire read_lock(&tasklist_lock), deadlocking because CPU 1 is waiting. Since PID hashing and do_each_pid_task() traversals are already RCU-protected, the read_lock on tasklist_lock is no longer strictly required for safe traversal. Fix this by replacing tasklist_lock with rcu_read_lock(), aligning the process group signaling path with the single-PID path. This also mitigates a potential remote denial of service vector via TCP URG packets. Lockdep splat: ===================================================== WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected [...] Chain exists of: &dev->event_lock --> &f_owner->lock --> tasklist_lock Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(tasklist_lock); local_irq_disable(); lock(&dev->event_lock); lock(&f_owner->lock); lock(&dev->event_lock); *** DEADLOCK *** Reviewed-by: Jeff Layton Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> Link: https://patch.msgid.link/20260523135210.590928-1-w15303746062@163.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit e09689286385a66311ac6922af95339d7a3cef8d Author: Harry Wentland Date: Tue May 5 11:52:15 2026 -0400 drm/amd/display: Use krealloc_array() in dal_vector_reserve() commit da48bc4461b8a5ebfb9264c9b191a701d8e99009 upstream. [Why & How] dal_vector_reserve() computes the allocation size as "capacity * vector->struct_size" using uint32_t arithmetic, which can silently wrap to a small value on overflow. This would cause krealloc to return a smaller buffer than expected, leading to heap overflows on subsequent vector appends. Replace krealloc() with krealloc_array() which performs an internal overflow check and returns NULL on wrap, preventing the issue. Fixes: 2004f45ef83f ("drm/amd/display: Use kernel alloc/free") Assisted-by: Copilot:claude-opus-4.6 Reviewed-by: Alex Hung Signed-off-by: Harry Wentland Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 37668568641ccc4cc1dbca4923d0a16609dd5707) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 454d3b3d499c18373f8960d31aea48338a3ca9e0 Author: Harry Wentland Date: Tue May 5 11:44:15 2026 -0400 drm/amd/display: Fix out-of-bounds read in dp_get_eq_aux_rd_interval() commit e8b4d37eba05141ee01794fc6b7f2da808cee83b upstream. [Why & How] The aux_rd_interval array in struct dc_lttpr_caps is declared with MAX_REPEATER_CNT - 1 (7) elements, indexed 0..6. However, the offset parameter passed to dp_get_eq_aux_rd_interval() can be as large as MAX_REPEATER_CNT (8) when a sink reports 8 LTTPR repeaters via DPCD. This leads to an out-of-bounds read of aux_rd_interval[7] when offset is 8. Fix this by growing aux_rd_interval to MAX_REPEATER_CNT elements to accommodate the full range of valid repeater counts defined by the DP spec. Assisted-by: GitHub Copilot:Claude claude-4-opus Signed-off-by: Harry Wentland Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit a55a458a8df37a65ffda5cf721d554a8f74f6b04) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit bb6f705b73b5f191f14ad004e2c8c4b615806187 Author: Harry Wentland Date: Mon May 11 16:46:25 2026 -0400 drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs commit adf67034b1f61f7119295208085bfd43f85f56af upstream. [Why & How] dp_sdp_message_debugfs_write() dereferences connector->base.state->crtc without checking for NULL. A connector can be connected but not bound to any CRTC (e.g. after hot-plug before the next atomic commit), causing a kernel crash when writing to the sdp_message debugfs node. The function also ignores the user-provided size argument and always passes 36 bytes to copy_from_user(), reading past the user buffer when size < 36. Fix both issues by: - Returning -ENODEV when connector->base.state or state->crtc is NULL - Clamping write_size to min(size, sizeof(data)) Fixes: c7ba3653e977 ("drm/amd/display: Generic SDP message access in amdgpu") Assisted-by: Copilot:claude-opus-4.6 Reviewed-by: Alex Hung Signed-off-by: Harry Wentland Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit c000da79df787097abdfb1cb4bf94af8151a566a Author: Leorize Date: Wed May 27 23:58:54 2026 -0700 drm/amd/display: add missing CSC entries for BT.2020 for DCE IPs commit 6590fe323ce2807f5d9454e7fccf3fab875d4352 upstream. DCE-based hardware does not have the CSC matrices for BT.2020, which causes the driver to fallback to the GPU built-in matrices. This does not appear to cause any issues for RGB sinks, but causes major color artifacts for YCbCr ones (e.g. black becomes green). This commit adds the missing CSC matrices (taken from DC common) to DCE CSC tables, resolving the issue. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/3358 Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5333 Assisted-by: oh-my-pi:GPT-5.5 Signed-off-by: Leorize Reviewed-by: Alex Hung Signed-off-by: Alex Deucher (cherry picked from commit 51e6668ab4baf55b082c376318d51ef965757196) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 3f32d52ec604c659725d865cf8cc6a17a33f9c6a Author: Harry Wentland Date: Mon May 4 15:51:13 2026 -0400 drm/amd/display: Clamp VBIOS HDMI retimer register count to array size commit fb0707ce00eef4e2d60c3020e1c0432739703e4a upstream. [Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe. Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1(). Assisted-by: GitHub Copilot:claude-opus-4.6 Reviewed-by: Alex Hung Signed-off-by: Harry Wentland Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 1906064d50d194a145486e5caf3db3e708b6f6ef Author: Harry Wentland Date: Thu May 7 15:38:37 2026 -0400 drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size commit f0f3981c43b32cadfe373d636d9e9ca522bb3702 upstream. [Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rx_id_list[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read. Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the rx_id_list buffer, matching the approach already used in the DP branch. Fixes: eff682f83c9c ("drm/amd/display: Add DDC handles for HDCP2.2") Assisted-by: Copilot:claude-opus-4.6 Reviewed-by: Alex Hung Signed-off-by: Harry Wentland Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 0e56f460bddb397fa9a8e6faf7ae7eaa86953eb1 Author: Harry Wentland Date: Tue May 12 15:24:22 2026 -0400 drm/amd/display: Bound VBIOS record-chain walk loops commit ff287df16a1a58aca78b08d1f3ee09fc44da0351 upstream. [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") Assisted-by: Copilot:claude-opus-4.6 Mythos Reviewed-by: Alex Hung Signed-off-by: Harry Wentland Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 57607fe55e6d598bc58c15d1143ba7a266b17103 Author: Priya Hosur Date: Thu May 7 13:31:37 2026 +0530 drm/amd/pm: smu_v14_0_0: use SoftMin for gfxclk in set_soft_freq_limited_range commit 03b70e0d8aa26bab89a0f1394c1c80a871925e42 upstream. In smu_v14_0_0_set_soft_freq_limited_range(), the gfxclk floor is programmed via SetHardMinGfxClk together with SetSoftMaxGfxClk. Under power_dpm_force_performance_level=high this pins HardMin to peak gfxclk. In PMFW arbitration HardMin has higher priority than SoftMax, so the firmware thermal/PPT throttler cannot clamp gfxclk via SoftMax once HardMin is set to peak. Replace SetHardMinGfxClk with SetSoftMinGfxclk so the driver still requests peak performance but the firmware throttler retains the ability to clamp gfxclk under thermal/PPT pressure. SoftMax handling is unchanged and no other clock domains are affected. Signed-off-by: Priya Hosur Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 3ea273267fd29cbf6d83ee72329f59eb5042605b) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 932642791cb1513118847370f4cbe09d69400eed Author: Yang Wang Date: Fri May 29 11:47:31 2026 +0800 drm/amd/pm: mark metrics.energy_accumulator is invalid for smu 14.0.2 commit ee193c5bbd5e2b56bbeb54ef554414b43a6fc896 upstream. EnergyAccumulator is unsupported on SMU 14.0.2, mark it invalid. Signed-off-by: Yang Wang Reviewed-by: Asad Kamal Signed-off-by: Alex Deucher (cherry picked from commit 646b05043eeed04b51c14aad22a400a8250af4b7) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 8979ded4d8997cdaba94a6c58be2ad069c720ee8 Author: Yang Wang Date: Tue May 19 11:18:12 2026 +0800 drm/amd/pm: fix smu13 power limit default/cap calculation commit bb204f19e4a115f094a6a3c4d82fcf48862d0766 upstream. smu_v13_0_0_get_power_limit() and smu_v13_0_7_get_power_limit() mix runtime power_limit with PP table limits when reporting default/min/max. When current power limit query succeeds, default_power_limit was set to the runtime value instead of the PP table default, and min/max could be derived from inconsistent bases (MsgLimits/runtime), leading to incorrect cap info. Use SocketPowerLimitAc/Dc as the PP default base (pp_limit), keep current_power_limit as runtime value, and derive min/max from pp_limit with OD percentages. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5227 Signed-off-by: Yang Wang Reviewed-by: Kenneth Feng Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher (cherry picked from commit 1eaf26db95901ca70737503a89b831dd763c8453) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 39b5397bf8de2c5f110a0599707a7b1e0dbc6bf3 Author: Vitaly Prosyak Date: Fri May 29 13:50:38 2026 -0400 drm/amdgpu: set noretry=1 as default for GFX 10.1.x (Navi10/12/14) commit e47b0056a08dc70430ffc44bbf62197e7d1ff8ea upstream. Problem: While developing the amd_close_race IGT test (which intentionally triggers execute permission faults by removing VM_PAGE_EXECUTABLE from GPU page table entries), we discovered that on Navi10 (GFX 10.1.x) these faults produce zero diagnostic output. The GPU simply hangs silently for ~10s until the scheduler timeout fires. There is no way to distinguish an execute permission fault from any other type of GPU hang. Root cause: GFX 10.1.x defaults to noretry=0, which sets RETRY_PERMISSION_OR_INVALID_PAGE_FAULT=1 in the GFXHUB UTCL2 registers (gfxhub_v2_0.c line 313). With this bit set, permission faults (valid PTE, wrong R/W/X bits) are handled entirely within the UTCL1/UTCL2 hardware loop: UTCL2 returns an XNACK to UTCL1, and UTCL1 re-requests the translation indefinitely, expecting software to eventually fix the permission bits (as happens in SVM/HMM recovery). No interrupt of any kind reaches the IH ring. This is different from invalid-page faults (V=0) which DO generate a retry fault interrupt that the driver can escalate to a no-retry fault. Permission faults with valid PTEs loop silently forever in hardware. GFX 10.3+ already defaults to noretry=1, which makes permission faults generate immediate L2 protection fault interrupts. GFX 10.1.x was inadvertently left out of this default. Fix: Change the noretry=1 threshold from IP_VERSION(10, 3, 0) to IP_VERSION(10, 1, 0) in amdgpu_gmc_noretry_set(). This is a one-line change that aligns GFX 10.1.x behavior with GFX 10.3+ and all newer generations. With noretry=1, the existing non-retry fault handler (gmc_v10_0_process_interrupt) already decodes and prints the full GCVM_L2_PROTECTION_FAULT_STATUS register including PERMISSION_FAULTS, faulting address, VMID, PASID, and process name. No additional logging code is needed — the fix is purely routing permission faults to the existing, fully-capable non-retry interrupt handler. v2: Dropped GFX10-specific logging from gmc_v10_0.c and kfd_int_process_v10.c (Felix Kuehling). v1 added logging in the retry fault handler, but with noretry=1 permission faults take the non-retry path — the v1 retry handler code was dead and would never execute. Tested on Navi10 (GFX 10.1.10): - Execute permission faults now produce immediate, clear output: [gfxhub] page fault (src_id:0 ring:64 vmid:4 pasid:592) Process amd_close_race pid 13380 thread amd_close_race pid 13384 in page at address 0x40001000 from client 0x1b (UTCL2) GCVM_L2_PROTECTION_FAULT_STATUS:0x00700881 PERMISSION_FAULTS: 0x8 - No regressions with properly-mapped GPU workloads Cc: Christian Koenig Cc: Alex Deucher Cc: Felix Kuehling Signed-off-by: Vitaly Prosyak Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit eb21edd24c40d81066753f8ac6f23bce15745395) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit fcd51a085e9a0d01315606e9d2dad1732563faf2 Author: Christian König Date: Wed Feb 25 15:12:02 2026 +0100 drm/amdgpu: restart the CS if some parts of the VM are still invalidated commit 40396ffdf6120e2380706c59e1a84d7e765a37b6 upstream. Make sure that we only submit work with full up to date VM page tables. Backport to 7.1 and older. Signed-off-by: Christian König Reviewed-by: Vitaly Prosyak Tested-by: Vitaly Prosyak Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 59720bfd8c6dbebeb8d5a7ab64241b007efd9213) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 68455b117258243e73b9697d15a570158ad93e1c Author: Christian König Date: Wed Feb 18 13:05:46 2026 +0100 drm/amdgpu: fix waiting for all submissions for userptrs commit 58bafc666c484b21839a2d27e923ae1b2727a1df upstream. Wait for all submissions when userptrs need to be invalidated by the MMU notifier, not just the one the userptr was involved into. Signed-off-by: Christian König Reviewed-by: Vitaly Prosyak Tested-by: Vitaly Prosyak Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 91250893cbaa25c86872deca95a540d08de1f91e) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 9655b56b6de918e1c22b92f3880ae41b052cbd00 Author: Maíra Canal Date: Tue Jun 2 14:50:15 2026 -0300 drm/v3d: Skip CSD when it has zeroed workgroups commit 7f93fad5ea0affc9e1505dd0f7596c0fdb496213 upstream. A compute shader dispatch encodes its workgroup counts in the CFG0..CFG2 registers. Kicking off a dispatch with a zero count in any of the three dimensions is invalid. First, the hardware will process 0 as 65536, while the user-space driver exposes a maximum of 65535. Over that, a submission with a zeroed workgroup dimension should be a no-op. These zeroed counts can reach the dispatch path through an indirect CSD job, whose workgroup counts are only known once the indirect buffer is read and may legitimately be zero, but such scenario should only result in a no-op. Overwrite the indirect CSD job workgroup counts with the indirect BO ones, even if they are zeroed, and don't submit the job to the hardware when any of the workgroup counts is zero, so the job completes immediately instead of running the shader. Cc: stable@vger.kernel.org Fixes: d223f98f0209 ("drm/v3d: Add support for compute shader dispatch.") Suggested-by: Jose Maria Casanova Crespo Reviewed-by: Iago Toral Quiroga Link: https://patch.msgid.link/20260602-v3d-fix-indirect-csd-v4-2-654309e32bc0@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Greg Kroah-Hartman commit 90b629269088a9fe24a02c032be9f08357f47873 Author: Maíra Canal Date: Tue Jun 2 14:50:14 2026 -0300 drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups commit ae7676952790f421c40918e2586a2c9f12a682b6 upstream. v3d_rewrite_csd_job_wg_counts_from_indirect() maps both the indirect buffer and the workgroup buffer and is expected to release them before returning. When any of the workgroup counts read from the buffer is zero, the function bailed out early and skipped the cleanup, leaking the vaddr mappings of both BOs. Jump to the cleanup path instead of returning directly, so the mappings are always dropped. Cc: stable@vger.kernel.org Fixes: 18b8413b25b7 ("drm/v3d: Create a CPU job extension for a indirect CSD job") Suggested-by: Jose Maria Casanova Crespo Reviewed-by: Iago Toral Quiroga Link: https://patch.msgid.link/20260602-v3d-fix-indirect-csd-v4-1-654309e32bc0@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Greg Kroah-Hartman commit 3e1947573140a57119294f0bff39ee18d93f23e1 Author: Maíra Canal Date: Sun May 31 17:18:55 2026 -0300 drm/v3d: Fix global performance monitor reference counting commit 6bf7e2affc6e62da7add393d7f352d4040f5bc27 upstream. In the SET_GLOBAL ioctl, v3d_perfmon_find() bumps the reference count on the perfmon it returns, but v3d_perfmon_set_global_ioctl() and v3d_perfmon_delete() fail to release that reference on several paths: 1. v3d_perfmon_set_global_ioctl() leaks the reference on its error paths. 2. CLEAR_GLOBAL leaks both the find reference and the reference previously stashed in v3d->global_perfmon by the SET_GLOBAL ioctl that configured it. 3. Destroying a perfmon that is the current global perfmon leaks the reference stashed by the SET_GLOBAL ioctl. Release each of these references explicitly. Cc: stable@vger.kernel.org Fixes: c6eabbab359c ("drm/v3d: Add DRM_IOCTL_V3D_PERFMON_SET_GLOBAL") Reviewed-by: Iago Toral Quiroga Link: https://patch.msgid.link/20260531-v3d-perfmon-lifetime-v2-1-60ed4485a203@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Greg Kroah-Hartman commit 11e9bdf8824b9e4e3c06d532c2663edb797c06f0 Author: Maíra Canal Date: Sat May 30 15:37:42 2026 -0300 drm/v3d: Wait for pending L2T flush before cleaning caches commit abf888b03a9805a3bc37948a0df443553b1c0910 upstream. v3d_clean_caches() starts the cache-clean sequence by writing V3D_L2TCACTL_TMUWCF to V3D_CTL_L2TCACTL and then polling for that bit to clear. It does not, however, check for an L2T flush (L2TFLS) that may still be in flight from a previous operation. On pre-V3D 7.1 hardware, kicking off the TMU write-combiner flush while an L2T flush is still pending can clobber bits in L2TCACTL and cause cache inconsistencies. Poll for L2TFLS to clear before writing L2TCACTL on V3D < 7.1, ensuring any pending flush has completed before a new clean is issued. Cc: stable@vger.kernel.org Fixes: d223f98f0209 ("drm/v3d: Add support for compute shader dispatch.") Link: https://patch.msgid.link/20260530-v3d-fix-rpi4-freezes-v1-1-c2c8307da6ce@igalia.com Signed-off-by: Maíra Canal Reviewed-by: Iago Toral Quiroga Signed-off-by: Greg Kroah-Hartman commit 4c10fd55187aaf7882bbb281ca37d6729198821e Author: Tangudu Tilak Tirumalesh Date: Wed Jun 3 12:22:16 2026 +0530 drm/xe: Clear pending_disable before signaling suspend fence commit 54f2a0442a30fe7a0f6bc8345e81f8b2db8effbd upstream. In the schedule-disable done path for suspend, we signal the suspend fence before clearing pending_disable. That wakeup can let suspend_wait complete and resume be queued immediately. The resume path may then reach enable_scheduling() while pending_disable is still set and hit the !exec_queue_pending_disable(q) assertion. Fix this by clearing pending_disable before signaling the suspend fence, so any resumed transition observes a consistent state. Fixes: 87651f31ae4e ("drm/xe/guc_submit: fix race around suspend_pending") Cc: stable@vger.kernel.org # v7.0+ Signed-off-by: Tangudu Tilak Tirumalesh Reviewed-by: Thomas Hellstrom Signed-off-by: Daniele Ceraolo Spurio Link: https://patch.msgid.link/20260603065217.3131066-3-tilak.tirumalesh.tangudu@intel.com (cherry picked from commit 4b1ae138b0e103d753773956a84eebc2edbf62c4) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 0f68ddfaaebfbb5581ee931779757d31f4dc9e24 Author: Jani Nikula Date: Fri May 15 19:09:20 2026 +0300 drm/xe/display: fix oops in suspend/shutdown without display commit 68938cc08e23a94fd881e845837ff918de005ce7 upstream. The xe driver keeps track of whether to probe display, and whether display hardware is there, using xe->info.probe_display. It gets set to false if there's no display after intel_display_device_probe(). However, the display may also be disabled via fuses, detected at a later time in intel_display_device_info_runtime_init(). In this case, the xe driver does for_each_intel_crtc() on uninitialized mode config in xe_display_flush_cleanup_work(), leading to a NULL pointer dereference, and generally calls display code with display info cleared. Check for intel_display_device_present() after intel_display_device_info_runtime_init(), and reset xe->info.probe_display as necessary. Also do unset_display_features() for completeness, although display runtime init has already done that. This will need to be unified across all cases later. Move intel_display_device_info_runtime_init() call slightly earlier, similar to i915, to avoid a bunch of unnecessary setup for no display cases. Note #1: The xe driver has no business doing low level display plumbing like for_each_intel_crtc() to begin with. It all needs to happen in display code. Note #2: The actual bug is present already in commit 44e694958b95 ("drm/xe/display: Implement display support"), but the oops was likely introduced later at commit ddf6492e0e50 ("drm/xe/display: Make display suspend/resume work on discrete"). Fixes: 44e694958b95 ("drm/xe/display: Implement display support") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7904 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/6150 Cc: stable@vger.kernel.org # v6.8+ Reviewed-by: Suraj Kandpal Link: https://patch.msgid.link/20260515160920.1082842-1-jani.nikula@intel.com Signed-off-by: Jani Nikula (cherry picked from commit 7c3eb9f47533220888a67266448185fd0775d4da) Signed-off-by: Matthew Brost Signed-off-by: Greg Kroah-Hartman commit d3efcadfe3eea5b4263b8f2d4463b15c9fc46a64 Author: Andrew Martin Date: Thu May 28 12:54:39 2026 -0400 drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11 commit 352ea59028ea48a6fff77f19ae28f98f71946a80 upstream. The v11 MQD manager incorrectly assigned the CP-compute variants of checkpoint_mqd/restore_mqd for KFD_MQD_TYPE_SDMA queues. These functions use sizeof(struct v11_compute_mqd) (2048 bytes) instead of sizeof(struct v11_sdma_mqd) (512 bytes), causing a 1536-byte overflow. During CRIU checkpoint of an SDMA queue on Navi3x: - checkpoint_mqd() reads 2048 bytes from a 512-byte SDMA MQD buffer, leaking 1536 bytes of adjacent GTT memory to userspace During CRIU restore: - restore_mqd() writes 2048 bytes into a 512-byte SDMA MQD buffer, corrupting 1536 bytes of adjacent GTT memory (often the ring buffer or neighboring MQDs) This is a copy-paste regression unique to v11. All other ASIC backends (cik, vi, v9, v10, v12) correctly use the SDMA-specific variants. Add checkpoint_mqd_sdma() and restore_mqd_sdma() functions that properly handle the smaller v11_sdma_mqd structure, matching the pattern used in other MQD managers. Fixes: cc009e613de6 ("drm/amdkfd: Add KFD support for soc21 v3") Assisted-by: Claude:Sonnet 4-5 Signed-off-by: Andrew Martin Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 6fa41db7ffdec97d62433adf03b7b9b759af8c2c) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 72e259a32084c42816152c346096d2edd4213e23 Author: Muhammad Bilal Date: Sat May 23 16:56:46 2026 +0000 drm/amdkfd: fix NULL dereference in get_queue_ids() commit 2bd550b547deabef98bd3b017ff743b7c34d3a6d upstream. When usr_queue_id_array is NULL and num_queues is non-zero, get_queue_ids() returns NULL. The callers check only IS_ERR() on the return value; since IS_ERR(NULL) == false the check passes, and suspend_queues() calls q_array_invalidate() which immediately dereferences NULL while iterating num_queues times. Userspace can trigger this via kfd_ioctl_set_debug_trap() by supplying num_queues > 0 with a zero queue_array_ptr, causing a kernel panic. A NULL usr_queue_id_array with num_queues == 0 is a legitimate no-op (q_array_invalidate never executes, and resume_queues already guards all queue_ids dereferences behind a NULL check). Return ERR_PTR(-EINVAL) only when num_queues is non-zero and the pointer is absent; both callers already propagate IS_ERR() returns correctly to userspace. Fixes: a70a93fa568b ("drm/amdkfd: add debug suspend and resume process queues operation") Signed-off-by: Muhammad Bilal Signed-off-by: Alex Deucher (cherry picked from commit f165a82cdf503884bb1797771c61b2fcc72113d4) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit c0639ede2f24ac224b2079cd35ecd5fd8ad4e3cd Author: Simona Vetter Date: Thu Jun 4 21:44:37 2026 +0200 drm/gem: Try to fix change_handle ioctl, attempt 4 commit 1a4f03d22fb655e5f192244fb2c87d8066fcfca2 upstream. [airlied: just added some comments on how to reenable] On-list because the cat is out of the bag and we're clearly not good enough to figure this out in private. The story thus far: 5e28b7b94408 ("drm: Set old handle to NULL before prime swap in change_handle") tried to fix a race condition between the gem_close and gem_change_handle ioctls, but got a few things wrong: - There's a confusion with the local variable handle, which is actually the new handle, and so the two-stage trick was actually applied to the wrong idr slot. 7164d78559b0 ("drm/gem: fix race between change_handle and handle_delete") tried to fix that by adding yet another code block, but forgot to add the error handling. Which meant we now have two paths, both kinda wrong. - dc366607c41c ("drm: Replace old pointer to new idr") tried to apply another fix, but inconsistently, again because of the handle confusion - this would be the right fix (kinda, somewhat, it's a mess) if we'd do the two-stage approach for the new handle. Except that wasn't the intent of the original fix. We also didn't have an igt merged for the original ioctl, which is a big no-go. This was attempted to address off-list in the original bugfix, and amd QA people claimed the bug was fixed now. Very clearly that's not the case. Here's my attempt to sort this out: - Rename the local variable to new_handle, the old aliasing with args->handle is just too dangerously confusing. - Merge the gem obj lookup with the two-stage idr_replace so that we avoid getting ourselves confused there. - This means we don't have a surplus temporary reference anymore, only an inherited from the idr. A concurrent gem_close on the new_handle could steal that. Fix that with the same two-stage approach create_tail uses. This is a bit overkill as documented in the comment, but I also don't trust my ability to understand this all correctly, so go with the established pattern we have from other ioctls instead for maximum paranoia. - Adjust error paths. I've tried to make the error and success paths common, because they are identical except for which handle is removed and on which we call idr_replace to (re)install the object again. But that made things messier to read, so I've left it at the more verbose version, which unfortunately hides the symmetry in the entire code flow a bit. - While at it, also replace the 7 space indent with 1 tab. And finally, because I flat out don't trust my abilities here at all anymore: - Disable the ioctl until we have the igt situation and everything else sorted out on-list and with full consensus. v2: Sashiko noticed that I didn't handle the error path for idr_replace correctly, it must be checked with IS_ERR_OR_NULL like in gem_handle_delete. So yeah, definitely should just the existing paths 1:1 because this is endless amounts of tricky. Also add the Fixes: line for the original ioctl, I forgot that too. Reported-by: DARKNAVY (@DarkNavyOrg) Signed-off-by: Simona Vetter Fixes: dc366607c41c ("drm: Replace old pointer to new idr") Cc: syzbot+d7c9eed171647e421013@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Cc: Edward Adam Davis Cc: Dave Airlie Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Fixes: 5e28b7b94408 ("drm: Set old handle to NULL before prime swap in change_handle") Cc: David Francis Cc: Puttimet Thammasaeng Cc: Christian Koenig Fixes: 7164d78559b0 ("drm/gem: fix race between change_handle and handle_delete") Cc: Zhenghang Xiao Fixes: 5e28b7b94408 ("drm: Set old handle to NULL before prime swap in change_handle") Reviewed-by: David Francis Signed-off-by: Dave Airlie Link: https://patch.msgid.link/20260604194437.1725314-1-simona.vetter@ffwll.ch Signed-off-by: Greg Kroah-Hartman commit 9f0d45d509b434c54da10e01f4ef8086e4583401 Author: Bjorn Andersson Date: Sat May 30 21:44:21 2026 +0100 slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock commit 55f2ea9ff83cc27a85526b14bc9b32f96a08d6ec upstream. During the SSR/PDR down notification the tx_lock is taken with the intent to provide synchronization with active DMA transfers. But during this period qcom_slim_ngd_down() is invoked, which ends up in slim_report_absent(), which takes the slim_controller lock. In multiple other codepaths these two locks are taken in the opposite order (i.e. slim_controller then tx_lock). The result is a lockdep splat, and a possible deadlock: rprocctl/449 is trying to acquire lock: ffff00009793e620 (&ctrl->lock){+.+.}-{4:4}, at: slim_report_absent (drivers/slimbus/core.c:322) slimbus but task is already holding lock: ffff00009793fb50 (&ctrl->tx_lock){+.+.}-{4:4}, at: qcom_slim_ngd_ssr_pdr_notify (drivers/slimbus/qcom-ngd-ctrl.c:1475) slim_qcom_ngd_ctrl which lock already depends on the new lock. Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ctrl->tx_lock); lock(&ctrl->lock); lock(&ctrl->tx_lock); lock(&ctrl->lock); The assumption is that the comment refers to the desire to not call qcom_slim_ngd_exit_dma() while we have an ongoing DMA TX transaction. But any such transaction is initiated and completed within a single qcom_slim_ngd_xfer_msg(). Prior to calling qcom_slim_ngd_exit_dma() the slim_controller is torn down, all child devices are notified that the slimbus is gone and the child devices are removed. Stop taking the tx_lock in qcom_slim_ngd_ssr_pdr_notify() to avoid the deadlock. Fixes: a899d324863a ("slimbus: qcom-ngd-ctrl: add Sub System Restart support") Cc: stable@vger.kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260530204421.116824-9-srini@kernel.org Signed-off-by: Greg Kroah-Hartman commit 8f4b371f4939361926ec3f7eaa27ec87565b0374 Author: Bjorn Andersson Date: Sat May 30 21:44:20 2026 +0100 slimbus: qcom-ngd-ctrl: Balance pm_runtime enablement for NGD commit 6a003446b725c44b9e3ffa111b0effbaa2d43085 upstream. The pm_runtime_enable() and pm_runtime_use_autosuspend() calls are supposed to be balanced on exit, add these calls. Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver") Cc: stable@vger.kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260530204421.116824-8-srini@kernel.org Signed-off-by: Greg Kroah-Hartman commit 5204cd22c1c7f5dc82f557a5231786eca3ae8fde Author: Bjorn Andersson Date: Sat May 30 21:44:17 2026 +0100 slimbus: qcom-ngd-ctrl: Correct PDR and SSR cleanup ownership commit 960b53a3f76fa214c2fc493734ae7b3c5e713bbf upstream. PDR and SSR callbacks are registred from the controller probe function, but currently released from the child device's remove function. The remove() function should only be unwinding what was done in the same device's probe() function. Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver") Cc: stable@vger.kernel.org Reviewed-by: Dmitry Baryshkov Reviewed-by: Mukesh Ojha Signed-off-by: Bjorn Andersson Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260530204421.116824-5-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit dd8e1025a84e0b556fa17b16e71ad3159c0ca3f2 Author: Bjorn Andersson Date: Sat May 30 21:44:19 2026 +0100 slimbus: qcom-ngd-ctrl: Initialize controller resources in controller commit 07c564ea5fb859b7381429de935d5df4781947c6 upstream. The work structs and work queue are controller resources, create and destroy them in the controller context. Creating them as part of the child device's probe path seems to be okay now that the controller's probe has been updated, but if for some reason the child does not probe successfully a SSR or PDR notification will schedule_work() on an uninitialized "ngd_up_work". Move the initialization of these controller resources to the controller probe function to avoid any issues, and to clarify the ownership. Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver") Cc: stable@vger.kernel.org Reviewed-by: Dmitry Baryshkov Reviewed-by: Mukesh Ojha Signed-off-by: Bjorn Andersson Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260530204421.116824-7-srini@kernel.org Signed-off-by: Greg Kroah-Hartman commit 24ec89123fc9d0d24ce719dcf7fd6c57e5b0d753 Author: Bjorn Andersson Date: Sat May 30 21:44:18 2026 +0100 slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd commit 2a9d50e9ea406e0c8735938484adc20515ef1b47 upstream. When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards. One such example can be seen in the following fault, where qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work. [ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] __queue_work+0x5e0/0x790 (P) [ 21.859265] queue_work_on+0x6c/0xf0 [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl] [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl] [ 21.859318] notifier_call_chain+0xa4/0x230 [ 21.859329] srcu_notifier_call_chain+0x64/0xb8 [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common] [ 21.859355] rproc_start+0x130/0x230 [ 21.859367] rproc_boot+0x3d4/0x518 ... Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered. This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture. Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver") Cc: stable@vger.kernel.org Reviewed-by: Mukesh Ojha Signed-off-by: Bjorn Andersson Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260530204421.116824-6-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 3bb2ac834ed391f15731547bcc8b8df12ce7a521 Author: Bjorn Andersson Date: Sat May 30 21:44:16 2026 +0100 slimbus: qcom-ngd-ctrl: Fix probe error path ordering commit 2c22ff152d380ec3d3af099fa05d0ac5ca9b4c1e upstream. qcom_slim_ngd_ctrl_probe() first registers the SSR callback then allocates the PDR context, as such the error path needs to come in opposite order to allow us to unroll each step. Fixes: 16f14551d0df ("slimbus: qcom-ngd: cleanup in probe error path") Cc: stable@vger.kernel.org Reviewed-by: Dmitry Baryshkov Reviewed-by: Mukesh Ojha Signed-off-by: Bjorn Andersson Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260530204421.116824-4-srini@kernel.org Signed-off-by: Greg Kroah-Hartman commit d6cb003e4661f9bd5321a047c01ae1761412a0f6 Author: Bjorn Andersson Date: Sat May 30 21:44:15 2026 +0100 slimbus: qcom-ngd-ctrl: Fix up platform_driver registration commit 8663e8334d7b6007f5d8a4e5dd270246f35107a6 upstream. Device drivers should not invoke platform_driver_register()/unregister() in their probe and remove paths. They should further not rely on platform_driver_unregister() as their only means of "deleting" their child devices. Introduce a helper to unregister the child device and move the platform_driver_register()/unregister() to module_init()/exit(). Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver") Cc: stable@vger.kernel.org Reviewed-by: Dmitry Baryshkov Reviewed-by: Mukesh Ojha Signed-off-by: Bjorn Andersson Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260530204421.116824-3-srini@kernel.org Signed-off-by: Greg Kroah-Hartman commit 6890bd2451a9e994f9a49f6e4a56770df8d6ed57 Author: Bartosz Golaszewski Date: Sat May 30 21:44:14 2026 +0100 slimbus: qcom-ngd-ctrl: fix OF node refcount commit 120134fe75c6b0ae38f14eb8b548ad1e5761f912 upstream. Platform devices created with platform_device_alloc() call platform_device_release() when the last reference to the device's kobject is dropped. This function calls of_node_put() unconditionally. This works fine for devices created with platform_device_register_full() but users of the split approach (platform_device_alloc() + platform_device_add()) must bump the reference of the of_node they assign manually. Add the missing call to of_node_get(). Cc: stable@vger.kernel.org Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver") Signed-off-by: Bartosz Golaszewski Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260530204421.116824-2-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit b5daa920f44cb582272fc9bfaeb67408776cbaef Author: Michael Bommarito Date: Mon May 25 05:28:29 2026 -0400 thunderbolt: Limit XDomain response copy to actual frame size commit 4db2bd2ed4785dbadaeeab9f4e346b21ac5fb8eb upstream. tb_xdomain_copy() copies req->response_size bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions. Use the minimum of frame size and expected response size for the copy length. Fixes: cdae7c07e3e3 ("thunderbolt: Add support for XDomain properties") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 46da5c3ea011e884028a91cf913db093920a915b Author: Michael Bommarito Date: Mon May 25 05:28:28 2026 -0400 thunderbolt: Validate XDomain request packet size before type cast commit a504b9f2797b739e0304d537e8aa4ce883ecce39 upstream. tb_xdp_handle_request() casts the received packet buffer to protocol-specific structs without verifying that the allocation is large enough for the target type. A peer can send a minimal XDomain packet that passes the generic header length check but is shorter than the struct accessed after the cast, causing out-of- bounds reads from the kmemdup allocation. Plumb the packet length through xdomain_request_work and validate it against the expected struct size before each cast. Fixes: 8e1de7042596 ("thunderbolt: Add support for XDomain lane bonding") Fixes: cdae7c07e3e3 ("thunderbolt: Add support for XDomain properties") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit fcbd0cdab92838854a5818be7ed8a097164ef6d5 Author: Michael Bommarito Date: Mon May 25 05:28:27 2026 -0400 thunderbolt: Clamp XDomain response data copy to allocation size commit 322e93448d908434ae5545660fcbe8f5a7a8e141 upstream. tb_xdp_properties_request() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared data_length, causing memcpy to write past the kcalloc allocation. Clamp the per-packet copy length so that the cumulative offset never exceeds data_len. Fixes: cdae7c07e3e3 ("thunderbolt: Add support for XDomain properties") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 60ba6217460792356a238299edd675d91d46bab4 Author: Michael Bommarito Date: Mon May 25 05:28:26 2026 -0400 thunderbolt: Bound root directory content to block size commit 65423079c7420e3dbf9a7aa345c243a3f5752e5d upstream. __tb_property_parse_dir() does not check that content_offset + content_len fits within block_len for the root directory case. When rootdir->length equals or exceeds block_len - 2, the entry loop reads past the allocated property block. Add a bounds check after computing content_offset and content_len to reject directories whose content extends past the block. Fixes: cdae7c07e3e3 ("thunderbolt: Add support for XDomain properties") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 2e0ddac549ebd713eb9f4a15b6496e3440a17d8b Author: Michael Bommarito Date: Mon May 25 05:28:25 2026 -0400 thunderbolt: Reject zero-length property entries in validator commit cff8eb65d1eafe7793e54b4d0cf6bf831644630b upstream. tb_property_entry_valid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\0'; When property->length is 0 this writes to offset -1 relative to the allocation. Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol. Fixes: cdae7c07e3e3 ("thunderbolt: Add support for XDomain properties") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit d5ea0b3e261fcb2cfff142675516165244cab1da Author: Wyatt Feng Date: Fri Jun 5 13:53:42 2026 +0800 sctp: stream: fully roll back denied add-stream state commit a5f8a90ac9f77c678a9781c0a464b635e0d63e49 upstream. When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions. Fixes: 637784ade221 ("sctp: introduce priority based stream scheduler") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Zhengchuan Liang Reported-by: Xin Liu Signed-off-by: Wyatt Feng Signed-off-by: Ren Wei Acked-by: Xin Long Link: https://patch.msgid.link/d78954ecd94954653ee299400e98d74a03a6f7d3.1780603399.git.bronzed_45_vested@icloud.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 78c4f964b2f94e405721c093773f6250e1e676b2 Author: Zhao Zhang Date: Sat May 30 23:57:14 2026 +0800 sctp: diag: reject stale associations in dump_one path commit 5eba3e48d78edd7551b992cb7ba687019b3a78da upstream. The SCTP exact sock_diag lookup can hold a transport reference, block on lock_sock(sk), and then resume after sctp_association_free() has marked the association dead and freed its bind address list. When that happens, inet_assoc_attr_size() and inet_diag_msg_sctpasoc_fill() can still dereference association state that is no longer valid for reporting. In particular, inet_diag_msg_sctpasoc_fill() may read an empty bind-address list as a real sctp_sockaddr_entry and trigger an out-of-bounds read from unrelated association memory. Reject the association after taking the socket lock if it has been reaped or detached from the endpoint, and report the lookup as stale. This keeps the exact dump-one path from formatting torn association state. Fixes: 8f840e47f190 ("sctp: add the sctp_diag.c file") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Zhengchuan Liang Reported-by: Xin Liu Signed-off-by: Zhao Zhang Signed-off-by: Ren Wei Acked-by: Xin Long Link: https://patch.msgid.link/fac6043fa20a2ff68e12958c431836f692c51268.1780113823.git.zzhan461@ucr.edu Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 566c4c1244de50fbff1f89ff93c9d7b0fc256db4 Author: David Howells Date: Thu Jun 4 12:46:00 2026 +0100 rxrpc: Fix the ACK parser to extract the SACK table for parsing commit 333b6d5bb9f87827ac2639c737bf9613dbae7253 upstream. Fix modification of the received skbuff in rxrpc_input_soft_acks() and a potential incorrect access of the buffer in a fragmented UDP packet (the packet would probably have to be deliberately pre-generated as fragmented) when AF_RXRPC tries to extract the contents of the SACK table by copying out the contents of the SACK table into a buffer before attempting to parse AF_RXRPC assumes that it can just call skb_condense() and then validly access the SACK table from skb->data and that it will be a flat buffer - but skb_condense() can silently fail to do anything under some circumstances. Note that whilst rxrpc_input_soft_acks() should be able to parse extended ACKs, the rest of AF_RXRPC doesn't currently support that. Further, there's then no need to call skb_condense() in rxrpc_input_ack(), so don't. Fixes: d57a3a151660 ("rxrpc: Save last ACK's SACK table rather than marking txbufs") Reported-by: Michael Bommarito Link: https://lore.kernel.org/r/20260513180907.2061972-1-michael.bommarito@gmail.com Signed-off-by: David Howells cc: Marc Dionne cc: Jeffrey Altman cc: Eric Dumazet cc: "David S. Miller" cc: Jakub Kicinski cc: Paolo Abeni cc: Simon Horman cc: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org cc: stable@kernel.org Link: https://patch.msgid.link/105362.1780573560@warthog.procyon.org.uk Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 1bf84f4013fac894dd058f84cc534f8ad461e003 Author: Justin Lai Date: Tue Jun 2 19:46:59 2026 +0800 rtase: Reset TX subqueue when clearing TX ring commit ab1ecaabe74b7d86c38ab2ab44bd56cdcc33645a upstream. rtase_tx_clear() clears the TX ring and resets the ring indexes. However, the TX queue state and BQL accounting are not reset at the same time. This may leave __QUEUE_STATE_STACK_XOFF asserted after rtase_sw_reset(), preventing new TX packets from being scheduled. Reset the TX subqueue when clearing the TX ring so the TX queue state and BQL accounting are restored together. Fixes: 5a2a2f15244c ("rtase: Implement the rtase_down function") Cc: stable@vger.kernel.org Signed-off-by: Justin Lai Reviewed-by: Alexander Lobakin Link: https://patch.msgid.link/20260602114659.12335-1-justinlai0215@realtek.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 54f9cdcd731181dc402770373dee2810f42dfd82 Author: Justin Lai Date: Wed Jun 3 14:18:16 2026 +0800 rtase: Avoid sleeping in get_stats64() commit 9fc237f8d49f06d05f0f8e80361047b718894e81 upstream. The .ndo_get_stats64 callback must not sleep because it can be called when reading /proc/net/dev. rtase_get_stats64() calls rtase_dump_tally_counter(), which polls the tally counter dump bit with read_poll_timeout(). This may sleep while waiting for the hardware counter dump to complete. Use read_poll_timeout_atomic() instead to avoid sleeping in the get_stats64() path. Fixes: 079600489960 ("rtase: Implement net_device_ops") Cc: stable@vger.kernel.org Signed-off-by: Justin Lai Link: https://patch.msgid.link/20260603061816.31356-1-justinlai0215@realtek.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ddcf84b25af0b08b99c27bd5e7104ea4afd86c57 Author: Kendall Willis Date: Wed May 6 22:16:45 2026 -0500 pmdomain: ti_sci: add wakeup constraint to parent devices of wakeup source commit 4db207599acfc9d676340daa2dc6b52bfca17db4 upstream. Set wakeup constraint for any device in a wakeup path. All parent devices of a wakeup device should not be turned off during suspend. This ensures the wakeup device is kept on while the system is suspended. Cc: stable@vger.kernel.org Fixes: 9d8aa0dd3be4 ("pmdomain: ti_sci: add wakeup constraint management") Reported-by: Vitor Soares Closes: https://lore.kernel.org/linux-pm/c0fe43a2339c802e9ce5900092cd530a2ba17a6b.camel@gmail.com/ Signed-off-by: Kendall Willis Reviewed-by: Sebin Francis Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 0d11992d1898b49bc56c33780d612d2fecb72329 Author: Bartosz Golaszewski Date: Thu May 21 10:36:27 2026 +0200 pmdomain: imx: fix OF node refcount commit fba0510cd62666951dcc0221527edc0c47ae6599 upstream. for_each_child_of_node_scoped() decrements the reference count of the nod after each iteration. Assigning it without incrementing the refcount to a dynamically allocated platform device will result in a double put in platform_device_release(). Add the missing call to of_node_get(). Cc: stable@vger.kernel.org Fixes: 3e4d109ee8fc ("pmdomain: imx: gpc: Simplify with scoped for each OF child loop") Signed-off-by: Bartosz Golaszewski Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 0aecf3c7b8f821287c967aeefc93be44911348ad Author: Jisheng Zhang Date: Sun May 24 10:34:55 2026 +0800 mmc: sdhci: add signal voltage switch in sdhci_resume_host commit f595e8e77a51eee35e331f69321766593a845ef2 upstream. I met one suspend/resume issue with sdr104 capable sdio wifi card (with "keep-power-in-suspend" set in DT property): After resuming from suspend to ram, the sdio wifi card stops working. Further debug shows that although ios shows the sdio card is at sdr104 mode, the voltage is still at 3V3. This is due to missing the calling of ->start_signal_voltage_switch() in sdhci_resume_host(). Fix this issue by adding ->start_signal_voltage_switch() in sdhci_resume_host(). This also matches what we do for sdhci_runtime_resume_host(). Then the question is: why this issue hasn't reported and fixed for so long time. IMHO, several reasons: Some host controllers just kick off the runtime resume for system resume, so they benefit from the well supported runtime pm code; Some platforms just use the old sdio wifi card which doesn't need signal voltage switch at all, the default voltage is 3v3 after resuming. Fixes: 6308d2905bd3 ("mmc: sdhci: add quirk for keeping card power during suspend") Signed-off-by: Jisheng Zhang Acked-by: Adrian Hunter Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 535ff092b68601547ec211c644c3fe6de430942d Author: Lad Prabhakar Date: Tue May 19 14:53:40 2026 +0100 mmc: renesas_sdhi: Add OF entry for RZ/G2H SoC commit f48ee49726ee4ab545fd2dc644f169c0809b19b3 upstream. The RZ/G2H (R8A774E1) SoC was previously handled via the generic "renesas,rcar-gen3-sdhi" fallback compatible string. However, because the SDHI IP on RZ/G2H is identical with the R-Car H3-N (R8A77951), it requires the specific quirks and configuration defined in `of_r8a7795_compatible` rather than the generic Gen3 data. Add the explicit "renesas,sdhi-r8a774e1" match entry to map it correctly. Note that the DT binding file renesas,sdhi.yaml does not need an update as the entry for this SoC is already present. Fixes: 31941342888d ("arm64: dts: renesas: r8a774e1: Add SDHI nodes") Cc: stable@vger.kernel.org Signed-off-by: Lad Prabhakar Reviewed-by: Wolfram Sang Reviewed-by: Geert Uytterhoeven Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 2f72d36f8accd53f9e09e27325826f219e70d820 Author: Inochi Amaoto Date: Thu May 21 15:21:21 2026 +0800 mmc: litex_mmc: Set mandatory idle clocks before CMD0 commit 99982b743e5ba72bd1f5de0e03e3b96ae70b1e51 upstream. The litex_mmc driver assumes the card is already probed in the BIOS and skip the phy initialization. This will cause the command fail like the following when the old card is unplugged and then insert a new card: [ 62.923593] litex-mmc f0004000.mmc: Command (cmd 8) error, status -110 [ 62.949717] litex-mmc f0004000.mmc: Command (cmd 55) error, status -110 [ 62.976606] litex-mmc f0004000.mmc: Command (cmd 55) error, status -110 [ 63.002516] litex-mmc f0004000.mmc: Command (cmd 55) error, status -110 [ 63.028442] litex-mmc f0004000.mmc: Command (cmd 55) error, status -110 Add required clock settings and initialization for the CMD 0, so it can probe the new card. Fixes: 92e099104729 ("mmc: Add driver for LiteX's LiteSDCard interface") Signed-off-by: Inochi Amaoto Reviewed-by: Gabriel Somlo Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 7f8007be13e6cc1e0a508fe461f9a91ba9a28b8c Author: Heiko Stuebner Date: Fri May 22 20:43:07 2026 +0200 mmc: dw_mmc-rockchip: Add missing private data for very old controllers commit 1e9a4850afa0ceb63984fb1a9f3e86d0fc4fd18f upstream. The really old controllers (rk2928, rk3066, rk3188) do not support UHS speeds at all, and thus never handled phase data. For that reason it never had a parse_dt callback and no driver private data at all. Commit ff6f0286c896 ("mmc: dw_mmc-rockchip: Add memory clock auto-gating support") makes the private data sort of mandatory, because the init function checks whether phases are configured internally or through the clock controller. This results in the old SoCs then experiencing NULL-pointer dereferences when they try to access that private-data struct. While we could have if (priv) conditionals in all places, it's way less cluttery to just give the old types their private-data struct. Fixes: ff6f0286c896 ("mmc: dw_mmc-rockchip: Add memory clock auto-gating support") Cc: stable@vger.kernel.org Signed-off-by: Heiko Stuebner Acked-by: Shawn Lin Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit c677b13671dc5195114aa25da85b29186fd80399 Author: Kamal Dasu Date: Thu Apr 23 15:18:55 2026 -0400 mmc: core: Fix host controller programming for fixed driver type commit 5a52c5701a67d5176eb1afbf1bdaf7d6dfeec597 upstream. When using the fixed-emmc-driver-type device tree property, the MMC core correctly selects the driver strength for the card but fails to program the host controller accordingly. This causes a mismatch where the card uses the specified driver type while the host controller defaults to Type B (since ios->drv_type remains zero). Split the driver type programming logic to handle both fixed and dynamic driver type selection paths. For fixed driver types, program the host controller with the selected drive_strength value. For dynamic selection, use the existing drv_type as before. This ensures both the eMMC device and host controller use matching driver strengths, preventing potential signal integrity issues. Fixes: 6186d06c519e ("mmc: parse new binding for eMMC fixed driver type") Signed-off-by: Kamal Dasu Reviewed-by: Shawn Lin Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit a8f91ddf67f669f547bb9fb559738da6f8ee2cf3 Author: Usama Arif Date: Tue Jun 2 10:22:47 2026 -0700 mm/mincore: handle non-swap entries before !CONFIG_SWAP guard commit 0c25b8734367574e21aeb8468c2e522713134da7 upstream. mincore_swap() also fields migration/hwpoison entries (and shmem swapin-error entries), which can exist on !CONFIG_SWAP builds when CONFIG_MIGRATION or CONFIG_MEMORY_FAILURE is enabled. The !IS_ENABLED(CONFIG_SWAP) guard ran before the non-swap-entry early return, so mincore_pte_range() can spuriously WARN and report these pages nonresident on !CONFIG_SWAP kernels. Move the guard below the non-swap-entry check so only true swap entries trip the WARN, and migration/hwpoison entries take the existing "uptodate / non-shmem" path. Link: https://lore.kernel.org/20260602172247.279421-1-usama.arif@linux.dev Fixes: 1f2052755c15 ("mm/mincore: use a helper for checking the swap cache") Signed-off-by: Usama Arif Reviewed-by: Pedro Falcato Reviewed-by: Kairui Song Reviewed-by: Lorenzo Stoakes Acked-by: Johannes Weiner Cc: Baoquan He Cc: Chris Li Cc: Jann Horn Cc: Liam R. Howlett Cc: Rik van Riel Cc: Shakeel Butt Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit c19ff4351214f059349788e13e70e74325831ff6 Author: Shakeel Butt Date: Mon Jun 1 09:15:01 2026 -0700 mm/list_lru: drain before clearing xarray entry on reparent commit 98733f3f0becb1ae0701d021c1748e974e5fa55c upstream. memcg_reparent_list_lrus() clears the dying memcg's xarray entry with xas_store(&xas, NULL) before reparenting its per-node lists into the parent. This opens a window where a concurrent list_lru_del() arriving for the dying memcg sees xa_load() == NULL, walks to the parent in lock_list_lru_of_memcg(), takes the parent's per-node lock, and calls list_del_init() on an item still physically linked on the dying memcg's list. If another in-flight thread holds the dying memcg's per-node lock at the same moment (another list_lru_del, or a list_lru_walk_one running an isolate callback), both threads modify ->next/->prev pointers on the same physical list under different locks. Adjacent items can corrupt each other's links. Fix it by reversing the order: reparent each per-node list and mark the child's list lru dead and then clear the xarray entry. Any concurrent list_lru op that finds the still-set xarray entry either takes the dying memcg's per-node lock (synchronizing with the drain) or sees LONG_MIN and walks to the parent, where the items now live. Link: https://lore.kernel.org/20260601161501.1444829-1-shakeel.butt@linux.dev Fixes: fb56fdf8b9a2 ("mm/list_lru: split the lock to per-cgroup scope") Signed-off-by: Shakeel Butt Reported-by: Chris Mason Reviewed-by: Kairui Song Acked-by: Muchun Song Cc: Dave Chinner Cc: Johannes Weiner Cc: Roman Gushchin Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit c72469ac0f274bde3f0df60a4584e14a123d0aa6 Author: David Carlier Date: Wed May 20 05:49:12 2026 +0100 mm/hugetlb: restore reservation on error in hugetlb folio copy paths commit 40c81856e622a9dc59294a90d169ac07ea25b0b0 upstream. Two sites in mm/hugetlb.c allocate a hugetlb folio via alloc_hugetlb_folio() (consuming a VMA reservation) and then call copy_user_large_folio(), which became int-returning in commit 1cb9dc4b475c ("mm: hwpoison: support recovery from HugePage copy-on-write faults") and can now fail (e.g. -EHWPOISON on a hwpoisoned source page). On the failure path, folio_put() restores the global hugetlb pool count through free_huge_folio(), but the per-VMA reservation map entry is left marked consumed: - hugetlb_mfill_atomic_pte() resubmission path (UFFDIO_COPY) - copy_hugetlb_page_range() fork-time CoW path when hugetlb_try_dup_anon_rmap() fails (rare: pinned hugetlb anon folio under fork) User-visible effect: on UFFDIO_COPY into a private hugetlb VMA where the resubmission copy fails, the reservation for that address is leaked from the VMA's reserve map. A subsequent fault at the same address takes the no-reservation path, and under hugetlb pool pressure the task is SIGBUSed at an address it had previously reserved. The fork-time CoW path leaks the same way in the child VMA's reserve map, though it requires the much rarer combination of pinned hugetlb anon page + hwpoisoned source. Add the missing restore_reserve_on_error() call before folio_put() on both error paths. Link: https://lore.kernel.org/20260520044912.6751-1-devnexen@gmail.com Fixes: 1cb9dc4b475c ("mm: hwpoison: support recovery from HugePage copy-on-write faults") Signed-off-by: David Carlier Reviewed-by: Muchun Song Cc: David Hildenbrand Cc: Mina Almasry Cc: Muchun Song Cc: Oscar Salvador Cc: yuehaibing Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit ecc24f0a8a3027cdb74157422fe154c58cbb25f0 Author: Lorenzo Stoakes Date: Wed May 13 09:56:58 2026 +0100 mm/hugetlb: avoid false positive lockdep assertion commit b4aea43cd37afad714b5684fe9fdfcb0e78dba26 upstream. Commit 081056dc00a2 ("mm/hugetlb: unshare page tables during VMA split, not before") changed the locking model around hugetlbfs PMD unsharing on VMA split, but did not update the function which asserts the locks, hugetlb_vma_assert_locked(). This function asserts that either the hugetlb VMA lock is held (if a shared mapping) or that the reservation map lock is held (if private). If you get an unfortunate race between something which results in one of these locks being released and a hugetlb VMA split and you have CONFIG_LOCKDEP enabled, you can therefore see a false positive assertion arise when there is in fact no issue. Since this change introduced a new take_locks parameter to hugetlb_unshare_pmds(), which, when set to false, indicates that locking is sufficient, simply pass this to the unsharing logic and predicate the lock assertions on this. This is safe, as we already asserted the file rmap lock and the VMA write lock prior to this (implying exclusive mmap write lock), so we cannot be raced by either rmap or page fault page table walkers which the asserted locks are intended to protect against (we don't mind GUP-fast). Separate out huge_pmd_unshare() into __huge_pmd_unshare() to add a check_locks parameter, and update hugetlb_unshare_pmds() to pass this parameter to it. This leaves all other callers of huge_pmd_unshare() still correctly asserting the locks. The below reproducer will trigger the assert in a kernel with CONFIG_LOCKDEP enabled by racing process teardown (which will release the hugetlb lock) against a hugetlb split. void execute_one(void) { void *ptr; pid_t pid; /* * Create a hugetlb mapping spanning a PUD entry. * * We force the hugetlb page allocation with populate and * noreserve. * * |---------------------| * | | * |---------------------| * 0 PUD boundary */ ptr = mmap(0, PUD_SIZE, PROT_READ | PROT_WRITE, MAP_FIXED | MAP_SHARED | MAP_ANON | MAP_NORESERVE | MAP_HUGETLB | MAP_POPULATE, -1, 0); if (ptr == MAP_FAILED) { perror("mmap"); exit(EXIT_FAILURE); } /* * Fork but with a bogus stack pointer so we try to execute code in * a non-VM_EXEC VMA, causing segfault + teardown via exit_mmap(). * * The clone will cause PMD page table sharing between the * processes first via: * copy_process() -> ... -> huge_pte_alloc() -> huge_pmd_share() * * Then tear down and release the hugetlb 'VMA' lock via: * exit_mmap() -> ... -> vma_close() -> hugetlb_vma_lock_free() */ pid = syscall(__NR_clone, 0, 2 * PMD_SIZE, 0, 0, 0); if (pid < 0) { perror("clone"); exit(EXIT_FAILURE); } if (pid == 0) { /* Pop stack... */ return; } /* * We are the parent process. * * Race the child process's teardown with a PMD unshare. * * We do this by triggering: * * __split_vma() -> hugetlb_split() -> hugetlb_unshare_pmds() * * Which, importantly, doesn't hold the hugetlb VMA lock (nor can * it), meaning we assert in hugetlb_vma_assert_locked(). * * . * |----------.----------| * | . | * |----------.----------| * 0 . PUD boundary */ mmap(0, PUD_SIZE / 2, PROT_READ | PROT_WRITE, MAP_FIXED | MAP_ANON | MAP_PRIVATE, -1, 0); } int main(void) { int i; /* Kick off fork children. */ for (i = 0; i < NUM_FORKS; i++) { pid_t pid = fork(); if (pid < 0) { perror("fork"); exit(EXIT_FAILURE); } /* Fork children do their work and exit. */ if (!pid) { int j; for (j = 0; j < NUM_ITERS; j++) execute_one(); return EXIT_SUCCESS; } } /* If we succeeded, wait on children. */ for (i = 0; i < NUM_FORKS; i++) wait(NULL); return EXIT_SUCCESS; } [ljs@kernel.org: account for the !CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING case] Link: https://lore.kernel.org/agWZsPGYid08uU6O@lucifer Link: https://lore.kernel.org/20260513085658.45264-1-ljs@kernel.org Fixes: 081056dc00a2 ("mm/hugetlb: unshare page tables during VMA split, not before") Signed-off-by: Lorenzo Stoakes Acked-by: David Hildenbrand (Arm) Acked-by: Oscar Salvador Cc: Jann Horn Cc: Muchun Song Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 66bc00ea37fa8ec14be5a3909d067a5967ef234b Author: SeongJae Park Date: Thu May 28 17:01:02 2026 -0700 mm/damon/reclaim: handle ctx allocation failure commit 7e2ed8a29427af534bf2cb9b8bc51762b8b6e654 upstream. Patch series "mm/damon/{reclaim,lru_sort}: handle ctx allocation failures". DAMON_RECLAIM and DAMON_LRU_SORT could dereference NULL pointers if their damon_ctx object allocations fail. The bugs are expected to happen infrequently because the allocations are arguably too small to fail on common setups. But theoretically they are possible and the consequences are bad. Fix those. The issues were discovered [1] by Sashiko. This patch (of 2): DAMON_RECLAIM allocates the damon_ctx object for its kdamond in its init function. damon_reclaim_enabled_store() wrongly assumes the allocation will always succeed once tried. If the damon_ctx allocation was failed, therefore, code execution reaches to damon_commit_ctx() while 'ctx' is NULL. As a result, it dereferences the NULL 'ctx' pointer. Avoid the NULL dereference by returning -ENOMEM if 'ctx' is NULL. Link: https://lore.kernel.org/20260529000104.7006-2-sj@kernel.org Link: https://lore.kernel.org/20260419014800.877-1-sj@kernel.org [1] Fixes: 3f7a914ab9a5 ("mm/damon/reclaim: use damon_initialized()") Signed-off-by: SeongJae Park Cc: # 6.18.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 6d48f15659395bf1381114f01be91bc68e0be46a Author: SeongJae Park Date: Thu May 28 17:01:03 2026 -0700 mm/damon/lru_sort: handle ctx allocation failure commit ab04340b5ae5d52c1d46b750538febcde9d889e7 upstream. DAMON_LRU_SORT allocates the damon_ctx object for its kdamond in its init function. damon_lru_sort_enabled_store() wrongly assumes the allocation will always succeed once tried. If the damon_ctx allocation was failed, therefore, code execution reaches to damon_commit_ctx() while 'ctx' is NULL. As a result, it dereferences the NULL 'ctx' pointer. Avoid the NULL dereference by returning -ENOMEM if 'ctx' is NULL. Link: https://lore.kernel.org/20260529000104.7006-3-sj@kernel.org Fixes: c4a8e662c839 ("mm/damon/lru_sort: use damon_initialized()") Signed-off-by: SeongJae Park Cc: # 6.18.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit d83390b21a0225bd03fe6402b1e25c7de855c05b Author: Muchun Song Date: Wed May 20 14:10:25 2026 +0800 mm/cma_debug: fix invalid accesses for inactive CMA areas commit c0ca59beb5252ea2bd4fdaef009d003dedc2030e upstream. cma_activate_area() can fail after allocating range bitmaps. Its cleanup path frees those bitmaps, but only clears cma->count and cma->available_count. It leaves cma->nranges and each range's count in place, so cma_debugfs_init() can still register debugfs files for an area that never activated successfully. That exposes two problems. Reading the bitmap file can make debugfs walk a freed range bitmap and trigger an invalid memory access. Reading maxchunk can also take cma->lock even though that lock is initialized only on the successful activation path. Fix this by creating debugfs entries only for CMA areas that reached CMA_ACTIVATED. c009da4258f9 introduced the invalid access to bitmap file. 2e32b947606d introduced the invalid access to cma->lock. This change applies to both issues. So I added two Fixes tags. Link: https://lore.kernel.org/20260520061025.3971821-1-songmuchun@bytedance.com Fixes: c009da4258f9 ("mm, cma: support multiple contiguous ranges, if requested") Fixes: 2e32b947606d ("mm: cma: add functions to get region pages counters") Signed-off-by: Muchun Song Acked-by: Mike Rapoport (Microsoft) Acked-by: Oscar Salvador (SUSE) Acked-by: David Hildenbrand (Arm) Cc: Dmitry Safonov <0x7f454c46@gmail.com> Cc: Frank van der Linden Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Michal Nazarewicz Cc: Stefan Strogin Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 52078596dce19ba355720238090876c8f446b2d1 Author: Muchun Song Date: Sat May 23 14:01:23 2026 +0800 mm/cma: fix reserved page leak on activation failure commit 00739e4dd46dde2b39dd9dd19a27e3c8af4ca0d0 upstream. If cma_activate_area() fails after allocating only part of the range bitmaps, the cleanup path still has to release the reserved pages when CMA_RESERVE_PAGES_ON_ERROR is clear. That is still worth doing even in this __init path. A bitmap_zalloc() failure does not necessarily mean the system cannot make further progress: freeing the reserved CMA pages can return a substantial amount of memory to the buddy allocator and may relieve the temporary memory shortage that caused the allocation failure in the first place. However, the cleanup path currently uses the bitmap-freeing bound for page release as well. That is only correct for ranges whose bitmap allocation already succeeded. The failed range and all later ranges still keep their reserved pages, so a partial bitmap allocation failure can permanently leak them. Fix this by releasing reserved pages for all ranges. Use the saved early_pfn[] value for ranges whose bitmap allocation already succeeded and for the failed range, and use cmr->early_pfn for later ranges whose bitmap allocation was never attempted. Link: https://lore.kernel.org/20260523060123.2207992-1-songmuchun@bytedance.com Fixes: c009da4258f9 ("mm, cma: support multiple contiguous ranges, if requested") Signed-off-by: Muchun Song Reviewed-by: Oscar Salvador (SUSE) Acked-by: Usama Arif Cc: David Hildenbrand Cc: Frank van der Linden Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit d5d37b7b72a9f96f0e0405d0099200068bec993b Author: Christian A. Ehrhardt Date: Sat Jun 6 22:11:20 2026 +0200 io_uring/wait: fix min_timeout behavior Commit 29fe1bd01b99714f3136f922230a643c2742cda9 upstream. The wakeup condition if a min timeout is present and has expired is that at least _one_ CQE was posted. Thus set the cq_tail target to ->cq_min_tail + 1. Without this commit a spurious wakeup can result in a premature wakeup because io_should_wake() will return true even if _no_ CQE was posted at all. Cc: Tip ten Brink Fixes: e15cb2200b93 ("io_uring: fix min_wait wakeups for SQPOLL") Cc: stable@vger.kernel.org Signed-off-by: Christian A. Ehrhardt Link: https://patch.msgid.link/20260606201120.1441447-1-lk@c--e.de Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c888d5198ffcdadb3a0617e6c831733dcac4c45f Author: Jens Axboe Date: Sun Jun 7 16:05:47 2026 -0600 io_uring/kbuf: don't truncate end buffer for bundles Commit 70f4886bcbb929e88038c8807f1daf7fc587ae7c upstream. If buffers have been peeked for a bundle receive, the kernel will truncate the end buffer, if the available length is shorter than the buffer itself. This is unnecessary, as applications iterating bundle receives must always use the minimum size of the buffer length and the remaining number of bytes in the bundle. The examples in liburing do that as well, eg examples/proxy.c. If the kernel does truncate this buffer AND the current transfer fails, then the buffer will be left with a smaller size than what is otherwise available. Just remove the buffer truncation, as it's not necessary in the first place. Link: https://lore.kernel.org/io-uring/CAAEr8jbY60noGj1fw_k91UJRBkyiRVoS6=nLhZ7Svwidjn4CAA@mail.gmail.com/ Reported-by: Federico Brasili Cc: stable@vger.kernel.org Fixes: 35c8711c8fc4 ("io_uring/kbuf: add helpers for getting/peeking multiple buffers") Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 3fdcca838f9716e82641a014942fa2f5fad5640b Author: Judith Mendez Date: Wed May 13 18:11:54 2026 -0500 pinctrl: mcp23s08: Read spi-present-mask as u8 not u32 commit b0c13ec17438577f90b379d448dfed1233e2c0a4 upstream. The binding (microchip,mcp23s08) specifies microchip,spi-present-mask as uint8, but driver would read u32, causing type mismatch. Use device_property_read_u8 to match binding spec, hardware (8 chips max), & prevent probe failure. Cc: stable@vger.kernel.org Fixes: 3ad8d3ec6d87 ("dt-bindings: pinctrl: convert pinctrl-mcp23s08.txt to yaml format") Signed-off-by: Judith Mendez Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit e646b86b3b4809d6af5addc53b6fec692332104c Author: Dawei Feng Date: Thu Jun 4 22:37:56 2026 +0800 octeontx2-af: fix memory leak in rvu_setup_hw_resources() commit 09a5bf856aa759513afc4afd233d15bcc711b84e upstream. If rvu_npc_exact_init() fails in rvu_setup_hw_resources(), the function returns directly instead of jumping to the error handling path. This causes a resource leak for the previously initialized CGX, NPC, fwdata, and MSI-X states. Fix this by replacing the direct return with goto cgx_err to ensure proper cleanup. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc6. An x86_64 allyesconfig build showed no new warnings. As we do not have access to Marvell OcteonTX2 RVU AF hardware to test with, no runtime testing was able to be performed. Fixes: 3571fe07a090 ("octeontx2-af: Drop rules for NPC MCAM") Cc: stable@vger.kernel.org Signed-off-by: Dawei Feng Signed-off-by: Zilin Guan Link: https://patch.msgid.link/20260604143756.1524482-1-dawei.feng@seu.edu.cn Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 4a4d21f531ccf5bb333d99b620e0d66551f3652c Author: Andre Heider Date: Sat May 30 21:43:39 2026 +0100 nvmem: layouts: onie-tlv: fix hang on unknown types commit ea41020b9018e31c2ea7e9d89021e3e6d7470883 upstream. The EEPROM on my board has a vendor specific entry of type 0x41. When stumbling upon that, this driver hangs in an endless loop. Fix it by keep incrementing the offset on unknown entries, so the loop will eventually stop. Fixes: d3c0d12f6474 ("nvmem: layouts: onie-tlv: Add new layout driver") Cc: Stable@vger.kernel.org Signed-off-by: Andre Heider Reviewed-by: Miquel Raynal Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260530204340.116743-2-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit cb85ef5a227b3662b88f4d849a1aad43bfe7f5ae Author: Bartosz Golaszewski Date: Sat May 30 21:43:40 2026 +0100 nvmem: core: fix use-after-free bugs in error paths commit 5b6b6fc491899d583eaa75344e094796ae9b530b upstream. Fix several instances of error paths in which we call __nvmem_device_put() - which may end up freeing the underlying memory and other resources - and then keep on using the nvmem structure. Always put the reference to the nvmem device as the last step before returning the error code. Cc: stable@vger.kernel.org Fixes: 7ae6478b304b ("nvmem: core: rework nvmem cell instance creation") Fixes: e888d445ac33 ("nvmem: resolve cells from DT at registration time") Signed-off-by: Bartosz Golaszewski Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260530204340.116743-3-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit bef389a210e7dc96073c813fab3a03a5136f8b13 Author: Jonas Jelonek Date: Thu May 28 20:52:40 2026 +0000 net: sfp: initialize i2c_block_size at adapter configure time commit 56d0885514491e5ed8f7593400879ab77c52504c upstream. sfp->i2c_block_size is only assigned in sfp_sm_mod_probe(), which runs from the state machine timer after SFP_F_PRESENT has been set. Between those two points, sfp_module_eeprom() (the ethtool -m callback) gates only on SFP_F_PRESENT and can be entered with i2c_block_size still at its kzalloc'd value of 0. On a pure-I2C adapter, sfp_i2c_read() then issues an i2c_transfer() with msgs[1].len = 0 inside a loop that subtracts this_len from len each iteration; on adapters that succeed a zero-length read the loop never advances, spinning while holding rtnl_lock. This was previously addressed by initializing i2c_block_size in sfp_alloc() (commit 813c2dd78618), but the initialization was dropped when i2c_block_size was split from i2c_max_block_size. Initialize sfp->i2c_block_size from sfp->i2c_max_block_size in sfp_i2c_configure(), so the field is valid as soon as the adapter is known. sfp_sm_mod_probe() still reassigns it on each module insertion to recover from a per-module clamp to 1 (sfp_id_needs_byte_io). Fixes: 7662abf4db94 ("net: phy: sfp: Add support for SMBus module access") Cc: stable@vger.kernel.org Signed-off-by: Jonas Jelonek Link: https://patch.msgid.link/20260528205242.971410-2-jelonek.jonas@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1d4ec754ee3871f7e3670c67bb0298c9c5760926 Author: Yuqi Xu Date: Fri May 29 21:01:44 2026 +0800 net: rds: clear i_sends on setup unwind commit 20cf0fb715c41111469577e85e35d15f099473e0 upstream. The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released. When rds_ib_setup_qp() fails after allocating i_sends but before allocating i_recvs, the sends_out path frees i_sends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation. Clear i_sends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state. Fixes: 3b12f73a5c29 ("rds: ib: add error handle") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Zhengchuan Liang Reported-by: Xin Liu Signed-off-by: Yuqi Xu Signed-off-by: Ren Wei Reviewed-by: Allison Henderson Link: https://patch.msgid.link/5a0f7624bb9845a7b67d26166a150b59e7f394ce.1779632468.git.xuyq21@lenovo.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 52b8f5ef82c886f7cd24617915e4b1579ddfd001 Author: Santosh Kalluri Date: Wed Jun 3 17:08:43 2026 -0700 net: phonet: free phonet_device after RCU grace period commit 71de0177b28da751f407581a4515cf4d762f6296 upstream. phonet_device_destroy() removes a phonet_device from the per-net device list with list_del_rcu(), but frees it immediately. RCU readers walking the same list can still hold a pointer to the object after it has been removed, leading to a slab-use-after-free. Use kfree_rcu(), matching the lifetime rule already used by phonet_address_del() for the same object type. Fixes: eeb74a9d45f7 ("Phonet: convert devices list to RCU") Cc: stable@vger.kernel.org Signed-off-by: Santosh Kalluri Acked-by: Rémi Denis-Courmont Reviewed-by: Simon Horman Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4a73cacb55863ca480d8ddda752d3944ad75bbbb Author: Bartosz Golaszewski Date: Tue Jun 2 09:34:14 2026 +0200 net: mv643xx: fix OF node refcount commit 4aacf509e537a711fa71bca9f234e5eb6968850e upstream. Platform devices created with platform_device_alloc() call platform_device_release() when the last reference to the device's kobject is dropped. This function calls of_node_put() unconditionally. This works fine for devices created with platform_device_register_full() but users of the split approach (platform_device_alloc() + platform_device_add()) must bump the reference of the of_node they assign manually. Add the missing call to of_node_get(). Cc: stable@vger.kernel.org Fixes: 76723bca2802 ("net: mv643xx_eth: add DT parsing support") Signed-off-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260602073414.22500-1-bartosz.golaszewski@oss.qualcomm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit bcb8fad90f27300add583a8371db504b766d95c7 Author: ZhaoJinming Date: Mon Jun 1 16:56:49 2026 +0800 net: bonding: fix NULL pointer dereference in bond_do_ioctl() commit a764b0e8317a863006e05732e1aefe821b9d8c2d upstream. In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which can return NULL if the requested interface name does not exist. However, the subsequent slave_dbg() call is placed before the NULL check: slave_dev = __dev_get_by_name(net, ifr->ifr_slave); slave_dbg(bond_dev, slave_dev, "slave_dev=%p:\n", slave_dev); //here if (!slave_dev) return -ENODEV; The slave_dbg() macro expands to netdev_dbg(bond_dev, "(slave %s): " fmt, (slave_dev)->name, ...) which unconditionally dereferences slave_dev->name before the NULL check is performed. This results in a NULL pointer dereference kernel oops when a user calls bonding ioctl (e.g. SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave interface name. This is reachable from userspace via the bonding ioctl interface with CAP_NET_ADMIN capability, making it a potential local denial-of-service vector. Fix by moving the slave_dbg() call after the NULL check. Fixes: e2a7420df2e0 ("bonding/main: convert to using slave printk macros") Cc: stable@vger.kernel.org # v5.2+ Signed-off-by: ZhaoJinming Link: https://patch.msgid.link/20260601085649.4029067-1-zhaojinming@uniontech.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 01f7d4b504580664d36faea5671cde5e3f0d8a5b Author: ZhaoJinming Date: Thu Jun 4 15:03:52 2026 +0800 net: airoha: Add NULL check for of_reserved_mem_lookup() in airoha_qdma_init_hfwd_queues() commit f9f25118faa4dd2b6e3d14a03d123bbdbd59925d upstream. of_reserved_mem_lookup() may return NULL if the reserved memory region referenced by the "memory-region" phandle is not found in the reserved memory table (e.g. due to a misconfigured DTS or a removed memory-region node). The current code dereferences the returned pointer without checking for NULL, leading to a kernel NULL pointer dereference at the following lines: dma_addr = rmem->base; // line 1156 num_desc = div_u64(rmem->size, buf_size); // line 1160 Add a NULL check after of_reserved_mem_lookup() and return -ENODEV if the lookup fails, which is consistent with the existing error handling for of_parse_phandle() failure in the same code block. Fixes: 3a1ce9e3d01b ("net: airoha: Add the capability to allocate hwfd buffers via reserved-memory") Cc: stable@vger.kernel.org Signed-off-by: ZhaoJinming Acked-by: Lorenzo Bianconi Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e0df4d9c090955c25a641f1df22593da6711a137 Author: Nikolay Kuratov Date: Tue May 26 19:29:32 2026 +0300 net/mlx5: Reorder completion before putting command entry in cmd_work_handler commit 02896a7fa4cd3ec61d60ba30136841e4f04bdeac upstream. Assuming callback != NULL && !page_queue, cmd_work_handler takes command entry with refcnt == 1 from mlx5_cmd_invoke. If either semaphore timeout or index allocation error happens, it does final cmd_ent_put(ent). To avoid access to freed memory, notify slotted completion before cmd_ent_put. This is theoretical issue found by Svace static analyser. Cc: stable@vger.kernel.org Fixes: 485d65e135712 ("net/mlx5: Add a timeout to acquire the command queue semaphore") Fixes: 0e2909c6bec90 ("net/mlx5: Fix variable not being completed when function returns") Signed-off-by: Nikolay Kuratov Reviewed-by: Md Haris Iqbal Reviewed-by: Moshe Shemesh Acked-by: Tariq Toukan Link: https://patch.msgid.link/20260526162932.501584-1-kniv@yandex-team.ru Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 0a46c7a5646dd0ffb09c073f640d269d635eea96 Author: Tudor Ambarus Date: Tue May 5 13:12:59 2026 +0000 firmware: samsung: acpm: Fix mailbox channel leak on probe error commit b66829b17f6385cc9ffbcbe2476d532d2e3121ad upstream. Sashiko identified the leak at [1]. The ACPM driver allocates hardware mailbox channels using `mbox_request_channel()` during `acpm_channels_init()`. However, the driver lacked a `.remove` callback and did not free these channels on subsequent error paths inside `acpm_probe()`. Additionally, if `acpm_achan_alloc_cmds()` failed during the channel initialization loop, the function returned immediately, bypassing the manual cleanup and permanently leaking any channels successfully requested in previous loop iterations. Fix this by modifying `acpm_free_mbox_chans()` to match the `devres` action signature and registering it via `devm_add_action_or_reset()`. Cc: stable@vger.kernel.org Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver") Closes: https://sashiko.dev/#/patchset/20260420-acpm-tmu-v3-0-3dc8e93f0b26%40linaro.org [1] Signed-off-by: Tudor Ambarus Link: https://patch.msgid.link/20260505-acpm-fixes-sashiko-reports-v5-2-43b5ee7f1674@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit d5de9cb5355db36438edc621dde3673e3f235767 Author: Mukesh Ojha Date: Sat May 30 21:45:27 2026 +0100 misc: fastrpc: Fix NULL pointer dereference in rpmsg callback commit 5401fb4fe10fac6134c308495df18ed74aebb9c4 upstream. A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : _raw_spin_lock_irqsave+0x34/0x8c lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx is NULL when fastrpc_rpmsg_callback() attempts to take the spinlock. There are two issues here. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), leaving a window where the callback can retrieve a valid cctx pointer but operate on an uninitialized spinlock. Second, the rpmsg channel becomes live as soon as the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is called at all, resulting in dev_get_drvdata() returning NULL. Fix both issues by moving all cctx initialization ahead of dev_set_drvdata() so the structure is fully initialized before it becomes visible to the callback, and add a NULL check in fastrpc_rpmsg_callback() as a guard against any remaining window. Fixes: f6f9279f2bf0 ("misc: fastrpc: Add Qualcomm fastrpc basic driver model") Cc: stable@vger.kernel.org Signed-off-by: Mukesh Ojha Reviewed-by: Bjorn Andersson Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260530204528.116920-4-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 53e06f8a3c2b085c31bf1284e2ebcb8036e99625 Author: Junrui Luo Date: Sat May 30 21:45:26 2026 +0100 misc: fastrpc: fix DMA address corruption due to find_vma misuse commit 464c6ad2aa16e1e1df9d559289199356493d1e00 upstream. fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGE_MASK) - vma->vm_start underflows, corrupting the DMA address sent to the DSP. Replace find_vma() with vma_lookup(), which returns NULL when the address is not contained within any VMA. Cc: stable@vger.kernel.org Fixes: 80f3afd72bd4 ("misc: fastrpc: consider address offset before sending to DSP") Reported-by: Yuhao Jiang Signed-off-by: Junrui Luo Reviewed-by: Dmitry Baryshkov Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260530204528.116920-3-srini@kernel.org Signed-off-by: Greg Kroah-Hartman commit 992f121796b7ca83a5a8b93da24e971363206218 Author: Zhenghang Xiao Date: Sat May 30 21:45:28 2026 +0100 misc: fastrpc: fix use-after-free race in fastrpc_map_create commit 07ebe87915d8accdaba20c4f88c5ae430fe62fbb upstream. fastrpc_map_lookup returns a raw pointer after releasing fl->lock. The caller fastrpc_map_create then calls fastrpc_map_get (kref_get_unless_zero) on this unprotected pointer. A concurrent MEM_UNMAP can free the map between the lock release and the kref operation, resulting in a use-after-free on the freed slab object. Restore the take_ref parameter to fastrpc_map_lookup so the reference is acquired atomically under fl->lock before the pointer is exposed to the caller. Fixes: 10df039834f8 ("misc: fastrpc: Skip reference for DMA handles") Cc: stable@vger.kernel.org Signed-off-by: Zhenghang Xiao Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260530204528.116920-5-srini@kernel.org Signed-off-by: Greg Kroah-Hartman commit 5278ccd357e0d7aeeb1e76c0f3e0e02894a9897c Author: Anandu Krishnan E Date: Sat May 30 21:45:25 2026 +0100 misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context commit e85eb5feca8e254905ffa6c57a3c99c89a674a0f upstream. There is a race between fastrpc_device_release() and the workqueue that processes DSP responses. When the user closes the file descriptor, fastrpc_device_release() frees the fastrpc_user structure. Concurrently, an in-flight DSP invocation can complete and fastrpc_rpmsg_callback() schedules context cleanup via schedule_work(&ctx->put_work). If the workqueue runs fastrpc_context_free() in parallel with or after fastrpc_device_release() has freed the user structure, it dereferences the freed fastrpc_user. Depending on the state of the context at the time of the race, any one of the following accesses can be hit: 1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf->fl->cctx, ...) to strip the SID bits from the stored IOVA before passing the physical address to dma_free_coherent(). 2. fastrpc_free_map() reads map->fl->cctx->vmperms[0].vmid to reconstruct the source permission bitmask needed for the qcom_scm_assign_mem() call that returns memory from the DSP VM back to HLOS. 3. fastrpc_free_map() acquires map->fl->lock to safely remove the map node from the fl->maps list. The resulting use-after-free manifests as: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Add kref-based reference counting to fastrpc_user. Have each invoke context take a reference on the user at allocation time and release it when the context is freed. Release the initial reference in fastrpc_device_release() at file close. Move the teardown of the user structure — freeing pending contexts, maps, mmaps, and the channel context reference — into the kref release callback fastrpc_user_free(), so that it runs only when the last reference is dropped, regardless of whether that happens at device close or after the final in-flight context completes. Fixes: 6cffd79504ce ("misc: fastrpc: Add support for dmabuf exporter") Cc: stable@kernel.org Signed-off-by: Anandu Krishnan E Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260530204528.116920-2-srini@kernel.org Signed-off-by: Greg Kroah-Hartman commit 89bd8215e25aa6999cc51696da418e0d422bc5e0 Author: Shakeel Butt Date: Thu May 21 15:37:51 2026 -0700 memcg: use round-robin victim selection in refill_stock commit c0cafe24d3f6534294c4b2bc2d47734ff7cbd313 upstream. Harry Yoo reported that get_random_u32_below() is not safe to call in the nmi context and memcg charge draining can happen in nmi context. More specifically get_random_u32_below() is neither reentrant- nor NMI-safe: it acquires a per-cpu local_lock via local_lock_irqsave() on the batched_entropy_u32 state. An NMI that lands on a CPU mid-update of the ChaCha batch state and recurses into the random subsystem would corrupt that state. The memcg_stock local_trylock prevents re-entry on the percpu stock itself, but cannot protect an unrelated subsystem's per-cpu lock. Replace the random pick with a per-cpu round-robin counter stored in memcg_stock_pcp and serialized by the same local_trylock that already guards cached[] and nr_pages[]. No atomics, no random calls, no extra locks needed. Link: https://lore.kernel.org/20260521223751.3794625-1-shakeel.butt@linux.dev Fixes: f735eebe55f8f ("memcg: multi-memcg percpu charge cache") Signed-off-by: Shakeel Butt Reported-by: Harry Yoo Closes: https://lore.kernel.org/4e20f643-6983-4b6e-b12d-c6c4eb20ae0c@kernel.org/ Acked-by: Harry Yoo (Oracle) Acked-by: Michal Hocko Cc: Johannes Weiner Cc: Muchun Song Cc: Roman Gushchin Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit a388e3dfaf9538a680de5ed43a8ebb5dd45b6e53 Author: Davidlohr Bueso Date: Thu May 7 04:29:13 2026 -0700 locking/rtmutex: Skip remove_waiter() when waiter is not enqueued commit 40a25d59e85b3c8709ac2424d44f65610467871e upstream. syzbot triggered the following splat in remove_waiter() via FUTEX_CMP_REQUEUE_PI: KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0 __x64_sys_futex+0x34f/0x4d0 task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection, leaving waiter->task nil, where 3bfdc63936dd ("rtmutex: Use waiter::task instead of current in remove_waiter()") made this fatal. Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter() upon a successfully grabbing the rtmutex. 1a1fb985f2e2 ("futex: Handle early deadlock return correctly"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock() (where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to account for try_to_take_rt_mutex(). Fixes: 3bfdc63936dd ("rtmutex: Use waiter::task instead of current in remove_waiter()") Reported-by: syzbot+78147abe6c524f183ee9@syzkaller.appspotmail.com Signed-off-by: Davidlohr Bueso Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Closes: https://lore.kernel.org/all/69f114ac.050a0220.ac8b.0003.GAE@google.com/ Link: https://patch.msgid.link/20260507112913.1019537-1-dave@stgolabs.net Signed-off-by: Greg Kroah-Hartman commit db752ebfdaf2c7f27cd9690ef48b616af068319c Author: Yilin Zhu Date: Thu Apr 30 13:21:34 2026 +0800 ipc/shm: serialize orphan cleanup with shm_nattch updates commit 2e5c6f4fd4001562781e99bbfc7f1f0127187542 upstream. shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal. Link: https://lore.kernel.org/9d97cc1031de2d0bace0edf3a668818aa2f4eca6.1777410234.git.zylzyl2333@gmail.com Fixes: 4c677e2eefdb ("shm: optimize locking and ipc_namespace getting") Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Yilin Zhu Signed-off-by: Ren Wei Cc: Christian Brauner Cc: Jeongjun Park Cc: Kees Cook Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Serge Hallyn Cc: Vasiliy Kulikov Cc: Davidlohr Bueso Cc: Oleg Nesterov Cc: Serge Hallyn Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit ab61c990a87d084f5565ee70340543e3a5394697 Author: Jason Gunthorpe Date: Mon Jun 8 15:10:04 2026 -0300 iommu/dma: Do not try to iommu_map a 0 length region in swiotlb commit 6ec91df8aff77e2e8fe3179c1f3fc15b43a40ba3 upstream. iommu_dma_iova_link_swiotlb() processes a mapping that is unaligned in three parts, the head, middle and trailer. If the middle is empty because there are no aligned pages it will call down to iommu_map() with a 0 size which the iommupt implementation will fail as illegal. It then tries to do an error unwind and starts from the wrong spot corrupting the mapping so the eventual destruction triggers a WARN_ON. Check for 0 length and avoid mapping and use offset not 0 as the starting point to unlink. This is frequently triggered by using some kinds of thunderbolt NVMe drives that trigger forced SWIOTLB for unaligned memory. NVMe seems to pass in oddly aligned buffers for the passthrough commands from smartctl that hit this condition. Cc: stable@vger.kernel.org Fixes: 433a76207dcf ("dma-mapping: Implement link/unlink ranges API") Reported-by: Mark Lord Signed-off-by: Jason Gunthorpe Reviewed-by: Christoph Hellwig Reviewed-by: Leon Romanovsky Reviewed-by: Samiullah Khawaja Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/0-v1-8536728bc89f+469-swiotlb_warn_jgg@nvidia.com Signed-off-by: Greg Kroah-Hartman commit f35a368fee8aeabd747ce95036f90bcb3805aada Author: Cryolitia PukNgae Date: Fri Jun 5 15:27:21 2026 +0800 Input: atkbd - skip deactivate for HONOR BCC-N's internal keyboard commit fb402386af4cdce108ff991a796386de55439735 upstream. After commit 9cf6e24c9fbf17e52de9fff07f12be7565ea6d61 ("Input: atkbd - do not skip atkbd_deactivate() when skipping ATKBD_CMD_GETID"), HONOR BCC-N, aka HONOR MagicBook 14 2026's internal keyboard stops working. Adding the atkbd_deactivate_fixup quirk fixes it. DMI: HONOR BCC-N/BCC-N-PCB, BIOS 1.04 04/07/2026 Fixes: 9cf6e24c9fbf17e52de9fff07f12be7565ea6d61 ("Input: atkbd - do not skip atkbd_deactivate() when skipping ATKBD_CMD_GETID") Reported-by: Hongfei Ren Link: https://github.com/colorcube/Linux-on-Honor-Magicbook-14-Pro/issues/1#issuecomment-4562679891 Tested-by: Hongfei Ren Cc: stable@kernel.org Signed-off-by: Cryolitia PukNgae Link: https://patch.msgid.link/20260605-honor-v1-1-78e05e491193@linux.dev Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit a3dff1e1a554c992963cae9e1c077a89c90382b4 Author: Zeyu WANG Date: Wed Jun 3 01:09:09 2026 +0800 Input: atkbd - add DMI quirk for Lenovo Yoga Air 14 (83QK) commit ad0979fe053e9f2db82da82188256ef6eb41095a upstream. The Lenovo Yoga Air 14 (83QK) laptop keyboard becomes unresponsive after the standard atkbd init sequence. Controlled testing on the actual hardware shows the F5 (ATKBD_CMD_RESET_DIS / deactivate) command specifically corrupts the EC state, causing zero IRQ1 interrupts after init. Skipping only the deactivate command (while keeping F4 ENABLE) resolves the issue completely: both keystroke input and CapsLock LED toggle work correctly. The reverse test - skipping only F4 while keeping F5 - makes the problem worse (zero keystroke interrupts), confirming F5 is the sole culprit. Add a DMI quirk entry for LENOVO/83QK using the existing atkbd_deactivate_fixup callback, consistent with the existing entries for LG Electronics and HONOR FMB-P that address the same EC F5 deactivate issue. Signed-off-by: Zeyu WANG Link: https://patch.msgid.link/20260602170909.14725-1-zeyu.thomas.wang@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 7f59e4f72a789bcda90aff05a3dbba93dc18807d Author: Akhil R Date: Mon May 18 17:10:13 2026 +0530 i2c: tegra: Fix NOIRQ suspend/resume commit 656646b3847ac6a21b074a813223feef2aadd6e2 upstream. The Tegra I2C driver relies on runtime PM to wake up the controller before each transfer. However, runtime PM is disabled between the system suspend and NOIRQ suspend. If an I2C device initiates a transfer during this window, the I2C controller fails to wake up and the transfer fails. To handle this, the controller must be kept available for this period to allow transfers. Rework the I2C controller's system PM callbacks such that the controller is resumed from runtime suspend during system suspend and it stays RPM_ACTIVE throughout the suspend-resume cycle until it is runtime suspended back in the system resume. The clocks are disabled in NOIRQ suspend and enabled back in NOIRQ resume by calling the controller's runtime PM functions directly. Fixes: 8ebf15e9c869 ("i2c: tegra: Move suspend handling to NOIRQ phase") Assisted-by: Cursor:claude-4.6-opus Signed-off-by: Akhil R Cc: # v5.4+ Reviewed-by: Jon Hunter Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260518114013.62065-5-akhilrajeev@nvidia.com Signed-off-by: Greg Kroah-Hartman commit 6018d73137cdcb7191a62cb824a24c5625b4c6c3 Author: Guillermo Rodríguez Date: Tue May 26 11:12:09 2026 +0200 i2c: stm32f7: fix timing computation ignoring i2c-analog-filter commit a124579c0763da7bc408f4cd7e8f606cadc94855 upstream. stm32f7_i2c_compute_timing() uses i2c_dev->analog_filter to pick the analog filter delay, but i2c_dev->analog_filter is parsed from the "i2c-analog-filter" DT property only after the compute_timing loop in stm32f7_i2c_setup_timing(), so in practice the timing calculations always ignore the analog filter. On an STM32MP1 board with clock-frequency = <400000> and i2c-analog-filter set, measured SCL frequency was ~382 kHz. This also affects (widens) the computed SDADEL range. At high bus clock speeds, this can select an SDADEL value that violates tVD;DAT (data valid time). Fix by parsing "i2c-analog-filter" before the compute_timing loop. Fixes: 83c3408f7b9c ("i2c: stm32f7: support DT binding i2c-analog-filter") Signed-off-by: Guillermo Rodríguez Cc: # v5.13+ Acked-by: Alain Volmat Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260526091210.20383-1-guille.rodriguez@gmail.com Signed-off-by: Greg Kroah-Hartman commit a162a260c8c4db7501c65220e76913e8e351f823 Author: Vladimir Zapolskiy Date: Sat May 16 02:41:18 2026 +0300 i2c: qcom-cci: Fix NULL pointer dereference in cci_remove() commit 729ac5a4b966aac42e08a94dea966f4429008548 upstream. On all modern platforms Qualcomm CCI controller provides two I2C masters, and on particular boards only one I2C master may be initialized, and in such cases the device unbinding or driver removal causes a NULL pointer dereference, because cci_halt() is called for all two I2C masters, but a completion is initialized only for the single enabled master: % rmmod i2c-qcom-cci Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __wait_for_common+0x194/0x1a8 (P) wait_for_completion_timeout+0x20/0x2c cci_remove+0xc4/0x138 [i2c_qcom_cci] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 qcom_cci_driver_exit+0x18/0x1008 [i2c_qcom_cci] .... Fixes: e517526195de ("i2c: Add Qualcomm CCI I2C driver") Signed-off-by: Vladimir Zapolskiy Cc: # v5.8+ Reviewed-by: Konrad Dybcio Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260515234121.1607425-2-vladimir.zapolskiy@linaro.org Signed-off-by: Greg Kroah-Hartman commit 9fa82cf393bafc7bd7ca15c1d5cbd5b57ab9de1d Author: Carlos Song Date: Thu May 21 14:50:38 2026 +0800 i2c: imx: fix clock and pinctrl state inconsistency in runtime PM commit 8783fb8031799f1230997c16df8c8dce9fcd1841 upstream. In i2c_imx_runtime_suspend(), the clock is disabled before switching the pinctrl state to sleep. If pinctrl_pm_select_sleep_state() fails, the runtime suspend is aborted but the clock remains disabled, causing a system crash when the hardware is subsequently accessed. Fix this by switching the pinctrl state before disabling the clock so that a pinctrl failure leaves the clock enabled and the hardware accessible. In i2c_imx_runtime_resume(), restore the pinctrl state back to sleep if clk_enable() fails to keep the consistent. Fixes: 576eba03c994 ("i2c: imx: switch different pinctrl state in different system power status") Signed-off-by: Carlos Song Cc: # v6.14+ Reviewed-by: Frank Li Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260521065038.2954998-1-carlos.song@oss.nxp.com Signed-off-by: Greg Kroah-Hartman commit b39f30c0a72fdd3a775f03ae52f5771cc908de9e Author: Carlos Song Date: Wed May 20 17:33:23 2026 +0800 i2c: imx-lpi2c: fix resource leaks switching to devm_dma_request_chan() commit 695fcefd4a81466ef9c529790b4e96f1ea2ba051 upstream. The LPI2C driver requests DMA channels using dma_request_chan(), but never releases them in lpi2c_imx_remove(), resulting in DMA channel leaks every time the driver is unloaded. Additionally, when lpi2c_dma_init() successfully requests the TX DMA channel but fails to request the RX DMA channel, the probe falls back to PIO mode and completes successfully. Since probe succeeds, the devres framework will not trigger any cleanup, leaving the TX DMA channel and the memory allocated for the dma structure held for the lifetime of the device even though DMA is never used. Switch to devm_dma_request_chan() to let the device core manage DMA channel lifetime automatically. Wrap all allocations within a devres group so that devres_release_group() can release all partially acquired resources when DMA init fails and probe continues in PIO mode. Fixes: a09c8b3f9047 ("i2c: imx-lpi2c: add eDMA mode support for LPI2C") Signed-off-by: Carlos Song Cc: # v6.14+ Reviewed-by: Frank Li Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260520093323.2882070-1-carlos.song@oss.nxp.com Signed-off-by: Greg Kroah-Hartman commit 16f8e17184b31382076f84751db5ac51fc02733e Author: Ji'an Zhou Date: Tue Jun 2 09:12:04 2026 +0000 futex/requeue: Prevent NULL pointer dereference in remove_waiter() on self-deadlock commit 74e144274af39935b0f410c0ee4d2b91c3730414 upstream. When FUTEX_CMP_REQUEUE_PI requeues a non-top waiter that already owns the target PI futex, task_blocks_on_rt_mutex() returns -EDEADLK before setting waiter->task. The subsequent remove_waiter() in rt_mutex_start_proxy_lock() dereferences the NULL waiter->task, causing a kernel crash. Add a self-deadlock check for non-top waiters before calling rt_mutex_start_proxy_lock(), analogous to the top-waiter check in futex_lock_pi_atomic(). Fixes: 3bfdc63936dd4773109b7b8c280c0f3b5ae7d349 ("rtmutex: Use waiter::task instead of current in remove_waiter()") Signed-off-by: Ji'an Zhou Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 56763afa013444a9d84ca1b74e4b7130942177ba Author: Jann Horn Date: Tue May 19 16:40:34 2026 +0200 fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios commit 4e3d1b2c48ca6c55f1e9ca7f8dccc76f120f276c upstream. FUSE_NOTIFY_RETRIEVE must be limited to uptodate folios; !uptodate folios can contain uninitialized data. Since FUSE_NOTIFY_RETRIEVE is intended to only return data that is already in the page cache and not wait for data from the FUSE daemon, treat !uptodate folios as if they weren't present. This only has security impact on systems that don't enable automatic zero-initialization of all page allocations via CONFIG_INIT_ON_ALLOC_DEFAULT_ON or init_on_alloc=1. Cc: stable@kernel.org Fixes: 2d45ba381a74 ("fuse: add retrieve request") Signed-off-by: Jann Horn Link: https://patch.msgid.link/20260519-fuse-retrieve-uptodate-v1-1-a7a1912a37f9@google.com Acked-by: Miklos Szeredi Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 12df4cfa738aefff21756728e91056d7defb0fe6 Author: Jann Horn Date: Tue May 19 16:29:38 2026 +0200 fuse: reject fuse_notify() pagecache ops on directories commit 9c954499d43aefac01c5dfb57a82b13d2dcf4b94 upstream. The operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the FUSE daemon to actively write/read pagecache contents. For directories with FOPEN_CACHE_DIR, the pagecache is used as kernel-internal cache storage, and userspace is not supposed to have direct access to this cache - in particular, fuse_parse_cache() will hit WARN_ON() if the cache contains bogus data. Reject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than regular files with -EINVAL. Fixes: 5d7bc7e8680c ("fuse: allow using readdir cache") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn Link: https://patch.msgid.link/20260519-fuse-dir-pagecache-v2-1-5428fa48e175@google.com Acked-by: Miklos Szeredi Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 57a9c085be07f7de76b9866107d8b06a101f06ae Author: Arpith Kalaginanavoor Date: Tue May 26 05:38:58 2026 -0700 fs/qnx6: fix pointer arithmetic in directory iteration commit 89c4a1167f3a0a0efd2ec3e1801036d2eb65ae1a upstream. The conversion to qnx6_get_folio() in commit b2aa61556fcf ("qnx6: Convert qnx6_get_page() to qnx6_get_folio()") introduced a regression in directory iteration. The pointer 'de' and the 'limit' address were calculated using byte offsets from a char pointer without scaling by the size of a QNX6 directory entry. This causes the driver to read from incorrect memory offsets, leading to "invalid direntry size" errors and premature termination of directory scans. Fix this by casting 'kaddr' to 'struct qnx6_dir_entry *' before applying the offset and last_entry(...) increments. This allows the compiler to correctly scale the pointer arithmetic by the 32-byte stride of the directory entry structure. Fixes: b2aa61556fcf ("qnx6: Convert qnx6_get_page() to qnx6_get_folio()") Cc: stable@vger.kernel.org Signed-off-by: Arpith Kalaginanavoor Link: https://patch.msgid.link/20260526123858.1683035-1-arpithk@nvidia.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 2990f143ec865aa728cbe6a4bcdd324f3c1b0f0f Author: Christian Brauner Date: Mon May 18 10:32:11 2026 +0200 pidfd: refuse access to tasks that have started exiting harder commit 62c4d31d78294bd61cf3403626b789e854357177 upstream. The recent ptrace fix closed a hole where someone could rely on task->mm becoming NULL during do_exit() to bypass dumpability checks. This api here leans on on the very same check and so inherits the fix. But there is no good reason to let it succeed at all once the target has entered do_exit(). PF_EXITING is set by exit_signals() at the very top of do_exit(), before exit_mm() and exit_files() run. Once we observe it, the task is committed to dying and exit_files() will release the fdtable shortly. Fixes: 8649c322f75c ("pid: Implement pidfd_getfd syscall") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260518-obgleich-petersilie-2d77ccccf9b9@brauner Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 89b909e9704587bfecc1aab1d37e98faee03b9f9 Author: Hyunwoo Kim Date: Tue Jun 2 19:21:05 2026 +0900 inet: frags: fix use-after-free caused by the fqdir_pre_exit() flush commit 32594b09854970d7ba83eb2dc8c69a2edd158c8e upstream. On netns teardown, fqdir_pre_exit() walks the fqdir rhashtable and flushes every fragment queue that is not yet complete using inet_frag_queue_flush(). That helper frees all the skbs queued on the fragment queue but does not set INET_FRAG_COMPLETE, and leaves q->fragments_tail and q->last_run_head pointing at the freed skbs. The queue itself stays in the rhashtable. fqdir_pre_exit() first lowers high_thresh to 0 to stop new queue lookups, but it cannot stop a fragment that already obtained the queue through inet_frag_find() earlier and stalled just before taking the queue lock. Once that fragment resumes after the flush and takes the queue lock, it passes the INET_FRAG_COMPLETE check and then dereferences the freed fragments_tail. inet_frag_queue_insert() reads FRAG_CB() and ->len of that pointer and, on the append path, writes ->next_frag, causing a slab use-after-free. IPv6, nf_conntrack_reasm6 and 6lowpan reassembly share the same flush path and are affected as well. Reset rb_fragments, fragments_tail and last_run_head in inet_frag_queue_flush() so a flushed queue no longer points at the freed skbs. A fragment that resumes after the flush and takes the queue lock then finds an empty queue and starts a new run instead of dereferencing the freed fragments_tail. ip_frag_reinit() already performed this reset after its own flush, so drop the now duplicate code there. Cc: stable@vger.kernel.org Fixes: 006a5035b495 ("inet: frags: flush pending skbs in fqdir_pre_exit()") Suggested-by: Eric Dumazet Signed-off-by: Hyunwoo Kim Link: https://patch.msgid.link/ah6ukYq5G98LshdA@v4bel Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit df422fd273c96c2ee5beb80fc21adc8c70c29260 Author: Michael Bommarito Date: Tue Jun 2 15:46:42 2026 -0400 IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN commit 29e7b925ae6df64894e82ab6419994dc25580a8a upstream. In drivers/infiniband/ulp/isert/ib_isert.c, isert_login_recv_done() computes the login request payload length as wc->byte_len minus ISER_HEADERS_LEN with no lower bound, and login_req_len is a signed int. A remote iSER initiator can post a login Send work request carrying fewer than ISER_HEADERS_LEN (76) bytes, so the subtraction underflows and login_req_len becomes negative. isert_rx_login_req() then reads that negative length back into a signed int, takes size = min(rx_buflen, MAX_KEY_VALUE_PAIRS), and because the min() is signed it keeps the negative value; the value is then passed as the memcpy() length and sign-extended to a multi-gigabyte size_t. The copy into the 8192-byte login->req_buf runs far out of bounds and faults, crashing the target node. The login phase precedes iSCSI authentication, so no credentials are required to reach this path. Reject any login PDU shorter than ISER_HEADERS_LEN before the subtraction, mirroring the existing early return on a failed work completion, so login_req_len can never go negative. The upper bound was already safe: a posted login buffer cannot deliver more than ISER_RX_PAYLOAD_SIZE, so the difference stays at or below MAX_KEY_VALUE_PAIRS and the existing min() clamps it; only the missing lower bound needs to be added. Fixes: b8d26b3be8b3 ("iser-target: Add iSCSI Extensions for RDMA (iSER) target driver") Link: https://patch.msgid.link/r/20260602194642.2273217-1-michael.bommarito@gmail.com Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 32138633e51e6db59e474765cf93268c92b42888 Author: Jann Horn Date: Wed Jun 3 21:31:57 2026 +0200 fhandle: fix UAF due to unlocked ->mnt_ns read in may_decode_fh() commit 40ab6644b99685755f740b872c00ef40d9aa870e upstream. may_decode_fh() accesses mount::mnt_ns without holding any locks; that means the mount can concurrently be unmounted, and the mnt_namespace can concurrently be freed after an RCU grace period. This race can happens as follows, assuming that the mount point was created by open_tree(..., OPEN_TREE_CLONE): thread 1 thread 2 RCU __do_sys_open_by_handle_at do_handle_open handle_to_path may_decode_fh is_mounted [mount::mnt_ns access] [mount::mnt_ns access] __do_sys_close fput_close_sync __fput dissolve_on_fput umount_tree class_namespace_excl_destructor namespace_unlock free_mnt_ns mnt_ns_tree_remove call_rcu(mnt_ns_release_rcu) mnt_ns_release_rcu mnt_ns_release kfree [mnt_namespace::user_ns access] **UAF** Fix it by taking rcu_read_lock() around the mount::mnt_ns access, like in __prepend_path(). Additionally, document the semantics of mount::mnt_ns, and use WRITE_ONCE() for writers that can race with lockless readers. This bug is unreachable unless one of the following is set: - CONFIG_PREEMPTION - CONFIG_RCU_STRICT_GRACE_PERIOD because it requires an RCU grace period to happen during a syscall without an explicit preemption. This doesn't seem to have interesting security impact; worst-case, it could leak the result of an integer comparison to userspace (from the level check in cap_capable()), cause an endless loop, or crash the kernel by dereferencing an invalid address. Fixes: 620c266f3949 ("fhandle: relax open_by_handle_at() permission checks") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn Link: https://patch.msgid.link/20260603-vfs-fhandle-uaf-fix-v2-1-d05db76a5084@google.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 3884976f87448e269908ae61bd5d62d54ce9c0c7 Author: Kyle Meyer Date: Fri Jun 5 17:25:24 2026 -0500 bnxt_en: Fix NULL pointer dereference commit d930276f2cddd0b7294cac7a8fe7b877f6d9e08d upstream. PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state. The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi. Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer. Check if bp->bnapi is NULL before disabling and synchronizing IRQs. Fixes: e5811b8c09df ("bnxt_en: Add IRQ remapping logic.") Cc: stable@vger.kernel.org Signed-off-by: Kyle Meyer Reviewed-by: Pavan Chebbi Link: https://patch.msgid.link/aiNM1CY2-StPilxW@hpe.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6f72b902c34d6c18bbb7d5a38898d5e198a4d743 Author: Chancel Liu Date: Mon Jun 1 17:33:27 2026 +0900 ASoC: fsl_sai: Fix 32 slots TDM broken by integer shift UB in xMR write commit 4790af1cc2e8871fb31f28c66e42b9a949a23992 upstream. When configuring 32 slots TDM (channels == slots == 32), the xMR (Mask Register) write used: ~0UL - ((1 << min(channels, slots)) - 1) The literal "1" is a signed 32-bit int. Shifting it by 32 positions is undefined behaviour which may set this register to 0xFFFFFFFF, masking all 32 slots. Use GENMASK_U32() macro instead. For 32 slots this produces a zero mask: ~GENMASK_U32(31, 0) = ~0xFFFFFFFF = 0x00000000 Behaviour for fewer than 32 slots is unchanged. Fixes: 770f58d7d2c5 ("ASoC: fsl_sai: Support multiple data channel enable bits") Cc: stable@vger.kernel.org Signed-off-by: Chancel Liu Reviewed-by: Shengjiu Wang Link: https://patch.msgid.link/20260601083327.1535185-1-chancel.liu@oss.nxp.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 735dabdf21561a24d8bcae456c9c32f7f961a029 Author: Salman Alghamdi Date: Sat May 9 01:26:14 2026 +0300 staging: rtl8723bs: fix buffer over-read in rtw_update_protection commit 514ab98364595007d4557ecc85d7e5f012c504d3 upstream. rtw_update_protection() is called with a pointer offset into the ies buffer but the full ie_length is passed, causing a potential buffer over-read. Fixes: e945c43df60b ("Staging: rtl8723bs: Delete dead code from update_current_network()") Fixes: d3fcee1b78a5 ("staging: rtl8723bs: fix camel case in struct wlan_bssid_ex") Reported-by: Luka Gejak Closes: https://lore.kernel.org/linux-staging/DI2H39EAAFBZ.3KI5NWN02AQ2S@linux.dev Cc: stable@vger.kernel.org Signed-off-by: Salman Alghamdi Reviewed-by: Luka Gejak Link: https://patch.msgid.link/20260508222649.23989-1-me@cipherat.com Signed-off-by: Greg Kroah-Hartman commit 1d6c2062b77be09ec15d6bf637b2e2221c4482fc Author: Amit Matityahu Date: Wed Jun 3 17:01:39 2026 +0000 timers/migration: Fix livelock in tmigr_handle_remote_up() commit d486b4934a8e504376b85cdb3766f306d57aff5b upstream. tmigr_handle_remote_cpu() skips timer_expire_remote() when cpu == smp_processor_id(), assuming the local softirq path already handled this CPU's timers. This assumption is wrong because jiffies can advance after the handling of the CPU's global timers in run_timer_base(BASE_GLOBAL) and before tmigr_handle_remote() evaluates the expiry times. As a consequence a timer which expires after the CPU local timer wheel advanced and becomes expired in the remote handling is ignored and the callback is never invoked and removed from the timer wheel. What's worse is that fetch_next_timer_interrupt_remote() keeps reporting it as expired, and the event is re-queued with expires == now on each iteration. The goto-again loop spins indefinitely. Fix this by calling timer_expire_remote() unconditionally. That's minimal overhead for the common case as __run_timer_base() returns immediately if there is nothing to expire in the local wheel. [ tglx: Amend change log and add a comment ] Fixes: 7ee988770326 ("timers: Implement the hierarchical pull model") Reported-by: Alon Kariv Signed-off-by: Amit Matityahu Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260603170139.33628-1-amitmat@amazon.com Signed-off-by: Greg Kroah-Hartman commit ba9ad6015937a5e46ba1a31370e3efdec8abbdcc Author: Raf Dickson Date: Tue May 26 10:43:56 2026 +0000 vsock/vmci: fix sk_ack_backlog leak on failed handshake commit c05fa14db43ebef3bd862ca9d073981c0358b3f0 upstream. When vmci_transport_recv_connecting_server() returns an error, vmci_transport_recv_listen() calls vsock_remove_pending() but never calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented permanently. Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause sk_ack_backlog to climb toward sk_max_ack_backlog. Once it reaches the limit the listener permanently refuses all new connections with -ECONNREFUSED, a silent denial of service requiring a process restart to recover. The two existing sk_acceptq_removed() calls in af_vsock.c do not cover this path: line 764 checks vsock_is_pending() which returns false after vsock_remove_pending(), and line 1889 is only reached on successful accept(). Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on the error path. Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Cc: stable@vger.kernel.org Signed-off-by: Raf Dickson Acked-by: Stefano Garzarella Link: https://patch.msgid.link/20260526104356.469928-1-rafdog35@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 265c07c09c837621730d35f02975207a1224bf05 Author: Yuqi Xu Date: Fri May 29 23:25:37 2026 +0800 wifi: nl80211: reject oversized EMA RNR lists commit 4cd92957e8f8cc4ebfe8a5d4203c14c592fde6b1 upstream. nl80211_parse_rnr_elems() stores the parsed element count in a u8-backed cfg80211_rnr_elems::cnt field and uses that count to size the flexible array allocation. Reject nested NL80211_ATTR_EMA_RNR_ELEMS input once the count reaches 255, before incrementing it again. This keeps the parser aligned with the data structure it fills and matches the existing bound check used by nl80211_parse_mbssid_elems(). Fixes: dbbb27e183b1 ("cfg80211: support RNR for EMA AP") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Zhengchuan Liang Reported-by: Xin Liu Assisted-by: Codex:gpt-5.4 Signed-off-by: Yuqi Xu Signed-off-by: Ren Wei Link: https://patch.msgid.link/20260529152542.1412734-1-n05ec@lzu.edu.cn Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit ac2000be0cbedab32c05644f10937dbde804aff5 Author: Emmanuel Grumbach Date: Sun May 31 13:30:19 2026 +0300 wifi: iwlwifi: pcie: simplify the resume flow if fast resume is not used commit 093305d801fae6ff9b8bb531fd78b579794c4f80 upstream. In most distributions, NetworkManager shuts the device down before entering system suspend, so fast suspend is typically not used. On older devices, resume currently tries to grab NIC access to infer whether the device was powered off while suspended. That probe is only meaningful for the fast-suspend path where the device is expected to remain alive. Unfortunately, for unclear reasons, grabbing NIC access was harmful as reported in the bugzilla ticket below. Workaround this issue by simply not grabbing NIC access if fast suspend is not used. Cc: stable@vger.kernel.org Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221501 Assisted-by: GitHub Copilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach Link: https://patch.msgid.link/20260531133005.e2ed9e0cd44f.If283625983a843933e0c01561a421daff184e9e9@changeid Signed-off-by: Miri Korenblit Signed-off-by: Greg Kroah-Hartman commit fcfdff42e841d246397c3756d4218c66c2b3b263 Author: Yingjie Gao Date: Wed May 27 12:31:34 2026 +0800 xfs: fix rtgroup cleanup in CoW fork repair commit c3e073894379532c00cca7ba5762e18fafe29da8 upstream. xrep_cow_find_bad_rt() initializes scrub rtgroup state before the force-rebuild path calls xrep_cow_mark_file_range(). If that call fails, the code jumps directly to out_rtg, which skips the scrub rtgroup cleanup and only drops the local rtgroup reference. Remove the unnecessary jump so the function falls through to out_sr, ensuring the realtime cursors, lock state, and sr->rtg reference are released before returning. Fixes: fd97fe111208 ("xfs: fix CoW forks for realtime files") Cc: # v6.14 Signed-off-by: Yingjie Gao Reviewed-by: "Darrick J. Wong" Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit d84ed2f9718efcfe7afae4821cefa1bcdccea970 Author: Yingjie Gao Date: Wed May 27 12:31:33 2026 +0800 xfs: fix error returns in CoW fork repair commit fcf4faba9f986b3bb528da11913c9ec5d6e8f689 upstream. xrep_cow_find_bad() returns success after the cleanup labels even if AG setup, btree queries, or bitmap updates failed. This can make repair continue with an incomplete bad-file-offset bitmap instead of stopping at the original error. The force-rebuild path has a related cleanup problem. If xrep_cow_mark_file_range() fails, the function returns directly and skips the scrub AG context and perag cleanup. Let the force-rebuild path fall through to the existing cleanup code and return the saved error after cleanup. Fixes: dbbdbd008632 ("xfs: repair problems in CoW forks") Cc: # v6.8 Signed-off-by: Yingjie Gao Reviewed-by: "Darrick J. Wong" Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 9f21885c11ba9bd24ce746283642bf5e4902edb4 Author: Matthieu Baerts (NGI0) Date: Tue Jun 2 22:14:18 2026 +1000 mptcp: add-addr: always drop other suboptions commit bd34fa0257261b76964df1c98f44b3cb4ee14620 upstream. When an ADD_ADDR needs to be sent, it could be prepared if there is enough remaining space and even if the packet is not a pure ACK. But it would be dropped soon after. Indeed, in mptcp_pm_add_addr_signal(), there is enough space to fit a DSS of 20 octets and an ADD_ADDR echo containing an IPv4 address on 8 octets for example. In this case, the packet would be prepared, the MPTCP_ADD_ADDR_ECHO bit would be removed from pm->addr_signal, but the option would be silently dropped in mptcp_established_options_add_addr() not to override DSS info in the union from 'struct mptcp_out_options', and also because mptcp_write_options() will enforce mutually exclusion with DSS. Instead, don't even try to send an ADD_ADDR if it is not a pure ACK. Retry for each new packet until a pure-ACK is emitted. That's fine to do that, because each time an ADD_ADDR (echo) is scheduled, a pure ACK is queued. This also simplifies the code, and the skb checks can be done earlier, before the lock. Note: also, since commit 6d0060f600ad ("mptcp: Write MPTCP DSS headers to outgoing data packets"), opts->ahmac would not have been set to 0 when other suboptions were not dropped, and when sending an ADD_ADDR echo. That would have resulted in sending an ADD_ADDR using garbage info, where there was not enough space, instead of an echo one without the ADD_ADDR HMAC. Fixes: 1bff1e43a30e ("mptcp: optimize out option generation") Cc: stable@vger.kernel.org Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260602-net-mptcp-misc-fixes-7-1-rc7-v2-11-856831229976@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6ea1134f1b5f0924b97d2617d762794aa2fa5e1f Author: Tao Cui Date: Tue Jun 2 22:14:13 2026 +1000 selftests: mptcp: add test for extra_subflows underflow on userspace PM commit 06fd2bec7aebf393288e4b78924482fe170caabc upstream. Add a test to verify that when userspace PM fails to create a subflow (e.g. using an unreachable address), the extra_subflows counter is not decremented below zero. Fixes: 77e4b94a3de6 ("mptcp: update userspace pm infos") Cc: stable@vger.kernel.org Signed-off-by: Tao Cui Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260602-net-mptcp-misc-fixes-7-1-rc7-v2-6-856831229976@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7bbc11437a2024d7e006ff569333a304d8a4a2d3 Author: Matthieu Baerts (NGI0) Date: Tue Jun 2 22:14:15 2026 +1000 mptcp: sockopt: set sockopt on all subflows commit 7690137e70ab0fb1f8b5a30e6f087f8ee908b680 upstream. The mptcp_setsockopt_all_sf(), currently used only with TCP_MAXSEG, stopped when one subflow returned an error. Even if it is not wrong, this is different from the other helpers trying to set the option on all subflows, and then returning an error if at least one of them had an issue. Follow this behaviour, for a question of uniformity. Fixes: 51c5fd09e1b4 ("mptcp: add TCP_MAXSEG sockopt support") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260602-net-mptcp-misc-fixes-7-1-rc7-v2-8-856831229976@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f591cbc088c950f816915abf9f93714675714a37 Author: Matthieu Baerts (NGI0) Date: Tue Jun 2 22:14:14 2026 +1000 mptcp: sockopt: check timestamping ret value commit 57132affbc89c02e1bf73fdf5724311bdc9a29da upstream. sock_set_timestamping() can fail for different reasons. The returned value should then be checked. If sock_set_timestamping() fails for at least one subflow, the first error is now reported to the userspace, similar to what is done with other socket options. Fixes: 9061f24bf82e ("mptcp: sockopt: propagate timestamp request to subflows") Cc: stable@vger.kernel.org Reported-by: Willem de Bruijn Closes: https://lore.kernel.org/willemdebruijn.kernel.178a41a53d041@gmail.com Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260602-net-mptcp-misc-fixes-7-1-rc7-v2-7-856831229976@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c0c152fc4ae6e29db387cf86d33f61735fae80b5 Author: Tao Cui Date: Tue Jun 2 22:14:12 2026 +1000 mptcp: pm: fix extra_subflows underflow on userspace PM subflow creation commit 14e9fea30b68fc75b2b3d97396a7e6adb544bd2a upstream. The userspace PM increments extra_subflows after __mptcp_subflow_connect() succeeds, but __mptcp_subflow_connect() calls mptcp_pm_close_subflow() on failure to roll back the pre-increment done by the kernel PM's fill_*() helpers. Because the userspace PM hasn't incremented yet at that point, this decrement is spurious and causes extra_subflows to underflow. Fix it by aligning the userspace PM with the kernel PM: increment extra_subflows before calling __mptcp_subflow_connect(), so the existing error path in subflow.c correctly rolls it back on failure. Also simplify the error handling by taking pm.lock only when needed for cleanup. Fixes: 77e4b94a3de6 ("mptcp: update userspace pm infos") Cc: stable@vger.kernel.org Signed-off-by: Tao Cui Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260602-net-mptcp-misc-fixes-7-1-rc7-v2-5-856831229976@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 653245266913f03fcf21cbca68eed5c197a33e52 Author: Paolo Abeni Date: Tue Jun 2 22:14:11 2026 +1000 mptcp: allow subflow rcv wnd to shrink commit da23be77e1292cd611e736c3aa17da633d7ddce7 upstream. In MPTCP connection, the `window` field in the TCP header refers to the MPTCP-level rcv_nxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time. At the same time, the TCP stack ensures independently that the TCP-level rcv wnd right's edge does not move backward. That in turn causes artificial inflating of the MPTCP rcv window when the incoming data is acked at the TCP level and is OoO in the MPTCP sequence space (or lands in the backlog). As a consequence, the incoming traffic can exceed the receiver rcvbuf size even when the sender is not misbehaving. Prevent such scenario forcibly allowing the TCP subflow to shrink the TCP-level rcv wnd regardless of the current netns setting. Fixes: f3589be0c420 ("mptcp: never shrink offered window") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260602-net-mptcp-misc-fixes-7-1-rc7-v2-4-856831229976@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3b8cbba7c0ed31189c89f90be247b8973ffa79ef Author: Paolo Abeni Date: Tue Jun 2 22:14:10 2026 +1000 mptcp: close TOCTOU race while computing rcv_wnd commit 8ab24fdebc369c0dfb90f82c1650b1e66662bb45 upstream. The MPTCP output path access locklessly the MPTCP-level ack_seq in multiple times, using possibly different values for the data_ack in the DSS option and to compute the announced rcv wnd for the same packet. Refactor the cote to avoid inconsistencies which may confuse the peer. Also ensure that the MPTCP level rcv wnd is updated only when the egress packet actually contains a DSS ack. Fixes: fa3fe2b15031 ("mptcp: track window announced to peer") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260602-net-mptcp-misc-fixes-7-1-rc7-v2-3-856831229976@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit edaf0c955aceff3ff8743090f2254ab88f64337e Author: Paolo Abeni Date: Tue Jun 2 22:14:09 2026 +1000 mptcp: fix retransmission loop when csum is enabled commit d1918b36edcaed0ec4ef6888b2358c6b1ddcff47 upstream. Sashiko noted that retransmission with csum enabled can actually transmit new data, but currently the relevant code does not update accordingly snd_nxt. The may cause incoming ack drop and an endless retransmission loop. Address the issue incrementing snd_nxt as needed. Fixes: 4e14867d5e91 ("mptcp: tune re-injections for csum enabled mode") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260602-net-mptcp-misc-fixes-7-1-rc7-v2-2-856831229976@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 95f27fcda681021ed3906d3cae7e68b6a57a1d8e Author: Alistair Popple Date: Thu May 21 13:27:30 2026 +1000 arm64: mm: call pagetable dtor when freeing hot-removed page tables commit c594b83457ccdee76d458416fb3bc9348a37592f upstream. Since 5e8eb9aeeda3 ("arm64: mm: always call PTE/PMD ctor in __create_pgd_mapping()") page-table allocation on ARM64 always calls pagetable_{pte,pmd,pud,p4d}_ctor(). This sets the page_type to PGTY_table, increments NR_PAGETABLE and possible allocates a PTL. However the matching pagetable_dtor() calls were never added. With DEBUG_VM enabled on kernel versions prior to v6.17 without 2dfcd1608f3a9 ("mm/page_alloc: let page freeing clear any set page type") this leads to the following warning when freeing these pages due to page->page_type sharing page->_mapcount: BUG: Bad page state in process ... pfn:284fbb page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x284fbb flags: 0x17fffc000000000(node=0|zone=2|lastcpupid=0x1ffff) page_type: f2(table) page dumped because: nonzero mapcount Call trace: bad_page+0x13c/0x160 __free_frozen_pages+0x6cc/0x860 ___free_pages+0xf4/0x180 free_pages+0x54/0x80 free_hotplug_page_range.part.0+0x58/0x90 free_empty_tables+0x438/0x500 __remove_pgd_mapping.constprop.0+0x60/0xa8 arch_remove_memory+0x48/0x80 try_remove_memory+0x158/0x1d8 offline_and_remove_memory+0x138/0x180 It can also lead to leaking the ptl allocation if ALLOC_SPLIT_PTLOCKS is defined and incorrect NR_PAGETABLE stats. Fix this by calling pagetable_dtor() in free_hotplug_pgtable_page() prior to freeing the page to undo the effects of calling pagetable_*_ctor(). Link: https://lore.kernel.org/20260521032730.2104017-1-apopple@nvidia.com Fixes: 5e8eb9aeeda3 ("arm64: mm: always call PTE/PMD ctor in __create_pgd_mapping()") Signed-off-by: Alistair Popple Cc: Catalin Marinas Cc: David Hildenbrand Cc: Will Deacon Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 517720913bd3c17a52cd55a740064f68455ab88e Author: Karl Mehltretter Date: Sun May 24 06:52:35 2026 +0100 ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow commit 77a1f6883dc6e837bb2cb30b9b02e2f94338e2c6 upstream. Commit 44e9a3bb76e5 ("ARM: 9430/1: entry: Do a dummy read from VMAP shadow") added a dummy read from the KASAN VMAP stack shadow in __switch_to(). The read uses ldr, but the KASAN shadow address is byte-granular and is not guaranteed to be word aligned. ARMv5 faults unaligned word loads. With CONFIG_KASAN_VMALLOC and CONFIG_VMAP_STACK enabled, ARM926/VersatilePB crashes in __switch_to() with an alignment exception before reaching init. Use ldrb for the dummy shadow access. The code only needs to fault in the shadow mapping if the stack shadow is missing, so a byte load is sufficient and matches the granularity of KASAN shadow memory. Fixes: 44e9a3bb76e5 ("ARM: 9430/1: entry: Do a dummy read from VMAP shadow") Cc: stable@vger.kernel.org # v6.13+ Signed-off-by: Karl Mehltretter Reviewed-by: Linus Walleij Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit da295adc9dab3c9a13ef62dad75af692490cad71 Author: Karl Mehltretter Date: Sun May 24 06:52:36 2026 +0100 ARM: 9474/1: io: avoid KASAN instrumentation of raw halfword I/O commit d59ed803715a71fb9582e139d648ece8d66dc743 upstream. For CPUs before ARMv6, __raw_readw() and __raw_writew() are implemented as C volatile halfword accesses so the compiler can generate an access sequence that is safe for those machines. With KASAN enabled, those C accesses are instrumented as normal memory accesses. That is not valid for MMIO. On ARM926/VersatilePB with KASAN enabled, PL011 probing traps in __asan_store2() while registering the UART, because the instrumented writew() tries to check KASAN shadow for an MMIO address. Keep the existing volatile halfword access, but move the ARMv5 definitions into __no_kasan_or_inline functions so raw MMIO halfword accesses are not instrumented by KASAN. The ARMv6-and-newer inline assembly path is unchanged. Fixes: 421015713b30 ("ARM: 9017/2: Enable KASan for ARM") Cc: stable@vger.kernel.org # v5.11+ Signed-off-by: Karl Mehltretter Reviewed-by: Linus Walleij Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 6243a363ec9037d060cd99fcfe496743789b80e0 Author: Yuho Choi Date: Sun May 24 22:47:09 2026 -0400 ARM: socfpga: Fix OF node refcount leak in SMP setup commit 63838c323924fe4a78b2323bd45aa1030f72ca60 upstream. socfpga_smp_prepare_cpus() looks up the Cortex-A9 SCU node with of_find_compatible_node(), which returns a node reference that must be released with of_node_put(). The function maps the SCU registers and then returns without dropping that reference, leaking the node on both the success path and the of_iomap() failure path. Drop the reference once the mapping attempt is complete. The returned MMIO mapping does not depend on keeping the device node reference held. Fixes: 122694a0c712 ("ARM: socfpga: use of_iomap to map the SCU") Cc: stable@vger.kernel.org Signed-off-by: Yuho Choi Signed-off-by: Dinh Nguyen Signed-off-by: Greg Kroah-Hartman commit 6822eed69572000a181fa4e31fceacc60918c471 Author: Sechang Lim Date: Wed Jun 3 16:27:33 2026 +0000 udp: clear skb->dev before running a sockmap verdict commit 3c94f241f776562c489876ff506f366224565c21 upstream. On the UDP receive path skb->dev is repurposed as dev_scratch (the truesize/state cache set by udp_set_dev_scratch()), through the union { struct net_device *dev; unsigned long dev_scratch; } in sk_buff. When a UDP socket is in a sockmap, sk_data_ready is sk_psock_verdict_data_ready(), which calls udp_read_skb() -> recv_actor() (sk_psock_verdict_recv) to run the attached SK_SKB verdict program in softirq. If that program calls a socket-lookup helper (bpf_sk_lookup_tcp/udp, bpf_skc_lookup_tcp), bpf_skc_lookup() does: if (skb->dev) caller_net = dev_net(skb->dev); skb->dev still holds the dev_scratch value (a non-NULL integer), so dev_net() dereferences it as a struct net_device * and the kernel takes a general protection fault on a non-canonical address in softirq: Oops: general protection fault, probably for non-canonical address 0x1010000800004a0 CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full) RIP: 0010:bpf_skc_lookup net/core/filter.c:7033 [inline] RIP: 0010:bpf_sk_lookup+0x45/0x160 net/core/filter.c:7047 Call Trace: bpf_prog_4675cb904b7071f8+0x12e/0x14e bpf_prog_run_pin_on_cpu+0xc6/0x1f0 sk_psock_verdict_recv+0x1ba/0x350 udp_read_skb+0x31a/0x370 sk_psock_verdict_data_ready+0x2e3/0x600 __udp_enqueue_schedule_skb+0x4c8/0x650 udpv6_queue_rcv_one_skb+0x3ec/0x740 udp6_unicast_rcv_skb+0x11d/0x140 ip6_protocol_deliver_rcu+0x61e/0x950 ip6_input_finish+0xa9/0x150 NF_HOOK+0x286/0x2f0 ip6_input+0x117/0x220 NF_HOOK+0x286/0x2f0 __netif_receive_skb+0x85/0x200 process_backlog+0x374/0x9a0 __napi_poll+0x4f/0x1c0 net_rx_action+0x3b0/0x770 handle_softirqs+0x15a/0x460 do_softirq+0x57/0x80 The rmem charge that dev_scratch accounted for is released by skb_recv_udp() on dequeue, just above, so the scratch is dead by the time recv_actor() runs. Clear skb->dev so bpf_skc_lookup() falls back to sock_net(skb->sk), which skb_set_owner_sk_safe() set just above. Fixes: 965b57b469a5 ("net: Introduce a new proto_ops ->read_skb()") Cc: stable@vger.kernel.org Signed-off-by: Sechang Lim Reviewed-by: Jiayuan Chen Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260603162737.697215-1-rhkrqnwk98@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c96786d6ff1acc1d54d9241e97767554c1dfdd5b Author: Cunlong Li Date: Thu May 28 10:48:44 2026 +0800 zram: fix use-after-free in zram_bvec_write_partial() commit 732fd9f0b9c1cdc6dfd77162ded60df005182cc0 upstream. zram_read_page() picks the sync or async backing device read path based on whether the parent bio is NULL. zram_bvec_write_partial() passes its parent bio down, so for ZRAM_WB slots the read is dispatched asynchronously and zram_read_page() returns 0 while the bio is still in flight. The caller then runs memcpy_from_bvec(), zram_write_page() and __free_page() on the buffer, leaving the async read to write into a freed page. zram_bvec_read_partial() was switched to NULL in commit 4e3c87b9421d ("zram: fix synchronous reads") for the same reason; the write_partial counterpart was missed. Link: https://lore.kernel.org/20260528-zram-v3-1-cab86eef8764@gmail.com Fixes: 8e654f8fbff5 ("zram: read page from backing device") Reviewed-by: Christoph Hellwig Reviewed-by: Sergey Senozhatsky Signed-off-by: Cunlong Li Cc: Jens Axboe Cc: Minchan Kim Cc: Yisheng Xie Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit f92a285db7ff6e598591ccbfb551be155c5f4d57 Author: Michael Bommarito Date: Tue Jun 2 18:04:57 2026 -0400 RDMA/srp: bound SRP_RSP sense copy by the received length commit 13e91fd076306f5d0cdfa14f53d69e37274723c4 upstream. srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them. Fixes: aef9ec39c47f ("IB: Add SCSI RDMA Protocol (SRP) initiator") Link: https://patch.msgid.link/r/20260602220457.2542840-1-michael.bommarito@gmail.com Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Bart Van Assche Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit bd5e818be7964c1689fba2dad9e6bd3a827fee74 Author: Yishai Hadas Date: Mon May 25 17:21:36 2026 +0300 RDMA/core: Validate cpu_id against nr_cpu_ids in DMAH alloc commit 323c98a4ff06aa28114f2bf658fb43eb3b536bbc upstream. The cpu_id attribute supplied by user space through UVERBS_ATTR_ALLOC_DMAH_CPU_ID is passed directly to cpumask_test_cpu() without first verifying that the value is within the valid CPU range. Passing such untrusted data to cpumask_test_cpu() may lead to an out-of-bounds read of the underlying cpumask bitmap: the helper expands to a test_bit() that indexes the bitmap by cpu_id / BITS_PER_LONG with no bound check. In addition, on kernels built with CONFIG_DEBUG_PER_CPU_MAPS it trips the WARN_ON_ONCE() in cpumask_check(); combined with panic_on_warn this turns a bad user input into a machine reboot. Reject any cpu_id that is not smaller than nr_cpu_ids with -EINVAL before it is used. Reported by Smatch. Fixes: d83edab562a4 ("RDMA/core: Introduce a DMAH object and its alloc/free APIs") Link: https://patch.msgid.link/r/20260525142136.28165-1-yishaih@nvidia.com Cc: stable@vger.kernel.org Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/ag68qoAW3P04J7pT@stanley.mountain/ Signed-off-by: Yishai Hadas Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 96b6e98ff12d50ed5817230c6f1188e1150d225d Author: Jason Gunthorpe Date: Tue May 26 12:40:25 2026 -0300 RDMA/core: Validate the passed in fops for ib_get_ucaps() commit 4a1b1ac2744694a2ecd66a84bdb1445f4ef24bee upstream. Sashiko pointed out it is not safe to rely only on the devt because char/block alias so if the user finds a block device with the same dev_t it can masquerade as a ucap cdev fd. Test the f_ops to only accept authentic cdevs. Link: https://patch.msgid.link/r/0-v1-fd9482545e37+1e25-ib_ucaps_fd_ops_jgg@nvidia.com Cc: stable@vger.kernel.org Fixes: 61e51682816d ("RDMA/uverbs: Introduce UCAP (User CAPabilities) API") Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit e99807bdcd20988557f56c8b53d5c16ee5e2006d Author: Yin Tirui Date: Tue May 26 18:13:55 2026 +0800 mm/huge_memory: update file PUD counter before folio_put() commit 40990c87a26e371594475acdc560c93cfae308a1 upstream. __split_huge_pud_locked() updates the file/shmem RSS counter after dropping the PUD mapping's folio reference. If folio_put() drops the last reference, mm_counter_file() can later read freed folio state via folio_test_swapbacked(). Move the counter update before folio_put(). Link: https://lore.kernel.org/20260526101355.1984244-1-yintirui@huawei.com Fixes: dbe54153296d ("mm/huge_memory: add vmf_insert_folio_pud()") Signed-off-by: Yin Tirui Reviewed-by: Lorenzo Stoakes Acked-by: David Hildenbrand (arm) Reviewed-by: Lance Yang Reviewed-by: Dev Jain Cc: Alistair Popple Cc: Baolin Wang Cc: Barry Song Cc: Chen Jun Cc: Kefeng Wang Cc: Liam R. Howlett Cc: Nico Pache Cc: Ryan Roberts Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit cb5230b6d8a0e036c7c15eb25057c8442ed2a3cc Author: SeongJae Park Date: Mon May 25 09:22:55 2026 -0700 mm/damon/ops-common: call folio_test_lru() after folio_get() commit d6b8b02a27b3dd09ec12144322b3dac46d9bc9ef upstream. damon_get_folio() speculatively calls folio_test_lru() before folio_try_get(). The folio can get freed and reallocated to a tail page. In the case, VM_BUG_ON_PGFLAGS() in const_folio_flags() can be triggered. Remove the speculative call. Also mark folio_test_lru() check right after folio_try_get() success as no more unlikely. The race should be rare. Also the problem can happen only if the kernel has enabled CONFIG_DEBUG_VM_PGFLAGS. No real world report of this issue has been made so far. This fix is based on only theoretical analysis. That said, a bug is a bug. A similar issue was also fixed via commit 3203b3ab0fcf ("mm/filemap: don't call folio_test_locked() without a reference in next_uptodate_folio()"). I don't expect this change will make a meaningful impact to DAMON performance in the real world, though I will be happy to be corrected from the real world reports. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260525162256.8317-1-sj@kernel.org Link: https://lore.kernel.org/20260517234112.89245-1-sj@kernel.org [1] Fixes: 3f49584b262c ("mm/damon: implement primitives for the virtual memory address spaces") Signed-off-by: SeongJae Park Cc: Fernand Sieber Cc: Leonard Foerster Cc: Shakeel Butt Cc: # 5.15.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 5f5b604e1e6bde4e889199168ee80fe8306d06ad Author: Yin Tirui Date: Tue May 26 18:13:37 2026 +0800 mm/huge_memory: update file PMD counter before folio_put() commit 8d878059924f12c1bc24556a92ec56add74de3c8 upstream. __split_huge_pmd_locked() updates the file/shmem RSS counter after dropping the PMD mapping's folio reference. If folio_put() drops the last reference, mm_counter_file() can later read freed folio state via folio_test_swapbacked(). Move the counter update before folio_put(). Link: https://lore.kernel.org/20260526101337.1984081-1-yintirui@huawei.com Fixes: fadae2953072 ("thp: use mm_file_counter to determine update which rss counter") Signed-off-by: Yin Tirui Reviewed-by: Lorenzo Stoakes Acked-by: David Hildenbrand (arm) Reviewed-by: Lance Yang Reviewed-by: Dev Jain Cc: Baolin Wang Cc: Barry Song Cc: Chen Jun Cc: Kefeng Wang Cc: Liam R. Howlett Cc: Nico Pache Cc: Ryan Roberts Cc: Vlastimil Babka Cc: Yang Shi Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit edabfe80e34efc468abb3ae5586d71830a1ae585 Author: Harry Wentland Date: Tue May 5 11:50:07 2026 -0400 drm/amd/display: Reject gpio_bitshift >= 32 in bios_parser_get_gpio_pin_info() commit 49c3da65961fe9857c831d47fa1989084e87514a upstream. [Why & How] gpio_bitshift is a uint8_t read directly from the VBIOS GPIO pin table. If the value is >= 32, the expression "1 << gpio_bitshift" triggers undefined behaviour in C (shift count exceeds type width). On x86 the shift is silently masked to 5 bits, producing an incorrect GPIO mask that may cause wrong MMIO register bits to be toggled. Validate gpio_bitshift before use and return BP_RESULT_BADBIOSTABLE for out-of-range values. Fixes: ae79c310b1a6 ("drm/amd/display: Add DCE12 bios parser support") Assisted-by: Copilot:claude-opus-4.6 Reviewed-by: Alex Hung Signed-off-by: Harry Wentland Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit eadf438ab8d370b9d19acee9359918c85afeb80d) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 8348567a6afb24e2c9cafe8a321162d0eebe1411 Author: Wentao Liang Date: Sun Jun 7 09:03:03 2026 +0000 drm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait() commit 3f26bb732cc136ab20176697c92f32c9c84cb125 upstream. dma_fence_unwrap_for_each() internally calls dma_fence_unwrap_first() which does cursor->chain = dma_fence_get(head), taking an extra reference. On normal loop completion, dma_fence_unwrap_next() releases this via dma_fence_chain_walk() -> dma_fence_put(). When virtio_gpu_do_fence_wait() fails and the function returns early from inside the loop, the cursor->chain reference is never released. This is the only caller in the entire kernel that does an early return inside dma_fence_unwrap_for_each. Add dma_fence_put(itr.chain) before the early return. Cc: stable@vger.kernel.org Fixes: eba57fb5498f ("drm/virtio: Wait for each dma-fence of in-fence array individually") Signed-off-by: Wentao Liang Reviewed-by: Dmitry Osipenko Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/20260607090303.92423-1-vulab@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit 0bbc9481f970b0b4ddb08cfa464db1cc93b74b56 Author: Clément Léger Date: Thu Jun 4 09:07:13 2026 -0700 io_uring/net: inherit IORING_CQE_F_BUF_MORE across bundle recv retries commit ed46f39c47eb5530a9c161481a2080d3a869cfaf upstream. When a bundle recv retries inside io_recv_finish(), the merge logic OR the saved cflags from the previous iteration with the cflags returned by the new iteration: cflags = req->cqe.flags | (cflags & CQE_F_MASK); Bits listed in CQE_F_MASK are inherited from the new iteration, and all other bits (notably IORING_CQE_F_BUFFER and the buffer ID) come from the saved cflags. Before this change CQE_F_MASK covered only IORING_CQE_F_SOCK_NONEMPTY and IORING_CQE_F_MORE. When using provided buffer rings (IOU_PBUF_RING_INC) with incremental mode, and bundle recv, io_kbuf_inc_commit() can leave the head ring entry partially consumed, __io_put_kbufs() then sets IORING_CQE_F_BUF_MORE on the returned cflags so userspace knows the buffer ID will be reused for subsequent completions. Because IORING_CQE_F_BUF_MORE was not in CQE_F_MASK, the merge above silently dropped it whenever the final retry iteration partially consumed the buffer, and the subsequent req->cqe.flags = cflags & ~CQE_F_MASK save would have left a stale IORING_CQE_F_BUF_MORE in the carried-over cflags had one been present. Userspace would then wrongfully advance it ring head past an entry the kernel still uses. Add IORING_CQE_F_BUF_MORE to CQE_F_MASK so it is both inherited from the new iteration into the user-visible CQE and stripped from the saved cflags between iterations. Cc: stable@vger.kernel.org Signed-off-by: Clément Léger Assisted-by: Claude:claude-opus-4.6 Fixes: ae98dbf43d75 ("io_uring/kbuf: add support for incremental buffer consumption") Link: https://patch.msgid.link/20260604160715.2482972-1-cleger@meta.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 3d39da65b5c422c5e5afb7d5651b0698d060a827 Author: Takashi Iwai Date: Sat Jun 6 18:11:41 2026 +0200 ALSA: timer: Fix UAF at snd_timer_user_params() commit 053a401b592be424fea9d57c789f66cd5d8cec11 upstream. At releasing a timer object, e.g. when a userspace timer (CONFIG_SND_UTIMER) gets closed and snd_timer_free() is called, it tries to detach the timer instances and release the resources. However, it's still possible that other in-flight tasks are holding the timer instance where the to-be-deleted timer object is associated, and this may lead to racy accesses. Fortunately, most of ioctls dealing with the timer instance list already have the protection with register_mutex, and this also avoids such races. But, SNDRV_TIMER_IOCTL_PARAMS isn't protected, hence the concurrent ioctl may lead to use-after-free. This patch just adds the guard with register_mutex to protect snd_timer_user_params() for covering the code path as a quick workaround. It's no hot-path but rather a rarely issued ioctl, so the performance penalty doesn't matter. Reported-by: Kyle Zeng Tested-by: Kyle Zeng Cc: Link: https://patch.msgid.link/20260606161145.1933447-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f46093dd22969037beb1fce2e043f3236be41c92 Author: Takashi Iwai Date: Sat Jun 6 18:11:40 2026 +0200 ALSA: timer: Forcibly close timer instances at closing commit da3039e91d1f835874ed6e9a33ea19ee80c2cb92 upstream. When snd_timer object is freed via snd_timer_free() and still pending snd_timer_instance objects are assigned to the timer object, it tries to unlink all instances and just set NULL to each ti->timer, then releases the resources immediately. The problem is, however, when there are slave timer instances that are associated with a master instance linked to this timer: namely, those slave instances still point to the freed timer object although the master instance is unlinked, which may lead to user-after-free. The bug can be easily triggered particularly when a new userspace-driven timers (CONFIG_SND_UTIMER) is involved, since it can create and delete the timer object via a simple file open/close, while the other applications may keep accessing to that timer. This patch is an attempt to paper over the problem above: now instead of just unlinking, call snd_timer_close[_locked]() forcibly for each pending timer instance, so that all assigned slave timer instances are properly detached, too. Since snd_timer_close() might be called later by the driver that created that instance, the check of SNDRV_TIMER_IFLG_DEAD is added at the beginning, too. Reported-by: Kyle Zeng Tested-by: Kyle Zeng Fixes: 37745918e0e7 ("ALSA: timer: Introduce virtual userspace-driven timers") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260606161145.1933447-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 372f33ebed747d91870f57c0a2e62884a870bffa Author: HyeongJun An Date: Mon Jun 8 18:09:26 2026 +0900 USB: serial: kl5kusb105: fix bulk-out buffer overflow commit 96d47e40bf9db4a9efd5c8fb53287a508d165f14 upstream. klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied. Fixes: 60b3013cdaf3 ("USB: kl5usb105: reimplement using generic framework") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 85bd2b3afa0ae9ce9330dc08124750486ff6dddf Author: Jack Wu Date: Thu Jun 4 10:04:40 2026 +0800 USB: serial: option: add usb-id for Dell Wireless DW5826e-m commit 1938fb9fe38c4f04a3f30bea44f8071c80a63be4 upstream. Add support for Dell DW5826e-m with USB-id 0x413c:0x81ea T: Bus=03 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 8 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=413c ProdID=81ea Rev= 5.04 S: Manufacturer=DELL S: Product=DW5826e-m Qualcomm Snapdragon X12 Global LTE-A S: SerialNumber=358988870177734 C:* #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA A: FirstIf#=12 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00 I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=87(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I:* If#=12 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=88(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#=13 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I:* If#=13 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Jack Wu Reviewed-by: Lars Melin Cc: stable@vger.kernel.org [ johan: reserve also interface 4 ] Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 294692d3296eee3391c348d7ea6401916d27806c Author: Adrian Korwel Date: Mon May 25 09:58:32 2026 -0500 USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr() commit 0fd2b00b2d3d05e3eaa13342b3dfb0fa85c226ae upstream. build_i2c_fw_hdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then copies le16_to_cpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header. img_header->Length is a __le16 from the firmware file and can be up to 65535. check_fw_sanity() validates the total firmware size but not img_header->Length specifically. Fix by rejecting images where img_header->Length exceeds the available destination space. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Adrian Korwel Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit f96cf7bf9fbf15d7fcf0c91fec47ba8a010369ea Author: Adrian Korwel Date: Mon May 25 09:58:31 2026 -0500 USB: serial: io_ti: fix heap overflow in get_manuf_info() commit 183c1076eca43bbb3e7bdf597456f91d81c73e74 upstream. get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Adrian Korwel [ johan: amend commit message; also check for short descriptors ] Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit a13ca53e47e500854a3b9ec18b5dc83acfec863e Author: Tristan Madani Date: Tue Jun 2 17:16:41 2026 +0000 xfrm: iptfs: fix ABBA deadlock in iptfs_destroy_state() commit c8a8a75b733467b00c08b91a38dbaf207a08ed6e upstream. iptfs_destroy_state() calls hrtimer_cancel() while holding a spinlock that the timer callback also acquires, leading to an ABBA deadlock on SMP systems. For the output timer (iptfs_timer): - iptfs_destroy_state() holds x->lock, calls hrtimer_cancel() - iptfs_delay_timer() callback takes x->lock For the drop timer (drop_timer): - iptfs_destroy_state() holds drop_lock, calls hrtimer_cancel() - iptfs_drop_timer() callback takes drop_lock Both timers use HRTIMER_MODE_REL_SOFT, so their callbacks run in softirq context. When hrtimer_cancel() is called for a soft timer that is currently executing on another CPU, hrtimer_cancel_wait_running() spins on softirq_expiry_lock -- the same lock held by the softirq running the callback. If the callback is blocked waiting for the spinlock held by the caller of hrtimer_cancel(), a circular dependency forms: CPU 0: holds lock_A -> waits for softirq_expiry_lock CPU 1: holds softirq_expiry_lock -> waits for lock_A Fix by calling hrtimer_cancel() before acquiring the respective locks. hrtimer_cancel() is safe to call without holding any lock and will wait for any in-progress callback to complete. For the output timer, the lock is still acquired afterwards to drain the packet queue. For the drop timer, the lock/unlock pair is removed entirely since it only existed to serialize with the timer callback, which hrtimer_cancel() already guarantees. Found by source code audit. Fixes: 4b3faf610cc6 ("xfrm: iptfs: add new iptfs xfrm mode impl") Cc: Christian Hopps Cc: Steffen Klassert Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit dd66f7f6e360ee82cd905517726f8e9091265de5 Author: Takao Sato Date: Tue May 26 13:09:57 2026 -0300 xfrm: iptfs: preserve shared-frag marker in iptfs_consume_frags() commit e9096a5a170e7ecd6467bc2e08668ec39897cda7 upstream. iptfs_consume_frags() transfers paged fragments from one socket buffer to another but fails to propagate the SKBFL_SHARED_FRAG flag. This is the same class of bug that was fixed in skb_try_coalesce() for CVE-2026-46300: when fragments backed by read-only page-cache pages are merged, the marker indicating their shared nature must be preserved so that ESP can decide correctly whether in-place encryption is safe. Apply the same two-line fix used in skb_try_coalesce() to iptfs_consume_frags(). Fixes: b96ba312e21c ("xfrm: iptfs: share page fragments of inner packets") Cc: stable@vger.kernel.org # 6.14+ Signed-off-by: Takao Sato Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit f9b38a8fbfa07f1deaf7ee1eb38fa8b21ea13990 Author: Wyatt Feng Date: Wed Jun 3 00:46:27 2026 +0800 xfrm: espintcp: do not reuse an in-progress partial send commit c381039ade2e161ab08c0eda73c4f8b9a7115928 upstream. espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to preserve espintcp's one-message-at-a-time transmit state. Fixes: e27cca96cd68 ("xfrm: add espintcp (RFC 8229)") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Zhengchuan Liang Reported-by: Xin Liu Assisted-by: Codex:GPT-5.4 Signed-off-by: Wyatt Feng Signed-off-by: Ren Wei Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 14d2eee0193ac3cd1bf3d014373449f0b8d35d6d Author: Gil Portnoy Date: Mon Jun 1 08:27:56 2026 +0900 ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL commit f580d27e8928828693df44ba2db0fffdbe11dfea upstream. A deferred byte-range lock (an SMB2_LOCK that blocks) registers an async work on conn->async_requests via setup_async_work(), with cancel_fn = smb2_remove_blocked_lock and cancel_argv[0] pointing at the struct file_lock. When the request is cancelled, the worker frees the file_lock with locks_free_lock() and takes the cancelled early-exit, which "goto out"s and never reaches release_async_work() -- the only site that unlinks the work from conn->async_requests and clears cancel_fn/cancel_argv. The work therefore stays matchable on async_requests with a live cancel_fn pointing at the freed file_lock, until connection teardown finally runs release_async_work(). smb2_cancel() fires cancel_fn unconditionally with no state guard, so a second SMB2_CANCEL for the same AsyncId, arriving in that window, re-runs smb2_remove_blocked_lock() on the freed file_lock -- a slab use-after-free: BUG: KASAN: slab-use-after-free in __locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- 2nd SMB2_CANCEL fires cancel_fn handle_ksmbd_work Allocated by ...: locks_alloc_lock <- smb2_lock Freed by ...: locks_free_lock <- smb2_lock (cancelled branch) ... cache file_lock_cache of size 192 Reproduced on mainline with KASAN by an authenticated SMB client. Skip a work whose state is already KSMBD_WORK_CANCELLED so its cancel callback cannot be fired a second time. Cc: stable@vger.kernel.org Signed-off-by: Gil Portnoy Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 0b38870d81ab3a04c1ab0598d9d3285f5d9d0584 Author: Anton Leontev Date: Thu Jun 4 19:59:38 2026 +0300 hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf commit 004e9ecfe6c5384f9e0b2f6f6389d42ec22789af upstream. netvsc_copy_to_send_buf() copies page buffer entries into the VMBus send buffer using phys_to_virt() on the entry PFN. Entries for the RNDIS header and the skb linear data come from kmalloc'd memory and are always in the kernel direct map, but entries for skb fragments reference page cache or user pages, which on 32-bit x86 with CONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page phys_to_virt() returns an address outside the direct map and the subsequent memcpy() faults on the transmit softirq path, which is fatal. Map the pages with kmap_local_page() instead, handling two properties of the page buffer entries: - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity, not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages). - Since commit 41a6328b2c55 ("hv_netvsc: Preserve contiguous PFN grouping in the page buffer array"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGE_SIZE, while kmap_local_page() maps a single page. Copy page by page, splitting at native page boundaries. The copy path only handles packets smaller than the send section size (6144 bytes by default); larger packets take the cp_partial path where only the RNDIS header is copied. So entries here are bounded by the section size and a copy is split at most once on 4K-page systems. On !CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and no mapping work is added. Fixes: c25aaf814a63 ("hyperv: Enable sendbuf mechanism on the send path") Cc: stable@vger.kernel.org Signed-off-by: Anton Leontev Link: https://patch.msgid.link/20260604165938.32033-1-leontyevantony@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 32d4c5d328a3ff995420f4f85163e1e403f43628 Author: Joonas Lahtinen Date: Wed Jun 10 09:03:14 2026 +0300 drm/i915/gem: Fix phys BO pread/pwrite with offset commit d21ad938398bca695a511307de38a65889e3b354 upstream. sg_page() returns struct page pointer not (void *) so the scaling of pread/pwrite is wrong for phys BO and wrong parts of BO would be accessed if non-zero offset is used. Last impacted platform with overlay or cursor planes using phys mapping was Gen3/945G/Lakeport. Reported-by: Matthew Wilcox (Oracle) Fixes: c6790dc22312 ("drm/i915: Wean off drm_pci_alloc/drm_pci_free") Cc: # v4.5+ Cc: Tvrtko Ursulin Cc: Simona Vetter Cc: Jani Nikula Cc: Rodrigo Vivi Signed-off-by: Joonas Lahtinen Reviewed-by: Tvrtko Ursulin Link: https://patch.msgid.link/20260610060314.26111-1-joonas.lahtinen@linux.intel.com (cherry picked from commit 3e49a2f85070b2fb672c1e0fdba281a4ea3aebe6) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit 0b79bcff7210ed5eb30fcd1346601c3808669919 Author: Joey Gouly Date: Thu Jun 4 11:54:34 2026 +0100 KVM: arm64: Restore POR_EL0 access to host EL0 commit cbaffe843a942c0d3102e0f9bce0e72b029b2594 upstream. CPTR_EL2.E0POE was being cleared in __deactivate_cptr_traps_vhe(), which meant that any accesses to POR_EL0 from host EL0 would trap and be reported to userspace as an Illegal instruction. This would happen after running any VM, regardless if it used POE or not. Signed-off-by: Joey Gouly Link: https://sashiko.dev/#/patchset/20260602155430.2088142-1-maz@kernel.org?part=1 Link: https://patch.msgid.link/20260604105434.2297268-1-joey.gouly@arm.com Signed-off-by: Marc Zyngier Cc: stable@vger,kernel.org Signed-off-by: Greg Kroah-Hartman commit 196f1ee137eb4a994266e789cac6a0dc1bd916c4 Author: Sean Christopherson Date: Fri May 29 20:35:41 2026 +0200 KVM: SEV: Decouple the need to sync the GHCB SA from the need to free the SA commit f041dc80de4abbdd0909d871bf64f3f87d2350ff upstream. Decouple synchronizing the GHCB SA from freeing/unpinning the SA, so that the free/unpin path can be reused when freeing a vCPU. Opportunistically add a WARN to harden KVM against stomping over (and thus leaking) an already-allocated scratch area. Cc: stable@vger.kernel.org Reviewed-by: Tom Lendacky Reviewed-by: Michael Roth Signed-off-by: Sean Christopherson Message-ID: <20260501202250.2115252-17-seanjc@google.com> Signed-off-by: Paolo Bonzini Message-ID: <20260529183549.1104619-17-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 343e95c8ecc40e0738975ef4ee24c0c35e800e6b Author: Sean Christopherson Date: Fri May 29 20:35:39 2026 +0200 KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying commit 8618004d3e897c0f1b71d9a9ab860461289bb89a upstream. When marking a page dirty, complain about not having a running/loaded vCPU if and only if the VM is still alive, i.e. its refcount is non-zero. This will allow fixing a memory leak for x86 SEV-ES guests without hitting what is effectively a false positive on the WARN. For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page across an exit to userspace, and typically unmaps the page on the next KVM_RUN. But if userspace never calls KVM_RUN after such an exit, then KVM needs to unmap the page when the vCPU is destroyed, which in turn triggers the WARN about not having a running vCPU. Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN, as is done in nested_vmx_free_vcpu() (but for completely unrelated reasons; suppressing WARN from nested_put_vmcs12_pages() is pure happenstance). But loading a vCPU during destruction is gross (ideally nVMX code would be cleaned up), risks complicating the SEV-ES code (KVM would need to ensure the temporarily load()+put() only runs when the vCPU isn't already loaded), and is ultimately pointless. The motivation for the WARN is to guard against KVM dirtying guest memory without pushing the corresponding GFN to the active vCPU's dirty ring, e.g. to ensure userspace doesn't miss a dirty page. But for the VM's refcount to reach zero, there can't be _any_ userspace mappings to the dirty ring, as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if userspace had a valid mapping for the dirty ring, then the vCPU file and thus the owning VM would still be alive. And so since userspace can't possibly reach the dirty ring, whether or not KVM technically "misses" a push to the dirty ring is irrelevant. Reported-by: Michael Roth Cc: stable@vger.kernel.org Reviewed-by: Michael Roth Signed-off-by: Sean Christopherson Message-ID: <20260501202250.2115252-15-seanjc@google.com> Signed-off-by: Paolo Bonzini Message-ID: <20260529183549.1104619-15-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 0864bdde152efe60a7c00c47beaa5e0d7adeb648 Author: Wei Liu Date: Thu Apr 23 17:26:26 2026 +0000 mshv: add a missing padding field commit 48fcc895403cc97aa6c776cb65e6aa11290c0b44 upstream. That was missed when importing the header. Reported-by: Doru Blânzeanu Reported-by: Magnus Kulke Fixes: e68bda71a2384 ("hyperv: Add new Hyper-V headers in include/hyperv") Cc: stable@kernel.org Reviewed-by: Easwar Hariharan Signed-off-by: Wei Liu Signed-off-by: Greg Kroah-Hartman commit 8bcbedce9bfaa582e3870b9e3093f88d8f437bd3 Author: Inochi Amaoto Date: Thu May 21 15:21:20 2026 +0800 mmc: litex_mmc: Use DIV_ROUND_UP for more accurate clock calculation commit b837e38c255dd9f8b53511d52e87f1fda32b3dfe upstream. The previous clock uses roundup_pow_of_two() to calculate the core clock frequency. It does not meet the actual hardware meaning. The actual frequency is calculated by "ref_clk / ((div >> 1) << 1)". Fix the clock divider calculation. Fixes: 92e099104729 ("mmc: Add driver for LiteX's LiteSDCard interface") Signed-off-by: Inochi Amaoto Reviewed-by: Gabriel Somlo Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit a0a4600b396b09a0788352cf6514efecc18867da Author: Alice Ryhl Date: Thu May 7 11:14:42 2026 +0000 rust: kasan/kbuild: fix rustc-option when cross-compiling commit 4a44b17406cb5a93f90af3df9392b3a45eb336fb upstream. The Makefile version of rustc-option currently checks whether the option exists for the host target instead of the target actually being compiled for. It was done this way in commit 46e24a545cdb ("rust: kasan/kbuild: fix missing flags on first build") to avoid a circular dependency on target.json. However, because of this, rustc-option currently does not function when cross-compiling from x86_64 to aarch64 if CONFIG_SHADOW_CALL_STACK is enabled. This is because KBUILD_RUSTFLAGS contains -Zfixed-x18 under this configuration. Since that flag does not exist on the host target, rustc-option runs into a compilation failure every time, leading to all flags being rejected as unsupported. To fix this, update rustc-option to pass a --target parameter so that the host target is not used. For targets using target.json, use a built-in target that is as close as possible to the target created with target.json to avoid the circular dependency on target.json. One scenario where this causes a boot failure: * Cross-compiled from x86_64 to aarch64. * With CONFIG_SHADOW_CALL_STACK=y * With CONFIG_KASAN_SW_TAGS=y * With CONFIG_KASAN_INLINE=n Then the resulting kernel image will fail to boot when it first calls into Rust code with a crash along the lines of "Unable to handle kernel paging request at virtual address 0ffffffc08541796". This is because the call threshold is not specified, so rustc will inline kasan operations, but the kasan shadow offset is not specified, which leads to the inlined kasan instructions being incorrect. Note that the -Zsanitizer=kernel-hwaddress parameter itself does not lead to a rustc-option failure despite being aarch64-specific because RUSTFLAGS_KASAN has not yet been added to KBUILD_RUSTFLAGS when rustc-option is evaluated by the kasan Makefile. Cc: stable@vger.kernel.org Fixes: 46e24a545cdb ("rust: kasan/kbuild: fix missing flags on first build") Signed-off-by: Alice Ryhl Link: https://patch.msgid.link/20260507-rustc-option-cross-v2-1-2f650a49c2b5@google.com [ Edited slightly: - Reset variable to avoid using the environment. - Use a simply expanded variable flavor for simplicity. - Export variable so that behavior in sub-`make`s is consistent. Signed-off-by: Greg Kroah-Hartman This matches other variables. - Miguel ] Signed-off-by: Miguel Ojeda commit d0f25a1755f2c15b1746379c8d9d7dfde85f58f5 Author: Alice Ryhl Date: Wed May 27 18:18:07 2026 +0000 rust: arm64: set uwtable llvm module flag for CONFIG_UNWIND_TABLES commit ac35b5580ace12e5d0a0b5e61e36d2c4e1ffa29c upstream. Due to a rustc bug [1] the -Cforce-unwind-tables=y flag only emits the uwtable annotation for functions, but not for the module. This means that compiler-generated functions such as 'asan.module_ctor' do not receive the uwtable annotation. When CONFIG_UNWIND_PATCH_PAC_INTO_SCS is enabled, this leads to boot failures because the dwarf information emitted for the kasan constructors is wrong, which causes the SCS boot patching code to patch the constructor in an illegal manner. Specifically, the paciasp instruction is patched, but the autiasp instruction is not. This mismatch leads to a crash when the constructor is called during boot. ================================================================== BUG: KASAN: global-out-of-bounds in do_basic_setup+0x4c/0x90 Read of size 8 at addr ffffffe3cc7eb488 by task swapper/0/1 Specifically the faulting instruction is the (*fn)() to invoke the constructor in do_ctors() of the init/main.c file. Once the fix lands in rustc, this flag can be made conditional on the rustc version. Note that passing the flag on a rustc with the fix present has no effect. [ The fix [1] has landed for Rust 1.98.0 (expected release on 2026-08-20). Thus add a version check as discussed. - Miguel ] Fixes: d077242d68a3 ("rust: support for shadow call stack sanitizer") Cc: stable@kernel.org Link: https://github.com/rust-lang/rust/pull/156973 [1] Reported-by: Bo Ye Debugged-by: Isaac Manjarres Debugged-by: Sami Tolvanen Tested-by: Isaac Manjarres Signed-off-by: Alice Ryhl Link: https://patch.msgid.link/20260527-uwtable-module-flag-v1-1-caa41342be4b@google.com [ Adjusted link and comment. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 5037b2ee1a175f74492a9281c459ade1bca88ef6 Author: Nathan Chancellor Date: Mon May 11 17:02:44 2026 +0900 ARM: Do not select HAVE_RUST when KASAN is enabled commit 84a0f7caafc679f763d3868635837e22bb89651a upstream. When KASAN is enabled, such as with allmodconfig, the build fails when building the Rust code with: error: kernel-address sanitizer is not supported for this target error: aborting due to 1 previous error make[4]: *** [rust/Makefile:654: rust/core.o] Error 1 The arm-unknown-linux-gnueabi target does not support KASAN, so avoid saying Rust is supported when it is enabled. Cc: stable@vger.kernel.org Fixes: ccb8ce526807 ("ARM: 9441/1: rust: Enable Rust support for ARMv7") Link: https://github.com/Rust-for-Linux/linux/issues/1234 Signed-off-by: Nathan Chancellor Reviewed-by: Christian Schrefl Link: https://patch.msgid.link/20260511-arm-avoid-rust-with-kasan-v1-1-24d55f4a900b@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 00875811f37221b583fe3f956671622da90e9a81 Author: Miguel Ojeda Date: Sat May 30 13:49:25 2026 +0200 rust: x86: support Rust >= 1.98.0 target spec commit 905b06d32a52afe32fcf5f30cf298c9ea6359f11 upstream. Starting with Rust 1.98.0 (expected 2026-08-20), the target spec will not support `x86-softfloat` anymore [1]. Instead, `softfloat` should be used, which is an alias. Otherwise, one gets: error: error loading target specification: rustc-abi: invalid rustc abi: 'x86-softfloat'. allowed values: 'x86-sse2', 'softfloat' at line 3 column 32 | = help: run `rustc --print target-list` for a list of built-in targets Thus conditionally use one or the other depending on the version. The alias has existed since Rust 1.95.0 (released 2026-04-16) [2], but use the newer version instead to avoid changing how the build works for existing compilers, at least until more testing takes place. Cc: Ralf Jung Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/pull/157151 [1] Link: https://github.com/rust-lang/rust/pull/151154 [2] Reviewed-by: Alice Ryhl Link: https://patch.msgid.link/20260530114925.260754-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 592be0dc491d1e45c913cdfe7a581612de8e1fe7 Author: Masami Hiramatsu (Google) Date: Mon May 25 11:21:14 2026 +0900 tracing/probes: Point the error offset correctly for eprobe argument error commit 85e0f27dd1396307913ffc5745b0c05137e9beac upstream. Fix to point the error offset correctly for eprobe argument error. In the cleanup commit 1b8b0cd754cd ("tracing/probes: Move event parameter fetching code to common parser"), due to incorrect backward compatibility aimed at conforming to the test specifications, the error location was set to 0 when a non-existent formal parameter was specified for Eprobe. However, this should be corrected in both the test and the implementation to point correct error position. Link: https://lore.kernel.org/all/177967567399.209006.1451571244515632097.stgit@devnote2/ Fixes: 1b8b0cd754cd ("tracing/probes: Move event parameter fetching code to common parser") Cc: stable@vger.kernel.org Signed-off-by: Masami Hiramatsu (Google) Reviewed-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 09df291fdf962040df5bf347c1d26a19920e9d00 Author: Eva Kurchatova Date: Wed Jun 3 18:31:42 2026 +0300 tracing: Fix CFI violation in probestub being called by tprobes commit 0652a3daa78723f955b1ebeb621665ce72bec53e upstream. The probestub is a function to allow tprobes to hook to a tracepoint to gain access to its parameters. The function itself is only referenced by the tracepoint structure which lives in the __tracepoint section. objtool explicitly ignores that section and when processing functions in the kernel, if it detects one that has no references it will seal it to have its ENDBR stripped on boot up. This means when a tprobe is attached to the sched_wakeup tracepoint, when it is triggered it will call __probestub_sched_wakeup and due to the missing ENDBR on a CFI-enabled machine it will take a #CP exception. Fix this by adding CFI_NOSEAL annotation to probestub declaration. Cc: stable@vger.kernel.org Acked-by: Masami Hiramatsu (Google) Link: https://patch.msgid.link/20260603153147.573589-1-eva.kurchatova@virtuozzo.com Fixes: d5173f753750 ("objtool: Exclude __tracepoints data from ENDBR checks") Signed-off-by: Eva Kurchatova [ Updated change log ] Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 45cb105b8642c65e9be286f7058e92314efe7ea3 Author: Andrzej Kacprowski Date: Mon Jun 1 18:16:43 2026 +0200 accel/ivpu: Fix signed integer truncation in IPC receive commit d9faef564438d1e4579c692c046603e7ada7bdf4 upstream. Fix potential buffer overflow where firmware-supplied data_size is cast to signed int before being used in min_t(). Large unsigned values (>= 0x80000000) become negative, causing unsigned wraparound and oversized memcpy operations that can overflow the stack buffer. Change min_t(int, ...) to min() as both values are unsigned and can be handled by min() without explicit cast. Fixes: 3b434a3445ff ("accel/ivpu: Use threaded IRQ to handle JOB done messages") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Andrzej Kacprowski Reviewed-by: Karol Wachowski Signed-off-by: Karol Wachowski Link: https://patch.msgid.link/20260601161643.229342-1-andrzej.kacprowski@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit fa598556ecef412edcb391f144b7642e18fdfd45 Author: Andrzej Kacprowski Date: Fri May 29 14:08:41 2026 +0200 accel/ivpu: Add buffer overflow check in MS get_info_ioctl commit fb176425837693f50c5c9fc8db6fbb04af22bd0a upstream. Add validation that the info size returned from the metric stream info query is not exceeded when checked against the allocated buffer size. If the firmware returns a size larger than the buffer, reject the operation with -EOVERFLOW instead of proceeding with an incorrect buffer copy. Fixes: cdfad4db7756 ("accel/ivpu: Add NPU profiling support") Cc: stable@vger.kernel.org # v6.18+ Signed-off-by: Andrzej Kacprowski Reviewed-by: Karol Wachowski Signed-off-by: Karol Wachowski Link: https://patch.msgid.link/20260529120841.135852-1-andrzej.kacprowski@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 8ec70c0dbdf04392a26e03e38798a373934177be Author: Andrzej Kacprowski Date: Fri May 29 13:58:42 2026 +0200 accel/ivpu: Add bounds checks for firmware log indices commit dd1311bcf0e62f0c515115f46a3813370f4a4bb1 upstream. Add validation that read and write indices in the firmware log buffer are within valid bounds (< data_size) before using them. If out-of-bounds indices are encountered (from firmware), clamp them to safe values instead of proceeding with invalid offsets. This prevents potential out-of-bounds buffer access when firmware supplies invalid log indices. Fixes: 1fc1251149a7 ("accel/ivpu: Refactor functions in ivpu_fw_log.c") Cc: stable@vger.kernel.org # v6.18+ Signed-off-by: Andrzej Kacprowski Reviewed-by: Karol Wachowski Signed-off-by: Karol Wachowski Link: https://patch.msgid.link/20260529115842.135378-1-andrzej.kacprowski@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit dd77a83915b07e2b0205adb284f08b39ae31dc4b Author: Wupeng Ma Date: Fri May 22 09:03:05 2026 +0800 mm/memory-failure: fix hugetlb_lock AA deadlock in get_huge_page_for_hwpoison commit 3c2d42b8ee345b17a4ba56b0f6492d1ff4c1178e upstream. Two concurrent madvise(MADV_HWPOISON) calls on the same hugetlb page can trigger a recursive spinlock self-deadlock (AA deadlock) on hugetlb_lock when racing with a concurrent unmap: thread#0 thread#1 -------- -------- madvise(folio, MADV_HWPOISON) -> poisons the folio successfully madvise(folio, MADV_HWPOISON) unmap(folio) try_memory_failure_hugetlb get_huge_page_for_hwpoison spin_lock_irq(&hugetlb_lock) <- held __get_huge_page_for_hwpoison hugetlb_update_hwpoison() -> MF_HUGETLB_FOLIO_PRE_POISONED goto out: folio_put() refcount: 1 -> 0 free_huge_folio() spin_lock_irqsave(&hugetlb_lock) -> AA DEADLOCK! The out: path in __get_huge_page_for_hwpoison() calls folio_put() to drop the GUP reference while the hugetlb_lock is still held by the hugetlb.c wrapper get_huge_page_for_hwpoison(). If concurrent unmap has released the page table mapping reference, folio_put() drops the folio refcount to zero, triggering free_huge_folio() which attempts to re-acquire the non-recursive hugetlb_lock. Fix this by moving hugetlb_lock acquisition from the hugetlb.c wrapper into get_huge_page_for_hwpoison(). Place spin_unlock_irq() before the folio_put() at the out: label so the folio is always released outside the lock. [akpm@linux-foundation.org: fix race, rename label per Miaohe] Link: https://sashiko.dev/#/patchset/20260522010305.4099834-1-mawupeng1@huawei.com Link: https://lore.kernel.org/f39f405e-4b4b-8f79-70fe-a2b5b62114eb@huawei.com Link: https://lore.kernel.org/20260522010305.4099834-1-mawupeng1@huawei.com Fixes: 405ce051236c ("mm/hwpoison: fix race between hugetlb free/demotion and memory_failure_hugetlb()") Signed-off-by: Wupeng Ma Acked-by: Oscar Salvador (SUSE) Acked-by: Muchun Song Reviewed-by: Kefeng Wang Acked-by: Miaohe Lin Cc: David Hildenbrand Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Naoya Horiguchi Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit cc160ce085408ae361727682809b352ab2e8cab7 Author: Manivannan Sadhasivam Date: Mon May 18 19:22:17 2026 +0530 soc: qcom: ice: Fix race between qcom_ice_probe() and of_qcom_ice_get() commit d922113ef91e6e7e8065e9070f349365341ba32e upstream. The current platform driver design causes probe ordering races with consumers (UFS, eMMC) due to ICE's dependency on SCM firmware calls. If ICE probe fails (missing ICE SCM or DT registers), devm_of_qcom_ice_get() loops with -EPROBE_DEFER, leaving consumers non-functional even when ICE should be gracefully disabled. devm_of_qcom_ice_get() doesn't know if the ICE driver probe has failed due to above reasons or it is waiting for the SCM driver. Moreover, there is no devlink dependency between ICE and consumer drivers as 'qcom,ice' is not considered as a DT 'supplier'. So the consumer drivers have no idea of when the ICE driver is going to probe. To address these issues, store the error pointer in a global xarray with ice node phandle as a key during probe in addition to the valid ice pointer and synchronize both qcom_ice_probe() and of_qcom_ice_get() using a mutex. If the xarray entry is NULL, then it implies that the driver is not probed yet, so return -EPROBE_DEFER. If it has any error pointer, return that error pointer directly. Otherwise, add the devlink as usual and return the valid pointer to the consumer. Xarray is used instead of platform drvdata, since driver core frees the drvdata during probe failure. So it cannot be used to pass the error pointer to the consumers. Note that this change only fixes the standalone ICE DT node bindings and not the ones with 'ice' range embedded in the consumer nodes, where there is no issue. Fixes: 2afbf43a4aec ("soc: qcom: Make the Qualcomm UFS/SDCC ICE a dedicated driver") Reported-by: Sumit Garg Tested-by: Sumit Garg # OP-TEE as TZ Acked-by: Sumit Garg Cc: stable@vger.kernel.org # 6.4 Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260518-qcom-ice-fix-v7-1-2a595382185b@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit dedc92b96dc1d8919a3bdf2495ede68922ef7ebc Author: Michael Bommarito Date: Thu May 21 10:45:17 2026 -0400 Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig commit dd214733544427587a95f66dbf3adff072568990 upstream. net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms. Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling packet containing packed ECHO_REQ commands. Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched. The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read. The unrestricted BR/EDR signaling parser and ECHO_REQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag. Cc: stable@vger.kernel.org Suggested-by: Luiz Augusto von Dentz Link: https://lore.kernel.org/r/20260518002800.1361430-1-michael.bommarito@gmail.com Link: https://lore.kernel.org/r/20260520135034.1060859-1-michael.bommarito@gmail.com Link: https://lore.kernel.org/r/20260521000555.3712030-1-michael.bommarito@gmail.com Assisted-by: Claude:claude-opus-4-7 Assisted-by: Codex:gpt-5-5-xhigh Signed-off-by: Michael Bommarito Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit dafc9f57140e66a10945127aa7433c3d715dc253 Author: Yuqi Xu Date: Fri May 29 16:54:23 2026 +0800 Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend commit 5c65b96b549ea2dcfde497436bf9e048deb87758 upstream. Existing advertising instances can already hold the maximum extended advertising payload. When hci_adv_bcast_annoucement() prepends the Broadcast Announcement service data to that payload, the combined data may no longer fit in the temporary buffer used to rebuild the advertising data. Reject that case before copying the existing payload and report the failure through the device log. This keeps the existing advertising data intact and avoids overrunning the temporary buffer. Fixes: 5725bc608252 ("Bluetooth: hci_sync: Fix broadcast/PA when using an existing instance") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Zhengchuan Liang Reported-by: Xin Liu Assisted-by: Codex:GPT-5.4 Signed-off-by: Yuqi Xu Signed-off-by: Ren Wei Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit c10c9c48b2903f41ed4c532043b0576e86228236 Author: Georgiy Osokin Date: Wed Apr 8 18:52:03 2026 +0300 tee: shm: fix shm leak in register_shm_helper() commit 26682f5efc276e3ad96d102019472bfbf03833b2 upstream. register_shm_helper() allocates shm before calling iov_iter_npages(). If iov_iter_npages() returns 0, the function jumps to err_ctx_put and leaks shm. This can be triggered by TEE_IOC_SHM_REGISTER with struct tee_ioctl_shm_register_data where length is 0. Jump to err_free_shm instead. Fixes: 7bdee4157591 ("tee: Use iov_iter to better support shared buffer registration") Cc: stable@vger.kernel.org Cc: lvc-project@linuxtesting.org Signed-off-by: Georgiy Osokin Reviewed-by: Sumit Garg Signed-off-by: Jens Wiklander Signed-off-by: Greg Kroah-Hartman commit 07acb9798477535933bd658ac9fa85b6cb10d995 Author: Davide Ornaghi Date: Wed Jun 10 12:39:13 2026 +0200 netfilter: nft_meta_bridge: fix stale stack leak via IIFHWADDR register commit c7d573551f9286100a055ef696cde6af54549677 upstream. NFT_META_BRI_IIFHWADDR declares its destination register with len = ETH_ALEN (6 bytes), which the register-init tracking rounds up to two 32-bit registers (8 bytes). nft_meta_bridge_get_eval() then does memcpy(dest, br_dev->dev_addr, ETH_ALEN), writing only 6 bytes and leaving the upper 2 bytes of the second register as uninitialised nft_do_chain() stack. A downstream load of that register span leaks those stale bytes to userspace. Zero the second register before the memcpy so the full declared span is written. Fixes: cbd2257dc96e ("netfilter: nft_meta_bridge: introduce NFT_META_BRI_IIFHWADDR support") Cc: stable@vger.kernel.org Signed-off-by: Davide Ornaghi Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 941d7394efda5e054e2d6f3e0dd0f6a9ba19aaa3 Author: Tristan Madani Date: Wed May 27 13:57:50 2026 +0000 netfilter: nft_tunnel: fix use-after-free on object destroy commit c32b26aaa2f9216520a38b3f4bfeec846eb3eb8a upstream. nft_tunnel_obj_destroy() calls metadata_dst_free() which directly kfree()s the metadata_dst, ignoring the dst_entry refcount. Packets that took a reference via dst_hold() in nft_tunnel_obj_eval() and are still queued (e.g. in a netem qdisc) are left with a dangling pointer. When these packets are eventually dequeued, dst_release() operates on freed memory. Replace metadata_dst_free() with dst_release() so the metadata_dst is freed only after all references are dropped. The dst subsystem already handles metadata_dst cleanup in dst_destroy() when DST_METADATA is set. Fixes: af308b94a2a4 ("netfilter: nf_tables: add tunnel support") Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit e83fc4c28226be75fbc0c41f2846935ba2b5f949 Author: Lizhi Hou Date: Wed Jun 10 08:11:27 2026 -0700 accel/amdxdna: Fix mm_struct reference leak in aie2_populate_range() [ Upstream commit 2f41af638c92bac6f1f9275ea2d1901baef578f3 ] aie2_populate_range() jumps back to the again label without calling mmput(mm), leaking a reference to the mm_struct. Add the missing mmput() before jumping to again. Fixes: e486147c912f ("accel/amdxdna: Add BO import and export") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260610151127.2994185-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 361e97d81331ca15fabf80b028b4caeb4a08862c Author: Wentao Liang Date: Wed Jun 10 10:27:05 2026 -0700 drm/xe: fix refcount leak in xe_range_fence_insert() [ Upstream commit ba36786b21d19082e696eda85bfcd49e7071944a ] xe_range_fence_insert() acquires a reference on fence via dma_fence_get() and stores it in rfence->fence. It then calls dma_fence_add_callback() and handles two cases: when the callback is successfully registered (err == 0) the fence is transferred to the tree for later cleanup; when the fence is already signaled (err == -ENOENT) it manually drops the extra reference with dma_fence_put(fence). However, dma_fence_add_callback() can fail with other errors (e.g. -EINVAL) and in that case the code falls through to the free: label without releasing the acquired reference, leaking it. Fix the leak by adding an else branch that calls dma_fence_put() before jumping to free: for any error other than -ENOENT. Fixes: 845f64bdbfc9 ("drm/xe: Introduce a range-fence utility") Signed-off-by: Wentao Liang Reviewed-by: Matthew Brost Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260610172705.3450560-1-matthew.brost@intel.com (cherry picked from commit 98c4a4201290823c2c5c7ba21692bd9a64b61021) Signed-off-by: Matthew Brost Signed-off-by: Sasha Levin commit 02f5e4db57c0cdd7bac89d503b301a093a0fa95c Author: Alexander A. Klimov Date: Sat Jun 6 14:38:10 2026 +0200 drm/vc4: fix krealloc() memory leak [ Upstream commit 5d563a5da8717629ae72f9eadf1e0e340bd1658b ] Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); if (!TMP) return; MEM = TMP; While on it, use krealloc_array(). Fixes: 6d45c81d229d ("drm/vc4: Add support for branching in shader validation.") Signed-off-by: Alexander A. Klimov Signed-off-by: Maíra Canal Link: https://patch.msgid.link/20260606123817.37222-1-grandmaster@al2klimov.de Signed-off-by: Sasha Levin commit 19a6a00ff50c284f3a9818882ad2be58b33b790a Author: Dmitry Osipenko Date: Thu Jun 4 15:27:43 2026 +0300 drm/virtio: Fix driver removal with disabled KMS [ Upstream commit f329e8325e054bd6d84d10904f8dd51137281b92 ] DRM atomic and modesetting aren't initialized if virtio-gpu driver built with disabled KMS, leading to access of uninitialized data on driver removal/unbinding and crashing kernel. Fix it by skipping shutting down atomic core with unavailable KMS. Fixes: 72122c69d717 ("drm/virtio: Add option to disable KMS support") Signed-off-by: Dmitry Osipenko Tested-by: Ryosuke Yasuoka Reviewed-by: Ryosuke Yasuoka Link: https://patch.msgid.link/20260604122743.13383-1-dmitry.osipenko@collabora.com Signed-off-by: Sasha Levin commit dda720b2928d162ad76273cd35d881bc69b71600 Author: Nikita Zhandarovich Date: Fri May 29 17:57:58 2026 +0300 drm/i915/edp: Check supported link rates DPCD read [ Upstream commit 2673cefa99ca918e7ac5b0388ff578a83656c896 ] intel_edp_set_sink_rates() reads DP_SUPPORTED_LINK_RATES into a local stack array and then parses the array unconditionally. If the read fails, the array contents are not valid and may result in bogus sink link rates being used. Use drm_dp_dpcd_read_data() and clear the sink rate array on failure, so the existing parser falls back to the default sink rate handling. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Fixes: 68f357cb7347 ("drm/i915/dp: generate and cache sink rate array for all DP, not just eDP 1.4") Signed-off-by: Nikita Zhandarovich Reviewed-by: Jani Nikula Link: https://patch.msgid.link/20260529145759.1640646-1-n.zhandarovich@fintech.ru Signed-off-by: Jani Nikula (cherry picked from commit bd61c7756b34157e093028225a69383b4b1203cc) Signed-off-by: Tvrtko Ursulin Signed-off-by: Sasha Levin commit 489f6d759fa4de7c6320161845aea8ac85a3eba9 Author: Pengyu Luo Date: Tue Mar 3 23:01:51 2026 +0800 clk: qcom: dispcc-sc8280xp: Don't park mdp_clk_src at registration time [ Upstream commit 5285b046757844435d1db96c1b5c3a6621b2979a ] Parking disp{0,1}_cc_mdss_mdp_clk_src clk broke simplefb on HUAWEI Gaokun3, the image will stuck at grey for seconds until msm takes over framebuffer. Use clk_rcg2_shared_no_init_park_ops to skip it. Signed-off-by: Pengyu Luo Tested-by: Jérôme de Bretagne Fixes: 01a0a6cc8cfd ("clk: qcom: Park shared RCGs upon registration") Link: https://lore.kernel.org/r/20260303150152.90685-1-mitltlatltl@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 3a4fc3617b7ec768f08f1a5df814d98bcc7d5176 Author: Kuan-Wei Chiu Date: Tue May 5 17:14:57 2026 +0000 clk: samsung: gs101: Fix missing USI7_USI DIV clock in peric0_clk_regs [ Upstream commit 78ee734b36284d82454e87a92094fdb926985b47 ] In the peric0_clk_regs array, the divider register offset for USI6 was accidentally listed twice, while the divider for USI7 was omitted. Missing this DIV register causes the USI7 clock divider setting to be lost and reset to its hardware default value during a suspend/resume cycle. Replace the duplicated USI6 DIV entry with the correct USI7 DIV register. Fixes: 893f133a040b ("clk: samsung: gs101: add support for cmu_peric0") Signed-off-by: Kuan-Wei Chiu Reviewed-by: Peter Griffin Reviewed-by: Tudor Ambarus Link: https://patch.msgid.link/20260505171457.1960837-1-visitorckw@gmail.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 656939c67595653fb753930a2f71096f9f2dc089 Author: Hans de Goede Date: Sat Apr 25 14:33:51 2026 +0200 clk: qcom: x1e80100-dispcc: Stop disp_cc_mdss_mdp_clk_src from getting parked [ Upstream commit bc27dbefae6ed11376d991a2921eff806ffef67c ] Parking disp_cc_mdss_mdp_clk_src at 19.2MHz causing the EFI GOP framebuffer to stop functioning. The EFI GOP framebuffer should keep working until the msm display driver loads, to help with boot debugging and to ensure display output when the msm module is not in the initramfs. Switch disp_cc_mdss_mdp_clk_src over to clk_rcg2_shared_no_init_park_ops to keep the EFI GOP working after binding the x1e80100-dispcc driver. Suggested-by: Dmitry Baryshkov Signed-off-by: Hans de Goede Reviewed-by: Dmitry Baryshkov Fixes: 01a0a6cc8cfd ("clk: qcom: Park shared RCGs upon registration") Link: https://lore.kernel.org/r/20260425123351.6292-1-johannes.goede@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f34689e7a0b3e5e16f9e2486712d7ad1814be291 Author: Dongli Zhang Date: Fri Jun 12 14:10:01 2026 -0700 KVM: VMX: Update SVI during runtime APICv activation commit b2849bec936be642b5420801f902337f2507648e upstream. The APICv (apic->apicv_active) can be activated or deactivated at runtime, for instance, because of APICv inhibit reasons. Intel VMX employs different mechanisms to virtualize LAPIC based on whether APICv is active. When APICv is activated at runtime, GUEST_INTR_STATUS is used to configure and report the current pending IRR and ISR states. Unless a specific vector is explicitly included in EOI_EXIT_BITMAP, its EOI will not be trapped to KVM. Intel VMX automatically clears the corresponding ISR bit based on the GUEST_INTR_STATUS.SVI field. When APICv is deactivated at runtime, the VM_ENTRY_INTR_INFO_FIELD is used to specify the next interrupt vector to invoke upon VM-entry. The VMX IDT_VECTORING_INFO_FIELD is used to report un-invoked vectors on VM-exit. EOIs are always trapped to KVM, so the software can manually clear pending ISR bits. There are scenarios where, with APICv activated at runtime, a guest-issued EOI may not be able to clear the pending ISR bit. Taking vector 236 as an example, here is one scenario. 1. Suppose APICv is inactive. Vector 236 is pending in the IRR. 2. To handle KVM_REQ_EVENT, KVM moves vector 236 from the IRR to the ISR, and configures the VM_ENTRY_INTR_INFO_FIELD via vmx_inject_irq(). 3. After VM-entry, vector 236 is invoked through the guest IDT. At this point, the data in VM_ENTRY_INTR_INFO_FIELD is no longer valid. The guest interrupt handler for vector 236 is invoked. 4. Suppose a VM exit occurs very early in the guest interrupt handler, before the EOI is issued. 5. Nothing is reported through the IDT_VECTORING_INFO_FIELD because vector 236 has already been invoked in the guest. 6. Now, suppose APICv is activated. Before the next VM-entry, KVM calls kvm_vcpu_update_apicv() to activate APICv. 7. Unfortunately, GUEST_INTR_STATUS.SVI is not configured, although vector 236 is still pending in the ISR. 8. After VM-entry, the guest finally issues the EOI for vector 236. However, because SVI is not configured, vector 236 is not cleared. 9. ISR is stalled forever on vector 236. Here is another scenario. 1. Suppose APICv is inactive. Vector 236 is pending in the IRR. 2. To handle KVM_REQ_EVENT, KVM moves vector 236 from the IRR to the ISR, and configures the VM_ENTRY_INTR_INFO_FIELD via vmx_inject_irq(). 3. VM-exit occurs immediately after the next VM-entry. The vector 236 is not invoked through the guest IDT. Instead, it is saved to the IDT_VECTORING_INFO_FIELD during the VM-exit. 4. KVM calls kvm_queue_interrupt() to re-queue the un-invoked vector 236 into vcpu->arch.interrupt. A KVM_REQ_EVENT is requested. 5. Now, suppose APICv is activated. Before the next VM-entry, KVM calls kvm_vcpu_update_apicv() to activate APICv. 6. Although APICv is now active, KVM still uses the legacy VM_ENTRY_INTR_INFO_FIELD to re-inject vector 236. GUEST_INTR_STATUS.SVI is not configured. 7. After the next VM-entry, vector 236 is invoked through the guest IDT. Finally, an EOI occurs. However, due to the lack of GUEST_INTR_STATUS.SVI configuration, vector 236 is not cleared from the ISR. 8. ISR is stalled forever on vector 236. Using QEMU as an example, vector 236 is stuck in ISR forever. (qemu) info lapic 1 dumping local APIC state for CPU 1 LVT0 0x00010700 active-hi edge masked ExtINT (vec 0) LVT1 0x00010400 active-hi edge masked NMI LVTPC 0x00000400 active-hi edge NMI LVTERR 0x000000fe active-hi edge Fixed (vec 254) LVTTHMR 0x00010000 active-hi edge masked Fixed (vec 0) LVTT 0x000400ec active-hi edge tsc-deadline Fixed (vec 236) Timer DCR=0x0 (divide by 2) initial_count = 0 current_count = 0 SPIV 0x000001ff APIC enabled, focus=off, spurious vec 255 ICR 0x000000fd physical edge de-assert no-shorthand ICR2 0x00000000 cpu 0 (X2APIC ID) ESR 0x00000000 ISR 236 IRR 37(level) 236 The issue isn't applicable to AMD SVM as KVM simply writes vmcb01 directly irrespective of whether L1 (vmcs01) or L2 (vmcb02) is active (unlike VMX, there is no need/cost to switch between VMCBs). In addition, APICV_INHIBIT_REASON_IRQWIN ensures AMD SVM AVIC is not activated until the last interrupt is EOI'd. Fix the bug by configuring Intel VMX GUEST_INTR_STATUS.SVI if APICv is activated at runtime. Signed-off-by: Dongli Zhang Reviewed-by: Chao Gao Link: https://patch.msgid.link/20251110063212.34902-1-dongli.zhang@oracle.com [sean: call out that SVM writes vmcb01 directly, tweak comment] Link: https://patch.msgid.link/20251205231913.441872-2-seanjc@google.com Signed-off-by: Sean Christopherson (cherry picked from commit b2849bec936be642b5420801f902337f2507648e) Cc: stable@vger.kernel.org # 6.6.x and above Cc: Gulshan Gabel Signed-off-by: Jon Kohler Signed-off-by: Sasha Levin commit 07d9a0870a178843cea44cfd58c27445dc94cf5f Author: Ido Schimmel Date: Tue Jun 9 17:54:48 2026 +0300 ipv6: Fix a potential NPD in cleanup_prefix_route() [ Upstream commit b70c687b7cf267fb08586667a3946c8851cad672 ] addrconf_get_prefix_route() can return the fib6_null_entry sentinel entry which has a NULL fib6_table pointer. Therefore, before setting the route's expiration time, check that we are not working with this entry, as otherwise a NPD will be triggered [1]. Note that the other callers of addrconf_get_prefix_route() are not susceptible to this bug: 1. addrconf_prefix_rcv(): Requests a route with the 'RTF_ADDRCONF | RTF_PREFIX_RT' flags which are not set on fib6_null_entry. 2. modify_prefix_route(): Fixed by commit a747e02430df ("ipv6: avoid possible NULL deref in modify_prefix_route()"). 3. __ipv6_ifa_notify(): Calls ip6_del_rt() which specifically checks for fib6_null_entry and returns an error. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [...] Call Trace: __kasan_check_byte (mm/kasan/common.c:573) lock_acquire.part.0 (kernel/locking/lockdep.c:5842 (discriminator 1)) _raw_spin_lock_bh (kernel/locking/spinlock.c:182 (discriminator 1)) cleanup_prefix_route (net/ipv6/addrconf.c:1280) ipv6_del_addr (net/ipv6/addrconf.c:1342) inet6_addr_del.isra.0 (net/ipv6/addrconf.c:3119) inet6_rtm_deladdr (net/ipv6/addrconf.c:4812) rtnetlink_rcv_msg (net/core/rtnetlink.c:6997) netlink_rcv_skb (net/netlink/af_netlink.c:2555) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1899) __sock_sendmsg (net/socket.c:802 (discriminator 4)) ____sys_sendmsg (net/socket.c:2698) ___sys_sendmsg (net/socket.c:2752) __sys_sendmsg (net/socket.c:2784) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Fixes: 5eb902b8e719 ("net/ipv6: Remove expired routes with a separated list of routes.") Reported-by: Ji'an Zhou Reviewed-by: David Ahern Signed-off-by: Ido Schimmel Link: https://patch.msgid.link/20260609145448.768318-1-idosch@nvidia.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 2c98343c9b23a4f271272938c49fbf5271719996 Author: Jiawen Wu Date: Mon Jun 8 15:08:40 2026 +0800 net: txgbe: initialize module info buffer [ Upstream commit 0487cfca46517ff6699c72dc1a8872b0af3c31a9 ] The module info buffer should be initialized to 0 before the firmware returns information. Otherwise, there is a risk that the buffer field not filled by the firmware is random value. Fixes: 343929799ace ("net: txgbe: Support to handle GPIO IRQs for AML devices") Signed-off-by: Jiawen Wu Link: https://patch.msgid.link/20260608070842.36504-2-jiawenwu@trustnetic.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 19a4d2aace1deaa5a7d541fd69c5638cf710b2a8 Author: Jiawen Wu Date: Tue Nov 18 16:02:56 2025 +0800 net: txgbe: rename the SFP related [ Upstream commit dbba6b7a47cba914d48890da7233a64c7b9f3ccc ] QSFP supported will be introduced for AML 40G devices, the code related to identify various modules should be renamed to more appropriate names. And struct txgbe_hic_i2c_read used to get module information is renamed as struct txgbe_hic_get_module_info, because another SW-FW command to read I2C will be added later. Signed-off-by: Jiawen Wu Link: https://patch.msgid.link/20251118080259.24676-3-jiawenwu@trustnetic.com Signed-off-by: Paolo Abeni Stable-dep-of: 0487cfca4651 ("net: txgbe: initialize module info buffer") Signed-off-by: Sasha Levin commit 9157060fed92ca6877337c89d4d6d352840d2892 Author: Jiawen Wu Date: Tue Nov 18 16:02:55 2025 +0800 net: txgbe: support CR modules for AML devices [ Upstream commit 354d128aa7212c53ffc7127877953264a445f5af ] Support to identify 25G/10G CR modules for AML devices. Autoneg is enbaled by default in CR mode. Signed-off-by: Jiawen Wu Link: https://patch.msgid.link/20251118080259.24676-2-jiawenwu@trustnetic.com Signed-off-by: Paolo Abeni Stable-dep-of: 0487cfca4651 ("net: txgbe: initialize module info buffer") Signed-off-by: Sasha Levin commit 7649ba2b1291fc478e5eab457fa8280b3dc9c68d Author: Jiawen Wu Date: Tue Oct 14 14:17:25 2025 +0800 net: txgbe: optimize the flow to setup PHY for AML devices [ Upstream commit 1f863ce5c71276710a7689c88bf4003fa5173998 ] To adapt to new firmware for AML devices, the driver should send the "SET_LINK_CMD" to the firmware only once when switching PHY interface mode, and no longer needs to re-trigger PHY configuration based on the RX signal interrupt (TXGBE_GPIOBIT_3). In previous firmware versions, the PHY was configured only after receiving "SET_LINK_CMD", and might remain incomplete if the RX signal was lost. To handle this case, the driver used TXGBE_GPIOBIT_3 interrupt to resend the command. This workaround is no longer necessary with the new firmware. And the unknown link speed is permitted in the mailbox buffer. Signed-off-by: Jiawen Wu Link: https://patch.msgid.link/20251014061726.36660-3-jiawenwu@trustnetic.com Signed-off-by: Paolo Abeni Stable-dep-of: 0487cfca4651 ("net: txgbe: initialize module info buffer") Signed-off-by: Sasha Levin commit af08fe9ba091e747a1f588e61ba5466a5dc3a239 Author: Til Kaiser Date: Sun Jun 7 15:49:43 2026 +0200 net: mvpp2: build skb from XDP-adjusted data on XDP_PASS [ Upstream commit 77a6b90ce56bc982dcfa94229b8e28e6abb16e95 ] When an XDP program uses bpf_xdp_adjust_head() or bpf_xdp_adjust_tail() and then returns XDP_PASS, mvpp2 still builds the skb from fixed offsets derived from the original RX descriptor. Packet geometry changes made by the XDP program are therefore discarded before the skb reaches the stack. Update rx_offset and rx_bytes from xdp.data and xdp.data_end for XDP_PASS. This makes skb_reserve() and skb_put() reflect the packet seen by XDP, and makes RX byte accounting for XDP_PASS follow the length of the skb passed to the network stack. Keep a separate rx_sync_size for page-pool recycling on skb allocation failure, which must stay tied to the received buffer range. Non-PASS verdicts continue to account the descriptor length because no skb is passed up in those cases. Fixes: 07dd0a7aae7f ("mvpp2: add basic XDP support") Signed-off-by: Til Kaiser Link: https://patch.msgid.link/20260607134943.21996-5-mail@tk154.de Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 8a2126c5afe89f8ceeb60a3afb9f075b736194cd Author: Til Kaiser Date: Sun Jun 7 15:49:42 2026 +0200 net: mvpp2: refill RX buffers before XDP or skb use [ Upstream commit 5e8e2a9624df72fca7c736b2966b2cbf6c9c3ff6 ] The RX error path returns the current descriptor buffer to the hardware BM pool. That is only valid while the driver still owns the buffer. mvpp2_rx_refill() can fail after the current buffer has been handed to XDP or attached to an skb. In those cases mvpp2_run_xdp() may have recycled, redirected, or queued the page for XDP_TX, and an skb free also retires the data buffer. Returning such a buffer to BM lets hardware DMA into memory that is no longer owned by the RX ring. Refill the BM pool before handing the current buffer to XDP or to the skb. If the allocation fails there, drop the packet and return the still-owned current buffer to BM, preserving the pool depth. Once the refill succeeds, later local drops retire/free the current buffer instead of returning it to BM. Fixes: 07dd0a7aae7f ("mvpp2: add basic XDP support") Fixes: d6526926de73 ("net: mvpp2: fix memory leak in mvpp2_rx") Signed-off-by: Til Kaiser Link: https://patch.msgid.link/20260607134943.21996-4-mail@tk154.de Signed-off-by: Paolo Abeni Stable-dep-of: 77a6b90ce56b ("net: mvpp2: build skb from XDP-adjusted data on XDP_PASS") Signed-off-by: Sasha Levin commit 910617a4e67dbdd5fdb39d9dc6a51e491e1b2c3e Author: Til Kaiser Date: Sun Jun 7 15:49:41 2026 +0200 net: mvpp2: limit XDP frame size to the RX buffer [ Upstream commit f3c6aa078927e6fe8121c9c591ddee8716c5305a ] mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet. Fixes: 07dd0a7aae7f ("mvpp2: add basic XDP support") Signed-off-by: Til Kaiser Link: https://patch.msgid.link/20260607134943.21996-3-mail@tk154.de Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit a13199fa224e9f776f4005d5037df03aa9ea8f37 Author: Til Kaiser Date: Sun Jun 7 15:49:40 2026 +0200 net: mvpp2: sync RX data at the hardware packet offset [ Upstream commit 180235600934bef6add3be637c296d6cf3272e67 ] mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame. Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware. Fixes: e1921168bbd4 ("mvpp2: sync only the received frame") Signed-off-by: Til Kaiser Link: https://patch.msgid.link/20260607134943.21996-2-mail@tk154.de Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 78069a6d8bc86c9e036eb82c2af4a19cc1871a53 Author: Florian Westphal Date: Tue Jun 9 21:28:09 2026 +0200 netfilter: nft_exthdr: fix register tracking for F_PRESENT flag [ Upstream commit 772cecf198da732faebb5dcfc46d66a505be8495 ] nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs. Bail out if userspace requests too much data when F_PRESENT is set. Reported-by: Ji'an Zhou Fixes: c078ca3b0c5b ("netfilter: nft_exthdr: Add support for existence check") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit af1b7699466f6556b351fa25d3dc870abfb5d310 Author: Xiang Mei Date: Tue Jun 9 15:55:02 2026 -0700 netfilter: nf_log: validate MAC header was set before dumping it [ Upstream commit a84b6fedbc97078788be78dbdd7517d143ad1a77 ] The fallback path of dump_mac_header() guards the MAC header access only with "skb->mac_header != skb->network_header", without checking skb_mac_header_was_set(). When the MAC header is unset, mac_header is 0xffff, so the test passes and skb_mac_header(skb) returns skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads dev->hard_header_len bytes out of bounds into the kernel log. This is reachable via the netdev logger: nf_log_unknown_packet() calls dump_mac_header() unconditionally, and an skb sent through AF_PACKET with PACKET_QDISC_BYPASS reaches the egress hook with mac_header still unset (__dev_queue_xmit(), which would reset it, is bypassed). Add the skb_mac_header_was_set() check the ARPHRD_ETHER path already uses, and replace the open-coded MAC header length test with skb_mac_header_len(). Only skbs with an unset MAC header are affected; valid ones are dumped as before. BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasan_report (mm/kasan/report.c:595) dump_mac_header (net/netfilter/nf_log_syslog.c:831) nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963) nf_log_packet (net/netfilter/nf_log.c:260) nft_log_eval (net/netfilter/nft_log.c:60) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307) nf_hook_slow (net/netfilter/core.c:619) nf_hook_direct_egress (net/packet/af_packet.c:257) packet_xmit (net/packet/af_packet.c:280) packet_sendmsg (net/packet/af_packet.c:3114) __sys_sendto (net/socket.c:2265) Fixes: 7eb9282cd0ef ("netfilter: ipt_LOG/ip6t_LOG: add option to print decoded MAC header") Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 08a3e218064db11f154ad9ad5541751ea7f34ebe Author: Kyle Zeng Date: Sat Jun 6 01:10:31 2026 -0700 netfilter: x_tables: avoid leaking percpu counter pointers [ Upstream commit f7f2fbb0e893a0238dc464f8d8c0f5609bec584f ] The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot. On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace. Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer. Fixes: 71ae0dff02d7 ("netfilter: xtables: use percpu rule counters") Signed-off-by: Kyle Zeng Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 9d017671dcfcec23321fb7962dea624f9e71ddb1 Author: Weiming Shi Date: Wed Jun 3 00:38:17 2026 -0700 netfilter: nf_conntrack: destroy stale expectfn expectations on unregister [ Upstream commit c3009418f9fa1dcb3eb86f4d8c92583537b5faa3 ] NAT helpers such as nf_nat_h323 store a raw pointer to module text in exp->expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister() only unlinks the callback descriptor and never walks the expectation table, so an expectation pending at module removal survives with a dangling exp->expectfn into freed module text. When the expected connection arrives, init_conntrack() invokes exp->expectfn(), now a stale pointer into the unloaded module. Reproduced on a KASAN build by loading the H.323 helpers, creating a Q.931 expectation, unloading nf_nat_h323, then connecting to the expected port: Oops: int3: 0000 [#1] SMP KASAN NOPTI RIP: 0010:0xffffffffa06102d1 init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862) nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049) ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223) nf_hook_slow (net/netfilter/core.c:619) __ip_local_out (net/ipv4/ip_output.c:120) __tcp_transmit_skb (net/ipv4/tcp_output.c:1715) tcp_connect (net/ipv4/tcp_output.c:4374) tcp_v4_connect (net/ipv4/tcp_ipv4.c:345) __sys_connect (net/socket.c:2167) Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323] Reaching the dangling state requires CAP_SYS_MODULE in the initial user namespace to remove a NAT helper that still has live expectations, so this is a robustness fix; leaving an expectation pointing at freed text is wrong regardless. Add nf_ct_helper_expectfn_destroy(), which walks the expectation table and drops every expectation whose ->expectfn matches the descriptor being torn down. Call it from each NAT helper's exit path after the existing RCU grace period, so no expectation outlives the code it points at and no extra synchronize_rcu() is introduced. With the fix, the same reproducer runs to completion without the Oops. Fixes: f587de0e2feb ("[NETFILTER]: nf_conntrack/nf_nat: add H.323 helper port") Reported-by: Xiang Mei Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Weiming Shi Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 4beffcd726e2a731cea4dc18e1fbc55c8d76f1a0 Author: Florian Westphal Date: Tue Jun 2 17:04:25 2026 +0200 netfilter: revalidate bridge ports [ Upstream commit ccb9fd4b87538ccf19ccff78ee26700526d94867 ] ebt_redirect_tg() dereferences br_port_get_rcu() return without a NULL check, causing a kernel panic when the bridge port has been removed between the original hook invocation and an NFQUEUE reinject. A mere NULL check isn't sufficient, however. As sashiko review points out userspace can not only remove the port from the bridge, it could also place the device in a different virtual device, e.g. macvlan. If this happens, we must drop the packet, there is no way for us to reinject it into the bridge path. Switch to _upper API, we don't need the bridge port structure. Also, this fix keeps another bug intact: Both nfnetlink_log and nfnetlink_queue use CONFIG_BRIDGE_NETFILTER too aggressive, which prevents certain logging features when queueing in bridge family: NETFILTER_FAMILY_BRIDGE can be enabled while the old CONFIG_BRIDGE_NETFILTER cruft is off. Fixes tag is a common ancestor, this was always broken. Fixes: f350a0a87374 ("bridge: use rx_handler_data pointer to store net_bridge_port pointer") Reported-by: Ji'an Zhou Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 865e94f6d8a5b99246975ac52a8857c7877ee3a0 Author: Felix Gu Date: Wed Jun 10 20:08:17 2026 +0800 spi: rzv2h-rspi: Fix SPDR read access width for 16-bit RX [ Upstream commit 310628484ef06f95c5589374fade917a5689787b ] The RZ/V2H hardware manual (section 7.5.2.2.1) specifies that read access size for the SPI Data Register (SPDR) are fixed at 32 bits. The RZV2H_RSPI_RX macro for the 16-bit data path used readw(), violating this requirement. Switch to readl() for the 16-bit RX path to conform to the hardware specification. Fixes: 8b61c8919dff ("spi: Add driver for the RZ/V2H(P) RSPI IP") Suggested-by: Geert Uytterhoeven Signed-off-by: Felix Gu Reviewed-by: Geert Uytterhoeven Reviewed-by: Fabrizio Castro Link: https://patch.msgid.link/20260610-rzv2h-rspi-v2-1-40c80b4a2c90@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5ae8a38169fc52db88f7b42e941ed4d2153ce1cb Author: Breno Leitao Date: Mon Jun 8 02:32:05 2026 -0700 rds: mark snapshot pages dirty in rds_info_getsockopt() [ Upstream commit 512db8267b73a220a64180d95ab5eebe7c4964a8 ] rds_info_getsockopt() pins the destination user pages with FOLL_WRITE and the RDS_INFO_* producers memcpy the snapshot into them through kmap_atomic(). Because that copy goes through the kernel direct map, the dirty bit on the user PTE is never set, so unpin_user_pages() releases the pages without marking them dirty. A file-backed destination page can then be reclaimed without writeback, silently discarding the copied data. Use unpin_user_pages_dirty_lock() with make_dirty=true so the modified pages are marked dirty before they are unpinned. Fixes: a8c879a7ee98 ("RDS: Info and stats") Signed-off-by: Breno Leitao Reviewed-by: Allison Henderson Link: https://patch.msgid.link/20260608-rds_fix-v1-1-006c88543408@debian.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2abfb19bbb81958714ad1d43ebeb65b30394184b Author: Eric Dumazet Date: Mon Jun 8 16:46:13 2026 +0000 ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() [ Upstream commit a5c0359f5cbc51a2e2b114d6041e0f3c73f903e9 ] In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions. The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address. Fixes: fbe68ee87522 ("vti6: Add a lookup method for tunnels with wildcard endpoints.") Signed-off-by: Eric Dumazet Cc: Steffen Klassert Reviewed-by: Nicolas Dichtel Link: https://patch.msgid.link/20260608164613.933023-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5fd1fa5a4254bfdd70571c77f5e3bcb4e43738d5 Author: Xiang Mei Date: Sat Jun 6 22:44:28 2026 -0700 tun: zero the whole vnet header in tun_put_user() [ Upstream commit 7f2fcff15e99bb852f6967396ed12b38376e2c8d ] tun_put_user() declares an on-stack struct virtio_net_hdr_v1_hash_tunnel without zeroing it. For a non-tunnel skb, virtio_net_hdr_tnl_from_skb() only initializes the first 10 bytes (sizeof(struct virtio_net_hdr)), leaving bytes 10..23 (num_buffers and the hash/tunnel fields) as stack garbage. An unprivileged user can set the vnet header size to 24 with TUNSETVNETHDRSZ, so __tun_vnet_hdr_put() copies all 24 bytes of the partially-initialized struct to userspace, leaking 14 bytes of kernel stack on every read of a non-tunnel packet. Fix it the same way tun_get_user() already does by zeroing the whole header right after declaration. Fixes: 288f30435132 ("tun: enable gso over UDP tunnel support.") Reported-by: Weiming Shi Signed-off-by: Xiang Mei Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260607054428.3050243-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dcf458120add64c96a6ef5cf719340453f6e6abf Author: Weiming Shi Date: Sat Jun 6 12:24:48 2026 -0700 net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic completion [ Upstream commit 34080db3e70ddf94c38512ad2331e3c3afca6cc1 ] rds_ib_xmit_atomic() always programs a masked atomic opcode (IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD) for every RDS atomic cmsg. But the completion-side switch in rds_ib_send_unmap_op() only handles the non-masked opcodes, so a masked atomic completion falls through to default and returns rm == NULL while send->s_op is left set. rds_ib_send_cqe_handler() then dereferences the NULL rm via rm->m_final_op, oopsing in softirq context. An unprivileged AF_RDS sendmsg() of an atomic cmsg over an active RDS/IB connection triggers it; on hardware that natively accepts masked atomics (mlx4, mlx5) no extra setup is needed. RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR! Oops: general protection fault [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197] RIP: rds_ib_send_cqe_handler+0x25c/0xb10 (net/rds/ib_send.c:282) Call Trace: rds_ib_send_cqe_handler (net/rds/ib_send.c:282) poll_scq (net/rds/ib_cm.c:274) rds_ib_tasklet_fn_send (net/rds/ib_cm.c:294) tasklet_action_common (kernel/softirq.c:943) handle_softirqs (kernel/softirq.c:573) run_ksoftirqd (kernel/softirq.c:479) Kernel panic - not syncing: Fatal exception in interrupt Handle the masked atomic opcodes in the same case as the non-masked ones: they map to the same struct rds_message.atomic union member, so the existing container_of()/rds_ib_send_unmap_atomic() body is correct for them. Fixes: 20c72bd5f5f9 ("RDS: Implement masked atomic operations") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Reviewed-by: Allison Henderson Link: https://patch.msgid.link/20260606192447.1179255-2-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3dde4fb941fa5649ab809f6cd3e20e0c424a4e31 Author: Kyle Zeng Date: Sat Jun 6 19:18:19 2026 -0700 net: guard timestamp cmsgs to real error queue skbs [ Upstream commit 1ee90b77b727df903033db873c75caac5c27ec98 ] skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership. Fixes: 8605330aac5a ("tcp: fix SCM_TIMESTAMPING_OPT_STATS for normal skbs") Signed-off-by: Kyle Zeng Reviewed-by: Kuniyuki Iwashima Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260607021819.49698-1-kylebot@openai.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7560afb8cddafd829e709d7ea09230e45a825557 Author: Xin Long Date: Sun Jun 7 19:03:47 2026 -0400 sctp: validate embedded INIT chunk and address list lengths in cookie [ Upstream commit 6f4c80a2a7e6d06753b89a578b710a2499a5e62b ] sctp_unpack_cookie() only checked that the embedded INIT chunk length did not exceed the remaining cookie payload, but did not ensure that the INIT chunk is large enough to contain a complete INIT header. A malformed COOKIE_ECHO can therefore carry a truncated INIT chunk whose length field is smaller than sizeof(struct sctp_init_chunk). Later, sctp_process_init() accesses INIT parameters unconditionally, which may lead to out-of-bounds reads. In addition, raw_addr_list_len is not fully validated against the remaining cookie payload. When cookie authentication is disabled, an attacker can supply an oversized raw_addr_list_len and cause sctp_raw_to_bind_addrs() to read beyond the end of the cookie. The address parser also lacks sufficient bounds checks for parameter headers and lengths, allowing malformed address parameters to trigger out-of-bounds reads. Fix this by: - requiring the embedded INIT chunk length to be at least sizeof(struct sctp_init_chunk); - validating that the INIT chunk and raw address list together fit within the cookie payload; - verifying sufficient data exists for each address parameter header and payload before parsing it. Note that sctp_verify_init() must be called after sctp_unpack_cookie() and before sctp_process_init() when cookie authentication is disabled. This will be addressed in a separate patch. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Sashiko Signed-off-by: Xin Long Link: https://patch.msgid.link/75af23a89adf881a0895d511775e4770da367cbf.1780873427.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ecf8904067dcba0dad86ece80874841e60317885 Author: Eric Dumazet Date: Mon Jun 8 15:59:18 2026 +0000 ip6_vti: set netns_immutable on the fallback device. [ Upstream commit d289d5307762d1838aaece22c6b6fcad9e8865f9 ] john1988 and Noam Rathaus reported that vti6_init_net() does not set the netns_immutable flag on the per-netns fallback tunnel device (ip6_vti0). Other similar tunnel drivers (like ip6_tunnel, sit, ip6_gre, and ip_tunnel) correctly set this flag during their fallback device initialization to prevent them from being moved to another network namespace. Fixes: 61220ab34948 ("vti6: Enable namespace changing") Reported-by: Noam Rathaus Signed-off-by: Eric Dumazet Cc: Steffen Klassert Reviewed-by: Nicolas Dichtel Link: https://patch.msgid.link/20260608155918.787644-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f76a8b323e28e0951f979dbef20a7496383c47df Author: Michael Bommarito Date: Mon Jun 8 08:22:34 2026 -0400 sctp: fix uninit-value in __sctp_rcv_asconf_lookup() [ Upstream commit f8373d7090b745728de66308deeecc67e8d319ce ] __sctp_rcv_asconf_lookup() in net/sctp/input.c only checks that the ASCONF chunk can hold the ADDIP header and a parameter header, then calls af->from_addr_param(), which reads the full address (16 bytes for IPv6) trusting the parameter's declared length. An unauthenticated peer can send a truncated trailing ASCONF chunk that declares an IPv6 address parameter but stops after the 4-byte parameter header; reached from the no-association lookup path, from_addr_param() then reads uninitialized bytes past the parameter. Impact: an unauthenticated SCTP peer makes the receive path read up to 16 bytes of uninitialized memory past a truncated ASCONF address parameter. The sibling __sctp_rcv_init_lookup() bounds parameters with sctp_walk_params(); this path open-codes the fetch and omits the bound. Verify the whole address parameter lies within the chunk before from_addr_param() reads it, the same class of fix as commit 51e5ad549c43 ("net: sctp: fix KMSAN uninit-value in sctp_inq_pop"). Fixes: df2185771439 ("[SCTP]: Update association lookup to look at ASCONF chunks as well") Signed-off-by: Michael Bommarito Acked-by: Xin Long Link: https://patch.msgid.link/20260608122234.459098-1-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d23d53355300142779457af4f2ff58091ac9a2cb Author: Vijendar Mukunda Date: Tue Jun 9 21:38:44 2026 +0530 ASoC: SOF: amd: fix for ipc flags check [ Upstream commit 6042c91df60e825625bc7d5c5c3b5a87b91d5805 ] Firmware will set dsp_ack to 1 when firmware sends response for the IPC command issued by host. Similarly dsp_msg flag will be updated to 1. During ACP D0 entry, the value read from the sof_dsp_ack_write scratch flag can be uninitialized. A non-zero garbage value is treated as a pending DSP IPC ack before SOF_FW_BOOT_COMPLETE, causing a spurious "IPC reply before FW_BOOT_COMPLETE" log. Fix the condition checks for ipc flags. Fixes: 738a2b5e2cc9 ("ASoC: SOF: amd: Add IPC support for ACP IP block") Link: https://github.com/thesofproject/linux/pull/5642 Signed-off-by: Vijendar Mukunda Tested-by: Umang Jain Link: https://patch.msgid.link/20260609160938.3717513-1-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6c75ee4d1d4056ceeeb53fb20def3eb89bf0c5b0 Author: Jeremy Kerr Date: Mon Jun 8 09:25:41 2026 +0800 net: mctp: usb: don't fail mctp_usb_rx_queue on a deferred submission [ Upstream commit 881a3113b74964918cdd72747e3bc119c02b0c0c ] In the ndo_open path, a deferred queue open will report a failure, and so the netdev will not be ndo_stop()ed, leaving us with the rx_retry work potentially pending. Don't report a deferred queue as an error, as we are still operational. This means we use the ndo_stop() path for future cleanup, which handles rx_retry_work cancellation. Fixes: 0791c0327a6e ("net: mctp: Add MCTP USB transport driver") Signed-off-by: Jeremy Kerr Link: https://patch.msgid.link/20260608-dev-mctp-usb-rx-requeue-v2-2-29a3aa507609@codeconstruct.com.au Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 9c46f3ee1837f6881cb99a52ffecb2760f11dc73 Author: Jeremy Kerr Date: Mon Jun 8 09:25:40 2026 +0800 net: mctp: usb: fix race between urb completion and rx_retry cancellation [ Upstream commit 54665dce982689e2fd99b32e9a0dcc204fda8a51 ] It's possible that sequencing between setting ->stopped and cancelling the rx_retry work (in ndo_stop) could leave us with an urb queued: T1: ndo_stop T2: rx_retry_work ------------ ---------------- LD: ->stopped => false ST: ->stopped <= true usb_kill_urb() mctp_usb_rx_queue() usb_submit_urb() cancel_delayed_work_sync() That urb completion can then re-schedule rx_retry_work. Strenghen the sequencing between the stop (preventing another requeue) and the cancel by updating both atomically under a new rx lock. After setting ->rx_stopped, and cancelling pending work, we know that the requeue cannot occur, so all that's left is killing any pending urb. Fixes: 0791c0327a6e ("net: mctp: Add MCTP USB transport driver") Signed-off-by: Jeremy Kerr Link: https://patch.msgid.link/20260608-dev-mctp-usb-rx-requeue-v2-1-29a3aa507609@codeconstruct.com.au Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit bace7b99bfa555fe833aee8827b8004c43666d02 Author: Marco Scardovi Date: Mon Jun 8 01:05:02 2026 +0200 gpio: rockchip: fix generic IRQ chip leak on remove [ Upstream commit 1c1e0fc88d6ef65bf15d517853251f75ab9d18c3 ] The driver allocates domain generic chips using irq_alloc_domain_generic_chips() during probe. However, on driver remove/teardown, the generic chips are not automatically freed when the IRQ domain is removed because the domain flags do not include IRQ_DOMAIN_FLAG_DESTROY_GC. This causes both the domain generic chips structure and the associated generic chips to be leaked. Additionally, the generic chips remain on the global gc_list and may later be visited by generic IRQ chip suspend, resume, or shutdown callbacks after the GPIO bank has been removed, potentially resulting in a use-after-free and kernel crash. Fix the resource leak by explicitly calling irq_domain_remove_generic_chips() before removing the IRQ domain in rockchip_gpio_remove(). Fixes: 936ee2675eee ("gpio/rockchip: add driver for rockchip gpio") Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Marco Scardovi Link: https://patch.msgid.link/20260607230504.35392-2-scardracs@disroot.org Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 5d4bca5cbb691821f27d3072ad5227d69f26153c Author: Ruoyu Wang Date: Tue Jun 9 15:33:13 2026 +0800 gpio: zynq: fix runtime PM leak on remove [ Upstream commit 6edb934de9bda3b7abcec856eaee6fc8b4278dd1 ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error. zynq_gpio_remove() uses it to keep the controller active while removing the GPIO chip, but never drops the usage counter again. Balance the get with pm_runtime_put_noidle() after disabling runtime PM. Fixes: 3242ba117e9b ("gpio: Add driver for Zynq GPIO controller") Signed-off-by: Ruoyu Wang Link: https://patch.msgid.link/20260609073313.5-1-ruoyuw560@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit c838ffc154cb2cb9fce8782fb6a84150a00ff793 Author: Chih Kai Hsu Date: Thu Jun 4 17:22:47 2026 +0800 r8152: handle the return value of usb_reset_device() [ Upstream commit 19440600e729d4f74a42591a872099cf25c7d28a ] If usb_reset_device() returns a negative error code, stop the process of probing. Fixes: 10c3271712f5 ("r8152: disable the ECM mode") Signed-off-by: Chih Kai Hsu Reviewed-by: Hayes Wang Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260604092247.27158-450-nic_swsd@realtek.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ecc55aad3390129a87106841f4b68bf3d70c9264 Author: Adrian Moreno Date: Thu Jun 4 14:19:46 2026 +0200 net: openvswitch: fix possible kfree_skb of ERR_PTR [ Upstream commit ee30dd2909d8b98619f4341c70ec8dc8e155ab02 ] After the patch in the "Fixes" tag, the allocation of the "reply" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming "reply" is allocated before locking: it is freed after unlocking. If "reply" allocation happens after locking the mutex and it fails, "reply" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value. Fixes: 893f139b9a6c ("openvswitch: Minimize ovs_flow_cmd_new|set critical sections.") Signed-off-by: Adrian Moreno Reviewed-by: Aaron Conole Acked-by: Eelco Chaudron Link: https://patch.msgid.link/20260604121946.942164-1-amorenoz@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2fa49b2715e1bad12ce3b0fa64e234d9582c8193 Author: Kyle Zeng Date: Fri Jun 5 00:34:48 2026 -0700 ipv6: sit: reload inner IPv6 header after GSO offloads [ Upstream commit f0e42f0c4337b1f220de1ddd63f47197c7dee4de ] ipip6_tunnel_xmit() caches the inner IPv6 header pointer at function entry and continues using it after iptunnel_handle_offloads(). For GSO skbs, iptunnel_handle_offloads() calls skb_header_unclone(). When the skb header is cloned, skb_header_unclone() can call pskb_expand_head(), which may move the skb head. The pskb_expand_head() contract requires pointers into the skb header to be reloaded after the call. If the later skb_realloc_headroom() branch is not taken, SIT uses the stale iph6 pointer to read the inner hop limit and DS field. That can read from a freed skb head after the old head's remaining clone is released. Reload iph6 after the offload helper succeeds and before subsequent reads from the inner IPv6 header. Keep the existing reload after skb_realloc_headroom(), since that branch can also replace the skb. Fixes: 14909664e4e1 ("sit: Setup and TX path for sit/UDP foo-over-udp encapsulation") Signed-off-by: Kyle Zeng Reviewed-by: Eric Dumazet Reported-by: syzbot+6eb9ca986d80f6f88cf9@syzkaller.appspotmail.com Link: https://patch.msgid.link/20260605073448.6524-1-kylebot@openai.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 289c06418ed97f4d27faf7aee09044539c18509f Author: Fushuai Wang Date: Fri Jun 5 18:21:12 2026 +0800 net/mlx5: Use effective affinity mask for IRQ selection [ Upstream commit a7767290e77ca2e926b49f8bfa29daa12262c612 ] When a sf is created after a CPU has been taken offline, the IRQ pool may contain IRQs with affinity masks that include the offline CPU. Since only online CPUs should be considered for IRQ placement, cpumask_subset() check would fail because the iter_mask contains offline CPUs that are not present in req_mask, causing sf creation to fail. This is an example: 1. When mlx5 driver loads, it initializes the IRQ pools. For sf_ctrl_pool with ≤64 sf: - xa_num_irqs = {N, N} (There is only one slot) 2. When the first SF is created: - The ctrl IRQ is allocated with mask=cpu_online_mask={0-191} 2. We take CPU 20 offline 3. Existing ctl irq still have mask={0-191} 4. Create a new SF: - req_mask={0-19,21-191} - iter_mask={0-191} - {0-191} is NOT a subset of {0-19,21-191} - least_loaded_irq=NULL 5. Try to allocate a new irq via irq_pool_request_irq() 6. xa_alloc() fails because the pool is full(There is only one slot) 7. sf creation fails with error Use irq_get_effective_affinity_mask() instead, which returns the IRQ's actual effective affinity that already excludes offline CPUs. Fixes: 061f5b23588a ("net/mlx5: SF, Use all available cpu for setting cpu affinity") Suggested-by: Shay Drory Signed-off-by: Fushuai Wang Reviewed-by: Shay Drory Reviewed-by: Tariq Toukan Link: https://patch.msgid.link/20260605102112.91772-1-fushuai.wang@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2789b74ae1f4b68333c9d5eec2f3354d07b16e61 Author: Dragos Tatulea Date: Thu Jun 4 16:54:46 2026 +0300 net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure [ Upstream commit b69004f5a6ad32da84d8aa5b23b9c0caafe6252e ] In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries. With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind: DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180 ... DMA-API: Mapped at: debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core] Add the missing unmap + xdp_return_frame, matching the cleanup already done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed. Fixes: 84a0a2310d6d ("net/mlx5e: XDP_TX from UMEM support") Signed-off-by: Dragos Tatulea Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260604135446.456119-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0f807764bb122fd63aa45f4229cb1ef2679fbd40 Author: Dragos Tatulea Date: Thu Jun 4 16:58:49 2026 +0300 net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list [ Upstream commit 894e036a24a26a6dd7b17d8d3fb5c53ab48a6074 ] mlx5_query_nic_vport_mac_list() sizes its firmware command buffer using the PF's log_max_current_uc/mc_list capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer: BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385 CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] Call Trace: dump_stack_lvl+0x69/0xa0 print_report+0x176/0x4e4 kasan_report+0xc8/0x100 mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core] esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core] esw_vport_change_handler+0x6a/0x90 [mlx5_core] process_one_work+0x87f/0x15e0 worker_thread+0x62b/0x1020 kthread+0x375/0x490 ret_from_fork+0x4dc/0x810 ret_from_fork_asm+0x11/0x20 Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max. Fixes: e16aea2744ab ("net/mlx5: Introduce access functions to modify/query vport mac lists") Signed-off-by: Dragos Tatulea Reviewed-by: Carolina Jubran Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260604135849.458060-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ab269990ed58143a92a263be1bee626d82ac03da Author: Mingyu Wang <25181214217@stu.xidian.edu.cn> Date: Thu Jun 4 14:48:01 2026 +0800 net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove [ Upstream commit a2171131ecda1ed61a594a1eb715e75fdad0fef5 ] In qrtr_port_remove(), the socket reference count is decremented via __sock_put() before the port is removed from the qrtr_ports XArray and before the RCU grace period elapses. This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtr_reset_ports() or qrtr_port_lookup()) can obtain a pointer to the socket from the XArray, and attempt to call sock_hold() on a socket whose reference count has already dropped to zero. This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free: refcount_t: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drm_shmem_helper ... Call Trace: qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c:3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c:1283 ... Fix this by deferring the reference count decrement until after the xa_erase() and the synchronize_rcu() complete. (Note: The v1 of this patch incorrectly replaced __sock_put() with sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the __sock_put() is kept, but only repositioned to close the RCU race.) Fixes: bdabad3e363d ("net: Add Qualcomm IPC router") Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260604064801.1180388-1-w15303746062@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3a254779c169954fe23328a1db51f67be374f913 Author: Maxime Chevallier Date: Thu Jun 4 11:28:15 2026 +0200 net: phy: clean the sfp upstream if phy probing fails [ Upstream commit 48774e87bbaa0056819d4b52301e4692e50e3252 ] Sashiko reported that we don't call sfp_bus_del_upstream() in the probe failure path, so let's add it, otherwise the sfp-bus is left with a dangling 'upstream' field, that may be used later on during SFP events. This issue existed before the generic phylib sfp support, back when drivers were calling phy_sfp_probe themselves. Reviewed-by: Nicolai Buchwitz Fixes: 298e54fa810e ("net: phy: add core phylib sfp support") Signed-off-by: Maxime Chevallier Link: https://patch.msgid.link/20260604092819.723505-2-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c299321bc6232770ce378d6fa6bc46004d2d7fdb Author: Jakub Kicinski Date: Fri Jun 5 18:21:24 2026 -0700 netdev: fix double-free in netdev_nl_bind_rx_doit() [ Upstream commit c849de7d8757a7af801fc4a4058f71d481d367f2 ] Sashiko flags that genlmsg_reply() always consumes the skb. The error path calls nlmsg_free(rsp) so we can't jump directly to it. Let's not unbind, just propagate the error to the user. This is the typical way of handling genlmsg_reply() failures. They shouldn't happen unless user does something silly like calling the kernel with an already-full rcvbuf. Reported-by: Sashiko Fixes: 170aafe35cb9 ("netdev: support binding dma-buf to netdevice") Reviewed-by: Bobby Eshleman Acked-by: Daniel Borkmann Reviewed-by: Nikolay Aleksandrov Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c09c2e236eef6f59e105f38a30f5439e6ccbcad7 Author: Rosen Penev Date: Wed Jun 3 15:12:17 2026 -0700 net: ibm: emac: Fix use-after-free during device removal [ Upstream commit a0130d682222ae21afc395aead7cd2d87e1a8358 ] The driver was using devm_register_netdev() which causes unregister_netdev() to be deferred until the devres cleanup phase, which runs after emac_remove() returns. This creates a use-after-free window where: 1. emac_remove() is called, which tears down hardware (cancels work, detaches modules, unregisters from MAL) 2. emac_remove() returns 3. devres cleanup runs and finally calls unregister_netdev() During step 3, the network stack might still process packets, triggering emac_irq(), emac_poll(), or other handlers that access now-freed hardware resources (dev->emacp, dev->mal, etc.). Fix this by replacing devm_register_netdev() with manual register_netdev() and calling unregister_netdev() at the beginning of emac_remove(), before any hardware teardown. This ensures the network device is fully stopped and unregistered before hardware resources are released. The change is safe because: - dev->ndev is assigned very early in probe (before any error paths that could bypass emac_remove) - platform_set_drvdata() is only called after successful registration, so emac_remove() only runs for fully registered devices - unregister_netdev() is idempotent and safe to call on any registered device Fixes: a4dd8535a527 ("net: ibm: emac: use devm for register_netdev") Signed-off-by: Rosen Penev Reviewed-by: Jacob Keller Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8b054123109170f164984904a98b2db32046d891 Author: Yao Sang Date: Wed Jun 3 14:10:44 2026 +0800 net/mlx4: avoid GCC 10 __bad_copy_from() false positive [ Upstream commit 2365343f4aad3e1b1e7a2e87e98cf66d5e590589 ] mlx4_init_user_cqes() fills a scratch buffer with the CQE initialization pattern and then copies from that buffer to userspace. In the single-copy path, the copy length is array_size(entries, cqe_size), but the scratch buffer is allocated with PAGE_SIZE. GCC 10 does not carry the branch invariant strongly enough through the object size checks and falsely triggers __bad_copy_from(). Size the scratch buffer to the actual copy length for the active path, keep array_size() for the single-copy case, and retain a WARN_ON_ONCE() guard for the PAGE_SIZE invariant before allocating the buffer. Fixes: f69bf5dee7ef ("net/mlx4: Use array_size() helper in copy_to_user()") Signed-off-by: Yao Sang Reviewed-by: Jacob Keller Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0cde3a004119db637b401c54e77536e4145fc0b4 Author: HanQuan Date: Thu Jun 4 14:46:25 2026 +0000 net: add pskb_may_pull() to skb_gro_receive_list() [ Upstream commit f2bb3434544454099a5b6dec213567267b05d79d ] skb_gro_receive_list() calls skb_pull(skb, skb_gro_offset(skb)) without first ensuring the data is in the linear area via pskb_may_pull(). When the skb arrives via napi_gro_frags(), skb_headlen can be 0 (all data in page fragments) while skb_gro_offset is non-zero (after IP+TCP header parsing). The skb_pull() then decrements skb->len by skb_gro_offset but skb->data_len stays unchanged, hitting BUG_ON(skb->len < skb->data_len) in __skb_pull(). The UDP fraglist GRO path already contains this guard at udp_offload.c:749. Adding it to skb_gro_receive_list() itself provides centralized protection for all callers (TCP, UDP, and any future protocols), and ensures the precondition of skb_pull() is satisfied before it is called. On pskb_may_pull() failure, set NAPI_GRO_CB(skb)->flush = 1 so the skb is not held as a new GRO head and is instead delivered through the normal receive path, matching the UDP handling. Fixes: 8d95dc474f85 ("net: add code for TCP fraglist GRO") Reported-by: HanQuan Reported-by: MingXuan Signed-off-by: HanQuan Reviewed-by: Eric Dumazet Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ede69b8f6670600e534591664584f810d7c385f9 Author: Eric Dumazet Date: Fri Jun 5 11:21:34 2026 +0000 tcp: restrict SO_ATTACH_FILTER to priv users [ Upstream commit 5d39580f68e6ddeedd15e587282207489dfb3da2 ] This patch restricts the use of SO_ATTACH_FILTER (cBPF) on TCP sockets to users with CAP_NET_ADMIN capability. This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reported-by: Tamir Shahar Reported-by: Amit Klein Cc: Willem de Bruijn Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Andrii Nakryiko Cc: Martin KaFai Lau Cc: Eduard Zingerman Cc: Kumar Kartikeya Dwivedi Cc: Song Liu Cc: Yonghong Song Cc: Jiri Olsa Cc: John Fastabend Cc: Stanislav Fomichev Acked-by: Daniel Borkmann Reviewed-by: Willem de Bruijn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 12e579b889624ec54a201d98fdff975de556c731 Author: Richard Fitzgerald Date: Thu Jun 4 11:12:44 2026 +0100 ASoC: wm_adsp: Fix NULL dereference when removing firmware controls [ Upstream commit 7d3fb78b550301e43fdc60312aed733069694426 ] In wm_adsp_control_remove() check that the priv pointer is not NULL before attempting to cleanup what it points to. When cs_dsp creates a control it calls wm_adsp_control_add_cb() so that wm_adsp can create its own private control data. There are two cases where private data is not created: 1. The control is a SYSTEM control, so an ALSA control is not created. 2. The codec driver has registered a control_add() callback that hides the control, so wm_adsp_control_add() is not called. When cs_dsp_remove destroys its control list it calls wm_adsp_control_remove() for each control. But wm_adsp_control_remove() was attempting to cleanup the private data pointed to by cs_ctl->priv without checking the pointer for NULL. Signed-off-by: Richard Fitzgerald Fixes: 0700bc2fb94c ("ASoC: wm_adsp: Separate generic cs_dsp_coeff_ctl handling") Link: https://patch.msgid.link/20260604101244.1402862-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6136c1474db88272231573e222896e1998d34662 Author: Yun Zhou Date: Mon Jun 8 16:43:34 2026 +0800 gpio: mvebu: fix NULL pointer dereference in suspend/resume [ Upstream commit b9ad50d7505ebd48282ec3630258dc820fc85c81 ] mvebu_pwm_suspend() and mvebu_pwm_resume() are called for all GPIO banks during suspend/resume, but not all banks have PWM functionality. GPIO banks without PWM have mvchip->mvpwm set to NULL. Calling mvebu_pwm_suspend() with mvpwm == NULL causes a NULL pointer dereference when it tries to access mvpwm->blink_select. Unable to handle kernel NULL pointer dereference at virtual address 00000020 when write [00000020] *pgd=00000000 Internal error: Oops: 815 [#1] PREEMPT ARM Modules linked in: CPU: 0 UID: 0 PID: 406 Comm: sh Not tainted 6.12.74-rt12-yocto-standard-g4e96f98fb7db-dirty #353 Hardware name: Marvell Armada 370/XP (Device Tree) PC is at regmap_mmio_read+0x38/0x54 LR is at regmap_mmio_read+0x38/0x54 pc : [] lr : [] psr: 200f0013 sp : f0c11d10 ip : 00000000 fp : c100d2f0 r10: c14fb854 r9 : 00000000 r8 : 00000000 r7 : c1799c00 r6 : 00000020 r5 : 00000020 r4 : c179c7c0 r3 : f0a231a0 r2 : 00000020 r1 : 00000020 r0 : 00000000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 135ec059 DAC: 00000051 Call trace: regmap_mmio_read from _regmap_bus_reg_read+0x78/0xac _regmap_bus_reg_read from _regmap_read+0x60/0x154 _regmap_read from regmap_read+0x3c/0x60 regmap_read from mvebu_gpio_suspend+0xa4/0x14c mvebu_gpio_suspend from dpm_run_callback+0x54/0x180 dpm_run_callback from device_suspend+0x124/0x630 device_suspend from dpm_suspend+0x124/0x270 dpm_suspend from dpm_suspend_start+0x64/0x6c dpm_suspend_start from suspend_devices_and_enter+0x140/0x8e8 suspend_devices_and_enter from pm_suspend+0x2fc/0x308 pm_suspend from state_store+0x6c/0xc8 state_store from kernfs_fop_write_iter+0x10c/0x1f8 kernfs_fop_write_iter from vfs_write+0x270/0x468 vfs_write from ksys_write+0x70/0xf0 ksys_write from ret_fast_syscall+0x0/0x54 Add a NULL check for mvchip->mvpwm before calling the PWM suspend/resume functions. Fixes: 757642f9a584 ("gpio: mvebu: Add limited PWM support") Signed-off-by: Yun Zhou Link: https://patch.msgid.link/20260608084334.2960803-1-yun.zhou@windriver.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 0c4bb32ad7fdc2dc6a8050f41eb04d4bda56b6c8 Author: Chenguang Zhao Date: Wed Jun 3 09:13:53 2026 +0800 netlabel: validate unlabeled address and mask attribute lengths [ Upstream commit 9772589b57e44aedc240211c5c3f7a684a034d3a ] netlbl_unlabel_addrinfo_get() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct in_addr or struct in6_addr. NLA_BINARY policy lengths are maximum lengths by default, so use NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection. Fixes: 8cc44579d1bd ("NetLabel: Introduce static network labels for unlabeled connections") Signed-off-by: Chenguang Zhao Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 972c106f5d012e66b065c5faba76fbbba68ee206 Author: Vikas Gupta Date: Thu Jun 4 22:07:09 2026 +0530 bnge: fix context mem iteration [ Upstream commit 3847d94783c0b893c27ff0b26a3325796d9444c6 ] The firmware advertises context memory (backing store) types through a linked list, with BNGE_CTX_INV serving as the end-of-list sentinel. However, the driver incorrectly assumes that the list is strictly ordered and prematurely terminates traversal when it encounters an unrecognized type (>=BNGE_CTX_V2_MAX). As a result, any valid context types that appear later in the chain are silently skipped, leading to incomplete memory configuration and eventual driver load failure. Fix this by traversing the entire list until the BNGE_CTX_INV sentinel is reached, while safely ignoring only those context types that fall outside the supported range. Fixes: 29c5b358f385 ("bng_en: Add backing store support") Signed-off-by: Vikas Gupta Reviewed-by: Dharmender Garg Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6b8baf42b1b7fa8506d738c9d979153dfebdcd08 Author: Arthur Kiyanovski Date: Thu Jun 4 08:07:04 2026 +0000 net: ena: PHC: Add missing barrier [ Upstream commit 954981dbbfbd78f21d2fbac1ac0742dbf38b4e69 ] Add dma_rmb() barrier after req_id completion check in ena_com_phc_get_timestamp(). On weakly-ordered architectures, payload fields may be read before req_id is observed as updated. Fixes: e0ea34158ee8 ("net: ena: Add PHC support in the ENA driver") Closes: https://sashiko.dev/#/patchset/20260430032507.11586-1-akiyano%40amazon.com Signed-off-by: Arthur Kiyanovski Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 640edc281d2f3b25d9e7bd5de1363806faab1fd1 Author: Alok Tiwari Date: Tue Jun 2 15:55:11 2026 -0700 idpf: fix mailbox capability for set device clock time [ Upstream commit 85b0cbc1f38bc1e38956a9e6d7b04d309b435697 ] The current code incorrectly uses VIRTCHNL2_CAP_PTP_SET_DEVICE_CLK_TIME for both direct and mailbox capabilities, causing mailbox-only support to be ignored and potentially reporting IDPF_PTP_NONE. Fixes: d5dba8f7206da ("idpf: add PTP clock configuration") Signed-off-by: Alok Tiwari Tested-by: Samuel Salin Reviewed-by: Aleksandr Loktionov Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260602225513.393338-4-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6bdbe6f43ecf34d5b6a7e86bb52124bb46fb5ce0 Author: Petr Oros Date: Tue Jun 2 15:55:10 2026 -0700 ice: fix missing priority callbacks for U.FL DPLL pins [ Upstream commit f1fa677e428e8873486938086bd934dc18169b47 ] The U.FL2 input pin advertises DPLL_PIN_CAPABILITIES_PRIORITY_CAN_CHANGE in its capability mask, but ice_dpll_pin_ufl_ops does not provide .prio_get and .prio_set callbacks. As a result the DPLL subsystem cannot report or accept priority for U.FL pins: pin-get omits the prio field on U.FL2 and pin-set with prio is rejected as invalid, even though the capability is present. This prevents user space from using priority to select or disable U.FL2 as a DPLL input source. Reproducer with iproute2 (dpll command): # dpll pin show board-label U.FL2 pin id 16: module-name ice board-label U.FL2 type ext capabilities priority-can-change|state-can-change parent-device: id 0 direction input state selectable phase-offset 0 /* note: no "prio" between "direction" and "state", even though priority-can-change is advertised */ # dpll pin set id 16 parent-device 0 prio 5 RTNETLINK answers: Operation not supported After the fix the prio field is reported by pin show and pin set with prio is accepted on U.FL2. Add the missing .prio_get and .prio_set callbacks to ice_dpll_pin_ufl_ops, reusing ice_dpll_sw_input_prio_{get,set}. The same ops struct is shared by U.FL1 and U.FL2: U.FL2 (input) delegates to the backing hardware input pin, while U.FL1 (output) does not advertise DPLL_PIN_CAPABILITIES_PRIORITY_CAN_CHANGE so the dpll core capability gate never invokes prio_set for it, and prio_get reports the OUTPUT sentinel (ICE_DPLL_PIN_PRIO_OUTPUT) on the output side exactly like the SMA path does today. Fixes: 2dd5d03c77e2 ("ice: redesign dpll sma/u.fl pins control") Reviewed-by: Aleksandr Loktionov Reviewed-by: Paul Menzel Signed-off-by: Petr Oros Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260602225513.393338-3-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b5316e2b8614a87d8736941972441cb47bfd4491 Author: Sanghyun Park Date: Tue Jun 2 18:49:05 2026 +0900 xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx() [ Upstream commit 7f2d76c9c03257c0782afef9d95321fa04096f60 ] Fix the race by pruning the bin while still holding xfrm_policy_lock, before dropping it. Use __xfrm_policy_inexact_prune_bin() directly since the lock is already held. The wrapper xfrm_policy_inexact_prune_bin() becomes unused and is removed. Race: CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO) ========================== ========================== xfrm_policy_bysel_ctx(): spin_lock_bh(xfrm_policy_lock) bin = xfrm_policy_inexact_lookup() __xfrm_policy_unlink(pol) spin_unlock_bh(xfrm_policy_lock) xfrm_policy_kill(ret) // wide window, lock not held xfrm_hash_rebuild(): spin_lock_bh(xfrm_policy_lock) __xfrm_policy_inexact_flush(): kfree_rcu(bin) // bin freed spin_unlock_bh(xfrm_policy_lock) xfrm_policy_inexact_prune_bin(bin) // UAF: bin is freed Fixes: 6be3b0db6db8 ("xfrm: policy: add inexact policy search tree infrastructure") Signed-off-by: Sanghyun Park Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 5513dcb378f90d2610b7fa948fa7699b7e62a0dd Author: Li RongQing Date: Wed Jun 3 20:37:08 2026 +0800 dma-debug: fix physical address retrieval in debug_dma_sync_sg_for_device [ Upstream commit 9bfaa86b405381326c971984fd6da184c289713f ] In debug_dma_sync_sg_for_device(), when iterating over a scatterlist, the debug entry population mistakenly uses the head of the scatterlist 'sg' to fetch the physical address via sg_phys(), instead of using the current iterator variable 's'. This causes dma-debug to track the physical address of the very first scatterlist entry for all subsequent entries in the list. Fix this by passing the correct loop iterator 's' to sg_phys() Fixes: 9d4f645a1fd49ee ("dma-debug: store a phys_addr_t in struct dma_debug_entry") Signed-off-by: Li RongQing Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20260603123708.1665-1-lirongqing@baidu.com Signed-off-by: Sasha Levin commit 4ee4d628c4d938c243e8a299ae26be6fccdb2e7f Author: Li RongQing Date: Wed Jun 3 09:37:23 2026 +0800 dma-mapping: direct: fix missing mapping for THRU_HOST_BRIDGE segments [ Upstream commit 560000d619ef162568746ce287f0c725e24ea967 ] In dma_direct_map_sg(), the case PCI_P2PDMA_MAP_THRU_HOST_BRIDGE incorrectly used 'break' instead of falling through to MAP_NONE. As a result, segments traversing the host bridge skipped the required dma_direct_map_phys() call entirely, leaving sg->dma_address uninitialized and leading to DMA failures. Fix this by using 'fallthrough;'. Fixes: a25e7962db0d79 ("PCI/P2PDMA: Refactor the p2pdma mapping helpers") Reviewed-by: Logan Gunthorpe Signed-off-by: Li RongQing Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20260603013723.2439-1-lirongqing@baidu.com Signed-off-by: Sasha Levin commit 8d9a79fbf5172d9c4c0146057af2360913265a11 Author: Zhenghang Xiao Date: Tue May 26 18:53:28 2026 +0800 xfrm: iptfs: fix use-after-free on first_skb in __input_process_payload [ Upstream commit eb48730bb827d1550401a5d391903f9d90b493c8 ] __input_process_payload() stores first_skb into xtfs->ra_newskb under drop_lock when starting partial reassembly, then unlocks and breaks out of the processing loop. The post-loop check reads xtfs->ra_newskb without the lock to decide whether first_skb is still owned: if (first_skb && first_iplen && !defer && first_skb != xtfs->ra_newskb) Between spin_unlock and this read, a concurrent CPU running iptfs_reassem_cont() (or the drop_timer hrtimer) can complete reassembly, NULL xtfs->ra_newskb, and free the skb. The check then evaluates first_skb != NULL as true, and pskb_trim/ip_summed/consume_skb operate on the freed skb — a use-after-free in skbuff_head_cache. Replace the unlocked read with a local bool that records whether first_skb was handed to the reassembly state in the current call. The flag is set after the existing spin_unlock, before the break, using the pointer equality that is stable at that point (first_skb == skb iff first_skb was stored in ra_newskb). Fixes: 3f3339885fb3 ("xfrm: iptfs: add reusing received skb for the tunnel egress packet") Signed-off-by: Zhenghang Xiao Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit e27c17346628cb56843a83f93ac63c314c00f388 Author: Weiming Shi Date: Thu Jun 11 06:21:06 2026 -0700 tap: free page on error paths in tap_get_user_xdp() [ Upstream commit 3bcf7aec6a9d16438f2cec29f5d7c8d5b8edf9b2 ] tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL, and returns -ENOMEM when build_skb() fails. Both paths jump to the err label without freeing the page that vhost_net_build_xdp() allocated for the frame. tap_sendmsg() discards the per-buffer return value and always returns 0, so vhost_tx_batch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk. Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tun_xdp_one(). Fixes: 0efac27791ee ("tap: accept an array of XDP buffs through sendmsg()") Fixes: ed7f2afdd0e0 ("tap: add missing verification for short frame") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Reviewed-by: Dongli Zhang Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260521163230.1478627-2-bestswngs@gmail.com Signed-off-by: Jakub Kicinski (cherry picked from commit 3bcf7aec6a9d16438f2cec29f5d7c8d5b8edf9b2) Signed-off-by: Harshit Mogalapalli Signed-off-by: Sasha Levin commit 0c03692e2372c2fc848d8cfd18b846ca03c7e08c Author: Gabriele Monaco Date: Thu May 14 17:20:48 2026 +0200 verification/rvgen: Fix ltl2k writing True as a literal [ Upstream commit df996599cc69a9b74ff437c67751cf8a61f62e39 ] The rvgen parser for LTL stores literal true values in the python representation (capitalised True), this doesn't build in C. The Literal class should already handle this case but ASTNode skips its strigification method and converts the value (true/false) directly. Fix by delegating ASTNode stringification to the Literal and Variable classes instead of bypassing them. Fixes: 97ffa4ce6ab32 ("verification/rvgen: Add support for linear temporal logic") Reviewed-by: Nam Cao Link: https://lore.kernel.org/r/20260514152055.229162-8-gmonaco@redhat.com Signed-off-by: Gabriele Monaco Signed-off-by: Sasha Levin commit 43ad0a0da486b989dedf21183dfad386ec8ddabc Author: Gabriele Monaco Date: Thu May 14 17:20:47 2026 +0200 verification/rvgen: Fix options shared among commands [ Upstream commit 5f845ad706c0b394ae274e9a930044f78bef782e ] After rvgen was refactored to use subparsers, the common options (-a and -D) were left in the main parser. This meant that they needed to be called /before/ the subcommand and using them without subcommand was allowed. This is not the original intent. rvgen -D "some description" container -n name Define the options as parent in the subparsers to allow them to be used from both subcommands together with other options. rvgen container -n name -D "some description" Fixes: 5270a0e3041c ("verification/dot2k: Replace is_container() hack with subparsers") Reviewed-by: Nam Cao Link: https://lore.kernel.org/r/20260514152055.229162-7-gmonaco@redhat.com Signed-off-by: Gabriele Monaco Signed-off-by: Sasha Levin commit 73590b4cfd056b3b8b506eb98562a3c90f953c79 Author: Gabriele Monaco Date: Thu May 14 17:20:45 2026 +0200 tools/rv: Fix cleanup after failed trace setup [ Upstream commit 33ec2269a4155cad7e9e42c92327dcaa9aee59a7 ] Currently if ikm_setup_trace_instance() fails, the tool returns without any cleanup, if rv was called with both -t and -r, this means the reactor is not going to be cleared. Jump to the cleanup label to restore the reactor if necessary. Fixes: 6d60f89691fc9 ("tools/rv: Add in-kernel monitor interface") Reviewed-by: Nam Cao Link: https://lore.kernel.org/r/20260514152055.229162-5-gmonaco@redhat.com Signed-off-by: Gabriele Monaco Signed-off-by: Sasha Levin commit fd1923910bbfe7f1a471cc04eacbc61eba361c1f Author: Gabriele Monaco Date: Thu May 14 17:20:43 2026 +0200 tools/rv: Fix substring match when listing container monitors [ Upstream commit ba0247c5aa3fcb2890a92a97a88c70fe5ce704a6 ] When listing monitors within a specific container (rv list ), the tool incorrectly matched monitors if the requested container name was only a prefix of the actual container (e.g., 'rv list sche' would incorrectly list monitors from 'sched:'). Fix this by ensuring the container name is an exact match and is immediately followed by the ':' separator. Fixes: eba321a16fc6 ("tools/rv: Add support for nested monitors") Reviewed-by: Nam Cao Link: https://lore.kernel.org/r/20260514152055.229162-3-gmonaco@redhat.com Signed-off-by: Gabriele Monaco Signed-off-by: Sasha Levin commit 2122d68f0864b68f4ccca0f58b7a7bb8910d823b Author: Gabriele Monaco Date: Thu May 14 17:20:42 2026 +0200 tools/rv: Fix substring match bug in monitor name search [ Upstream commit a963fbf3166f2e178ac38b6c3c186a0c98092fb9 ] __ikm_find_monitor_name() relies on strstr() to find a monitor by name, which fails if the target monitor is a substring of a previously listed monitor. Fix it by tokenizing the available_monitors file and matching full tokens instead. Fixes: eba321a16fc6 ("tools/rv: Add support for nested monitors") Reviewed-by: Nam Cao Link: https://lore.kernel.org/r/20260514152055.229162-2-gmonaco@redhat.com Signed-off-by: Gabriele Monaco Signed-off-by: Sasha Levin commit 618193aba6fe2530d19b9ffaf327997362736dec Author: Gabriele Monaco Date: Thu Jun 4 14:09:45 2026 +0200 tools/rv: Ensure monitor name and desc are NUL-terminated [ Upstream commit 08904765bb941f98306ae6841c33cfd299343faf ] ikm_fill_monitor_definition() copies monitor name and description with strncpy(), but does not guarantee NUL termination when source strings are equal to or longer than the destination buffers. Clamp copies to sizeof(dst) - 1 and explicitly append '\0' for both fields to keep them safe for later string operations. Suggested-by: unknownbbqrx Fixes: 6d60f89691fc9 ("tools/rv: Add in-kernel monitor interface") Link: https://lore.kernel.org/r/20260604120946.90302-2-gmonaco@redhat.com Signed-off-by: Gabriele Monaco Signed-off-by: Sasha Levin commit 65046b0d853da5be1dc9075f809ef454dc1b1ca3 Author: Zhan Xusheng Date: Tue May 26 10:21:31 2026 +0800 cpufreq/amd-pstate: drop stale @epp_cached kdoc [ Upstream commit 3cd07ee35a66038fd1a643632bfc057645e07c9a ] Commit 4e16c1175238 ("cpufreq/amd-pstate: Stop caching EPP") removed the epp_cached field from struct amd_cpudata in favour of always reading from cppc_req_cached, but the kdoc above the struct still documents @epp_cached. Drop the now-stale @epp_cached entry. Reviewed-by: Mario Limonciello (AMD) Fixes: 4e16c1175238 ("cpufreq/amd-pstate: Stop caching EPP") Signed-off-by: Zhan Xusheng Link: https://lore.kernel.org/r/20260526022131.1302373-1-zhanxusheng@xiaomi.com Signed-off-by: Mario Limonciello (AMD) Signed-off-by: Sasha Levin commit 63a9f6012f453578898c9fcc13c8452a8651104e Author: Johan Hovold Date: Thu Jun 11 14:37:19 2026 +0800 spi: cadence-quadspi: fix unclocked access on unbind [ Upstream commit 233db2cb14db8b1935dda52a6affd97276462b82 ] Make sure that the controller is runtime resumed before disabling it during driver unbind to avoid an unclocked register access. This issue was flagged by Sashiko when reviewing a controller deregistration fix. Fixes: 0578a6dbfe75 ("spi: spi-cadence-quadspi: add runtime pm support") Cc: stable@vger.kernel.org # 6.7 Cc: Dhruva Gole Link: https://sashiko.dev/#/patchset/20260414134319.978196-1-johan%40kernel.org?part=2 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260421125354.1534871-4-johan@kernel.org Signed-off-by: Mark Brown [ Context adaptation performed. ] Signed-off-by: Robert Garcia Signed-off-by: Sasha Levin commit 6671a46144f880c5a167930ebb14c12f3d059fe9 Author: Kyle Zeng Date: Fri Jun 5 01:02:04 2026 -0700 ALSA: seq: dummy: fix UMP event stack overread [ Upstream commit 2b5ff4db5d7aa5b981d966df02e687f79ad7b311 ] The dummy sequencer port forwards events by copying an incoming struct snd_seq_event into a stack temporary, rewriting source and destination, and dispatching the temporary to subscribers. That legacy event storage is smaller than struct snd_seq_ump_event. When a UMP event reaches the dummy client, the copy leaves the UMP flag set but only provides legacy-sized stack storage. The subscriber delivery path then uses snd_seq_event_packet_size() and copies a UMP-sized packet from that stack object, reading past the end of the temporary. Use the existing union __snd_seq_event storage and copy the packet size reported for the incoming event before rewriting the common routing fields. This preserves the full UMP packet for UMP events while keeping legacy event handling unchanged. Fixes: 32cb23a0f911 ("ALSA: seq: dummy: Allow UMP conversion") Signed-off-by: Kyle Zeng Link: https://patch.msgid.link/20260605080204.32045-1-kylebot@openai.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit cd98837db15f323463b8df07282ac723bd5c3fed Author: Ji'an Zhou Date: Thu Jun 4 14:25:59 2026 +0000 ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams [ Upstream commit 88fe2e3658726cb21ff2dcf9770bf672f9b9d31b ] snd_pcm_drain() uses init_waitqueue_entry which does not clear entry.prev/next, and add_wait_queue with a conditional remove_wait_queue that is skipped when to_check is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, add_wait_queue adds the entry to a new queue while still linked on the old one, corrupting both lists. A subsequent wake_up dereferences NULL at the func pointer (mapped from the spinlock at offset 0 of the misinterpreted wait_queue_head_t), causing a kernel panic. Replace init_waitqueue_entry/add_wait_queue/conditional remove_wait_queue with init_wait_entry/prepare_to_wait/ finish_wait. init_wait_entry clears prev/next via INIT_LIST_HEAD on each iteration and sets autoremove_wake_function which auto-removes the entry on wake-up. finish_wait safely handles both the already-removed and still-queued cases. Fixes: 9b1dbd69ba6f ("ALSA: pcm: fix use-after-free on linked stream runtime in snd_pcm_drain") Signed-off-by: Ji'an Zhou Link: https://patch.msgid.link/20260604142559.3840881-1-eilaimemedsnaimel@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 6b71956c25f94b67fd50f3487d50c031da7329f5 Author: Naveen Kumar Chaudhary Date: Tue Jun 2 23:37:37 2026 +0530 time: Fix off-by-one in settimeofday() usec validation [ Upstream commit ce4abda5e12622f33450159e76c8f56d28d7f03d ] The validation check uses '>' instead of '>=' when comparing tv_usec against USEC_PER_SEC, allowing the value 1000000 through. After conversion to nanoseconds (*= 1000), this produces tv_nsec == NSEC_PER_SEC, violating the timespec invariant that tv_nsec must be less than NSEC_PER_SEC. Use '>=' to reject tv_usec values that are not in the valid range of 0 to 999999. Fixes: 5e0fb1b57bea ("y2038: time: avoid timespec usage in settimeofday()") Signed-off-by: Naveen Kumar Chaudhary Signed-off-by: Thomas Gleixner Acked-by: John Stultz Link: https://patch.msgid.link/4rikk44zew3s6577dugmx4jyblz7o5c57niuap6ct3td5yfm6w@gh7pcumg7qor Signed-off-by: Sasha Levin commit ed0ad65741266176433f23fd6ef27c173f97befc Author: Dexuan Cui Date: Wed May 27 12:21:01 2026 -0700 hyperv: Clean up and fix the guest ID comment in hvgdk.h [ Upstream commit 83eb00f31eb1b10735d48e469df72cc2b0e06f6d ] Change the "64 bit" to "64-bit", and the "Os" to "OS". Remove the obsolete paragraph since the guideline has been published in the Hypervisor Top Level Functional Specification for many years. The "OS Type" is 0x1 for Linux, not 0x100. No functional change. Fixes: 83ba0c4f3f31 ("Drivers: hv: Cleanup the guest ID computation") Signed-off-by: Dexuan Cui Reviewed-by: Hamza Mahfooz Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 8c046f36222c6ce1e0daef2c45c891c72602f8a1 Author: Aleksandr Nogikh Date: Thu May 21 16:22:40 2026 +0200 signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads() [ Upstream commit 90918794a4e2c3b440f8fcf3847765a8b1d81b25 ] When a multi-threaded process receives a stop signal (e.g., SIGSTOP), do_signal_stop() sets JOBCTL_STOP_PENDING and JOBCTL_STOP_CONSUME on all threads and sets signal->group_stop_count to the number of threads. If one of the threads concurrently calls execve(), de_thread() invokes zap_other_threads() to kill all other threads. zap_other_threads() aborts the pending group stop by resetting signal->group_stop_count to 0 and clears the JOBCTL_PENDING_MASK for all other threads. However, it fails to clear the job control flags for the calling thread. When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTL_STOP_PENDING flag, it calls do_signal_stop(), which invokes task_participate_group_stop(). Since JOBCTL_STOP_CONSUME is still set, it attempts to decrement the already-zero signal->group_stop_count, triggering a warning: sig->group_stop_count == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 task_participate_group_stop+0x215/0x2d0 Call Trace: do_signal_stop+0x3be/0x5c0 kernel/signal.c:2619 get_signal+0xa8c/0x1330 kernel/signal.c:2884 arch_do_signal_or_restart+0xbc/0x840 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x8c/0x4d0 kernel/entry/common.c:98 do_syscall_64+0x33e/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this race condition by clearing the JOBCTL_PENDING_MASK for the calling thread in zap_other_threads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zap_process() and complete_signal(), which correctly clear these flags for all threads including the current one. Fixes: 39efa3ef3a37 ("signal: Use GROUP_STOP_PENDING to stop once for a single group stop") Assisted-by: Gemini:gemini-3.1-pro-preview Gemini:gemini-3-flash-preview syzbot Reported-by: syzbot+b109633ea805cac54a61@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b109633ea805cac54a61 Link: https://syzkaller.appspot.com/ai_job?id=d70208cc-862b-4fe3-bf02-3031e10cd0b3 Signed-off-by: Aleksandr Nogikh Link: https://patch.msgid.link/20260521142240.2973022-1-nogikh@google.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 6dc6e5b5c32e5ddb5660dbce672e37eaf123a68a Author: Geliang Tang Date: Mon Apr 20 17:45:28 2026 +0800 selftests: harness: fix pidfd leak in __wait_for_test [ Upstream commit 0eb307d61317b42b120ab02099b597226318358a ] Fix the pidfd leak in kselftest_harness.h's __wait_for_test() where childfd = syscall(__NR_pidfd_open, t->pid, 0) is never closed. Fixes: 73a3cde97677 ("selftests: harness: Implement test timeouts through pidfd") Signed-off-by: Geliang Tang Link: https://patch.msgid.link/a82e275ccfb2609a1984d90ab559fa3af78f1e81.1776678050.git.tanggeliang@kylinos.cn Reviewed-by: Thomas Weißschuh Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 752e22ecf4dff4acab917290709b8489ccedb752 Author: Michael Kelley Date: Tue Feb 17 10:23:35 2026 -0800 drm/hyperv: During panic do VMBus unload after frame buffer is flushed [ Upstream commit 8b35874f56ded0cc1a90a25b87411249a86246cd ] In a VM, Linux panic information (reason for the panic, stack trace, etc.) may be written to a serial console and/or a virtual frame buffer for a graphics console. The latter may need to be flushed back to the host hypervisor for display. The current Hyper-V DRM driver for the frame buffer does the flushing *after* the VMBus connection has been unloaded, such that panic messages are not displayed on the graphics console. A user with a Hyper-V graphics console is left with just a hung empty screen after a panic. The enhanced control that DRM provides over the panic display in the graphics console is similarly non-functional. Commit 3671f3777758 ("drm/hyperv: Add support for drm_panic") added the Hyper-V DRM driver support to flush the virtual frame buffer. It provided necessary functionality but did not handle the sequencing problem with VMBus unload. Fix the full problem by using VMBus functions to suppress the VMBus unload that is normally done by the VMBus driver in the panic path. Then after the frame buffer has been flushed, do the VMBus unload so that a kdump kernel can start cleanly. As expected, CONFIG_DRM_PANIC must be selected for these changes to have effect. As a side benefit, the enhanced features of the DRM panic path are also functional. Fixes: 3671f3777758 ("drm/hyperv: Add support for drm_panic") Signed-off-by: Michael Kelley Reviewed-by: Jocelyn Falempe Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit b0f77f76231be8674faa6348c636a4cc4a17c953 Author: Michael Kelley Date: Tue Feb 17 10:23:34 2026 -0800 Drivers: hv: vmbus: Provide option to skip VMBus unload on panic [ Upstream commit c5c3ef8d49e15d2fc1cec4ad7c91d81b99977440 ] Currently, VMBus code initiates a VMBus unload in the panic path so that if a kdump kernel is loaded, it can start fresh in setting up its own VMBus connection. However, a driver for the VMBus virtual frame buffer may need to flush dirty portions of the frame buffer back to the Hyper-V host so that panic information is visible in the graphics console. To support such flushing, provide exported functions for the frame buffer driver to specify that the VMBus unload should not be done by the VMBus driver, and to initiate the VMBus unload itself. Together these allow a frame buffer driver to delay the VMBus unload until after it has completed the flush. Ideally, the VMBus driver could use its own panic-path callback to do the unload after all frame buffer drivers have finished. But DRM frame buffer drivers use the kmsg dump callback, and there are no callbacks after that in the panic path. Hence this somewhat messy approach to properly sequencing the frame buffer flush and the VMBus unload. Fixes: 3671f3777758 ("drm/hyperv: Add support for drm_panic") Signed-off-by: Michael Kelley Reviewed-by: Long Li Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 1639df1a9844e9fefbbe099e61942ea8c8792811 Author: Roman Kisel Date: Wed Oct 8 16:34:04 2025 -0700 Drivers: hv: VMBus protocol version 6.0 [ Upstream commit 6802d8af47d1dccd9a74a1f708fb9129244ef843 ] The confidential VMBus is supported starting from the protocol version 6.0 onwards. Provide the required definitions. No functional changes. Signed-off-by: Roman Kisel Reviewed-by: Alok Tiwari Reviewed-by: Michael Kelley Signed-off-by: Wei Liu Stable-dep-of: c5c3ef8d49e1 ("Drivers: hv: vmbus: Provide option to skip VMBus unload on panic") Signed-off-by: Sasha Levin commit a6207349e703cfc04756a4d16dec9176135813a5 Author: Xin Long Date: Wed Jun 3 14:11:44 2026 -0400 sctp: purge outqueue on stale COOKIE-ECHO handling [ Upstream commit e374b22e9b07b72a25909621464ff74096151bfb ] sctp_stream_update() is only invoked when the association is moved into COOKIE_WAIT during association setup/reconfiguration. In this path, the outbound stream scheduler state (stream->out_curr) is expected to be clean, since no user data should have been transmitted yet unless the state machine has already partially progressed. However, a corner case exists in sctp_sf_do_5_2_6_stale(): when a Stale Cookie ERROR is received, the association is rolled back from COOKIE_ECHOED to COOKIE_WAIT. In this scenario, user data may already have been queued and even bundled with the COOKIE-ECHO chunk. During the rollback, sctp_stream_update() frees the old stream table and installs a new one, but it does not invalidate stream->out_curr. As a result, out_curr may still point to a freed sctp_stream_out entry from the previous stream state. Later, SCTP scheduler dequeue paths (FCFS, RR, PRIO, etc.) rely on stream->out_curr->ext, which can lead to use-after-free once the old stream state has been released via sctp_stream_free(). This results in crashes such as (reported by Yuqi): BUG: KASAN: slab-use-after-free in sctp_sched_fcfs_dequeue+0x13a/0x140 Read of size 8 at addr ff1100004d4d3208 by task mini_poc/9312 CPU: 1 UID: 1001 PID: 9312 Comm: mini_poc Not tainted 7.1.0-rc1-00305-gbd3a4795d574 #5 PREEMPT(full) sctp_sched_fcfs_dequeue+0x13a/0x140 sctp_outq_flush+0x1603/0x33e0 sctp_do_sm+0x31c9/0x5d30 sctp_assoc_bh_rcv+0x392/0x6f0 sctp_inq_push+0x1db/0x270 sctp_rcv+0x138d/0x3c10 Fix this by fully purging the association outqueue when handling the Stale Cookie case. This ensures all pending transmit and retransmit state is dropped, and any scheduler cached pointers are invalidated, making it safe to rebuild stream state during COOKIE_WAIT restart. Updating only stream->out_curr would be insufficient, since queued and retransmittable data would still reference the old stream state and trigger later use-after-free in dequeue paths. Fixes: 5bbbbe32a431 ("sctp: introduce stream scheduler foundations") Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Zhengchuan Liang Reported-by: Xin Liu Reported-by: Yuqi Xu Reported-by: Ren Wei Signed-off-by: Xin Long Link: https://patch.msgid.link/94318159b9052907a6cbb7256aee8b5f8dfbfccb.1780510304.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 42446ca0f3570663e87183c065e0b4def52dfba2 Author: Yizhou Zhao Date: Wed Jun 3 14:00:13 2026 +0800 net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr [ Upstream commit 7561c7fbc694308da73300f036719e63e42bf0b4 ] In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration. Fixes: febf018d2234 ("net/802: Implement Multiple Registration Protocol (MRP)") Reported-by: Yizhou Zhao Reported-by: Yuxiang Yang Reported-by: Ao Wang Reported-by: Xuewei Feng Reported-by: Qi Li Reported-by: Ke Xu Signed-off-by: Yizhou Zhao Link: https://patch.msgid.link/20260603060016.21522-1-zhaoyz24@mails.tsinghua.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 285b0842f2e01c3edf805f1fd64da11d9b7f6b4c Author: Eric Dumazet Date: Wed Jun 3 07:29:55 2026 +0000 ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit() [ Upstream commit 3a5f3f7aff18bcc36a57839cf50cf0cc8de707f3 ] The aoe driver (or similar) generates a non-IPv6 packet (e.g., ETH_P_AOE) and queues it for transmission via dev_queue_xmit() on a 6LoWPAN interface (configured by the user or test case). Since the packet is not IPv6, the 6LoWPAN header_ops->create function (lowpan_header_create or header_create) returns early without initializing the lowpan_addr_info structure in the skb headroom. In the transmit function (lowpan_xmit), the driver calls lowpan_header (or setup_header) which unconditionally copies and uses the lowpan_addr_info from the headroom, which contains uninitialized data. Fix this by dropping non IPv6 packets. A similar fix is needed in net/bluetooth/6lowpan.c bt_xmit(). Fixes: 4dc315e267fe ("ieee802154: 6lowpan: move transmit functionality") Reported-by: syzbot+f13c19f75e1097abd116@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a1fd763.278b5b03.2bcf39.0049.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Reviewed-by: Miquel Raynal Link: https://patch.msgid.link/20260603072955.4032221-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3b7ee029b5561b6ff0c2ebe62fc76230698b1431 Author: Andy Roulin Date: Tue Jun 2 11:51:37 2026 -0700 vxlan: vnifilter: fix spurious notification on VNI update [ Upstream commit 84683b5b60c7274e2c8f7f413d39d78d3db5540f ] When a VNI is re-added with the same attributes (e.g. same group or no group), vxlan_vni_update() sends a spurious RTM_NEWTUNNEL notification even though nothing changed. The bug is that 'if (changed)' tests whether the pointer is non-NULL, not the bool value it points to. Since every caller passes a valid pointer, the condition is always true and the notification fires unconditionally. Fix by dereferencing the pointer: 'if (*changed)'. Reproducer: # ip link add vxlan100 type vxlan dstport 4789 local 10.0.0.1 \ nolearning external vnifilter # ip link set vxlan100 up # bridge monitor vni & # bridge vni add vni 1000 dev vxlan100 # bridge vni add vni 1000 dev vxlan100 # spurious notification Fixes: f9c4bb0b245c ("vxlan: vni filtering support on collect metadata device") Signed-off-by: Andy Roulin Reviewed-by: Petr Machata Link: https://patch.msgid.link/20260602185138.253265-3-aroulin@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8e4d1188bad745de496d88a246627b6f232864b5 Author: Andy Roulin Date: Tue Jun 2 11:51:36 2026 -0700 vxlan: vnifilter: send notification on VNI add [ Upstream commit aa6ca1c5c338907817374b59f7551fd855a88754 ] When a new VNI is added to a vxlan device with vnifilter enabled, no RTM_NEWTUNNEL notification is sent to userspace. This means 'bridge monitor vni' never shows VNI add events, even though VNI delete events are reported correctly. The bug is in vxlan_vni_add(), where the notification is guarded by 'if (changed)'. The 'changed' flag is set by vxlan_vni_update_group() only when the multicast group or remote IP is modified, but for a new VNI added without a group (e.g. in L3 VxLAN interface scenarios), the function returns early without setting changed=true. Since this is a new VNI, the notification should be sent unconditionally. The notification is not guarded by the return value of vxlan_vni_update_group() because, at this point, the VNI has already been inserted into the hash table and list with no rollback on error. The VNI will be visible in 'bridge vni show' regardless, so userspace should be informed. This is consistent with vxlan_vni_del() which also notifies unconditionally. The 'if (changed)' guard remains correct in vxlan_vni_update(), which handles the case where a VNI already exists and is being re-added -- there, we only want to notify if the group/remote actually changed. Reproducer: # ip link add vxlan100 type vxlan dstport 4789 local 10.0.0.1 \ nolearning external vnifilter # ip link set vxlan100 up # bridge monitor vni & # bridge vni add vni 1000 dev vxlan100 # no notification # bridge vni delete vni 1000 dev vxlan100 # notification received Fixes: f9c4bb0b245c ("vxlan: vni filtering support on collect metadata device") Reported-by: Chirag Shah Signed-off-by: Andy Roulin Reviewed-by: Petr Machata Link: https://patch.msgid.link/20260602185138.253265-2-aroulin@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit eb676fb14427957adb8ccf9085a7cb69839e0f6d Author: Nithin Dabilpuram Date: Tue Jun 2 10:28:53 2026 +0530 octeontx2-af: npc: Fix CPT channel mask in npc_install_flow [ Upstream commit 1d31eb27e570daa04f5373345f9ac98c95863be9 ] Use the CPT-aware NIX channel mask in the npc_install_flow path so that when the host PF installs steering rules in kernel for a VF used from userspace (e.g. DPDK), MCAM entries see the same channel mask semantics as other RX paths. Fixes: 56bcef528bd8 ("octeontx2-af: Use npc_install_flow API for promisc and broadcast entries") Cc: Naveen Mamindlapalli Signed-off-by: Nithin Dabilpuram Signed-off-by: Ratheesh Kannoth Link: https://patch.msgid.link/20260602045853.1558530-1-rkannoth@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cc272185c9a9a4b7febc2de52eeaa3d00f19091e Author: Xin Long Date: Mon Jun 1 21:06:06 2026 -0400 sctp: validate cached peer INIT chunk length in COOKIE_ECHO processing [ Upstream commit 0861615c28de668669d748ef4eb913ea9262d13b ] When a listening SCTP server processes a COOKIE_ECHO chunk, the cached peer INIT chunk embedded after the cookie is parsed and its parameters are later walked by sctp_process_init() using sctp_walk_params(). However, the chunk header length of this cached INIT chunk was not validated against the remaining buffer in the COOKIE_ECHO payload. If the length field is inflated, the parameter walk can run beyond the actual received data, leading to out-of-bounds reads and potential memory corruption during later parameter handling (e.g. STATE_COOKIE processing and kmemdup() copies). Add a bounds check in sctp_unpack_cookie() to ensure the cached INIT chunk length does not exceed the available data in the COOKIE_ECHO buffer before it is used. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Brian Geffon Signed-off-by: Xin Long Link: https://patch.msgid.link/eb60825fa22d6f9e663c7d4dbb69f397b5d34d42.1780362366.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b198ed4e52580a7238c7c7082f03906f8b310313 Author: Rajat Gupta Date: Sun May 31 08:32:21 2026 -0400 net/sched: fix pedit partial COW leading to page cache corruption [ Upstream commit 899ee91156e57784090c5565e4f31bd7dbffbc5a ] tcf_pedit_act() computes the COW range for skb_ensure_writable() once before the key loop using tcfp_off_max_hint, but the hint does not account for the runtime header offset added by typed keys. This can leave part of the write region un-COW'd. Fix by moving skb_ensure_writable() inside the per-key loop where the actual write offset is known, and add overflow checking on the offset arithmetic. For negative offsets (e.g. Ethernet header edits at ingress), use skb_cow() to COW the headroom instead. Guard offset_valid() against INT_MIN, where negation is undefined. Fixes: 8b796475fd78 ("net/sched: act_pedit: really ensure the skb is writable") Reported-by: Yiming Qian Reported-by: Keenan Dong Reported-by: Han Guidong <2045gemini@gmail.com> Reported-by: Zhang Cen Reviewed-by: Han Guidong <2045gemini@gmail.com> Tested-by: Han Guidong <2045gemini@gmail.com> Reviewed-by: Davide Caratti Tested-by: Davide Caratti Reviewed-by: Toke Høiland-Jørgensen Tested-by: Toke Høiland-Jørgensen Reviewed-by: Victor Nogueira Tested-by: Victor Nogueira Acked-by: Jamal Hadi Salim Signed-off-by: Rajat Gupta Link: https://patch.msgid.link/20260531123221.48732-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e634408d2b0cd939cfe019398a21fb47b7a8ffe3 Author: Lorenzo Bianconi Date: Tue Jun 2 11:21:05 2026 +0200 net: ethernet: mtk_eth_soc: Fix use-after-free in metadata dst teardown [ Upstream commit 80df409e1a483676826a6c66e693dba6ac507751 ] mtk_free_dev() calls metadata_dst_free() which frees the metadata_dst with kfree() immediately, bypassing the RCU grace period. In the RX path, skb_dst_set_noref() sets a non-refcounted pointer from the skb to the metadata_dst. This function requires RCU read-side protection and the dst must remain valid until all RCU readers complete. Since metadata_dst_free() calls kfree() directly, a use-after-free can occur if any skb still holds a noref pointer to the dst when the driver tears it down. Replace metadata_dst_free() with dst_release() which properly goes through the refcount path: when the refcount drops to zero, it schedules the actual free via call_rcu_hurry(), ensuring all RCU readers have completed before the memory is freed. Fixes: 2d7605a72906 ("net: ethernet: mtk_eth_soc: enable hardware DSA untagging") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260602-airoha-mtk-metadata-uaf-fix-v1-2-3aaa99d83351@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6f829e2c17a53a35321268339cd252aff6d6d723 Author: Lorenzo Bianconi Date: Tue Jun 2 11:21:04 2026 +0200 net: airoha: Fix use-after-free in metadata dst teardown [ Upstream commit b38cae85d1c45ff189d7ecb6ac36f41cdc3d84d0 ] airoha_metadata_dst_free() runs metadata_dst_free() which frees the metadata_dst with kfree() immediately, bypassing the RCU grace period. In the RX path, skb_dst_set_noref() sets a non-refcounted pointer from the skb to the metadata_dst. This function requires RCU read-side protection and the dst must remain valid until all RCU readers complete. Since metadata_dst_free() calls kfree() directly, an use-after-free can occur if any skb still holds a noref pointer to the dst when the driver tears it down. Replace metadata_dst_free() with dst_release() which properly goes through the refcount path: when the refcount drops to zero, it schedules the actual free via call_rcu_hurry(), ensuring all RCU readers have completed before the memory is freed. Fixes: af3cf757d5c9 ("net: airoha: Move DSA tag in DMA descriptor") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260602-airoha-mtk-metadata-uaf-fix-v1-1-3aaa99d83351@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9a263bbd1ec0daedaf93cbb52b3257167f59afe1 Author: Kurt Kanzenbach Date: Fri May 29 19:11:47 2026 +0200 ptp: vclock: Switch from RCU to SRCU [ Upstream commit 672bd0519e27c357c43b7f8c0d653fce3817d06e ] The usage of PTP vClocks leads immediately to the following issues with ptp4l with LOCKDEP and DEBUG_ATOMIC_SLEEP enabled: "BUG: sleeping function called from invalid context". ptp_convert_timestamp() acquires a mutex_t within a RCU read section. This is illegal, because acquiring a mutex_t can result in voluntary scheduling request which is not allowed within a RCU read section. Replace the RCU usage with SRCU where sleeping is allowed. Reported-by: Florian Zeitz Closes: https://lore.kernel.org/all/00a8cce8-410e-4038-98af-49be6d93d7bd@schettke.com/ Fixes: 67d93ffc0f3c ("ptp: vclock: use mutex to fix "sleep on atomic" bug") Signed-off-by: Kurt Kanzenbach Reviewed-by: Sebastian Andrzej Siewior Link: https://patch.msgid.link/20260529-vclock_rcu-v2-1-02a5531fab92@linutronix.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a4f3fd6516920988c47ba8d19714985c40c816a1 Author: Eric Dumazet Date: Tue Jun 2 16:15:47 2026 +0000 ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options [ Upstream commit d3915a1f5a4bc0ac911032903c3c6ab8df9fcc7c ] This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAP_NET_RAW capability. This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information. While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths. RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Tamir Shahar Reported-by: Amit Klein Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260602161547.2642155-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 91106d0348a5c4f998563509b78049b8b490c868 Author: Jianyu Li Date: Mon Jun 1 19:36:39 2026 +0800 af_unix: Fix inq_len update problem in partial read [ Upstream commit c1f07a7f2d47aeb9878301e7bb36bc1c2bc2be8e ] Currently inq_len is updated only when the whole skb is consumed. If only part of the data is read, following SIOCINQ query would get value greater than what actually left. This change update inq_len timely in unix_stream_read_generic(), and adjust unix_stream_read_skb() accordingly to prevent repetitive update. Fixes: f4e1fb04c123 ("af_unix: Use cached value for SOCK_STREAM in unix_inq_len().") Signed-off-by: Jianyu Li Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260601113640.231897-2-jianyu.li@mediatek.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f010cf9aea01487595c79183687d27c557eff9da Author: Suman Ghosh Date: Fri May 29 17:07:05 2026 +0530 octeontx2-af: Fix initialization of mcam's entry2target_pffunc field [ Upstream commit 9a85ec3dc28b6df246801c19e4d9bae6297a25b0 ] NPC mcam entry stores a mapping between mcam entry and target pcifunc. During initialization of this field, API kmalloc_array has been used which caused some junk values to array. Whereas, the array is expected to be initialized by 0. This patch fixes the same by using kcalloc instead of kmalloc_array. Fixes: 55307fcb9258 ("octeontx2-af: Add mbox messages to install and delete MCAM rules") Signed-off-by: Suman Ghosh Signed-off-by: Subbaraya Sundeep Reviewed-by: Simon Horman Link: https://patch.msgid.link/1780054625-17090-1-git-send-email-sbhatta@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ddf930f28be6a96dc3f1f3f9050cdb70bd3177da Author: Geetha sowjanya Date: Fri May 29 17:07:57 2026 +0530 octeontx2-pf: Fix NDC sync operation errors [ Upstream commit a910fb8f7b9e4c566db363e6c2ec378dc7153995 ] On system reboot "rvu_nicpf 0002:03:00.0: NDC sync operation failed" error messages are shown, even if the operations is successful. This is due to wrong if error check in ndc_syc() function. Fixes: 42c45ac1419c ("octeontx2-af: Sync NIX and NPA contexts from NDC to LLC/DRAM") Signed-off-by: Geetha sowjanya Signed-off-by: Subbaraya Sundeep Reviewed-by: Simon Horman Link: https://patch.msgid.link/1780054677-17249-1-git-send-email-sbhatta@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0dfe05b938435892875e07771170051346412df9 Author: Jason Xing Date: Sat May 30 12:26:30 2026 +0800 xsk: cache csum_start/csum_offset to fix TOCTOU in xsk_skb_metadata() [ Upstream commit 22ba97ea9cc1f63a0d0244fae38057ed452b6ac7 ] The TX metadata area resides in the UMEM buffer which is memory-mapped and concurrently writable by userspace. In xsk_skb_metadata(), csum_start and csum_offset are read from shared memory for bounds validation, then read again for skb assignment. A malicious userspace application can race to overwrite these values between the two reads, bypassing the bounds check and causing out-of-bounds memory access during checksum computation in the transmit path. Fix this by reading csum_start and csum_offset into local variables once, then using the local copies for both validation and assignment. Note that other metadata fields (flags, launch_time) and the cached csum fields may be mutually inconsistent due to concurrent userspace writes, but this is benign: the only security-critical invariant is that each field's validated value is the same one used, which local caching guarantees. Closes: https://lore.kernel.org/all/20260503200927.73EA1C2BCB4@smtp.kernel.org/ Reviewed-by: Maciej Fijalkowski Signed-off-by: Jason Xing Acked-by: Stanislav Fomichev Fixes: 48eb03dd2630 ("xsk: Add TX timestamp and TX checksum offload support") Link: https://patch.msgid.link/20260530042630.80626-1-kerneljasonxing@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 58d810354de1b19d9af86a9829ad555d934a4866 Author: Luiz Augusto von Dentz Date: Tue Jun 2 16:48:34 2026 -0400 Bluetooth: MGMT: Fix backward compatibility with userspace [ Upstream commit 149324fc762c2a7acef9c26790566f81f475e51f ] bluetoothd has a bug with makes it send extra bytes as part of MGMT_OP_ADD_EXT_ADV_DATA which are now being checked to be the exact the expected length, relax this so only when the expected length is greater than the data length to cause an error since that would result in accessing invalid memory, otherwise just ignore the extra bytes. Link: https://lore.kernel.org/linux-bluetooth/20260602204749.210857-1-luiz.dentz@gmail.com/T/#u Fixes: d3f7d17960ed ("Bluetooth: MGMT: validate Add Extended Advertising Data length") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 446a17b1b509c027dec1b5be8796d43aa738f332 Author: SeungJu Cheon Date: Mon Jun 1 20:19:08 2026 +0900 Bluetooth: SCO: Fix data-race on sco_pi fields in sco_connect [ Upstream commit 4847c5bca22227100ae69e96af86618b6fd2671f ] sco_sock_connect() copies the destination address into sco_pi(sk)->dst under lock_sock(), then releases the lock and calls sco_connect(), which reads dst, src, setting, and codec without holding lock_sock() in hci_get_route() and hci_connect_sco(). These fields may be modified concurrently by connect(), bind(), or setsockopt() on the same socket, resulting in data-races reported by KCSAN. Fix this by snapshotting dst, src, setting, and codec under lock_sock() at the start of sco_connect() before passing them to hci_get_route() and hci_connect_sco(). BUG: KCSAN: data-race in memcmp+0x45/0xb0 race at unknown origin, with read to 0xffff88800e6b0dd0 of 1 bytes by task 315 on cpu 0: memcmp+0x45/0xb0 hci_connect_acl+0x1b7/0x6b0 hci_connect_sco+0x4d/0xb30 sco_sock_connect+0x27b/0xd60 __sys_connect_file+0xbd/0xe0 __sys_connect+0xe0/0x110 __x64_sys_connect+0x40/0x50 x64_sys_call+0xcad/0x1c60 do_syscall_64+0x133/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 9a8ec9e8ebb5 ("Bluetooth: SCO: Fix possible circular locking dependency on sco_connect_cfm") Signed-off-by: SeungJu Cheon Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit ab84fd7779a2a7ff5d2c8eac212c43733f56216e Author: SeungJu Cheon Date: Mon Jun 1 20:19:07 2026 +0900 Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls [ Upstream commit 9ca7053d6215d89c33f28893bfd1625a32919d3f ] iso_connect_bis(), iso_connect_cis(), iso_listen_bis(), and iso_conn_big_sync() call hci_get_route() using iso_pi(sk)->dst, iso_pi(sk)->src, and iso_pi(sk)->src_type without holding lock_sock(). These fields may be modified concurrently by connect() or setsockopt() on the same socket, resulting in data-races reported by KCSAN. Fix this by snapshotting the required fields under lock_sock() before calling hci_get_route(). BUG: KCSAN: data-race in memcmp+0x45/0xb0 race at unknown origin, with read to 0xffff8880122135cf of 1 bytes by task 333 on cpu 1: memcmp+0x45/0xb0 hci_get_route+0x27e/0x490 iso_connect_cis+0x4c/0xa10 iso_sock_connect+0x60e/0xb30 __sys_connect_file+0xbd/0xe0 __sys_connect+0xe0/0x110 __x64_sys_connect+0x40/0x50 x64_sys_call+0xcad/0x1c60 do_syscall_64+0x133/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 241f51931c35 ("Bluetooth: ISO: Avoid circular locking dependency") Signed-off-by: SeungJu Cheon Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 33d677d2e3713d98012c3dbd4a9207f7d785b854 Author: Luiz Augusto von Dentz Date: Mon Jun 1 14:45:42 2026 -0400 Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync [ Upstream commit 5cbf290b79351971f20c7a533247e8d58a3f970c ] hci_get_route() returns a reference-counted hci_dev pointer via hci_dev_hold(). The function exits normally or with an error without ever releasing it. Fixes: 07a9342b94a9 ("Bluetooth: ISO: Send BIG Create Sync via hci_sync") Reported-by: Sashiko Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit ce4b4cac3c5749b6aa75e62e2991ae2263f2f889 Author: Bharath Reddy Date: Mon Jun 1 08:54:26 2026 +0530 Bluetooth: fix memory leak in error path of hci_alloc_dev() [ Upstream commit 37b3009bf5976e8ab77c8b9a9bc3bbd7ff49e37f ] Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory. When device initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. As a result, when the device reference count reaches zero, bt_host_release() evaluates this flag as false and falls back to a direct kfree(hdev). Because hci_release_dev() is bypassed, the SRCU struct initialized early in hci_alloc_dev() is never cleaned up, resulting in a leak of percpu memory. Fix the leak by explicitly calling cleanup_srcu_struct() in the fallback (unregistered) branch of bt_host_release() before freeing the device. Reported-by: syzbot+535ecc844591e50588a5@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=535ecc844591e50588a5 Tested-by: syzbot+535ecc844591e50588a5@syzkaller.appspotmail.com Fixes: 1d6123102e9f ("Bluetooth: hci_core: Fix use-after-free in vhci_flush()") Signed-off-by: Bharath Reddy Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit c893e17d2809ec9c4b3f1cdd5847cecbc27a311b Author: Zhang Cen Date: Fri May 29 11:22:09 2026 +0800 Bluetooth: bnep: reject short frames before parsing [ Upstream commit 6770d3a8acdf9151769180cc3710346c4cfbe6f0 ] A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bnep_rx_control() also dereferences the control opcode without rejecting an empty control payload. Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads. For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the setup payload. struct bnep_setup_conn_req carries destination and source service UUIDs after that byte, each uuid_size bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication. Validation reproduced this kernel report: KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dump_stack_lvl+0xb3/0x140 (?:?) print_address_description+0x57/0x3a0 (?:?) bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virt_addr_valid+0x1ba/0x3a0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) kasan_addr_to_slab+0x21/0x60 (?:?) kasan_report+0xe0/0x110 (?:?) process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200) worker_thread+0x65c/0xe40 (?:?) __kthread_parkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) ret_from_fork+0x586/0x870 (?:?) __switch_to+0x74f/0xdc0 (?:?) ret_from_fork_asm+0x1a/0x30 (?:?) Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Assisted-by: Codex:gpt-5.5 Signed-off-by: Zhang Cen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 7f5367f1ad9bec0b381225e941899b7b8a6009cb Author: Dudu Lu Date: Wed Apr 15 17:39:53 2026 +0800 Bluetooth: bnep: fix incorrect length parsing in bnep_rx_frame() extension handling [ Upstream commit 72b8deccff17a7644e0367e1aaf1a36cfb014324 ] In bnep_rx_frame(), the BNEP_FILTER_NET_TYPE_SET and BNEP_FILTER_MULTI_ADDR_SET extension header parsing has two bugs: 1) The 2-byte length field is read with *(u16 *)(skb->data + 1), which performs a native-endian read. The BNEP protocol specifies this field in big-endian (network byte order), and the same file correctly uses get_unaligned_be16() for the identical fields in bnep_ctrl_set_netfilter() and bnep_ctrl_set_mcfilter(). 2) The length is multiplied by 2, but unlike BNEP_SETUP_CONN_REQ where the length byte counts UUID pairs (requiring * 2 for two UUIDs per entry), the filter extension length field already represents the total data size in bytes. This is confirmed by bnep_ctrl_set_netfilter() which reads the same field as a byte count and divides by 4 to get the number of filter entries. The bogus * 2 means skb_pull advances twice as far as it should, either dropping valid data from the next header or causing the pull to fail entirely when the doubled length exceeds the remaining skb. Fix by splitting the pull into two steps: first use skb_pull_data() to safely pull and validate the 3-byte fixed header (ctrl type + length), then pull the variable-length data using the properly decoded length. Fixes: bf8b9a9cb77b ("Bluetooth: bnep: Add support to extended headers of control frames") Signed-off-by: Dudu Lu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 3eabc6d47a0ad22b053329997aaf0ec1e581e392 Author: SeungJu Cheon Date: Mon May 25 20:04:43 2026 +0900 Bluetooth: RFCOMM: validate skb length in MCC handlers [ Upstream commit 23882b828c3c8c51d0c946446a396b10abb3b16b ] The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers. Fix this by using skb_pull_data() to validate and access the required data before dereferencing it. rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Suggested-by: Muhammad Bilal Signed-off-by: SeungJu Cheon Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 1a3c8ffbb469859b076445af44bdfa6a711d483e Author: Zhang Cen Date: Thu May 28 17:45:06 2026 +0800 Bluetooth: MGMT: validate advertising TLV before type checks [ Upstream commit de23fb62259aa01d294f77238ae3b835eb674413 ] tlv_data_is_valid() reads each advertising data field length from data[i], then inspects data[i + 1] for managed EIR types before checking that the current field still fits inside the supplied buffer. A malformed field whose length byte is the last byte of the buffer can therefore make the parser read one byte past the advertising data. KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING request reached that path: BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid() Read of size 1 Call trace: tlv_data_is_valid() add_advertising() hci_mgmt_cmd() hci_sock_sendmsg() Move the existing element-length check before any type-octet inspection so each non-empty element is proven to contain its type byte before the parser looks at data[i + 1]. Fixes: 2bb36870e8cb ("Bluetooth: Unify advertising instance flags check") Reviewed-by: Paul Menzel Signed-off-by: Zhang Cen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 8802413ce63175fb522a2bd609fb043a3550c720 Author: Zhang Cen Date: Thu May 28 15:56:41 2026 +0800 Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() [ Upstream commit 43c441edacf953b39517a44f5e5e10a93618b226 ] rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it. The buggy scenario involves two paths, with each column showing the order within that path: rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change(). If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback. Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use. KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Zhang Cen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit fb8db813eba2e56ee001c9fb5c2ce2cb78c42642 Author: Fedor Pchelkin Date: Mon Jun 1 12:41:56 2026 +0300 wifi: fix leak if split 6 GHz scanning fails [ Upstream commit e8694f7cc29287e843648d1075177b9a2000d957 ] rdev->int_scan_req is leaked if cfg80211_scan() fails. Note that it's supposed to be released at ___cfg80211_scan_done() but this doesn't happen as rdev->scan_req is NULL at that point, too, leading to the early return from the freeing function. unreferenced object 0xffff8881161d0800 (size 512): comm "wpa_supplicant", pid 379, jiffies 4294749765 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 f0 81 13 16 81 88 ff ff ................ backtrace (crc c867fdb6): kmemleak_alloc+0x89/0x90 __kmalloc_noprof+0x2fd/0x410 cfg80211_scan+0x133/0x730 nl80211_trigger_scan+0xc69/0x1cc0 genl_family_rcv_msg_doit+0x204/0x2f0 genl_rcv_msg+0x431/0x6b0 netlink_rcv_skb+0x143/0x3f0 genl_rcv+0x27/0x40 netlink_unicast+0x4f6/0x820 netlink_sendmsg+0x797/0xce0 __sock_sendmsg+0xc4/0x160 ____sys_sendmsg+0x5e4/0x890 ___sys_sendmsg+0xf8/0x180 __sys_sendmsg+0x136/0x1e0 __x64_sys_sendmsg+0x76/0xc0 x64_sys_call+0x13f0/0x17d0 Found by Linux Verification Center (linuxtesting.org). Fixes: c8cb5b854b40 ("nl80211/cfg80211: support 6 GHz scanning") Signed-off-by: Fedor Pchelkin Link: https://patch.msgid.link/20260601094157.92703-1-pchelkin@ispras.ru Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 15be7e9fdbff831fb3e89b83cc337a4f85ad3310 Author: Jiayuan Chen Date: Fri May 29 23:22:18 2026 +0800 ipv6: anycast: insert aca into global hash under idev->lock [ Upstream commit f723ccaff2fb72b71ae8a9fd283f0dee4d9ae7a3 ] syzbot reported a splat [1]: a slab-use-after-free in ipv6_chk_acast_addr(), which walks the global inet6_acaddr_lst[] hash under RCU and dereferences a struct ifacaddr6 that has already been freed while still linked in the hash, so a later reader walks into a dangling node. In __ipv6_dev_ac_inc() the aca is allocated with refcount 1, then aca_get() bumps it to 2 to keep it alive across the unlocked region. It is published to idev->ac_list under idev->lock, but ipv6_add_acaddr_hash() runs after write_unlock_bh(). A concurrent teardown (ipv6_ac_destroy_dev() from addrconf_ifdown(), under RTNL) can slip into that window: CPU0 __ipv6_dev_ac_inc CPU1 ipv6_ac_destroy_dev (RTNL) ------------------------------ ------------------------------------ aca_alloc() refcnt 1 aca_get() refcnt 2 write_lock_bh(idev->lock) add aca to ac_list write_unlock_bh(idev->lock) write_lock_bh(idev->lock) pull aca off ac_list write_unlock_bh(idev->lock) ipv6_del_acaddr_hash(aca) hlist_del_init_rcu() is a no-op, aca is not in the hash yet aca_put() refcnt 2->1 ipv6_add_acaddr_hash(aca) aca now inserted into the hash aca_put() refcnt 1->0 call_rcu(aca_free_rcu) -> kfree(aca) The hash removal becomes a no-op because the insertion has not happened yet, so once CPU0 inserts and drops the last reference, the aca is freed while still linked in inet6_acaddr_lst[], and readers dereference freed memory after the slab slot is reused. This window opened once RTNL stopped serializing the join path against device teardown. Move ipv6_add_acaddr_hash() inside the idev->lock section so the ac_list and hash insertions are atomic with respect to teardown: a racing remover now either misses the aca entirely or finds it in both lists. acaddr_hash_lock is now nested under idev->lock, which is acquired in softirq context, so switch all acaddr_hash_lock sites to spin_lock_bh() to avoid the irq lock inversion reported in [2]. [1] https://syzkaller.appspot.com/bug?extid=a01df04303c131efbf3a [2] https://lore.kernel.org/netdev/6a194ef7.ba3b1513.1890b4.0000.GAE@google.com/ Reported-by: syzbot+819eb928d120d2bdad0e@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6a191f87.ce022c6e.138e56.0003.GAE@google.com/T/ Reviewed-by: Kuniyuki Iwashima Fixes: eb1ac9ff6c4a ("ipv6: anycast: Don't hold RTNL for IPV6_JOIN_ANYCAST.") Signed-off-by: Jiayuan Chen Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260529152219.235475-1-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 23bf7d5c250bd91f715713bf23904eaab4e6617e Author: Tapio Reijonen Date: Fri May 29 06:18:57 2026 +0000 net: fec: fix pinctrl default state restore order on resume [ Upstream commit b455410146bf723c7ebcb49ecd5becc0d6611482 ] In fec_resume(), fec_enet_clk_enable() is called before pinctrl_pm_select_default_state() in the non-WoL path, inverting the ordering used in fec_suspend() which correctly switches to the sleep pinctrl state before disabling clocks. For PHYs with the PHY_RST_AFTER_CLK_EN flag (e.g. TI DP83848 or SMSC LAN87xx), fec_enet_clk_enable() triggers a hardware reset pulse via the phy-reset GPIO. With the GPIO pin still in sleep pinctrl state at that point, the GPIO write has no physical effect and the PHY never receives the required reset after clock enable, leading to unreliable link establishment after system resume. Fix by restoring the default pinctrl state before enabling clocks, making resume the proper mirror of suspend. The call is made unconditionally: fec_suspend() only switches to the sleep pinctrl state on the non-WoL path and leaves the pins in the default state when WoL is enabled, so on a WoL resume the device is already in the default state and pinctrl_pm_select_default_state() is a no-op. Fixes: de40ed31b3c5 ("net: fec: add Wake-on-LAN support") Signed-off-by: Tapio Reijonen Reviewed-by: Wei Fang Link: https://patch.msgid.link/20260529-b4-fec-resume-pinctrl-order-v3-1-6eda0f592fca@vaisala.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 76244b33640b6a928ed28c362d6d5eafff307308 Author: David Thompson Date: Fri May 29 21:03:00 2026 +0000 net: lan743x: permit VLAN-tagged packets up to configured MTU [ Upstream commit 8173d22b211f615015f7b35f48ab11a6dd78dc99 ] VLAN-tagged interfaces on lan743x devices were previously unreachable via SSH and failed to respond to large ping packets (e.g. "ping -s 1469" given MTU=1500). In these scenarios, "ethtool -S" reports non-zero "RX Oversize Frame Errors". According to Microchip AN2948, the MAC_RX FSE (VLAN field size enforcement) bit determines whether frames with VLAN tags exceeding the base MTU plus tag length are discarded. The driver must set the MAC_RX.FSE bit before setting MAC_RX.RXEN to allow VLAN-tagged frames up to the interface MTU, preventing them from being treated as oversized. As a result, both the base and VLAN-tagged interfaces can use the same MTU without receive errors. Fixes: 23f0703c125b ("lan743x: Add main source files for new lan743x driver") Signed-off-by: David Thompson Reviewed-by: Thangaraj Samynathan Reviewed-by: Nicolai Buchwitz Tested-by: Nicolai Buchwitz # lan7430 on arm64 (RevPi Link: https://patch.msgid.link/20260529210300.433135-1-davthompson@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 04e22fefac1af3e32f245e9045382348773b5d59 Author: Yizhou Zhao Date: Wed May 27 16:31:58 2026 +0800 net: garp: fix unsigned integer underflow in garp_pdu_parse_attr [ Upstream commit 16e408e607a94b646fb14a2a98422c6877ae4b3c ] The receive-side GARP attribute parser computes dlen with reversed operands: dlen = sizeof(*ga) - ga->len; ga->len is the on-wire attribute length and includes the GARP attribute header. For normal attributes with data, ga->len is larger than sizeof(*ga), so the subtraction underflows in unsigned arithmetic. The resulting value is later passed to garp_attr_lookup(), whose length argument is u8. After truncation, the parsed data length usually no longer matches the length stored for locally registered attributes, so received Join/Leave events are ignored. This breaks the GARP receive path for common attributes, such as GVRP VLAN registration attributes. Compute the data length as the attribute length minus the header length. Fixes: eca9ebac651f ("net: Add GARP applicant-only participant") Reported-by: Yizhou Zhao Reported-by: Yuxiang Yang Reported-by: Ao Wang Reported-by: Xuewei Feng Reported-by: Qi Li Reported-by: Ke Xu Signed-off-by: Yizhou Zhao Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260527083200.42861-1-zhaoyz24@mails.tsinghua.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 66a46e22396fd5d09606f37f73643eb20e99aa42 Author: Kuniyuki Iwashima Date: Sat May 30 06:42:58 2026 +0000 hsr: Remove WARN_ONCE() in hsr_addr_is_self(). [ Upstream commit afd0f17ca46258cec3a5cc48b8df9327fe772490 ] syzbot reported the warning [0] in hsr_addr_is_self(), whose assumption is simply wrong. hsr->self_node is cleared in hsr_del_self_node(), which is called from hsr_dellink(). Since dev->rtnl_link_ops->dellink() is called before unregister_netdevice_many(), there is a window when user can find the device but without hsr->self_node. Let's remove WARN_ONCE() in hsr_addr_is_self(). [0]: HSR: No self node WARNING: net/hsr/hsr_framereg.c:39 at hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39, CPU#0: syz.4.16848/17220 Modules linked in: CPU: 0 UID: 0 PID: 17220 Comm: syz.4.16848 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)} Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 RIP: 0010:hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39 Code: 33 2f 41 0f b7 dd 89 ee 09 de 31 ff e8 c8 b4 c6 f6 09 dd 74 54 e8 0f b0 c6 f6 31 ed eb 53 e8 06 b0 c6 f6 48 8d 3d 2f 50 9c 04 <67> 48 0f b9 3a 31 ed eb 42 e8 c1 13 1f 00 89 c5 31 ff 89 c6 e8 96 RSP: 0018:ffffc900041c70e0 EFLAGS: 00010283 RAX: ffffffff8afdc6ca RBX: ffffffff8afdc4e6 RCX: 0000000000080000 RDX: ffffc90010493000 RSI: 0000000000000948 RDI: ffffffff8f9a1700 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc900041c71e8 R11: fffff52000838e3f R12: dffffc0000000000 R13: ffff888041f9e3c0 R14: ffff888086ee3802 R15: 0000000000000000 FS: 00007f6fe985d6c0(0000) GS:ffff888126176000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f80bd437dac CR3: 0000000025096000 CR4: 00000000003526f0 DR0: ffffffffffffffff DR1: 00000000000001f8 DR2: 0000000000000002 DR3: ffffffffefffff15 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: check_local_dest net/hsr/hsr_forward.c:592 [inline] fill_frame_info net/hsr/hsr_forward.c:728 [inline] hsr_forward_skb+0xa11/0x2a80 net/hsr/hsr_forward.c:739 hsr_dev_xmit+0x253/0x370 net/hsr/hsr_device.c:236 __netdev_start_xmit include/linux/netdevice.h:5368 [inline] netdev_start_xmit include/linux/netdevice.h:5377 [inline] xmit_one net/core/dev.c:3888 [inline] dev_hard_start_xmit+0x2df/0x860 net/core/dev.c:3904 __dev_queue_xmit+0x1428/0x3900 net/core/dev.c:4870 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xcec/0x10b0 net/ipv4/ip_output.c:237 ip_send_skb net/ipv4/ip_output.c:1510 [inline] ip_push_pending_frames+0x8b/0x110 net/ipv4/ip_output.c:1530 raw_sendmsg+0x1547/0x1a50 net/ipv4/raw.c:659 sock_sendmsg_nosec net/socket.c:787 [inline] __sock_sendmsg net/socket.c:802 [inline] ____sys_sendmsg+0x7da/0x9c0 net/socket.c:2698 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2752 __sys_sendmsg net/socket.c:2784 [inline] __do_sys_sendmsg net/socket.c:2789 [inline] __se_sys_sendmsg net/socket.c:2787 [inline] __x64_sys_sendmsg+0x1c3/0x2a0 net/socket.c:2787 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f6feb62ce59 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6fe985d028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6feb8a6090 RCX: 00007f6feb62ce59 RDX: 0000000000000000 RSI: 0000200000000000 RDI: 0000000000000004 RBP: 00007f6feb6c2d6f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6feb8a6128 R14: 00007f6feb8a6090 R15: 00007ffcf01cc488 Fixes: f266a683a480 ("net/hsr: Better frame dispatch") Reported-by: syzbot+652670cf249077eb498b@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a1a861e.b111c304.35cd64.0016.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima Reviewed-by: Fernando Fernandez Mancera Link: https://patch.msgid.link/20260530064300.340793-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 07f13816be5aa15952f3f20459dd82eb204336d9 Author: Kuniyuki Iwashima Date: Fri May 29 19:39:23 2026 +0000 net: Annotate sk->sk_write_space() for UDP SOCKMAP. [ Upstream commit b748765019fe9e9234660327090fc1a9665cdbdd ] UDP TX skb->destructor() is sock_wfree(), and UDP holds lock_sock() only for UDP_CORK / MSG_MORE sendmsg(). Otherwise, sk->sk_write_space() may be read locklessly while SOCKMAP rewrites sk->sk_write_space(). Let's use WRITE_ONCE() and READ_ONCE() for sk->sk_write_space(). Note that the write side is annotated by commit 2ef2b20cf4e0 ("net: annotate data-races around sk->sk_{data_ready,write_space}"). Fixes: 7b98cd42b049 ("bpf: sockmap: Add UDP support") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Jakub Sitnicki Link: https://patch.msgid.link/20260529193941.3897256-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 83810d51d6995666255b8c7a5bd9a2276022a334 Author: Oscar Maes Date: Thu May 28 16:03:20 2026 +0200 pcnet32: stop holding device spin lock during napi_complete_done [ Upstream commit 73bf3cca7de6a73f53b6a52dc3b1c82ae5667a4d ] napi_complete_done may call gro_flush_normal (though not currently, as GRO is unsupported at the moment), which may result in packet TX. This will eventually result in calling pcnet32_start_xmit - resulting in a deadlock while trying to re-acquire the already locked spin lock. It is safe to split the spinlock block into two, because the hardware registers are still protected from concurrent access, and the two blocks perform unrelated operations that don't need to happen atomically. Fixes: 5b2ec6f2be51 ("pcnet32: use napi_complete_done()") Reviewed-by: Andrew Lunn Signed-off-by: Oscar Maes Reviewed-by: Alexander Lobakin Link: https://patch.msgid.link/20260528140320.5556-1-oscmaes92@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9b40c59bab08f2a99abf969cc0bb92fa49de004b Author: Deepanshu Kartikey Date: Sun May 31 06:47:21 2026 +0530 wifi: mac80211: limit injected antenna index in ieee80211_parse_tx_radiotap [ Upstream commit 6c0cf89f36ac0c0fd8687a4ccdce2efb23a9c663 ] When parsing the radiotap header of an injected frame, ieee80211_parse_tx_radiotap() uses the IEEE80211_RADIOTAP_ANTENNA value directly as a shift count: info->control.antennas |= BIT(*iterator.this_arg); *iterator.this_arg is an 8-bit value taken straight from the frame supplied by userspace, so BIT() can be asked to shift by up to 255. That is undefined behaviour on the unsigned long and is reported by UBSAN: UBSAN: shift-out-of-bounds in net/mac80211/tx.c:2174:30 shift exponent 235 is too large for 64-bit type 'unsigned long' Call Trace: ieee80211_parse_tx_radiotap+0xadb/0x1950 net/mac80211/tx.c:2174 ieee80211_monitor_start_xmit+0xb1f/0x1250 net/mac80211/tx.c:2451 ... packet_sendmsg+0x3eb6/0x50f0 net/packet/af_packet.c:3109 info->control.antennas is a 2-bit bitmap (u8 antennas:2), so only antenna indices 0 and 1 can ever be represented. Ignore any larger value instead of shifting out of bounds. Reported-by: syzbot+8e0622f6d9446420271f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=8e0622f6d9446420271f Fixes: ef246a1480cc ("wifi: mac80211: support antenna control in injection") Signed-off-by: Deepanshu Kartikey Link: https://patch.msgid.link/20260531011721.102941-1-kartikey406@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit e3f6ba5f8cf3374995359b29a4eaa23a11155a4d Author: Yicong Hui Date: Mon Apr 6 19:00:13 2026 +0100 drm/imx: Fix three kernel-doc warnings in dcss-scaler.c [ Upstream commit ae0383e5a9a4b12d68c76c4769857def4665deff ] Fix the following W=1 kerneldoc warnings by adding the missing parameter descriptions for @phase0_identity and @nn_interpolation in dcss_scaler_filter_design() and @phase0_identity in dcss_scaler_gaussian_filter() Warning: drivers/gpu/drm/imx/dcss/dcss-scaler.c:173 function parameter 'phase0_identity' not described in 'dcss_scaler_gaussian_filter' Warning: drivers/gpu/drm/imx/dcss/dcss-scaler.c:270 function parameter 'phase0_identity' not described in 'dcss_scaler_filter_design' Warning: drivers/gpu/drm/imx/dcss/dcss-scaler.c:270 function parameter 'nn_interpolation' not described in 'dcss_scaler_filter_design' Fixes: 9021c317b770 ("drm/imx: Add initial support for DCSS on iMX8MQ") Signed-off-by: Yicong Hui Reviewed-by: Laurentiu Palcu Link: https://patch.msgid.link/20260406180013.2442096-1-yiconghui@gmail.com Signed-off-by: Liu Ying Signed-off-by: Sasha Levin commit 927f96861f939c0b517d13ed27bf4fabbfc1cfb3 Author: Mark Bloch Date: Thu May 28 22:14:10 2026 +0300 devlink: Release nested relation on devlink free [ Upstream commit 3522b21fd7e1863d0734537737bd59f1b90d0190 ] devlink relation state is normally released from devl_unregister(), which calls devlink_rel_put(). This misses devlink instances that get a nested relation before registration and then fail probe before devl_register() is reached. That flow can happen for SFs. The child devlink gets linked to its parent before registration, then a later probe error calls devlink_free() directly. Since the instance was never registered, devl_unregister() is not called and devlink->rel is leaked. Release any pending relation from devlink_free() as well. The registered path is unchanged because devl_unregister() already clears devlink->rel before devlink_free() runs. Fixes: c137743bce02 ("devlink: introduce object and nested devlink relationship infra") Signed-off-by: Mark Bloch Reviewed-by: Jiri Pirko Link: https://patch.msgid.link/20260528191411.3270532-1-mbloch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e251d4cdfc725c9e7d686161e3b775a0e7d95053 Author: Lee Jones Date: Wed May 27 13:36:29 2026 +0000 l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl() [ Upstream commit a213a8950414c684999dcf03edeea6c46ede172e ] pppol2tp_ioctl() read sock->sk->sk_user_data directly without any locks or reference counting. If a controllable sleep was induced during copy_from_user() (e.g. via a userfaultfd page fault sleep), a concurrent socket close could trigger pppol2tp_session_close() asynchronously. This frees the l2tp_session structure via the l2tp_session_del_work workqueue. Upon resuming, the ioctl thread dereferences the stale session pointer, resulting in a Use-After-Free (UAF). Fix this by securely fetching the session reference using the RCU-safe, refcounted helper pppol2tp_sock_to_session(sk) on entry. This locks the session's refcount across the sleep. We structured the function to exit via standard err breaks, guaranteeing that l2tp_session_put() is cleanly called on all return paths to drop the reference. To preserve existing behavior we validate the session and its magic signature only for the specific L2TP commands that require it. This ensures that generic/unknown ioctls called on an unconnected socket still return -ENOIOCTLCMD and correctly fall back to generic handlers (e.g. in sock_do_ioctl()). Signed-off-by: Lee Jones Fixes: fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts") Link: https://patch.msgid.link/20260527133630.2120612-1-lee@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c32f30ef5e66adbfa102348e2e8a23776eb007cb Author: Yizhou Zhao Date: Wed May 27 16:18:01 2026 +0800 6lowpan: fix off-by-one in multicast context address compression [ Upstream commit 2a58899d11009bffc7b4b32a571858f381121837 ] The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses &data[1] as destination and &ipaddr->s6_addr[11] as source, but both should be offset by one: &data[2] and &ipaddr->s6_addr[12] respectively. This off-by-one has two consequences: 1. data[1] is overwritten with s6_addr[11], corrupting the RIID field in the compressed multicast address 2. data[5] is never written, so uninitialized kernel stack memory is transmitted over the network via lowpan_push_hc_data(), leaking kernel stack contents The correct inline data layout must match what the decompression function lowpan_uncompress_multicast_ctx_daddr() expects: data[0..1] = s6_addr[1..2] (flags/scope + RIID) data[2..5] = s6_addr[12..15] (group ID) Also zero-initialize the data array as a defensive measure against similar bugs in the future. Fixes: 5609c185f24d ("6lowpan: iphc: add support for stateful compression") Reported-by: Yizhou Zhao Reported-by: Yuxiang Yang Reported-by: Ao Wang Reported-by: Xuewei Feng Reported-by: Qi Li Reported-by: Ke Xu Signed-off-by: Yizhou Zhao Acked-by: Alexander Aring Link: https://patch.msgid.link/20260527081806.42747-1-zhaoyz24@mails.tsinghua.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b60e9391142e983fab2be53497aa8f71fdd09cd5 Author: Jamal Hadi Salim Date: Sun May 31 12:08:12 2026 -0400 net/sched: act_api: use RCU with deferred freeing for action lifecycle [ Upstream commit 5057e1aca011e51ef51498c940ef96f3d3e8a305 ] When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action. Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER: 0: mutex_lock() <-- holds the idr lock 0: rcu_read_lock() 0: p = idr_find(idr, index) <-- action p is valid (RCU protects IDR) 0: mutex_unlock() <-- releases the idr lock 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) <-- Action removed from IDR 1: mutex_unlock() <-- mutex released allowing us to delete the action 1: tcf_action_cleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcu_head to tc_action used in the deferral and introducing a call_rcu() in the delete path to defer the final kfree(). Note: this is a revert of commit d7fb60b9cafb ("net_sched: get rid of tcfa_rcu") but also modernization/simplification to directly use kfree_rcu(). Let's illustrate the new restored code path: 0: rcu_read_lock() 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) 1: mutex_unlock() 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) <-- defer kfree after grace period 0: p = idr_find(idr, index) 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- fails, refcnt already 0 1: rcu_read_unlock() <-- release so freeing can run after grace period After CPU1 calls idr_remove(), the object is no longer reachable through the IDR. CPU0's subsequent idr_find() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur. Fixes: d7fb60b9cafb ("net_sched: get rid of tcfa_rcu") Suggested-by: Jakub Kicinski Reported-by: Kyle Zeng Tested-by: Victor Nogueira Tested-by: syzbot@syzkaller.appspotmail.com Signed-off-by: Jamal Hadi Salim Tested-by: Kyle Zeng Reviewed-by: Pedro Tammela Reviewed-by: Eric Dumazet Reviewed-by: Victor Nogueira Link: https://patch.msgid.link/20260531160812.68020-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 42ff6774ecd9d7f70d599cb71ff64373a1da4948 Author: Guangshuo Li Date: Fri May 29 23:57:45 2026 +0800 dm cache policy smq: check allocation under invalidate lock [ Upstream commit d3f0a606b9f278ece8a0df626ded9c4044071235 ] commit 2d1f7b65f5de ("dm cache policy smq: fix missing locks in invalidating cache blocks") added mq->lock around the destructive part of smq_invalidate_mapping(), but left the e->allocated check outside the critical section. That leaves a check-then-act race. Two concurrent invalidators can both observe e->allocated as true before either of them takes mq->lock. The first invalidator that acquires the lock removes the entry from the queues and hash table and then calls free_entry(), which clears e->allocated and puts the entry back on the free list. The second invalidator can then acquire mq->lock and continue with the stale result of the unlocked check. This can corrupt the SMQ queues or hash table by deleting an entry that is no longer on those structures. It can also hit the allocation check in free_entry() when the same entry is freed again. Move the allocation check under mq->lock so the predicate and the destructive operations are serialized by the same lock. Fixes: 2d1f7b65f5de ("dm cache policy smq: fix missing locks in invalidating cache blocks") Signed-off-by: Guangshuo Li Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit b18675263db1147c8e1cab625400c13a0d87bd2d Author: Yiming Qian Date: Sat May 23 12:29:10 2026 +0000 netfilter: bridge: make ebt_snat ARP rewrite writable [ Upstream commit 67ba971ae02514d85818fe0c32549ab4bfa3bf49 ] The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits(). Fixes: 63137bc5882a ("netfilter: ebtables: Fixes dropping of small packets in bridge nat") Reported-by: Yiming Qian Signed-off-by: Yiming Qian Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit f071b0bf078146368d18e4eec386bf2ddc0ab7e0 Author: Jiayuan Chen Date: Thu May 28 19:09:19 2026 +0800 netfilter: nft_ct: bail out on template ct in get eval [ Upstream commit 3027ecbdb5fdf9200251c21d4818e4c447ef78e1 ] I noticed this issue while looking at a historic syzbot report [1]. A rule like the one below is enough to trigger the bug: table ip t { chain pre { type filter hook prerouting priority raw; ct zone set 1 ct original saddr 1.2.3.4 accept } } The first expression attaches a per-cpu template ct via nft_ct_set_zone_eval() (nf_ct_tmpl_alloc -> kzalloc, tuple is all zero, nf_ct_l3num(ct) == 0). The next expression then calls nft_ct_get_eval() on the same skb, treats the template as a real ct and hits the 16-byte memcpy path. With dreg at NFT_REG32_15 this overflows past struct nft_regs on the kernel stack; with smaller dreg values it silently clobbers adjacent registers. Reject template ct at the eval entry and in nft_ct_get_fast_eval(), mirroring the check nft_ct_set_eval() already has. Additionally, bound the address copy in NFT_CT_SRC / NFT_CT_DST by priv->len instead of by nf_ct_l3num(ct): nf_ct_get_tuple() zeroes the tuple before pkt_to_tuple() fills in only the protocol-relevant leading bytes, so the trailing bytes of tuple->{src,dst}.u3.all are well-defined zero. priv->len is validated at rule load, so the copy size is now bounded by the destination register rather than by an untrusted field on the conntrack. [1]: https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c Fixes: 45d9bcda21f4 ("netfilter: nf_tables: validate len in nft_validate_data_load()") Suggested-by: Florian Westphal Signed-off-by: Jiayuan Chen Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 9e5da2379f968a3ea5a6e38921ab6201576466dc Author: Florian Westphal Date: Wed May 27 12:20:19 2026 +0200 netfilter: conntrack_irc: fix possible out-of-bounds read [ Upstream commit 66eba0ffce3b7e11449946b4cbbef8ea36112f56 ] When parsing fails after we've matched the command string we should bail out instead of trying to match a different command. This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026. Fixes: 869f37d8e48f ("[NETFILTER]: nf_conntrack/nf_nat: add IRC helper port") Closes: https://sashiko.dev/#/patchset/20260525182924.28456-1-fw%40strlen.de Signed-off-by: Florian Westphal Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit aaf80701dc2f7a48fe543961e21f8ca3924d587c Author: Fernando Fernandez Mancera Date: Tue May 26 23:58:31 2026 +0200 netfilter: synproxy: add mutex to guard hook reference counting [ Upstream commit 2fcba19caaeb2a33017459d3430f057967bb91b6 ] As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other. Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY. Fixes: ad49d86e07a4 ("netfilter: nf_tables: Add synproxy support") Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 25918720ba97f974a4f8d433b5a0132c5b43f6f3 Author: Julian Anastasov Date: Mon May 25 07:07:44 2026 +0300 ipvs: clear the svc scheduler ptr early on edit [ Upstream commit 193989cc6d80dd8e0460fb3992e69fa03bf0ff9b ] ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code. Link: https://sashiko.dev/#/patchset/20260519015506.634185-1-rosenp%40gmail.com Fixes: 05f00505a89a ("ipvs: fix crash if scheduler is changed") Signed-off-by: Julian Anastasov Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit cdaf13260c99575626c01808a1bc7ca56c6391b9 Author: Fernando Fernandez Mancera Date: Fri May 22 12:47:17 2026 +0200 netfilter: xt_NFQUEUE: prefer raw_smp_processor_id [ Upstream commit c6c5327dd18bec1e1bbf139b2cf5ae53608a9d30 ] With PREEMPT_RCU this triggers a splat because smp_processor_id() can be preempted while inside a RCU critical section. If xt_NFQUEUE target is invoked via nft_compat_eval() path, we are inside a RCU critical section. Just use the raw version instead. Fixes: 0ca743a55991 ("netfilter: nf_tables: add compatibility layer for x_tables") Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit e735dbd489e3ea02be78dba991056fe1138be51e Author: Gil Portnoy Date: Thu May 28 00:00:00 2026 +0000 ksmbd: fix NULL-deref of opinfo->conn in oplock/lease break notifiers [ Upstream commit b003086d76968298f22e7cf62239833b5a3a06b1 ] smb2_oplock_break_noti() and smb2_lease_break_noti() read opinfo->conn into a local with neither READ_ONCE() nor a NULL check. Both run from oplock_break() after opinfo_get_list() has dropped ci->m_lock, so a concurrent SMB2 LOGOFF (session_fd_check()) can set op->conn = NULL under ci->m_lock within that window. ksmbd_conn_r_count_inc(conn) then writes through NULL at offset 0xc4 -- a remotely triggerable oops. Guard both reads the way compare_guid_key() already does: read opinfo->conn with READ_ONCE() and return early if it is NULL, before allocating the work struct so nothing leaks. A NULL conn means the client is gone and the break is moot, so return 0; oplock_break() treats that as success and runs the normal teardown. Fixes: c8efcc786146 ("ksmbd: add support for durable handles v1/v2") Assisted-by: Henry (Claude):claude-opus-4 Signed-off-by: Gil Portnoy Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 9dca676247216949fe5f34406fe631bdcc2db60f Author: Emmanuel Grumbach Date: Fri May 29 08:57:05 2026 +0300 wifi: iwlwifi: mvm: don't support the reset handshake for old firmwares [ Upstream commit 0eaa1f245ac03ed0c6394159360532726f666811 ] -77.ucode doesn't contain the fixes for this flow it seems. Don't use the firmware reset handshake even if the firmware claims support for it. Fixes: 906d4eb84408 ("iwlwifi: support firmware reset handshake") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220600 Signed-off-by: Emmanuel Grumbach Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260529085453.9307b81d9b02.I21bba9e649f4cd0e35d3ea6cd97a03258be5832f@changeid Signed-off-by: Sasha Levin commit 00bf6868df65fa95b3854996246d15759fdc7070 Author: Gao Xiang Date: Fri May 22 16:27:16 2026 +0800 erofs: fix use-after-free on sbi->sync_decompress [ Upstream commit 1aee05e814d292064bf5fa15733741040cdc48ba ] z_erofs_decompress_kickoff() can race with filesystem unmount, causing a use-after-free on sbi->sync_decompress. When I/O completes, z_erofs_endio() calls z_erofs_decompress_kickoff() to queue z_erofs_decompressqueue_work() asynchronously. Then, after all folios are unlocked, unmount workflow can proceed and sbi will be freed before accessing to sbi->sync_decompress. Thread (unmount) I/O completion kworker queue_work z_erofs_decompressqueue_work (all folios are unlocked) cleanup_mnt .. erofs_kill_sb erofs_sb_free kfree(sbi) access sbi->sync_decompress // UAF!! Fixes: 40452ffca3c1 ("erofs: add sysfs node to control sync decompression strategy") Reported-by: syzbot+52bae5c495dbe261a0bc@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=52bae5c495dbe261a0bc Reviewed-by: Chao Yu Reviewed-by: Jianan Huang Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 50fd261b1ec4b31f749c4e498b877dbb0417c8a9 Author: Gao Xiang Date: Mon Jan 12 11:43:30 2026 +0800 erofs: tidy up synchronous decompression [ Upstream commit cc831ab33644088c1eef78936de24701014d520a ] - Get rid of `sbi->opt.max_sync_decompress_pages` since it's fixed as 3 all the time; - Add Z_EROFS_MAX_SYNC_DECOMPRESS_BYTES in bytes instead of in pages, since for non-4K pages, 3-page limitation makes no sense; - Move `sync_decompress` to sbi to avoid unexpected remount impact; - Fold z_erofs_is_sync_decompress() into its caller; - Better description of sysfs entry `sync_decompress`. Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Stable-dep-of: 1aee05e814d2 ("erofs: fix use-after-free on sbi->sync_decompress") Signed-off-by: Sasha Levin commit 8db2fabb5ecd9e4917a938d6021fd0a2f4bfbfc5 Author: Robertus Diawan Chris Date: Tue May 19 09:05:28 2026 +0700 tee: qcomtee: add missing va_end in early return qcomtee_object_user_init() [ Upstream commit 471c18323dfdfe7844e193b896a9267ae23a1026 ] qcomtee_object_user_init() is a variadic function and when the function return because there's no dispatch callback in QCOMTEE_OBJECT_TYPE_CB case, there's no va_end to cleanup "ap" object initialized by va_start and that can cause undefined behavior. So make sure to use va_end before returning the error code when there's no dispatch callback. This is reported by Coverity Scan as "Missing varargs init or cleanup". Fixes: d6e290837e50 ("tee: add Qualcomm TEE driver") Signed-off-by: Robertus Diawan Chris Reviewed-by: Amirreza Zarrabi Signed-off-by: Jens Wiklander Signed-off-by: Sasha Levin commit ac7eca1ae4e571868f1aafb260c3c0b79c028db6 Author: Arnd Bergmann Date: Thu Dec 4 11:17:23 2025 +0100 tee: fix tee_ioctl_object_invoke_arg padding [ Upstream commit c15d7a2a11ea055bcecc0b538ae8ba79475637f9 ] The tee_ioctl_object_invoke_arg structure has padding on some architectures but not on x86-32 and a few others: include/linux/tee.h:474:32: error: padding struct to align 'params' [-Werror=padded] I expect that all current users of this are on architectures that do have implicit padding here (arm64, arm, x86, riscv), so make the padding explicit in order to avoid surprises if this later gets used elsewhere. Fixes: d5b8b0fa1775 ("tee: add TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF") Signed-off-by: Arnd Bergmann Reviewed-by: Jens Wiklander Tested-by: Harshal Dev Reviewed-by: Sumit Garg Signed-off-by: Jens Wiklander Signed-off-by: Sasha Levin commit 633db9a1991a0eb503261318150810d05b796400 Author: Manivannan Sadhasivam Date: Mon May 18 19:22:18 2026 +0530 soc: qcom: ice: Return -ENODEV if the ICE platform device is not found [ Upstream commit 5a4dc805a80e6fe303d6a4748cd451ea15987ffd ] By the time the consumer driver calls devm_of_qcom_ice_get(), all the platform devices for ICE nodes would've been created by of_platform_default_populate(). So for the absence of any platform device, -ENODEV should not returned, not -EPROBE_DEFER. Fixes: 2afbf43a4aec ("soc: qcom: Make the Qualcomm UFS/SDCC ICE a dedicated driver") Tested-by: Sumit Garg # OP-TEE as TZ Acked-by: Sumit Garg Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260518-qcom-ice-fix-v7-2-2a595382185b@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 40fc6ed12f9193c66dfb58ecde74256423b6cf78 Author: Mihai Sain Date: Mon Mar 9 09:53:29 2026 +0200 ARM: dts: microchip: sam9x7: fix GMAC clock configuration [ Upstream commit 765aaba18413a66f6c8fe8416336ca9b3dd98a79 ] The GMAC node incorrectly listed four clocks, including a separate tx_clk and a TSU GCK clock sourced from ID 67. According to the SAM9X7 clocking scheme, the GMAC uses only three clocks: HCLK, PCLK, and the TSU GCK derived from the GMAC peripheral clock (ID 24). Remove the unused tx_clk, update the clock-names accordingly, and correct the assigned clock to use GCK 24 instead of GCK 67. This aligns the device tree with the actual hardware clock topology and prevents misconfiguration of the GMAC clock tree. [root@SAM9X75 ~]$ cat /sys/kernel/debug/clk/clk_summary | grep gmac gmac_gclk 1 1 1 266666666 0 0 50000 Y f802c000.ethernet tsu_clk f802c000.ethernet tsu_clk gmac_clk 2 2 0 266666666 0 0 50000 Y f802c000.ethernet hclk f802c000.ethernet pclk Fixes: 41af45af8bc3 ("ARM: dts: at91: sam9x7: add device tree for SoC") Signed-off-by: Mihai Sain Link: https://lore.kernel.org/r/20260309075329.1528-5-mihai.sain@microchip.com [claudiu.beznea: massaged the patch description] Signed-off-by: Claudiu Beznea Signed-off-by: Sasha Levin commit 9cb93ec617fb9060ce57e5faa97d99180e4a4377 Author: Val Packett Date: Wed Mar 11 21:53:37 2026 -0300 arm64: dts: qcom: x1-dell-thena: remove i2c20 (battery SMBus) and reserve its pins [ Upstream commit 4b15b03166cc5d28e9912287b1f9b6607c8710ec ] i2c20 is used by the battmgr service on the ADSP to communicate with the SBS interface of the battery. Initializing it from Linux would break the battmgr functionality when booted in EL2. Mark those pins as reserved. Fixes: e7733b42111c ("arm64: dts: qcom: Add support for Dell Inspiron 7441 / Latitude 7455") Reviewed-by: Konrad Dybcio Reviewed-by: Abel Vesa Signed-off-by: Val Packett Link: https://lore.kernel.org/r/20260312005731.12488-2-val@packett.cool Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a171bc68e9af26b5946047f6485e75d169d526a8 Author: Harshal Dev Date: Thu Apr 16 17:29:19 2026 +0530 soc: qcom: ice: Allow explicit votes on 'iface' clock for ICE [ Upstream commit 0d5dc5818191b55e4364d04b1b898a14a2ccac38 ] Since Qualcomm inline-crypto engine (ICE) is now a dedicated driver de-coupled from the QCOM UFS driver, it explicitly votes for its required clocks during probe. For scenarios where the 'clk_ignore_unused' flag is not passed on the kernel command line, to avoid potential unclocked ICE hardware register access during probe the ICE driver should additionally vote on the 'iface' clock. Also update the suspend and resume callbacks to handle un-voting and voting on the 'iface' clock. Fixes: 2afbf43a4aec6 ("soc: qcom: Make the Qualcomm UFS/SDCC ICE a dedicated driver") Reviewed-by: Manivannan Sadhasivam Reviewed-by: Kuldeep Singh Reviewed-by: Konrad Dybcio Signed-off-by: Harshal Dev Link: https://lore.kernel.org/r/20260416-qcom_ice_power_and_clk_vote-v5-2-5ccf5d7e2846@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d5b57bb314d79e99bebb58a53588fa11dd4dbf69 Author: Amirreza Zarrabi Date: Mon Feb 16 14:24:06 2026 -0800 tee: optee: prevent use-after-free when the client exits before the supplicant [ Upstream commit 387a926ee166814611acecb960207fe2f3c4fd3e ] Commit 70b0d6b0a199 ("tee: optee: Fix supplicant wait loop") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request. If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free. Serialise access to the request with supp->mutex: * Hold supp->mutex in optee_supp_recv() and optee_supp_send() while looking up and touching the request. * Let optee_supp_thrd_req() notice that the client has terminated and signal optee_supp_send() accordingly. With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race. Fixes: 70b0d6b0a199 ("tee: optee: Fix supplicant wait loop") Signed-off-by: Amirreza Zarrabi Tested-by: Ox Yeh Reviewed-by: Sumit Garg Signed-off-by: Jens Wiklander Signed-off-by: Sasha Levin commit dcd90f42a33e4220385f27b515183d0c91b2fc4a Author: Nicolò Coccia Date: Sun May 10 12:34:13 2026 -0400 net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS commit a3fdd924d88c30b9f488636ce0e4696012cf5511 upstream. A logic flaw in __smc_setsockopt() allows a local unprivileged user to cause a Denial of Service (DoS) by holding the socket lock indefinitely. The function __smc_setsockopt() calls copy_from_sockptr() while holding lock_sock(sk). By passing a userfaultfd-monitored memory page (or FUSE-backed memory on systems where unprivileged userfaultfd is disabled) as the optval, an attacker can halt execution during the copy operation, keeping the lock held. Combined with asynchronous tear-down operations like shutdown(), this exhausts the kernel wq (kworkers) and triggers the hung task watchdog. [ 240.123456] INFO: task kworker/u8:2 blocked for more than 120 seconds. [ 240.123489] Call Trace: [ 240.123501] smc_shutdown+... [ 240.123512] lock_sock_nested+... This patch moves the user-space copy outside the lock_sock() critical section to prevent the issue. Fixes: a6a6fe27bab4 ("net/smc: Dynamic control handshake limitation by socket options") Signed-off-by: Nicolò Coccia Reviewed-by: Dust Li Tested-by: Dust Li Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4203806f700bb44ea0b05d484d9d40044b47fb04 Author: Ido Schimmel Date: Wed Jun 3 13:18:11 2026 +0300 ipv6: mcast: Fix use-after-free when processing MLD queries commit 791c91dc7a9dfb2457d5e29b8216a6484b9c4b40 upstream. When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskb_may_pull() calls, leading to a use-after-free [1]. Fix by copying the multicast group address when the packet is initially parsed. [1] BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118 Workqueue: mld mld_query_work Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_address_description.constprop.0 (mm/kasan/report.c:378) print_report (mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) __mld_query_work (net/ipv6/mcast.c:1512) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) [...] Freed by task 118: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskb_expand_head (net/core/skbuff.c:2335) __pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4)) __mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1)) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Fixes: 97300b5fdfe2 ("[MCAST] IPv6: Check packet size when process Multicast") Reported-by: Leo Lin Reviewed-by: David Ahern Signed-off-by: Ido Schimmel Reviewed-by: Eric Dumazet Reviewed-by: Jiayuan Chen Link: https://patch.msgid.link/20260603101811.612594-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ffbcf31f032eb454ebfd29309f51366fe57f4ac4 Author: Mingyu Wang <25181214217@stu.xidian.edu.cn> Date: Mon Apr 27 10:57:45 2026 +0800 i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl commit 617eb7c0961a8dfcfc811844a6396e406b2923ea upstream. While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong timeout value` warning was observed, accompanied by SMBus controller state machine corruption. The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INT_MAX, but it is subsequently multiplied by 10 before being passed to msecs_to_jiffies(). A malicious user can pass a large value (e.g., 429496729) that passes the `arg > INT_MAX` check but overflows when multiplied by 10. This results in a truncated 32-bit unsigned value that bypasses the internal `(int)m < 0` check in `msecs_to_jiffies()`. The truncated value is then assigned to `client->adapter->timeout` (a signed 32-bit int), which is reinterpreted as a negative number. When passed to wait_for_completion_timeout(), this negative value undergoes sign extension to a 64-bit unsigned long, triggering the `schedule_timeout` warning and causing premature returns. This leaves the SMBus state machine in an unrecoverable state, constituting a local Denial of Service (DoS). Fix this by bounding the user argument to `INT_MAX / 10`. Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> [wsa: move the comment as well] Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 97706097f9b851cfe55c3b00b083dfc2bcf542bc Author: Hyunwoo Kim Date: Wed Jun 3 21:09:33 2026 +0900 KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation commit f2ca45b50d4216c9cc7ffabf50d9ad1932209251 upstream. walk_s1() and kvm_walk_nested_s2() expect to be called while holding kvm->srcu to guard against memslot changes. While this is generally the case, __kvm_at_s12() and __kvm_find_s1_desc_level() call into the respective walkers without taking kvm->srcu. Fix by acquiring kvm->srcu prior to the table walk in both instances. Cc: stable@vger.kernel.org Fixes: 50f77dc87f13 ("KVM: arm64: Populate level on S1PTW SEA injection") Fixes: be04cebf3e78 ("KVM: arm64: nv: Add emulation of AT S12E{0,1}{R,W}") Suggested-by: Oliver Upton Signed-off-by: Hyunwoo Kim Reviewed-by: Oliver Upton Link: https://patch.msgid.link/aiAZfdeyanIvP8SD@v4bel Signed-off-by: Marc Zyngier [ Hyunwoo Kim: __kvm_at_s12() still returns void in 6.18.y, so the surrounding context differs from upstream (return; instead of return ret;); the added scoped_guard() is unchanged. ] Signed-off-by: Hyunwoo Kim Signed-off-by: Greg Kroah-Hartman commit 9e767af5f10956073ab2694b9fbe3267a15e872a Author: Russell King (Oracle) Date: Mon May 11 15:53:57 2026 +0200 ARM: fix branch predictor hardening commit fd2dee1c6e2256f726ba33fd3083a7be0efc80d3 upstream. __do_user_fault() may be called with indeterminent interrupt enable state, which means we may be preemptive at this point. This causes problems when calling harden_branch_predictor(). For example, when called from a data abort, do_alignment_fault()->do_bad_area(). Move harden_branch_predictor() out of __do_user_fault() and into the calling contexts. Moving it into do_kernel_address_page_fault(), we can be sure that interrupts will be disabled here. Converting do_translation_fault() to use do_kernel_address_page_fault() rather than do_bad_area() means that we keep branch predictor handling for translation faults. Interrupts will also be disabled at this call site. do_sect_fault() needs special handling, so detect user mode accesses to kernel-addresses, and add an explicit call to branch predictor hardening. Finally, add branch predictor hardening to do_alignment() for the faulting case (user mode accessing kernel addresses) before interrupts are enabled. This should cover all cases where harden_branch_predictor() is called, ensuring that it is always has interrupts disabled, also ensuring that it is called early in each call path. Reviewed-by: Xie Yuanbin Tested-by: Xie Yuanbin Signed-off-by: Russell King (Oracle) Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Sasha Levin commit 05e22564a4f9888ca916225a5e599e6fbe11e327 Author: Russell King (Oracle) Date: Mon May 11 15:53:56 2026 +0200 ARM: fix hash_name() fault commit 7733bc7d299d682f2723dc38fc7f370b9bf973e9 upstream. Zizhi Wo reports: "During the execution of hash_name()->load_unaligned_zeropad(), a potential memory access beyond the PAGE boundary may occur. For example, when the filename length is near the PAGE_SIZE boundary. This triggers a page fault, which leads to a call to do_page_fault()->mmap_read_trylock(). If we can't acquire the lock, we have to fall back to the mmap_read_lock() path, which calls might_sleep(). This breaks RCU semantics because path lookup occurs under an RCU read-side critical section." This is seen with CONFIG_DEBUG_ATOMIC_SLEEP=y and CONFIG_KFENCE=y. Kernel addresses (with the exception of the vectors/kuser helper page) do not have VMAs associated with them. If the vectors/kuser helper page faults, then there are two possibilities: 1. if the fault happened while in kernel mode, then we're basically dead, because the CPU won't be able to vector through this page to handle the fault. 2. if the fault happened while in user mode, that means the page was protected from user access, and we want to fault anyway. Thus, we can handle kernel addresses from any context entirely separately without going anywhere near the mmap lock. This gives us an entirely non-sleeping path for all kernel mode kernel address faults. As we handle the kernel address faults before interrupts are enabled, this change has the side effect of improving the branch predictor hardening, but does not completely solve the issue. Reported-by: Zizhi Wo Reported-by: Xie Yuanbin Link: https://lore.kernel.org/r/20251126090505.3057219-1-wozizhi@huaweicloud.com Reviewed-by: Xie Yuanbin Tested-by: Xie Yuanbin Signed-off-by: Russell King (Oracle) Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Sasha Levin commit 8bdb574b217694855ff91488d48c03065f103415 Author: Russell King (Oracle) Date: Mon May 11 15:53:55 2026 +0200 ARM: allow __do_kernel_fault() to report execution of memory faults commit 40b466db1dffb41f0529035c59c5739636d0e5b8 upstream. Allow __do_kernel_fault() to detect the execution of memory, so we can provide the same fault message as do_page_fault() would do. This is required when we split the kernel address fault handling from the main do_page_fault() code path. Reviewed-by: Xie Yuanbin Tested-by: Xie Yuanbin Signed-off-by: Russell King (Oracle) Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Sasha Levin commit 22e26df355afc2eb1f51e0c808bfb3a38a548ef7 Author: Russell King (Oracle) Date: Mon May 11 15:53:54 2026 +0200 ARM: group is_permission_fault() with is_translation_fault() commit dea20281ac88226615761c570c8ff7adc18e6ac2 upstream. Group is_permission_fault() with is_translation_fault(), which is needed to use is_permission_fault() in __do_kernel_fault(). As this is static inline, there is no need for this to be under CONFIG_MMU. Signed-off-by: Russell King (Oracle) Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Sasha Levin commit 87dfb977bdb6eaa47e9993a34e18f44970f88b1f Author: Kuniyuki Iwashima Date: Sun Apr 26 01:26:43 2026 +0000 bpf: Free reuseport cBPF prog after RCU grace period. [ Upstream commit 18fc650ccd7fe3376eca89203668cfb8268f60df ] Eulgyu Kim reported the splat below with a repro. [0] The repro sets up a UDP reuseport group with a cBPF prog and replaces it with a new one while another thread is sending a UDP packet to the group. The reuseport prog is freed by sk_reuseport_prog_free(). bpf_prog_put() is called for "e"BPF prog to destruct through multiple stages while cBPF prog is freed immediately by bpf_release_orig_filter() and bpf_prog_free(). If a reuseport prog is detached from the setsockopt() path (reuseport_attach_prog() or reuseport_detach_prog()), sk_reuseport_prog_free() is called without waiting for RCU readers to complete, resulting in various bugs. Let's defer freeing the reuseport cBPF prog after one RCU grace period. Note "e"BPF prog is safe as is unless the fast path starts to touch fields destroyed in bpf_prog_put_deferred() and __bpf_prog_put_noref(). [0]: BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 Read of size 4 at addr ffffc9000051e004 by task slowme/10208 CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6181 [inline] __netif_receive_skb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napi_poll+0xae/0x340 net/core/dev.c:7709 napi_poll net/core/dev.c:7772 [inline] net_rx_action+0x5d7/0xf50 net/core/dev.c:7929 handle_softirqs+0x22b/0x870 kernel/softirq.c:622 do_softirq+0x76/0xd0 kernel/softirq.c:523 __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip_output+0x29f/0x450 net/ipv4/ip_output.c:438 ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508 udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195 udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x415a2d Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d RDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003 RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000212 R12: 00007f6bc31e46c0 R13: ffffffffffffffb8 R14: 0000000000000000 R15: 00007ffc9b0d70b0 Fixes: 538950a1b752 ("soreuseport: setsockopt SO_ATTACH_REUSEPORT_[CE]BPF") Reported-by: Eulgyu Kim Reported-by: Taeyang Lee <0wn@theori.io> Signed-off-by: Kuniyuki Iwashima Signed-off-by: Daniel Borkmann Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20260426012647.3233119-1-kuniyu@google.com Signed-off-by: Sasha Levin commit b0ffe362d9f8fe04afea146b6496c05d931c4ab1 Author: Alexandre Frade Date: Tue Jun 9 15:46:42 2026 +0000 Linux 6.18.35-rt-xanmod1 Signed-off-by: Alexandre Frade commit a42985600ae2c510bac1afc79692c7b7b0ceb3a0 Merge: dbbf2fd18057 da2d87f71ae2 Author: Alexandre Frade Date: Tue Jun 9 15:44:54 2026 +0000 Merge branch '6.18' into 6.18-rt commit da2d87f71ae2f444fce22bc7caa1bcc43c375efb Author: Alexandre Frade Date: Tue Jun 9 15:42:43 2026 +0000 Linux 6.18.35-xanmod1 Signed-off-by: Alexandre Frade commit f718432d2e3a8b0bd91efd58c58564cb5784668b Merge: 599f0b059dab acb7cf4c1184 Author: Alexandre Frade Date: Tue Jun 9 15:41:43 2026 +0000 Merge tag 'v6.18.35' into 6.18 This is the 6.18.35 stable release commit acb7cf4c1184e27622be0faf89244d5001ed1e87 Author: Greg Kroah-Hartman Date: Tue Jun 9 12:28:53 2026 +0200 Linux 6.18.35 Link: https://lore.kernel.org/r/20260607095727.528828913@linuxfoundation.org Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Wentao Guan Tested-by: Ron Economos Tested-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit 918450ad6010df6ecd2efde12a1409e011da22d6 Author: Hyunwoo Kim Date: Fri Jun 5 17:27:01 2026 +0900 KVM: arm64: Reassign nested_mmus array behind mmu_lock commit 70543358fa08e0f7cebc3447c3b70fe97ad7aaa8 upstream. kvm->arch.nested_mmus[] is walked under kvm->mmu_lock, including from the MMU notifier path (kvm_unmap_gfn_range() -> kvm_nested_s2_unmap()), which can run at any time. kvm_vcpu_init_nested() reallocates the array and frees the old buffer while holding only kvm->arch.config_lock, so such a walker can reference the freed array. Allocate the new array outside of mmu_lock, as the allocation can sleep. Under the lock, copy the existing entries, fix up the back pointers and reassign the array. Free the old buffer after dropping the lock, as kvfree() can sleep as well. Fixes: 4f128f8e1aaac ("KVM: arm64: nv: Support multiple nested Stage-2 mmu structures") Signed-off-by: Hyunwoo Kim Reviewed-by: Oliver Upton Link: https://patch.msgid.link/aiKIVVeIr1aAB1yp@v4bel Signed-off-by: Marc Zyngier Cc: stable@vger,kernel.org Signed-off-by: Greg Kroah-Hartman commit 2bbc395e81bd29c543a0529a678327e932a7ec69 Author: Hyunwoo Kim Date: Mon Jun 1 23:53:26 2026 +0900 KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry commit 13031fb6b8357fbbcded2a7f4cba73e4781ee594 upstream. vgic_its_invalidate_cache() walks the per-ITS translation cache with xa_for_each() and drops the cache's reference on each entry with vgic_put_irq(). It puts the iterated pointer, though, rather than the value returned by xa_erase(). The function is called from contexts that do not exclude one another: the ITS command handlers hold its_lock, the GITS_CTLR write path holds cmd_lock, and the path that clears EnableLPIs in a redistributor's GICR_CTLR holds neither. Two or more of them can drain the same cache concurrently, and if each one observes the same entry, erases it and then puts it, the single reference the cache holds on that entry is dropped more than once. The entry can then be freed while an ITE still maps it. xa_erase() is atomic and returns the previous entry, so put only the entry that this context actually removed. The cache reference is then dropped exactly once per entry even when the invalidations run concurrently, and the behavior is unchanged when only one context runs. Fixes: 8201d1028caa ("KVM: arm64: vgic-its: Maintain a translation cache per ITS") Signed-off-by: Hyunwoo Kim Reviewed-by: Oliver Upton Link: https://patch.msgid.link/ah2c5lu4JbUg7dj-@v4bel Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit adc6fc240a612611283cd537d15cb5cf0369a7e6 Author: Jakub Kicinski Date: Sun May 10 12:29:01 2026 -0700 tools: ynl: add scope qualifier for definitions commit fbf5df34a4dbcd09d433dd4f0916bf9b2ddb16de upstream. Using definitions in kernel policies is awkward right now. On one hand we want defines for max values and such. On the other we don't have a way of adding kernel-only defines. Adding unnecessary defines to uAPI is a bad idea, we won't be able to delete them. And when it comes to policy user space should just query it via the policy dump, not use hard coded defines. Add a "scope" property to definitions, which will let us tell the codegen that a definition is for kernel use only. Support following values: - uapi: render into the uAPI header (default, today's behavior) - kernel: render to kernel header only - user: same as kernel but for the user-side generated header Definitions may have a header property (definition is "external", provided by existing header). Extend the scope to headers, too. If definition has both scope and header properties we will only generate the includes in the right scope. Signed-off-by: Jakub Kicinski Link: https://patch.msgid.link/20260510192904.3987113-8-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit f54b30f3316a7d45be25a2abfb3359db89e78cd5 Author: Michal Pecio Date: Mon May 18 07:31:21 2026 +0200 usb: core: Fix SuperSpeed root hub wMaxPacketSize commit d1e280334b7f0a1df441e08bd1f6a1bcc36b3bbb upstream. There is no good reason to have wBytesPerInterval < wMaxPacketSize - either one is too low or the other too high, and we may want to warn about such descriptors. Start with cleaning up our own root hubs. USB 3.2 section 10.15.1 sets wMaxPacketSize and wBytesPerInterval of SuperSpeed hub status endpoints at 2 bytes, so reduce wMaxPacketSize from its former value of 4, which was derived from USB 2.0 spec and the kernel's USB_MAXCHILDREN limit. They don't apply because USB 3.2 10.15.2.1 specifies SuperSpeed hubs to have up to 15 ports. Suggested-by: Mathias Nyman Signed-off-by: Michal Pecio Link: https://patch.msgid.link/20260518073121.7bc1da0f.michal.pecio@gmail.com Signed-off-by: Greg Kroah-Hartman commit 830c8a9b467e7d3a158483d37fa7dc13892b293a Author: Michael Bommarito Date: Fri Jun 5 15:30:29 2026 -0400 thunderbolt: property: Cap recursion depth in __tb_property_parse_dir() [ Upstream commit 928abe19fbf0127003abcb1ea69cabc1c897d0ab ] A DIRECTORY entry's value field is used as the dir_offset for a recursive call into __tb_property_parse_dir() with no depth counter. A crafted peer that chains DIRECTORY entries into a back-reference loop drives the parser until the kernel stack is exhausted and the guard page fires. Any untrusted XDomain peer (cable, dock, in-line inspector, adjacent host) that reaches the PROPERTIES_REQUEST control-plane exchange can trigger this without authentication. Thread a depth counter through tb_property_parse() and __tb_property_parse_dir(), and reject blocks that exceed TB_PROPERTY_MAX_DEPTH = 8. That is comfortably larger than any observed legitimate XDomain layout. Operators who do not need XDomain host-to-host discovery can disable the path entirely with thunderbolt.xdomain=0 on the kernel command line. Fixes: cdae7c07e3e3 ("thunderbolt: Add support for XDomain properties") 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: Mika Westerberg Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 21bfa15a89d888d37e4881d64fc473cb85f4697a Author: Jouni Högander Date: Fri Jun 5 22:18:39 2026 -0400 drm/i915/psr: Use DC_OFF wake reference to block DC6 on vblank enable [ Upstream commit 3549a9649dc7c5fc586ab12f675279283cdcb2a7 ] We are observing following warnings: *ERROR* power well DC_off state mismatch (refcount 0/enabled 1) gen9_dc_off_power_well_enabled is considering target state DC_STATE_DISABLE as DC_OFF power well being enabled. Fix this by using wakeref for the purpose. To achieve this we need to modify notification code as well. Currently it is possible that PSR gets notified vblank enable/disable twice on same status. This is currently not a problem as it is just triggering call to intel_display_power_set_target_dc_state with same target state as a parameter. When using wakeref this becomes a problem due to reference counting. Fix this storing vbank status on last notification and use that to ensure there are no more than one notification with same vblank status. v2: ensure there is no subsequent notifications with same status Fixes: aa451abcffb5 ("drm/i915/display: Prevent DC6 while vblank is enabled for Panel Replay") Cc: # v6.13+ Signed-off-by: Jouni Högander Reviewed-by: Michał Grzelak Link: https://patch.msgid.link/20260520104944.239797-2-jouni.hogander@intel.com (cherry picked from commit 35485ac56d878192a3829a58cb26503125ec7104) Signed-off-by: Tvrtko Ursulin Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 00869f2320dc55f49e36f9677a6ce5c530d67534 Author: Jassi Brar Date: Fri Mar 27 17:00:40 2026 -0500 mailbox: Fix NULL message support in mbox_send_message() commit c58e9456e30c7098cbcd9f04571992be8a2e4e63 upstream. The active_req field serves double duty as both the "is a TX in flight" flag (NULL means idle) and the storage for the in-flight message pointer. When a client sends NULL via mbox_send_message(), active_req is set to NULL, which the framework misinterprets as "no active request". This breaks the TX state machine by: - tx_tick() short-circuits on (!mssg), skipping the tx_done callback and the tx_complete completion - txdone_hrtimer() skips the channel entirely since active_req is NULL, so poll-based TX-done detection never fires. Fix this by introducing a MBOX_NO_MSG sentinel value that means "no active request," freeing NULL to be valid message data. The sentinel is defined in the subsystem-internal mailbox.h so that controller drivers within drivers/mailbox/ can reference it, but it is not exposed to clients outside the subsystem. Fifteen in-tree callers send NULL (doorbell-style IPCs on Qualcomm, Tegra, TI, Xilinx, i.MX, SCMI, and PCC platforms). All were audited for regression: - Most already work around the bug via knows_txdone=true with a manual mbox_client_txdone() call, making the framework's tracking irrelevant. These are unaffected. - Poll-based callers (Xilinx zynqmp/r5) are strictly better off: the poll timer now correctly detects NULL-active channels instead of silently skipping them. - irq-qcom-mpm.c was a pre-existing bug -- the only Qualcomm caller that omitted the knows_txdone + mbox_client_txdone() pattern. Fixed in a companion commit ("irqchip/qcom-mpm: Fix missing mailbox TX done acknowledgment"). - No caller sets both a tx_done callback and sends NULL, nor combines tx_block=true with NULL sends, so the newly reachable callback/completion paths are never exercised. Also update tegra-hsp's flush callback, which directly inspects active_req to wait for the channel to drain: the old "!= NULL" check becomes "!= MBOX_NO_MSG", otherwise flush spins until timeout since the sentinel is non-NULL. The only tradeoff is that 'MBOX_NO_MSG' can not be used as a message by clients. Reported-by: Joonwon Kang Reviewed-by: Douglas Anderson Signed-off-by: Jassi Brar Signed-off-by: Joonwon Kang Signed-off-by: Greg Kroah-Hartman commit 5372f6f10b0a85bb7bbbfd30197f31aa4a21488b Author: Wei-Cheng Chen Date: Thu Jun 4 20:19:07 2026 +0800 xhci: tegra: Fix ghost USB device on dual-role port unplug [ Upstream commit 5a4c828b8b29b47534814ade26d9aee09d5101fc ] When a USB device is unplugged from the dual-role port, the device-mode path in tegra_xhci_id_work() explicitly clears both SS and HS port power via direct hub_control ClearPortFeature(POWER) calls. This preempts the xHCI controller's normal disconnect processing -- PORT_CSC is never generated, the USB core never sees the disconnect, and the device remains in its internal tree as a ghost visible in lsusb. Add an otg_set_port_power flag to control whether the dual-role switch path performs explicit port power management. SoCs that need it (Tegra124 / Tegra210 / Tegra186) set the flag; later SoCs (Tegra194 and beyond) rely on the PHY mode change to handle disconnect naturally and skip all port power calls. Within the port power path, otg_reset_sspi additionally gates the SSPI reset sequence on host-mode entry for SoCs that require it. Flags set per SoC: Tegra124, Tegra186 -> otg_set_port_power Tegra210 -> otg_set_port_power, otg_reset_sspi Tegra194 and later -> (none) [ Backport to 6.18.y: keep the host-mode snapshot in the existing tegra->lock section, retain pm_runtime_mark_last_busy() in the host port-power path, preserve str_on_off(), and resolve context around the SoC ops/Tegra234 entries. ] Fixes: f836e7843036 ("usb: xhci-tegra: Add OTG support") Cc: stable@vger.kernel.org Signed-off-by: Wei-Cheng Chen Link: https://patch.msgid.link/20260505112630.217704-1-weichengc@nvidia.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 58b2c0f096b36a93e1975b6fa7f8d629e6fd9425 Author: Robert Marko Date: Tue Apr 28 15:41:01 2026 +0200 net: phy: micrel: fix LAN8814 QSGMII soft reset [ Upstream commit e027c218c482c6a0ae1948129ccda3b0a2033368 ] LAN8814 QSGMII soft reset was moved into the probe function to avoid triggering it for each of 4 PHY-s in the package. However, that broke QSGMII link between the MAC and PHY on most LAN8814 PHY-s, specificaly for us on the Microchip LAN969x switch. Reading the QSGMII status registers it was visible that lanes were only partially synced. It looks like the reset timing is crucial, so lets move the reset back into the .config_init function but guard it with phy_package_init_once() to avoid it being triggered on each of 4 PHY-s in the package. Change the probe function to use phy_package_probe_once() for coma and PtP setup. Fixes: 96a9178a29a6 ("net: phy: micrel: lan8814 fix reset of the QSGMII interface") Signed-off-by: Robert Marko Link: https://patch.msgid.link/20260428134138.1741253-1-robert.marko@sartura.hr Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 972ea882d4bf7077f6c0bafd9665928ebfc29245 Author: Qing Wang Date: Mon Jun 1 07:05:09 2026 -0400 mm/slub: hold cpus_read_lock around flush_rcu_sheaves_on_cache() [ Upstream commit 67ea9d353d0ba12bdbc9183ff568dead9e949b80 ] flush_rcu_sheaves_on_cache() calls queue_work_on() in a for_each_online_cpu() loop, which requires the cpu to stay online. But cpus_read_lock() is not held in kvfree_rcu_barrier_on_cache() and the set of "online cpus" is subject to change. There are two paths that call flush_rcu_sheaves_on_cache(): // has cpus_read_lock() flush_all_rcu_sheaves() -> flush_rcu_sheaves_on_cache() // no cpus_read_lock() kvfree_rcu_barrier_on_cache() -> flush_rcu_sheaves_on_cache() Fix this by holding cpus_read_lock() in kvfree_rcu_barrier_on_cache(). Why not move cpus_read_lock() from flush_all_rcu_sheaves() into flush_rcu_sheaves_on_cache()? The reason is it would introduce a new lock order (slab_mutex -> cpu_hotplug_lock). The reverse order (cpu_hotplug_lock -> slab_mutex) is established by - cpuhp_setup_state_nocalls(..., slub_cpu_setup, ...) - kmem_cache_destroy() The two orders together would form an AB-BA deadlock. Finally, add lockdep_assert_cpus_held() in flush_rcu_sheaves_on_cache() to catch the same problem in the future. Fixes: 0f35040de593 ("mm/slab: introduce kvfree_rcu_barrier_on_cache() for cache destruction") Cc: Signed-off-by: Qing Wang Link: https://patch.msgid.link/20260512035035.762317-1-wangqing7171@gmail.com Signed-off-by: Vlastimil Babka (SUSE) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 56857385f313efab5bba1bf821223d984b1be671 Author: Abdurrahman Hussain Date: Mon Jun 1 09:53:37 2026 -0400 hwmon: (pmbus/adm1266) serialize GPIO PMBus accesses with pmbus_lock [ Upstream commit bab8c6fb5af8df7e753d196c1262cb78e92ca872 ] adm1266_gpio_get(), adm1266_gpio_get_multiple(), and adm1266_gpio_dbg_show() all issue PMBus reads against the device but none of them take pmbus_lock. The pmbus_core framework holds pmbus_lock around its own multi-transaction sequences (notably the "set PAGE, then read paged register" pattern used by hwmon attributes), so an unlocked GPIO accessor can land between a PAGE write and the subsequent paged read in another thread and corrupt either side's view of the device state machine. Take pmbus_lock at the top of each of the three accessors via the scope-based guard(). The lock is uncontended in the common case and adds only a single mutex round-trip per call. Fixes: d98dfad35c38 ("hwmon: (pmbus/adm1266) Add support for GPIOs") Cc: stable@vger.kernel.org Signed-off-by: Abdurrahman Hussain Reviewed-by: Bartosz Golaszewski Link: https://lore.kernel.org/r/20260518-adm1266-gpio-fixes-v3-6-e425e4f88139@nexthop.ai Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6b94f9f5fe2889c1dab94d9562d08495989252c0 Author: Abdurrahman Hussain Date: Mon Jun 1 08:49:49 2026 -0400 hwmon: (pmbus/adm1266) serialize sequencer_state debugfs read with pmbus_lock [ Upstream commit 4e4af55aaca7f6d7673d5f9889ad0529db86a048 ] adm1266_state_read() backs the sequencer_state debugfs entry and issues an i2c_smbus_read_word_data(client, ADM1266_READ_STATE) against the device without taking pmbus_lock. pmbus_core holds pmbus_lock around its own multi-transaction sequences (notably the "set PAGE, then read paged register" pattern used by hwmon attributes), so an unlocked debugfs reader can land between a PAGE write and the subsequent paged read in another thread. READ_STATE itself is not paged, so it cannot corrupt PAGE in flight, but the same defensive serialisation that applies to the GPIO accessors applies here: any direct device access from outside pmbus_core should be ordered with respect to pmbus_core's own. Take pmbus_lock at the top of adm1266_state_read() via the scope-based guard(). Fixes: ed1ff457e187 ("hwmon: (pmbus/adm1266) add debugfs for states") Cc: stable@vger.kernel.org Signed-off-by: Abdurrahman Hussain Link: https://lore.kernel.org/r/20260518-adm1266-gpio-fixes-v3-8-e425e4f88139@nexthop.ai Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 192516d727741be788a4483c16823be25a0013ba Author: Guenter Roeck Date: Mon Jun 1 08:49:48 2026 -0400 hwmon: (pmbus) Add support for guarded PMBus lock [ Upstream commit 1814f4d3ff358277a5b6957e7f133c2812dc80ec ] Add support for guard(pmbus_lock)() and scoped_guard(pmbus_lock)() to be able to simplify the PMBus code. Also introduce pmbus_lock() as pre-requisite for supporting guard(). Reviewed-by: Sanman Pradhan Signed-off-by: Guenter Roeck Stable-dep-of: 4e4af55aaca7 ("hwmon: (pmbus/adm1266) serialize sequencer_state debugfs read with pmbus_lock") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d8fdf33d6fcfb90cbec26299baf2352c84b2d768 Author: Johan Hovold Date: Thu Jun 4 14:11:33 2026 +0200 USB: serial: mct_u232: fix memory corruption with small endpoint commit 915b36d701950503c4ea0f6e314b10868e59fce3 upstream. The driver overrides the maximum transfer size for a specific device which only accepts 16 byte packets for its 32 byte bulk-out endpoint. Make sure to never increase the maximum transfer size to prevent slab corruption should a malicious device report a smaller endpoint max packet size than expected. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 062dcc0b324afd03b1406f157190804f105718bb Author: Johan Hovold Date: Thu Jun 4 14:07:58 2026 +0200 USB: serial: digi_acceleport: fix memory corruption with small endpoints commit cb3560e8eab1dfa1cac1ed52631adf8ec6ff2cd5 upstream. Add the missing bulk-out buffer size sanity checks to avoid out-of-bounds memory accesses or slab corruption should a malicious device report smaller buffers than expected. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 284105c40fc31fff90cdab8a0377aaeb92f87f0e Author: Johan Hovold Date: Thu Jun 4 10:36:36 2026 +0200 USB: serial: cypress_m8: fix memory corruption with small endpoint commit e1a9d791fd66ab2431b9e6f6f835823809869047 upstream. Make sure that the interrupt-out endpoint max packet size is at least eight bytes to avoid user-controlled slab corruption or NULL-pointer dereference should a malicious device report a smaller size. Fixes: 3416eaa1f8f8 ("USB: cypress_m8: Packet format is separate from characteristic size") Cc: stable@vger.kernel.org # 2.6.26 Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold [ johan: adjust context for 6.18 ] Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit c73c62a4bd52d9e3b2b0558f934dc136e8f9ca5e Author: Radhey Shyam Pandey Date: Fri Jun 5 09:39:59 2026 -0400 usb: dwc3: xilinx: fix error handling in zynqmp init error paths [ Upstream commit c1a0ecbf32c4b397353204e2ec94c5bb9f3300ed ] Fix error handling and resource cleanup i.e remove invalid phy_exit() after failed phy_init(), route failures through proper cleanup paths and return 0 explicitly on success. Fixes: 84770f028fab ("usb: dwc3: Add driver for Xilinx platforms") Cc: stable@vger.kernel.org Acked-by: Thinh Nguyen Signed-off-by: Radhey Shyam Pandey Link: https://patch.msgid.link/20260519115529.2980421-1-radhey.shyam.pandey@amd.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9327252e04626d4bb02ca8c0c108fbe8eabf0c5a Author: Shaomin Chen Date: Fri Jun 5 08:59:53 2026 -0400 xfrm: iptfs: reset runtime state when cloning SAs [ Upstream commit 7f83d174073234839aea176f265e517e0d50a1d2 ] iptfs_clone_state() clones the IPTFS mode data with kmemdup(). This copies runtime objects which must not be shared with the original SA, including the embedded sk_buff_head, hrtimers, spinlock, and in-flight reassembly/reorder state. If xfrm_state_migrate() fails after clone_state() but before the later init_state() call has reinitialized those fields, the cloned state can be destroyed by xfrm_state_gc_task() with list and timer state copied from the original SA. With queued packets this lets the clone splice and free skbs owned by the original IPTFS queue, leading to use-after-free and double-free reports in iptfs_destroy_state() and skb release paths. Reinitialize the clone's runtime state before publishing it through x->mode_data. Because clone_state() now publishes a destroyable mode_data object before init_state(), take the mode callback module reference there. Avoid taking it again from __iptfs_init_state() for the same object. Fixes: 0e4fbf013fa5 ("xfrm: iptfs: add user packet (tunnel ingress) handling") Cc: stable@vger.kernel.org Signed-off-by: Shaomin Chen Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bb50838a2a0679642b10455335b8b4f43ab5b011 Author: Rafael J. Wysocki Date: Mon Jun 1 07:02:04 2026 -0400 cpufreq: intel_pstate: Use correct scaling factor on Raptor Lake-E [ Upstream commit 0e7c710478b3089cdfe8669347f77b163e836c4f ] Raptor Lake-E has the same processor ID as Raptor Lake-S, so there is an entry in intel_hybrid_scaling_factor[] for it. It does not contain E-cores though and hybrid_get_cpu_type() returns 0 for its P-cores, so they get the default "core" scaling factor. However, the original Raptor Lake scaling factor for P-cores still needs to be used for mapping the HWP performance levels of the P-cores in Raptor Lake-E to frequency, as though they were part of a real hybrid system. To address this, update hwp_get_cpu_scaling() to return hybrid_scaling_factor, which is the P-core scaling factor retrieved from intel_hybrid_scaling_factor[], for all CPUs that are not enumerated as E-cores. Fixes: 9b18d536b124 ("cpufreq: intel_pstate: Use CPPC to get scaling factors") Link: https://lore.kernel.org/all/20260511235328.2018458-1-srinivas.pandruvada@linux.intel.com/ Reported-by: Henry Tseng Closes: https://lore.kernel.org/linux-pm/20260508063032.3248602-1-henrytseng@qnap.com/ Signed-off-by: Rafael J. Wysocki Cc: All applicable Link: https://patch.msgid.link/4523296.ejJDZkT8p0@rafael.j.wysocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7cb2daed350940bfc927e4ac894a4e4e507309e3 Author: Rafael J. Wysocki Date: Mon Jun 1 07:02:03 2026 -0400 cpufreq: intel_pstate: Add and use hybrid_get_cpu_type() [ Upstream commit 528dde6619677ac6dc26d9dda1e3c9014b4a08c8 ] Introduce a function for identifying the type of a given CPU in a hybrid system, called hybrid_get_cpu_type(), and use if for hybrid scaling factor determination in hwp_get_cpu_scaling(). Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/1954386.tdWV9SEqCh@rafael.j.wysocki Stable-dep-of: 0e7c710478b3 ("cpufreq: intel_pstate: Use correct scaling factor on Raptor Lake-E") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8f72a2509163ae24a9aff1f269a9ff481ee273c8 Author: Paolo Abeni Date: Sat May 30 07:48:24 2026 -0400 mptcp: reset rcv wnd on disconnect [ Upstream commit 0981f90e1a05773a4c29c6e720f5ea1e3c8f1876 ] If the MPTCP socket fallback to TCP before the MP handshake completion, the IASN remain 0, and the rcv_wnd_sent field is not explicitly initialized, just incremented over time with the data transfer. At disconnect time such value is not cleared. If the next connection falls back to TCP before the MP handshake completion, the data transfer will keep incrementing the receive window end sequence starting from the last value used in the previous connection: the announced window will be unrelated from the actual receiver buffer size and likely too big. Address the issue zeroing the field at disconnect time. Fixes: b29fcfb54cd7 ("mptcp: full disconnect implementation") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260515-net-mptcp-misc-fixes-7-1-rc4-v2-4-701e96419f2f@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 82e742b9d2cc75721999e6e084155c855695edc7 Author: Paolo Abeni Date: Sat May 30 07:48:23 2026 -0400 mptcp: cleanup fallback dummy mapping generation [ Upstream commit 2834f8edd74d5dda368087a654c0e52b141e9893 ] MPTCP currently access ack_seq outside the msk socket log scope to generate the dummy mapping for fallback socket. Soon we are going to introduce backlog usage and even for fallback socket the ack_seq value will be significantly off outside of the msk socket lock scope. Avoid relying on ack_seq for dummy mapping generation, using instead the subflow sequence number. Note that in case of disconnect() and (re)connect() we must ensure that any previous state is re-set. Signed-off-by: Paolo Abeni Reviewed-by: Geliang Tang Tested-by: Geliang Tang Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20251121-net-next-mptcp-memcg-backlog-imp-v1-6-1f34b6c1e0b1@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: 0981f90e1a05 ("mptcp: reset rcv wnd on disconnect") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0d9b9d7dbef976ae7f855b6358f1d703014e96ea Author: Dawei Feng Date: Sat May 30 12:52:02 2026 -0400 octeontx2-pf: avoid double free of pool->stack on AQ init failure [ Upstream commit 9b244c242bec48b37e82b89787afd6a4c43457e1 ] otx2_pool_aq_init() frees pool->stack when mailbox sync or retry allocation fails, but leaves the pointer unchanged. Later, otx2_sq_aura_pool_init() unwinds the partial setup through otx2_aura_pool_free(), which frees pool->stack again. The CN20K-specific cn20k_pool_aq_init() implementation has the same bug in its corresponding error path. Set pool->stack to NULL immediately after the local free so the shared cleanup path does not free the same stack again while cleaning up partially initialized pool state. 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-rc3. Runtime validation was not performed because reproducing this path requires OcteonTX2/CN20K hardware. Fixes: caa2da34fd25 ("octeontx2-pf: Initialize and config queues") Fixes: d322fbd17203 ("octeontx2-pf: Initialize cn20k specific aura and pool contexts") Cc: stable@vger.kernel.org Signed-off-by: Zilin Guan Signed-off-by: Dawei Feng Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260515151826.1005397-1-dawei.feng@seu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fe93e907b1af03cc229a80aa64a570a103d2b279 Author: Zeng Heng Date: Sun May 31 20:38:49 2026 -0400 arm64: tlb: Flush walk cache when unsharing PMD tables [ Upstream commit c2ff4764e03e7a8d758352f4aceb8fe1be6ac971 ] When huge_pmd_unshare() is called to unshare a PMD table, the tlb_unshare_pmd_ptdesc() function sets tlb->unshared_tables=true but the aarch64 tlb_flush() only checked tlb->freed_tables to determine whether to use TLBF_NONE (vae1is, invalidates walk cache) or TLBF_NOWALKCACHE (vale1is, leaf-only). This caused the stale PMD page table entry to remain in the walk cache after unshare, potentially leading to incorrect page table walks. Fix by including unshared_tables in the check, so that when unsharing tables, TLBF_NONE is used and the walk cache is properly invalidated. Here is the detailed distinction between vae1is and vale1is: | Instruction Combination | Actual Invalidation Scope | | ------------------------ | --------------------------------------------------| | `VAE1IS` + TTL=`0` | All entries at all levels (full invalidation) | | `VAE1IS` + TTL=`2` (L2) | Non-leaf at Level 0/1 + leaf at Level 2 | | `VALE1IS` + TTL=`0` | Leaf entries at all levels (non-leaf not cleared) | | `VALE1IS` + TTL=`2` (L2) | Leaf entry at Level 2 only | Signed-off-by: Zeng Heng Fixes: 8ce720d5bd91 ("mm/hugetlb: fix excessive IPI broadcasts when unsharing PMD tables using mmu_gather") Cc: Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bb37498a99e4e3a25a47265785979402dd79de30 Author: Shardul Bankar Date: Sat May 30 07:48:10 2026 -0400 mptcp: do not drop partial packets [ Upstream commit 50c2d91c5dfa0e465826ec1f8dbad9cdc254bd85 ] When a packet arrives with map_seq < ack_seq < end_seq, the beginning of the packet has already been acknowledged but the end contains new data. Currently the entire packet is dropped as "old data," forcing the sender to retransmit. Instead, skip the already-acked bytes by adjusting the skb offset and enqueue only the new portion. Update bytes_received and ack_seq to reflect the new data consumed. A previous attempt at this fix has been sent by Paolo Abeni [1], but had issues [2]: it also added a zero-window check and changed rcv_wnd_sent initialization, which caused test regressions. This version addresses only the partial packet handling without modifying receive window accounting. Fixes: ab174ad8ef76 ("mptcp: move ooo skbs into msk out of order queue.") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/c9b426a4e163aa3c4fe8b80c79f1a610f47ae7d8.1763075056.git.pabeni@redhat.com [1] Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/600 [2] Signed-off-by: Shardul Bankar [pabeni@redhat.com: update map] Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260515-net-mptcp-misc-fixes-7-1-rc4-v2-1-701e96419f2f@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a84164847b1e0a106ebc46821e5d2f9b775c9dc8 Author: Paolo Abeni Date: Sat May 30 07:48:09 2026 -0400 mptcp: borrow forward memory from subflow [ Upstream commit 9db5b3cec4ec1c0cd3239689f5c8653d691a1754 ] In the MPTCP receive path, we release the subflow allocated fwd memory just to allocate it again shortly after for the msk. That could increases the failures chances, especially when we will add backlog processing, with other actions could consume the just released memory before the msk socket has a chance to do the rcv allocation. Replace the skb_orphan() call with an open-coded variant that explicitly borrows, the fwd memory from the subflow socket instead of releasing it. The borrowed memory does not have PAGE_SIZE granularity; rounding to the page size will make the fwd allocated memory higher than what is strictly required and could make the incoming subflow fwd mem consistently negative. Instead, keep track of the accumulated frag and borrow the full page at subflow close time. This allow removing the last drop in the TCP to MPTCP transition and the associated, now unused, MIB. Signed-off-by: Paolo Abeni Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20251121-net-next-mptcp-memcg-backlog-imp-v1-12-1f34b6c1e0b1@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: 50c2d91c5dfa ("mptcp: do not drop partial packets") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c67f986fc02ce7dcf4616a6a3221a25a44ca067f Author: Paolo Abeni Date: Sat May 30 07:48:08 2026 -0400 mptcp: handle first subflow closing consistently [ Upstream commit 0eeb372deebce6c25b9afc09e35d6c75a744299a ] Currently, as soon as the PM closes a subflow, the msk stops accepting data from it, even if the TCP socket could be still formally open in the incoming direction, with the notable exception of the first subflow. The root cause of such behavior is that code currently piggy back two separate semantic on the subflow->disposable bit: the subflow context must be released and that the subflow must stop accepting incoming data. The first subflow is never disposed, so it also never stop accepting incoming data. Use a separate bit to mark the latter status and set such bit in __mptcp_close_ssk() for all subflows. Beyond making per subflow behaviour more consistent this will also simplify the next patch. Signed-off-by: Paolo Abeni Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20251121-net-next-mptcp-memcg-backlog-imp-v1-11-1f34b6c1e0b1@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: 50c2d91c5dfa ("mptcp: do not drop partial packets") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 134c517dfa63203287b2aad6558017f42435a02e Author: David Carlier Date: Fri May 29 19:22:54 2026 -0400 net: devmem: reject dma-buf bind with non-page-aligned size or SG length [ Upstream commit 4eb82ba543421e9e38cc14e4e82058b78850df50 ] net_devmem_bind_dmabuf() trusts dmabuf->size and sg_dma_len() to be PAGE_SIZE multiples without checking: - tx_vec is sized dmabuf->size / PAGE_SIZE, and net_devmem_get_niov_at() only bounds-checks virt_addr < dmabuf->size before indexing tx_vec[virt_addr / PAGE_SIZE]. With size = N*PAGE_SIZE + r (1 <= r < PAGE_SIZE), sendmsg() at iov_base = N*PAGE_SIZE passes the bound check and reads tx_vec[N] -- one past. - owner->area.num_niovs = len / PAGE_SIZE while gen_pool_add_owner() covers the full byte len, so a non-page-multiple non-final sg desyncs num_niovs from the gen_pool region for every later sg, on both RX and TX. dma-buf does not require page-aligned sizes, so the bind path has to enforce what its own indexing assumes. Reject both with -EINVAL. The size check is TX-only (only tx_vec is sized off dmabuf->size); the SG-length check covers both directions. Fixes: bd61848900bf ("net: devmem: Implement TX path") Cc: stable@vger.kernel.org Signed-off-by: David Carlier Reviewed-by: Bobby Eshleman Acked-by: Stanislav Fomichev Reviewed-by: Mina Almasry Link: https://patch.msgid.link/20260519203530.66310-1-devnexen@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b2beed6ad14937966768aa8e423ea7cabe298037 Author: Matthieu Baerts (NGI0) Date: Fri May 29 20:20:38 2026 -0400 selftests: mptcp: drop nanoseconds width specifier [ Upstream commit 01ff78e4b3d98689184c52d97f9575dfbdc3b10f ] Using the format specifier +%s%3N with GNU date is honoured, and only prints 3 digits of the nanoseconds portion of the seconds since epoch, which corresponds to the milliseconds. The uutils implementation of date currently does not honour this, and always prints all 9 digits. This is a known issue [1], but can be worked around by adapting this test to use nanoseconds instead of microseconds, and then divide it by 1e6. This fix is similar to what has been done on systemd side [2], and it is needed to run the selftests on Ubuntu 26.04, containing uutils 0.8.0. Note that the Fixes tag is there even if this patch doesn't fix an issue in the kernel selftests, but it is useful for those using uutils 0.8.0. Fixes: 048d19d444be ("mptcp: add basic kselftest for mptcp") Cc: stable@vger.kernel.org Link: https://github.com/uutils/coreutils/issues/11658 [1] Link: https://github.com/systemd/systemd/pull/41627 [2] Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260515-net-mptcp-misc-fixes-7-1-rc4-v2-6-701e96419f2f@kernel.org Signed-off-by: Paolo Abeni [ kept `timeout ${timeout_test}` wrapper in do_transfer() ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c5e7d4865292459ba216b12001b70577da0efc4b Author: Shuai Zhang Date: Fri May 29 15:23:50 2026 -0400 Bluetooth: hci_qca: Convert timeout from jiffies to ms [ Upstream commit 375ba7484132662a4a8c7547d088fb6275c00282 ] Since the timer uses jiffies as its unit rather than ms, the timeout value must be converted from ms to jiffies when configuring the timer. Otherwise, the intended 8s timeout is incorrectly set to approximately 33s. To improve readability, embed msecs_to_jiffies() directly in the macro definitions and drop the _MS suffix from macros that now yield jiffies values: MEMDUMP_TIMEOUT, FW_DOWNLOAD_TIMEOUT, IBS_DISABLE_SSR_TIMEOUT, CMD_TRANS_TIMEOUT, and IBS_BTSOC_TX_IDLE_TIMEOUT. IBS_WAKE_RETRANS_TIMEOUT_MS and IBS_HOST_TX_IDLE_TIMEOUT_MS are intentionally left unchanged. Their values are stored in the struct fields wake_retrans and tx_idle_delay, which hold ms values at runtime and can be modified via debugfs. The msecs_to_jiffies() conversion happens at each call site against the field value, so it cannot be embedded in the macro. Wake timer depends on commit c347ca17d62a Cc: stable@vger.kernel.org Fixes: d841502c79e3 ("Bluetooth: hci_qca: Collect controller memory dump during SSR") Reviewed-by: Paul Menzel Acked-by: Bartosz Golaszewski Signed-off-by: Shuai Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8264178afb5c874ed986245e026d6629427d638b Author: Uwe Kleine-König Date: Fri May 29 15:23:49 2026 -0400 Bluetooth: hci_qca: Migrate to serdev specific shutdown function [ Upstream commit 12a6a5726c515455935982429ac35dee2307233d ] This saves a cast in the driver. The motivation is stop using the callback .shutdown in qca_serdev_driver.driver to make it possible to drop that. Signed-off-by: Uwe Kleine-König Link: https://patch.msgid.link/261a3384e25c4837d4efee87958805f15d7d4e3c.1765526117.git.u.kleine-koenig@baylibre.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 375ba7484132 ("Bluetooth: hci_qca: Convert timeout from jiffies to ms") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0acba63d7d462e87d362f650e79b9475d1ec703a Author: Uwe Kleine-König Date: Fri May 29 15:23:48 2026 -0400 serdev: Provide a bustype shutdown function [ Upstream commit 6d71c62b13c33ea858ab298fe20beaec5736edc7 ] To prepare serdev driver to migrate away from struct device_driver::shutdown (and then eventually remove that callback) create a serdev driver shutdown callback and migration code to keep the existing behaviour. Note this introduces a warning for each driver at register time that isn't converted yet to that callback. Signed-off-by: Uwe Kleine-König Link: https://patch.msgid.link/ab518883e3ed0976a19cb5b5b5faf42bd3a655b7.1765526117.git.u.kleine-koenig@baylibre.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 375ba7484132 ("Bluetooth: hci_qca: Convert timeout from jiffies to ms") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8bf7dbb741dde2e97f85816d2db0e6e1dc6b49c0 Author: David Howells Date: Fri May 29 14:35:08 2026 -0400 rxrpc: Fix RESPONSE packet verification to extract skb to a linear buffer [ Upstream commit 8bfab4b6ffc2fe92da86300728fc8c3c7ebffb56 ] This improves the fix for CVE-2026-43500. Fix the verification of RESPONSE packets to avoid the problem of overwriting a RESPONSE packet sent via splice to a local address by extracting the contents of the UDP packet into a kmalloc'd linear buffer rather than decrypting the data in place in the sk_buff (which may corrupt the original buffer). Fixes: 24481a7f5733 ("rxrpc: Fix conn-level packet handling to unshare RESPONSE packets") Reported-by: Hyunwoo Kim Closes: https://lore.kernel.org/r/afKV2zGR6rrelPC7@v4bel/ Signed-off-by: David Howells cc: Simon Horman cc: Jiayuan Chen cc: linux-afs@lists.infradead.org cc: stable@kernel.org Reviewed-by: Jeffrey Altman Tested-by: Marc Dionne Link: https://patch.msgid.link/20260515230516.2718212-4-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 46cb765e2e5ad52303ea157e10d370bb6b7acbbf Author: David Howells Date: Fri May 29 14:35:07 2026 -0400 rxrpc: Fix DATA decrypt vs splice() by copying data to buffer in recvmsg [ Upstream commit d2bc90cf6c75cb96d2ce549be6c35efa3099d25b ] This improves the fix for CVE-2026-43500. Fix the pagecache corruption from in-place decryption of a DATA packet transmitted locally by splice() by getting rid of the packet sharing in the I/O thread and unconditionally extracting the packet content into a bounce buffer in which the buffer is decrypted. recvmsg() (or the kernel equivalent) then copies the data from the bounce buffer to the destination buffer. The sk_buff then remains unmodified. This has an additional advantage in that the packet is then arranged in the buffer with the correct alignment required for the crypto algorithms to process directly. The performance of the crypto does seem to be a little faster and, surprisingly, the unencrypted performance doesn't seem to change much - possibly due to removing complexity from the I/O thread. Yet another advantage is that the I/O thread doesn't have to copy packets which would slow down packet distribution, ACK generation, etc.. The buffer belongs to the call and is allocated initially at 2K, sufficiently large to hold a whole jumbo subpacket, but the buffer will be increased in size if needed. However, to take this work, MSG_PEEK may cause a later packet to be decrypted into the buffer, in which case the earlier one will need re-decrypting for a subsequent recvmsg(). Note that rx_pkt_offset may legitimately see 0 as a valid offset now, so switch to using USHRT_MAX to indicate an invalid offset. Note also that I would generally prefer to replace the buffers of the current sk_buff with a new kmalloc'd buffer of the right size, ditching the old data and frags as this makes the handling of MSG_PEEK easier and removes the re-decryption issue, but this looks like quite a complicated thing to achieve. skb_morph() looks half way to what I want, but I don't want to have to allocate a new sk_buff. Fixes: d0d5c0cd1e71 ("rxrpc: Use skb_unshare() rather than skb_cow_data()") Reported-by: Hyunwoo Kim Closes: https://lore.kernel.org/r/afKV2zGR6rrelPC7@v4bel/ Signed-off-by: David Howells cc: Simon Horman cc: Jiayuan Chen cc: linux-afs@lists.infradead.org Reviewed-by: Jeffrey Altman Tested-by: Marc Dionne Link: https://patch.msgid.link/20260515230516.2718212-3-dhowells@redhat.com Signed-off-by: Jakub Kicinski Stable-dep-of: 8bfab4b6ffc2 ("rxrpc: Fix RESPONSE packet verification to extract skb to a linear buffer") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fed725cace3ab1c4f7f8182e35029a603d953187 Author: Tom Lendacky Date: Fri May 29 14:07:46 2026 -0400 x86/mm: Disable broadcast TLB flush when PCID is disabled [ Upstream commit 44126343d58c68adaa8343fbf1c07dd20078c35e ] Booting with "nopcid" clears X86_FEATURE_PCID and keeps CR4.PCIDE from being set to one. On AMD CPUs that support INVLPGB, broadcast TLB flushing remains enabled. There are two checks that decide whether the global ASID code runs, mm_global_asid() and consider_global_asid(), that key off of the X86_FEATURE_INVLPGB feature. Once an mm becomes active on more than three CPUs, consider_global_asid() assigns it a global ASID, after which flush_tlb_mm_range() takes the broadcast_tlb_flush() path using a non-zero PCID. Issuing an INVLPGB with a non-zero PCID while CR4.PCIDE is not set results in a #GP: Oops: general protection fault, kernel NULL pointer dereference 0x1: 0000 [#1] SMP NOPTI CPU: 158 UID: 0 PID: 3119 Comm: snap Not tainted 7.1.0-rc3 #1 PREEMPT(full) Hardware name: ... RIP: 0010:broadcast_tlb_flush Code: ... 89 da 48 83 c8 07 <0f> 01 fe eb 08 cc cc cc ... Call Trace: flush_tlb_mm_range ptep_clear_flush wp_page_copy ? _raw_spin_unlock __handle_mm_fault handle_mm_fault do_user_addr_fault exc_page_fault asm_exc_page_fault All processors that support broadcast TLB invalidation also have PCID support, so it is only the "nopcid" scenario that is of concern. In this situation just disable the broadcast TLB support using the CPUID dependency support by making X86_FEATURE_INVLPGB dependent on X86_FEATURE_PCID. [ bp: Massage commit message. ] Fixes: 4afeb0ed1753 ("x86/mm: Enable broadcast TLB invalidation for multi-threaded processes") Suggested-by: Dave Hansen Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Tom Lendacky Signed-off-by: Borislav Petkov (AMD) Acked-by: Rik van Riel Cc: Link: https://patch.msgid.link/b915acfd63e8b2a094fdeb8dc608738072518764.1779296450.git.thomas.lendacky@amd.com [ adjusted insertion point to after X86_FEATURE_SPEC_CTRL_SSBD ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 81181a39bde9ad5b44a1b2d68702da6a8c84a565 Author: Lukas Wunner Date: Fri May 29 12:59:26 2026 -0400 platform/x86/intel/vsec: Fix enable_cnt imbalance on PCIe error recovery [ Upstream commit 348ccc754d8939e21ca5956ff45720b81d6e407f ] After a PCIe Uncorrectable Error has been reported by a device with Intel Vendor Specific Extended Capabilities and has been recovered through a Secondary Bus Reset, its driver calls intel_vsec_pci_probe() to rescan and reinitialize VSECs. intel_vsec_pci_probe() invokes pcim_enable_device() and thereby adds another devm action which calls pcim_disable_device() on driver unbind. So once the driver unbinds, pcim_disable_device() will be called as many times as an Uncorrectable Error occurred, plus one. This will lead to an enable_cnt imbalance on driver unbind. Additionally, since commit dc957ab6aa05 ("platform/x86/intel/vsec: Add private data for per-device data"), a devm_kzalloc() allocation is leaked on every Uncorrectable Error. Avoid by splitting the VSEC rescan out of intel_vsec_pci_probe() into a separate helper and calling that on PCIe error recovery. Fixes: 936874b77dd0 ("platform/x86/intel/vsec: Add PCI error recovery support to Intel PMT") Signed-off-by: Lukas Wunner Cc: stable@vger.kernel.org # v6.0+ Link: https://patch.msgid.link/bd594d09fa866dc51dddc9a447c3b23f9b1402cc.1778736835.git.lukas@wunner.de Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1730c91a8b9a319e272558a40be08b4d936f4078 Author: David E. Box Date: Fri May 29 12:59:25 2026 -0400 platform/x86/intel/vsec: Make driver_data info const [ Upstream commit 9577c74c96f88d807d1ba005adbf5952e7127e55 ] Treat PCI id->driver_data (intel_vsec_platform_info) as read-only by making vsec_priv->info a const pointer and updating all function signatures to accept const intel_vsec_platform_info *. This improves const-correctness and clarifies that the platform info data from the driver_data table is not meant to be modified at runtime. No functional changes intended. Signed-off-by: David E. Box Reviewed-by: Michael J. Ruhl Link: https://patch.msgid.link/20260313015202.3660072-3-david.e.box@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Stable-dep-of: 348ccc754d89 ("platform/x86/intel/vsec: Fix enable_cnt imbalance on PCIe error recovery") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4b0e87f9b50ff5136228b3c30dee6b399c9b473f Author: David E. Box Date: Fri May 29 12:59:24 2026 -0400 platform/x86/intel/vsec: Refactor base_addr handling [ Upstream commit 904b333fc51cc045941df9656302449a0fc9978e ] The base_addr field in intel_vsec_platform_info was originally added to support devices that emulate PCI VSEC capabilities in MMIO. Previously, the code would check at registration time whether base_addr was set, falling back to the PCI BAR if not. Refactor this by making base_addr an explicit function parameter. This clarifies ownership of the value and removes conditional logic from intel_vsec_add_dev(). It also enables making intel_vsec_platform_info const in a later patch, since the function no longer needs to write to info->base_addr. No functional change intended. Signed-off-by: David E. Box Reviewed-by: Michael J. Ruhl Link: https://patch.msgid.link/20260313015202.3660072-2-david.e.box@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Stable-dep-of: 348ccc754d89 ("platform/x86/intel/vsec: Fix enable_cnt imbalance on PCIe error recovery") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 71b88acec0a7142964b1a2b77faa5c51072244a2 Author: Jacques Nilo Date: Wed May 13 15:30:25 2026 +0200 serial: 8250_dw: dispatch SysRq character in dw8250_handle_irq() commit 2e211723953f7740e54b53f3d3a0d5e351a5e223 upstream. dw8250_handle_irq() calls serial8250_handle_irq_locked() with the port lock held via guard(uart_port_lock_irqsave). The guard destructor is plain uart_port_unlock_irqrestore(), so a SysRq character captured into port->sysrq_ch by uart_prepare_sysrq_char() is dropped without ever being dispatched to handle_sysrq(). This is the same regression pattern as in serial8250_handle_irq(), introduced when 883c5a2bc934 ("serial: 8250_dw: Rework dw8250_handle_irq() locking and IIR handling") moved the function to the guard()-based locking scheme without using the sysrq-aware unlock helper. Switch to guard(uart_port_lock_check_sysrq_irqsave) so that captured sysrq_ch is dispatched on scope exit, matching the fix in serial8250_handle_irq(). Fixes: 883c5a2bc934 ("serial: 8250_dw: Rework dw8250_handle_irq() locking and IIR handling") Cc: stable@vger.kernel.org Reviewed-by: Ilpo Järvinen Signed-off-by: Jacques Nilo Link: https://patch.msgid.link/ed56fcaf4af24e4ed011a7bce206e0182acb761c.1778675349.git.jnilo@free.fr Signed-off-by: Greg Kroah-Hartman commit 7f8b194ed7206bc866d554b9f63f47e11d97c2c0 Author: Jacques Nilo Date: Wed May 13 15:30:24 2026 +0200 serial: 8250: dispatch SysRq character in serial8250_handle_irq() commit 71f42b2149a1307a97165b409493665579462ea0 upstream. serial8250_handle_irq() captures a SysRq character into port->sysrq_ch inside serial8250_handle_irq_locked() via uart_prepare_sysrq_char() (reached from serial8250_read_char()). Dispatch of that captured character to handle_sysrq() is expected to happen at port-unlock time, through uart_unlock_and_check_sysrq[_irqrestore](). After commit 8324a54f604d ("serial: 8250: Add serial8250_handle_irq_locked()") the function was reduced to a wrapper that takes the port lock via guard(uart_port_lock_irqsave) whose destructor is plain uart_port_unlock_irqrestore(). The sysrq-aware unlock helper is no longer called, so port->sysrq_ch is captured but never dispatched: BREAK + SysRq key is consumed silently. This was the very condition Johan Hovold's 853a9ae29e978 ("serial: 8250: fix handle_irq locking", 2021) introduced uart_unlock_and_check_sysrq_irqrestore() to address. Switch to the new guard(uart_port_lock_check_sysrq_irqsave), whose destructor is the sysrq-aware unlock helper, restoring the pre-split behaviour. Update the Context: comment on serial8250_handle_irq_locked() so future HW-specific 8250 wrappers know to use the same guard or the explicit sysrq-aware unlock. Verified on RTL8196E with CONFIG_MAGIC_SYSRQ_SERIAL=y: BREAK + 'h' on the console UART produces the SysRq help dump in dmesg and the brk counter in /proc/tty/driver/serial increments correctly. Fixes: 8324a54f604d ("serial: 8250: Add serial8250_handle_irq_locked()") Cc: stable@vger.kernel.org Reviewed-by: Ilpo Järvinen Signed-off-by: Jacques Nilo Link: https://patch.msgid.link/52692ae6c3501f7940347cef364ad7fcacaab7e5.1778675349.git.jnilo@free.fr Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 5f2172d799f3d47b3e51b50bbe20acaaa4d36e6a Author: Jacques Nilo Date: Wed May 13 15:30:23 2026 +0200 serial: core: introduce guard(uart_port_lock_check_sysrq_irqsave) commit c3cce2e67bb22a223f5b8ef05db0fcde70994068 upstream. uart_handle_break() and uart_prepare_sysrq_char() (in include/linux/serial_core.h) capture a SysRq character into port->sysrq_ch while the port lock is held and rely on the unlock helper -- uart_unlock_and_check_sysrq_irqrestore() -- to dispatch the captured character to handle_sysrq() on scope exit. The existing guard(uart_port_lock_irqsave) cannot be used by IRQ handlers that process RX, because its destructor calls plain uart_port_unlock_irqrestore() and silently drops port->sysrq_ch. Add a dedicated guard(uart_port_lock_check_sysrq_irqsave) variant whose destructor is the sysrq-aware unlock helper. The lock side is identical to uart_port_lock_irqsave -- only the unlock-time behaviour differs. Callers that may capture SysRq characters must use guard(uart_port_lock_check_sysrq_irqsave); the existing guard(uart_port_lock_irqsave) keeps its current plain-unlock semantics for the many callers that do not process RX. The new macro is placed after the CONFIG_MAGIC_SYSRQ_SERIAL block so both definitions of uart_unlock_and_check_sysrq_irqrestore() (sysrq enabled and disabled) are visible at expansion time. When CONFIG_MAGIC_SYSRQ_SERIAL=n the destructor degenerates to plain uart_port_unlock_irqrestore(), so there is no overhead. No functional change on its own; users are converted in the following patches. Cc: stable@vger.kernel.org Signed-off-by: Jacques Nilo Reviewed-by: Ilpo Järvinen Link: https://patch.msgid.link/3849af4bc55d5d2a424fa850844e94d641b2f8a6.1778675349.git.jnilo@free.fr Signed-off-by: Greg Kroah-Hartman commit 237dc8c08de3cb293b6607aaee8b13b3a671e267 Author: Maciej W. Rozycki Date: Wed May 6 23:42:52 2026 +0100 serial: zs: Convert to use a platform device commit 7cac59d08a73cb866ec51a483a6f3fe0f531947c upstream. Prevent a crash from happening as the first serial port is initialised: Console: switching to mono frame buffer device 160x64 fb0: PMAG-AA frame buffer device at tc0 DECstation Z85C30 serial driver version 0.10 CPU 0 Unable to handle kernel paging request at virtual address 0000002c, epc == 803ab00c, ra == 803aafe0 Oops[#1]: CPU: 0 PID: 1 Comm: swapper Not tainted 6.4.0-rc3-00031-g84a9582fd203-dirty #57 $ 0 : 00000000 10012c00 803aaeb0 00000000 $ 4 : 80e12f60 80e12f50 80e12f58 81000030 $ 8 : 00000000 805ff37c 00000000 33433538 $12 : 65732030 00000006 80c2915d 6c616972 $16 : 80e12f00 807b7630 00000000 00000000 $20 : 00000004 00000348 000001a0 807623b8 $24 : 00000018 00000000 $28 : 80c24000 80c25d60 8078b148 803aafe0 Hi : 00000000 Lo : 00000000 epc : 803ab00c serial_base_ctrl_add+0x78/0xf4 ra : 803aafe0 serial_base_ctrl_add+0x4c/0xf4 Status: 10012c03 KERNEL EXL IE Cause : 00000008 (ExcCode 02) BadVA : 0000002c PrId : 00000440 (R4400SC) Modules linked in: Process swapper (pid: 1, threadinfo=(ptrval), task=(ptrval), tls=00000000) Stack : 80760000 00000cc0 00400044 00400040 803aa02c 80d61ab8 00000000 807b7630 80760000 807623b8 807b7628 803aa644 80386998 00000000 80e17780 80220f68 80e17780 80d61ab8 80c17d80 80e17780 80e17780 8063c798 80e17780 80383fa0 00000010 80e17780 00000000 80386998 807a0000 00000000 00400040 8038f848 807623b8 80d61ab8 00000004 80e17780 00000000 803a68e4 80c25e2c 803bb884 ... Call Trace: [<803ab00c>] serial_base_ctrl_add+0x78/0xf4 [<803aa644>] serial_core_register_port+0x174/0x69c [<8077e9ac>] zs_init+0xc8/0xfc [<800404d4>] do_one_initcall+0x40/0x2ac [<8076cecc>] kernel_init_freeable+0x1e4/0x270 [<80605bec>] kernel_init+0x20/0x108 [<800431e8>] ret_from_kernel_thread+0x14/0x1c Code: 2442aeb0 ae120024 ae0200d0 <8c67002c> 50e00001 8c670000 3c06806e 3c05806e afb30010 ---[ end trace 0000000000000000 ]--- (report at the offending commit) -- where a pointer is dereferenced that has been derived from a null pointer to the port's parent device. Since no device is available with legacy probing and it's not anymore a preferable way to discover devices anyway, switch the driver to using a platform device and use it as the port's parent device. Update resource handling accordingly and only request the actual span of addresses used within the slot, which will have had its resource already requested by generic platform device code. Use platform_driver_probe() not just because SCC devices are fixed with solder on board and not straightforward to remove, but foremost because the associated TTY's major device number is the same as used by the dz driver and the first driver to claim it will prevent the other one from using it. Either one DZ device or some SCC devices will be present in a given system but never both at a time, and therefore we want the major device number to be claimed by the first driver to actually successfully bind to its device and platform_driver_probe() is a way to fulfil that. An unfortunate consequence of the switch to a platform device is we now hand the console over from the bootconsole much later in the bootstrap. The firmware console handler appears good enough though to work so late and in particular with interrupts enabled. Since there is one way only remaining to reach zs_reset() now, remove the port initialisation marker as no longer needed and go through the channel reset unconditionally. Fixes: 84a9582fd203 ("serial: core: Start managing serial controllers to enable runtime PM") Signed-off-by: Maciej W. Rozycki Cc: stable@vger.kernel.org # needs to use .remove_new for <= 6.10 Link: https://patch.msgid.link/alpine.DEB.2.21.2605062328480.46195@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 81984447eac41d0807107234652d9ef28e7a07cc Author: Maciej W. Rozycki Date: Wed May 6 23:42:43 2026 +0100 serial: zs: Switch to using channel reset commit 8572955630f30948837088aa98bcbe0532d1ceac upstream. Switch the driver to using the channel reset rather than hardware reset, simplifying handling by removing an interference between channels that causes the other channel to become uninitialised afterwards. There is little difference between the two kinds of reset in terms of register settings that result, and we initialise the whole register set right away anyway. However this prevents a hang from happening should the console output handler in the firmware try to access the other port whose transmitter has been disabled and line parameters messed up. For example this will happen if the keyboard port (port A) is chosen for the system console, unusually but not insanely for a headless system, as the port is wired to a standard DA-15 connector and an adapter can be easily made. Or with the next change in place this would happen for the regular console port (port B), since the keyboard port (port A) will be initialised first. Just remove the unnecessary complication then, a channel reset is good enough. We still need the initialisation marker, now per channel rather than per SCC, as for the console port zs_reset() will be called twice: once early on via zs_serial_console_init() for the console setup only, and then again via zs_config_port() as the port is associated with a TTY device. Fixes: 8b4a40809e53 ("zs: move to the serial subsystem") Signed-off-by: Maciej W. Rozycki Cc: stable@vger.kernel.org # v2.6.23+ Link: https://patch.msgid.link/alpine.DEB.2.21.2605062323430.46195@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman commit b1ceeaef4fbc5108b4521d30f8ea92b98e440579 Author: Maciej W. Rozycki Date: Wed May 6 23:42:39 2026 +0100 serial: zs: Fix bootconsole handover lockup commit 6c05cf72e13314ce9b770b5951695dc5a2152920 upstream. Calling zs_reset() in the course of setting up the serial device causes line parameters to be reset and the transmitter disabled. We've been lucky in that no message is usually produced to the kernel log between this call and the later call to uart_set_options() in the course of console setup done by zs_serial_console_init(), or the system would hang as the console output handler in the firmware tried to access a port the transmitter of which has been disabled and line parameters messed up. This will change with the next change to the driver, so fix zs_reset() such that line parameters are set for 9600n8 console operation as with the system firmware and the transmitter re-enabled after reset. This also means zs_pm() serves no purpose anymore, so drop it. Fixes: 8b4a40809e53 ("zs: move to the serial subsystem") Signed-off-by: Maciej W. Rozycki Cc: stable@vger.kernel.org # v2.6.23+ Link: https://patch.msgid.link/alpine.DEB.2.21.2605062308040.46195@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman commit 2ff0401ffddaccc85f758c8259912d686d052b31 Author: Maciej W. Rozycki Date: Wed May 6 23:42:48 2026 +0100 serial: dz: Convert to use a platform device commit 5d7a49d60b8fda66da60e240fd7315232fa1754f upstream. Prevent a crash from happening as the first serial port is initialised: Console: switching to colour frame buffer device 160x64 tgafb: SFB+ detected, rev=0x02 fb0: Digital ZLX-E1 frame buffer device at 0x1e000000 DECstation DZ serial driver version 1.04 CPU 0 Unable to handle kernel paging request at virtual address 000000bc, epc == 8048b3a4, ra == 80470a78 Oops[#1]: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.19.0-dirty #35 NONE $ 0 : 00000000 1000ac00 00000004 804707ac $ 4 : 00000000 80e20850 80e20858 81000030 $ 8 : 00000000 8072c81c 00000008 fefefeff $12 : 6c616972 00000006 80c5917f 69726420 $16 : 80e20800 00000000 808f8968 80e20800 $20 : 00000000 807f5a90 808b0094 808d3bc8 $24 : 00000018 80479030 $28 : 80c2e000 80c2fd70 00000069 80470a78 Hi : 00000004 Lo : 00000000 epc : 8048b3a4 __dev_fwnode+0x0/0xc ra : 80470a78 serial_base_ctrl_add+0xa0/0x168 Status: 1000ac04 IEp Cause : 30000008 (ExcCode 02) BadVA : 000000bc PrId : 00000220 (R3000) Modules linked in: Process swapper/0 (pid: 1, threadinfo=(ptrval), task=(ptrval), tls=00000000) Stack : 00400044 00400040 8046f4cc 00000000 808a6148 808a0000 808f8968 8086983c 808e0000 8046fc84 1000ac01 00000028 80e20700 802ba3f8 80e20700 80d34a94 80c1b900 80e20700 80e20700 80e20700 80e20700 80444650 00000000 00000000 00000000 807f5a90 808b0094 80447080 00400040 808e0000 80d34a94 808a6148 80d34a94 00000004 80e20700 00000000 8076974c 80469810 80c2fe3c 1000ac01 ... Call Trace: [<8048b3a4>] __dev_fwnode+0x0/0xc [<80470a78>] serial_base_ctrl_add+0xa0/0x168 [<8046fc84>] serial_core_register_port+0x1c8/0x974 [<808c6af0>] dz_init+0x74/0xc8 [<800470e0>] do_one_initcall+0x44/0x2d4 [<808b111c>] kernel_init_freeable+0x258/0x308 [<8072e434>] kernel_init+0x20/0x114 [<80049cd0>] ret_from_kernel_thread+0x14/0x1c Code: 27bd0018 03e00008 2402ffea <8c8200bc> 03e00008 00000000 27bdffc0 afbe0038 afb30024 ---[ end trace 0000000000000000 ]--- -- where a pointer is dereferenced that has been derived from a null pointer to the port's parent device. Since no device is available with legacy probing and it's not anymore a preferable way to discover devices anyway, switch the driver to using a platform device and use it as the port's parent device. Update resource handling accordingly and only request the actual span of addresses used within the slot, which will have had its resource already requested by generic platform device code. Use platform_driver_probe() not just because the DZ device is fixed with solder on board and not straightforward to remove, but foremost because the associated TTY's major device number is the same as used by the zs driver and the first driver to claim it will prevent the other one from using it. Either one DZ device or some SCC devices will be present in a given system but never both at a time, and therefore we want the major device number to be claimed by the first driver to actually successfully bind to its device and platform_driver_probe() is a way to fulfil that. An unfortunate consequence of the switch to a platform device is we now hand the console over from the bootconsole much later in the bootstrap. The firmware console handler appears good enough though to work so late and in particular with interrupts enabled. Conversely only starting the console port so late lets the reset code fully utilise our delay handlers, so switch from udelay() to fsleep() for transmitter draining so as to avoid busy-waiting for an excessive amount of time. Fixes: 84a9582fd203 ("serial: core: Start managing serial controllers to enable runtime PM") Signed-off-by: Maciej W. Rozycki Cc: stable@vger.kernel.org # needs to use .remove_new for <= 6.10 Link: https://patch.msgid.link/alpine.DEB.2.21.2605062326540.46195@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman commit 2c5b693d918ced53fc096515ff49c196c32dc7fd Author: Maciej W. Rozycki Date: Wed May 6 23:42:35 2026 +0100 serial: dz: Fix bootconsole handover lockup commit 7f127b2208e5e2b817243cad41fe4211a6d5a7a3 upstream. Calling dz_reset() in the course of setting up the serial device causes line parameters to be reset and the transmitter disabled. We've been lucky in that no message is usually produced to the kernel log between this call and the later call to uart_set_options() in the course of console setup done by dz_serial_console_init(), or the system would hang as the console output handler in the firmware tried to access a port the transmitter of which has been disabled and line parameters messed up. This will change with the next change to the driver, so fix dz_reset() such that line parameters are set for 9600n8 console operation as with the system firmware and the transmitter re-enabled after reset. This also means dz_pm() serves no purpose anymore, so drop it. Fixes: e6ee512f5a77 ("dz.c: Resource management") Signed-off-by: Maciej W. Rozycki Cc: stable@vger.kernel.org # v2.6.25+ Link: https://patch.msgid.link/alpine.DEB.2.21.2605062302010.46195@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman commit 24b7be239b0b20beaf56910b53da12a79aea2c58 Author: Maciej W. Rozycki Date: Wed May 6 23:42:31 2026 +0100 serial: dz: Fix bootconsole message clobbering at chip reset commit ca904f4b42355287bc5ce8b7550ebe909cda4c2c upstream. In the DZ interface as implemented by the DC7085 gate array the serial transmitters are double buffered, meaning that at the time a transmitter is ready to accept the next character there is one in the transmit shift register still being sent to the line. Issuing a master clear at this time causes this character to be lost, so wait an extra amount of time sufficient for the transmit shift register to drain at 9600bps, which is the baud rate setting used by the firmware console. Mind the specified 1.4us TRDY recovery time in the course and continue using iob() as the completion barrier, since the platforms involved use a write buffer that can delay and combine writes, and reorder them with respect to reads regardless of the MMIO locations accessed and we still lack a platform-independent handler for that. When called from dz_serial_console_init() this is too early for fsleep() to work and even before lpj has been calculated and therefore the delay is actually not sufficient for the transmitter to drain and is merely a placeholder now. This will be addressed in a follow-up change. Fixes: e6ee512f5a77 ("dz.c: Resource management") Signed-off-by: Maciej W. Rozycki Cc: stable@vger.kernel.org # v2.6.25+ Link: https://patch.msgid.link/alpine.DEB.2.21.2605062259080.46195@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman commit f059b4c493df3e54fe3ffe4658009c31864275da Author: Ziyi Guo Date: Sun Feb 8 00:02:55 2026 +0000 drm/amdgpu: check num_entries in GEM_OP GET_MAPPING_INFO commit a1ba4594232c87c3b8defd6f89a2e40f8b08395d upstream. kvcalloc(args->num_entries, sizeof(*vm_entries), GFP_KERNEL) at amdgpu_gem.c:1050 uses the user-supplied num_entries directly without any upper bounds check. Since num_entries is a __u32 and sizeof(drm_amdgpu_gem_vm_entry) is 32 bytes, a large num_entries produces an allocation exceeding INT_MAX, triggering WARNING in __kvmalloc_node_noprof(), causing a kernel WARNING, TAINT_WARN, and panic on CONFIG_PANIC_ON_WARN=y systems. Add a size bounds check before we invoke the kvzalloc() to reject oversized num_entries early with -EINVAL. Fixes: 4d82724f7f2b ("drm/amdgpu: Add mapping info option for GEM_OP ioctl") Signed-off-by: Ziyi Guo Signed-off-by: Alex Deucher (cherry picked from commit 1fe7bf5457f6efd7be60b17e23163ba54341d73d) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit fa372f4e8aeff6d0d3dd2f14b9165b4013e72a6d Author: Christian König Date: Wed Feb 18 12:31:29 2026 +0100 drm/amdgpu: fix calling VM invalidation in amdgpu_hmm_invalidate_gfx commit 1c824497d8acd3187d585d6187cedc1897dcc871 upstream. Otherwise we don't invalidate page tables on next CS. Signed-off-by: Christian König Reviewed-by: Vitaly Prosyak Tested-by: Vitaly Prosyak Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit b6444d1bcbc34f6f2a31a3aab3059be082f3683e) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 1eb86334e391695d4a40743b114afc15df4dc506 Author: Michael Bommarito Date: Sun May 17 09:17:42 2026 -0400 drm/amdgpu: fix lock leak on ENOMEM in AMDGPU_GEM_OP_GET_MAPPING_INFO commit 2e7f55eb408c3f72ee1957a0d0ad11d8648a6379 upstream. The AMDGPU_GEM_OP_GET_MAPPING_INFO branch of amdgpu_gem_op_ioctl() holds three cleanup-tracked resources before calling kvcalloc(): the drm_gem_object reference from drm_gem_object_lookup(), the drm_exec lock on the looked-up GEM via drm_exec_lock_obj(), and the drm_exec lock on the per-process VM root page directory via amdgpu_vm_lock_pd(). All three are released by the out_exec label that every other error path in this function jumps to. The kvcalloc() failure path returns -ENOMEM directly, skipping out_exec and leaking all three. The leaked per-process VM root PD dma_resv lock is the load-bearing leak: any subsequent operation on the same VM (further GEM ops, command-submission, eviction, TTM shrinker callbacks) blocks on the held lock. DRM_IOCTL_AMDGPU_GEM_OP is DRM_AUTH | DRM_RENDER_ALLOW, so this is an unprivileged-local denial of service against the caller's GPU context, reachable by any process with /dev/dri/renderD* access. Route the failure through out_exec so drm_exec_fini() and drm_gem_object_put() run. Reproduced on stock 7.0.0-10, Ryzen 7 5700U / Radeon Vega (Lucienne): the failing ioctl returns -ENOMEM and a second GET_MAPPING_INFO on the same fd then blocks in drm_exec_lock_obj() on the leaked dma_resv. SIGKILL on the caller does not reap the task; the fd-release path during process exit goes through amdgpu_gem_object_close() -> drm_exec_prepare_obj() on the same lock, leaving the task in D state until the box is rebooted. The patched kernel was not rebuilt and re-tested on this hardware; the fix is mechanical. Tested on a single Lucienne / Vega box only. Ziyi Guo posted an independent INT_MAX-bound check for args->num_entries in the same branch [1]; the two patches are complementary and can land in either order. Fixes: 4d82724f7f2b ("drm/amdgpu: Add mapping info option for GEM_OP ioctl") Link: https://lore.kernel.org/all/20260208000255.4073363-1-n7l8m4@u.northwestern.edu/ # [1] Signed-off-by: Michael Bommarito Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Alex Deucher (cherry picked from commit b69d3256d79de15f54c322986ff4da68f1d65b0a) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 275396bf71c4d30a2a86ccf078f732cc9fe17e26 Author: David Francis Date: Thu May 14 10:31:20 2026 -0400 drm/amdkfd: Check for pdd drm file first in CRIU restore path commit 6842b6a4b72da9b2906ffc5ca9d846ace2c54c14 upstream. CRIU restore ioctls are meant to be called by CRIU with no existing drm file. There's an error path for if the drm file unexpectedly exists. It was positioned so it was missing a fput(drm_file). Do that check earlier, as soon as we have the pdd. Signed-off-by: David Francis Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 2bab781dac78916c5cc8de76345a4102449267d7) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 5cf4a41aa0d74e4c83f82d2ce233b5189ed4b43c Author: Eric Huang Date: Tue May 12 10:19:52 2026 -0400 drm/amdkfd: fix a vulnerability of integer overflow in kfd debugger commit 93f5534b35a05ef8a0109c1eefa800062fee810a upstream. get_queue_ids() computes array_size = num_queues * sizeof(uint32_t), which could overflow on 32-bit size_t build. using array_size() instead, it saturates to SIZE_MAX on overflow. Signed-off-by: Eric Huang Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 2d57a0475f085c08b49312dfd8edcb461845f285) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2f9c3c161692f5bf1436e869a651bed10936e071 Author: Eric Huang Date: Thu May 7 15:51:49 2026 -0400 drm/amdkfd: fix NULL pointer bug in svm_range_set_attr commit e984d61d92e702096058f0f828f4b2b8563b88ce upstream. The process_info could be NULL if user doesn't call kfd_ioctl_acquire_vm before calling kfd_ioctl_svm. Signed-off-by: Eric Huang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 83a26c812e0529eb040d31a76f73e33e637243d4) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 348e01e64a87ce4a84288050584537264e43a5ac Author: Shitalkumar Gandhi Date: Mon Apr 20 19:29:03 2026 +0530 serial: fsl_lpuart: fix rx buffer and DMA map leaks in start_rx_dma commit 9a9254c4a2a3ca2b3da16d173f3b0dd01f397ff6 upstream. lpuart_start_rx_dma() allocates sport->rx_ring.buf with kzalloc() and then maps a scatterlist via dma_map_sg(). On three subsequent error paths the function returns directly without releasing those resources: - when dma_map_sg() returns 0 (-EINVAL): ring->buf is leaked. - when dmaengine_slave_config() fails: ring->buf and the DMA mapping are leaked. - when dmaengine_prep_dma_cyclic() returns NULL: ring->buf and the DMA mapping are leaked. The sole cleanup path, lpuart_dma_rx_free(), is only reached when lpuart_dma_rx_use is set, and the caller lpuart_rx_dma_startup() clears that flag on failure of lpuart_start_rx_dma(). So these resources are permanently leaked on every failure in this function. Repeated port open/close or termios changes under error conditions will slowly consume memory and leave stale streaming DMA mappings behind. Fix it by introducing two error labels that unmap the scatterlist and free the ring buffer as appropriate. While here, replace the misleading -EFAULT (bad userspace pointer) returned when dmaengine_prep_dma_cyclic() fails with the more accurate -ENOMEM, matching how other dmaengine users in the tree treat this failure. No functional change on the success path. Fixes: 5887ad43ee02 ("tty: serial: fsl_lpuart: Use cyclic DMA for Rx") Cc: stable Signed-off-by: Shitalkumar Gandhi Reviewed-by: Frank Li Link: https://patch.msgid.link/20260420135903.2062024-1-shitalkumar.gandhi@cambiumnetworks.com Signed-off-by: Greg Kroah-Hartman commit 8e39badab0904a566bebb32187160895229c5ae9 Author: Maciej W. Rozycki Date: Fri Apr 10 18:19:31 2026 +0100 serial: zs: Fix swapped RI/DSR modem line transition counting commit d15cd40cb1858f75846eaafa9a6bca841b790a92 upstream. Fix a thinko in the status interrupt handler that has caused counters for the RI and DSR modem line transitions to be used for the other line each. Fixes: 8b4a40809e53 ("zs: move to the serial subsystem") Cc: stable Signed-off-by: Maciej W. Rozycki Link: https://patch.msgid.link/alpine.DEB.2.21.2604101747110.29980@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman commit 10ddd1a320e16f65d899dd16c6bae3f671a2e6e0 Author: Hongling Zeng Date: Tue Apr 21 14:57:37 2026 +0800 serial: sh-sci: fix memory region release in error path commit 92b1ea22454b08a39baef3a7290fb3ec50366616 upstream. The sci_request_port() function uses request_mem_region() to reserve I/O memory, but in the error path when sci_remap_port() fails, it incorrectly calls release_resource() instead of release_mem_region(). This mismatch can cause resource accounting issues. Fix it by using the correct release function, consistent with sci_release_port(). Fixes: e2651647080930a1 ("serial: sh-sci: Handle port memory region reservations.") Cc: stable Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202604032356.SzEjYkBC-lkp@intel.com/ Signed-off-by: Hongling Zeng Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260421065737.724187-1-zenghongling@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit 654f45a8569f3cd6ff20bd724a18e0cce65893ba Author: Viken Dadhaniya Date: Wed May 6 10:15:21 2026 +0530 serial: qcom_geni: fix kfifo underflow when flush precedes DMA completion IRQ commit 452d6fa37ae9b021f4f6d397dbae077f7296f6f4 upstream. When uart_flush_buffer() runs before the DMA completion IRQ is delivered, the following race can occur (all steps serialized by uart_port_lock): 1. DMA starts: tx_remaining = N, kfifo contains N bytes 2. DMA completes in hardware; IRQ is pending but not yet delivered 3. uart_flush_buffer() acquires the port lock and calls kfifo_reset(), making kfifo_len() = 0 while tx_remaining remains N 4. uart_flush_buffer() releases the port lock 5. DMA IRQ fires; handle_tx_dma() acquires the port lock and calls uart_xmit_advance(uport, tx_remaining) on an empty kfifo uart_xmit_advance() increments kfifo->out by tx_remaining. Since kfifo_reset() already set both in and out to 0, out wraps past in, causing kfifo_len() to return UART_XMIT_SIZE - tx_remaining. The next start_tx_dma() call then submits a DMA transfer of stale buffer data. Fix this by snapshotting kfifo_len() at the start of handle_tx_dma() and skipping uart_xmit_advance() when fifo_len < tx_remaining, which indicates the kfifo was reset by a preceding flush. Fixes: 2aaa43c70778 ("tty: serial: qcom-geni-serial: add support for serial engine DMA") Cc: stable Signed-off-by: Viken Dadhaniya Reviewed-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260506-serial-dma-stale-tx-buf-v1-1-e3ccb360d719@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 78d0d6f69bd6a876602683406dc945056bbf3e1c Author: Prasanna S Date: Tue Apr 28 09:56:13 2026 +0530 serial: qcom-geni: fix UART_RX_PAR_EN bit position commit ca2584d841b69391ffc4144840563d2e1a0018df upstream. UART_RX_PAR_EN is incorrectly defined as bit 3, which triggers false framing errors (S_GP_IRQ_1_EN) and causes received data to be dropped when parity is enabled and the parity bit is 0. Define UART_RX_PAR_EN as bit 4 of the SE_UART_RX_TRANS_CFG register, as specified in the reference manual. Fixes: c4f528795d1a ("tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP") Cc: stable Signed-off-by: Prasanna S Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260428-serial-bit-correct-v1-1-9131ad5b97d8@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit 9a91692fae5cac5662b962c5d8f6f60fb02b08b7 Author: Myeonghun Pak Date: Tue May 12 15:56:57 2026 +0900 serial: altera_jtaguart: handle uart_add_one_port() failures commit ea66be25f0e934f49d24cd0c5845d13cdba3520b upstream. altera_jtaguart_probe() maps the register window before registering the UART port, but it ignores failures from uart_add_one_port(). If port registration fails, probe still returns success and the mapping remains live until a later remove path that is not part of probe failure cleanup. Return the uart_add_one_port() error and unmap the register window on that failure path. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 5bcd601049c6 ("serial: Add driver for the Altera JTAG UART") Cc: stable Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Link: https://patch.msgid.link/20260512065837.79528-1-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit ffa7dce35b64fc5cfce56fe9f164c708a6b5ca54 Author: Timur Kristóf Date: Tue May 19 10:41:54 2026 +0200 drm/amd/pm/si: Disregard vblank time when no displays are connected commit dd4f3ee535b3b0ac027f75dbf9dc5fc88733c765 upstream. When no displays are connected, there is no vblank happening so the power management code shouldn't worry about it. This fixes a regression that caused the memory clock to be stuck at maximum when there were no displays connected to a SI GPU. Fixes: 9003a0746864 ("drm/amd/pm: Treat zero vblank time as too short in si_dpm (v3)") Fixes: 9d73b107a61b ("drm/amd/pm: Use pm_display_cfg in legacy DPM (v2)") Reviewed-by: Alex Deucher Tested-by: Jeremy Klarenbeek Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher (cherry picked from commit 6d87e0199f7b83735b56e422d59f170a201897a8) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit c9ae7e7e3bc98615364313b08d7acea5239ded0b Author: Janusz Krzysztofik Date: Fri May 8 14:23:51 2026 +0200 drm/i915: Fix potential UAF in TTM object purge commit 5c4063c87a619e4df954c179d24628636f5db15f upstream. TLDR: The bo->ttm object might be changed by calling ttm_bo_validate(), move casting it to an i915_tt object later to actually get the right pointer. A user reported hitting the following bug under heavy use on DG2: [26620.095550] Oops: general protection fault, probably for non-canonical address 0xa56b6b6b6b6b6b8b: 0000 1 SMP NOPTI [26620.095556] CPU: 2 UID: 0 PID: 631 Comm: Xorg Not tainted 6.18.8 #1 PREEMPT(lazy) [26620.095558] Hardware name: ASRock B850M Steel Legend WiFi/B850M Steel Legend WiFi, BIOS 3.50 09/18/2025 [26620.095559] RIP: 0010:i915_ttm_purge+0x84/0x100 [i915] [26620.095604] Code: 00 00 00 48 8d 54 24 10 48 89 e6 48 89 fb e8 83 aa ae ff 85 c0 75 6f 48 83 bb a8 01 00 00 00 74 2c 48 8b 45 78 48 85 c0 74 23 <48> 8b 78 20 48 c7 c2 ff ff ff ff 31 f6 e8 7a 73 e3 e0 48 8b 7d 78 [26620.095605] RSP: 0018:ffffc90005fd7430 EFLAGS: 00010282 [26620.095607] RAX: a56b6b6b6b6b6b6b RBX: ffff8881f46c3dc0 RCX: 0000000000000000 [26620.095608] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 00000000ffffffff [26620.095609] RBP: ffff888289610f00 R08: 0000000000000001 R09: ffff88823b022000 [26620.095609] R10: ffff888103029b28 R11: ffff8881fc7f3800 R12: ffff88810b6150d0 [26620.095609] R13: ffff888289610f00 R14: 0000000000000000 R15: ffff8881f46c3dc0 [26620.095610] FS: 00007f1004d86900(0000) GS:ffff88901c858000(0000) knlGS:0000000000000000 [26620.095611] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [26620.095611] CR2: 00007f0fdf489000 CR3: 000000035b0c1000 CR4: 0000000000750ef0 [26620.095612] PKRU: 55555554 [26620.095612] Call Trace: [26620.095615] [26620.095615] i915_ttm_move+0x2b9/0x420 [i915] [26620.095642] ? ttm_tt_init+0x65/0x80 [ttm] [26620.095644] ? i915_ttm_tt_create+0xc6/0x150 [i915] [26620.095667] ttm_bo_handle_move_mem+0xb6/0x160 [ttm] [26620.095669] ttm_bo_evict+0x100/0x150 [ttm] [26620.095671] ? preempt_count_add+0x64/0xa0 [26620.095673] ? _raw_spin_lock+0xe/0x30 [26620.095675] ? _raw_spin_unlock+0xd/0x30 [26620.095675] ? i915_gem_object_evictable+0xb7/0xd0 [i915] [26620.095704] ttm_bo_evict_cb+0x6e/0xd0 [ttm] [26620.095705] ttm_lru_walk_for_evict+0xa6/0x200 [ttm] [26620.095708] ttm_bo_alloc_resource+0x185/0x4f0 [ttm] [26620.095709] ? init_object+0x62/0xd0 [26620.095712] ttm_bo_validate+0x7a/0x180 [ttm] [26620.095713] ? _raw_spin_unlock_irqrestore+0x16/0x30 [26620.095714] __i915_ttm_get_pages+0xb0/0x170 [i915] [26620.095737] i915_ttm_get_pages+0x9f/0x150 [i915] [26620.095759] ? i915_gem_do_execbuffer+0xedc/0x2b40 [i915] [26620.095786] ? alloc_debug_processing+0xd0/0x100 [26620.095787] ? _raw_spin_unlock_irqrestore+0x16/0x30 [26620.095788] ? i915_vma_instance+0xa0/0x4e0 [i915] [26620.095822] __i915_gem_object_get_pages+0x2f/0x40 [i915] [26620.095848] i915_vma_pin_ww+0x706/0x980 [i915] [26620.095875] ? i915_gem_do_execbuffer+0xedc/0x2b40 [i915] [26620.095904] eb_validate_vmas+0x170/0xa00 [i915] [26620.095930] i915_gem_do_execbuffer+0x1201/0x2b40 [i915] [26620.095953] ? alloc_debug_processing+0xd0/0x100 [26620.095954] ? _raw_spin_unlock_irqrestore+0x16/0x30 [26620.095955] ? i915_gem_execbuffer2_ioctl+0xc9/0x240 [i915] [26620.095977] ? __wake_up_sync_key+0x32/0x50 [26620.095979] ? i915_gem_execbuffer2_ioctl+0xc9/0x240 [i915] [26620.096001] ? __slab_alloc.isra.0+0x67/0xc0 [26620.096003] i915_gem_execbuffer2_ioctl+0x11a/0x240 [i915] Results from decode_stacktrace.sh pointed to dereference of a file pointer field of a i915 TTM page vector container associated with an object being purged on eviction. That path is taken when the object is marked as no longer needed. Code analysis revealed a possibility of the i915 TTM page vector container being replaced with a new instance inside a function that purges content of the object, should it be still busy. That function is called, indirectly via a more general function that changes the object's placement and caching policy, before the problematic dereference, but still after a pointer to the container is captured, rendering the pointer no longer valid. Fix the issue by capturing the pointer to the container only after its potential replacement. v2: Move the container_of() inside the if block (Sebastian), - a simplified version of the commit description that explains briefly why the change is necessary (Christian). Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/14882 Fixes: 7ae034590ceae ("drm/i915/ttm: add tt shmem backend") Signed-off-by: Janusz Krzysztofik Cc: stable@vger.kernel.org # v5.17+ Cc: Matthew Auld Cc: Thomas Hellström Cc: Sebastian Brzezinka Cc: Christian König Reviewed-by: Andi Shyti Reviewed-by: Christian König Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260508122612.469227-2-janusz.krzysztofik@linux.intel.com (cherry picked from commit 4462966a93eb185849b7f174f0d0de53476d00a4) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit fed64e47a32f390fb3a0fc7c87b8ef96c8897333 Author: Jouni Högander Date: Wed May 20 13:49:43 2026 +0300 drm/i915/psr: Block DC states on vblank enable when Panel Replay supported commit 8bb9093df555f9e89fdbe1405118b11384c03e04 upstream. Currently we are blocking DC states only when Panel Replay is enabled on vblank enable. It may happen that Panel Replay is getting enabled when vblank is already enabled. Fix this by blocking DC states always if Panel Replay is supported. While at it take care of possible dual eDP case by looping all encoders supporting PSR. Fixes: 0c427ac78a1d ("drm/i915/psr: Add interface to notify PSR of vblank enable/disable") Cc: # v6.16+ Signed-off-by: Jouni Högander Reviewed-by: Michał Grzelak Link: https://patch.msgid.link/20260520104944.239797-1-jouni.hogander@intel.com (cherry picked from commit eb5911f990554f7ce947dd53df00c114362e4465) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit 0dfa42cfe4dbe114533480503934f43e33c1e83d Author: Zhenghang Xiao Date: Tue May 26 16:53:13 2026 +0800 drm/gem: fix race between change_handle and handle_delete commit 7164d78559b0ff29931a366a840a9e5dd53d4b7c upstream. drm_gem_change_handle_ioctl leaves the old handle live in the IDR during the window between spin_unlock(table_lock) and the final spin_lock(table_lock). A concurrent drm_gem_handle_delete on the old handle succeeds in this window, decrements handle_count to 0, and frees the GEM object while the new handle's IDR entry still references it. NULL the old handle's IDR entry before dropping table_lock so that any concurrent GEM_CLOSE on the old handle sees NULL and returns -EINVAL. Restore the old entry on the prime-bookkeeping error path. Fixes: 5e28b7b94408 ("drm: Set old handle to NULL before prime swap in change_handle") Signed-off-by: Zhenghang Xiao Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie Link: https://patch.msgid.link/20260526085313.26791-1-kipreyyy@gmail.com Signed-off-by: Greg Kroah-Hartman commit 164dc7bf17609340233c6bf4f66bb7c7008a0511 Author: Berkant Koc Date: Sat May 23 15:27:47 2026 +0200 drm/hyperv: validate VMBus packet size in receive callback commit 7f87763f47a3c22fb50265a00619ef10f2394b18 upstream. hyperv_receive_sub() reads msg->vid_hdr.type and dispatches into one of four message-type branches without knowing how many bytes the host wrote into hv->recv_buf. The completion path then runs memcpy(hv->init_buf, msg, VMBUS_MAX_PACKET_SIZE), so the consumer that wakes on wait_for_completion_timeout() can read up to 16 KiB of residue from a prior message as if it were the response payload. Pass bytes_recvd into hyperv_receive_sub() and reject any packet that does not cover the pipe + synthvid header. A single switch on msg->vid_hdr.type then computes the type-specific payload size: the three completion-driving types (SYNTHVID_VERSION_RESPONSE, SYNTHVID_RESOLUTION_RESPONSE, SYNTHVID_VRAM_LOCATION_ACK) fall through to a shared exit that requires that size before memcpy/complete, while SYNTHVID_FEATURE_CHANGE validates its own payload and returns before reading is_dirt_needed. Unknown types are dropped. SYNTHVID_RESOLUTION_RESPONSE is variable length: the host fills resolution_count entries, not the full SYNTHVID_MAX_RESOLUTION_COUNT array. Validate the fixed prefix first so resolution_count can be read, bound it against the array, then require only the count-sized array, so the shorter responses the host actually sends are accepted. Only run the sub-handler when vmbus_recvpacket() returned success. The memcpy length is bytes_recvd, which is bounded by VMBUS_MAX_PACKET_SIZE only on a successful receive; on -ENOBUFS vmbus_recvpacket() instead reports the required length, which can exceed hv->recv_buf, so copying bytes_recvd would read and write past the 16 KiB buffers. Gating on the success return keeps the copy bounded. The nonzero-return path is itself a malformed-message case and is now logged rather than silently skipped; channel recovery is not attempted. Rejected packets are reported via drm_err_ratelimited() rather than silently dropped, matching the CoCo-hardened pattern in hv_kvp_onchannelcallback(). Fixes: 76c56a5affeb ("drm/hyperv: Add DRM driver for hyperv synthetic video device") Cc: stable@vger.kernel.org # 5.14+ Signed-off-by: Berkant Koc Assisted-by: Claude:claude-opus-4-7 berkoc-pipeline Reviewed-by: Michael Kelley Tested-by: Michael Kelley Signed-off-by: Hamza Mahfooz Link: https://patch.msgid.link/8200dbc199c7a9b75ac7e8af6c748d2189b5ebd5.1779542874.git.me@berkoc.com Signed-off-by: Greg Kroah-Hartman commit 9c698b2c43c2667c34f5336bf46ad5786216ac2a Author: Berkant Koc Date: Tue May 19 22:08:17 2026 +0200 drm/hyperv: validate resolution_count and fix WIN8 fallback commit 13d33b9ef67066c77c84273fac5a1d3fde3533d1 upstream. A SYNTHVID_RESOLUTION_RESPONSE with resolution_count > 64 walks past the supported_resolution[SYNTHVID_MAX_RESOLUTION_COUNT] array in the parse loop. Bound resolution_count against the array size, folded into the existing zero-check. When the WIN10 resolution probe fails, the caller in hyperv_connect_vsp() left hv->screen_*_max / preferred_* unpopulated, which sets mode_config.max_width / max_height to 0 and makes drm_internal_framebuffer_create() reject every userspace framebuffer with -EINVAL. The pre-WIN10 branch had the same gap for preferred_width / preferred_height. Use a single post-probe fallback guarded by screen_width_max == 0 so both paths converge on the WIN8 defaults. Signed-off-by: Berkant Koc Assisted-by: Claude:claude-opus-4-7 berkoc-pipeline Fixes: 76c56a5affeb ("drm/hyperv: Add DRM driver for hyperv synthetic video device") Cc: stable@vger.kernel.org # 5.14+ Reviewed-by: Michael Kelley Tested-by: Michael Kelley Signed-off-by: Hamza Mahfooz Link: https://patch.msgid.link/6945b22419c7d404b4954a113de2ac9c900dba93.1779542874.git.me@berkoc.com Signed-off-by: Greg Kroah-Hartman commit 4a3a19c98a8207ad08bec554703d90f2c34a8cc6 Author: Alexandru Hossu Date: Thu May 21 17:11:21 2026 +0200 scsi: target: iscsi: Validate CHAP_R length before base64 decode commit 85db7391310b1304d2dc8ae3b0b12105a9567147 upstream. chap_server_compute_hash() allocates client_digest as kzalloc(chap->digest_size) and then, for BASE64-encoded responses, passes chap_r directly to chap_base64_decode() without checking whether the input length could produce more than digest_size bytes of output. chap_base64_decode() writes to the destination unconditionally as long as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and the "0b" prefix stripped by extract_param(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digest_size=32) this overflows client_digest by 63 bytes; for MD5 (digest_size=16) the overflow is 79 bytes. The length check at line 344 fires after the write has already happened. The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder. Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chap_base64_decode() already returns early on '=', so the full original string is still passed to the decoder unchanged. The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1 base64 characters reach the decoder. The maximum decoded size, DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is added at the call site to document this. Fixes: 1e5733883421 ("scsi: target: iscsi: Support base64 in CHAP") Cc: stable@vger.kernel.org Signed-off-by: Alexandru Hossu Reviewed-by: David Disseldorp Link: https://patch.msgid.link/20260521151121.808477-1-hossu.alexandru@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 594a40360012ce5f94c715d5e3b20fa3af7d525a Author: Michael Bommarito Date: Mon May 11 14:49:14 2026 -0400 scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf commit bf33e01f88388c43e285492a63e539df6ffed64c upstream. iscsi_encode_text_output() concatenates "key=value\0" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity: *length += sprintf(output_buf, "%s=%s", er->key, er->value); *length += 1; output_buf = textbuf + *length; The 8192-byte ceiling at iscsi_target_check_login_request() bounds the *input* Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte "a=b\0" pairs, each unknown key expanding to a 16-byte "a=NotUnderstood\0" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab. The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.) Fixes: e48354ce078c ("iscsi-target: Add iSCSI fabric support for target v4.1") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Tested-by: John Garry Reviewed-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 89c81d1228c00fa6dd91de6c1c5aa1ef8a7875e3 Author: Michael Bommarito Date: Sat Apr 18 11:49:27 2026 -0400 scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd() commit 778c2ab142c625a8a8afa570e0f9b7873f445d99 upstream. Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c ("iscsi-target: Add iSCSI fabric support for target v4.1"): 1) DataDigest CRC buffer overread (4 bytes past text_in). text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf(): if (conn->conn_ops->DataDigest) { ... rx_size += ISCSI_CRC_LEN; } ... if (conn->conn_ops->DataDigest) { data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL); iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C. Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc(). 2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop. On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap: kfree(text_in); return 0; cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does kfree(cmd->text_in_ptr); cmd->text_in_ptr = NULL; freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives. On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats: BUG: KASAN: double-free in iscsit_setup_text_cmd+0x?? BUG: KASAN: double-free in iscsit_release_cmd+0x?? showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist. Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together. Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected. Fixes: e48354ce078c ("iscsi-target: Add iSCSI fabric support for target v4.1") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Tested-by: John Garry Reviewed-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 35461d23744175a78b6280293892cca357c22793 Author: Michael Bommarito Date: Wed May 20 09:30:15 2026 -0400 scsi: scsi_transport_fc: Widen FPIN pname walker counter to u32 commit a9a39233ec1fc9f97ea1340a4d09bb7ec2be5153 upstream. An adjacent Fibre Channel fabric actor that can deliver an FPIN ELS frame to an lpfc or qla2xxx Linux initiator can trigger a non-return in the generic FC transport. This is not a local userspace or IP network path; the attacker must be able to inject fabric traffic, for example as a compromised switch or fabric controller, or as a same-zone N_Port on a fabric that permits source spoofing. The Link-Integrity and Peer-Congestion FPIN walkers used a u8 loop counter against the 32-bit on-wire pname_count field, and did not bound pname_count by the descriptor body already validated by the TLV walker. A pname_count of 256 therefore wraps the counter and keeps the loop condition true indefinitely. Factor the shared pname_list[] walk into one helper, widen the counter to u32, and clamp pname_count against the entries that fit in the descriptor body before iterating. Fixes: 3dcfe0de5a97 ("scsi: fc: Parse FPIN packets and update statistics") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Reviewed-by: Christoph Hellwig Reviewed-by: John Garry Link: https://patch.msgid.link/20260520133015.1018937-1-michael.bommarito@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 14dd80a20a72ce334adcc2d67402360527065948 Author: Michael Bommarito Date: Mon May 18 10:43:07 2026 -0400 scsi: fcoe: Reject FIP descriptors with zero fip_dlen in CVL walker commit 9eed1bd59937e6828b00d2f2dfef631d964f3636 upstream. drivers/scsi/fcoe/fcoe_ctlr.c::fcoe_ctlr_recv_clr_vlink() advanced the descriptor cursor by an attacker-supplied fip_dlen without ever requiring dlen >= sizeof(struct fip_desc) in the default branch. The named descriptor cases (FIP_DT_MAC, FIP_DT_NAME, FIP_DT_VN_ID) checked their per-type minimum lengths, but a FIP_DT_NON_CRITICAL descriptor (fip_dtype >= 128, which the standard requires receivers to silently ignore) skipped that check entirely. An unauthenticated L2 peer on the FCoE control VLAN could hang fcoe_ctlr_recv_work on an fcoe, qedf, or bnx2fc initiator indefinitely by emitting one FIP CVL frame whose single descriptor had fip_dtype == FIP_DT_NON_CRITICAL and fip_dlen == 0: the cursor advanced zero bytes per iteration and the loop condition rlen >= sizeof(*desc) stayed true forever, blocking every subsequent FIP frame on that controller. Tighten the outer dlen guard to also reject dlen < sizeof(struct fip_desc), so a malformed descriptor whose length cannot even cover the descriptor header is rejected before the switch. This is the same lower-bound the named cases already apply and is the minimum scope that closes the loop. Fixes: 97c8389d54b9 ("[SCSI] fcoe, libfcoe: Add support for FIP. FCoE discovery and keep-alive.") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260518144307.2820961-1-michael.bommarito@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit d548179adcc87e1bc66b17e00352a1f536e76065 Author: Michael Bommarito Date: Sun May 10 19:16:57 2026 -0400 thunderbolt: property: Reject dir_len < 4 to prevent size_t underflow commit de21b59c29e31c5108ddc04210631bbfab81b997 upstream. On the non-root path, __tb_property_parse_dir() takes dir_len from entry->length (u16 widened to size_t). Two distinct OOB conditions follow when entry->length < 4: 1. The non-root path begins with kmemdup(&block[dir_offset], sizeof(*dir->uuid), ...) which always reads 4 dwords from dir_offset. tb_property_entry_valid() only enforces dir_offset + entry->length <= block_len, so a crafted entry with dir_offset close to the end of the property block and entry->length in 0..3 passes that gate but lets the UUID copy run off the block (e.g. dir_offset = 497, dir_len = 3 in a 500-dword block reads block[497..501]). 2. After the kmemdup, content_len = dir_len - 4 underflows size_t to ~SIZE_MAX, nentries becomes SIZE_MAX / 4, and the entry walk runs OOB on each iteration until an entry fails validation or the kernel oopses on an unmapped page. Reject dir_len < 4 on the non-root path *before* the UUID kmemdup, which closes both holes. Also move INIT_LIST_HEAD(&dir->properties) up to immediately after the dir allocation so the new error-return path (and the existing uuid-alloc failure path) calling tb_property_free_dir() sees a walkable list rather than the zero-initialized NULL next/prev that list_for_each_entry_safe() would oops on. Fixes: cdae7c07e3e3 ("thunderbolt: Add support for XDomain properties") 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: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 31b98e503ecca8077e5247253dd5425ab84bc96d Author: Michael Bommarito Date: Sun May 10 19:16:56 2026 -0400 thunderbolt: property: Reject u32 wrap in tb_property_entry_valid() commit 01deda0152066c6c955f0619114ea6afa070aaec upstream. entry->value is u32 and entry->length is u16; the sum is performed in u32 and wraps. A malicious XDomain peer can pick value = 0xffffff00, length = 0x100 so the sum 0x100000000 wraps to 0 and passes the > block_len check. tb_property_parse() then passes entry->value to parse_dwdata() as a dword offset into the property block, reading attacker-directed memory far past the allocation. For TEXT-typed entries with the "deviceid" or "vendorid" keys this lands in xd->device_name / xd->vendor_name and is readable back via the per-XDomain device_name / vendor_name sysfs attributes; the leak is NUL-bounded (kstrdup() stops at the first zero byte) and untargeted (the attacker picks a delta, not an absolute address). DATA-typed entries are parsed into property->value.data but not generically surfaced to userspace. Use check_add_overflow() so a wrapped sum is rejected. Fixes: cdae7c07e3e3 ("thunderbolt: Add support for XDomain properties") 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: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit c7d421123b98d5e9c1c84bd9957aba36f1cbb4ca Author: Michael Bommarito Date: Sun Apr 19 12:12:27 2026 -0400 usb: gadget: f_fs: serialize DMABUF cancel against request completion commit 2796646f6d892c1eb6818c7ca41fdfa12568e8d1 upstream. ffs_epfile_dmabuf_io_complete() calls usb_ep_free_request() on the completed request but leaves priv->req, the back-pointer that ffs_dmabuf_transfer() set on submission, pointing at the freed memory. A later FUNCTIONFS_DMABUF_DETACH ioctl or ffs_epfile_release() on the close path still sees priv->req non-NULL under ffs->eps_lock: if (priv->ep && priv->req) usb_ep_dequeue(priv->ep, priv->req); so usb_ep_dequeue() is called on a freed usb_request. On dummy_hcd the dequeue path only walks a live queue and pointer-compares, so the freed pointer reads without faulting and KASAN requires an explicit check at the FunctionFS call site to surface the use-after-free. On SG-capable in-tree UDCs the dequeue path dereferences the supplied request immediately: * chipidea's ep_dequeue() does container_of(req, struct ci_hw_req, req) and reads hwreq->req.status before acquiring its own lock. * cdnsp's cdnsp_gadget_ep_dequeue() reads request->status first. The narrower option of clearing priv->req via cmpxchg() in the completion does not close the race: the completion runs without eps_lock, so a cancel path holding eps_lock can still observe priv->req non-NULL, race a concurrent completion that clears and frees, and pass the freed pointer to usb_ep_dequeue(). A slightly longer fix that moves the free into the cleanup work is needed. Same class of lifetime race as the recent usbip-vudc timer fix [1]. Take eps_lock in the sole place that mutates priv->req from the callback direction by moving usb_ep_free_request() out of the completion into ffs_dmabuf_cleanup(), the existing work handler scheduled by ffs_dmabuf_signal_done() on ffs->io_completion_wq. Clear priv->req there under eps_lock before freeing, and only clear if priv->req still names our request (a subsequent ffs_dmabuf_transfer() on the same attachment may have queued a new one). This keeps the existing dummy_hcd sync-dequeue invariant: the completion callback is still invoked by the UDC without eps_lock held (dummy_hcd drops its own lock before calling the callback), and the callback now takes no f_fs lock at all. Serialization against the cancel path happens in cleanup, which runs from the workqueue with no f_fs lock held on entry. The priv ref count protects the containing ffs_dmabuf_priv: ffs_dmabuf_transfer() takes a ref via ffs_dmabuf_get(), cleanup drops it via ffs_dmabuf_put(), so priv stays live for the cleanup even after the cancel path's list_del + ffs_dmabuf_put. The ffs_dmabuf_transfer() error path no longer frees usb_req inline: fence->req and fence->ep are set before usb_ep_queue(), so ffs_dmabuf_cleanup() (scheduled by the error-path ffs_dmabuf_signal_done()) owns the free regardless of whether the queue succeeded. Reproduced under KASAN on both detach and close paths against dummy_hcd with an observability hook (kasan_check_byte(priv->req) immediately before usb_ep_dequeue) at the two FunctionFS cancel sites to surface the stale-pointer access; the hook is not part of this patch. The KASAN allocator / free stacks in the captured splats identify the same request: alloc in dummy_alloc_request, free in dummy_timer, fault reached from ffs_epfile_release (close) and from the FUNCTIONFS_DMABUF_DETACH ioctl (detach). With the patch applied, both paths are silent under the same hook. The bug is reached from the FunctionFS device node, which in real deployments is owned by the privileged gadget daemon (adbd, UMS, composite gadget services, etc.); it is not reachable from unprivileged userspace or from a USB host on the cable. FunctionFS mounts default to GLOBAL_ROOT_UID, but the filesystem supports uid=, gid=, and fmode= delegation to a non-root gadget daemon, so on real deployments the attacker may be a less-privileged service rather than root. Fixes: 7b07a2a7ca02 ("usb: gadget: functionfs: Add DMABUF import interface") Link: https://lore.kernel.org/all/20260417163552.807548-1-michael.bommarito@gmail.com/ [1] Cc: stable Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260419161227.1587668-1-michael.bommarito@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 607730a414773a7cbe3037a64a6c64e72689ff5e Author: Michael Bommarito Date: Sun Apr 19 12:03:59 2026 -0400 usb: gadget: f_fs: copy only received bytes on short ep0 read commit 4e036c10e7f4df5d951c69cc3697bc8e209c6d02 upstream. ffs_ep0_read() allocates its control-OUT data buffer with kmalloc() (not kzalloc) at the Length value from the Setup packet, then copies that full len to userspace regardless of how many bytes were actually received: data = kmalloc(len, GFP_KERNEL); ... ret = __ffs_ep0_queue_wait(ffs, data, len); if ((ret > 0) && (copy_to_user(buf, data, len))) ret = -EFAULT; __ffs_ep0_queue_wait() returns req->actual, which on a short control OUT transfer is strictly less than len. The copy_to_user() call still copies len bytes, so on a short OUT the last (len - ret) bytes of the kmalloc() buffer -- uninitialised slab residue -- are delivered to the FunctionFS daemon. Short ep0 OUT completions are specified USB control-transfer behavior and are produced by in-tree UDCs: * dwc2 continues on req->actual < req->length for ep0 DATA OUT (short-not-ok is the only ep0-OUT stall path). * aspeed_udc ends ep0 OUT on rx_len < ep->ep.maxpacket. * renesas_usbf logs "ep0 short packet" and completes the request. * dwc3 stalls on short IN but not on short OUT. A short ep0 OUT is therefore not evidence of a broken UDC; it is a normal condition f_fs has to cope with. The sibling gadgetfs implementation in drivers/usb/gadget/legacy/inode.c already does this correctly via min(len, dev->req->actual) before copy_to_user(). This patch brings f_fs.c to the same safe pattern rather than trimming at a defensive layer. The bug is reached from the FunctionFS device node, which in real deployments is owned by the privileged gadget daemon (adbd, UMS, composite gadget services, etc.); it is not reachable from unprivileged userspace. Linux host stacks normally reject short-wLength control OUTs before they reach the gadget, so reproducing this required a build that bypasses that host-side check. With the bypass in place, a 1-byte payload on a 64-byte Setup produces 63 bytes of non-canary slab residue in the daemon's read buffer. Fix by copying only ret (actually received) bytes to userspace. Fixes: ddf8abd25994 ("USB: f_fs: the FunctionFS driver") Cc: stable Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260419160359.1577270-1-michael.bommarito@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 5933063935e8404c9a0504c4ed96260a0530196d Author: Seungjin Bae Date: Mon May 18 19:43:14 2026 -0400 usb: gadget: dummy_hcd: Reject hub port requests for non-existent ports commit 7d9633528dd40e33964d2dc74a5abbf5c4d116ce upstream. The `dummy_hub_control()` function handles USB hub class requests to the virtual root hub. The `GetPortStatus` case returns -EPIPE for requests with `wIndex != 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 `wIndex != 1` rejection to both cases, matching the existing behavior of `GetPortStatus`. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable Suggested-by: Alan Stern Signed-off-by: Seungjin Bae Reviewed-by: Alan Stern Link: https://patch.msgid.link/20260518234314.1889396-1-eeodqql09@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit f8f5a8f48c7cae3fac85e04b593bd47939f9725f Author: Jeremy Erazo Date: Tue May 12 16:05:30 2026 +0000 usb: gadget: composite: fix integer underflow in WebUSB GET_URL handling commit 6c5dbc104dadd79fc2923497c20bae759a18758c upstream. The WebUSB GET_URL handler in composite_setup() narrows landing_page_length to fit the host-supplied wLength using landing_page_length = w_length - WEBUSB_URL_DESCRIPTOR_HEADER_LENGTH + landing_page_offset; If wLength is smaller than WEBUSB_URL_DESCRIPTOR_HEADER_LENGTH the unsigned subtraction wraps, and the subsequent memcpy(url_descriptor->URL, cdev->landing_page + landing_page_offset, landing_page_length - landing_page_offset); ends up copying close to UINT_MAX bytes from cdev->landing_page into cdev->req->buf. KASAN reports a slab-out-of-bounds in composite_setup on the kmalloc-2k gadget_info allocation, and FORTIFY_SOURCE traps the memcpy as a 4294967293-byte field-spanning write into url_descriptor->URL (size 252). A USB host can reach this from a single SETUP packet against any gadget that has webusb/use=1 and a landingPage configured. Handle the small-wLength case before the math: when the host requested fewer bytes than the URL descriptor header, only the header is meaningful and no URL bytes need to be copied. Setting landing_page_length to landing_page_offset makes the existing memcpy a no-op and leaves the descriptor returned to the host unchanged for all larger wLength values. Fixes: 93c473948c58 ("usb: gadget: add WebUSB landing page support") Cc: stable Signed-off-by: Jeremy Erazo Link: https://patch.msgid.link/20260512160530.352318-1-mendozayt13@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit f928630f450be7008e1dce86bf95275b2f92af91 Author: Guangshuo Li Date: Mon Apr 13 22:21:19 2026 +0800 usb: gadget: f_hid: fix device reference leak in hidg_alloc() commit 4f88d65def6f3c90121601b4f62a4c967f3063a6 upstream. hidg_alloc() initializes hidg->dev with device_initialize() before calling dev_set_name(). If dev_set_name() fails, the function currently jumps to err_unlock and returns without calling put_device(). This leaves the device reference unbalanced and prevents hidg_release() from being called. Calling put_device() here is also safe, since hidg_release() only frees resources owned by hidg. The issue was identified by a static analysis tool I developed and confirmed by manual review. Route the dev_set_name() failure path through err_put_device so the device reference is dropped properly. Fixes: 89ff3dfac604 ("usb: gadget: f_hid: fix f_hidg lifetime vs cdev") Cc: stable Reviewed-by: Johan Hovold Signed-off-by: Guangshuo Li Reviewed-by: Johan Hovold johan@kernel.org Link: https://patch.msgid.link/20260413142119.2977716-1-lgs201920130244@gmail.com Signed-off-by: Greg Kroah-Hartman commit e6f8be12f0307145b9a6010f044925952b37de8b Author: Guangshuo Li Date: Mon Apr 27 23:36:51 2026 +0800 usb: gadget: net2280: Fix double free in probe error path commit c8547c74988e0b5f4cbb1b895e2a57aae084f070 upstream. usb_initialize_gadget() installs gadget_release() as the release callback for the embedded gadget device. The struct net2280 instance is therefore released through gadget_release() when the gadget device's last reference is dropped. The probe error path calls net2280_remove(), which tears down the partially initialized device and drops the gadget reference with usb_put_gadget(). Calling kfree(dev) afterwards can free the same object again. Drop the explicit kfree() and let the gadget device release callback handle the final free. This issue was found by a static analysis tool I am developing. Fixes: f770fbec4165 ("USB: UDC: net2280: Fix memory leaks") Cc: stable Signed-off-by: Guangshuo Li Reviewed-by: Alan Stern Link: https://patch.msgid.link/20260427153651.337846-1-lgs201920130244@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit caec0145e5974e85fe5192fc6a6f5aa1a98f82a6 Author: Kai Aizen Date: Thu Apr 30 20:56:43 2026 +0300 usb: gadget: uvc: hold opts->lock across XU walks in uvc_function_bind commit 68aa70648b625fa684bc0b71bbfd905f4943ca20 upstream. uvc_function_bind() walks &opts->extension_units twice without holding opts->lock: - directly, for the iExtension string-descriptor fixup loop; - indirectly, four times via uvc_copy_descriptors() (once per speed), where the helper iterates uvc->desc.extension_units (which aliases &opts->extension_units) to size and emit XU descriptors. The configfs side (uvcg_extension_make / uvcg_extension_drop, in drivers/usb/gadget/function/uvc_configfs.c) takes opts->lock around its list_add_tail / list_del operations. A privileged userspace process that holds the configfs subtree open and writes the gadget UDC name to bind the function while concurrently rmdir()'ing an extensions subdir can race uvcg_extension_drop() against the bind-time list walks and dereference a freed struct uvcg_extension. Hold opts->lock from the start of the XU string-descriptor fixup through the last uvc_copy_descriptors() call, releasing on the descriptor-error path via a new error_unlock label that drops the lock before falling through to the existing error label. This matches the locking discipline of the configfs callbacks and removes the only remaining unsynchronised reader of the XU list during bind. Reachability: only privileged processes that can mount configfs and write to gadget UDC files can trigger the race, so this is a correctness fix rather than a security boundary. Fixes: 0525210c9840 ("usb: gadget: uvc: Allow definition of XUs in configfs") Cc: stable Signed-off-by: Kai Aizen Link: https://patch.msgid.link/20260430175643.67120-1-kai.aizen.dev@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit f06bcaba29707f060706483b2020d3cafbe98f9f Author: Johan Hovold Date: Wed May 20 16:27:10 2026 +0200 USB: serial: mct_u232: fix missing interrupt-in transfer sanity check commit 245aba83e3c288e176ed037a1f6b618b09e92ed8 upstream. Add the missing sanity check on the size of interrupt-in transfers to avoid parsing stale or uninitialised slab data (and leaking it to user space). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 6c0cf56f00f280d72180bb6ce79741bc787a6269 Author: Johan Hovold Date: Fri May 22 16:19:50 2026 +0200 USB: serial: mxuport: fix memory corruption with small endpoint commit 4085f0dbb1ce2251c9a5938d693de6593f0ab2bd upstream. Make sure that the bulk-out endpoint max packet size is at least eight bytes to avoid user-controlled slab corruption should a malicious device report a smaller size. Fixes: ee467a1f2066 ("USB: serial: add Moxa UPORT 12XX/14XX/16XX driver") Cc: stable@vger.kernel.org # 3.14 Cc: Andrew Lunn Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit ea2b792330b44b6d7ce671c3e1d59d0c121f7ed1 Author: Johan Hovold Date: Wed May 20 16:26:48 2026 +0200 USB: serial: keyspan: fix missing indat transfer sanity check commit ab8336a7e414f018430aa1af3a46944032f7ff96 upstream. Add the missing sanity check on the size of usa49wg indat transfers to avoid parsing stale or uninitialised slab data. Fixes: 0ca1268e109a ("USB Serial Keyspan: add support for USA-49WG & USA-28XG") Cc: stable@vger.kernel.org # 2.6.23 Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit ae03453f2c809ca3cf73753269fa6184dea7160f Author: Zhang Cen Date: Fri May 22 22:54:42 2026 +0800 USB: serial: cypress_m8: validate interrupt packet headers commit 9f9bfc80c67f35a275820da7e83a35dface08281 upstream. cypress_read_int_callback() parses the interrupt-in buffer according to the selected Cypress packet format. Format 1 has a two-byte status/count header and format 2 has a one-byte combined status/count header. The usb-serial core sizes the interrupt-in buffer from the endpoint descriptor's wMaxPacketSize, and successful interrupt transfers can complete short when URB_SHORT_NOT_OK is not set. Check that the completed packet contains the selected header before reading it. Malformed short reports are ignored and the interrupt URB is resubmitted through the existing retry path, preventing out-of-bounds header-byte reads. KASAN report as below: KASAN slab-out-of-bounds in cypress_read_int_callback+0x240/0x7f0 Read of size 1 Call trace: cypress_read_int_callback() (drivers/usb/serial/cypress_m8.c:1009) __usb_hcd_giveback_urb() dummy_timer() Fixes: 3416eaa1f8f8 ("USB: cypress_m8: Packet format is separate from characteristic size") Assisted-by: Codex:gpt-5.5 Signed-off-by: Zhang Cen Fixes: 3416eaa1f8f8 ("USB: cypress_m8: Packet format is separate from characteristic size") Cc: stable@vger.kernel.org # 2.6.26 [ johan: use constants in header length sanity checks ] Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 22823a319fb2afdf02cacafbed8b613b757efbc8 Author: Zhang Cen Date: Tue May 19 19:11:50 2026 +0800 USB: serial: belkin_sa: validate interrupt status length commit 4ce058df2ee02cc2a0f0fd5cd64ce6f1482a0b65 upstream. The Belkin interrupt callback treats interrupt data as a four-byte status report and reads LSR/MSR fields at offsets 2 and 3. The interrupt-in buffer length is derived from endpoint wMaxPacketSize, and short interrupt transfers may complete successfully with a smaller actual_length. Check the completed interrupt packet length before parsing status fields so short interrupt endpoints and short successful packets are ignored instead of causing out-of-bounds or stale status-byte reads. KASAN report as below: BUG: KASAN: slab-out-of-bounds in belkin_sa_read_int_callback() Read of size 1 Call trace: belkin_sa_read_int_callback() (drivers/usb/serial/belkin_sa.c:202) __usb_hcd_giveback_urb() (drivers/usb/core/hcd.c:1630) dummy_timer() (?:?) Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Assisted-by: Codex:gpt-5.5 Signed-off-by: Zhang Cen Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit f7c3fcd634052548313ffaa7c83d350816a887fe Author: Wanquan Zhong Date: Wed May 20 19:32:45 2026 +0800 USB: serial: option: add missing RSVD(5) flag for Rolling RW135R-GL commit 689f2facc689c8add11d7ff69fbbad17d65ee596 upstream. The RW135R-GL entry added in commit 01e8d0f74222 ("USB: serial: option: add support for Rolling Wireless RW135R-GL") was missing the .driver_info = RSVD(5) flag used by other Rolling Wireless MBIM laptop modules (e.g. RW135-GL and RW350-GL). Without this flag, the option driver incorrectly binds to the reserved ADB interface (If#5) in multi-interface USB modes, causing AT/MBIM communication failures after mode switching. This matches the handling of other Rolling Wireless MBIM devices. - VID:PID 33f8:1003, RW135R-GL for laptop debug M.2 cards (with MBIM interface for Linux/Chrome OS) 0x1003: mbim, diag, AT, pipe Here are the outputs of usb-devices: T: Bus=03 Lev=01 Prnt=01 Port=04 Cnt=02 Dev#= 8 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=33f8 ProdID=1003 Rev= 5.15 S: Manufacturer=Rolling Wireless S.a.r.l. S: Product=Rolling RW135R-GL Module S: SerialNumber=12345678 C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=82(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms - VID:PID 33f8:1003, RW135R-GL for laptop debug M.2 cards (with MBIM interface for Linux/Chrome OS) 0x1003: mbim, diag, AT, ADB, pipe Here are the outputs of usb-devices: T: Bus=03 Lev=01 Prnt=01 Port=04 Cnt=02 Dev#= 7 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=33f8 ProdID=1003 Rev= 5.15 S: Manufacturer=Rolling Wireless S.a.r.l. S: Product=Rolling RW135R-GL Module S: SerialNumber=12345678 C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=82(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms - VID:PID 33f8:1003, RW135R-GL for laptop debug M.2 cards (with MBIM interface for Linux/Chrome OS) 0x1003: mbim, pipe Here are the outputs of usb-devices: T: Bus=03 Lev=01 Prnt=01 Port=04 Cnt=02 Dev#= 9 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=33f8 ProdID=1003 Rev= 5.15 S: Manufacturer=Rolling Wireless S.a.r.l. S: Product=Rolling RW135R-GL Module S: SerialNumber=12345678 C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=500mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=82(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Fixes: 01e8d0f74222 ("USB: serial: option: add support for Rolling Wireless RW135R-GL") Signed-off-by: Wanquan Zhong Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 38ba1a464c0d141abf01e231f5c5bc949e851ed6 Author: Jan Volckaert Date: Sun May 17 17:32:37 2026 +0200 USB: serial: option: add MeiG SRM813Q commit 7d2b37d3e42d19071b62f4ddbee6e16e905efbf1 upstream. Add support for the Qualcomm Technology Snapdragon X35-based MeiG SRM813Q module. The module can be put in different modes via AT commands to enable/disable GPS functionality: MODEM - PPP mode(2dee:4d63): AT+SER=1,1 If#= 0: RMNET If#= 1: DIAG/ADB If#= 2: MODEM If#= 3: AT P: Vendor=2dee ProdID=4d63 Rev=05.15 S: Manufacturer=MEIG S: Product=LTE-A Module S: SerialNumber=1bd51f0e C: #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms NMEA mode(2dee:4d64): AT+SER=51,1 If#= 0: RMNET If#= 1: DIAG/ADB If#= 2: NMEA If#= 3: AT P: Vendor=2dee ProdID=4d64 Rev=05.15 S: Manufacturer=MEIG S: Product=LTE-A Module S: SerialNumber=1bd51f0e C: #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms Signed-off-by: Jan Volckaert Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 62fbc1396108764cd069962906ce57598810a307 Author: Myrrh Periwinkle Date: Tue May 19 18:41:40 2026 +0700 usb: typec: ucsi: Don't update power_supply on power role change if not connected commit d98d413ca65d0790a8f3695d0a5845538958ab84 upstream. We only need to update the power_supply on power role change if the port is connected, because otherwise the online status should be the same for both cases. Cc: stable Fixes: 7616f006db07 ("usb: typec: ucsi: Update power_supply on power role change") Signed-off-by: Myrrh Periwinkle Reported-and-tested-by: Sergey Senozhatsky Link: https://patch.msgid.link/20260519-ucsi-fix-2-v1-2-6f1239535187@qtmlabs.xyz Signed-off-by: Greg Kroah-Hartman commit d62d97c9c8c27801ee3930cc3723083a26c77036 Author: Myrrh Periwinkle Date: Tue May 19 18:41:39 2026 +0700 usb: typec: ucsi: Check if power role change actually happened before handling commit b80e7d34c7ea6a564525119d6138fbb577a23dba upstream. The CrOS EC may send a connector status change event with the power direction changed flag set even if the power direction hasn't actually changed after initiating a SET_PDR command internally [1]. In practice this happens on every system suspend due to other changes performed by the EC [2][3][4], causing suspend to fail. Fix this by checking if the power role change actually happened before handling it. [1]: https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/platform/ec/zephyr/subsys/pd_controller/pdc_power_mgmt.c;l=1689;drc=2d5a1cffce4e5ac8a39442cb3b764d2d5e1cf794 [2]: https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/platform/ec/zephyr/subsys/pd_controller/pdc_power_mgmt.c;l=3923;drc=2d5a1cffce4e5ac8a39442cb3b764d2d5e1cf794 [3]: https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/platform/ec/zephyr/subsys/pd_controller/pdc_power_mgmt.c;l=5094;drc=2d5a1cffce4e5ac8a39442cb3b764d2d5e1cf794 [4]: https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/platform/ec/zephyr/subsys/pd_controller/pdc_power_mgmt.c;l=2229;drc=2d5a1cffce4e5ac8a39442cb3b764d2d5e1cf794 Cc: stable Fixes: 7616f006db07 ("usb: typec: ucsi: Update power_supply on power role change") Signed-off-by: Myrrh Periwinkle Reported-and-tested-by: Sergey Senozhatsky Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260519-ucsi-fix-2-v1-1-6f1239535187@qtmlabs.xyz Signed-off-by: Greg Kroah-Hartman commit f34effb0b5456cc27bbbb15258785ad9fedf10c1 Author: Sebastian Reichel Date: Wed Apr 29 18:33:32 2026 +0200 usb: typec: tcpm: improve handling of DISCOVER_MODES failures commit c06e6cd488194e37ed4dc29d1488d1ffb760de60 upstream. UGREEN USB-C Multifunction Adapter Model CM512 (AKA "Revodok 107") exposes two SVIDs: 0xff01 (DP Alt Mode) and 0x1d5c. The DISCOVER_MODES step succeeds for 0xff01 and gets a NAK for 0x1d5c. Currently this results in DP Alt Mode not being registered either, since the modes are only registered once all of them have been discovered. The NAK results in the processing being stopped and thus no Alt modes being registered. Improve the situation by handling the NAK gracefully and continue processing the other modes. Before this change, the TCPM log ends like this: (more log entries before this) [ 5.028287] AMS DISCOVER_SVIDS finished [ 5.028291] cc:=4 [ 5.040040] SVID 1: 0xff01 [ 5.040054] SVID 2: 0x1d5c [ 5.040082] AMS DISCOVER_MODES start [ 5.040096] PD TX, header: 0x1b6f [ 5.050946] PD TX complete, status: 0 [ 5.059609] PD RX, header: 0x264f [1] [ 5.059626] Rx VDM cmd 0xff018043 type 1 cmd 3 len 2 [ 5.059640] AMS DISCOVER_MODES finished [ 5.059644] cc:=4 [ 5.069994] Alternate mode 0: SVID 0xff01, VDO 1: 0x000c0045 [ 5.070029] AMS DISCOVER_MODES start [ 5.070043] PD TX, header: 0x1d6f [ 5.081139] PD TX complete, status: 0 [ 5.087498] PD RX, header: 0x184f [1] [ 5.087515] Rx VDM cmd 0x1d5c8083 type 2 cmd 3 len 1 [ 5.087529] AMS DISCOVER_MODES finished [ 5.087534] cc:=4 (no further log entries after this point) After this patch the TCPM log looks exactly the same, but then continues like this: [ 5.100222] Skip SVID 0x1d5c (failed to discover mode) [ 5.101699] AMS DFP_TO_UFP_ENTER_MODE start (log goes on as the system initializes DP AltMode) Cc: stable Fixes: 41d9d75344d9 ("usb: typec: tcpm: add discover svids and discover modes support for sop'") Reviewed-by: Heikki Krogerus Signed-off-by: Sebastian Reichel Reviewed-by: RD Babiera Reviewed-by: Badhri Jagan Sridharan Link: https://patch.msgid.link/20260429-tcpm-discover-modes-nak-fix-v4-1-75945d0ed30f@collabora.com Signed-off-by: Greg Kroah-Hartman commit 02d9d8b79e18bc24ce89572868388c4478a6c2ae Author: Dan Carpenter Date: Tue May 12 13:14:59 2026 +0300 usb: typec: tipd: Fix error code in tps6598x_probe() commit b02900c85a6423cf9b3dcc6b47bf060c85075e69 upstream. Set the error code on these two error paths. The existing code returns success. Fixes: 77ed2f4538da ("usb: typec: tipd: Use read_power_status function in probe") Fixes: 04041fd7d6ec ("usb: typec: tipd: Read data status in probe and cache its value") Cc: stable Signed-off-by: Dan Carpenter Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/agL9o7wUK1dOVBTy@stanley.mountain Signed-off-by: Greg Kroah-Hartman commit a90139ff1ebaff0e2b581827bd9290fbf34ed10f Author: Heitor Alves de Siqueira Date: Tue May 5 15:56:04 2026 -0300 usb: usbtmc: reject interrupt endpoints with small wMaxPacketSize commit 121d2f682ba912b1427cddca7cf84840f41cc620 upstream. The USB488 subclass specification requires interrupt wMaxPacketSize to be 0x02, unless the device sends vendor-specific notifications. Endpoints that advertise less than 2 bytes for wMaxPacketSize are unlikely to work with the current driver, as URBs will not have enough space for interrupt headers. Considering that any notification URBs will be ignored by the driver, reject these endpoints early during probe. Fixes: 041370cce889 ("USB: usbtmc: refactor endpoint retrieval") Cc: stable Suggested-by: Michal Pecio Signed-off-by: Heitor Alves de Siqueira Link: https://patch.msgid.link/20260505-usbtmc-iin-size-v3-2-a36113f62db7@igalia.com Signed-off-by: Greg Kroah-Hartman commit 75f6d3da2cc646983f41807ef98851569c12bca9 Author: Heitor Alves de Siqueira Date: Tue May 5 15:56:03 2026 -0300 usb: usbtmc: check URB actual_length for interrupt-IN notifications commit 52f2ad3f7e5eb3b5908e1d685d4342519dc9cfcd upstream. USBTMC devices can use an optional interrupt endpoint for notification messages. These typically contain two-byte headers indicating the payload format, but the driver does not check if these headers are present before accessing the data buffers. In cases where the URB actual_length is not enough to fit these headers, the driver will either cause an out-of-bounds read, or consume stale leftover data from a previous notification. Fix by checking if actual_data contains enough bytes for the headers, otherwise resubmit URB to the interrupt endpoint. Fixes: dbf3e7f654c0 ("Implement an ioctl to support the USMTMC-USB488 READ_STATUS_BYTE operation.") Reported-by: syzbot+abbfd103085885cf16a2@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=abbfd103085885cf16a2 Cc: stable Suggested-by: Michal Pecio Signed-off-by: Heitor Alves de Siqueira Link: https://patch.msgid.link/20260505-usbtmc-iin-size-v3-1-a36113f62db7@igalia.com Signed-off-by: Greg Kroah-Hartman commit 88d459e5b5a46da1ef9fd6f52d9439343edeec88 Author: Michael Bommarito Date: Fri Apr 17 12:35:52 2026 -0400 usbip: vudc: Fix use after free bug in vudc_remove due to race condition commit d96209626a29ea64666be98c30b30ac82e5f1be6 upstream. This patch follows up Zheng Wang's 2023 report of a use-after-free in vudc_remove(). The original thread stalled on Shuah Khan's request for runtime testing of the unplug/unbind path. This patch supplies that testing and keeps Zheng's original fix shape. In vudc_probe(), v_init_timer() binds udc->tr_timer.timer to v_timer(). usbip_sockfd_store() starts the timer via v_start_timer()/v_kick_timer(). vudc_remove() can then free the containing struct vudc while the timer is still pending or executing. KASAN confirms the race on an unpatched x86_64 QEMU guest with CONFIG_KASAN=y, CONFIG_USBIP_VUDC=y, CONFIG_USB_ZERO=y, and a tight loop that repeatedly writes a socket fd to usbip_sockfd, closes the socket pair, and unbinds/rebinds usbip-vudc.0: BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x8ba/0x8e0 Write of size 8 at addr ffff888001b80740 by task trigger_and_unb/239 Allocated by task 239: vudc_probe+0x4d/0xaa0 Freed by task 239: kfree+0x18f/0x520 device_release_driver_internal+0x388/0x540 unbind_store+0xd9/0x100 This lands in the timer core rather than v_timer() itself because the embedded timer_list is being walked after its containing struct vudc has already been freed. The underlying lifetime bug is the same one Zheng reported. With v_stop_timer() called from vudc_remove() and the timer deleted synchronously, the same harness completed 5000 bind/unbind iterations with no KASAN report. Fixes: b6a0ca111867 ("usbip: vudc: Add UDC specific ops") Cc: stable Reported-by: Zheng Wang Closes: https://lore.kernel.org/linux-usb/20230317100954.2626573-1-zyytlz.wz@163.com/ Signed-off-by: Michael Bommarito Acked-by: Shuah Khan Link: https://patch.msgid.link/20260417163552.807548-1-michael.bommarito@gmail.com Signed-off-by: Greg Kroah-Hartman commit 5b78d8b9a83216da8fd6de442f77d52f4f3e622a Author: Sam Burkels Date: Fri May 1 15:23:46 2026 +0200 usb: storage: Add quirks for PNY Elite Portable SSD commit b53ebb811e00be50a779ce4e7aee604178b4a825 upstream. The PNY Elite Portable SSD (USB ID 154b:f009) is a sibling of the already-quirked PNY Pro Elite SSDs (154b:f00b and 154b:f00d). Like its siblings, it uses a Phison-based USB-SATA bridge that exhibits firmware bugs when bound to the uas driver. Without quirks, the device fails to complete READ CAPACITY commands when accessed over UAS on a SuperSpeed (USB 3) port. The device enumerates and reports as a SCSI direct-access device, but reports zero logical blocks and never finishes spin-up: usb 2-3: new SuperSpeed USB device number 8 using xhci_hcd usb 2-3: New USB device found, idVendor=154b, idProduct=f009 usb 2-3: Product: PNY ELITE PSSD usb 2-3: Manufacturer: PNY scsi host0: uas scsi 0:0:0:0: Direct-Access PNY PNY ELITE PSSD 0 sd 0:0:0:0: [sda] Spinning up disk... [...10+ seconds of polling, no progress...] sd 0:0:0:0: [sda] Read Capacity(16) failed: hostbyte=DID_ERROR sd 0:0:0:0: [sda] Read Capacity(10) failed: hostbyte=DID_ERROR sd 0:0:0:0: [sda] 0 512-byte logical blocks: (0 B/0 B) Tested each individual quirk to find the minimum that fixes this: - US_FL_NO_ATA_1X alone: device hangs on spin-up - US_FL_NO_REPORT_OPCODES alone: works on USB 2.0, hangs on USB 3.0 - US_FL_NO_ATA_1X | US_FL_NO_REPORT_OPCODES: works on both With both quirks the device enumerates correctly while still using the uas driver, and delivers full UAS throughput (~281 MB/s sequential read on a USB 3.0 Gen 1 port). The existing PNY Pro Elite entries (f00b, f00d) only set NO_ATA_1X, but this device additionally chokes on REPORT OPCODES under SuperSpeed. Signed-off-by: Sam Burkels Acked-by: Oliver Neukum Cc: stable Link: https://patch.msgid.link/20260501132346.86572-1-sam@1a38.nl Signed-off-by: Greg Kroah-Hartman commit 94b05aec1985ac35d136be7fef9ffdec0e1d159f Author: Stephen J. Fuhry Date: Wed May 13 13:14:19 2026 -0400 USB: quirks: add NO_LPM for Lenovo ThinkPad USB-C Dock Gen2 hub controllers commit 9ddb9c0deca48d2c2a22ebf4d2f35c925a520328 upstream. The Lenovo ThinkPad USB-C Dock Gen2 (17ef:a391, 17ef:a392) hub controllers exhibit link instability when USB Link Power Management is enabled, similar to the dock's Ethernet adapter (17ef:a387) which already carries USB_QUIRK_NO_LPM. When the dock reconnects after a transient disconnect, the hub controllers enter LPM states between re-enumeration retries, causing repeated disconnect/reconnect cycles lasting up to two minutes. Disabling LPM for these devices restores stable enumeration. Signed-off-by: Stephen J. Fuhry Cc: stable Link: https://patch.msgid.link/20260513171419.44849-1-fuhrysteve@gmail.com Signed-off-by: Greg Kroah-Hartman commit 69f9f2b30af03d9b6e83f78fb0f734b6066d4678 Author: Wentao Liang Date: Thu Apr 9 10:11:04 2026 +0000 usb: musb: omap2430: Fix use-after-free in omap2430_probe() commit e194ce048f5a6c549b3a23a8c568c6470f40f772 upstream. In omap2430_probe(), of_node_put(np) is called prematurely before the last access to np, leading to a use-after-free if the node's reference count drops to zero. Move the of_node_put() calls after the last use of np in both the success and error paths. Fixes: ffbe2feac59b ("usb: musb: omap2430: Fix probe regression for missing resources") Cc: stable Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260409101104.480623-1-vulab@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit 3bc65566331abcf884ebcf09b1755a134914b2c9 Author: Michal Pecio Date: Mon May 18 07:32:07 2026 +0200 usb: core: Fix up Interrupt IN endpoints with bogus wBytesPerInterval commit 727d045d064b7c9a24db3bce9c0485a382cb768b upstream. Tao Xue found that some common devices violate USB 3.x section 9.6.7 by reporting wBytesPerInterval lower than the size of packets they actually send. I confirmed that AX88179 may set it to 0 and RTL8153 CDC configuration sets it to 8 but sends both 8 and 16 byte packets: S Ii:11:007:3 -115:128 16 < C Ii:11:007:3 0:128 8 = a1000000 01000000 S Ii:11:007:3 -115:128 16 < C Ii:11:007:3 0:128 16 = a12a0000 01000800 00000000 00000000 Most xHCI host controllers neglect interrupt bandwidth reservations and let such devices exceed theirs, some fail the URB with EOVERFLOW. Assume that wBytesPerInterval lower than wMaxPacketSize is bogus and increase it to the worst case maximum on interrupt IN endpoints. This solves xHCI problems and appears to have no other effect. Interrupt transfers are not limited to one interval and drivers submit URBs of class defined size without looking at wBytesPerInterval. Any multi- interval transfer is considered terminated by a packet shorter than wMaxPacketSize regardless of wBytesPerInterval - see USB3 8.10.3. Stay in spec on OUT endpoints and isochronous. No buggy devices are known and we don't want to risk sending more data than the device is prepared to handle or confusing isoc drivers regarding altsetting capacities guaranteed by the device itself. And don't complain when wMaxPacketSize <= wBytesPerInterval < wMaxPacketSize * (bMaxBurst+1) because enabling this seems to be the exact goal of the spec. Reported-and-tested-by: Tao Xue Closes: https://lore.kernel.org/linux-usb/20260402021400.28853-1-xuetao09@huawei.com/ Cc: stable@vger.kernel.org Signed-off-by: Michal Pecio Link: https://patch.msgid.link/20260518073207.5b7d26e7.michal.pecio@gmail.com Signed-off-by: Greg Kroah-Hartman commit 7118304b1a776d915147f367da5b273ee38737ec Author: Xu Yang Date: Mon Apr 27 15:57:55 2026 +0800 usb: chipidea: core: convert ci_role_switch to local variable commit 8f6aa392653e52a45858cff5c063df550028836b upstream. When a system contains multiple USB controllers, the global ci_role_switch variable may be overwritten by subsequent driver initialization code. This can cause issues in the following cases: - The 2nd ci_hdrc_probe() sees ci_role_switch.fwnode as non-NULL even though the "usb-role-switch" property is not present for the controller. - When the ci_hdrc device is unbound and bound again, ci_role_switch fwnode will not be reassigned, and the old value will be used instead. Convert ci_role_switch to a local variable to fix these issues. Fixes: 05559f10ed79 ("usb: chipidea: add role switch class support") Cc: stable Acked-by: Peter Chen Reviewed-by: Frank Li Signed-off-by: Xu Yang Link: https://patch.msgid.link/20260427075755.3611217-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman commit 9fd48937046efc9abb89379d63ee9cc5c661d711 Author: Tudor Ambarus Date: Fri May 15 12:41:21 2026 +0000 tty: serial: samsung: Remove redundant port lock acquisition in rx helpers commit a3bb136bff5e6a5e48cdd813246c9c4686feaaa9 upstream. Sashiko identified a deadlock when the console flow is engaged [1]. When console flow control is enabled (UPF_CONS_FLOW), s3c24xx_serial_stop_tx() calls s3c24xx_serial_rx_enable() and s3c24xx_serial_start_tx() calls s3c24xx_serial_rx_disable(). The serial core framework invokes the .stop_tx() and .start_tx() callbacks with the port->lock spinlock already held. Furthermore, all internal driver paths that invoke stop_tx (such as the DMA TX completion handler s3c24xx_serial_tx_dma_complete() or the PIO TX IRQ handler s3c24xx_serial_tx_irq()) also acquire port->lock prior to calling it. (Note that s3c24xx_serial_start_tx() is only invoked by the serial core). However, s3c24xx_serial_rx_enable() and s3c24xx_serial_rx_disable() unconditionally attempt to acquire port->lock again using uart_port_lock_irqsave(). Since spinlocks are not recursive, this causes a deadlock on the same CPU when console flow control is engaged. Remove the redundant lock acquisition from both rx helper functions. Cc: stable Fixes: b497549a035c ("[ARM] S3C24XX: Split serial driver into core and per-cpu drivers") Reported-by: John Ogness Closes: https://sashiko.dev/#/patchset/20260506121606.5805-1-john.ogness%40linutronix.de [1] Signed-off-by: Tudor Ambarus Link: https://patch.msgid.link/20260515-samsung-tty-flow-control-deadlock-v1-1-93255edbc9bc@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 66f8bfea055b23719b4fd6ce207c44de37d82a59 Author: Zhaoyang Yu <2426767509@qq.com> Date: Thu Apr 9 13:41:58 2026 +0800 tty: serial: pch_uart: add check for dma_alloc_coherent() commit 6fe472c1bbbe238e91141f7cabc1226e96a60d43 upstream. Add a check for dma_alloc_coherent() failure to prevent a potential NULL pointer dereference in dma_handle_rx(). Properly release DMA channels and the PCI device reference using a goto ladder if the allocation fails. Fixes: 3c6a483275f4 ("Serial: EG20T: add PCH_UART driver") Cc: stable Signed-off-by: Zhaoyang Yu <2426767509@qq.com> Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/tencent_E328416B7CFD436F6029F2DF02AD7ED89C08@qq.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit b4bebb6e0a449ec1c621e1e7df682c402f386a1f Author: Guangshuo Li Date: Mon Apr 13 21:46:04 2026 +0800 counter: Fix refcount leak in counter_alloc() error path commit d9eeb0ea0d2de658663bfaa9c26eccdd8fd64440 upstream. After device_initialize(), the lifetime of the embedded struct device is expected to be managed through the device core reference counting. In counter_alloc(), if dev_set_name() fails after device_initialize(), the error path removes the chrdev, frees the ID, and frees the backing allocation directly instead of releasing the device reference with put_device(). This bypasses the normal device lifetime rules and may leave the reference count of the embedded struct device unbalanced, resulting in a refcount leak. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fix this by using put_device() in the dev_set_name() failure path and let counter_device_release() handle the final cleanup. Fixes: 4da08477ea1f ("counter: Set counter device name") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Link: https://lore.kernel.org/r/20260413134604.2861772-1-lgs201920130244@gmail.com Signed-off-by: William Breathitt Gray Signed-off-by: Greg Kroah-Hartman commit c7e670cb2538d7b3a1a1cdc87764b26464a72bdc Author: Ian Abbott Date: Wed Apr 22 15:46:37 2026 +0100 comedi: comedi_test: Fix limiting of convert_arg in waveform_ai_cmdtest() commit 8a3bee801d420be8a7a0bae4a26547b353b8fe22 upstream. The function checks and possibly modifies the description of an asynchronous command to be run on the analog input subdevice of a comedi device attached to the "comedi_test" driver, returning 0 if no modifications were required, or a positive value that indicates which step of the checking process it failed on. Step 4 fixes up various argument values for various trigger sources. There are two bugs in the fixing up of the `convert_arg` value to keep the `scan_begin_arg` value within the range of `unsigned int` when `scan_begin_src` and `convert_src` both have the value `TRIG_TIMER`, which indicates that the corresponding `_arg` values hold a time period in nanoseconds. The code also uses `scan_end_arg` which hold the number of "conversions" within each "scan". The goal is to end up with the scan period being less than or equal to the convert period multiplied by the number of conversions per scan. It intends to do that by clamping the `convert_arg` value to a maximum value of `UINT_MAX / scan_end_arg` rounded down to a multiple of 1000 (`NSEC_PER_USEC`). (The rounding from nanoseconds to microseconds is because the driver is modelling a device that uses a 1 MHz clock for timing. This is partly because that is a more typical timing base for real hardware devices driven by comedi, and partly because the driver used to use `struct timeval` internally.) The first bug is that the code checks if `scan_begin_arg == TRIG_TIMER` when it should be checking if `scan_begin_src == TRIG_TIMER`. The bugged check will always fail because if `scan_begin_src == TRIG_TIMER`, then `scan_begin_arg` will be at least 1000 (`NSEC_PER_USEC`), otherwise `scan_begin_src == TRIG_FOLLOW` and `scan_begin_arg` will be 0. (N.B `TRIG_TIMER` is defined as `0x10`.) The second bug is that is rounding the maximum value down to a multiple of 1000000000 (`NSEC_PER_SEC`) instead of 1000 (`NSEC_PER_USEC`), however this bug is not reached due to the first bug. This patch fixes both bugs. Fixes: 783ddaebd397 ("staging: comedi: comedi_test: support scan_begin_src == TRIG_FOLLOW") Fixes: 5afdcad2f818 ("staging: comedi: comedi_test: limit maximum convert_arg") Cc: stable Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260422144637.27692-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 269f5be6a6e4a8dd511887181d83c4b1a1f34d57 Author: Ian Abbott Date: Wed Apr 22 17:21:19 2026 +0100 comedi: comedi_test: fix check for valid scan_begin_src in waveform_ai_cmdtest() commit 542f5248cb481073203e0dadab5bcbd28aeae308 upstream. Commit 783ddaebd397 ("staging: comedi: comedi_test: support scan_begin_src == TRIG_FOLLOW") neglected to add a test that `scan_begin_src` has only one bit set. The allowed values are `TRIG_FOLLOW` and `TRIG_TIMER`, but the code incorrectly also allows `TRIG_FOLLOW | TRIG_TIMER`. Add a call to `comedi_check_trigger_is_unique()` to check that only one trigger source bit is set. Fixes: 783ddaebd397 ("staging: comedi: comedi_test: support scan_begin_src == TRIG_FOLLOW") Cc: stable Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260422162138.36003-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit fdb74898d91d7871e85d752d33bb61d336301d93 Author: Nicolás Bazaes Date: Wed May 13 21:35:49 2026 -0400 Input: synaptics - add LEN2058 to SMBus passlist for ThinkPad E490 commit 16ca52bc209fa4bf9239cd9e5643e95533476b58 upstream. The Lenovo ThinkPad E490 (PNP ID: LEN2058) has a Synaptics TM3471-020 touchpad that supports SMBus/RMI4 mode but is not listed in smbus_pnp_ids[]. Without this entry, RMI4 over SMBus is not enabled by default, and the touchpad falls back to PS/2 mode. Adding LEN2058 to the passlist enables automatic RMI4 detection without requiring the psmouse.synaptics_intertouch parameter, and matches the behavior of similar ThinkPad models already in the list (E480/LEN2054, E580/LEN2055). Tested on ThinkPad E490 with kernel 7.0.5-zen1 and Arch Linux. RMI4 over SMBus is confirmed working without any kernel parameters. Signed-off-by: Nicolás Bazaes Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/20260514013552.14234-1-contacto@bazaes.cl Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 7f95f4792c0dc767fcb8e405391e779ab419d55a Author: Dmitry Torokhov Date: Mon May 4 11:54:45 2026 -0700 Input: atmel_mxt_ts - fix boundary check in mxt_prepare_cfg_mem commit baa0210fb6a9dc3882509a9411b6d284d88fe30e upstream. When a configuration file provides an object size that is larger than the driver's known mxt_obj_size(object), the driver intends to discard the extra bytes. The loop iterates using for (i = 0; i < size; i++). Inside the loop, the condition to skip processing extra bytes is: if (i > mxt_obj_size(object)) continue; Since i is a 0-based index, the valid indices for the object are 0 through mxt_obj_size(object) - 1. When i == mxt_obj_size(object), the condition evaluates to false, and the code processes the byte instead of discarding it. This causes the code to calculate byte_offset = reg + i - cfg->start_ofs and writes the byte there, overwriting exactly one byte of the adjacent instance or object. Update the boundary check to skip extra bytes correctly by using >=. Fixes: 50a77c658b80 ("Input: atmel_mxt_ts - download device config using firmware loader") Cc: stable@vger.kernel.org Assisted-by: Gemini:gemini-3.1-pro Reviewed-by: Ricardo Ribalda Link: https://patch.msgid.link/20260504185448.4055973-1-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 639fa8af506ec96cd1292d580f598e93a1939c88 Author: Xiaolei Wang Date: Mon May 18 15:34:05 2026 +0800 misc: rp1: Send IACK on IRQ activate to fix kdump/kexec commit 36770417153644bc88281c7284730ef1d14d8d3c upstream. After a kexec/kdump reboot, the macb Ethernet controller fails to receive any packets, causing DHCP to hang indefinitely and the network interface to be unusable despite link being up. The root cause is that RP1's level-triggered MSI-X interrupt sources (such as macb on hwirq 6) may have their internal state machines stuck in the "waiting for IACK" state. This happens because the previous kernel crashed before sending the acknowledgment for a pending level interrupt. In this stuck state, RP1 will not generate new MSI-X writes even though the interrupt source remains asserted. Since no new MSI-X is sent, the GIC never sees a new edge, the chained IRQ handler is never invoked, and the interrupt is permanently lost. Fix this by sending MSIX_CFG_IACK in rp1_irq_activate(). This unconditionally resets the MSI-X state machine back to idle when a child device requests its interrupt. If the interrupt source is still asserted, RP1 will immediately issue a new MSI-X with the freshly configured msg_addr/msg_data, and normal interrupt delivery resumes. Writing IACK when the state machine is already idle (i.e., on a normal cold boot) is harmless — it has no effect. Fixes: 49d63971f963 ("misc: rp1: RaspberryPi RP1 misc driver") Cc: stable Signed-off-by: Xiaolei Wang Link: https://patch.msgid.link/20260518073405.2115003-1-xiaolei.wang@windriver.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 94215d55b09445993929f4fc966061d61de74929 Author: Ali Ganiyev Date: Mon May 25 10:23:47 2026 +0900 ksmbd: OOB read regression in smb_check_perm_dacl() ACE-walk loops commit 0e60dafe97eca61721f3db456f97d97a80c6c8ae upstream. Commit d07b26f39246 ("ksmbd: require minimum ACE size in smb_check_perm_dacl()") introduced a transposed bounds check: if (offsetof(struct smb_ace, sid) + aces_size < CIFS_SID_BASE_SIZE) Since offsetof(..sid) is 8 and CIFS_SID_BASE_SIZE is 8, this evaluates to `aces_size < 0`. Because `aces_size` is always non-negative, this check becomes dead code and never breaks the loop. Worse, that commit removed the old 4-byte guard, meaning the loop now reads `ace->size` (offset 2) even when `aces_size` is 0-3 bytes. This re-opens a 2-byte heap out-of-bounds (OOB) read past the pntsd allocation during subsequent SMB2_CREATE operations. Fix this by properly transposing the comparison to require at least 16 bytes (8-byte offset + 8-byte SID base), matching the correct form used in smb_inherit_dacl(). Fixes: d07b26f39246 ("ksmbd: require minimum ACE size in smb_check_perm_dacl()") Cc: stable@vger.kernel.org Signed-off-by: Ali Ganiyev Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 6617ee91062bc2099a37da8e1404e5d183058928 Author: Dmitriy Zharov Date: Thu Apr 30 22:35:22 2026 +0400 Input: xpad - add support for ASUS ROG RAIKIRI II commit c897cf120696b94f56ed0f3197ba9a77071a59ec upstream. Add the VID/PIDs for the ASUS ROG RAIKIRI II controller to xpad_device and the VID to xpad_table. The controller has a physical PC/XBOX toggle which switches between XBOX360 and XBOXONE protocols. Signed-off-by: Dmitriy Zharov Link: https://patch.msgid.link/20260430183522.122151-1-contact@zharov.dev Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 3d63b8077f5bd177c8f9c852a2e095dd8b52c452 Author: Qbeliw Tanaka Date: Thu Apr 30 21:44:12 2026 -0700 Input: xpad - add "Nova 2 Lite" from GameSir commit 1f6ac0f8441c48c4cc250141e1da8486c13512ba upstream. Add support for the gamepad "Nova 2 Lite" from GameSir, compatible with the Xbox 360 gamepad. Signed-off-by: Qbeliw Tanaka Link: https://patch.msgid.link/20260429.162040.930225048583399359.q.tanaka@gmx.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 2ffd8b0dd4484b92325d3f7e098cdb66adff2ca2 Author: Zhang Heng Date: Tue May 26 09:36:11 2026 +0800 ALSA: hda/realtek: Fix speaker output on ASUS ROG Strix G615LP commit 20587302f8d700f26ee2c8a60ffb0a69ae0edf16 upstream. Add quirk for ALC294 codec on ASUS ROG Strix G615LP (SSID 1043:1214) using ALC287_FIXUP_TXNW2781_I2C_ASUS to fix speaker output. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221173 Cc: Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260526013611.1954949-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c093468aea8277f77272a4f199b2e15e19cabb59 Author: Jingguo Tan Date: Mon May 18 17:06:48 2026 +0800 xfrm: esp: restore combined single-frag length gate commit dfa0d7b0ff1eb6b2c416b8fdb9b4f2cefba57a40 upstream. The ESP out-of-place fast path appends the trailer in esp_output_head() before esp_output_tail() allocates the destination page frag. The head-side gate currently checks skb->data_len and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->data_len. Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skb_page_frag_refill() may fall back to a single page while the destination sg still spans the combined skb->data_len. Restore this combined-length page gate for both IPv4 and IPv6. Fixes: 5bd8baab087d ("esp: limit skb_page_frag_refill use to a single page") Cc: stable@vger.kernel.org Signed-off-by: Lin Ma Signed-off-by: Chenyuan Mi Signed-off-by: Jingguo Tan Reviewed-by: Sabrina Dubroca Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit c4609fff0665e8ec0e198aa43a0934dfe338e0c8 Author: Srinivas Kandagatla Date: Mon May 18 09:23:43 2026 +0000 ASoC: qcom: q6asm-dai: do not set stream state in event and trigger callbacks commit cee3e63e7106c3c81b2053371fdf14240bfba2fc upstream. The q6asm-dai stream state is used by prepare() to decide whether an existing stream setup needs to be closed before opening/configuring a new one. Updating the state from trigger or asynchronous DSP callbacks can make that state stale or incorrect relative to the actual setup lifetime. In particular, setting Q6ASM_STREAM_STOPPED on STOP or EOS completion can make prepare() believe there is no active setup to close, which can result in opening/configuring the same stream more than once. Keep stream state updates tied to prepare(), where the stream is actually closed and reopened, and stop changing it from trigger and EOS callbacks. Fixes: bfbb12dfa144 ("ASoC: qcom: q6asm-dai: perform correct state check before closing") Cc: Stable@vger.kernel.org Closes: https://lore.kernel.org/all/afS7rTHdc9TyIeLx@rdacayan/ Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260518092347.3446946-2-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 35be14ea82982c2304b7d8a853957e0dd7537d77 Author: Srinivas Kandagatla Date: Mon May 18 09:23:44 2026 +0000 ASoC: qcom: q6asm-dai: close stream only when running commit 048c540ee76ded666bda74f9dae1ca3254e0633c upstream. q6asm_dai_close() and q6asm_dai_compr_free() currently issue CMD_CLOSE whenever prtd->state is non-zero. After prepare() closes an existing stream, the state is updated to Q6ASM_STREAM_STOPPED. Since this state is also non-zero, the close and free paths can send CMD_CLOSE again for a stream that has already been closed. Restrict CMD_CLOSE to the Q6ASM_STREAM_RUNNING state so the command is sent only when the ASM stream is still active. Fixes: 2a9e92d371db ("ASoC: qdsp6: q6asm: Add q6asm dai driver") Cc: Stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260518092347.3446946-3-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b98ab51c45c5608a1c19ce7fd17a3032469bb83f Author: Hamza Mahfooz Date: Mon May 11 10:43:14 2026 -0400 netfilter: conntrack: tcp: do not force CLOSE on invalid-seq RST without direction check commit bed6e04be8e6b9133d8b16d5a42d0e0ce674fa9a upstream. An unintended behavior in the TCP conntrack state machine allows a connection to be forced into the CLOSE state using an RST packet with an invalid sequence number. Specifically, after a SYN packet is observed, an RST with an invalid SEQ can transition the conntrack entry to TCP_CONNTRACK_CLOSE, regardless of whether the RST corresponds to the expected reply direction. The relevant code path assumes the RST is a response to an outgoing SYN, but does not validate packet direction or ensure that a matching SYN was actually sent in the opposite direction. As a result, a crafted packet sequence consisting of a SYN followed by an invalid-sequence RST can prematurely terminate an active NAT entry. This makes connection teardown easier than intended. So, tighten the state transition logic to ensure that RST-triggered CLOSE transitions only occur when the RST is a valid response to a previously observed SYN in the correct direction. Cc: stable@vger.kernel.org Fixes: 9fb9cbb1082d ("[NETFILTER]: Add nf_conntrack subsystem.") Signed-off-by: Hamza Mahfooz Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit b9027ff112b693b2e0a63d73626ce360720edc0d Author: Cássio Gabriel Date: Thu May 21 08:01:23 2026 -0300 ALSA: firewire-motu: Protect register DSP event queue positions commit 98fb1c1bb11e29eb609b7200a25e136e05aa4498 upstream. The register DSP event queue is updated under parser->lock, but snd_motu_register_dsp_message_parser_count_event() reads pull_pos and push_pos without the lock. snd_motu_register_dsp_message_parser_copy_event() also reads both queue positions before taking the lock. Protect these accesses with parser->lock as well. This keeps the hwdep poll/read path consistent with the producer side and with the cached meter/parameter accessors. Fixes: 634ec0b2906e ("ALSA: firewire-motu: notify event for parameter change in register DSP model") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Reviewed-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260521-alsa-firewire-motu-event-locking-v1-1-708e1c2b5e56@gmail.com Signed-off-by: Greg Kroah-Hartman commit befcb15c1f05e87d3072d68a02b5b9c80322cfb9 Author: Geoffrey D. Bennett Date: Sun May 24 06:34:14 2026 +0930 ALSA: scarlett2: Fix 2i2 Gen 4 direct monitor gain on firmware 2417 commit db37cf47b67e38ade40de5cd74a4d4d772ff1416 upstream. Firmware 2417 for the Scarlett 4th Gen 2i2 moved the direct monitor gain parameter by 4 bytes, from offset 0x2a0 to 0x2a4, breaking the "Direct Monitor X Mix Y" controls. Special-case the offset in the get/set config helpers when the running firmware is 2417 or later. Fixes: 4e809a299677 ("ALSA: scarlett2: Add support for Solo, 2i2, and 4i4 Gen 4") Cc: Signed-off-by: Geoffrey D. Bennett Link: https://patch.msgid.link/ahIWTueUlWA5xiV+@m.b4.vu Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit aa0c7e59192b158c28525d065d343ebc7fe65c18 Author: Michael Bommarito Date: Fri May 15 11:45:31 2026 -0400 xfrm: ah: use skb_to_full_sk in async output callbacks commit 79d8be262377f7112cfa3088dfc4142d5a2533f3 upstream. When AH output is offloaded to an asynchronous crypto provider (hardware accelerators such as AMD CCP, or a forced-async software shim used for testing), the digest completion fires ah_output_done() / ah6_output_done() on a workqueue. The egress skb at that point may have been originated by a TCP listener sending a SYN-ACK, which sets skb->sk to a request_sock via skb_set_owner_edemux(); it may also have been originated by an inet_timewait_sock retransmit. Neither is a full struct sock, and passing the raw skb->sk to xfrm_output_resume() then forwards a non-full socket through the rest of the xfrm output chain. xfrm_output_resume() and its downstream consumers expect a full sk where they dereference at all. The natural egress path through ah_output_done() does not crash today because the consumers that read past sock_common are either gated by sk_fullsock() or short-circuit on flags that are clear on a fresh request_sock; an exhaustive walk of the 50 most plausible consumers under sch_fq, dev_queue_xmit, netfilter, tc-egress and cgroup-egress BPF found no current unguarded deref. The bug is still a real type confusion that future consumer changes could turn into a memory-corruption primitive. This is the same bug class fixed for ESP in commit 1620c88887b1 ("xfrm: Fix the usage of skb->sk"). Apply the analogous fix to AH: convert skb->sk to a full socket pointer (or NULL) via skb_to_full_sk() before handing it to xfrm_output_resume(). The same async AH callbacks were touched recently for an independent ESN-related ICV layout bug in commit ec54093e6a8f ("xfrm: ah: account for ESN high bits in async callbacks"); the sk type-confusion addressed here is orthogonal. This patch is part of an ongoing audit of the AH callback paths; an ah_output ihl-validation hardening series is also currently under review on netdev. Reproduced under UML + KASAN + lockdep with a forced-async hmac(sha1) shim that registers at priority 9999 and wraps the sync in-tree hmac-sha1-lib. With the shim loaded, ah_output_done runs on every SYN-ACK egress through a transport-mode AH SA and skb->sk arrives as a request_sock (TCP_NEW_SYN_RECV); after this patch, xfrm_output_resume() receives the listener (the result of sk_to_full_sk()) and consumer derefs land on full-sock fields as intended. Fixes: 9ab1265d5231 ("xfrm: Use actual socket sk instead of skb socket for xfrm_output_resume") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit dc6dcba80d72a27ab61831ad3d253316e0c9b9d5 Author: Herbert Xu Date: Wed May 6 21:23:28 2026 +0800 xfrm: ipcomp: Free destination pages on acomp errors commit 7dbac7680eb629b3b4dc7e98c34f943b8814c0c8 upstream. Move the out_free_req label up by a couple of lines so that the allocated dst SG list gets freed on error as well as success. Fixes: eb2953d26971 ("xfrm: ipcomp: Use crypto_acomp interface") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Reported-by: Yilin Zhu Signed-off-by: Herbert Xu Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 448bb92ca101dde8a6e88b4dc824044b4e341604 Author: Maoyi Xie Date: Mon May 4 22:27:36 2026 +0800 xfrm: route MIGRATE notifications to caller's netns commit 7e2a4f7ca0952820731ef7bdadfc9a9e9d3571b4 upstream. xfrm_send_migrate() in net/xfrm/xfrm_user.c and pfkey_send_migrate() in net/key/af_key.c both hardcode &init_net for the multicast that announces a successful XFRM_MSG_MIGRATE / SADB_X_MIGRATE. XFRM_MSG_MIGRATE arrives on a per-netns NETLINK_XFRM socket, and the rest of the xfrm/af_key netlink path was made netns-aware in 2008. The other 14 multicast paths in xfrm_user.c route their event using xs_net(x), xp_net(xp) or sock_net(skb->sk); only the migrate path was missed. Two consequences of the init_net hardcoding: 1. The notification (selector, old/new endpoint addresses, and the km_address) is delivered to listeners on init_net's XFRMNLGRP_MIGRATE / pfkey BROADCAST_ALL groups rather than on the issuing netns. An IKE daemon running in init_net therefore receives migration notifications originating from any other netns on the host. 2. An IKE daemon running inside a non-init netns and subscribed to its own XFRMNLGRP_MIGRATE / pfkey groups never receives the notification of its own migration. IKEv2 MOBIKE / address-update handling inside a netns is silently broken. Thread struct net through km_migrate() and the xfrm_mgr.migrate function pointer, drop the &init_net override in xfrm_send_migrate() and pfkey_send_migrate(), and pass the caller's net (already in scope in xfrm_migrate() via sock_net(skb->sk)) all the way down. struct xfrm_mgr is in-tree only and not exported as a stable API, so the function-pointer signature change is internal. pfkey_broadcast() is already netns-aware via net_generic(net, pfkey_net_id) since the pernet conversion. The five other pfkey_broadcast() callers in af_key.c already pass xs_net(x), sock_net(sk) or a per-netns net, so this only removes the &init_net outlier. Fixes: 5c79de6e79cd ("[XFRM]: User interface for handling XFRM_MSG_MIGRATE") Cc: stable@vger.kernel.org # v5.15+ Signed-off-by: Maoyi Xie Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 22d41b176b9989efd21c3b2d3abf6728f05b9d9a Author: Ashutosh Desai Date: Tue May 5 17:07:12 2026 +0000 nfc: hci: fix out-of-bounds read in HCP header parsing commit f040e590c035bfd9553fe79ee9585caf1b14d67b upstream. Both nfc_hci_recv_from_llc() and nci_hci_data_received_cb() read packet->header from skb->data at function entry without first checking that the buffer holds at least one byte. A malicious NFC peer can send a 0-byte HCP frame that passes through the SHDLC layer and reaches these functions, causing an out-of-bounds heap read of packet->header. The same 0-byte frame, if queued as a non-final fragment, also causes the reassembly loop to underflow msg_len to UINT_MAX, triggering skb_over_panic() when the reassembled skb is written. Fix this by adding a pskb_may_pull() check at the entry of each function before packet->header is first accessed. The existing pskb_may_pull() checks before the reassembled hcp_skb is cast to struct hcp_packet remain in place to guard the 2-byte HCP message header. Fixes: 8b8d2e08bf0d ("NFC: HCI support") Fixes: 11f54f228643 ("NFC: nci: Add HCI over NCI protocol support") Cc: stable@vger.kernel.org Reviewed-by: Simon Horman Signed-off-by: Ashutosh Desai Link: https://patch.msgid.link/20260505170712.96560-1-ashutoshdesai993@gmail.com Signed-off-by: David Heidelberg Signed-off-by: Greg Kroah-Hartman commit 8b1f4f618fd8531744e87abc1eb5bab2193e6356 Author: Arnd Bergmann Date: Wed May 13 16:53:54 2026 +0200 iommu, debugobjects: avoid gcc-16.1 section mismatch warnings commit 4c9ad387aa2d6785299722e54224d34764edaeb3 upstream. gcc-16 has gained some more advanced inter-procedual optimization techniques that enable it to inline the dummy_tlb_add_page() and dummy_tlb_flush() function pointers into a specialized version of __arm_v7s_unmap: WARNING: modpost: vmlinux: section mismatch in reference: __arm_v7s_unmap+0x2cc (section: .text) -> dummy_tlb_add_page (section: .init.text) ERROR: modpost: Section mismatches detected. >From what I can tell, the transformation is correct, as this is only called when __arm_v7s_unmap() is called from arm_v7s_do_selftests(), which is also __init. Since __arm_v7s_unmap() however is not __init, gcc cannot inline the inner function calls directly. In debug_objects_selftest(), the same thing happens. Both the caller and the leaf function are __init, but the IPA pulls it into a non-init one: WARNING: modpost: vmlinux: section mismatch in reference: lookup_object_or_alloc+0x7c (section: .text.lookup_object_or_alloc) -> is_static_object (section: .init.text) Marking the affected functions as not "__init" would reliably avoid this issue but is not a good solution because it removes an otherwise correct annotation. I tried marking the functions as 'noinline', but that ended up not covering all the affected configurations. With some more experimenting, I found that marking these functions as __attribute__((noipa)) is both logical and reliable. In order to keep the syntax readable, add a custom macro for this in include/linux/compiler_attributes.h next to other related macros and use it to annotate both files. Link: https://lore.kernel.org/all/abRB6g-48ZX6Yl2r@willie-the-truck/ Cc: Will Deacon Cc: Thomas Gleixner Cc: Andrew Morton Cc: Miguel Ojeda Cc: linux-kbuild@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann Acked-by: Will Deacon Acked-by: Thomas Gleixner Acked-by: Miguel Ojeda Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit b8338111e14183972359009c12d0dbd81d2e1e16 Author: Lee Jones Date: Wed May 27 17:05:26 2026 +0100 HID: wacom: Fix OOB write in wacom_hid_set_device_mode() commit c0a8899e02ddebd51e2589835182c239c2e224ae upstream. wacom_hid_set_device_mode() currently assumes that the HID_DG_INPUTMODE usage is always located in the first field (field[0]) of the feature report. However, a device can specify HID_DG_INPUTMODE in a different field. If HID_DG_INPUTMODE is in a field other than the first one and the first field has a report_count smaller than the usage_index of HID_DG_INPUTMODE, this leads to an out-of-bounds write to r->field[0]->value. Fix this by storing the field index of HID_DG_INPUTMODE in 'struct hid_data' during feature mapping. In wacom_hid_set_device_mode(), use this stored field index to access the correct field and add bounds checks to ensure both the field index and the value index are within valid ranges before writing. Cc: stable@vger.kernel.org Fixes: 5ae6e89f7409 ("HID: wacom: implement the finger part of the HID generic handling") Tested-by: Ping Cheng Reviewed-by: Ping Cheng Signed-off-by: Lee Jones Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 59139473a7a73647830a09edddf847888496511b Author: Santhosh Kumar K Date: Wed May 27 23:07:36 2026 +0530 spi: spi-mem: avoid mutating op template in spi_mem_supports_op() commit 79378db6a86c7014cce40b65252e6c18f5b8bcc2 upstream. spi_mem_supports_op() accepts a const struct spi_mem_op pointer but casts away const internally to call spi_mem_adjust_op_freq(). This mutates the caller's op template, which causes stale max_freq values when callers reuse persistent templates - subsequent calls won't re-apply the device frequency cap since spi_mem_adjust_op_freq() skips non-zero values. Fix by operating on a stack-local copy instead. Fixes: a4f8e70d75dd ("spi: spi-mem: add spi_mem_adjust_op_freq() in spi_mem_supports_op()") Cc: Tianyu Xu Cc: stable@vger.kernel.org Signed-off-by: Santhosh Kumar K Reviewed-by: Miquel Raynal Link: https://patch.msgid.link/20260527173736.2243004-1-s-k6@ti.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 96a4713ae041cc85e712bac682cd2e644004d6c6 Author: Minh Nguyen Date: Tue May 26 11:12:39 2026 +0700 net: skbuff: fix missing zerocopy reference in pskb_carve helpers commit 98d0912e9f841e5529a5b89a972805f34cb1c69d upstream. pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy the old skb_shared_info header into a new buffer via memcpy(), which includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs. Neither function calls net_zcopy_get() for the new shinfo, creating an unaccounted holder: every skb_shared_info with destructor_arg set will call skb_zcopy_clear() once when freed, but the corresponding net_zcopy_get() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while TX skbs still hold live destructor_arg pointers. KASAN reports use-after-free on a freed ubuf_info_msgzc: BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220 Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180 Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0 Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530 The skb consuming the late access still referenced the same uarg via shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration. The fix follows the pattern of pskb_expand_head() which has the same memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get() is placed after skb_orphan_frags() succeeds, so the orphan error path needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is placed after all failure points and just before skb_release_data(), so no error path needs cleanup at all -- matching pskb_expand_head() more closely and avoiding the need for a balancing net_zcopy_put(). Fixes: 6fa01ccd8830 ("skbuff: Add pskb_extract() helper function") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Minh Nguyen Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260526041240.329462-1-minhnguyen.080505@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit fc32be9ac2788524c6b24efd681cce7a6e731a92 Author: Kuniyuki Iwashima Date: Thu May 21 21:05:54 2026 +0800 ip6: vti: Use ip6_tnl.net in vti6_changelink(). commit 11b326fb0a374f4654f9be22d0f0f7abd9f7d3fe upstream. ip netns add ns1 ip netns add ns2 ip -n ns1 link add vti6_test type vti6 remote ::1 local ::2 key 7 ip -n ns1 link set vti6_test netns ns2 ip -n ns2 link set vti6_test type vti6 remote ::3 local ::4 key 9 ip netns del ns2 ip netns del ns1 [ 132.495484] ------------[ cut here ]------------ [ 132.497609] kernel BUG at net/core/dev.c:12376! Commit 61220ab34948 ("vti6: Enable namespace changing") dropped NETIF_F_NETNS_LOCAL from vti6 devices. A vti6 tunnel can then move through IFLA_NET_NS_FD. After the move dev_net(dev) points at the new netns while t->net stays at the creation netns. vti6_changelink() and vti6_update() still use dev_net(dev) and dev_net(t->dev). They unlink from one per netns hash and relink into another. The creation netns is left with a stale entry. cleanup_net() of that netns later walks freed memory. Reachable from an unprivileged user namespace (unshare --user --map-root-user --net). Cross tenant scope on container hosts. Fixes: 61220ab34948 ("vti6: Enable namespace changing") Reported-by: Maoyi Xie Reviewed-by: Eric Dumazet Cc: stable@vger.kernel.org # v5.15+ Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260521130555.3421684-2-maoyixie.tju@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 947013fd7c8c35dd5856557b215840098a3f67f8 Author: Michael Bommarito Date: Fri May 22 22:34:23 2026 -0400 l2tp: use refcount_inc_not_zero in l2tp_session_get_by_ifname commit 05f95729ca844704d15e49ce14868af4b403b32b upstream. A reader in l2tp_session_get_by_ifname() can return a pointer to a session whose refcount has reached zero. The getter takes its reference with plain refcount_inc(), but every other session getter in the same file (l2tp_v2_session_get, l2tp_v3_session_get, and the corresponding _get_next variants) uses refcount_inc_not_zero() because the IDR/RCU lookup can race with refcount_dec_and_test() -> l2tp_session_free() -> kfree_rcu(). The ifname getter is the only outlier; the inconsistency was raised on-list after 979c017803c4 ("l2tp: use list_del_rcu in l2tp_session_unhash"). A reader inside rcu_read_lock_bh() that matches session->ifname can be preempted between the strcmp() and the refcount_inc(). If the last reference drops on another CPU in that window, the reader's refcount_inc() runs on a counter that has reached zero. refcount_t catches the addition-on-zero, prints "refcount_t: addition on 0; use-after-free", saturates the counter, and returns the saturated pointer to the caller. Session memory is held live by the in-flight RCU read section, but the kfree_rcu() callback queued from l2tp_session_free() will free it once the grace period closes; a caller that dereferences the returned session past that point hits a slab-use-after-free. On PREEMPT_RT local_bh_disable() is a per-CPU sleeping lock and the preemption window is real; on stock PREEMPT kernels local_bh_disable() is a preempt_count increment that closes the cross-CPU race in practice (see below). Use refcount_inc_not_zero() and continue the list walk on failure, matching the other session getters in the file. The ifname getter is the only session getter in net/l2tp/ that still uses the bare refcount_inc() pattern; this change restores file-internal consistency. The success path is unchanged. Fixes: abe7a1a7d0b6 ("l2tp: improve tunnel/session refcount helpers") Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Reviewed-by: James Chapman Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260523023423.2568972-1-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9f7ebb45a83afc3216e855e57d51bb4bc9b5232e Author: Zhengchuan Liang Date: Fri May 22 17:31:55 2026 +0800 xfrm: input: hold netns during deferred transport reinjection commit c16f74dc1d75d0e2e7670076d5375deda110ebeb upstream. Transport-mode reinjection stores a struct net pointer in skb->cb and uses it later from xfrm_trans_reinject(). That pointer must stay valid until the deferred callback runs. Take a netns reference when queueing deferred reinjection work and drop it after the callback completes. Use maybe_get_net() so the queueing path does not revive a namespace that is already being torn down. This keeps the existing workqueue design and fixes the netns lifetime handling in one place for all users of xfrm_trans_queue_net(). Fixes: 7b3801927e52 ("xfrm: introduce xfrm_trans_queue_net") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Xin Liu Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Signed-off-by: Zhengchuan Liang Signed-off-by: Ren Wei Assisted-by: Codex:gpt-5.4 Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit a35daeabb433686234b010ebf7b53778dbd6c9b8 Author: Qi Tang Date: Sat May 23 22:32:45 2026 +0800 ipv6: validate extension header length before copying to cmsg commit dd433671fef381fdaf7b530c631e6b782d66e224 upstream. ip6_datagram_recv_specific_ctl() builds IPV6_{HOPOPTS,DSTOPTS,RTHDR} cmsgs (and their IPV6_2292* legacy counterparts) by trusting the on-wire hdrlen byte (ptr[1]) when computing the put_cmsg() length. The length was validated only at parse time (ipv6_parse_hopopts(), etc.). An nftables payload-write expression can rewrite hdrlen after parsing and before the skb reaches recvmsg; the write itself is in-bounds but put_cmsg() then reads up to ((hdrlen+1) << 3) = 2040 bytes from an 8-byte header. nftables is reachable from an unprivileged user namespace, so this is an unprivileged slab-out-of-bounds read: BUG: KASAN: slab-out-of-bounds in put_cmsg+0x3ac/0x540 put_cmsg+0x3ac/0x540 udpv6_recvmsg+0xca0/0x1250 sock_recvmsg+0xdf/0x190 ____sys_recvmsg+0x1b1/0x620 Add ipv6_get_exthdr_len() which validates that at least two bytes are accessible before reading the hdrlen field, then checks the computed length against skb_tail_pointer(skb), returning 0 on failure. Extension headers are kept in the linear skb area by pskb_may_pull() during input, so skb_tail_pointer() is the correct bound. Use ipv6_get_exthdr_len() at all non-AH call sites: the five standalone cmsg blocks (HbH, 2292HbH, 2292DSTOPTS x2, 2292RTHDR) and the three standard cases in the extension-header walk loop (DSTOPTS, ROUTING, default). AH retains an inline bounds check because its length formula differs ((ptr[1]+2)<<2). The walk loop also gets a pre-read bounds check at the top to validate ptr before any case accesses ptr[0] or ptr[1]. When the walk loop detects a corrupted header, return from the function instead of continuing to process later socket options. Cc: stable@vger.kernel.org Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Qi Tang Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260523143245.2281415-1-tpluszz77@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 853f6ea482dfcd3404bbef458ab4d68364eed838 Author: Maoyi Xie Date: Thu May 21 21:05:55 2026 +0800 ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate(). commit 8b484efd5cb4eeef9021a661e198edc5349dacf6 upstream. After patch 1/2 in this series, vti6_update() unlinks and relinks the tunnel through t->net. vti6_siocdevprivate() still uses dev_net(dev) for the collision lookup. For a tunnel moved through IFLA_NET_NS_FD, dev_net(dev) is the new netns, not t->net. SIOCCHGTUNNEL on a migrated tunnel then runs: net = dev_net(dev) /* migrated netns */ t = vti6_locate(net, &p1, false) /* misses target in t->net */ ... t = netdev_priv(dev) vti6_update(t, &p1, false) /* mutates t->net's hash */ A caller in the migrated netns picks params that match a tunnel in the creation netns. The lookup in dev_net(dev) finds nothing. vti6_update() prepends the migrated tunnel at the head of the creation netns hash bucket for those params. Later lookups in the creation netns resolve to the migrated device. xfrm receive delivers the matched packets through a device the caller controls. Reachable from an unprivileged user namespace (unshare --user --map-root-user --net). Cross tenant scope on container hosts. Switch the SIOCCHGTUNNEL path on a non fallback device to use t->net for the lookup. The lookup now matches the netns vti6_update() operates on. Also add ns_capable(self->net->user_ns, CAP_NET_ADMIN) before the lookup. The check at the top of the case is against dev_net(dev)->user_ns, which after migration is the attacker's netns. A caller there can pick params absent from self->net, the lookup returns NULL, t becomes self, and vti6_update() inserts the device into the creation netns hash. The new check requires CAP_NET_ADMIN in the creation netns user_ns too. SIOCADDTUNNEL and SIOCCHGTUNNEL on the fallback device keep dev_net(dev), which equals init_net there. Fixes: 61220ab34948 ("vti6: Enable namespace changing") Suggested-by: Jakub Kicinski Suggested-by: Xiao Liang Cc: stable@vger.kernel.org # v5.15+ Signed-off-by: Maoyi Xie Link: https://patch.msgid.link/20260521130555.3421684-3-maoyixie.tju@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 751db1b802a067b7fff25880f4e9f9152a171538 Author: Zhengchuan Liang Date: Fri May 22 17:42:26 2026 +0800 ipv6: exthdrs: refresh nh after handling HAO option commit f7b52afe3592eae66e160586b45a3f2242972c63 upstream. ip6_parse_tlv() caches skb_network_header(skb) in nh while walking IPv6 TLVs. ipv6_dest_hao() may call pskb_expand_head() for a cloned skb, which can move the skb head and invalidate the cached network header pointer. Refresh nh after ipv6_dest_hao() returns so any trailing padding or TLVs are parsed from the current skb head. This matches the existing pattern used in ip6_parse_tlv() after helpers that can modify skb header storage. Fixes: a831f5bbc89a ("[IPV6] MIP6: Add inbound interface of home address option.") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Xin Liu Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Signed-off-by: Zhengchuan Liang Signed-off-by: Ren Wei Reviewed-by: Justin Iurman Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/7aba1debc2196189172499e5769802b026f8caf8.1779247873.git.zcliangcn@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 90983f841dfa9fec19b4e0d560a1d3bcf98da633 Author: Srinivas Kandagatla Date: Mon May 18 09:23:45 2026 +0000 ASoC: qcom: q6asm-dai: fix error handling in prepare and set_params commit 4b4db09f283df65d780bc7cee66cb4a7e9bf4770 upstream. Fix error handling in q6asm_dai_compr_set_params() and q6asm_dai_prepare() for both CMD_CLOSE and q6asm_unmap_memory_regions(). In both the functions, we are doing q6asm_audio_client_free in failure cases, which means if prepare or set_params fail, we can never recover. Now open and close are done in respective dai_open/close functions. Fixes: 2a9e92d371db ("ASoC: qdsp6: q6asm: Add q6asm dai driver") Cc: Stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260518092347.3446946-4-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c512e1c819dfbf6ae95ee7a44b65b9ad98979157 Author: Justin Iurman Date: Fri May 22 13:20:13 2026 +0200 ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo() commit d47548a36639095939f4747d4c43f2271366f565 upstream. ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Justin Iurman Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260522112013.12342-1-justin.iurman@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6d00f5c7e5ff7ec4795b7f5f8ed88bd346641652 Author: Junrui Luo Date: Wed May 20 11:47:55 2026 +0800 macsec: fix replay protection at XPN lower-PN wrap commit e68842b3356471ba56c882209f324613dac47f64 upstream. In macsec_post_decrypt(), when pn is U32_MAX, pn + 1 overflows u32 to 0 and the first branch never fires. If next_pn_halves.lower is also in the upper half, pn_same_half(pn, lower) is true and the XPN else-if does not fire either, leaving next_pn_halves unchanged. An attacker that captures the legitimate frame carrying pn == 0xFFFFFFFF on an XPN association can then replay it indefinitely, since lowest_pn never rises above the captured pn and macsec_decrypt() reconstructs the same IV. Extend the XPN else-if to also fire when pn + 1 wraps to 0, so receipt of pn == U32_MAX advances next_pn_halves to (upper + 1, 0). Fixes: a21ecf0e0338 ("macsec: Support XPN frame handling - IEEE 802.1AEbw") Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Link: https://patch.msgid.link/SYBPR01MB78813FD49E58F253B989F197AF012@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5e19028667963fb371ebb00cecc2a473ef92056b Author: Yuqi Xu Date: Wed May 27 11:48:15 2026 +0800 bpf: sockmap: fix tail fragment offset in bpf_msg_push_data commit f72eed9b84fb771019a955908132410a9ba9ea3f upstream. When bpf_msg_push_data() inserts data in the middle of a scatterlist entry, it splits the original entry into a left fragment and a right fragment. The right fragment offset is page-local, but the code advances it with `start`, which is the message-global insertion point. For inserts into a non-first SG entry, this over-advances the offset and leaves the split layout inconsistent. Advance the right fragment offset by the fragment-local delta, `start - offset`, which matches the length removed from the front of the original entry. Fixes: 6fff607e2f14 ("bpf: sk_msg program helper bpf_msg_push_data") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Zhengchuan Liang Reported-by: Xin Liu Signed-off-by: Yuqi Xu Signed-off-by: Ren Wei Link: https://patch.msgid.link/8b129d10566aa3eb43f61a8f9757bcf51707d324.1779636774.git.xuyq21@lenovo.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e4892b1ecd73d6690424b075feea48e05aaa0ad0 Author: Jason A. Donenfeld Date: Fri May 29 19:31:34 2026 +0200 wireguard: send: append trailer after expanding head commit f75e3eb08fe31d30a9af6ed80cdd22e6772837e2 upstream. With how this is currently written, we add the trailer, zero it out, and then add the header space on. If that header space requires a reallocation + copy, the zeros in the trailer aren't copied, because the skb len hasn't actually been yet expanded to cover that. Instead add the padding at the end of the process rather than at the beginning. Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Cc: stable@vger.kernel.org Signed-off-by: Jason A. Donenfeld Link: https://patch.msgid.link/20260529173134.3080773-2-Jason@zx2c4.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d59cc66b702757e3c5a711e78a38583eac0c2738 Author: Alexis Lothoré (eBPF Foundation) Date: Wed May 27 21:12:31 2026 +0200 x86/ftrace: Relocate %rip-relative percpu refs in dynamic trampolines commit a17dc12bfed8868e6a86f3b45c16065a70641acb upstream. With CONFIG_CALL_DEPTH_TRACKING enabled on an x86 retbleed-affected platform (eg: Skylake), with retbleed=stuff, registering a dynamic ftrace trampoline crashes on the first call into the traced function: BUG: unable to handle page fault for address: ffff88817ae18880 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 4b53067 P4D 4b53067 PUD 0 Oops: Oops: 0002 [#1] SMP PTI CPU: 3 UID: 0 PID: 187 Comm: usleep Not tainted 7.0.10 #243 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 Code: 24 78 00 00 00 00 48 89 ea 48 89 54 24 20 48 8b b4 24 b8 00 00 00 48 8b bc 24 b0 00 00 00 48 89 bc 24 80 00 00 00 48 83 ef 05 <65> 48 c1 3d 1f a8 b6 02 05 48 8b 15 f6 00 00 00 4c 89 3c 24 4c 89 Call Trace: ? find_held_lock ? exc_page_fault ? lock_release ? __x64_sys_clock_nanosleep ? lockdep_hardirqs_on_prepare ? trace_hardirqs_on __x64_sys_clock_nanosleep do_syscall_64 ? exc_page_fault ? call_depth_return_thunk entry_SYSCALL_64_after_hwframe ... Kernel panic - not syncing: Fatal exception This small reproducer allows to easily trigger the crash: # echo 'p __x64_sys_clock_nanosleep' > /sys/kernel/tracing/kprobe_events # echo 1 > /sys/kernel/tracing/events/kprobes/p___x64_sys_clock_nanosleep_0/enable # usleep 1 Monitoring the crash under GDB points to the exact instruction in charge of incrementing the call depth: sarq $5, %gs:__x86_call_depth(%rip) This instruction matches the one inserted by the ftrace_regs_caller from ftrace_64.S. This emitted code was likely working fine until the introduction of 59bec00ace28 ("x86/percpu: Introduce %rip-relative addressing to PER_CPU_VAR()"): it has made the call depth accounting addressing relative to $rip, instead of being based on an absolute address. As this code exact location depends on where the trampoline lives in memory, the corresponding displacement needs to be adjusted at runtime to actually correctly find the per-cpu __x86_call_depth value, otherwise the targeted address is wrong, leading to the page fault seen above. Fix the %rip-relative displacement of the copied CALL_DEPTH_ACCOUNT instruction (from ftrace_regs_caller) by calling text_poke_apply_relocation(), as it is done for example by the x86 BPF JIT compiler through x86_call_depth_emit_accounting(). This corrects both CALL_DEPTH_ACCOUNT slots, in ftrace_caller and ftrace_regs_caller. [ bp: Massage. ] Fixes: 59bec00ace28 ("x86/percpu: Introduce %rip-relative addressing to PER_CPU_VAR()") Signed-off-by: Alexis Lothoré (eBPF Foundation) Signed-off-by: Borislav Petkov (AMD) Acked-by: Peter Zijlstra (Intel) Acked-by: Steven Rostedt Cc: Link: https://patch.msgid.link/20260527-fix_call_depth_in_trampoline-v1-1-1c1abc8ae310@bootlin.com Signed-off-by: Greg Kroah-Hartman commit 3f43865cb64dd7cb50efae1281a95585617b12a1 Author: Chaitanya Sabnis Date: Tue May 26 15:52:40 2026 +0530 i2c: davinci: fix division by zero on missing clock-frequency commit 030675aa54cf757769b3db65642433d626b3ed7c upstream. When the 'clock-frequency' property is missing from the device tree, the driver falls back to DAVINCI_I2C_DEFAULT_BUS_FREQ. However, this macro was defined in kHz (100), whereas the device tree property is expected in Hz. The probe function divided the fallback value by 1000, causing integer truncation that resulted in dev->bus_freq = 0. This triggered a deterministic division-by-zero kernel panic when calculating clock dividers later in the probe sequence. Fix this by redefining DAVINCI_I2C_DEFAULT_BUS_FREQ in Hz (100000) to match the expected device tree property unit, allowing the existing division logic to work correctly for both cases. Fixes: b04ce6385979 ("i2c: davinci: kill platform data") Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260514044726.57297C2BCB7@smtp.kernel.org/ Signed-off-by: Chaitanya Sabnis Cc: # v6.14+ Reviewed-by: Bartosz Golaszewski Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260526102240.4949-1-chaitanya.msabnis@gmail.com Signed-off-by: Greg Kroah-Hartman commit bf769358419e00344c1b16fa034d058f563d46a1 Author: Dmitry Torokhov Date: Sat Apr 25 22:07:06 2026 -0700 Input: elan_i2c - validate firmware size before use commit 76b0d0baa9ae9c60e726bbe1b6ff0bec2c993634 upstream. Ensure that the firmware file is large enough to contain the expected number of pages and the signature (which resides at the end of the firmware blob) before accessing them to prevent potential out-of-bounds reads. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/ae2dOgiFvXRm4BHo@google.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 84ea928ed584756e59c6ac09736f12d1db95ded0 Author: Dan Carpenter Date: Wed May 20 08:59:28 2026 +0300 usb: dwc2: Fix use after free in debug code commit 9ea06a3fbf9f16e0d98c52cb3b99642be15ec281 upstream. We're not allowed to dereference "urb" after calling usb_hcd_giveback_urb() so save the urb->status ahead of time. Fixes: 7359d482eb4d ("staging: HCD files for the DWC2 driver") Cc: stable Signed-off-by: Dan Carpenter Link: https://patch.msgid.link/ag1NwBpqT4IEQcdJ@stanley.mountain Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 94c92f9c886ca0a8b74207e9994f39e47242dd1b Author: Peter Chen Date: Wed May 13 16:53:10 2026 +0800 usb: cdns3: plat: fix unbalanced pm_runtime_forbid() call permanently leaks the runtime PM usage counter across bind/unbind cycles commit ae6f3b82324e4f39ad8443c9020787e6fc889637 upstream. Call pm_runtime_allow(dev) conditionally at cdns3_plat_remove. Fixes: f738957277ba ("usb: cdns3: Split core.c into cdns3-plat and core.c file") Cc: stable Reported-by: sashiko-bot Closes: https://lore.kernel.org/linux-devicetree/agKaEePSFknhDBg2@nchen-desktop/T/#m21e1d9c1574eb127ce03c0c2a1a49002ce435b52 Signed-off-by: Peter Chen Link: https://patch.msgid.link/20260513085310.2217547-3-peter.chen@cixtech.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 459c4fa089f79a68b8217707cb21415317f4a83f Author: Peter Chen Date: Wed May 13 16:53:09 2026 +0800 usb: cdns3: plat: fix leaked usb2_phy initialization on usb3_phy acquisition failure commit e6970cda63fd4b4546aeed9d0e2f53a7c95cd09c upstream. Move usb2_phy initialization after usb3_phy acquisition. Fixes: f738957277ba ("usb: cdns3: Split core.c into cdns3-plat and core.c file") Cc: stable Reported-by: sashiko-bot Closes: https://lore.kernel.org/linux-devicetree/agKaEePSFknhDBg2@nchen-desktop/T/#m21e1d9c1574eb127ce03c0c2a1a49002ce435b52 Signed-off-by: Peter Chen Link: https://patch.msgid.link/20260513085310.2217547-2-peter.chen@cixtech.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit b2723bd468c5ce2ce4e5ee9d41dd21e6b6009f47 Author: Yongchao Wu Date: Thu May 14 00:00:12 2026 +0800 usb: cdns3: gadget: fix request skipping after clearing halt commit c8778ff817a7047d6848fefba99dcb27b1bf01fe upstream. According to the cdns3 datasheet, the EPRST (Endpoint Reset) command causes the DMA engine to reposition its internal pointer to the next Transfer Descriptor (TD) if it was already processing one. This issue is consistently observed during the ADB identification process on macOS hosts, where the host issues a Clear_Halt. Although commit 4bf2dd65135a ("usb: cdns3: gadget: toggle cycle bit before reset endpoint") attempted to avoid DMA advance by toggling the cycle bit, trace logs show that on certain hosts like macOS, the DMA pointer (EP_TRADDR) still shifts after EPRST: cdns3_ctrl_req: Clear Endpoint Feature(Halt ep1out) cdns3_doorbell_epx: ep1out, ep_trbaddr f9c04030 <-- Should be f9c04000 cdns3_gadget_giveback: ep1out: req: ... length: 16384/16384 As shown above, the DMA pointer jumped to the next TD, causing the controller to skip the initial TRBs of the request. This leads to data misalignment and ADB protocol hangs on macOS. Fix this by manually restoring the EP_TRADDR register to the starting physical address of the current request after the EPRST operation is complete. Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") Cc: stable Cc: Peter Chen Signed-off-by: Yongchao Wu Acked-by: Peter Chen Link: https://patch.msgid.link/20260513160012.2547894-1-yongchao.wu@autochips.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 0fee0ccac29e088d4bfab7e2d075725dcecd803d Author: Johan Hovold Date: Fri May 22 16:20:58 2026 +0200 USB: serial: omninet: fix memory corruption with small endpoint commit 60df93d30f9bdd27db17c4d80ed80ef718d7226b upstream. Make sure that the bulk-out buffers are at least as large as the hardcoded transfer size to avoid user-controlled slab corruption should a malicious device report a smaller endpoint max packet size than expected. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 3412a95afaa5d3262008dfc34f3c7be33d8151dc Author: Benoît Monin Date: Wed Apr 1 17:24:58 2026 +0200 iio: buffer: Fix DMA fence leak in iio_buffer_enqueue_dmabuf() commit a093999355084bdbfe6e97f1dd232e58a1525f0b upstream. iio_buffer_enqueue_dmabuf() allocates a struct iio_dma_fence (104 bytes, kmalloc-128) via kmalloc_obj()+dma_fence_init(), which sets the initial kref to 1. It then calls dma_resv_add_fence() which takes a second reference (kref=2), and stores a raw pointer in block->fence. On the success path the function returns without calling dma_fence_put() to release the initial reference, so every buffer enqueue permanently leaks one kmalloc-128 allocation. The iio_buffer_cleanup() work item only releases the temporary reference taken during completion signalling by iio_buffer_signal_dmabuf_done(); the initial reference from dma_fence_init() is never released. With four iio_rwdev instances at 240kHz and 512 samples per buffer, this produces ~1875 kmalloc-128 allocations per second matching the observed slab growth exactly. A test with ftrace confirmed that the dma_fence_destroy event was never triggered. Fix by calling dma_fence_put() after dma_resv_add_fence(), transferring ownership of the fence to the DMA reservation object. The DMA fence then gets properly discarded after being signalled. Fixes: 3e26d9f08fbe0 ("iio: core: Add new DMABUF interface infrastructure") Originally-by: James Nuss Signed-off-by: Benoît Monin Reviewed-by: Paul Cercueil Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit a3763ae33476328cf8d661742deb9daec78eac96 Author: Felix Gu Date: Thu Apr 30 21:29:06 2026 +0800 iio: buffer: hw-consumer: fix use-after-free in error path commit 6f5ed4f2c7c83f33344e0ba179f72a12e5dad4a4 upstream. In the err_put_buffers cleanup path of iio_hw_consumer_alloc(), the code was using list_for_each_entry() to iterate through buffers while calling iio_buffer_put() which can free the current buffer if refcount drops to 0. The list_for_each_entry() loop macro then evaluates buf->head.next to continue iteration, accessing the freed buffer. Fix this by using list_for_each_entry_safe(). Fixes: 48b66f8f936f ("iio: Add hardware consumer buffer support") Reported-by: sashiko Closes: https://sashiko.dev/#/patchset/20260427-iio_buf-v1-1-2bbdac844647%40gmail.com Signed-off-by: Felix Gu Reviewed-by: Andy Shevchenko Reviewed-by: Nuno Sá Reviewed-by: Maxwell Doose Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 390254cf509b8e433b17287bb3aa1990c942d3af Author: Aldo Conte Date: Tue Apr 7 17:17:01 2026 +0200 iio: light: cm3323: fix reg_conf not being initialized correctly commit 1f4f0bcc5255dec5c4c3a1551bf49d8c33b69b20 upstream. The code stores the return value of i2c_smbus_write_word_data() in data->reg_conf; however, this value represents the result of the write operation and not the value actually written to the configuration register. This meant that the contents of data->reg_conf did not truly reflect the contents of the hardware register. Instead, save the value of the register before the write and use this value in the I2C write. The bug was found by code inspection: i2c_smbus_write_word_data() returns 0 on success, not the value written to the register. Tested using i2c-stub on a Raspberry Pi 3B running a custom 6.19.10 kernel. Before loading the driver, the configuration register 0x00 CM3323_CMD_CONF was populated with 0x0030 using `i2cset -y 11 0x10 0x00 0x0030 w`, encoding an integration time of 320ms in bits[6:4]. Due to incorrect initialization of data->reg_conf in cm3323_init(), the print of integration_time returns 0.040000 instead of the expected 0.320000. This happens because the read of the integration_time depends on cm3323_get_it_bits() that is based on the value of data->reg_conf, which is erroneously set to 0. With this fix applied, data->reg_conf correctly saves 0x0030 after init and the successive integration_time reports 0.320000 as expected. Fixes: 8b0544263761 ("iio: light: Add support for Capella CM3323 color sensor") Cc: stable@vger.kernel.org Signed-off-by: Aldo Conte Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 5e4d34092a5ebfbc3a45a180c76ecb1cdbbedd53 Author: Antoniu Miclaus Date: Wed Apr 1 14:08:29 2026 +0300 iio: chemical: scd30: fix division by zero in write_raw commit 5aba4f94b225617a55fed442a70329b2ee19c0a5 upstream. Add a zero check for val2 before using it as a divisor when setting the sampling frequency. A user writing a zero fractional part to the sampling_frequency sysfs attribute triggers a division by zero in the kernel. Fixes: 64b3d8b1b0f5 ("iio: chemical: scd30: add core driver") Signed-off-by: Antoniu Miclaus Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit a5a05410cb34bfa486d63684cdc1f87a3b13f20a Author: Pengpeng Hou Date: Thu Apr 2 13:40:15 2026 +0800 iio: chemical: mhz19b: reject oversized serial replies commit 673478bc29cf72010faaf293c1c8c667393335a0 upstream. mhz19b_receive_buf() appends each serdev chunk into the fixed MHZ19B_CMD_SIZE receive buffer and advances buf_idx by len without checking that the chunk fits in the remaining space. A large callback can therefore overflow st->buf before the command path validates the reply. Reset the reply state before each command and reject oversized serial replies before copying them into the fixed buffer. When an oversized reply is detected, wake the waiter and report -EMSGSIZE instead of overwriting st->buf. Fixes: 4572a70b3681 ("iio: chemical: Add support for Winsen MHZ19B CO2 sensor") Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou Acked-by: Gyeyoung Baek Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit cbd2d7e6bd4f4828acbe784f33453baba911cd06 Author: Svyatoslav Ryhel Date: Thu Apr 16 14:14:42 2026 +0300 iio: Fix iio_multiply_value use in iio_read_channel_processed_scale commit bb21ee31f5753a7972148798fd7dfb841dd33bdb upstream. The function iio_multiply_value returns IIO_VAL_INT (1) on success or a negative error number on failure, while iio_read_channel_processed_scale should return an error code or 0. This creates a situation where the expected result is treated as an error. Fix this by checking the iio_multiply_value result separately, instead of passing it as a return value. Fixes: 05f958d003c9 ("iio: Improve iio_read_channel_processed_scale() precision") Signed-off-by: Svyatoslav Ryhel Reviewed-by: Hans de Goede Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 8d4daa6144404ea938935a9f1989550b5f7b7d2a Author: Felix Gu Date: Fri Mar 27 20:27:54 2026 +0800 iio: light: veml6070: Fix resource leak in probe error path commit b66f922f6a4fa92840f662fbcfeb4f8a0f774bcc upstream. The driver calls i2c_new_dummy_device() to create a dummy device, then calls i2c_smbus_write_byte(). If i2c_smbus_write_byte() fails and returns, the cleanup via devm_add_action_or_reset() was never registered, so the dummy device leaks. Switch to devm_i2c_new_dummy_device() which registers cleanup atomically with device creation, eliminating the error-path window. Fixes: 7501bff87c3e ("iio: light: veml6070: add action for i2c_unregister_device") Reviewed-by: Andy Shevchenko Signed-off-by: Felix Gu Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit ae01ec83841d7dcc716156d06631a514af68126b Author: Advait Dhamorikar Date: Tue Apr 7 12:50:59 2026 +0530 iio: magnetometer: st_magn: fix default DRDY pin selection for LIS2MDL commit 49f79cd28f1e3333cbe0d616ce59ead0b24bf34e upstream. The device tree binding for st,lis2mdl does not support st,drdy-int-pin property. However, when no platform data is provided and the property is absent, the driver falls back to default_magn_pdata which hardcodes drdy_int_pin = 2. This causes `st_sensors_set_drdy_int_pin` to fail with -EINVAL because the LIS2MDL sensor settings have no INT2 DRDY mask defined. Fix this by checking the sensor's INT2 DRDY mask availability at probe time and selecting the appropriate default pin. Sensors that do not support INT2 DRDY will default to INT1, while all others retain the existing default of INT2. Fixes: 38934daf7b5c ("iio: magnetometer: st_magn: Provide default platform data") Signed-off-by: Advait Dhamorikar Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit aefc19ca3dd3db67e2dd40a194e39854689d80fe Author: Salah Triki Date: Tue May 5 08:10:24 2026 +0100 iio: temperature: tsys01: fix broken PROM checksum validation commit 4701e471c16866e7aa8f5e6a3a6b0d31e097e2c9 upstream. The current implementation of tsys01_crc_valid() incorrectly sums the first word (n_prom[0]) repeatedly instead of iterating over the 8 words retrieved from the PROM. This leads to a checksum mismatch and probe failure on hardware. According to the TSYS01 datasheet, the PROM consists of 8 words. A valid check must iterate through all 8 words to verify the integrity of the calibration data. The current driver only checks the first word 8 times. Note: This fix was identified during a code audit and is based on datasheet specifications. It has not been tested on real hardware. Fixes: 43e53407f680 ("Add tsys01 meas-spec driver support") Signed-off-by: Salah Triki Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 04a4d9822210937707ca61980f82d9de4f8ab5f0 Author: Sanjay Chitroda Date: Sun Apr 26 14:47:04 2026 +0530 iio: ssp_sensors: cancel delayed work_refresh on remove commit eedf7602fbd929e97e0c480da501dc7a34beb2a8 upstream. The work_refresh may still be pending or running when the device is removed, cancel the delayed work_refresh in remove path. Fixes: 50dd64d57eee ("iio: common: ssp_sensors: Add sensorhub driver") Signed-off-by: Sanjay Chitroda Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit aaf9d640e9ae1172d0a9c659ecb245a50a10850a Author: Antoniu Miclaus Date: Tue Mar 31 13:13:00 2026 +0300 iio: gyro: adis16260: fix division by zero in write_raw commit 761e8b489e6cf166c574034b70637f8a7eadd0ee upstream. Add a validation check for the sampling frequency value before using it as a divisor. A user writing zero to the sampling_frequency sysfs attribute triggers a division by zero in the kernel. Fixes: 089a41985c6c ("staging: iio: adis16260 digital gyro driver") Signed-off-by: Antoniu Miclaus Reviewed-by: Nuno Sá Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 15a0b3f33ffb6c78b3de6f69b026ceb09b973dd1 Author: David Carlier Date: Tue May 5 14:37:48 2026 +0100 iio: gyro: itg3200: fix i2c read into the wrong stack location commit 6bdc3023d62ed5c7d591f0eb27a5adb37fb892ae upstream. itg3200_read_all_channels() takes `__be16 *buf' as a parameter and fills the i2c_msg destination as `(char *)&buf'. Since `buf' is the parameter (a pointer), `&buf' is the address of the local pointer slot on the stack of itg3200_read_all_channels(), not the address of the caller's scan buffer. The (char *) cast hides the type mismatch. i2c_transfer() therefore writes ITG3200_SCAN_ELEMENTS * sizeof(s16) = 8 bytes into the parameter's stack slot, which is discarded when the function returns. The caller's scan buffer in itg3200_trigger_handler() is never written to, so iio_push_to_buffers_with_timestamp() pushes uninitialised stack contents to userspace via /dev/iio:deviceX every scan -- both a functional bug (no actual gyroscope or temperature data is delivered through the triggered buffer) and an information leak. The non-buffered read_raw() path is unaffected: it goes through itg3200_read_reg_s16() which uses `&out' on a local s16 value, where that is correct. Drop the spurious `&' so the i2c read writes into the caller's buffer. Fixes: 9dbf091da080 ("iio: gyro: Add itg3200") Cc: stable@vger.kernel.org Signed-off-by: David Carlier Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 5cb8cede8baf771bec4c033ac690049204c26ae1 Author: Radu Sabau Date: Wed Apr 8 13:32:13 2026 +0300 iio: adc: ad4695: Fix call ordering in offload buffer postenable commit 1a772719318c11e146f6fbe621fffd230a6f456a upstream. ad4695_enter_advanced_sequencer_mode() was called after spi_offload_trigger_enable(). That is wrong because ad4695_enter_advanced_sequencer_mode() issues regular SPI transfers to put the ADC into advanced sequencer mode, and not all SPI offload capable controllers support regular SPI transfers while offloading is enabled. Fix this by calling ad4695_enter_advanced_sequencer_mode() before spi_offload_trigger_enable(), so the ADC is fully configured before the first CNV pulse can occur. This is consistent with the same constraint that already applies to the BUSY_GP_EN write above it. Update the error unwind labels accordingly: add err_exit_conversion_mode so that a failure of spi_offload_trigger_enable() correctly exits conversion mode before clearing BUSY_GP_EN. Fixes: f09f140e3ea8 ("iio: adc: ad4695: Add support for SPI offload") Reviewed-by: Nuno Sá Reviewed-by: David Lechner Signed-off-by: Radu Sabau Cc: Stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 7155e7fce4290533843d6e3784fe8575d14a8aca Author: Salah Triki Date: Thu May 7 20:07:51 2026 +0100 iio: adc: viperboard: Fix error handling in vprbrd_iio_read_raw commit 422b5bbf333f75fb486855ad0eedc23cf21f3277 upstream. The driver proceeds to the reception phase even if the preceding transmission fails. This uses a goto error label for an early bail out and ensures the mutex is properly unlocked in case of failure. Fixes: ffd8a6e7a778 ("iio: adc: Add viperboard adc driver") Signed-off-by: Salah Triki Reviewed-by: Joshua Crofts Reviewed-by: Maxwell Doose Reviewed-by: Nuno Sá Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 944082fdb0284a31c0b37a88c8a1d4404da3a6d9 Author: Salah Triki Date: Mon Apr 27 21:12:38 2026 +0100 iio: adc: mt6359: fix unchecked return value in mt6358_read_imp commit f9bbd943c34a9ad60e593a4b99ce2394e4e2381b upstream. In mt6358_read_imp(), the variable val_v is passed to regmap_read() but the return value is not checked. If the read fails, val_v remains uninitialized and its random stack content is subsequently reported as a measurement result. Initialize val_v to zero to ensure a predictable value is reported in case of bus failure and to prevent potential stack data leakage. This also satisfies static analyzers that might otherwise flag the variable as used uninitialized. Fixes: 3587914bf61d ("iio: adc: Add support for MediaTek MT6357/8/9 Auxiliary ADC") Signed-off-by: Salah Triki Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 991d359faa9526963ae4dc6d16dd131d0894b4e6 Author: Rodrigo Alencar Date: Tue May 5 13:35:05 2026 +0100 iio: dac: ad5686: fix powerdown control on dual-channel devices commit 8aeaf25a85263a7a43357e16ad78ab969f6f8aeb upstream. Fix powerdown control by using a proper bit shift for the powerdown mask values. During initialization, powerdown bits are initialized so that unused bits are set to 1 and the correct bit shift is used. Dual-channel devices use one-hot encoding in the address and that reflects on the position of the powerdown bits, which are not channel-index based for that case. Quad-channel devices also use one-hot encoding for the channel address but the result of log2(address) coincides with the channel index value. Mask as 0x3U is used rather than 0x3, because shift can reach value of 30 (last channel of a 16-channel device), which would mess with the sign bit. The issue was introduced when first adding support for dual-channel devices, which overlooked powerdown control differences. Fixes: 7dc8faeab3e3 ("iio: dac: ad5686: add support for AD5338R") Signed-off-by: Rodrigo Alencar Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 31de336a2c0d02b080488bb47b088d4fc1a26614 Author: Rodrigo Alencar Date: Tue May 5 13:35:04 2026 +0100 iio: dac: ad5686: acquire lock when doing powerdown control commit 5237c3175cae5ab05f18878cec3301a04403859e upstream. Protect access of pwr_down_mode and pwr_down_mask fields with existing mutex lock. Each channel exposes their own attributes for controlling powerdown modes and powerdown state. This fixes potential race conditions as those the write functions perform non-atomic read-modify-write operations to those pwr_down_* fields. This issue exists since the ad5686 driver was first introduced. Fixes: c2f37c8dcadc ("iio: dac: New driver for AD5686R, AD5685R, AD5684R Digital to analog converters") Signed-off-by: Rodrigo Alencar Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit f541c9a1eb89346cb27a47e47ce5c33c59ee4cfc Author: Rodrigo Alencar Date: Fri May 1 10:14:55 2026 +0100 iio: dac: ad5686: fix input raw value check commit d01220ee5e43c65a206df827b39bf5cf5f7b9dce upstream. Fix range check for input raw value, which is off by one, i.e., for a 10-bit DAC the max valid value is 1023, but 1 << 10 equals 1024, which passes the previous check, allowing an out-of-range write. The issue exists since the ad5686 driver was first introduced. Fixes: c2f37c8dcadc ("iio: dac: New driver for AD5686R, AD5685R, AD5684R Digital to analog converters") Reviewed-by: Andy Shevchenko Signed-off-by: Rodrigo Alencar Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 69f7d101976c617e1f406bc7da6eb4129739bf54 Author: Rodrigo Alencar Date: Fri May 1 10:14:54 2026 +0100 iio: dac: ad5686: fix ref bit initialization for single-channel parts commit ecae2ae606d493cf11457946436335bd0e726663 upstream. The reference bit position was ignored when writing the register at the probe() function (!!val was used). When such bit is 1, internal voltage reference is disabled so that an external one can be used. For multi-channel devices, bit 0 of the Internal Reference Setup command behaves the same way, so AD5686_REF_BIT_MSK is created. The issue exists since support for single-channel devices were first introduced. Fixes: be1b24d24541 ("iio:dac:ad5686: Add AD5691R/AD5692R/AD5693/AD5693R support") Reviewed-by: Andy Shevchenko Signed-off-by: Rodrigo Alencar Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 684bfd655b8084e744aa1e58cb7d29026a8e5ea1 Author: Salah Triki Date: Mon Apr 27 22:33:19 2026 +0100 iio: dac: max5821: fix return value check in powerdown sync commit d0a228d903425e653f18a4341e60c0538afb6d41 upstream. The function max5821_sync_powerdown_mode() returned the result of i2c_master_send() directly. If a partial transfer occurred, it would be incorrectly treated as a success by the caller. While the caller currently handles the positive return value of 2 as success, this patch refactors the function to return 0 on full success and -EIO on short writes. This ensures robust error handling for incomplete transfers and improves code maintainability by using sizeof(outbuf). Fixes: 472988972737 ("iio: add support of the max5821") Signed-off-by: Salah Triki Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 88c9dd5170e057f07ae1cbbf0b4c43ec050bd919 Author: Kim Seer Paller Date: Tue May 5 12:34:32 2026 +0800 iio: dac: ad3530r: Fix AD3531/AD3531R powerdown mode strings commit ebd250c2581ec46c64c73fdfa918c9a7f757505e upstream. The AD3531/AD3531R has different output operating modes from the AD3530/AD3530R. According to the AD3531/AD3531R datasheet, the powerdown modes are: 01: 500 Ohm output impedance 10: 3.85 kOhm output impedance 11: 16 kOhm output impedance The driver currently uses the AD3530R modes (1k, 7.7k, 32k) for all variants, which is incorrect for AD3531/AD3531R. Add AD3531R-specific powerdown mode strings and assign them to the AD3531/AD3531R chip variants. Fixes: 93583174a3df ("iio: dac: ad3530r: Add driver for AD3530R and AD3531R") Signed-off-by: Kim Seer Paller Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 2ce5ca7824a18c36fdd817398b881c3777b7325e Author: David Carlier Date: Tue Apr 14 13:30:06 2026 +0100 iio: adc: npcm: fix unbalanced clk_disable_unprepare() commit 0d42e2c0bd6ceb89e44c6e065f9bdf9b1df3ef0c upstream. The driver acquired the ADC clock with devm_clk_get() and read its rate, but never called clk_prepare_enable(). The probe error path and npcm_adc_remove() both called clk_disable_unprepare() unconditionally, causing the clk framework's enable/prepare counts to underflow on probe failure or module unbind. The issue went unnoticed because NPCM BMC firmware leaves the ADC clock enabled at boot, so the driver happened to work in practice. Switch to devm_clk_get_enabled() so the clock is properly enabled during probe and automatically released by the device-managed cleanup, and drop the now-redundant clk_disable_unprepare() from both the probe error path and remove(). While at it, drop the duplicate error message on devm_request_irq() failure since the IRQ core already logs it. Fixes: 9bf85fbc9d8f ("iio: adc: add NPCM ADC driver") Signed-off-by: David Carlier Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 0ee771fff32e8b4c3f531deb1e408901fb4b6700 Author: Christofer Jonason Date: Wed Mar 4 10:07:27 2026 +0100 iio: adc: xilinx-xadc: Fix sequencer mode in postdisable for dual mux commit 852534744c2d35626a604f128ff0b8ec12805591 upstream. xadc_postdisable() unconditionally sets the sequencer to continuous mode. For dual external multiplexer configurations this is incorrect: simultaneous sampling mode is required so that ADC-A samples through the mux on VAUX[0-7] while ADC-B simultaneously samples through the mux on VAUX[8-15]. In continuous mode only ADC-A is active, so VAUX[8-15] channels return incorrect data. Since postdisable is also called from xadc_probe() to set the initial idle state, the wrong sequencer mode is active from the moment the driver loads. The preenable path already uses xadc_get_seq_mode() which returns SIMULTANEOUS for dual mux. Fix postdisable to do the same. Fixes: bdc8cda1d010 ("iio:adc: Add Xilinx XADC driver") Cc: stable@vger.kernel.org Signed-off-by: Christofer Jonason Reviewed-by: Andy Shevchenko Reviewed-by: Nuno Sá Reviewed-by: Salih Erim Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit bb1b43e8a7ede56b6beed0e6d73023ade753e6f2 Author: Nathan Chancellor Date: Sat May 16 04:34:14 2026 +0900 Disable -Wattribute-alias for clang-23 and newer commit 175db11786bde9061db526bf1ac5107d915f5163 upstream. Clang recently added support for -Wattribute-alias [1], which results in the same warnings that necessitated commit bee20031772a ("disable -Wattribute-alias warning for SYSCALL_DEFINEx()") for GCC. kernel/time/itimer.c:325:1: error: alias and aliasee have different types 'long (unsigned int)' and 'long (typeof (__builtin_choose_expr((__builtin_types_compatible_p(typeof ((unsigned int)0), typeof (0LL)) || __builtin_types_compatible_p(typeof ((unsigned int)0), typeof (0ULL))), 0LL, 0L)))' (aka 'long (long)') [-Werror,-Wattribute-alias] 325 | SYSCALL_DEFINE1(alarm, unsigned int, seconds) | ^ include/linux/syscalls.h:225:36: note: expanded from macro 'SYSCALL_DEFINE1' 225 | #define SYSCALL_DEFINE1(name, ...) SYSCALL_DEFINEx(1, _##name, __VA_ARGS__) | ^ include/linux/syscalls.h:236:2: note: expanded from macro 'SYSCALL_DEFINEx' 236 | __SYSCALL_DEFINEx(x, sname, __VA_ARGS__) | ^ include/linux/syscalls.h:251:18: note: expanded from macro '__SYSCALL_DEFINEx' 251 | __attribute__((alias(__stringify(__se_sys##name)))); \ | ^ kernel/time/itimer.c:325:1: note: aliasee is declared here include/linux/syscalls.h:225:36: note: expanded from macro 'SYSCALL_DEFINE1' 225 | #define SYSCALL_DEFINE1(name, ...) SYSCALL_DEFINEx(1, _##name, __VA_ARGS__) | ^ include/linux/syscalls.h:236:2: note: expanded from macro 'SYSCALL_DEFINEx' 236 | __SYSCALL_DEFINEx(x, sname, __VA_ARGS__) | ^ include/linux/syscalls.h:255:18: note: expanded from macro '__SYSCALL_DEFINEx' 255 | asmlinkage long __se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \ | ^ :16:1: note: expanded from here 16 | __se_sys_alarm | ^ Disable the warnings in the same way for clang-23 and newer. Disable the warning about unknown warning options to avoid breaking the build for versions of clang-23 that do not have -Wattribute-alias, such as ones deployed by vendors like Android or CI systems or when bisecting LLVM between llvmorg-23-init and release/23.x. Cc: stable@vger.kernel.org Closes: https://github.com/ClangBuiltLinux/linux/issues/2163 Link: https://github.com/llvm/llvm-project/commit/40da6920a0d71d49dfa2392b09153600b0759f5e [1] Link: https://patch.msgid.link/20260515-syscall-disable-attribute-alias-for-clang-v1-1-9a9d95d41df6@kernel.org Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit bbd989d6fd3667d635c9afdeda6e05a2237e418c Author: Sean Christopherson Date: Fri May 1 13:22:33 2026 -0700 KVM: SEV: Don't explicitly pass PSC buffer to snp_begin_psc() commit ebe4b2dc9cfbfb2d8f665667c4d08f4c6c9bec05 upstream. Stop explicitly passing the PSC buffer to snp_begin_psc(): it *must* be the scratch area. This will allow fixing a variety of bugs without further complicating the code. No functional change intended. Cc: stable@vger.kernel.org Reviewed-by: Tom Lendacky Reviewed-by: Michael Roth Signed-off-by: Sean Christopherson Message-ID: <20260501202250.2115252-9-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit b1dfaa6f7a957726a6800135be3659fbe4bbf2a4 Author: Sean Christopherson Date: Fri May 1 13:22:35 2026 -0700 KVM: SEV: Use READ_ONCE() when reading entries/indices from PSC buffer commit c8cc238093ca6c99267032f6cfe78f59389f3157 upstream. Use READ_ONCE() when reading entries/indices from the guest-accessible Page State Change buffer to defend against TOCTOU bugs. Don't bother with READ_ONCE()/WRITE_ONCE() for cases where KVM is writing (and not consuming the result!), as the guest isn't supposed to touch the buffer while it's being processed. I.e. using READ_ONCE() is all about protecting against misbehaving guests. Fixes: 9b54e248d264 ("KVM: SEV: Add support to handle Page State Change VMGEXIT") Cc: stable@vger.kernel.org Reviewed-by: Tom Lendacky Signed-off-by: Sean Christopherson Message-ID: <20260501202250.2115252-11-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 75c8d1d7291268b479794fba5808971dc2f5eaf3 Author: Sean Christopherson Date: Fri May 1 13:22:34 2026 -0700 KVM: SEV: Check PSC request indices against the actual size of the buffer commit 121d88de56bc5c0ba0ce2f6381af67f948a7e7c1 upstream. When processing Page State Change (PSC) requests, validate the PSC buffer against the effective size of the scratch area, which could be less than the maximum size if the guest provided a pointer that isn't exactly at the start of the GHCB shared buffer. Fixes: 9b54e248d264 ("KVM: SEV: Add support to handle Page State Change VMGEXIT") Cc: stable@vger.kernel.org Reviewed-by: Tom Lendacky Reviewed-by: Michael Roth Signed-off-by: Sean Christopherson Message-ID: <20260501202250.2115252-10-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 9f0a9e780f02c02d025a190f1885e1d1d73b87bd Author: Sean Christopherson Date: Fri May 1 13:22:31 2026 -0700 KVM: SEV: Compute the correct max length of the in-GHCB scratch area commit 5867d7e202e09f037cefe77f7af4413c7c0fa088 upstream. When setting the length of the GHCB scratch area, and the area is in the GHCB shared buffer, set the effective length of the scratch area to the max possible size given the start of the guest-provided pointer, and the end of the shared buffer. The code was "fine" when first introduced, as KVM doesn't consult the length of the buffer when emulating MMIO, because the passed in @len always specifies the *max* size required. But for PSC requests, the incoming @len is just the minimum length (to process the header), and KVM needs to know the full size of the scratch area to avoid buffer overflows (spoiler alert). Opportunistically rename @len => @min_len to better reflect its role. Fixes: 9b54e248d264 ("KVM: SEV: Add support to handle Page State Change VMGEXIT") Cc: stable@vger.kernel.org Reviewed-by: Tom Lendacky Reviewed-by: Michael Roth Signed-off-by: Sean Christopherson Message-ID: <20260501202250.2115252-7-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 5300aedbee5618edf16527dc539fea6001916a40 Author: Sean Christopherson Date: Fri May 1 13:22:32 2026 -0700 KVM: SEV: WARN if KVM attempts to setup scratch area with min_len==0 commit f185e05dce6f170f83c4ba602e969b1c3c7a22e6 upstream. Now that all paths in KVM properly validate the length needed for the scratch area, and are guaranteed to pass in a non-zero length, WARN if KVM attempts to configured the scratch area with min_len==0 to guard against future bugs. Cc: stable@vger.kernel.org Reviewed-by: Tom Lendacky Reviewed-by: Michael Roth Signed-off-by: Sean Christopherson Message-ID: <20260501202250.2115252-8-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit e4ab26f81a632a971936db0301be52da253300dd Author: Sean Christopherson Date: Fri May 1 13:22:30 2026 -0700 KVM: SEV: Use the size of the PSC header as the minimum size for PSC requests commit 2be54670bdc017004c4a4b8bddb6ff02ebe7dbe2 upstream. When handling a Page State Change (PSC) #VMGEXIT use the size of the PSC header as the minimum size for the scratch area. Per the GHCB spec, PSC requests do NOT provide the length, i.e. using control->exit_info_2 for the length is completely made up behavior. The existing code "works", e.g. even though Linux-as-a-guest always passes '0', because KVM doesn't do anything with the length when the request is in the GHCB's shared buffer. Use the header as the min length. Once the header is retrieved, KVM can use the specified indices to compute the full size of the request. Fixes: 9b54e248d264 ("KVM: SEV: Add support to handle Page State Change VMGEXIT") Cc: stable@vger.kernel.org Reviewed-by: Tom Lendacky Reviewed-by: Michael Roth Signed-off-by: Sean Christopherson Message-ID: <20260501202250.2115252-6-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 2254972d4d69e279ba4e87bf0968eb08ad0d3c92 Author: Sean Christopherson Date: Fri May 1 13:22:29 2026 -0700 KVM: SEV: Ignore Port I/O requests of length '0' commit 3988bd2723de407ae90fa7a6f6029b4e60238c58 upstream. Explicitly ignore Port I/O requests of length '0' (or count '0'), so that setting up the software scratch area (and other code) doesn't have to worry about underflowing the length, and to allow for WARNing on trying to configure the scratch area with len==0. Fixes: 291bd20d5d88 ("KVM: SVM: Add initial support for a VMGEXIT VMEXIT") Cc: stable@vger.kernel.org Reviewed-by: Tom Lendacky Signed-off-by: Sean Christopherson Message-ID: <20260501202250.2115252-5-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit c9b4198fbc6ed99a9da4bee9f74bb730f926c9ae Author: Michael Roth Date: Fri May 1 13:22:26 2026 -0700 KVM: SEV: Require in-GHCB scratch area if GHCB v2+ is in use commit db3f2195d29344a3cf1e9dd9ab7f21ced7308cf7 upstream. As per the GHCB spec, when using GHCB v2+ require the software scratch area to reside in the GHCB's shared buffer. Note, things like Page State Change (PSC) requests _rely_ on this behavior, as the guest can't provide a length when making the request, i.e. the size of the guest payload is bounded by the size of the shared buffer. Failure to force usage of the GHCB, and a slew of other flaws, lets a malicious SNP guest corrupt host kernel heap memory, and leak host heap layout information. setup_vmgexit_scratch() allocates a buffer via kvzalloc(exit_info_2), where exit_info_2 is guest-controlled. With exit_info_2=24, this yields a 24-byte allocation in kmalloc-cg-32 (32-byte slab objects). The buffer holds an 8-byte psc_hdr followed by 8-byte psc_entry structs, so only entries[0] and entries[1] are in-bounds. snp_begin_psc() validates end_entry against VMGEXIT_PSC_MAX_COUNT (253) but NOT against the actual buffer size: idx_end = hdr->end_entry; if (idx_end >= VMGEXIT_PSC_MAX_COUNT) { // checks 253, not buffer snp_complete_psc(svm, ...); return 1; } for (idx = idx_start; idx <= idx_end; idx++) { entry_start = entries[idx]; // OOB when idx >= 2 The guest sets end_entry=10+, causing the host to iterate entries[2+] which are OOB into adjacent slab objects. For each OOB entry: - The host reads 8 bytes (OOB READ / info leak oracle) - If the data passes PSC validation, __snp_complete_one_psc() writes cur_page = 1 or 512 into the entry (OOB WRITE, sev.c:3806) - If validation fails, the error response reveals whether adjacent memory is zero vs non-zero (information disclosure to guest) The guest controls allocation size (exit_info_2), entry range (cur_entry/end_entry), and can fire unlimited VMGEXITs to repeatedly hit different slab positions. By exploiting the variety of bugs, a malicious SEV-SNP guest can: - OOB read adjacent kmalloc-cg-32 objects (heap layout disclosure) - OOB write cur_page bits into adjacent objects (heap corruption) - Trigger use-after-free conditions across VMGEXITs E.g. with KASAN enabled, a single insmod of the PoC guest module produces 73 KASAN reports: BUG: KASAN: slab-out-of-bounds in snp_begin_psc+0x126/0x890 Read of size 8 at addr ffff888219ffb5e0 by task qemu-system-x86/2199 BUG: KASAN: slab-out-of-bounds in snp_begin_psc+0x468/0x890 Write of size 8 at addr ffff888351566648 by task qemu-system-x86/2199 The buggy address belongs to the object at ffff888XXXXXXXXX which belongs to the cache kmalloc-cg-32 of size 32 The buggy address is located N bytes to the right of allocated 32-byte region [ffff888XXXXXXXXX, ffff888XXXXXXXXX) Breakdown: 62 slab-out-of-bounds (reads + writes past allocation) 7 slab-use-after-free 4 use-after-free All credit to Stan for the wonderful description and reproducer! Reported-by: Stan Shaw Cc: Michael Roth Cc: Tom Lendacky Cc: Peter Gonda Cc: Jacky Li Fixes: 4af663c2f64a ("KVM: SEV: Allow per-guest configuration of GHCB protocol version") Cc: stable@vger.kernel.org Signed-off-by: Michael Roth [sean: write changelog] Reviewed-by: Tom Lendacky Signed-off-by: Sean Christopherson Message-ID: <20260501202250.2115252-2-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit ec62e8480e824cdb866cba21d2340111f53953be Author: Sean Christopherson Date: Fri May 15 10:15:36 2026 -0700 KVM: SVM: Flush the current TLB when transitioning from xAVIC => x2AVIC commit a9e18aa3263f356edae305e29830e5fe63d8597a upstream. Flush the current TLB when xAVIC *or* x2AVIC is activated, as KVM is (apparently) responsible for purging TLB entries when transitioning from xAVIC to x2AVIC. The APM says a whole lot of nothing about TLB flushing with respect to (x2)AVIC, but empirical data strongly suggests hardware also does a whole lot of nothing. Failure to flush the TLB when enabling x2AVIC can lead to guest accesses to the APIC base address getting incorrectly redirected to the virtual APIC page. The flaw most visibly manifests as failures in KVM-Unit-Test's verify_disabled_apic_mmio() testcase when x2APIC is enabled (though for reasons unknown, the test only reliably fails with EFI builds). Fixes: 0ccf3e7cb95a ("KVM: SVM: Flush the "current" TLB when activating AVIC") Fixes: 4d1d7942e36a ("KVM: SVM: Introduce logic to (de)activate x2AVIC mode") Cc: stable@vger.kernel.org Cc: Naveen N Rao (AMD) Link: https://patch.msgid.link/20260515171536.1841645-1-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit b1fc4a83dd4495d4c381dcdd3d19c6520e5fb62c Author: Qiang Ma Date: Tue May 26 15:46:40 2026 +0800 KVM: arm64: PMU: Preserve AArch32 counter low bits commit 1750ad1388e03fb27068cd1f22c9c8b4590fe936 upstream. AArch32 writes to PMU event counters cannot update the top 32 bits, even when PMUv3p5 makes the counters 64-bit. KVM therefore needs to preserve the existing high half and only update the low half written by the guest, unless the caller explicitly forces a full reset through PMCR.P. The current code masks @val down to the old high half before taking lower_32_bits(val), which means the low half is always zero. As a result, AArch32 writes to event counters discard the guest-provided low 32 bits instead of storing them. Build the new value from the old high 32 bits and the low 32 bits of the value supplied by the guest. Fixes: 26d2d0594d70 ("KVM: arm64: PMU: Do not let AArch32 change the counters' top 32 bits") Signed-off-by: Qiang Ma Signed-off-by: Marc Zyngier Link: https://patch.msgid.link/20260526074640.791991-1-maqianga@uniontech.com Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 625153b917bc490c8f05ea4c84463e42ec1e590c Author: Wentao Guan Date: Fri May 22 17:13:58 2026 +0800 USB: cdc-acm: Fix bit overlap and move quirk definitions to header commit 5eb070769ea5e18405535609d1d3f6886f3755bd upstream. The VENDOR_CLASS_DATA_IFACE and ALWAYS_POLL_CTRL quirk flags added in commit f58752ebcb35 ("USB: cdc-acm: Add quirks for Yoga Book 9 14IAH10 INGENIC touchscreen") were placed inside the acm_ctrl_msg() function rather than in the header with the other quirk flags. Then, their values (BIT(9) and BIT(10)) collided with NO_UNION_12 which is already BIT(9). Move the definitions to drivers/usb/class/cdc-acm.h where they belong and shift them to BIT(10) and BIT(11) to avoid the overlap. Fixes: f58752ebcb35 ("USB: cdc-acm: Add quirks for Yoga Book 9 14IAH10 INGENIC touchscreen") Cc: stable Signed-off-by: Wentao Guan Link: https://patch.msgid.link/20260522091357.1301196-1-guanwentao@uniontech.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 667599e718329b4e8396e6958aa16295554278ee Author: Alice Ryhl Date: Tue Apr 14 12:02:34 2026 +0000 rust_binder: avoid calling pending_oneway_finished() on TF_UPDATE_TXN commit 4c19719eb8b8df08c5bec7c499f73ddaea6f09fc upstream. When an outdated transaction is removed from `oneway_todo` due to `TF_UPDATE_TXN`, its `Allocation` is dropped. The current implementation of `Allocation::drop` calls `pending_oneway_finished()`, assuming the transaction was executed. This leads to premature execution of the next queued one-way transaction. Fix this by taking the `oneway_node` from the `Allocation` of the outdated transaction before it is dropped. This prevents `Allocation::drop` from signaling completion. We do not call `take_oneway_node()` from `Transaction::cancel` because it's actually correct to call `pending_oneway_finished()` on cancel if the transaction did not come from `oneway_todo`. This ensures that if `BINDER_THREAD_EXIT` is invoked and cancels a oneway transaction, then the next transaction is taken from `oneway_todo`. This bug does not lead to any issues in the kernel, but may lead to Binder delivering transactions to userspace earlier than userspace expected to receive them. Cc: stable Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver") Assisted-by: Antigravity:gemini Signed-off-by: Alice Ryhl Acked-by: Carlos Llamas Link: https://patch.msgid.link/20260414-tf-update-txn-fix-v1-1-d2b83303acc9@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit f2f2671e32c55e93247febfad3d71973a9f5046e Author: Matthew Maurer Date: Fri Apr 3 18:18:58 2026 +0000 rust_binder: Avoid holding lock when dropping delivered_death commit f6d8fea9e3953151a4adb4f603503dc3dc9c69da upstream. In 6c37bebd8c926, we switched to looping over the list and dropping each individual node, ostensibly without the lock held in the loop body. If the kernel were using Rust Edition 2024, the comment would be accurate, and the lock would not be held across the drop. However, the kernel is currently using 2021, so tail expression lifetime extension results in the lock being held across the drop. Explicitly binding the expression result to a variable makes the lockguard no longer part of a tail expression, causing the lock to be dropped before entering the loop body. This was detected via `CONFIG_PROVE_LOCKING` identifying an invalid wait context at the drop site. Reported-by: David Stevens Signed-off-by: Matthew Maurer Cc: stable Fixes: 6c37bebd8c92 ("rust_binder: avoid mem::take on delivered_deaths") Reviewed-by: Alice Ryhl Acked-by: Carlos Llamas Link: https://patch.msgid.link/20260403-lockhold-v1-1-c332b56cd8ae@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 74d6aae1df45d3414178986be743f946988fddf6 Author: Ben Hutchings Date: Tue May 5 20:45:12 2026 +0200 parport: Fix race between port and client registration commit ef15ccbb3e8640a723c42ad90eaf81d66ae02017 upstream. The parport subsystem registers port devices before they are fully initialised, resulting in a race condition where client drivers such as lp can attach to ports that are not completely initialised or even being torn down. When the port and client drivers are built as modules and loaded around the same time during boot, this occasionally results in a crash. I was able to make this happen reliably in a VM with a PC-style parallel port by patching parport_pc to fail probing: > --- a/drivers/parport/parport_pc.c > +++ b/drivers/parport/parport_pc.c > @@ -2069,7 +2069,7 @@ static struct parport *__parport_pc_probe_port(unsigned long int base, > if (!p) > goto out3; > > - base_res = request_region(base, 3, p->name); > + base_res = NULL; > if (!base_res) > goto out4; > and then running: while true; do modprobe lp & modprobe parport_pc wait rmmod lp parport_pc done for a few seconds. In the long term I think port registration should be changed to put the call to device_add() inside parport_announce_port(), but since the latter currently cannot fail this will require changing all port drivers. For now, add a flag to indicate whether a port has been "announced" and only try to attach client drivers to ports when the flag is set. Fixes: 6fa45a226897 ("parport: add device-model to parport subsystem") Closes: https://bugs.debian.org/1130365 Closes: https://lore.kernel.org/all/6ba903ad-9897-42bb-8c2d-337385cc3746@molgen.mpg.de/ Cc: stable Signed-off-by: Ben Hutchings Acked-by: Sudip Mukherjee Link: https://patch.msgid.link/afo6uBv68GDevbMD@decadent.org.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 9749db57233b396353ad5dee81eec9d9880c9246 Author: Dmitry Torokhov Date: Sun Apr 26 21:09:33 2026 -0700 Input: xpad - fix out-of-bounds access for Share button commit 6cdc46b38cf146ce81d4831b6472dbf7731849a2 upstream. xpadone_process_packet() receives len directly from urb->actual_length and uses it to index the share-button byte at data[len - 18] or data[len - 26]. Since both len and data[0] are under the device's control, a broken controller can send a GIP_CMD_INPUT packet with actual_length < 18 (e.g. 5 bytes) and reach this code path, causing accesses beyond the actual array. Fix this by calculating the offset and checking bounds against the packet length. Reported-by: Greg Kroah-Hartman Fixes: 4ef46367073b ("Input: xpad - fix Share button on Xbox One controllers") Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit d9019210c8c30d40eb20094274cc647e352f48f7 Author: Doruk Tan Ozturk Date: Mon May 25 18:24:38 2026 +0200 Bluetooth: hci_sync: fix UAF in hci_le_create_cis_sync commit bfea6091e0fffb270c20e74384b660910277eb6c upstream. hci_le_create_cis_sync() dereferences conn->conn_timeout after releasing both rcu_read_lock() and hci_dev_lock(hdev). The conn pointer was obtained from an RCU-protected iteration over hdev->conn_hash.list and is not valid once these locks are dropped. A concurrent disconnect can free the hci_conn between the unlock and the dereference, causing a use-after-free read. The cancellation mechanism in hci_conn_del() cannot prevent this because hci_le_create_cis_pending() queues hci_create_cis_sync with data=NULL: hci_cmd_sync_queue(hdev, hci_create_cis_sync, NULL, NULL); While hci_conn_del() dequeues with data=conn: hci_cmd_sync_dequeue(hdev, NULL, conn, NULL); Since NULL != conn, the lookup in _hci_cmd_sync_lookup_entry() never matches, and the pending work item is not cancelled. Fix this by saving conn->conn_timeout into a local variable while the locks are still held, so the stale conn pointer is never dereferenced after unlock. This is the same class of bug as the one fixed by commit 035c25007c9e ("Bluetooth: hci_sync: Fix UAF on le_read_features_complete") which addressed the identical pattern in a different function. This vulnerability was identified using 0sec.ai, an open-source automated security auditing platform (https://github.com/0sec-labs). Fixes: c09b80be6ffc ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED") Cc: stable@vger.kernel.org Reported-by: Doruk Tan Ozturk Signed-off-by: Doruk Tan Ozturk Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 2b7651f58670585426938886abdf872bd3fefa3f Author: Shuai Zhang Date: Mon May 25 14:51:56 2026 +0800 Bluetooth: hci_qca: Use 100 ms SSR delay for rampatch and NVM loading commit fa21e86caba2347e89eb65af926205a36a097c53 upstream. When bt_en is pulled high by hardware, the host does not re-download the firmware after SSR. The controller loads the rampatch and NVM internally. On HMT chip, the rampatch is ~264 KB and the NVM is ~9.4 KB. The loading process takes approximately 70 ms. The previous 50 ms delay is too short, causing the controller to not respond to the reset command sent by the host, which leads to BT initialization failure: Bluetooth: hci0: QCA memdump Done, received 458752, total 458752 Bluetooth: hci0: mem_dump_status: 2 Bluetooth: hci0: Opcode 0x0c03 failed: -110 Increase the delay to 100 ms, which was confirmed as a safe value by the controller, to ensure the controller has finished loading the firmware before the host sends commands. Steps to reproduce: 1. Trigger SSR and wait for SSR to complete: hcitool cmd 0x3f 0c 26 2. Run "bluetoothctl power on" and observe that BT fails to start. Fixes: fce1a9244a0f ("Bluetooth: hci_qca: Fix SSR (SubSystem Restart) fail when BT_EN is pulled up by hw") Cc: stable@vger.kernel.org Reviewed-by: Dmitry Baryshkov Signed-off-by: Shuai Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit e6b78019664dfe37c3dc707f50e7b453d6c7726d Author: Pavitra Jha Date: Thu May 21 04:04:14 2026 -0400 Bluetooth: hci_conn: Fix memory leak in hci_le_big_terminate() commit bfa9d28960ed677d556bdf097073bc3129686229 upstream. hci_le_big_terminate() allocates iso_list_data via kzalloc_obj but returns 0 without freeing it when neither pa_sync_term nor big_sync_term flags are set after evaluating the PA and BIG sync connection state. This early-return path was introduced when hci_le_big_terminate() was refactored to take struct hci_conn instead of raw u8 parameters, adding PA/BIG flag evaluation logic. The existing kfree() on hci_cmd_sync_queue failure does not cover this path. Fixes: a7bcffc673de ("Bluetooth: Add PA_LINK to distinguish BIG sync and PA sync connections") Cc: stable@vger.kernel.org Signed-off-by: Pavitra Jha Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit bc08c15746f25f41dd0508b25780d1e84acbb2ef Author: Muhammad Bilal Date: Wed May 27 04:59:18 2026 +0000 Bluetooth: ISO: serialize iso_sock_clear_timer with socket lock commit 4b5f8e608749b7e8fa386c6e4301cf9272595859 upstream. iso_sock_close() calls iso_sock_clear_timer() before acquiring lock_sock(sk). iso_sock_clear_timer() reads iso_pi(sk)->conn twice without the socket lock held: if (!iso_pi(sk)->conn) return; cancel_delayed_work(&iso_pi(sk)->conn->timeout_work); Concurrently, iso_conn_del() executes under lock_sock(sk) and calls iso_chan_del(), which sets iso_pi(sk)->conn to NULL and may result in the final reference to the connection being dropped: CPU0 CPU1 ---- ---- iso_sock_clear_timer() if (conn != NULL) ... lock_sock(sk) iso_chan_del() iso_pi(sk)->conn = NULL cancel_delayed_work(conn) /* NULL deref or UAF */ iso_pi(sk)->conn is not stable across the unlock window, causing a NULL pointer dereference or use-after-free. Serialize iso_sock_clear_timer() with the socket lock by moving it inside lock_sock()/release_sock(), matching the pattern used in iso_conn_del() and all other call sites. Fixes: ccf74f2390d60a2f9a75ef496d2564abb478f46a ("Bluetooth: Add BTPROTO_ISO socket type") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit c318aa51830a3d2cc1229968fe521441c97356cd Author: Muhammad Bilal Date: Wed May 27 04:59:17 2026 +0000 Bluetooth: ISO: fix UAF in iso_recv_frame commit 47f23a259517abbdb8032c057a1e8a6bf3734878 upstream. iso_recv_frame reads conn->sk under iso_conn_lock but releases the lock before using sk, with no reference held. A concurrent iso_sock_kill() can free sk in that window, causing use-after-free on sk->sk_state and sock_queue_rcv_skb(). Fix by replacing the bare pointer read with iso_sock_hold(conn), which calls sock_hold() while the spinlock is held, atomically elevating the refcount before the lock drops. Add a drop_put label so sock_put() is called on all exit paths where the hold succeeded. Fixes: ccf74f2390d60a2f9a75ef496d2564abb478f46a ("Bluetooth: Add BTPROTO_ISO socket type") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 6348dfed5b0f9c6074f14322332e97493d32fef0 Author: Muhammad Bilal Date: Wed May 20 18:56:43 2026 -0400 Bluetooth: HIDP: fix missing length checks in hidp_input_report() commit 2a3ac9ee11dbb9845f3947cef4a79dba658cf6f6 upstream. hidp_input_report() reads keyboard and mouse payload data from an skb without first verifying that skb->len contains enough data. hidp_recv_intr_frame() pulls the 1-byte HIDP header before dispatching to hidp_input_report(). If a paired device sends a truncated packet, the handler reads beyond the valid skb data, resulting in an out-of-bounds read of skb data. The OOB bytes may be interpreted as phantom key presses or spurious mouse movement. Replace the open-coded length tracking and pointer arithmetic with skb_pull_data() calls. skb_pull_data() returns NULL if the requested bytes are not present, eliminating the need for a manual size variable and the separate skb->len guard. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit e8a5baff5be273ca07771fd2b9bb1f2a4152917b Author: Siwei Zhang Date: Wed May 20 22:30:36 2026 -0400 Bluetooth: L2CAP: fix chan ref leak in l2cap_chan_timeout() on !conn commit 9dbd84990394c51f5cee1e8871bb5ff8af5ed939 upstream. __set_chan_timer() takes a l2cap_chan reference via l2cap_chan_hold() before scheduling the delayed work. The normal path in l2cap_chan_timeout() drops this reference with l2cap_chan_put() at the end, but the early return when chan->conn is NULL skips the put, leaking the reference. Add the missing l2cap_chan_put() before the early return. Fixes: adf0398cee86 ("Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout") Cc: stable@vger.kernel.org Signed-off-by: Siwei Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 859d3ace791ed878ae9ba5522c7844d960da8f88 Author: Siwei Zhang Date: Wed May 20 22:12:20 2026 -0400 Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen() commit 8c8e620467a7b51562dbcefbd1f09f288d7d710d upstream. l2cap_chan_close() removes the channel from conn->chan_l, which must be done under conn->lock. cleanup_listen() runs under the parent sk_lock, so acquiring conn->lock would invert the established conn->lock -> chan->lock -> sk_lock order. Instead of calling l2cap_chan_close() directly, schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously. The timeout handler already acquires conn->lock and chan->lock in the correct order. The timer is only armed when chan->conn is still set: if it is already NULL, l2cap_conn_del() has already processed this channel (l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb), so there is nothing left to do. If l2cap_conn_del() races in after the timer is armed, __clear_chan_timer() inside l2cap_chan_del() cancels it; if the timer has already fired, the handler returns harmlessly because chan->conn was cleared. Fixes: 3df91ea20e74 ("Bluetooth: Revert to mutexes from RCU list") Cc: # 0b58004: Bluetooth: fix UAF in l2cap_sock_cleanup_listen() vs l2cap_conn_del() Signed-off-by: Siwei Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 388051f7389a61697c69691e5a40bb977cebd57c Author: Steve French Date: Fri May 22 18:28:49 2026 -0500 smb: client: fix uninitialized variable in smb2_writev_callback commit 9d2491197a00acf8c423512078458c2855102b66 upstream. compiling with W=2 pointed out that "written may be used uninitialized" Fixes: 20d72b00ca81 ("netfs: Fix the request's work item to not require a ref") Cc: stable@vger.kernel.org Reviewed-by: David Howells Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 197476b126010bac1b3199833c6966cd6f54c2a9 Author: Stepan Ionichev Date: Thu May 14 22:43:42 2026 +0500 auxdisplay: line-display: fix OOB read on zero-length message_store() commit a7511dcd9dd4bc55d123f9b800c8a4ed2662e5c6 upstream. linedisp_display() unconditionally reads msg[count - 1] before checking whether count is zero, so a write of zero bytes to the message sysfs attribute hits msg[-1]: write(fd, "", 0); -> message_store(..., buf, count=0) -> linedisp_display(linedisp, buf, count=0) -> msg[count - 1] == '\n' ; OOB read The kernfs write buffer for that store is a 1-byte allocation (kernfs_fop_write_iter() does kmalloc(len + 1) with len == 0), so msg[-1] is a 1-byte read before the slab object. On a KASAN-enabled kernel this trips an out-of-bounds report and panics; on stock kernels it silently reads adjacent slab data and, if that byte happens to be '\n', the following count-- wraps ssize_t 0 to -1 and is then passed to kmemdup_nul(). linedisp_display() is reached from the message_store() sysfs callback (drivers/auxdisplay/line-display.c message attribute, mode 0644) and from the in-tree initial-message setup with count == -1, so the OOB path is only userspace-triggerable via zero-byte writes; vfs_write() does not short-circuit on count == 0 and kernfs_fop_write_iter() dispatches the store callback regardless. Guard the trailing-newline trim with a count check. The existing if (!count) block then takes the clear-display path unchanged. Affects every auxdisplay driver that registers via linedisp_register() / linedisp_attach(): ht16k33, max6959, img-ascii-lcd, seg-led-gpio. Fixes: 7e76aece6f03 ("auxdisplay: Extract character line display core support") Signed-off-by: Stepan Ionichev Signed-off-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit 0fcc34d0d8fefca4fea349e45c10e3a3d90350eb Author: Dev Jain Date: Mon May 18 12:06:56 2026 +0530 mm/rmap: initialize nr_pages to 1 at loop start in try_to_unmap_one commit 3f8968e9cbf95d5d87d32218906cab0b9b9eddbe upstream. Initialize nr_pages to 1 at the start of each loop iteration, like folio_referenced_one() does. Without this, nr_pages computed by a previous folio_unmap_pte_batch() call can be reused on a later iteration that does not run folio_unmap_pte_batch() again. mmap a 64K large folio with MAP_ANONYMOUS | MAP_DROPPABLE, then call madvise(MADV_FREE), then make the last page device-exclusive via HMM_DMIRROR_EXCLUSIVE. Trigger node reclaim through sysfs. Now, in try_to_unmap_one(), we will first clear the first 15 out of 16 entries mapping the lazyfree folio. This will set nr_pages to 15. In the next pvmw walk, this nr_pages gets reused on a device-exclusive pte, thus potentially corrupting folio refcount/mapcount. At the moment, I have a userspace program which can make the kernel spit out a trace, but the blow up is in folio_referenced_one(), because there are existing bugs in the interaction between device-private and rmap (which too I am investigating). I did a one liner kernel change to avoid going into folio_referenced_one(), and the kernel blows up at folio_remove_rmap_ptes in try_to_unmap_one which is what I wanted. Note that the bug is there not since file folio batching but lazyfree folio batching, since device-exclusive only works for anonymous folios. Userspace visible effect is simply kernel crashing somewhere due to refcount/mapcount corruption. Link: https://lore.kernel.org/20260518063656.3721056-1-dev.jain@arm.com Fixes: 354dffd29575 ("mm: support batched unmap for lazyfree large folios during reclamation") Signed-off-by: Dev Jain Acked-by: Barry Song Acked-by: David Hildenbrand (Arm) Reviewed-by: Lorenzo Stoakes Cc: Anshuman Khandual Cc: Barry Song Cc: Dev Jain Cc: Harry Yoo Cc: Jann Horn Cc: Liam R. Howlett Cc: Rik van Riel Cc: Ryan Roberts Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 0995d1f79aed8ccbf62056189dd53fd19726ea08 Author: Pratyush Yadav (Google) Date: Tue May 5 15:39:20 2026 +0200 memfd: deny writeable mappings when implying SEAL_WRITE commit 3b041514cb6eae45869b020f743c14d983363222 upstream. When SEAL_EXEC is added, SEAL_WRITE is implied to make W^X. But the implied seal is set after the check that makes sure the memfd can not have any writable mappings. This means one can use SEAL_EXEC to apply SEAL_WRITE while having writeable mappings. This breaks the contract that SEAL_WRITE provides and can be used by an attacker to pass a memfd that appears to be write sealed but can still be modified arbitrarily. Fix this by adding the implied seals before the call for mapping_deny_writable() is done. Link: https://lore.kernel.org/20260505133922.797635-1-pratyush@kernel.org Fixes: c4f75bc8bd6b ("mm/memfd: add write seals when apply SEAL_EXEC to executable memfd") Signed-off-by: Pratyush Yadav (Google) Reviewed-by: Pasha Tatashin Acked-by: Jeff Xu Cc: Baolin Wang Cc: Brendan Jackman Cc: Greg Thelen Cc: Hugh Dickins Cc: Kees Cook Cc: "David Hildenbrand (Arm)" Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit f1f0cdca932be50f278385574661822abb9ae326 Author: Alexandre Ghiti Date: Mon May 18 10:28:19 2026 +0200 mm: memcontrol: propagate NMI slab stats to memcg vmstats commit e16f17a9c5af50221184d1ef4be4056bf3c4209e upstream. flush_nmi_stats() drains per-node NMI slab atomics into the per-node lruvec_stats, but does not propagate them to the memcg-level vmstats. For non NMI case, account_slab_nmi_safe() calls mod_memcg_lruvec_state() which updates both per-node lruvec_stats and memcg-level vmstats, so flush_nmi_stats() needs to flush to per-node lruvec_stats as well as memcg-level vmstats. So fix this by flushing to the memcg-level vmstats for NMI too. Link: https://lore.kernel.org/20260518082830.599102-1-alex@ghiti.fr Fixes: 940b01fc8dc1 ("memcg: nmi safe memcg stats for specific archs") Signed-off-by: Alexandre Ghiti Acked-by: Shakeel Butt Acked-by: Johannes Weiner Reviewed-by: Harry Yoo (Oracle) Cc: Michal Hocko Cc: Muchun Song Cc: Roman Gushchin Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit a3cc795129e5ec0f8948653a3bf471e7d8852f5e Author: Linpu Yu Date: Sun May 10 13:43:30 2026 +0800 ipc: limit next_id allocation to the valid ID range commit fa0b9b2b7ae3539908d69c2b9ac0d144d9bc5139 upstream. The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx 4. Later removal goes through ipc_rmid(), which uses: ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index. 5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer. 6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory. Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted. Link: https://lore.kernel.org/cover.1778336914.git.linpu5433@gmail.com Link: https://lore.kernel.org/2eebe949bfa7d1f6e13b5be6a92c64c850ce9d45.1778336914.git.linpu5433@gmail.com Fixes: 03f595668017 ("ipc: add sysctl to specify desired next object id") Signed-off-by: Linpu Yu Signed-off-by: Ren Wei Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Cc: Kees Cook Cc: Stanislav Kinsbursky Cc: Davidlohr Bueso Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 0ba6c05156d9ff9fc6ca22b7690e2eec9eca66f7 Author: SeongJae Park Date: Mon May 18 08:25:58 2026 -0700 mm/damon/sysfs-schemes: delete tried region in regions_rmdirs() commit 441f92f7d386b85bad16de49db95a307cba048a2 upstream. DAMON sysfs maintains the DAMOS tried region directory objects via a linked list. When the user requests refresh of the directories, DAMON sysfs removes all the region directories first, and then generate updated regions directory on the empty space. The removal function (damon_sysfs_scheme_regions_rm_dirs()) only puts the kobj objects. Deletion of the container region object from the linked list is done inside the kobj release callback function. If somehow the callback invocation is delayed, the list will contain regions list that gonna be freed. If the updated region directories creation is started in this situation, the list can be corrupted and use-after-free can happen. Because the kobj objects are managed by only DAMON sysfs, the issue cannot happen in normal situation. But, such delays can be made on kernels that built with CONFIG_DEBUG_KOBJECT_RELEASE. On the kernel, the issue can indeed be reproduced like below. # damo start --damos_action stat # cd /sys/kernel/mm/damon/admin/kdamonds/0/ # for i in {1..10}; do echo update_schemes_tried_regions > state; done # dmesg | grep underflow [ 89.296152] refcount_t: underflow; use-after-free. Fix the issue by removing the region object from the list when decrementing the reference count. Also update damos_sysfs_populate_region_dir() to add the region object to the list only after the kobject_init_and_add() is success, so that fail of kobject_init_and_add() is not leaving the deallocated object on the list. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260518152559.93038-1-sj@kernel.org Link: https://lore.kernel.org/20260513011920.119183-1-sj@kernel.org [1] Fixes: 9277d0367ba1 ("mm/damon/sysfs-schemes: implement scheme region directory") Signed-off-by: SeongJae Park Cc: # 6.2.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 0886c6f257fe3663f80218aa1919b0f3f21bf22c Author: Mikulas Patocka Date: Mon May 25 14:48:58 2026 +0200 hpfs: fix a crash if hpfs_map_dnode_bitmap fails commit 974820a59efde7c1a7e1260bcfe9bb81f833cc9f upstream. If hpfs_map_dnode_bitmap fails, the code would call hpfs_brelse4 on uninitialized quad buffer head, causing a crash. Signed-off-by: Mikulas Patocka Reported-by: Farhad Alemi Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 4064a30381fadefc42114fcbd178dd1c73626e88 Author: Shuai Zhang Date: Thu May 21 13:25:47 2026 +0800 Bluetooth: btusb: Allow firmware re-download when version matches commit 82855073c1081732656734b74d7d1d5e4cfd0da7 upstream. The Bluetooth host decides whether to download firmware by reading the controller firmware download completion flag and firmware version information. If a USB error occurs during the firmware download process (for example due to a USB disconnect), the download is aborted immediately. An incomplete firmware transfer does not cause the controller to set the download completion flag, but the firmware version information may be updated at an early stage of the download process. In this case, after USB reconnection, the host attempts to re-download the firmware because the download completion flag is not set. However, since the controller reports the same firmware version as the target firmware, the download is skipped. This ultimately results in the firmware not being properly updated on the controller. This change removes the restriction that skips firmware download when the versions are equal. It covers scenarios where the USB connection can be disconnected at any time and ensures that firmware download can be retriggered after USB reconnection, allowing the Bluetooth firmware to be correctly and completely updated. Fixes: 3267c884cefa ("Bluetooth: btusb: Add support for QCA ROME chipset family") Cc: stable@vger.kernel.org Signed-off-by: Shuai Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 6728e80c9d292b194133c9b98663ce14784884fd Author: hlleng Date: Tue May 12 09:57:37 2026 +0800 HID: quirks: Add ALWAYS_POLL quirk for SIGMACHIP USB mouse commit 07466fc91c55532edcfb5c6a7ccd2ea52728d6bd upstream. The SIGMACHIP USB mouse with VID/PID 1c4f:0034 can disconnect and re-enumerate repeatedly after it has been enumerated if its interrupt endpoint is not continuously polled. This was observed with the device reporting itself as "SIGMACHIP Usb Mouse". Keeping the input event device open avoids the disconnects. Add HID_QUIRK_ALWAYS_POLL for this device so the HID core keeps polling it even when there is no userspace input consumer. Cc: stable@vger.kernel.org Signed-off-by: hlleng Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 8735a28f2dcd6facc199752162592eb98ae4b419 Author: Thomas Fourier Date: Fri May 22 10:54:04 2026 +0200 Input: ims-pcu - fix usb_free_coherent() size in ims_pcu_buffers_free() commit dab48a7e74e6a394f3aa0461a2b1fb0c7b38fcb8 upstream. The input buffer size is pcu->max_in_size, but pcu->max_out_size is passed to usb_free_coherent(). Change size to match the allocation size. Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver") Cc: stable@vger.kernel.org Signed-off-by: Thomas Fourier Link: https://patch.msgid.link/20260522085412.45430-2-fourier.thomas@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit f33b5a61673bd220fdaaf4202cf1013d6d66c943 Author: Henri A Date: Wed May 20 10:25:44 2026 -0400 media: rc: igorplugusb: fix control request setup packet commit 171022c7d594c133a45f92357a2a91475edabe20 upstream. Commit eac69475b01f ("media: rc: igorplugusb: heed coherency rules") changed the control request storage from an embedded struct to an allocated pointer so it can obey DMA coherency rules. However, the driver still passes &ir->request to usb_fill_control_urb(). That points the URB setup packet at the pointer field itself rather than at the allocated struct usb_ctrlrequest. USB core then interprets pointer bytes as the setup packet. This can produce an invalid bRequestType and trigger the control direction warning reported by syzbot: usb 2-1: BOGUS control dir, pipe 80003580 doesn't match bRequestType 0 Pass ir->request itself as the setup packet. Fixes: eac69475b01f ("media: rc: igorplugusb: heed coherency rules") Reported-by: syzbot+11f0e4f957c7c3bf3d51@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=11f0e4f957c7c3bf3d51 Tested-by: syzbot+11f0e4f957c7c3bf3d51@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5.5 Signed-off-by: Henri A Signed-off-by: Sean Young Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit f793b67d41e5fab719c5a90baa77cbd2fe259517 Author: Johan Hovold Date: Fri May 22 16:22:18 2026 +0200 USB: serial: safe_serial: fix memory corruption with small endpoint commit 438061ed1ad85e6743e2dce826671772d81089ec upstream. Make sure that the bulk-out buffer size is at least eight bytes to avoid user-controlled slab corruption in "safe" mode should a malicious device report a smaller size. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 0edd1e21587b0483c7ceb993b9fb9668bbef7433 Author: Greg Kroah-Hartman Date: Wed May 13 17:52:55 2026 +0200 usb: typec: ucsi: validate connector number in ucsi_connector_change() commit 288a81a8507052bcfbf884d39a463c44c42c5fd9 upstream. The connector number in a UCSI CCI notification is a 7-bit field supplied by the PPM. ucsi_connector_change() uses it to index the ucsi->connector[] array without checking it against the number of connectors the PPM reported at init time, so a buggy or malicious PPM (EC firmware, or an I2C-attached UCSI controller on the ccg / stm32g0 / glink transports) can drive schedule_work() on memory past the end of the array. Reject connector numbers that are zero or exceed cap.num_connectors before dereferencing the array. Assisted-by: gkh_clanker_t1000 Cc: Heikki Krogerus Cc: Benson Leung Cc: Jameson Thies Cc: Nathan Rebello Cc: Johan Hovold Cc: Pooja Katiyar Cc: Hsin-Te Yuan Cc: Abel Vesa Cc: stable Reviewed-by: Abel Vesa Reviewed-by: Heikki Krogerus Reviewed-by: Benson Leung Link: https://patch.msgid.link/2026051351-truck-steadfast-df48@gregkh Signed-off-by: Greg Kroah-Hartman commit 9b496e3371c04f0a03b7faa5d2442536d00e3998 Author: Greg Kroah-Hartman Date: Wed May 13 17:52:50 2026 +0200 usb: typec: tcpm/tcpci_maxim: validate header NDO against RX_BYTE_CNT commit aa2f716327be1818e1cb156da8a2844804aaec2f upstream. A broken/malicious port can transmit a CRC-valid frame whose header advertises up to seven data objects but whose body carries fewer than that. Check for this, and rightfully reject the message, instead of reading from uninitialized stack memory. Assisted-by: gkh_clanker_t1000 Cc: Heikki Krogerus Cc: "André Draszik" Cc: Badhri Jagan Sridharan Cc: Amit Sunil Dhamne Cc: stable Link: https://patch.msgid.link/2026051350-sitter-canopener-9045@gregkh Signed-off-by: Greg Kroah-Hartman commit e94933dc41b87503bf585c8c6d53d740620eceb9 Author: Greg Kroah-Hartman Date: Wed May 13 17:52:48 2026 +0200 usb: typec: wcove: don't write past struct pd_message in wcove_read_rx_buffer() commit 4af7ad0e6d7aa4403dbb1dac7b9659b0421efcaa upstream. wcove_read_rx_buffer() copies the PD RX FIFO into the caller's struct pd_message with for (i = 0; i < USBC_RXINFO_RXBYTES(info); i++) regmap_read(wcove->regmap, USBC_RX_DATA + i, msg + i); which has two problems: USBC_RXINFO_RXBYTES() is a 5-bit field (max 31) while struct pd_message is 30 bytes (__le16 header + __le32 payload[PD_MAX_PAYLOAD], packed). The byte count latched in RXINFO is the number of bytes the port partner put on the wire, so a malicious partner that transmits a 31-byte frame can drive the loop one byte past the destination if the WCOVE BMC receiver does not enforce the PD object-count limit in hardware. The existing FIXME flagged this as unverified. Independently, regmap_read() takes an unsigned int * and stores a full unsigned int at the destination. Passing the byte pointer msg + i means each iteration writes four bytes; the high three are zero (val_bits is 8) and are normally overwritten by the next iteration, but the final iteration's high bytes are not. With RXBYTES == 30 the i == 29 iteration already writes three zero bytes past msg, which sits on the IRQ thread's stack in wcove_typec_irq(). Clamp the loop to sizeof(struct pd_message) and read each register into a local before storing only its low byte, so the copy can never exceed the destination regardless of what RXINFO reports. Assisted-by: gkh_clanker_t1000 Cc: stable Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/2026051347-clustered-deflected-9543@gregkh Signed-off-by: Greg Kroah-Hartman commit b10eff5abe6aa2a5af10ed17bddff76e3b6e6b9b Author: Greg Kroah-Hartman Date: Wed May 13 17:52:49 2026 +0200 usb: typec: altmodes/displayport: validate count before reading Status Update VDO commit 8a18f896e667df491331371b55d4ad644dc51d60 upstream. A broken/malicious device can send the incorrect count for a status update VDO, which will cause the kernel to read uninitialized stack data and send it off elsewhere. Fix this up by correctly verifying the count for the update object. Assisted-by: gkh_clanker_t1000 Cc: stable Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/2026051350-reacquire-sculpture-4244@gregkh Signed-off-by: Greg Kroah-Hartman commit 052dbef45cb36b89b503d72ea6b22d5f5bb1e586 Author: Greg Kroah-Hartman Date: Wed May 13 17:52:54 2026 +0200 usb: typec: ucsi: displayport: NAK DP_CMD_CONFIGURE without a payload VDO commit 167dd8d12226587ee554f520aed0256b7769cd5d upstream. ucsi_displayport_vdm() handles a DP_CMD_CONFIGURE by copying the first payload VDO from data[], but unlike the equivalent handler in altmodes/displayport.c it does not check that count covers a VDO beyond the header. A header-only Configure VDM (count == 1) would read one u32 past the caller's array. In the normal UCSI path the caller controls count, so this is hardening for non-standard delivery paths. NAK and bail when no configuration VDO is present, matching the generic DP altmode driver's existing guard. Assisted-by: gkh_clanker_t1000 Cc: Pooja Katiyar Cc: Johan Hovold Cc: stable Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/2026051351-vividly-flattered-eb3d@gregkh Signed-off-by: Greg Kroah-Hartman commit 4505f33dab56c274e82f47f94bf60a8cbf8f4b42 Author: Greg Kroah-Hartman Date: Wed May 13 17:52:53 2026 +0200 usb: typec: tcpm: bound altmode_desc[] per iteration in svdm_consume_modes() commit 3389c149c68c3fea61910ad5d34f7bf3bff44e32 upstream. svdm_consume_modes() checks pmdata->altmodes against the array size once before the loop over the count, but forgot to check the bound at every point in the loop. In the well-behaved SVDM discovery flow this is harmless because each of at most SVID_DISCOVERY_MAX SVIDs contributes at most MODE_DISCOVERY_MAX modes, exactly filling altmode_desc[ALTMODE_DISCOVERY_MAX]. But the CMDT_RSP_ACK handler in tcpm_pd_svdm() does not correlate an incoming ACK with any request the port actually sent. Once port->partner is set, an unsolicited Discover Modes ACK is consumed unconditionally. A broken or malicious port partner can therefore drive altmodes to ALTMODE_DISCOVERY_MAX - 1 via the normal flow, and then send one extra Discover Modes ACK with seven VDOs. Because the pre-loop check passes, the loop could then writes up to five entries past altmode_desc[]. For mode_data_prime the next field in struct tcpm_port is the partner_altmode[] pointer array, which then receives partner-chosen SVID/VDO bytes. Move the bound check inside the loop so the array can never be indexed past ALTMODE_DISCOVERY_MAX regardless of how many VDOs the partner supplies or how the function was reached. Assisted-by: gkh_clanker_t1000 Cc: Badhri Jagan Sridharan Cc: Heikki Krogerus Cc: stable Link: https://patch.msgid.link/2026051351-reshuffle-skillful-90af@gregkh Signed-off-by: Greg Kroah-Hartman commit f9d787fbe83127105e42088cca40e5118db0d810 Author: Greg Kroah-Hartman Date: Wed May 13 17:52:51 2026 +0200 usb: typec: tcpm: validate VDO count in Discover Identity ACK handlers commit 8fbc349e8383125dd2d8de1c1e926279d398ab17 upstream. Properly validate the count passed from a device when calling svdm_consume_identity() or svdm_consume_identity_sop_prime() as the device-controlled value could index off of the static arrays, which could leak data. Assisted-by: gkh_clanker_t1000 Cc: Heikki Krogerus Cc: stable Reviewed-by: Badhri Jagan Sridharan Link: https://patch.msgid.link/2026051350-plated-salute-0efe@gregkh Signed-off-by: Greg Kroah-Hartman commit a38ed87818b2419090fb1a6338ddce6842b65dfa Author: Greg Kroah-Hartman Date: Thu May 14 19:10:06 2026 +0200 usb: typec: ucsi: ccg: reject firmware images without a ':' record header commit d7486952bf74e546ee3748fb14b2d07881fa6273 upstream. do_flash() locates the first .cyacd record with p = strnchr(fw->data, fw->size, ':'); while (p < eof) { s = strnchr(p + 1, eof - p - 1, ':'); ... } If the firmware image contains no ':' byte, strnchr() returns NULL. NULL compares less than the valid kernel pointer eof, so the loop body runs and strnchr() is called with p + 1 == (void *)1 and a length of roughly (unsigned long)eof, causing a wonderful crash. The not_signed_fw fallthrough earlier in do_flash() and the chip-state branches in ccg_fw_update_needed() allow an unsigned blob to reach this loop, so a root user who can place a crafted file under /lib/firmware and write the do_flash sysfs attribute can trigger the oops. Bail out with -EINVAL when the initial strnchr() returns NULL. Assisted-by: gkh_clanker_t1000 Cc: stable Cc: Heikki Krogerus Reviewed-by: Heikki Krogerus Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2026051405-posture-shrill-7884@gregkh Signed-off-by: Greg Kroah-Hartman commit a58400f58f82f3d8de9c067aa7cda690228c1ecc Author: Greg Kroah-Hartman Date: Thu Apr 9 15:40:47 2026 +0200 iio: pressure: bmp280: fix stack leak in bmp580 trigger handler commit 387c86b582e0782ab332e7bfcd4e6e3f93922961 upstream. bmp580_trigger_handler() declares its scan buffer on the stack without an initializer and then memcpy()s 3 bytes of 24-bit sensor data into each 4-byte __le32 field. The high byte of comp_temp and comp_press is left uninitialized, and the channel storagebits is 32, so two bytes of stack are pushed to userspace per scan. This is a regression from when the buffer lived in the private data, the move to a stack-local struct dropped the implicit zeroing. bme280_trigger_handler() was fixed up to handle this bug, but this driver was not fixed because there was no padding hole, but rather a short-fill issue. Fix this all by just zero-initializing the structure on the stack. Cc: Jonathan Cameron Cc: David Lechner Cc: "Nuno Sá" Cc: Andy Shevchenko Fixes: 872c8014e05e ("iio: pressure: bmp280: drop sensor_data array") Cc: stable Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Reviewed-by: David Lechner Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit ce582b22dd2ff15ac99101c22ec1559d1febe2ff Author: Greg Kroah-Hartman Date: Thu Apr 9 15:40:49 2026 +0200 iio: imu: adis16550: fix stack leak in trigger handler commit 474f8928d50b09f7dcf507049f08732640b88b49 upstream. adis16550_trigger_handler() declares the scan data array on the stack without initializing it. The memcpy() at the bottom fills only the first 28 bytes (TEMP + 6 channels of GYRO/ACCEL data), and iio_push_to_buffers_with_timestamp() writes the s64 timestamp at the 8-byte-aligned offset 32. Bytes 28-31 remain uninitialized stack data which leaks to userspace on ever trigger. Fix this all by just zero-initializing the structure on the stack. Cc: Lars-Peter Clausen Cc: Michael Hennerich Cc: Jonathan Cameron Cc: David Lechner Cc: "Nuno Sá" Cc: Andy Shevchenko Fixes: e4570f4bb231 ("iio: imu: adis16550: align buffers for timestamp") Cc: stable Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Reviewed-by: David Lechner Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit e6bb3a49c5f9de870ea95e69775df785728e3366 Author: Greg Kroah-Hartman Date: Thu Apr 9 15:40:48 2026 +0200 iio: imu: st_lsm6dsx: fix stack leak in tagged FIFO buffer commit c9d8e9adaa63150ef7e833480b799d0bab83a276 upstream. The tagged FIFO path declares iio_buff on the stack with __aligned(8) but no initializer, but there is a hole in the structure, which will then leak to userspace as ST_LSM6DSX_SAMPLE_SIZE bytes (6) will be copied, but the space between that and the timestamp are not initialized. Commit c14edb4d0bdc ("iio:imu:st_lsm6dsx Fix alignment and data leak issues") moved the untagged FIFO path to a kzalloc'd buffer in hw->scan, but for the tagged path it only added the alignment qualifier and not the initializer :( Fix this by just zero-initializing the structure on the stack. Cc: Lorenzo Bianconi Cc: Jonathan Cameron Cc: David Lechner Cc: "Nuno Sá" Cc: Andy Shevchenko Fixes: c14edb4d0bdc ("iio:imu:st_lsm6dsx Fix alignment and data leak issues") Cc: stable Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Reviewed-by: David Lechner Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 278b0df1f736faa30e18806edd9b4591a51f190b Author: Horatiu Vultur Date: Thu Oct 23 21:13:49 2025 +0200 phy: mscc: Use PHY_ID_MATCH_EXACT for VSC8584, VSC8582, VSC8575, VSC856X [ Upstream commit 1bc80d673087e5704adbb3ee8e4b785c14899cce ] As the PHYs VSC8584, VSC8582, VSC8575 and VSC856X exists only as rev B, we can use PHY_ID_MATCH_EXACT to match exactly on revision B of the PHY. Because of this change then there is not need the check if it is a different revision than rev B in the function vsc8584_probe() as we already know that this will never happen. These changes are a preparation for the next patch because in that patch we will make the PHYs VSC8574 and VSC8572 to use vsc8584_probe() and these PHYs have multiple revision. Reviewed-by: Maxime Chevallier Signed-off-by: Horatiu Vultur Link: https://patch.msgid.link/20251023191350.190940-2-horatiu.vultur@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 487393023feb57ce5305e00eaae21dd50520f3d0 Author: Jouni Högander Date: Fri May 29 13:06:13 2026 +0300 drm/i915/psr: Apply Intel DPCD workaround when SDP on prior line used commit 4703049f768fc1c1caac754134118bee1a3af189 upstream. There is Intel specific workaround DPCD address containing workaround for case where SDP is on prior line. Apply this workaround according to values in the offset. Fixes: 61e887329e33 ("drm/i915/xelpd: Handle PSR2 SDP indication in the prior scanline") Cc: # v5.15+ Signed-off-by: Jouni Högander Reviewed-by: Suraj Kandpal Link: https://patch.msgid.link/20260515095756.2799483-4-jouni.hogander@intel.com (cherry picked from commit c3fe899fbeac86ea4a5ca9dd845b2cbc0da46249) Signed-off-by: Tvrtko Ursulin Signed-off-by: Jouni Högander Signed-off-by: Sasha Levin commit c058cf6b84c131c3f535f5fd08ec6eba1e9da9df Author: Jouni Högander Date: Fri May 29 13:06:12 2026 +0300 drm/i915/psr: Read Intel DPCD workaround register commit f30bece421a4ae34359254e1dc2a187a42b6af9b upstream. Read Intel DPCD workaround register and store it into intel_connector->dp.psr_caps. psr_caps was chosen as currently it contains only PSR workaround for PSR2 SDP on prior scanline implementation. Signed-off-by: Jouni Högander Reviewed-by: Suraj Kandpal Link: https://patch.msgid.link/20260515095756.2799483-3-jouni.hogander@intel.com (cherry picked from commit c48ff24d0f4ab7ad696b2d35ad64ce7e049c668c) Signed-off-by: Tvrtko Ursulin Signed-off-by: Sasha Levin commit dd4cbab2a446d87b94f8337e38653a0f9a679ded Author: Jouni Högander Date: Fri May 29 13:06:11 2026 +0300 drm/i915/psr: Add defininitions for INTEL_WA_REGISTER_CAPS DPCD register commit fbceb39b536e40c2f7cc47ab42037bb7c2b7ced9 upstream. EDP specification says: "If either VSC SDP is unable to be transmitted 100 ns before the SU region, the Source device may optionally transmit the VSC SDP during the prior video scan line’s HBlank period There is a Intel specific drm dp register currently containing bits related how TCON can support PSR2 with SDP on prior line." Unfortunately many panels are having problems in implementing this. So there is a custom Intel specific DPCD register (INTEL_WA_REGISTER_CAPS) to figure out if this is properly implemented on a panel or if panel doesn't require that 100 ns delay before the SU region. Here are the definitions in this custom DPCD address: 0 = Panel doesn't support SDP on prior line 1 = Panel supports SDP on prior line 2 = Panel doesn't have 100ns requirement 3 = Reserved Add definitions for this new register and it's values into new header intel_dpcd.h. v2: add INTEL_DPCD_ prefix to definitions Bspec: 74741 Signed-off-by: Jouni Högander Reviewed-by: Suraj Kandpal Link: https://patch.msgid.link/20260515095756.2799483-2-jouni.hogander@intel.com (cherry picked from commit 1da1c9294825f08f622c473480d185680c2a3b75) Signed-off-by: Tvrtko Ursulin Signed-off-by: Sasha Levin commit 600ad63124deada4ed039cd2949b0705e93bb640 Author: Peter Oberparleiter Date: Tue Jun 2 18:22:21 2026 +0200 s390/cio: Restore GFP_DMA for CHSC allocation [ Upstream commit ea34567db0a6b3a7ce78ba421592344315c8f90e ] Re-add GFP_DMA when allocating memory for CHSC control blocks. On some supported machines, CHSC cannot access memory outside the DMA zone, causing CHSC command failures. Cc: stable@vger.kernel.org Fixes: a3a64a4def8d ("s390/cio: remove unneeded DMA zone allocation") Signed-off-by: Peter Oberparleiter Reviewed-by: Heiko Carstens Signed-off-by: Alexander Gordeev [ adjusted context to account for missing commit bf4afc53b77ae ] Signed-off-by: Peter Oberparleiter Signed-off-by: Sasha Levin commit 0171e01de47a4ccb2c64c668871a01c99d82d740 Author: Andrei Vagin Date: Tue May 26 20:50:43 2026 +0000 Revert "x86/fpu: Refine and simplify the magic number check during signal return" [ Upstream commit 44eeff9bc467bc7d1fec34fc3f6001f385fe462c ] This reverts dc8aa31a7ac2 ("x86/fpu: Refine and simplify the magic number check during signal return"). The aforementioned commit broke applications that construct signal frames in userspace (such as CRIU and gVisor) if the frame's xstate size is smaller than the kernel's fpstate->user_size. Furthermore, this introduces a critical issue for checkpoint/restore tools like CRIU. If a process is checkpointed while inside a signal handler, its stack contains a signal frame formatted according to the source host's xstate capabilities. If that process is later restored on a destination host with larger xstate capabilities (e.g., a newer CPU with more features enabled, resulting in a larger fpstate->user_size), the kernel will look for FP_XSTATE_MAGIC2 at the destination host's larger user_size offset instead of the offset encoded in the frame's fx_sw->xstate_size. This causes the magic2 check to fail, forcing sigreturn to silently fall back to "FX-only" mode. Upon return from the signal handler, the process's extended state is reset to initial values instead of being restored, leading to silent data corruption. The aforementioned commit cited d877550eaf2d ("x86/fpu: Stop relying on userspace for info to fault in xsave buffer") as justification to stop relying on userspace for the magic number check. However, these two changes are fundamentally different. The last one only changed how much memory the kernel ensures is paged-in before running XRSTOR to prevent an infinite loop. It did not change the signal frame format or how the layout is validated. Reverting this change restores the use of fx_sw->xstate_size for locating magic2 and restores the necessary sanity checks, ensuring that the signal frame remains self-describing and portable. [ bp: Massage commit message. ] Fixes: dc8aa31a7ac2 ("x86/fpu: Refine and simplify the magic number check during signal return") Signed-off-by: Andrei Vagin Signed-off-by: Borislav Petkov (AMD) Acked-by: Chang S. Bae Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20260429000623.3356606-1-avagin@google.com Signed-off-by: Sasha Levin commit ff0ca46b13b9ef6edbcd238a3b6caacfef8ba0e5 Author: Michael Bommarito Date: Sun Apr 19 20:11:31 2026 -0400 smb: client: validate the whole DACL before rewriting it in cifsacl [ Upstream commit 0a8cf165566ba55a39fd0f4de172119dd646d39a ] build_sec_desc() and id_mode_to_cifs_acl() derive a DACL pointer from a server-supplied dacloffset and then use the incoming ACL to rebuild the chmod/chown security descriptor. The original fix only checked that the struct smb_acl header fits before reading dacl_ptr->size or dacl_ptr->num_aces. That avoids the immediate header-field OOB read, but the rewrite helpers still walk ACEs based on pdacl->num_aces with no structural validation of the incoming DACL body. A malicious server can return a truncated DACL that still contains a header, claims one or more ACEs, and then drive replace_sids_and_copy_aces() or set_chmod_dacl() past the validated extent while they compare or copy attacker-controlled ACEs. Factor the DACL structural checks into validate_dacl(), extend them to validate each ACE against the DACL bounds, and use the shared validator before the chmod/chown rebuild paths. parse_dacl() reuses the same validator so the read-side parser and write-side rewrite paths agree on what constitutes a well-formed incoming DACL. Fixes: bc3e9dd9d104 ("cifs: Change SIDs in ACEs while transferring file ownership.") 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: Steve French Signed-off-by: Sasha Levin commit efacf63ed087050a4091298427bfb69e34082ef1 Author: Oliver Neukum Date: Fri Apr 10 23:03:09 2026 +0200 media: rc: ttusbir: fix inverted error logic [ Upstream commit 646ebdd3105809d84ed04aa9e92e47e89cc44502 ] We have to report ENOMEM if no buffer is allocated. Typo dropped a "!". Restore it. Fixes: 50acaad3d202 ("media: rc: ttusbir: respect DMA coherency rules") Cc: stable@vger.kernel.org Signed-off-by: Oliver Neukum Signed-off-by: Sean Young Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit e250b672d40a9e0d97a8895cbb301248bea0fce6 Author: Sean Young Date: Sat Dec 20 10:33:26 2025 +0000 media: rc: fix race between unregister and urb/irq callbacks [ Upstream commit dccc0c3ddf8f16071736f98a7d6dd46a2d43e037 ] Some rc device drivers have a race condition between rc_unregister_device() and irq or urb callbacks. This is because rc_unregister_device() does two things, it marks the device as unregistered so no new commands can be issued and then it calls rc_free_device(). This means the driver has no chance to cancel any pending urb callbacks or interrupts after the device has been marked as unregistered. Those callbacks may access struct rc_dev or its members (e.g. struct ir_raw_event_ctrl), which have been freed by rc_free_device(). This change removes the implicit call to rc_free_device() from rc_unregister_device(). This means that device drivers can call rc_unregister_device() in their remove or disconnect function, then cancel all the urbs and interrupts before explicitly calling rc_free_device(). Note this is an alternative fix for an issue found by Haotian Zhang, see the Closes: tags. Reported-by: Haotian Zhang Closes: https://lore.kernel.org/linux-media/20251114101432.2566-1-vulab@iscas.ac.cn/ Closes: https://lore.kernel.org/linux-media/20251114101418.2548-1-vulab@iscas.ac.cn/ Closes: https://lore.kernel.org/linux-media/20251114101346.2530-1-vulab@iscas.ac.cn/ Closes: https://lore.kernel.org/linux-media/20251114090605.2413-1-vulab@iscas.ac.cn/ Reviewed-by: Patrice Chotard Signed-off-by: Sean Young Signed-off-by: Hans Verkuil Stable-dep-of: 646ebdd31058 ("media: rc: ttusbir: fix inverted error logic") Signed-off-by: Sasha Levin commit 814be4a0924b6b3dab092670b566d6368c076cb9 Author: Pavel Begunkov Date: Thu May 28 19:43:53 2026 +0100 net: skbuff: fix pskb_carve leaking zcopy pages [ Upstream commit ff6e798c2eac3ebd0501ad7e796f583fab928de8 ] When SKBFL_MANAGED_FRAG_REFS is set, frag pages are not refcounted but their lifetime is controlled by the attached ubuf_info. To make a copy of the skb_shared_info, we either should clear the flag and reference the frags, or keep the flag and have frags unreferenced. pskb_carve_inside_header() and pskb_carve_inside_nonlinear() don't follow the rule and thus can leak page references. Let's clear SKBFL_MANAGED_FRAG_REFS from the original skb to fix it. It's the simplest way to address it, but there are more performant ways to do that if it ever becomes a problem. Link: https://lore.kernel.org/all/20260523085809.26331-1-nvminh232@clc.fitus.edu.vn/ Fixes: 753f1ca4e1e50 ("net: introduce managed frags infrastructure") Reported-by: Minh Nguyen Reported-by: Willem de Bruijn Signed-off-by: Pavel Begunkov Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/1e2086aa69217d7f9c8da3d38f5be7160f1b4cd1.1779993185.git.asml.silence@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ab9a10969a907b472a0196d999c08ff7144172e3 Author: Jiayuan Chen Date: Wed May 27 13:31:31 2026 +0800 ipv6: fix possible infinite loop in fib6_select_path() [ Upstream commit 9c7da87c2dc860bb17ca1ece942495d28b1ce3b9 ] Found while auditing the same pattern Sashiko reported in rt6_fill_node() [1]. Apply the same fix as commit f8d8ce1b515a ("ipv6: fix possible infinite loop in fib6_info_uses_dev()"). Writers holding tb6_lock can list_del_rcu(&first->fib6_siblings) without waiting for RCU readers; first->fib6_siblings.next then still points into the old ring and this softirq-side walker never reaches &first->fib6_siblings as its terminator. fib6_purge_rt() always WRITE_ONCE()s first->fib6_nsiblings to 0 before list_del_rcu(), so an inside-loop check is a reliable detach signal. [1] https://sashiko.dev/#/patchset/20260526020227.4857-1-jiayuan.chen%40linux.dev Fixes: d9ccb18f83ea ("ipv6: Fix soft lockups in fib6_select_path under high next hop churn") Signed-off-by: Jiayuan Chen Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260527053133.180695-2-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dc36a04621dcc2447dae428709207810b6c06e14 Author: Jiayuan Chen Date: Wed May 27 13:31:30 2026 +0800 ipv6: fix possible infinite loop in rt6_fill_node() [ Upstream commit 9f72412bcf60144f252b0d6205106abf14344abc ] Sashiko reported this issue [1]. Apply the same fix as commit f8d8ce1b515a ("ipv6: fix possible infinite loop in fib6_info_uses_dev()"). Writers holding tb6_lock can list_del_rcu(&rt->fib6_siblings) without waiting for RCU readers; rt->fib6_siblings.next then still points into the old ring and this softirq-side walker never reaches &rt->fib6_siblings, causing a CPU stall. fib6_del_route() always WRITE_ONCE()s rt->fib6_nsiblings to 0 before list_del_rcu(), so an inside-loop check is a reliable detach signal. [1] https://sashiko.dev/#/patchset/20260526020227.4857-1-jiayuan.chen%40linux.dev Fixes: d9ccb18f83ea ("ipv6: Fix soft lockups in fib6_select_path under high next hop churn") Signed-off-by: Jiayuan Chen Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260527053133.180695-1-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b62e2b2b4a50953ca952f3cd3f77dd62dc50fd5d Author: Jingguo Tan Date: Wed May 27 10:33:01 2026 +0800 vsock/virtio: bind uarg before filling zerocopy skb [ Upstream commit 1e584c304cfb94a759417130b1fc6d30b30c4cce ] virtio_transport_send_pkt_info() allocates or reuses the zerocopy uarg before entering the send loop, but virtio_transport_alloc_skb() still fills the skb before it inherits that uarg. When fixed-buffer vectored zerocopy hits MAX_SKB_FRAGS, io_sg_from_iter() may partially attach managed frags and return -EMSGSIZE. The rollback path call kfree_skb() to free an skb that carries SKBFL_MANAGED_FRAG_REFS but no uarg, so skb_release_data() falls through to ordinary frag unref. Pass the uarg into virtio_transport_alloc_skb() and bind it immediately before virtio_transport_fill_skb(). This keeps control or no-payload skbs untouched while ensuring success and rollback share one lifetime rule. Fixes: 581512a6dc93 ("vsock/virtio: MSG_ZEROCOPY flag support") Signed-off-by: Lin Ma Signed-off-by: Rongzhen Cui Signed-off-by: Jingguo Tan Acked-by: Arseniy Krasnov Acked-by: Michael S. Tsirkin Reviewed-by: Stefano Garzarella Link: https://patch.msgid.link/20260527023301.1075581-1-malin89@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 68667ee4c7dadf7f63167234e2a1af09b3f7874e Author: Zhenghang Xiao Date: Wed May 27 11:24:11 2026 +0800 sctp: fix race between sctp_wait_for_connect and peeloff [ Upstream commit f14fe6395a8b3d961a61e138ad7b36ba3626dd4e ] sctp_wait_for_connect() drops and re-acquires the socket lock while waiting for the association to reach ESTABLISHED state. During this window, another thread can peeloff the association to a new socket via getsockopt(SCTP_SOCKOPT_PEELOFF), changing asoc->base.sk. After re-acquiring the old socket lock, sctp_wait_for_connect() returns success without noticing the migration — the caller then accesses the association under the wrong lock in sctp_datamsg_from_user(). Add the same sk != asoc->base.sk check that sctp_wait_for_sndbuf() already has, returning an error if the association was migrated while we slept. Fixes: 668c9beb9020 ("sctp: implement assign_number for sctp_stream_interleave") Signed-off-by: Zhenghang Xiao Acked-by: Xin Long Link: https://patch.msgid.link/20260527032411.60959-1-kipreyyy@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c4152b4e28b3e550ec99351bf900e2c24c2608cc Author: Dipayaan Roy Date: Mon May 25 01:08:25 2026 -0700 net: mana: Skip redundant detach on already-detached port [ Upstream commit 5b05aa36ee24297d7296ca58dfd8c448d0e4cda3 ] When mana_per_port_queue_reset_work_handler() runs after a previous detach succeeded but attach failed, the port is left in a detached state with apc->tx_qp and apc->rxqs already freed. Calling mana_detach() again unconditionally leads to NULL pointer dereferences during queue teardown. Add an early exit in mana_detach() when the port is already in detached state (!netif_device_present) for non-close callers, making it safe to call idempotently. This allows the queue reset handler and other recovery paths to simply retry mana_attach() without redundant teardown. Fixes: 3b194343c250 ("net: mana: Implement ndo_tx_timeout and serialize queue resets per port.") Reviewed-by: Haiyang Zhang Signed-off-by: Dipayaan Roy Link: https://patch.msgid.link/20260525081129.1230035-3-dipayanroy@linux.microsoft.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit da87896f34e0a51489811d1a684e2953099ca98f Author: Dipayaan Roy Date: Mon May 25 01:08:24 2026 -0700 net: mana: Add NULL guards in teardown path to prevent panic on attach failure [ Upstream commit 17bfe0a8c014ee1d542ad352cd6a0a505361664a ] When queue allocation fails partway through, the error cleanup frees and NULLs apc->tx_qp and apc->rxqs. Multiple teardown paths such as mana_remove(), mana_change_mtu() recovery, and internal error handling in mana_alloc_queues() can subsequently call into functions that dereference these pointers without NULL checks: - mana_chn_setxdp() dereferences apc->rxqs[0], causing a NULL pointer dereference panic (CR2: 0000000000000000 at mana_chn_setxdp+0x26). - mana_destroy_vport() iterates apc->rxqs without a NULL check. - mana_fence_rqs() iterates apc->rxqs without a NULL check. - mana_dealloc_queues() iterates apc->tx_qp without a NULL check. Add NULL guards for apc->rxqs in mana_fence_rqs(), mana_destroy_vport(), and before the mana_chn_setxdp() call. Add a NULL guard for apc->tx_qp in mana_dealloc_queues() to skip TX queue draining when TX queues were never allocated or already freed. Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Reviewed-by: Haiyang Zhang Signed-off-by: Dipayaan Roy Link: https://patch.msgid.link/20260525081129.1230035-2-dipayanroy@linux.microsoft.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7f945f7f10f442270518dfd768d230227c495fcf Author: Marco Scardovi Date: Tue May 26 19:02:46 2026 +0200 gpio: rockchip: teardown bugs and resource leaks [ Upstream commit 9500077678230e36d22bf16d2b9539c13e59a801 ] Address several teardown issues and resource leaks in the driver's remove path and error handling: 1. Debounce clock reference leak: The debounce clock (bank->db_clk) is obtained using of_clk_get() which increments the clock's reference count, but clk_put() is never called. Register a devm action to cleanly release it on unbind. Note that of_clk_get(..., 1) remains necessary over devm_clk_get() because the DT binding does not define clock-names, precluding name-based lookup. 2. Unregistered chained IRQ handler: The chained IRQ handler is not disconnected in remove(). If a stray interrupt fires after the driver is removed, the kernel attempts to execute a stale handler, leading to a panic. Fix this by clearing the handler in remove(). 3. IRQ domain leak: The linear IRQ domain and its generic chips are allocated manually during probe but never removed. Remove the IRQ domain during driver teardown to free the associated generic chips and mappings. Fixes: 936ee2675eee ("gpio/rockchip: add driver for rockchip gpio") Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Marco Scardovi Link: https://patch.msgid.link/20260526171050.12785-3-scardracs@disroot.org [Bartosz: don't emit an error message on devres allocation failure] Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit e2fabb984bfdc66b9e514fbcd6dcfc6d7d5187d6 Author: Marco Scardovi Date: Tue May 26 19:02:45 2026 +0200 gpio: rockchip: convert bank->clk to devm_clk_get_enabled() [ Upstream commit 3e46c18d5d87f063a93ae0fe7662fbf6660459d5 ] The bank->clk was previously obtained via of_clk_get() and manually prepared/enabled. However, it was missing a corresponding clk_put() in both the error paths and the remove function, leading to a reference leak. Convert the allocation to devm_clk_get_enabled(), which also properly propagates failures from clk_prepare_enable() that were previously ignored. The GPIO bank device uses the same OF node as the previous of_clk_get() call, so devm_clk_get_enabled(dev, NULL) correctly resolves the same clock provider entry. Fix the reference leak and simplify the code by removing the manual clk_disable_unprepare() calls in the probe error paths and in the remove function. Fixes: 936ee2675eee ("gpio/rockchip: add driver for rockchip gpio") Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Marco Scardovi Link: https://patch.msgid.link/20260526171050.12785-2-scardracs@disroot.org Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 5d43c71fa8e1b5f940730c11a141839d89e696ec Author: Dan Carpenter Date: Mon May 25 10:15:16 2026 +0300 gpio: virtuser: Fix uninitialized data bug in gpio_virtuser_direction_do_write() [ Upstream commit 8a122b5e72cc0043705f0d524bcd15f0c0b3ec15 ] If *ppos is non-zero (user-space write split over multiple calls to write()) then simple_write_to_buffer() won't initialize the start of the buffer. Really, non-zero values for *ppos aren't going to work at all. Check for that and return -EINVAL at the start of the function. Fixes: 91581c4b3f29 ("gpio: virtuser: new virtual testing driver for the GPIO API") Signed-off-by: Dan Carpenter Link: https://patch.msgid.link/ahP3BJWWy-m_qI0X@stanley.mountain Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit b6cdbb681ce13b449b3c35d0082daacf099270cc Author: Bartosz Golaszewski Date: Fri May 22 09:35:27 2026 +0200 gpio: adnp: fix flow control regression caused by scoped_guard() [ Upstream commit a5c627d90809b793fc053849b3a00609db305776 ] scoped_guard() is implemented as a for loop. Using it to protect code using the continue statement changes the flow as we now only break out of the hidden loop inside scoped_guard(), not the original for loop. Use a regular code block instead. Fixes: c7fe19ed3973 ("gpio: adnp: use lock guards for the I2C lock") Reported-by: David Lechner Closes: https://lore.kernel.org/all/cde2abb2-4cc8-4fc9-b34a-0c5d2b95779f@baylibre.com/ Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260522073527.9812-1-bartosz.golaszewski@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit ae2eac5e9cfeec8631d7a08594a25176c68ce0f3 Author: Heitor Alves de Siqueira Date: Tue May 26 10:50:59 2026 -0300 Bluetooth: hci_sync: Reset device counters in hci_dev_close_sync() [ Upstream commit cdf88b35e06f1b385f7f6228060ae541d44fbb72 ] Before resetting or closing the device, protocol counters should also be zeroed. Fixes: d0b137062b2d ("Bluetooth: hci_sync: Rework init stages") Signed-off-by: Heitor Alves de Siqueira Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 47330cc875b36a1cf7b3543cb2cf90a7c603ce0e Author: Heitor Alves de Siqueira Date: Tue May 26 10:50:58 2026 -0300 Bluetooth: hci_sync: Set HCI_CMD_DRAIN_WORKQUEUE during device close [ Upstream commit 525daaea459fc215f432de1b8debbd9144bf97b0 ] Since hci_dev_close_sync() can now be called during the reset path, we should also set HCI_CMD_DRAIN_WORKQUEUE. This avoids queuing timeouts while the hdev workqueue is being drained. Fixes: 877afadad2dc ("Bluetooth: When HCI work queue is drained, only queue chained work") Signed-off-by: Heitor Alves de Siqueira Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 41e29548b5e8b5e5fcf708786b3bea67cab107fa Author: Luiz Augusto von Dentz Date: Mon May 11 12:09:42 2026 -0400 Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp [ Upstream commit 41c2713b204e6cb6a94587bc6bf6935107df5479 ] If dcid is received for an already-assigned destination CID the spec requires that both channels to be discarded, but calling l2cap_chan_del may invalidate the tmp cursor created by list_for_each_entry_safe and in fact it is the wrong procedure as the chan->dcid may be assigned previously it really needs to be disconnected. Calling l2cap_chan_clone directly may still lead to l2cap_chan_del so instead schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously. Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit f39049304ba655ffcbb92edbdf8c51a1f1210bed Author: Zhenghang Xiao Date: Tue May 26 18:51:52 2026 +0800 Bluetooth: l2cap: clear chan->ident on ECRED reconfiguration success [ Upstream commit 00e1950716c6ed67d74777b2db286b0fa23b4be9 ] l2cap_ecred_reconf_rsp() returns early on success without clearing chan->ident. Every other L2CAP response handler (l2cap_ecred_conn_rsp, l2cap_le_connect_rsp, l2cap_config_rsp) clears chan->ident after a successful transaction to prevent the channel from matching subsequent responses with the recycled ident value. A remote attacker that completed a reconfiguration as the peer can replay a failure response with the stale ident, causing the kernel to match and destroy the already-established channel via l2cap_chan_del(chan, ECONNRESET). Clear chan->ident for all matching channels on success, and harden the failure path by using l2cap_chan_hold_unless_zero() consistent with other L2CAP handlers (l2cap_le_command_rej, __l2cap_get_chan_by_ident). Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode") Signed-off-by: Zhenghang Xiao Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 1d4dcfe60fe111823b2339c84d7455e9e89fbfc5 Author: Chuck Lever Date: Mon May 25 12:51:17 2026 -0400 net/handshake: Pass negative errno through handshake_complete() [ Upstream commit 6b22d433aa13f68e3cd9534ca9a5f4277bfa01c2 ] handshake_complete() declares status as unsigned int and tls_handshake_done() negates that value (-status) before handing it to the TLS consumer. Consumers match on negative errno constants -- xs_tls_handshake_done() has switch (status) { case 0: case -EACCES: case -ETIMEDOUT: lower_transport->xprt_err = status; break; default: lower_transport->xprt_err = -EACCES; } so the API as designed expects callers to pass positive errno values that the tlshd shim then negates. Three internal callers in handshake_nl_accept_doit(), the net-exit drain, and a kunit test follow kernel convention and pass negative errnos -- -EIO, -ETIMEDOUT, -ETIMEDOUT. The implicit conversion to unsigned int turns -ETIMEDOUT into 0xFFFFFF92; the subsequent -status in tls_handshake_done() wraps back to 110, the consumer's switch falls through, and the xprt reports -EACCES on what should be -ETIMEDOUT or -EIO. Fix the API rather than the call sites. The natural kernel convention is negative errno in, negative errno out. Change handshake_complete() and hp_done to take int status, drop the negation in tls_handshake_done(), and negate once in handshake_nl_done_doit() where status arrives from the wire as an unsigned netlink attribute. The three internal callers were already correct under that convention and need no change. At the same wire boundary, declare MAX_ERRNO as the netlink policy upper bound for HANDSHAKE_A_DONE_STATUS. Attribute validation rejects out-of-range values before handshake_nl_done_doit() runs, and negating a bounded u32 there stays within int range -- closing the UBSAN-visible signed- integer overflow that an unconstrained u32 would invoke. Fixes: 3b3009ea8abb ("net/handshake: Create a NETLINK service for handling handshake requests") Signed-off-by: Chuck Lever Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260525-handshake-file-pin-v3-3-66c616906ead@oracle.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 25b2fcdea6f6277ecd3d7adc082197e61424d179 Author: Chuck Lever Date: Mon May 25 12:51:16 2026 -0400 nvme-tcp: store negative errno in queue->tls_err [ Upstream commit 9015985b5eb1a90eb86caf5bce1dfcf1aa38f8ad ] nvme_tcp_tls_done() assigns queue->tls_err in three branches. The ENOKEY lookup failure and the EOPNOTSUPP initializer both store negative errnos. The third branch, reached when the handshake layer reports a non-zero status, stores -status. The handshake layer delivers status to the consumer callback as a negative errno; the other in-tree consumers -- xs_tls_handshake_done() and the nvmet target callback -- treat their status argument that way. The extra negation in nvme_tcp_tls_done() flips the sign, leaving tls_err as a positive value (for instance, +EIO), which nvme_tcp_start_tls() then returns to its caller. Drop the extra negation so queue->tls_err uniformly carries a negative errno on failure. Fixes: be8e82caa685 ("nvme-tcp: enable TLS handshake upcall") Signed-off-by: Chuck Lever Reviewed-by: Hannes Reinecke Reviewed-by: Alistair Francis Link: https://patch.msgid.link/20260525-handshake-file-pin-v3-2-66c616906ead@oracle.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 0866569fc36a56f568acd3900d354e3505932e09 Author: Chuck Lever Date: Mon May 25 12:51:15 2026 -0400 net/handshake: Use spin_lock_bh for hn_lock [ Upstream commit cc993e0927ec8bd98ea33377ada03295fcda0f24 ] nvmet_tcp_state_change(), a socket callback that runs in BH context, can reach handshake_req_cancel() via nvmet_tcp_schedule_release_queue() and tls_handshake_cancel(). handshake_req_cancel() acquires hn->hn_lock with plain spin_lock(). If a process-context thread on the same CPU holds hn->hn_lock when a softirq invokes the cancel path, the lock attempt deadlocks. This is the only caller that invokes tls_handshake_cancel() from BH context; every other consumer calls it from process context. Deferring the cancel to process context in the NVMe target is not straightforward: nvmet_tcp_schedule_release_queue() must call tls_handshake_cancel() atomically with its state transition to DISCONNECTING. If the cancel were deferred, the handshake completion callback could fire in the window before the cancel runs, observe the unexpected state, and return without dropping its kref on the queue. Reworking that interlock is considerably more invasive than hardening the handshake lock. Convert all hn->hn_lock acquisitions from spin_lock/spin_unlock to spin_lock_bh/spin_unlock_bh so the lock is never taken with softirqs enabled. Fixes: 675b453e0241 ("nvmet-tcp: enable TLS handshake upcall") Signed-off-by: Chuck Lever Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260525-handshake-file-pin-v3-1-66c616906ead@oracle.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c35064294eca3dce2432eb5069b123f522a8b877 Author: Jijie Shao Date: Mon May 25 22:45:24 2026 +0800 net: hibmcge: disable Relaxed Ordering to fix RX packet corruption [ Upstream commit 463a1271aa26eac992851b9d98cc75bc3cd4a1ed ] When SMMU is disabled, the hibmcge driver may receive corrupted packets. The hardware writes packet data and descriptors to the same page, but with Relaxed Ordering enabled, PCI write transactions may not be strictly ordered. This can cause the driver to observe a valid descriptor before the corresponding packet data is fully written. Fix this by clearing PCI_EXP_DEVCTL_RELAX_EN in the PCI bridge control register to ensure strict write ordering between packet data and descriptors. Fixes: f72e25594061 ("net: hibmcge: Implement rx_poll function to receive packets") Signed-off-by: Jijie Shao Link: https://patch.msgid.link/20260525144525.94884-2-shaojijie@huawei.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 7f97b8352ce55c87bc4227d5a16ef0f997e27329 Author: Jamal Hadi Salim Date: Mon May 25 08:25:49 2026 -0400 net/sched: Revert "net/sched: Restrict conditions for adding duplicating netems to qdisc tree" [ Upstream commit eda0b7f203bb166c98d1418b204135bd566ac83b ] This reverts commit ec8e0e3d7adef940cdf9475e2352c0680189d14e. The original patch rejects any tree containing two netems when either has duplication set, even when they sit on unrelated classes of the same classful parent. That broke configurations that have worked since netem was introduced. The re-entrancy problem the original commit was trying to solve is handled by later patch using tc_depth flag. Doing this revert will (re)expose the original bug with multiple netem duplication. When this patch is backported make sure and get the full series. Fixes: ec8e0e3d7ade ("net/sched: Restrict conditions for adding duplicating netems to qdisc tree") Reported-by: Ji-Soo Chung Reported-by: Gerlinde Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220774 Reported-by: zyc zyc Closes: https://lore.kernel.org/all/19adda5a1e2.12410b78222774.9191120410578703463@zohomail.cn/ Reported-by: Manas Ghandat Closes: https://lore.kernel.org/netdev/f69b2c8f-8325-4c2e-a011-6dbc089f30e4@gmail.com/ Reviewed-by: Stephen Hemminger Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260525122556.973584-3-jhs@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 6fe1cb312038516cb4d9fa089d700af7059f1a64 Author: Rahul Chandelkar Date: Mon May 25 21:10:31 2026 +0530 ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() [ Upstream commit 9d5e7a46a9f6d8f503b41bfefef70659845f1679 ] ipv6_rpl_srh_decompress() computes: outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3); hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16): (128 * 16) >> 3 = 256, truncated to 0 as __u8 The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet. The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit. Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment. Fixes: 8610c7c6e3bd ("net: ipv6: add support for rpl sr exthdr") Signed-off-by: Rahul Chandelkar Link: https://patch.msgid.link/20260525154031.2290876-1-rc@rexion.ai Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fd0de51c54fa8474a0ddeedd71c65ad09fada390 Author: Jakub Kicinski Date: Tue May 26 08:35:33 2026 -0700 ethtool: eeprom: add more safeties to EEPROM Netlink fallback [ Upstream commit 67cfdd9210b99f260b3e0afeb9525e0acc7be31e ] The Netlink fallback path for reading module EEPROM (fallback_set_params()) validates that offset < eeprom_len, but does not check that offset + length stays within eeprom_len. The ioctl equivalent (ethtool_get_any_eeprom() in ioctl.c) has always enforced both bounds: if (eeprom.offset + eeprom.len > total_len) return -EINVAL; This could lead to surprises in both drivers and device FW. Add the missing offset + length validation to fallback_set_params(), mirroring the ioctl. Similarly - ethtool core in general, and ethtool_get_any_eeprom() in particular tries to zero-init all buffers passed to the drivers to avoid any extra work of zeroing things out. eeprom_fallback() uses a plain kmalloc(), change it to zalloc. Fixes: 96d971e307cc ("ethtool: Add fallback to get_module_eeprom from netlink command") Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260526153533.2779187-11-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c944cab3df82567a9560fefc87728782d2ccf69e Author: Jakub Kicinski Date: Tue May 26 08:35:32 2026 -0700 ethtool: eeprom: add missing ethnl_ops_begin() / _complete() during fallback [ Upstream commit 2376586f85f972fefe701f095bb37dcfe7405d21 ] All ethtool driver op calls should be sandwiched between ethnl_ops_begin() / ethnl_ops_complete(). In Netlink eeprom code, if the paged access failed we fall back to old API, but we first call _complete() and the fallback never does its own ethnl_ops_begin(). Move the fallback into the _begin() / _complete() section. Fixes: 96d971e307cc ("ethtool: Add fallback to get_module_eeprom from netlink command") Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260526153533.2779187-10-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3e656023a64965ccbad417131e82b4e2ba3ad070 Author: Jakub Kicinski Date: Tue May 26 08:35:31 2026 -0700 ethtool: strset: fix header attribute index in ethnl_req_get_phydev() [ Upstream commit a8d8bef6b45bf7cc0b1f6110c5cd8d0160a9bad7 ] strset_prepare_data() passes ETHTOOL_A_HEADER_FLAGS (3) as the header attribute to ethnl_req_get_phydev(). This is incorrect, in the main attr space 3 is ETHTOOL_A_STRSET_COUNTS_ONLY, not the request header attr. The correct constant is ETHTOOL_A_STRSET_HEADER (1). ethnl_req_get_phydev() only uses this value for the extack, so this is not a "functionally visible"(?) bug. Fixes: e96c93aa4be9 ("net: ethtool: strset: Allow querying phy stats by index") Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260526153533.2779187-9-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2008f9bb1ede9b688624a241228b8e54fc74f0f6 Author: Jakub Kicinski Date: Tue May 26 08:35:30 2026 -0700 ethtool: tsinfo: don't pass ERR_PTR to genlmsg_cancel on prepare failure [ Upstream commit c3fc9976f686f9a95baf87db9d387f218fd65394 ] The goto err label leads to: genlmsg_cancel(skb, ehdr); return ret; If ethnl_tsinfo_prepare_dump() failed, it has not started a genlmsg. There's nothing to cancel, and passing an error pointer to genlmsg_cancel() would cause a crash. Fixes: b9e3f7dc9ed9 ("net: ethtool: tsinfo: Enhance tsinfo to support several hwtstamp by net topology") Reviewed-by: Maxime Chevallier Reviewed-by: Kory Maincent Link: https://patch.msgid.link/20260526153533.2779187-8-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ab94e0d6664ddd3e227cc23049b6e52148cb67d8 Author: Jakub Kicinski Date: Tue May 26 08:35:29 2026 -0700 ethtool: tsinfo: fix uninitialized stats on the by-PHC path [ Upstream commit 1de405699c62c3a9544bcdcfb9eff8a01cfc7582 ] tsinfo_prepare_data() has two code paths: a "by-PHC" path for user-specified hardware timestamping providers, and the old path. Commit 89e281ebff72 ("ethtool: init tsinfo stats if requested") added ethtool_stats_init() to mark stat slots as ETHTOOL_STAT_NOT_SET before the driver callback populates them, but placed the call inside the old-path block. When commit b9e3f7dc9ed9 ("net: ethtool: tsinfo: Enhance tsinfo to support several hwtstamp by net topology") added the by-PHC early return, it landed above the stats initialization. On that path the stats array retains the zero-fill from ethnl_init_reply_data()'s zalloc. This leads to the reply including a stats nest with four zero-valued attributes that should have been absent. Reject GET requests for stats with HWTSTAMP_PROVIDER or dump. Fixes: b9e3f7dc9ed9 ("net: ethtool: tsinfo: Enhance tsinfo to support several hwtstamp by net topology") Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260526153533.2779187-7-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d02342d9bb4f0ab682f1846a4fbc15dd2955f7e6 Author: Jakub Kicinski Date: Tue May 26 08:35:28 2026 -0700 ethtool: tsconfig: fix missing ethnl_ops_complete() [ Upstream commit 6386bd772de64e6760306eb91c7e86163af6c22f ] tsconfig_prepare_data() calls ethnl_ops_begin(), we need to call ethnl_ops_complete() before returning the error. Fixes: 6e9e2eed4f39 ("net: ethtool: Add support for tsconfig command to get/set hwtstamp config") Reviewed-by: Vadim Fedorenko Reviewed-by: Kory Maincent Link: https://patch.msgid.link/20260526153533.2779187-6-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 912f8b23bc4b6c76e4378999e490fc360ba8fcf4 Author: Jakub Kicinski Date: Tue May 26 08:35:27 2026 -0700 ethtool: pse-pd: fix missing ethnl_ops_complete() [ Upstream commit ab5bf428fb6bd361163c7247b92750d1d24ca2ed ] pse_prepare_data() is missing ethnl_ops_complete() if ethnl_req_get_phydev() returned an error. Move getting phydev up so that we don't have to worry about this (similar order to linkstate_prepare_data()). Note that phydev may still be NULL (this is checked in pse_get_pse_attributes()), the goal isn't really to avoid the _begin() / _complete() calls, only to simplify the error handling. While at it propagate the original error. Why this code overrides the error with -ENODEV but !phydev generates -EOPNOTSUPP is unclear to me... Fixes: 31748765bed3 ("net: ethtool: pse-pd: Target the command to the requested PHY") Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260526153533.2779187-5-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 49455e27838aa0da04ab18ac529ec9d9edb460cd Author: Jakub Kicinski Date: Tue May 26 08:35:26 2026 -0700 ethtool: linkstate: fix unbalanced ethnl_ops_complete() on PHY lookup error [ Upstream commit 596c51ed9e125b12c4d85b4530dfd4c7847634b7 ] linkstate_prepare_data() calls ethnl_req_get_phydev() before ethnl_ops_begin(), but routes its error path through "goto out" which calls ethnl_ops_complete(). Fixes: fe55b1d401c6 ("ethtool: linkstate: migrate linkstate functions to support multi-PHY setups") Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260526153533.2779187-4-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d11c98484485bead8de86d315052752a343f22d0 Author: Jakub Kicinski Date: Tue May 26 08:35:25 2026 -0700 ethtool: tsconfig: fix reply error handling [ Upstream commit a888bbd43940cada72f7686337741ce86d1cf869 ] A couple of trivial bugs in error handling in tsconfig_send_reply(). If we failed to allocate rskb we need to set the error. If we did allocate it but failed to send it - we need to remember to free it. Fixes: 6e9e2eed4f39 ("net: ethtool: Add support for tsconfig command to get/set hwtstamp config") Reviewed-by: Vadim Fedorenko Reviewed-by: Kory Maincent Link: https://patch.msgid.link/20260526153533.2779187-3-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0c02c190bcd9822477038ff2cee10ea584ac1b1d Author: Jakub Kicinski Date: Tue May 26 08:35:24 2026 -0700 ethtool: coalesce: cap profile updates at NET_DIM_PARAMS_NUM_PROFILES [ Upstream commit 7281b096b072f6c6e30420e3467d738f2e4c4b57 ] ethnl_update_profile() walks the ETHTOOL_A_PROFILE_IRQ_MODERATION nest list with an index 'i' and writes new_profile[i++] without bounding i. The destination is kmemdup()'d at NET_DIM_PARAMS_NUM_PROFILES entries (5), but the Netlink nest count is entirely user-controlled. Netlink policies do not have support for constraining the number of nested entries (or number of multi-attr entries). Fixes: f750dfe825b9 ("ethtool: provide customized dim profile management") Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260526153533.2779187-2-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e976e3f2f2005c6267089a1a3b6344f234a59a55 Author: Ido Schimmel Date: Tue May 26 09:48:17 2026 +0300 bridge: Fix sleep in atomic context in sysfs path [ Upstream commit 6d34594cc619d0d4b07d5afcad8b5984f3526dcf ] Since the start of the git history, brport_store() always acquired the bridge lock. Back then this decision made sense: The bridge lock protects the STP state of the bridge and its ports and at that time the function was only used by two STP related attributes (cost and priority). Nowadays, brport_store() processes a lot more attributes and most of them do not need the bridge lock: * Bridge flags: Only require RTNL. Read locklessly by the data path. Annotations can be added in net-next. * FDB port flushing: Only requires the FDB lock. * Multicast attributes: Only require the multicast lock. * Group forward mask: Only requires RTNL. Read locklessly by the data path. Annotations can be added in net-next. * Backup port: Only requires RTNL. Read locklessly by the data path. This is a problem as the bridge calls dev_set_promiscuity() when certain bridge port flags change and this function can sleep since the commit cited below, resulting in a splat such as [1]. Fix this by reducing the scope of the bridge lock and only take it when processing the two STP related attributes that require it. Remove the now stale comment from br_switchdev_set_port_flag(). The SWITCHDEV_F_DEFER flag can be removed in net-next. [1] BUG: sleeping function called from invalid context at net/core/dev_addr_lists.c:1262 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 372, name: bash preempt_count: 201, expected: 0 RCU nest depth: 0, expected: 0 5 locks held by bash/372: #0: ffff88810c51c3f0 (sb_writers#7){.+.+}-{0:0}, at: ksys_write (fs/read_write.c:740) #1: ffff888115ce9480 (&of->mutex){+.+.}-{4:4}, at: kernfs_fop_write_iter (fs/kernfs/file.c:343) #2: ffff88810b9fd330 (kn->active#37){.+.+}-{0:0}, at: kernfs_fop_write_iter (fs/kernfs/file.c:80 fs/kernfs/file.c:344) #3: ffffffffa59473a0 (rtnl_mutex){+.+.}-{4:4}, at: brport_store (net/bridge/br_sysfs_if.c:326) #4: ffff8881099d2d58 (&br->lock){+...}-{3:3}, at: brport_store (./include/linux/spinlock.h:348 net/bridge/br_sysfs_if.c:345) Preemption disabled at: 0x0 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) __might_resched.cold (kernel/sched/core.c:9163) netif_rx_mode_run (net/core/dev_addr_lists.c:1262) netif_rx_mode_sync (net/core/dev_addr_lists.c:1428) dev_set_promiscuity (net/core/dev_api.c:289) br_manage_promisc (net/bridge/br_if.c:135 net/bridge/br_if.c:172) br_port_flags_change (net/bridge/br_if.c:242 net/bridge/br_if.c:747) store_learning (net/bridge/br_sysfs_if.c:79 net/bridge/br_sysfs_if.c:235) brport_store (net/bridge/br_sysfs_if.c:346) kernfs_fop_write_iter (fs/kernfs/file.c:352) new_sync_write (fs/read_write.c:595) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Fixes: 78cd408356fe ("net: add missing instance lock to dev_set_promiscuity") Reviewed-by: Nikolay Aleksandrov Signed-off-by: Ido Schimmel Link: https://patch.msgid.link/20260526064818.272516-3-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c9c2e609e8397bb57b4d73675f33a99183c4a0bd Author: Ido Schimmel Date: Tue May 26 09:48:16 2026 +0300 bridge: Fix sleep in atomic context in netlink path [ Upstream commit 5eec4427b89c2fb2beac54920101e55a2f1c0c21 ] Since the introduction of the netlink configuration path for bridge ports in commit 25c71c75ac87 ("bridge: bridge port parameters over netlink"), br_setport() was always called with the bridge lock held around it. Back then this decision made sense: The bridge lock protects the STP state of the bridge and its ports and at that time the function only processed three STP related netlink attributes (cost, priority and state). Nowadays, br_setport() processes a lot more attributes and most of them do not need the bridge lock: * Bridge flags: Only require RTNL. Read locklessly by the data path. Annotations can be added in net-next. * FDB port flushing: Only requires the FDB lock. * Multicast attributes: Only require the multicast lock. * Group forward mask: Only requires RTNL. Read locklessly by the data path. Annotations can be added in net-next. * Backup port and NHID: Only require RTNL. Read locklessly by the data path. This is a problem as the bridge calls dev_set_promiscuity() when certain bridge port flags change and this function can sleep since the commit cited below, resulting in a splat such as [1]. Fix this by reducing the scope of the bridge lock and only take it when processing the three STP related attributes that require it. This is consistent with the multicast attributes where each attribute acquires the multicast lock instead of having one critical section for all relevant attributes. [1] BUG: sleeping function called from invalid context at net/core/dev_addr_lists.c:1262 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 356, name: bridge preempt_count: 201, expected: 0 RCU nest depth: 0, expected: 0 2 locks held by bridge/356: #0: ffffffff919473a0 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg (net/core/rtnetlink.c:80 net/core/rtnetlink.c:7002) #1: ffff888115072d58 (&br->lock){+...}-{3:3}, at: br_setlink (./include/linux/spinlock.h:348 net/bridge/br_netlink.c:1117) Preemption disabled at: 0x0 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) __might_resched.cold (kernel/sched/core.c:9163) netif_rx_mode_run (net/core/dev_addr_lists.c:1262) netif_rx_mode_sync (net/core/dev_addr_lists.c:1428) dev_set_promiscuity (net/core/dev_api.c:289) br_manage_promisc (net/bridge/br_if.c:135 net/bridge/br_if.c:172) br_port_flags_change (net/bridge/br_if.c:242 net/bridge/br_if.c:747) br_setport (net/bridge/br_netlink.c:1000) br_setlink (net/bridge/br_netlink.c:1118) rtnl_bridge_setlink (net/core/rtnetlink.c:5572) rtnetlink_rcv_msg (net/core/rtnetlink.c:7005) netlink_rcv_skb (net/netlink/af_netlink.c:2550) netlink_unicast (net/netlink/af_netlink.c:1318 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sock_sendmsg (net/socket.c:787 (discriminator 4) net/socket.c:802 (discriminator 4)) ____sys_sendmsg (net/socket.c:2698) ___sys_sendmsg (net/socket.c:2752) __sys_sendmsg (net/socket.c:2784) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Fixes: 78cd408356fe ("net: add missing instance lock to dev_set_promiscuity") Reviewed-by: Nikolay Aleksandrov Signed-off-by: Ido Schimmel Link: https://patch.msgid.link/20260526064818.272516-2-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9ea8a648d9120f7652bcde1ce2c4ad66871af707 Author: Oliver Hartkopp Date: Tue May 26 21:33:19 2026 +0200 bonding: refuse to enslave CAN devices [ Upstream commit 8ba68464e4787b6a7ec938826e16124df20fd23d ] syzbot reported a kernel paging request crash in can_rx_unregister() inside net/can/af_can.c. The crash occurs because a virtual CAN device (vxcan) is being enslaved to a bonding master. During the enslavement process, the bonding driver mutates and modifies the network device states to fit an Ethernet-like aggregation model. However, CAN devices operate on a completely different Layer 2 architecture, relying on the CAN mid-layer private data structure (can_ml_priv) instead of standard Ethernet structures. Since bonding does not initialize or maintain these CAN structures, subsequent operations on the half-enslaved interface (such as closing associated sockets via isotp_release) lead to a null-pointer dereference when accessing the CAN receiver lists. Bonding CAN interfaces is architecturally invalid as CAN lacks MAC addresses, ARP capabilities, and standard Ethernet link-layer mechanisms. While generic loopback devices are blocked globally in net/core/dev.c, virtual CAN devices bypass this check because they do not carry the IFF_LOOPBACK flag, despite acting as local software-loopbacks. Fix this by explicitly blocking network devices of type ARPHRD_CAN from being enslaved at the very beginning of bond_enslave(). This prevents illegal state mutations, eliminates the resulting KASAN crashes, and avoids potential memory leaks from incomplete socket cleanups. As the CAN support has been added a long time after bonding the Fixes-tag points to the introduction of ARPHRD_CAN that would have needed a specific handling in bonding_main.c. Fixes: cd05acfe65ed ("[CAN]: Allocate protocol numbers for PF_CAN") Reported-by: syzbot+8ed98cbd0161632bce95@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=8ed98cbd0161632bce95 Signed-off-by: Oliver Hartkopp Acked-by: Jay Vosburgh Link: https://patch.msgid.link/20260526-bonding-candev-v1-1-ba1df400918a@hartkopp.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e673889a35a5e4c586d0fae67d8755ca4367d3e2 Author: Zhao Dongdong Date: Tue May 26 11:21:39 2026 +0800 Bluetooth: 6lowpan: check skb_clone() return value in send_mcast_pkt() [ Upstream commit 3c40d381ce04f9575a5d8b542898183c3b4b38dc ] The skb_clone() function can return NULL if memory allocation fails. send_mcast_pkt() calls skb_clone() without checking the return value, which can lead to a NULL pointer dereference in send_pkt() when it dereferences skb->data. Add a NULL check after skb_clone() and skip the peer if the clone fails. Fixes: 18722c247023 ("Bluetooth: Enable 6LoWPAN support for BT LE devices") Signed-off-by: Zhao Dongdong Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 75cf24709037c671c62c49cd12285893bd679eb2 Author: Balasubramani Vivekanandan Date: Fri May 22 22:05:32 2026 +0530 drm/xe: Restore IDLEDLY regiter on engine reset [ Upstream commit f657a6a3ba4c20bc01f5be3752d53498ee1bfe35 ] Wa_16023105232 programs the register IDLEDLY. The register is reset whenever the engine is reset. Therefore it should be added to the GuC save-restore register list for it to be restored after reset. Fixes: 7c53ff050ba8 ("drm/xe: Apply Wa_16023105232") Reviewed-by: Matt Roper Link: https://patch.msgid.link/20260522163531.1365540-2-balasubramani.vivekanandan@intel.com Signed-off-by: Balasubramani Vivekanandan (cherry picked from commit df1cfe24743a93b71eab27687e148ab8ae9b69e3) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 164dcbec9632ca93ae313e6da6e4e05584fa0f02 Author: Cássio Gabriel Date: Wed May 27 09:24:00 2026 -0300 ASoC: codecs: simple-mux: Fix enum control bounds check [ Upstream commit f63ad68e18d774a5d15cd7e405ead63f6b322679 ] simple_mux_control_put() rejects values greater than e->items, but enum control values are zero based. For the two-entry mux used by this driver, valid values are 0 and 1, so value 2 must be rejected as well. Accepting e->items can store an invalid mux state, pass it to the GPIO setter, and pass it on to the DAPM mux update path where it is used as an index into the enum text array. Use the same >= e->items check used by the ASoC enum helpers. Fixes: 342fbb7578d1 ("ASoC: add simple-mux") Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260527-asoc-simple-mux-enum-bounds-v1-1-3f805b9fc671@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit de9eb0b44fa9123170e6245b49638e0e453c10f8 Author: Sean Shen Date: Tue May 26 22:07:16 2026 +0900 ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE [ Upstream commit cc57232cae23c0df91b4a59d0f519141ce9b5b02 ] FSCTL_SET_SPARSE in fsctl_set_sparse() modifies the file's sparse attribute and saves it through xattr without any permission checks. This exposes two issues: 1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check test_tree_conn_flag(work->tcon, KSMBD_TREE_CONN_FLAG_WRITABLE), but FSCTL_SET_SPARSE does not. 2) Even on writable shares, clients without FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here. Add both share-level writable check and per-handle access check. Use goto out on error to avoid leaking file references. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: Namjae Jeon Cc: Sergey Senozhatsky Cc: Steve French Signed-off-by: Sean Shen Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 43368636c663cff6e59dde93cf4b8e43ac28eb93 Author: Eric Dumazet Date: Fri May 22 11:55:12 2026 +0000 tunnels: do not assume transport header in iptunnel_pmtud_check_icmp() [ Upstream commit 509323077ef79a26ba0c60bb556e45c12c398b2d ] In some cases, iptunnel_pmtud_check_icmp() can be called while skb transport header is not set. This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535. Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part. Note that iptunnel_pmtud_check_icmpv6()) is fine. Fixes: 4cb47a8644cc ("tunnels: PMTU discovery support for directly bridged IP packets") Reported-by: Damiano Melotti Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260522115512.1519110-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5303925e360527243b46a440a04667826bbc72b7 Author: Eric Dumazet Date: Mon May 25 20:36:42 2026 +0000 vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu() [ Upstream commit 7d9ef0cb271555d8cf39fefe6c981e1493b25ecf ] skb_tunnel_check_pmtu() can change skb->head. Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF. Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c. Found by Sashiko. Fixes: 4cb47a8644cc ("tunnels: PMTU discovery support for directly bridged IP packets") Signed-off-by: Eric Dumazet Reviewed-by: Stefano Brivio Link: https://patch.msgid.link/20260525203642.2389723-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6dff77899b9e9fe5d854abda3a98ad04e7229ef7 Author: Eric Dumazet Date: Mon May 25 20:13:35 2026 +0000 tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]() [ Upstream commit b4bc94353050b1fa7b702bd4c6600710dd926cff ] Sashiko found that iptunnel_pmtud_build_icmp() and iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr() before an skb_cow() call which can reallocate skb->head. Fix this possible UAF by initializing the local variables after the skb_cow() call. Remove skb_reset_network_header() calls which were not needed. Fixes: 4cb47a8644cc ("tunnels: PMTU discovery support for directly bridged IP packets") Signed-off-by: Eric Dumazet Reviewed-by: Stefano Brivio Link: https://patch.msgid.link/20260525201335.2361845-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2a8c9994406b4f1892e85c0dfb8b9cb106084019 Author: Li Ming Date: Wed May 20 20:14:57 2026 +0800 cxl/test: Update mock dev array before calling platform_device_add() [ Upstream commit d90f236f8b9e354848bd226f581db27755ab901d ] CXL test environment hits the following error sometimes. cxl_mem mem9: endpoint7 failed probe All mock memdevs are platform firmware devices added by cxl_test module, and cxl_test module also provides a platform device driver for them to create a memdev device to CXL subsystem. cxl_test module uses cxl_rcd/mem_single/mem arrays to store different types of mock memdevs. CXL drivers calls registered mock functions for a mock memdev by checking if a given memdev is in these arrays. When cxl_test module adds these mock memdevs, it always calls platform_device_add() before adding them to a suitable mock memdev array. However, there is a small window where CXL drivers calls mock function for a added memdev before it added to a mock memdev array. In above case, cxl endpoint driver considers a added memdev was not a mock memdev, then calling devm_cxl_endpoint_decoders_setup() for it rather than mock_endpoint_decoders_setup(). An appropriate solution is that adding a new mock device to a mock device array before calling platform_device_add() for it. It can guarantee the new mock device is visible to CXL subsystem. This patch introduces a new helped called cxl_mock_platform_device_add() to handle the issue, and uses the function for all mock devices addition. Fixes: 3a2b97b3210b ("cxl/test: Improve init-order fidelity relative to real-world systems") Signed-off-by: Li Ming Tested-by: Alison Schofield Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260520121457.234404-1-ming.li@zohomail.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 41d2dc766bf8cade44ca25ad10673ad740bb89cc Author: Jakub Kicinski Date: Fri May 22 16:13:12 2026 -0700 ethtool: cmis: validate fw->size against start_cmd_payload_size [ Upstream commit d5551f4c1800dc714cec86647bdd651ae0de923e ] cmis_fw_update_start_download() copies start_cmd_payload_size bytes from the firmware blob into the CDB LPL vendor_data[] payload without validating that the FW has enough data. Since the start_cmd_payload_size can only be ~120B an image too short is most likely corrupted, so reject it. Fixes: c4f78134d45c ("ethtool: cmis_fw_update: add a layer for supporting firmware update using CDB") Reviewed-by: Maxime Chevallier Reviewed-by: Danielle Ratson Link: https://patch.msgid.link/20260522231312.1710836-10-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0696709e951be54c699664adf546d16e28974d53 Author: Jakub Kicinski Date: Fri May 22 16:13:11 2026 -0700 ethtool: cmis: validate start_cmd_payload_size from module [ Upstream commit 12c2496a71f82f63617971ca9b730dffa05cf58b ] The CMIS firmware update code reads start_cmd_payload_size from the module's FW Management Features CDB reply and uses it directly as the byte count for memcpy. The destination buffer is 112 bytes (ETHTOOL_CMIS_CDB_LPL_MAX_PL_LENGTH - 8). So a malicious module (or corrupted response) can cause a OOB write later on in cmis_fw_update_start_download(). Let's error out. If modules that expect longer LPL writes actually exist we should revisit. struct cmis_cdb_start_fw_download_pl's definition has to move, no change there. Fixes: c4f78134d45c ("ethtool: cmis_fw_update: add a layer for supporting firmware update using CDB") Reviewed-by: Maxime Chevallier Reviewed-by: Danielle Ratson Link: https://patch.msgid.link/20260522231312.1710836-9-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0cbce444db75f64dceee839bf8794470e78f8e68 Author: Jakub Kicinski Date: Fri May 22 16:13:10 2026 -0700 ethtool: cmis: fix u16-to-u8 truncation of msleep_pre_rpl [ Upstream commit 3e8c3d464c36bb342fe377b026577c7ec27fdbb4 ] ethtool_cmis_cdb_compose_args() accepts msleep_pre_rpl as u16 but stores it into the u8 field ethtool_cmis_cdb_cmd_args::msleep_pre_rpl, silently truncating values >= 256. Seven of the nine call sites pass 1000 ms (it's the third argument from the end). Fixes: a39c84d79625 ("ethtool: cmis_cdb: Add a layer for supporting CDB commands") Reviewed-by: Maxime Chevallier Reviewed-by: Danielle Ratson Link: https://patch.msgid.link/20260522231312.1710836-8-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4d42fb88ec61f2e98c33a9e3a2de371d5edbc6b1 Author: Jakub Kicinski Date: Fri May 22 16:13:09 2026 -0700 ethtool: cmis: require exact CDB reply length [ Upstream commit 6c3f999a9d1338c6c89a9ff4549eafe72bc2e7b1 ] Malicious SFP module could respond with rpl_len longer than what cmis_cdb_process_reply() expected, leading to OOB writes. Malicious HW is a bit theoretical but some modules may just be buggy and/or the reads may occasionally get corrupted, so let's protect the kernel. The existing check protects from short replies. We need to protect from long ones, too. All callers that pass a non-zero rpl_exp_len cast the reply payload to a fixed-layout struct and read fields at fixed offsets, with no version negotiation or short-reply handling: - cmis_cdb_validate_password() - cmis_cdb_module_features_get() - cmis_fw_update_fw_mng_features_get() so let's assume that responses longer than expected do not have to be handled gracefully here. Add a warning message to make the debug easier in case my understanding is wrong... Note that page_data->length (argument of kmalloc) comes from last arg to ethtool_cmis_page_init() which is rpl_exp_len. Note2 that AIs also like to point out overflows in args->req.payload itself (which is a fixed-size 120 B buffer, on the stack), but callers should be reading structs defined by the standard, so protecting from requests for more data than max seem like defensive programming. Fixes: a39c84d79625 ("ethtool: cmis_cdb: Add a layer for supporting CDB commands") Reviewed-by: Danielle Ratson Link: https://patch.msgid.link/20260522231312.1710836-7-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e1dd697094f1d4223052c82f140fb49b3aaad5bb Author: Jakub Kicinski Date: Fri May 22 16:13:08 2026 -0700 ethtool: module: fix cleanup if socket used for flashing multiple devices [ Upstream commit 760d04ebad5c4304f22c0d2251c9623b87a117c8 ] When a single Netlink socket issues MODULE_FW_FLASH_ACT against multiple devices, ethnl_sock_priv_set() overwrites sk_priv->dev on each call, retaining only the last one. The socket priv is used on socket close, to walk the global work list and mark the uncompleted flashing work as "orphaned". Otherwise if another socket reuses the PID it will unexpectedly receive the flashing notifications. Don't record the device, record net pointer instead. The purpose of the dev is to scope the work to a netns, anyway. If we store netns the overrides are safe/a nop since all flashed devices must be in the same netns as the socket. Fixes: 32b4c8b53ee7 ("ethtool: Add ability to flash transceiver modules' firmware") Reviewed-by: Danielle Ratson Link: https://patch.msgid.link/20260522231312.1710836-6-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9e70c8efb0caf3652864b1c3f867b89082a04580 Author: Jakub Kicinski Date: Fri May 22 16:13:07 2026 -0700 ethtool: module: check fw_flash_in_progress under rtnl_lock [ Upstream commit 504eaefa44c8dec50f7499edcb36d24f3aefab2a ] ethnl_set_module_validate() inspects module_fw_flash_in_progress but validate is meant for _input_ validation, not state validation. rtnl_lock is not held, yet. Move the check into ethnl_set_module(). Fixes: 32b4c8b53ee7 ("ethtool: Add ability to flash transceiver modules' firmware") Reviewed-by: Maxime Chevallier Reviewed-by: Danielle Ratson Link: https://patch.msgid.link/20260522231312.1710836-5-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9f5108f5ee27302437db855abbc36fb0deb7e4e8 Author: Jakub Kicinski Date: Fri May 22 16:13:06 2026 -0700 ethtool: module: avoid racy updates to dev->ethtool bitfield [ Upstream commit 7a84b965ffc12030af63cd10a8f3a1123ff39b7a ] When reviewing other changes Gemini points out that we currently update module_fw_flash_in_progress without holding any locks. Since module_fw_flash_in_progress is part of a bitfield this is not great, updates to other fields may be lost. We could use a bool and sprinkle some READ_ONCE/WRITE_ONCE here but seems like the issue is rather than the work is an unusual writer. The other writers already hold the right locks. So just very briefly take these locks when the work completes. Note that nothing ever cancels the FW update work, so there's no concern with deadlocks vs cancel. Fixes: 32b4c8b53ee7 ("ethtool: Add ability to flash transceiver modules' firmware") Reviewed-by: Maxime Chevallier Reviewed-by: Danielle Ratson Link: https://patch.msgid.link/20260522231312.1710836-4-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 61848c83b9132ab839809fe415ba7802a0aca4f6 Author: Jakub Kicinski Date: Fri May 22 16:13:05 2026 -0700 ethtool: module: avoid leaking a netdev ref on module flash errors [ Upstream commit fb7f511d62692661846c47f199e0afe25c2982db ] module_flash_fw_schedule() is missing undo for setting the "in_progress" flag and taking the netdev reference. Delay taking these, the device can't disappear while we are holding rtnl_lock. Fixes: 32b4c8b53ee7 ("ethtool: Add ability to flash transceiver modules' firmware") Reviewed-by: Maxime Chevallier Reviewed-by: Danielle Ratson Link: https://patch.msgid.link/20260522231312.1710836-3-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d9defbf8b62bde89e206d74c2a2b445b9ed66108 Author: Jakub Kicinski Date: Fri May 22 16:13:04 2026 -0700 ethtool: module: call ethnl_ops_complete() on module flash errors [ Upstream commit 84371fb58423f997939aacdcbc02d128d76a54e5 ] When validate() fails we are skipping over ethnl_ops_complete() even tho we already called ethnl_ops_begin(). Fixes: 32b4c8b53ee7 ("ethtool: Add ability to flash transceiver modules' firmware") Reviewed-by: Maxime Chevallier Reviewed-by: Danielle Ratson Link: https://patch.msgid.link/20260522231312.1710836-2-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7877d8fbbec2d03d4dd890728f9777e1679fa731 Author: Jakub Kicinski Date: Fri May 22 16:06:47 2026 -0700 ethtool: rss: avoid device context leak on reply-build failure [ Upstream commit 32a9ecde62731c9f7412507709192c84dafc38d1 ] We wait with filling the reply for new RSS context creation until after the driver ->create_rxfh_context call. The driver needs to fill some of the defaults in the context. The failure of rss_fill_reply() is somewhat theoretical, but doesn't take much effort to handle it properly. Call ->remove_rxfh_context(). If the driver's remove callback fails (some implementations like sfc can return real command errors from firmware RPCs) - skip the xa_erase and kfree, leaving the context in the xarray. This matches how ethnl_rss_delete_doit() behaves. Fixes: a166ab7816c5 ("ethtool: rss: support creating contexts via Netlink") Link: https://patch.msgid.link/20260522230647.1705600-7-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7ddc3b3ddee8c78e2d82f6cfa682a201faafdc4d Author: Jakub Kicinski Date: Fri May 22 16:06:46 2026 -0700 ethtool: rss: fix hkey leak when indir_size is 0 [ Upstream commit 78ccf1a70c6378e1f5073a8c2209b5129067b925 ] rss_get_data_alloc() allocates a single buffer that backs both the indirection table and the hash key, but only assigned data->indir_table when indir_size was nonzero. The expectation was that no driver implements RSS without supporting indirection table but apparently enic does just that (it's the only such in-tree driver). enic has get_rxfh_key_size but no get_rxfh_indir_size. data->indir_table stays as NULL, hkey gets set but rss_get_data_free() kfree(data->indir_table) is a nop and the allocation leaks. Always store the allocation base in data->indir_table so the free path is unambiguous. No caller treats indir_table as a sentinel; everything keys off indir_size. Fixes: 7112a04664bf ("ethtool: add netlink based get rss support") Link: https://patch.msgid.link/20260522230647.1705600-6-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 33d05c22d6f227c5ae171c46df2f6f8bf48047ea Author: Jakub Kicinski Date: Fri May 22 16:06:45 2026 -0700 ethtool: rss: fix indir_table and hkey leak on get_rxfh failure [ Upstream commit 266297692f97008ca48bc311775c087c59bd7fe3 ] rss_prepare_get() allocates the indirection table and hash key buffer via rss_get_data_alloc(), then calls ops->get_rxfh() to populate them. If get_rxfh() fails, the function returns an error without freeing the allocation. Fixes: 4f038a6a02d2 ("net: ethtool: Don't call .cleanup_data when prepare_data fails") Link: https://patch.msgid.link/20260522230647.1705600-5-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 39c01c405063a8a8697f156dcbde8fcf011e98cd Author: Jakub Kicinski Date: Fri May 22 16:06:44 2026 -0700 ethtool: rss: fix falsely ignoring indir table updates [ Upstream commit 8d60141a32875248ef71d49c9920fa5e2aa40b29 ] rss_set_prep_indir() compares the new indirection table against the current one to determine whether any update is needed. The memcmp call passes data->indir_size as the length argument, but indir_size is the number of u32 entries, not the byte count. Fixes: c0ae03588bbb ("ethtool: rss: initial RSS_SET (indirection table handling)") Link: https://patch.msgid.link/20260522230647.1705600-4-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6a775ec73210d222dec7f5f08caf1b315e527b8b Author: Jakub Kicinski Date: Fri May 22 16:06:43 2026 -0700 ethtool: rss: add missing errno on RSS context delete [ Upstream commit 3e6c6e9782ff8a8d8ded774b07ad4590cd61d04c ] Remember to set ret before jumping out if someone tries to delete a context on a device which doesn't support contexts. Fixes: fbe09277fa63 ("ethtool: rss: support removing contexts via Netlink") Link: https://patch.msgid.link/20260522230647.1705600-3-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f23e4d7324b8d3bd892f52323b0b88d08c8a38e4 Author: Jakub Kicinski Date: Fri May 22 16:06:42 2026 -0700 ethtool: rss: avoid modifying the RSS context response [ Upstream commit c75b6f6eaacd0b74b832414cc3b9289c3686e941 ] Gemini says that we're modifying the RSS_CREATE response skb. I think it's right, the comment says that unicast() should unshare the skb but I'm not entirely sure what I meant there. netlink_trim() does a copy but only if skb is not well sized (it's at least 2x larger than necessary for the payload). Fixes: a166ab7816c5 ("ethtool: rss: support creating contexts via Netlink") Link: https://patch.msgid.link/20260522230647.1705600-2-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 48fd840a26d35cca8a1c338c22f790db953a64a7 Author: Björn Töpel Date: Fri May 22 14:06:40 2026 +0200 net: Avoid checksumming unreadable skb tail on trim [ Upstream commit 2e357f002c61fd76fd8f12468744a06a5ec48eaa ] pskb_trim_rcsum_slow() keeps CHECKSUM_COMPLETE valid by subtracting the checksum of the bytes removed from the skb tail. That assumes the removed bytes can be read. io_uring zcrx skbs may contain unreadable net_iov frags. With fbnic header/data split, small TCP/IPv4 packets can carry Ethernet padding in such a frag. ip_rcv_core() trims the skb to iph->tot_len before TCP sees it, and the CHECKSUM_COMPLETE adjustment then calls skb_checksum() on the padding. This is exposed by IPv4 because small TCP/IPv4 frames can be shorter than the Ethernet minimum payload. TCP/IPv6 frames are large enough in the normal zcrx path, so they do not hit the same padding trim. Keep the existing checksum adjustment for readable skbs. If the remaining packet is fully linear, drop CHECKSUM_COMPLETE and let the stack validate the packet after trimming. If unreadable payload would remain, fail the trim; the checksum cannot be adjusted without reading the trimmed tail. Also clear skb->unreadable when trimming removes all frags. Fixes: 65249feb6b3d ("net: add support for skbs with unreadable frags") Signed-off-by: Björn Töpel Reviewed-by: Breno Leitao Link: https://patch.msgid.link/20260522120643.242974-1-bjorn@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 03e9405c518c4d61f28079492f252d6d4e2bac5c Author: Weiming Shi Date: Thu May 21 01:12:01 2026 -0700 net: team: fix NULL pointer dereference in team_xmit during mode change [ Upstream commit 25fe708bbc59289d3d1ea4b126fbc1b460a072a5 ] __team_change_mode() clears team->ops with memset() before restoring safe dummy handlers via team_adjust_ops(). A concurrent team_xmit() running under RCU on another CPU can read team->ops.transmit during this window and call a NULL function pointer, crashing the kernel. The race requires a mode change (CAP_NET_ADMIN) concurrent with transmit on the team device. BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: 0010 [#1] SMP KASAN NOPTI RIP: 0010:0x0 Call Trace: team_xmit (drivers/net/team/team_core.c:1853) dev_hard_start_xmit (net/core/dev.c:3904) __dev_queue_xmit (net/core/dev.c:4871) packet_sendmsg (net/packet/af_packet.c:3109) __sys_sendto (net/socket.c:2265) The original code assumed that no ports means no traffic, so mode changes could freely memset()/memcpy() the ops. AF_PACKET with forced carrier breaks that assumption. Prevent the race instead of making it safe: replace memset()/memcpy() with per-field updates that never touch transmit or receive. Those two handlers are managed solely by team_adjust_ops(), which already installs dummies when tx_en_port_count == 0 (always true during mode change since no ports are present). WRITE_ONCE/READ_ONCE prevent store/load tearing on the handler pointers. synchronize_net() before exit_op() drains in-flight readers that may still reference old mode state from before port removal switched the handlers to dummies. Fixes: 3d249d4ca7d0 ("net: introduce ethernet teaming device") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Reviewed-by: Jiayuan Chen Link: https://patch.msgid.link/20260521081159.1491563-3-bestswngs@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c2af23b48f936e944bbd779ad12f179f18bd10a5 Author: Marc Harvey Date: Thu Apr 9 02:59:25 2026 +0000 net: team: Rename port_disabled team mode op to port_tx_disabled [ Upstream commit cfa477df2cc62ba53cb936669886361152b594a7 ] This team mode op is only used by the load balance mode, and it only uses it in the tx path. Reviewed-by: Jiri Pirko Signed-off-by: Marc Harvey Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260409-teaming-driver-internal-v7-3-f47e7589685d@google.com Signed-off-by: Paolo Abeni Stable-dep-of: 25fe708bbc59 ("net: team: fix NULL pointer dereference in team_xmit during mode change") Signed-off-by: Sasha Levin commit a20e6ae5f05e26c4bdf1471d2f96bb622bed09c9 Author: Marc Harvey Date: Thu Apr 9 02:59:24 2026 +0000 net: team: Remove unused team_mode_op, port_enabled [ Upstream commit 014f249121d73909528df320818fba7693d0ec92 ] This team_mode_op wasn't used by any of the team modes, so remove it. Reviewed-by: Jiri Pirko Signed-off-by: Marc Harvey Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260409-teaming-driver-internal-v7-2-f47e7589685d@google.com Signed-off-by: Paolo Abeni Stable-dep-of: 25fe708bbc59 ("net: team: fix NULL pointer dereference in team_xmit during mode change") Signed-off-by: Sasha Levin commit f2e077e8979f204fd3480d411cea3e7325c596a8 Author: Alexander Stein Date: Tue May 26 08:35:01 2026 +0200 gpio: mxc: fix irq_high handling [ Upstream commit dac917ed5aead741004db8d0d5151dd577802df8 ] If port->irq_high is -1 (fsl,imx21-gpio compatible) and gpio_idx is >= 16 enable_irq_wake() is called with -1 which is wrong. Fixes: 5f6d1998adeb ("gpio: mxc: release the parent IRQ in runtime suspend") Signed-off-by: Alexander Stein Reviewed-by: Frank Li Link: https://patch.msgid.link/20260526063504.25916-1-alexander.stein@ew.tq-group.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit fbd0662f9c9a66e8cc3df3099cca8ed6d3837cc7 Author: Luka Gejak Date: Sat May 23 15:03:30 2026 +0200 net: hsr: fix potential OOB access in supervision frame handling [ Upstream commit f229426072fc865654a60978bb7fda790a051ff3 ] Ensure the entire TLV header is linearized before access by adding sizeof(struct hsr_sup_tlv) to the pskb_may_pull() calls. Without this, a truncated frame could cause an out-of-bounds access. Fixes: eafaa88b3eb7 ("net: hsr: Add support for redbox supervision frames") Signed-off-by: Luka Gejak Reviewed-by: Fernando Fernandez Mancera Link: https://patch.msgid.link/20260523130330.61880-1-luka.gejak@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2a15a03e58b00484e7f48aabb3a309735ca0a572 Author: Prathamesh Deshpande Date: Wed May 6 01:00:31 2026 +0100 net/mlx5: HWS: Reject unsupported remove-header action [ Upstream commit 86f1d0f063e423a5c1982db1e5e7a8eac511e603 ] mlx5_cmd_hws_packet_reformat_alloc() handles MLX5_REFORMAT_TYPE_REMOVE_HDR by looking up a matching HWS remove-header action. If mlx5_fs_get_action_remove_header_vlan() returns NULL, the code only logs an error and continues. The function then returns success with a NULL HWS action stored in the packet-reformat object. Return an error when no matching remove-header action is available. Fixes: aecd9d1020e3 ("net/mlx5: fs, add HWS packet reformat API function") Signed-off-by: Prathamesh Deshpande Reviewed-by: Simon Horman Reviewed-by: Yevgeny Kliteynik Acked-by: Tariq Toukan Link: https://patch.msgid.link/20260506000054.51797-1-prathameshdeshpande7@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f0ac76e3d55e9e7f0e6b26610e3de49026a4a196 Author: Cássio Gabriel Date: Tue May 19 13:51:47 2026 -0300 ASoC: Intel: bytcht_es8316: Fix MCLK leak on init errors [ Upstream commit afb2a3a9d8369d18122a0d7cd294eba9a98259c6 ] byt_cht_es8316_init() enables MCLK before configuring the codec sysclk and creating the headset jack. If either of those later steps fails, the function returns without disabling MCLK, leaving the clock enabled after card registration fails. Track whether this driver enabled MCLK and disable it on the init error paths. Add the matching DAI link exit callback so the same clock enable is also balanced when ASoC cleans up a successfully initialized link. Fixes: a03bdaa565cb ("ASoC: Intel: add machine driver for BYT/CHT + ES8316") Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260519-asoc-bytcht-es8316-mclk-leak-v1-1-b4a11cdc2afd@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e13922bb97b4e6f94f8ac02d034f2d4bd65eeb3c Author: Cássio Gabriel Date: Fri May 22 22:09:40 2026 -0300 ALSA: pcm: oss: Fix setup list UAF on proc write error [ Upstream commit 4cc54bdd54b337e77115be5b55577d1c58608eae ] snd_pcm_oss_proc_write() links a newly allocated setup entry into the OSS setup list before duplicating the task name. If the task-name allocation fails, the error path frees the already linked entry and leaves setup_list pointing at freed memory. A later OSS device open can then walk the stale list entry in snd_pcm_oss_look_for_setup() and dereference freed memory. Allocate the task name and initialize the setup entry before publishing the entry on setup_list. Also fetch the initial proc read iterator only after taking setup_mutex, so all setup_list traversal follows the same list lifetime rules. Reported-by: syzbot+8e498074a794999eb41c@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6a1062b7.170a0220.35b2b7.0003.GAE@google.com Closes: https://syzkaller.appspot.com/bug?extid=8e498074a794999eb41c Fixes: 060d77b9c04a ("[ALSA] Fix / clean up PCM-OSS setup hooks") Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260522-alsa-pcm-oss-setup-uaf-v1-1-40bdcc4d17e8@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit a7f4eefb6e1458431eef9fa20fb363320d185f76 Author: Eric Dumazet Date: Thu May 21 12:21:47 2026 +0000 ipv4: free net->ipv4.sysctl_local_reserved_ports after unregister_net_sysctl_table() [ Upstream commit 87a1e0fe7776da7ab411be332b4be58ac8840d10 ] ipv4_sysctl_exit_net() is currently freeing net->ipv4.sysctl_local_reserved_ports too soon. Only after unregister_net_sysctl_table() we can be sure no threads can possibly use the sysctls, including /proc/sys/net/ipv4/ip_local_reserved_ports. Fixes: 122ff243f5f1 ("ipv4: make ip_local_reserved_ports per netns") Reported-by: Ji'an Zhou Signed-off-by: Eric Dumazet Cc: Cong Wang Reviewed-by: Jason Xing Reviewed-by: Jiayuan Chen Link: https://patch.msgid.link/20260521122147.3584624-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 475f2b37a78f4c698967a7f14f325f04e24c9175 Author: David Jeffery Date: Fri May 15 14:09:41 2026 -0400 scsi: core: Run queues for all non-SDEV_DEL devices from scsi_run_host_queues [ Upstream commit 7205b58702273baf21d6ba7992e6ba15852325f7 ] While a SCSI host is in a recovery state, scsi_mq_requeue_cmd() will not set the requeue list for a requeued command to be kicked in the future. The expectation is a call to scsi_run_host_queues() will kick all SCSI devices once the recovery state is cleared. However, scsi_run_host_queues() uses shost_for_each_device() which uses scsi_device_get() and so will ignore devices in a partially removed state like SDEV_CANCEL. But these devices may also have requeued requests, leaving their requests stuck from not being kicked and causing the removal process of the device to hang. scsi_run_host_queues() needs to run against more devices than the macro shost_for_each_device() allows. Instead of using the too limiting scsi_device_get() state checks, only ignore devices in SDEV_DEL state or when unable to acquire a reference. Attempt to run the queues for all other devices when scsi_run_host_queues() is called. Fixes: 8b566edbdbfb ("scsi: core: Only kick the requeue list if necessary") Signed-off-by: David Jeffery Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260515180941.9698-1-djeffery@redhat.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 9817369243380e287ebe5525411557eaa3aa2a79 Author: Breno Leitao Date: Thu May 21 07:11:45 2026 -0700 net/iucv: fix locking in .getsockopt [ Upstream commit 3589d20a666caf30ad100c960a2de7de390fce88 ] Mirror iucv_sock_setsockopt() and wrap the whole switch in lock_sock()/release_sock(). The pre-existing SO_MSGLIMIT-only lock becomes redundant and is removed. Any AF_IUCV HIPER user can potentially crash the kernel by racing recvmsg() with getsockopt(SO_MSGSIZE): the SO_MSGSIZE arm dereferences iucv->hs_dev->mtu after iucv_sock_close() (called from the racing recvmsg()) has set hs_dev to NULL, producing a NULL pointer dereference oops. Suggested-by: Stanislav Fomichev Fixes: 51363b8751a6 ("af_iucv: allow retrieval of maximum message size") Signed-off-by: Breno Leitao Reviewed-by: Alexandra Winter Tested-by: Alexandra Winter Link: https://patch.msgid.link/20260521-af_iucv_fix2-v1-1-f16b1c510aa9@debian.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 55cba6b883b41e5922c00ba9d4e3262131f46f1b Author: Alexandra Winter Date: Thu May 21 16:56:39 2026 +0200 net/smc: Do not re-initialize smc hashtables [ Upstream commit 9e4389b0038781f19f97895186ed941ff8ac1678 ] INIT_HLIST_HEAD(&smc_v*_hashinfo.ht) are called after smc_nl_init(), proto_register() and sock_register(). This can lead to smc_v*_hashinfo.ht being reset even though hash entries already exist and are being used, possibly resulting in a corrupted list. Remove unnecessary and dangerous re-initialisation of smc_v*_hashinfo.ht in smc_init(); it is implicitly initialised to zero anyhow. Add HLIST_HEAD_INIT to the definitions for clarity. Fixes: f16a7dd5cf27 ("smc: netlink interface for SMC sockets") Suggested-by: Halil Pasic Signed-off-by: Alexandra Winter Acked-by: Halil Pasic Reviewed-by: Mahanta Jambigi Link: https://patch.msgid.link/20260521145639.10317-1-wintera@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bcd0d19db3e66d457c18f8e54302115cbd175f31 Author: Ilya Maximets Date: Wed May 20 19:22:36 2026 +0200 net: netlink: don't set nsid on local notifications [ Upstream commit 88b126b39f9757e9debc322d4679239e9af089c7 ] In most cases, notifications on sockets with NETLINK_LISTEN_ALL_NSID do not contain NSID in their ancillary data in case the event is local to the listener. However, when a self-referential NSID is allocated for a namespace, every local notification starts sending this ID to the user space. This is problematic, because the listener cannot tell if those notifications are local or not anymore without making extra requests to figure out if the provided NSID is local or not. The listener can also not figure out the local NSID beforehand as it can be allocated at any point in time by other processes, changing the structure of the future notifications for everyone. The value is practically not useful, since it's the namespace's own ID that the application has to obtain from other sources in order to figure out if it's the same or not. So, for the application it's just an extra busy work with no benefits. Moreover, applications that do not know about this quirk may be mishandling notifications with NSID set as notifications from remote namespaces. This is the case for ovs-vswitchd and the iproute2's 'ip monitor' that stops printing 'current' and starts printing the nsid number mid-session. Lack of clear documentation for this behavior is also not helping. A search though open-source projects doesn't reveal any projects that use NETNSA_NSID_NOT_ASSIGNED and rely on metadata to contain self-referential NSIDs (expected, since the value is not useful). Quite the opposite, as already mentioned, there are few applications that rely on NSID to not be present in local events. Since the value is not useful and actively harmful in some cases, let's not report it for local events, making the notifications more consistent. Also adding some blank lines for readability. Fixes: 59324cf35aba ("netlink: allow to listen "all" netns") Reported-by: Matteo Perin Signed-off-by: Ilya Maximets Acked-by: Nicolas Dichtel Link: https://patch.msgid.link/20260520172317.175168-3-i.maximets@ovn.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ca5e366296417f399b73fa5ce39f9f37770d1e1c Author: Ilya Maximets Date: Wed May 20 19:22:35 2026 +0200 net: netlink: fix sending unassigned nsid after assigned one [ Upstream commit 70f8592ee90585272018a725054b6eb2ab7e99ca ] If the current skb is not shared, it is re-used directly for all the sockets subscribed to the notification. If we have remote all-nsid socket receiving a message first, then the 'nsid_is_set' will be set to 'true'. If the nsid is NOT_ASSIGNED for the next socket in the list, the 'nsid_is_set' will remain 'true' and the negative value is be delivered to the user space. All subsequent nsid values will be delivered as well, since there is no code path that sets the flag back to 'false'. Fix that by always dropping the flag to 'false' first. Fixes: 7212462fa6fd ("netlink: don't send unknown nsid") Signed-off-by: Ilya Maximets Acked-by: Nicolas Dichtel Link: https://patch.msgid.link/20260520172317.175168-2-i.maximets@ovn.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ef3b3ea864d0aecfc8bcec471d567edfe7b6572e Author: Ziyu Zhang Date: Wed May 20 00:56:36 2026 +0800 vsock: keep poll shutdown state consistent [ Upstream commit aae9d8a5528b8ee9ff8dc5d3558b8a9f852a724a ] vsock_poll() reads vsk->peer_shutdown before taking the socket lock to set EPOLLHUP and EPOLLRDHUP, then reads it again after taking the lock to report EOF readability. A shutdown packet can update peer_shutdown while poll is waiting for the lock, so one poll invocation can report EOF readability without the corresponding HUP/RDHUP bits. For connectible sockets, take one peer_shutdown snapshot after lock_sock() and use it for all peer-shutdown-derived poll bits. For datagram sockets, which do not take lock_sock() in poll(), take one lockless READ_ONCE() snapshot and pair it with WRITE_ONCE() on the writer side. This keeps the peer-shutdown-derived bits internally consistent for each poll pass. Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Signed-off-by: Ziyu Zhang Link: https://patch.msgid.link/20260519165636.62542-1-ziyuzhang201@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit aa308e9dbb9acb17cacdbbce9e4504f69bac8385 Author: Weiming Shi Date: Thu May 21 09:33:13 2026 -0700 tun: free page on build_skb failure in tun_xdp_one() [ Upstream commit aa8963fdce667a42fb7f0bdd2909fadcab02f9a8 ] When build_skb() fails in tun_xdp_one(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhost_net_build_xdp() allocated for the frame. As with the short-frame rejection path, tun_sendmsg() discards the per-buffer error and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk. Free the page before taking the error path, matching the put_page() the other error exits of tun_xdp_one() already perform. Fixes: 043d222f93ab ("tuntap: accept an array of XDP buffs through sendmsg()") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Reviewed-by: Dongli Zhang Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260521163312.1479805-2-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 37a1c268c2c8090bf4dc552d732bd23ba36f8eb0 Author: Weiming Shi Date: Wed May 20 09:00:21 2026 -0700 tun: free page on short-frame rejection in tun_xdp_one() [ Upstream commit f4feb1e20058e407cb00f45aff47f5b7e19a6bbf ] tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without freeing the page that vhost_net_build_xdp() allocated for it. tun_sendmsg() discards that -EINVAL and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk. A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function. Fixes: 049584807f1d ("tun: add missing verification for short frame") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Reviewed-by: Dongli Zhang Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260520160020.375349-2-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 96bea2a7baac4a1137c188dc7610184487ab30a7 Author: Fernando Fernandez Mancera Date: Mon May 11 16:37:56 2026 +0200 netfilter: nf_tables: fix dst corruption in same register operation [ Upstream commit 18014147d3ee7831dce53fe65d7fc8d428b02552 ] For lshift and rshift, the shift operations are performed in a loop over 32-bit words. The loop calculates the shifted value and write it to dst, and then immediately reads from src to calculate the carry for the next iteration. Because src and dst could point to the same memory location, the carry is incorrectly calculated using the newly modified dst value instead of the original src value. Adding a temporary local variable to cache the original value before writing to dst and using it for the carry calculation solves the problem. In addition, partial overlap is rejected from control plane for all kind of operations including byteorder. This was tested with the following bytecode: table test_table ip flags 0 use 1 handle 1 ip test_table test_chain use 3 type filter hook input prio 0 policy accept packets 0 bytes 0 flags 1 ip test_table test_chain 2 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x66443322 0x00887766 ] [ counter pkts 0 bytes 0 ] ip test_table test_chain 4 3 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x55443322 0x00887766 ] [ counter pkts 21794 bytes 1917798 ] Fixes: 567d746b55bc ("netfilter: bitwise: add support for shifts.") Acked-by: Jeremy Sowden Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit bf8e8eac7ede51dc318e06acef5a896dcbba7595 Author: Florian Westphal Date: Tue May 19 22:52:07 2026 +0200 netfilter: ebtables: fix OOB read in compat_mtw_from_user [ Upstream commit f438d1786d657d57790c5d138d6db3fc9fdac392 ] Luxiao Xu says: The function compat_mtw_from_user() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied match_size/target_size. When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN. This fix introduces a check to ensure match_size is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets. AFAIU this is relevant for matches that need to go though match->compat_from_user() call. Those that use plain memcpy with the user-provided size are ok because the caller checks that size vs the start of the next rule entry offset (which itself is checked vs. total size copied from userspace). The ->compat_from_user() callbacks assume they can read compatsize bytes, so they need this extra check. Based on an earlier patch from Luxiao Xu. Fixes: 81e675c227ec ("netfilter: ebtables: add CONFIG_COMPAT support") Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Luxiao Xu Signed-off-by: Ren Wei Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 052468b1c93b2642c851b8a292c1f9c173daa604 Author: Florian Westphal Date: Tue May 19 20:10:08 2026 +0200 netfilter: xt_cpu: prefer raw_smp_processor_id [ Upstream commit c376f07e16c02239ed44cabb97145d03f65b4d15 ] With PREEMPT_RCU we get splat: BUG: using smp_processor_id() in preemptible [..] caller is cpu_mt+0x53/0xd0 net/netfilter/xt_cpu.c:37 CPU: 1 .. Comm: syz.3.1377 #0 PREEMPT(full) Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 check_preemption_disabled+0xd3/0xe0 lib/smp_processor_id.c:47 cpu_mt+0x53/0xd0 net/netfilter/xt_cpu.c:37 [..] Just use raw version instead. This is similar to 14d14a5d2957 ("netfilter: nft_meta: use raw_smp_processor_id()"). Fixes: 0ca743a55991 ("netfilter: nf_tables: add compatibility layer for x_tables") Reported-by: syzbot+690d3e3ffa7335ac10eb@syzkaller.appspotmail.com Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit f0fea2b6d5453a11ad11713bbf37561b9b3a7edf Author: Chris Mason Date: Tue May 19 12:36:14 2026 -0700 netfilter: synproxy: refresh tcphdr after skb_ensure_writable [ Upstream commit 92170e6afe927ab2792a3f71902845789c8e31b1 ] synproxy_tstamp_adjust() rewrites the TCP timestamp option in place and then patches the TCP checksum via inet_proto_csum_replace4() on the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and ipv6_synproxy_hook() obtain that pointer with skb_header_pointer() before calling in, so it may either alias skb->head directly or point at the caller's on-stack _tcph buffer. Between obtaining the pointer and using it, the function calls skb_ensure_writable(skb, optend), which on a cloned or non-linear skb invokes pskb_expand_head() and frees the old skb->head. After that point the cached th is stale: caller (ipv[46]_synproxy_hook) th = skb_header_pointer(skb, ..., &_tcph) synproxy_tstamp_adjust(skb, protoff, th, ...) skb_ensure_writable(skb, optend) pskb_expand_head() /* kfree(old skb->head) */ ... inet_proto_csum_replace4(&th->check, ...) /* writes into freed head, or into the caller's stack copy leaving the on-wire checksum stale */ The option bytes are written through skb->data and are fine; only the checksum update goes through th and so lands in the wrong place. The result is either a write into freed slab memory or a packet leaving with a checksum that does not match its payload. Fix by re-deriving th from skb->data + protoff immediately after skb_ensure_writable() succeeds, so the subsequent checksum update targets the linear, writable header. Fixes: 48b1de4c110a ("netfilter: add SYNPROXY core/target") Assisted-by: kres (claude-opus-4-7) Signed-off-by: Chris Mason Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 18abd88d19ea195e2e1547fca0970c2f91d77a42 Author: Dhabaleshwar Das Date: Thu May 21 00:00:00 2026 +0530 accel/rocket: fix UAF via dangling GEM handle in create_bo [ Upstream commit f706e6a4ce75585af979aec3dcbdce68bc76306b ] rocket_ioctl_create_bo() inserts a GEM handle into the file's IDR via drm_gem_handle_create() early on, then performs several operations that can fail (sgt allocation, drm_mm insert, iommu_map). If any fail after the handle is live, the error path calls drm_gem_shmem_object_free() which kfree's the object without removing the handle from the IDR. This leaves a dangling handle pointing to freed slab memory. Any subsequent ioctl using that handle (PREP_BO, FINI_BO, SUBMIT) calls drm_gem_object_lookup() and dereferences freed memory (UAF). Fix by moving drm_gem_handle_create() to after all fallible operations succeed, matching the pattern used by panfrost, lima, and etnaviv. Also fix drm_mm_insert_node_generic() whose return value was silently overwritten by iommu_map_sgtable() on the next line. Add the missing error check. [tomeu: Move handle creation to the very end] Fixes: 658ebeac3351 ("accel/rocket: Add IOCTL for BO creation") Reported-by: Dhabaleshwar Das Signed-off-by: Dhabaleshwar Das Reviewed-by: Tomeu Vizoso Link: https://patch.msgid.link/20260521165720.2113571-1-tomeu@tomeuvizoso.net Signed-off-by: Tomeu Vizoso Signed-off-by: Sasha Levin commit 45564a16a24f2c2573fedb7186a9e4adbacb2ad4 Author: Florian Schmaus Date: Thu May 7 10:48:54 2026 +0200 kunit: fix use-after-free in debugfs when using kunit.filter [ Upstream commit fb6988b83b4cafe8db63999c1ddff1b7c66d2ff5 ] When the kernel is booted with a kunit filter (e.g., kunit.filter="speed!=slow"), the kunit executor dynamically allocates copies of the filtered test suites using kmalloc/kmemdup. During the initial boot execution, kunit_debugfs_create_suite() creates debugfs files (such as /sys/kernel/debug/kunit//run) and permanently stores a pointer to the dynamically allocated suite in the inode's i_private field. Previously, the executor freed this dynamically allocated suite_set immediately after executing the boot-time tests. Because the debugfs nodes were not destroyed, any subsequent interaction with the debugfs `run` file from userspace triggered a use-after-free (UAF). On systems with architectural capabilities, like CHERI RISC-V, this resulted in an immediate fatal hardware exception due to the invalidation of the capability tags on the reclaimed memory. On other architectures, it resulted in silent memory corruption. Fix this UAF by properly coupling the lifetime of the filtered suite memory allocation to the lifetime of the kunit subsystem and its associated VFS nodes. Ownership of the boot-time suite_set is now transferred to a global tracker ('kunit_boot_suites'), and the memory is cleanly released in kunit_exit() during module teardown. Link: https://lore.kernel.org/r/20260507084854.233984-1-florian.schmaus@codasip.com Fixes: e2219db280e3 ("kunit: add debugfs /sys/kernel/debug/kunit//results display") Signed-off-by: Florian Schmaus Reviewed-by: Martin Kaiser Reviewed-by: David Gow Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit e1b8a53834dc951b0e024b45d3edb4e390d70e55 Author: Liu Kai Date: Thu May 7 16:32:04 2026 +0800 HID: remove duplicate hid_warn_ratelimited definition [ Upstream commit dd2147375a8fe7c5bc3f1f1b1d3a9567c26faefa ] The hid_warn_ratelimited macro is defined twice in include/linux/hid.h: - first one added by commit 4051ead99888 ("HID: rate-limit hid_warn to prevent log flooding") - second one added by commit 1d64624243af ("HID: core: Add printk_ratelimited variants to hid_warn() etc")). The second definition is correctly grouped with other ratelimited macros. Remove the duplicate definition. Fixes: 1d64624243af ("HID: core: Add printk_ratelimited variants to hid_warn() etc") Signed-off-by: Liu Kai [bentiss: edited commit message] Signed-off-by: Benjamin Tissoires Signed-off-by: Sasha Levin commit bebc7dc0fb4b03148272d68ae07985a242439aed Author: Hongtao Lee Date: Wed May 20 11:01:26 2026 +0800 tools/bootconfig: Fix buf leaks in apply_xbc [ Upstream commit f42d01aadcedd7bbf4f9a466cabe25c1781dedad ] If data calloc failed, free the buf before return. Link: https://lore.kernel.org/all/20260520030126.147782-1-lihongtao@kylinos.cn/ Fixes: 950313ebf79c ("tools: bootconfig: Add bootconfig command") Signed-off-by: Hongtao Lee Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin commit b4702049417f12e07e87f7eda80121c236950967 Author: Carl Lee Date: Sat May 16 19:55:18 2026 +0800 nfc: nxp-nci: i2c: use rising-edge IRQ on ACPI systems [ Upstream commit f23bf992d65a42007c517b060ca35cebdea3525a ] Some ACPI-based platforms report incorrect IRQ trigger types (e.g. IRQF_TRIGGER_HIGH), which can lead to interrupt storms. Use the historically working rising-edge trigger on ACPI systems to avoid this regression. Device Tree-based systems continue to use the firmware-provided trigger type. Fixes: 57be33f85e36 ("nfc: nxp-nci: remove interrupt trigger type") Signed-off-by: Carl Lee Tested-by: Bartosz Golaszewski Reviewed-by: Bartosz Golaszewski Reviewed-by: Mark Pearson Tested-by: Mark Pearson Tested-by: Luca Stefani Link: https://patch.msgid.link/20260516-nfc-nxp-nci-i2c-restore-irq-trigger-fallback-v3-1-37ba4b6e9086@amd.com Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit 82ac903e0b519849647657b8c48d21237ada06a2 Author: David Ahern Date: Wed May 13 10:49:14 2026 -0600 xfrm: Check for underflow in xfrm_state_mtu [ Upstream commit 742b04d0550b0ec89dcbc99537ec88653bd1ad90 ] Leo Lin reported OOB write issue in esp component: xfrm_state_mtu() returns u32 but performs its arithmetic in unsigned modulo-2^32 space using an attacker-influenced "header_len + authsize + net_adj" subtracted from a small "mtu" argument. A nobody user can install an IPv4 ESP tunnel SA with a large authentication key (XFRMA_ALG_AUTH_TRUNC, e.g. hmac(sha512), 64-byte key, 64-byte trunc), configure a small interface MTU (68 bytes), and set XFRMA_TFCPAD to a large value. When a single UDP datagram is then sent through the tunnel, xfrm_state_mtu() underflows to a near-2^32 value, and esp_output() consumes it as a signed int via: padto = min(x->tfcpad, xfrm_state_mtu(x, mtu_cached)) esp.tfclen = padto - skb->len (assigned to int) esp.tfclen ends up negative (e.g. -207). It is sign-extended to size_t when passed to memset() inside esp_output_fill_trailer(), producing a ~16 EB write of zeroes at skb_tail_pointer(skb). KASAN logs it as "Write of size 18446744073709551537 at addr ffff888...". Check for underflow and return 1. This causes the sendmsg attempt to fail with ENETUNREACH. Fixes: c5c252389374 ("[XFRM]: Optimize MTU calculation") Reported-by: Leo Lin Assisted-by: Codex:26.506.31004 Signed-off-by: David Ahern Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 650bdd8fdfab64a09ee474150313dbc48c374795 Author: Lee Jones Date: Wed Apr 29 13:40:42 2026 +0000 nfc: llcp: Fix use-after-free race in nfc_llcp_recv_cc() [ Upstream commit b493ea2765cc17cb8aa7e7544a4b6dcb05b6ed77 ] A race condition exists in the NFC LLCP connection state machine where the connection acceptance packet (CC) can be processed concurrently with socket release. This can lead to a use-after-free of the socket object. When nfc_llcp_recv_cc() moves the socket from the connecting_sockets list to the sockets list, it does so without holding the socket lock. If llcp_sock_release() is executing concurrently, it might have already unlinked the socket and dropped its references, which can result in nfc_llcp_recv_cc() linking a freed socket into the live list. Fix this by holding lock_sock() during the state transition and list movement in nfc_llcp_recv_cc(). After acquiring the lock, check if the socket is still hashed to ensure it hasn't already been unlinked and marked for destruction by the release path. This aligns the locking pattern with recv_hdlc() and recv_disc(). Fixes: a69f32af86e3 ("NFC: Socket linked list") Signed-off-by: Lee Jones Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260429134115.3558604-2-lee@kernel.org Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit 912ebc49d4406a17fe73e5671d674fbc2f6b2634 Author: Lee Jones Date: Wed Apr 29 13:40:41 2026 +0000 nfc: llcp: Fix use-after-free in llcp_sock_release() [ Upstream commit f4268b466190dae95a7585f69b4f1f8ad097632c ] llcp_sock_release() unconditionally unlinks the socket from the local sockets list. However, if the socket is still in connecting state, it is on the connecting list. Fix this by checking the socket state and unlinking from the correct list. Fixes: b4011239a08e ("NFC: llcp: Fix non blocking sockets connections") Signed-off-by: Lee Jones Link: https://patch.msgid.link/20260429134115.3558604-1-lee@kernel.org Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit 8b733ee4aecd03930e5c02f4365044d93b51f117 Author: Mingzhe Zou Date: Fri Apr 3 12:21:35 2026 +0800 bcache: fix uninitialized closure object [ Upstream commit 20a8e451ec1c7e99060b1bbaaad03ce88c39ddb8 ] In the previous patch ("bcache: fix cached_dev.sb_bio use-after-free and crash"), we adopted a simple modification suggestion from AI to fix the use-after-free. But in actual testing, we found an extreme case where the device is stopped before calling bch_write_bdev_super(). At this point, struct closure sb_write has not been initialized yet. For this patch, we ensure that sb_bio has been completed via sb_write_mutex. Signed-off-by: Mingzhe Zou Signed-off-by: Coly Li Link: https://patch.msgid.link/20260403042135.2221247-1-colyli@fnnas.com Fixes: fec114a98b87 ("bcache: fix cached_dev.sb_bio use-after-free and crash") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit dbc560858da8b77dd9e4ef0cd93d421e0e4d7e0e Author: Victor Nogueria Date: Thu Apr 30 11:29:56 2026 -0400 net/sched: sch_sfb: Replace direct dequeue call with peek and qdisc_dequeue_peeked [ Upstream commit 1b9bc71153b01dbde8045b9edede4240f4f5520e ] When sfb has children (eg qfq qdisc) whose peek() callback is qdisc_peek_dequeued(), we could get a kernel panic. When the parent of such qdiscs (eg illustrated in patch #3 as tbf) wants to retrieve an skb from its child (sfb in this case), it will do the following: 1a. do a peek() - and when sensing there's an skb the child can offer, then - the child in this case(sfb) calls its child's (qfq) peek. qfq does the right thing and will return the gso_skb queue packet. Note: if there wasnt a gso_skb entry then qfq will store it there. 1b. invoke a dequeue() on the child (sfb). And herein lies the problem. - sfb will call the child's dequeue() which will essentially just try to grab something of qfq's queue. [ 127.594489][ T453] KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f] [ 127.594741][ T453] CPU: 2 UID: 0 PID: 453 Comm: ping Not tainted 7.1.0-rc1-00035-gac961974495b-dirty #793 PREEMPT(full) [ 127.595059][ T453] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 127.595254][ T453] RIP: 0010:qfq_dequeue+0x35c/0x1650 [sch_qfq] [ 127.595461][ T453] Code: 00 fc ff df 80 3c 02 00 0f 85 17 0e 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 76 0c 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b [ 127.596081][ T453] RSP: 0018:ffff88810e5af440 EFLAGS: 00010216 [ 127.596337][ T453] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: dffffc0000000000 [ 127.596623][ T453] RDX: 0000000000000009 RSI: 0000001880000000 RDI: ffff888104fd82b0 [ 127.596917][ T453] RBP: ffff888104fd8000 R08: ffff888104fd8280 R09: 1ffff110211893a3 [ 127.597165][ T453] R10: 1ffff110211893a6 R11: 1ffff110211893a7 R12: 0000001880000000 [ 127.597404][ T453] R13: ffff888104fd82b8 R14: 0000000000000048 R15: 0000000040000000 [ 127.597644][ T453] FS: 00007fc380cbfc40(0000) GS:ffff88816f2a8000(0000) knlGS:0000000000000000 [ 127.597956][ T453] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 127.598160][ T453] CR2: 00005610aa9890a8 CR3: 000000010369e000 CR4: 0000000000750ef0 [ 127.598390][ T453] PKRU: 55555554 [ 127.598509][ T453] Call Trace: [ 127.598629][ T453] [ 127.598718][ T453] ? mark_held_locks+0x40/0x70 [ 127.598890][ T453] ? srso_alias_return_thunk+0x5/0xfbef5 [ 127.599053][ T453] sfb_dequeue+0x88/0x4d0 [ 127.599174][ T453] ? ktime_get+0x137/0x230 [ 127.599328][ T453] ? srso_alias_return_thunk+0x5/0xfbef5 [ 127.599480][ T453] ? qdisc_peek_dequeued+0x7b/0x350 [sch_qfq] [ 127.599670][ T453] ? srso_alias_return_thunk+0x5/0xfbef5 [ 127.599831][ T453] tbf_dequeue+0x6b1/0x1098 [sch_tbf] [ 127.599988][ T453] __qdisc_run+0x169/0x1900 The right thing to do in #1b is to grab the skb off gso_skb queue. This patchset fixes that issue by changing #1b to use qdisc_dequeue_peeked() method instead. Fixes: e13e02a3c68d ("net_sched: SFB flow scheduler") Signed-off-by: Victor Nogueria Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260430152957.194015-3-jhs@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 91cc13978ab0bc6f669139f53e7e613a860d10e0 Author: Usama Arif Date: Thu May 21 03:29:26 2026 -0700 xfrm: move policy_bydst RCU sync from per-netns .exit to .pre_exit [ Upstream commit 3e52417318473782012b236d0325bf7d2266a597 ] The struct pernet_operations docstring in include/net/net_namespace.h explicitly warns against blocking RCU primitives in .exit handlers: Exit methods using blocking RCU primitives, such as synchronize_rcu(), should be implemented via exit_batch. [...] Please, avoid synchronize_rcu() at all, where it's possible. Note that a combination of pre_exit() and exit() can be used, since a synchronize_rcu() is guaranteed between the calls. xfrm_policy_fini() violates this: it calls synchronize_rcu() before freeing the policy_bydst hash tables (so no RCU reader is mid- traversal at free time), but runs from xfrm_net_ops.exit -- once per namespace -- so a cleanup_net() of N namespaces pays N full RCU grace periods serially. Use the documented pre_exit/exit split. Move the policy flush (and the workqueue drains it depends on) into a new .pre_exit handler; xfrm_policy_fini() then runs in .exit and frees the hash tables after the synchronize_rcu_expedited() that cleanup_net() guarantees between the two phases. Providing O(1) RCU grace periods per batch instead of O(N). Observed on Linux 6.18 with a workload doing unshare(CLONE_NEWNET) at ~13/sec sustained: cleanup_net() and the netns_wq rescuer kthread both stuck in xfrm_policy_fini()'s synchronize_rcu(), >300k struct net accumulated in the cleanup queue, Percpu in /proc/meminfo climbed to 130+ GB on 256-CPU hosts, and memcg OOMs followed. setup_net and __put_net counts were balanced, ruling out a refcount leak. Fixes: 069daad4f2ae ("xfrm: Wait for RCU readers during policy netns exit") Signed-off-by: Usama Arif Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 54ed418de62a148a655262da682a050fa05f7924 Author: Jeremy Kerr Date: Tue Jun 2 15:34:28 2026 +0800 net: mctp: ensure our nlmsg responses are initialised [ Upstream commit a6a9bc544b675d8b5180f2718ec985ad267b5cbf ] Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTM_GETNEIGH will return uninitalised data in the pad bytes of the ndmsg data. Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages. Fixes: 831119f88781 ("mctp: Add neighbour netlink interface") Fixes: 06d2f4c583a7 ("mctp: Add netlink route management") Fixes: 583be982d934 ("mctp: Add device handling and netlink interface") Signed-off-by: Jeremy Kerr Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260209-dev-mctp-nlmsg-v1-1-f1e30c346a43@codeconstruct.com.au Signed-off-by: Jakub Kicinski Signed-off-by: Li hongliang <1468888505@139.com> Signed-off-by: Sasha Levin commit 41845bc5bb64f3d615abe575ad655b5e7f193634 Author: Davide Caratti Date: Wed Apr 8 17:24:36 2026 +0200 net/sched: cls_fw: fix NULL dereference of "old" filters before change() [ Upstream commit 65782b2db7321d5f97c16718c4c7f6c7205a56be ] Like pointed out by Sashiko [1], since commit ed76f5edccc9 ("net: sched: protect filter_chain list with filter_chain_lock mutex") TC filters are added to a shared block and published to datapath before their ->change() function is called. This is a problem for cls_fw: an invalid filter created with the "old" method can still classify some packets before it is destroyed by the validation logic added by Xiang. Therefore, insisting with repeated runs of the following script: # ip link add dev crash0 type dummy # ip link set dev crash0 up # mausezahn crash0 -c 100000 -P 10 \ > -A 4.3.2.1 -B 1.2.3.4 -t udp "dp=1234" -q & # sleep 1 # tc qdisc add dev crash0 egress_block 1 clsact # tc filter add block 1 protocol ip prio 1 matchall \ > action skbedit mark 65536 continue # tc filter add block 1 protocol ip prio 2 fw # ip link del dev crash0 can still make fw_classify() hit the WARN_ON() in [2]: WARNING: ./include/net/pkt_cls.h:88 at fw_classify+0x244/0x250 [cls_fw], CPU#18: mausezahn/1399 Modules linked in: cls_fw(E) act_skbedit(E) CPU: 18 UID: 0 PID: 1399 Comm: mausezahn Tainted: G E 7.0.0-rc6-virtme #17 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Red Hat KVM, BIOS 1.16.3-2.el9 04/01/2014 RIP: 0010:fw_classify+0x244/0x250 [cls_fw] Code: 5c 49 c7 45 00 00 00 00 00 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 <0f> 0b 90 eb a0 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffd1b7026bf8a8 EFLAGS: 00010202 RAX: ffff8c5ac9c60800 RBX: ffff8c5ac99322c0 RCX: 0000000000000004 RDX: 0000000000000001 RSI: ffff8c5b74d7a000 RDI: ffff8c5ac8284f40 RBP: ffffd1b7026bf8d0 R08: 0000000000000000 R09: ffffd1b7026bf9b0 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000010000 R13: ffffd1b7026bf930 R14: ffff8c5ac8284f40 R15: 0000000000000000 FS: 00007fca40c37740(0000) GS:ffff8c5b74d7a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fca40e822a0 CR3: 0000000005ca0001 CR4: 0000000000172ef0 Call Trace: tcf_classify+0x17d/0x5c0 tc_run+0x9d/0x150 __dev_queue_xmit+0x2ab/0x14d0 ip_finish_output2+0x340/0x8f0 ip_output+0xa4/0x250 raw_sendmsg+0x147d/0x14b0 __sys_sendto+0x1cc/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x126/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fca40e822ba Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 RSP: 002b:00007ffc248a42c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055ef233289d0 RCX: 00007fca40e822ba RDX: 000000000000001e RSI: 000055ef23328c30 RDI: 0000000000000003 RBP: 000055ef233289d0 R08: 00007ffc248a42d0 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001e R13: 00000000000186a0 R14: 0000000000000000 R15: 00007fca41043000 irq event stamp: 1045778 hardirqs last enabled at (1045784): [] __up_console_sem+0x52/0x60 hardirqs last disabled at (1045789): [] __up_console_sem+0x37/0x60 softirqs last enabled at (1045426): [] __alloc_skb+0x207/0x260 softirqs last disabled at (1045434): [] __dev_queue_xmit+0x78/0x14d0 Then, because of the value in the packet's mark, dereference on 'q->handle' with NULL 'q' occurs: BUG: kernel NULL pointer dereference, address: 0000000000000038 [...] RIP: 0010:fw_classify+0x1fe/0x250 [cls_fw] [...] Skip "old-style" classification on shared blocks, so that the NULL dereference is fixed and WARN_ON() is not hit anymore in the short lifetime of invalid cls_fw "old-style" filters. [1] https://sashiko.dev/#/patchset/20260331050217.504278-1-xmei5%40asu.edu [2] https://elixir.bootlin.com/linux/v7.0-rc6/source/include/net/pkt_cls.h#L86 Fixes: faeea8bbf6e9 ("net/sched: cls_fw: fix NULL pointer dereference on shared blocks") Fixes: ed76f5edccc9 ("net: sched: protect filter_chain list with filter_chain_lock mutex") Acked-by: Jamal Hadi Salim Signed-off-by: Davide Caratti Link: https://patch.msgid.link/e39cbd3103a337f1e515d186fe697b4459d24757.1775661704.git.dcaratti@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0ca809ea8e0355299266c46e5f1755040aa8dcf3 Author: Greg Kroah-Hartman Date: Mon Apr 20 18:00:27 2026 +0200 Input: usbtouchscreen - clamp NEXIO data_len/x_len to URB buffer size commit 2905281cbda52ec9df540113b35b835feb5fafd3 upstream. nexio_read_data() pulls data_len and x_len from a packed __be16 header in the device's interrupt packet and then walks packet->data[0..x_len) and packet->data[x_len..data_len) comparing each byte against a threshold. Both fields are 16-bit on the wire (max 65535). The existing adjustments shave at most 0x100 / 0x80 off, so the loop bound can still reach roughly 0xfeff. The URB transfer buffer for NEXIO is rept_size (1024) bytes from usb_alloc_coherent(), with the first 7 occupied by the packed header — so packet->data[] has 1017 valid bytes. read_data() callbacks are not given urb->actual_length, and nothing else bounds the walk. A device that lies about its length can get a ~64 KiB out-of-bounds read past the coherent DMA allocation. The first index whose byte exceeds NEXIO_THRESHOLD lands in begin_x / begin_y and from there into the reported touch coordinates, so adjacent kernel memory contents leak to userspace as ABS_X / ABS_Y events. Far enough out, the read can also hit an unmapped page and fault. Fix this all by clamping data_len to the buffer's data[] capacity and x_len to data_len. Cc: Dmitry Torokhov Fixes: 5197424cdccc ("Input: usbtouchscreen - add NEXIO (or iNexio) support") Cc: stable Assisted-by: gkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2026042026-chlorine-epidermis-fd6d@gregkh Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 599f0b059dab281a35a14490217f8388c2158530 Author: Alexandre Frade Date: Tue Jun 2 13:21:33 2026 +0000 Linux 6.18.34-xanmod1 Signed-off-by: Alexandre Frade commit a17ef3eb3ae006b89c9f43fc13fd511c71828050 Merge: e469a636f608 18ad16ce4a6b Author: Alexandre Frade Date: Tue Jun 2 13:20:33 2026 +0000 Merge tag 'v6.18.34' into 6.18 This is the 6.18.34 stable release commit 18ad16ce4a6b2714583fd1e1044c6ea8e53b3519 Author: Greg Kroah-Hartman Date: Mon Jun 1 17:51:08 2026 +0200 Linux 6.18.34 Link: https://lore.kernel.org/r/20260528194638.371537336@linuxfoundation.org Tested-by: Ron Economos Tested-by: Miguel Ojeda Tested-by: Brett A C Sheffield Tested-by: Pavel Machek (CIP) Tested-by: Peter Schneider Tested-by: Wentao Guan Tested-by: Florian Fainelli Tested-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 50bb3435a5e627bfbdc52eb4536f49f88b3486b8 Author: Linus Torvalds Date: Thu May 28 11:45:41 2026 -0700 security/keys: fix missed RCU read section on lookup commit 43a1e3744548e6fd85873e6fb43e293eb4010694 upstream. Nicholas Carlini reports that the keyring code calls assoc_array_find() in find_key_to_update() without holding the RCU read lock, while the assoc_array_gc() code really is designed around removing the node from the tree and then freeing it after an RCU grace-period. The regular key handling doesn't see this because holding the keyring semaphore hides any lifetime issues, but the persistent key handling uses a different model. Instead of extending the keyring locking, just do the simple RCU locking that the assoc_array was designed for. Reported-by: Nicholas Carlini Cc: David Howells Cc: Jarkko Sakkinen Cc: Paul Moore Cc: James Morris James Morris Cc: Serge E. Hallyn Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 239172639075ef745ca233386086ba4b2b5077f8 Author: Nathan Chancellor Date: Mon May 18 15:17:14 2026 -0700 drm/msm: Restore second parameter name in purge() and evict() [ Upstream commit 53676e4d44d6b38c8a0d9bff331f170ae2e41bbe ] After commit 3392291fc509 ("drm/msm: Fix shrinker deadlock"), all supported versions of clang warn (or error with CONFIG_WERROR=y): drivers/gpu/drm/msm/msm_gem_shrinker.c:105:58: error: omitting the parameter name in a function definition is a C23 extension [-Werror,-Wc23-extensions] 105 | purge(struct drm_gem_object *obj, struct ww_acquire_ctx *) | ^ drivers/gpu/drm/msm/msm_gem_shrinker.c:117:58: error: omitting the parameter name in a function definition is a C23 extension [-Werror,-Wc23-extensions] 117 | evict(struct drm_gem_object *obj, struct ww_acquire_ctx *) | ^ 2 errors generated. With older but supported versions of GCC, this is an unconditional hard error: drivers/gpu/drm/msm/msm_gem_shrinker.c: In function 'purge': drivers/gpu/drm/msm/msm_gem_shrinker.c:105:35: error: parameter name omitted purge(struct drm_gem_object *obj, struct ww_acquire_ctx *) ^~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/msm/msm_gem_shrinker.c: In function 'evict': drivers/gpu/drm/msm/msm_gem_shrinker.c:117:35: error: parameter name omitted evict(struct drm_gem_object *obj, struct ww_acquire_ctx *) ^~~~~~~~~~~~~~~~~~~~~~~ Restore the parameter name to clear up the warnings, renaming it "unused" to make it clear it is only needed to satisfy the prototype of drm_gem_lru_scan(). Cc: stable@vger.kernel.org Fixes: 3392291fc509 ("drm/msm: Fix shrinker deadlock") Signed-off-by: Nathan Chancellor Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 306ba9d0e5aa98465c2d5588f91994fbdf95c4d6 Author: Tiezhu Yang Date: Fri May 22 15:05:07 2026 +0800 LoongArch: kprobes: Fix handling of fatal unrecoverable recursions [ Upstream commit 1c856e158fd34ef2c4475a81c1dc386329989938 ] KPROBE_HIT_SS and KPROBE_REENTER are two types of fatal recursions that can not be safely recovered in kprobes. KPROBE_HIT_SS means that a kprobe is hit during single-stepping. At this point, the architecture-specific single-step context is already active. Nested single-stepping would corrupt the state, as the kprobe control block (kcb) and hardware registers cannot safely store multiple levels of stepping state. KPROBE_REENTER means that a third-level recursion occurs when a probe is hit while the system is already handling a nested probe (second- level). The kcb only provides a single slot (prev_kprobe) to backup the state. When a third probe is hit, there is no more space to save the state without corrupting the first-level backup. Kprobes work by replacing instructions with breakpoints. In order to execute the original instruction and continue, it must be moved to a temporary "single-step" slot. Since there is no backup space left to set up this slot safely, the CPU would be forced to return to the same original breakpoint address, triggering an endless loop. Currently, the code only prints a warning and returns. This leads to an infinite re-entry loop as the CPU repeatedly hits the same trap and a "stuck" CPU core because preemption was disabled at the start of the handler and never re-enabled in this early return path. Fix the logic by: 1. Merging KPROBE_HIT_SS and KPROBE_REENTER cases, as both represent fatal recursions that cannot be safely recovered. 2. Replacing WARN_ON_ONCE() with BUG() to terminate the system. This aligns LoongArch with other architectures (x86, arm64, riscv) and prevents stack overflow while providing diagnostic information. Fixes: 6d4cc40fb5f5 ("LoongArch: Add kprobes support") Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit a1a39f227c80cbf369767badc32cba2b225147d1 Author: Junyi Liu Date: Mon May 18 23:27:19 2026 +0900 ksmbd: fix durable reconnect error path file lifetime [ Upstream commit 3515503322f4819277091839eed46b695096aca5 ] After a durable reconnect succeeds, ksmbd_reopen_durable_fd() republishes the same ksmbd_file into the session volatile-id table. If smb2_open() then takes a later error path, cleanup first calls ksmbd_fd_put(work, fp) and then unconditionally calls ksmbd_put_durable_fd(dh_info.fp). In this case fp and dh_info.fp are the same object. The first put drops the reconnect lookup reference, but the final durable put can run __ksmbd_close_fd(NULL, fp). Because the final close is not session-aware, it can free the file object without removing the volatile-id entry that was just published into the session table. Use the session-aware put for the final reconnect drop when the reconnect had already succeeded and the error path is cleaning up the republished file. Earlier reconnect failures, before fp is assigned to dh_info.fp, keep using the durable-only put path. Fixes: 1baff47b81f9 ("ksmbd: fix use-after-free in smb2_open during durable reconnect") Signed-off-by: Junyi Liu Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 6836f694126e5dfb44da4f77706ae29e45cc2e1e Author: Alexander A. Klimov Date: Wed May 20 20:00:44 2026 +0200 io_uring/nop: pass all errors to userspace [ Upstream commit e97ff8b62d4690c69297f0f6de874f0564cc01a4 ] This fixes an inconsistency where io_nop() called req_set_fail() based on ret, but passed just nop->result to userspace. Originally, ret is a even copy of nop->result, but is set to an error when such happens subsequently. Now that's also passed to userspace. Fixes: a85f31052bce ("io_uring/nop: add support for testing registered files and buffers") Signed-off-by: Alexander A. Klimov Link: https://patch.msgid.link/20260520180045.538533-1-grandmaster@al2klimov.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e334cbf3388fd9334503a778a82d9e9f14dd2f71 Author: Sabrina Dubroca Date: Wed May 20 22:44:42 2026 +0200 net: gro: don't merge zcopy skbs [ Upstream commit 4db79a322db8c97f7b73b8a347395ef4d685eb40 ] skb_gro_receive() can currently copy frags between the source and GRO skb, without checking the zerocopy status, and in particular the SKBFL_MANAGED_FRAG_REFS flag. When SKBFL_MANAGED_FRAG_REFS is set, the skb doesn't hold a reference on the pages in shinfo->frags. Appending those frags to another skb's frags without fixing up the page refcount can lead to UAF. When either the last skb in the GRO chain (the one we would append frags to) or the source skb is zerocopy, don't merge the skbs. Fixes: 753f1ca4e1e5 ("net: introduce managed frags infrastructure") Reported-by: Huzaifa Sidhpurwala Signed-off-by: Sabrina Dubroca Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/c3b7f906bbfcbdfd7b4fa9d6c18a438870df85be.1779307748.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8129611d4ede5c4b36a6b2649db140826fa0e569 Author: Nikhil P. Rao Date: Wed May 20 20:58:42 2026 +0000 pds_core: ensure null-termination for firmware version strings [ Upstream commit 3d4432d34c1992701289cbe12df9fd024f315998 ] The driver passes fw_version directly to devlink_info_version_stored_put() without ensuring null-termination. While current firmware null-terminates these strings, the driver should not rely on this behavior. Add explicit null-termination to prevent potential issues if firmware behavior changes. Fixes: 45d76f492938 ("pds_core: set up device and adminq") Signed-off-by: Nikhil P. Rao Link: https://patch.msgid.link/20260520205842.1486718-1-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d1d76bbb6d7af470fa57bf4888d4912109c72bd2 Author: Lorenzo Bianconi Date: Wed May 20 15:12:02 2026 +0200 net: airoha: Disable GDM2 forwarding before configuring GDM2 loopback [ Upstream commit 985d4a55e64e43bd86eeb896b81ceba453301989 ] Hw design requires to disable GDM2 forwarding before configuring GDM2 loopback in airoha_set_gdm2_loopback routine. Fixes: 9cd451d414f6e ("net: airoha: Add loopback support for GDM2") Tested-by: Madhur Agrawal Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260520-airoha-disable-gdm2-fwd-v1-1-1eeea5dffc2f@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 719007c3492f0f1f9e9cdbed8ac45ba45bb13eeb Author: Weiming Shi Date: Wed May 20 00:57:38 2026 -0700 tap: fix stack info leak in tap_ioctl() SIOCGIFHWADDR [ Upstream commit bddc09212c24934643bd44fc794748d2bbb3b6cd ] In the SIOCGIFHWADDR path, tap_ioctl() copies 16 bytes of an uninitialised on-stack struct sockaddr_storage to userspace via ifr_hwaddr, but netif_get_mac_address() only writes sa_family and dev->addr_len (6 for Ethernet) bytes, leaving sa_data[6..13] uninitialised. Those 8 trailing bytes leak kernel stack contents; SIOCGIFHWADDR on a macvtap chardev returns kernel .text and direct-map pointers, defeating KASLR. Initialise ss at declaration. Fixes: 3b23a32a6321 ("net: fix dev_ifsioc_locked() race condition") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260520075736.3415676-3-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fa627a5eaa83fc0261f44ef3769693b886ca6e27 Author: Aditya Garg Date: Tue May 19 22:15:53 2026 -0700 net: mana: validate rx_req_idx to prevent out-of-bounds array access [ Upstream commit b809d0409991b75a6cff846a5ac27c3062953f84 ] In mana_hwc_rx_event_handler(), rx_req_idx is derived from sge->address in DMA-coherent memory. In Confidential VMs (SEV-SNP/TDX), this memory is shared unencrypted and HW can modify WQE contents at any time. No bounds check exists on rx_req_idx, which can lead to an out-of-bounds access into reqs[]. Add bounds check on rx_req_idx in mana_hwc_rx_event_handler() before using it to index the reqs[] array. Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Signed-off-by: Aditya Garg Reviewed-by: Haiyang Zhang Link: https://patch.msgid.link/20260520051553.857120-1-gargaditya@linux.microsoft.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bc0020490f8890ea83950a1f1883c7c1898a8a35 Author: Ratheesh Kannoth Date: Wed May 20 10:00:36 2026 +0530 octeontx2-af: npc: Fix allmulticast skip logic for LBK and SDP VFs [ Upstream commit 9eddc819f00b5b74bb4ac91396f80bd35f5f3561 ] When installing the allmulticast NPC rule, rvu_npc_install_allmulti_entry() should skip LBK and SDP VFs (only CGX PF/VF may add the entry). The code combined is_lbk_vf() and is_sdp_vf() with logical AND, which is never true for a single pcifunc, so the intended early return never ran. Use logical OR instead. Cc: Geetha sowjanya Fixes: ae703539f49d2 ("octeontx2-af: Cleanup loopback device checks") Signed-off-by: Ratheesh Kannoth Link: https://patch.msgid.link/20260520043036.1523798-1-rkannoth@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 76dd50b7888d65956ca796d9b6cdd17a9001fb79 Author: Nimrod Oren Date: Wed May 20 18:39:28 2026 +0300 selftests: net: Fix checksums in xdp_native [ Upstream commit dfc077043351a81887d1e4c9ac244e9243f3cbf2 ] Data adjustment cases failed with "Data exchange failed" when using IPv4 because the program did not update the IP and UDP checksums in the IPv4 branch. The issue was masked when both IPv4 and IPv6 were configured, since the test harness prefers IPv6. While here, generalize csum_fold_helper() to fold twice so it works for any 32-bit input. Fixes: 0b65cfcef9c5 ("selftests: drv-net: Test tail-adjustment support") Reviewed-by: Carolina Jubran Reviewed-by: Dragos Tatulea Signed-off-by: Nimrod Oren Link: https://patch.msgid.link/20260520153928.3371765-1-noren@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 04ef7592eaadd9ca8f8f66e76452f73525cff819 Author: Shuicheng Lin Date: Thu May 14 20:32:10 2026 +0000 drm/xe/oa: Fix exec_queue leak on width check in stream open [ Upstream commit 4d25342543c01310fc4e0cba7cb17c775e2421e2 ] In xe_oa_stream_open_ioctl(), when param.exec_q->width > 1 the function returns -EOPNOTSUPP directly, skipping the existing err_exec_q cleanup path. The exec_queue reference obtained by xe_exec_queue_lookup() is leaked. The exec queue holds a reference on the xe_file, which is only dropped during queue teardown. The leaked lookup ref is not on the file's exec_queue xarray, so file close cannot release it. This keeps both the exec queue and the file private state pinned indefinitely. Jump to err_exec_q instead of returning directly so the reference is released. Fixes: f0ed39830e60 ("xe/oa: Fix query mode of operation for OAR/OAC") Assisted-by: Claude:claude-opus-4.6 Reviewed-by: Ashutosh Dixit Link: https://patch.msgid.link/20260514203210.593488-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin (cherry picked from commit 339fa0be9e4a5d69fa47e91f4a36574224fb478f) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit db86ac6d8dafea982967e1bde249df8545af67ac Author: Richard Fitzgerald Date: Thu May 21 13:30:57 2026 +0100 ASoC: cs35l56: Fix flushing of IRQ work in cs35l56_sdw_remove() [ Upstream commit 18e7bd9f2446664053f8c34b72abd4606d22d858 ] Use flush_work() instead of cancel_work_sync() to terminate pending IRQ work in cs35l56_sdw_remove(). And flush_work() again after masking the interrupts to flush any queueing that was racing with the masking. This is the same sequence as cs35l56_sdw_system_suspend(). cs35l56_sdw_interrupt() takes the pm_runtime to prevent the bus powering- down before the interrupt status can be read and handled. The work releases this pm_runtime. So cancelling it, instead of flushing, could leave an unbalanced pm_runtime. Signed-off-by: Richard Fitzgerald Fixes: e49611252900 ("ASoC: cs35l56: Add driver for Cirrus Logic CS35L56") Link: https://patch.msgid.link/20260521123057.988732-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit decacc6308c539db7b7152afd42b232aaf816ac9 Author: Bartosz Golaszewski Date: Mon May 18 11:53:18 2026 +0200 gpio: aggregator: lock device when calling device_is_bound() [ Upstream commit 598a2b3e2e0e6aa2e9f7843c96c45b5ea11e0411 ] The kerneldoc for device_is_bound() says it must be called with the device lock taken. Add missing synchronization to this driver. Fixes: 3a27f40b4570 ("gpio: aggregator: stop using dev-sync-probe") Link: https://patch.msgid.link/20260518-gpio-dev-lock-v1-2-cc4736f3ff0b@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 3e657619cf7258cb53b1beaf0d02998297695cde Author: Bartosz Golaszewski Date: Wed May 20 14:16:31 2026 +0200 gpio: aggregator: remove the software node when deactivating the aggregator [ Upstream commit 61fef83f239ecace1cce716135762a2d9b7b1fc6 ] The dynamic software node we create for the aggregator platform device when using configfs is leaked when the device is deactivated. Destroy it as the last step in the tear-down path. Fixes: 86f162e73d2d ("gpio: aggregator: introduce basic configfs interface") Reported-by: Geert Uytterhoeven Closes: https://lore.kernel.org/all/CAMuHMdVZ=XUvJTGdDAjnkxgtw7Uvnn61iOy3XN_5XNZM2anctw@mail.gmail.com/ Link: https://patch.msgid.link/20260520121631.33976-1-bartosz.golaszewski@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 80d94cf1773a367f6c83ffc2a09dfc01fdf64de7 Author: Bartosz Golaszewski Date: Fri Mar 27 11:31:12 2026 +0100 gpio: aggregator: stop using dev-sync-probe [ Upstream commit 3a27f40b457053e6112a63d14590e4a3ff553b44 ] dev-err-probe is an overengineered solution to a simple problem. Use a combination of wait_for_probe() and device_is_bound() to synchronously wait for the platform device to probe. Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260327-gpio-kill-dev-sync-probe-v1-2-efac254f1a1d@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski Stable-dep-of: 61fef83f239e ("gpio: aggregator: remove the software node when deactivating the aggregator") Signed-off-by: Sasha Levin commit ea28b286649b70618e9dd3e895812417a7712a11 Author: Bartosz Golaszewski Date: Wed May 20 10:49:11 2026 +0200 gpio: aggregator: fix a potential use-after-free [ Upstream commit 30c073cab97afb31901f94de9605177b6b84367e ] On error we free aggr->lookups->dev_id before removing the entry from the lookup table. If a concurrent thread calls gpiod_find() before we remove the entry, it could iterate over the list and call gpiod_match_lookup_table() which unconditionally dereferences dev_id when calling strcmp(). Reverse the order of cleanup. Fixes: 86f162e73d2d ("gpio: aggregator: introduce basic configfs interface") Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260520084911.27938-1-bartosz.golaszewski@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 4669f84adcb1e0567bd9c2e1cae827b63c53103b Author: Bartosz Golaszewski Date: Thu May 21 10:42:16 2026 +0200 gpio: cdev: check if uAPI v2 config attributes are correctly zeroed [ Upstream commit 3e6ccd790ed69bedd3d9626d01dd35cf9821c121 ] We check the padding of other uAPI v2 structures but not that of line config attributes. For used attributes: check if their padding is zeroed, for unused: check if the entire structure is zeroed. Fixes: 3c0d9c635ae2 ("gpiolib: cdev: support GPIO_V2_GET_LINE_IOCTL and GPIO_V2_LINE_GET_VALUES_IOCTL") Reviewed-by: Kent Gibson Link: https://patch.msgid.link/20260521-gpio-cdev-attr-padding-check-v3-1-ec3bcbe2e358@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit e47f7060eaf60894e3e4d0e3c4fe6e1f2eacfbdd Author: Eric Dumazet Date: Tue May 19 08:46:11 2026 +0000 tcp: fix stale per-CPU tcp_tw_isn leak enabling ISN prediction [ Upstream commit 1bbf0ced1d9db73ac7893c2187f3459288603e0d ] Blamed commit moved the TIME_WAIT-derived ISN from the skb control block to a per-CPU variable, assuming the value would always be consumed by tcp_conn_request() for the same packet that wrote it. That assumption is violated by multiple drop paths between the producer (__this_cpu_write(tcp_tw_isn, isn) in tcp_v{4,6}_rcv()) and the consumer (tcp_conn_request()): - min_ttl / min_hopcount check - xfrm policy check - tcp_inbound_hash() MD5/AO mismatch - tcp_filter() eBPF/SO_ATTACH_FILTER drop - th->syn && th->fin discard in tcp_rcv_state_process() TCP_LISTEN - psp_sk_rx_policy_check() in tcp_v{4,6}_do_rcv() - tcp_checksum_complete() in tcp_v{4,6}_do_rcv() - tcp_v{4,6}_cookie_check() returning NULL When a packet is dropped on any of these paths, tcp_tw_isn is left set. The next SYN processed on the same CPU then consumes the non zero value in tcp_conn_request(), receiving a potentially predictable ISN. This patch moves back tcp_tw_isn to skb->cb[], getting rid of the per-cpu variable. Note that tcp_v{4,6}_fill_cb() do not set it. Very litle impact on overall code size/complexity: $ scripts/bloat-o-meter -t vmlinux.old vmlinux.new add/remove: 0/0 grow/shrink: 2/1 up/down: 8/-15 (-7) Function old new delta tcp_v6_rcv 3038 3042 +4 tcp_v4_rcv 3035 3039 +4 tcp_conn_request 2938 2923 -15 Total: Before=24436060, After=24436053, chg -0.00% Fixes: 41eecbd712b7 ("tcp: replace TCP_SKB_CB(skb)->tcp_tw_isn with a per-cpu field") Reported-by: Chris Mason Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260519084611.2485277-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1861d369efd62d67796563bf3e01fc22e5626f8b Author: Xingwang Xiang Date: Sun May 17 23:56:26 2026 +0900 bpf, skmsg: fix verdict sk_data_ready racing with ktls rx [ Upstream commit ddf8029623a1af20e984c040e89ff918158397ab ] sk_psock_strp_data_ready() already checks tls_sw_has_ctx_rx() and defers to psock->saved_data_ready when a TLS RX context is present, avoiding a conflict with the TLS strparser's ownership of the receive queue (commit e91de6afa81c, "bpf: Fix running sk_skb program types with ktls"). sk_psock_verdict_data_ready() has no equivalent guard. When a socket is inserted into a sockmap (BPF_SK_SKB_VERDICT) before TLS RX is configured, tls_sw_strparser_arm() saves sk_psock_verdict_data_ready as rx_ctx->saved_data_ready. On data arrival: tls_data_ready -> tls_strp_data_ready -> tls_rx_msg_ready -> saved_data_ready() = sk_psock_verdict_data_ready() -> tcp_read_skb() drains sk_receive_queue via __skb_unlink() without calling tcp_eat_skb(), so copied_seq is not advanced. tls_strp_msg_load() then finds tcp_inq() >= full_len (stale), calls tcp_recv_skb() on the now-empty queue, hits WARN_ON_ONCE(!first), and returns with rx_ctx->strp.anchor.frag_list pointing at a psock-owned (potentially freed) skb. tls_decrypt_sg() subsequently walks that frag_list: use-after-free. Apply the same fix as sk_psock_strp_data_ready(): if a TLS RX context is present, call psock->saved_data_ready (sock_def_readable) to wake recv() waiters and return immediately, leaving the receive queue untouched. TLS retains sole ownership of the queue and decrypts the record normally through tls_sw_recvmsg(). Fixes: ef5659280eb1 ("bpf, sockmap: Allow skipping sk_skb parser program") Signed-off-by: Xingwang Xiang Link: https://patch.msgid.link/20260517145630.20521-2-v3rdant.xiang@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 26f1d4522060ee1f16f1165d29a7aa2926bd21ff Author: Rosen Penev Date: Sat May 16 14:26:16 2026 -0700 net: ag71xx: check error for platform_get_irq [ Upstream commit e7c70bf97e90d974cd575e4c90f8f9b07d056da3 ] Complete error handling for a failed platform_get_irq() call Fixes: d51b6ce441d3 ("net: ethernet: add ag71xx driver") Signed-off-by: Rosen Penev Reviewed-by: Oleksij Rempel Link: https://patch.msgid.link/20260516212616.11758-1-rosenp@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 585f9f6aef5c4542ac9d6ec45cd7dbc7df9af3ff Author: David Howells Date: Sat May 16 00:05:13 2026 +0100 crypto/krb5, rxrpc: Fix lack of pre-decrypt/pre-verify length checks [ Upstream commit 2b50aceafe6606ea52ed42aadd1b4d44a188aade ] Change the krb5 crypto library to provide facilities to precheck the length of the message about to be decrypted or verified. Fix AF_RXRPC to make use of this to validate DATA packets secured with RxGK. Fixes: 9d1d2b59341f ("rxrpc: rxgk: Implement the yfs-rxgk security class (GSSAPI)") Closes: https://sashiko.dev/#/patchset/20260511160753.607296-1-dhowells%40redhat.com Signed-off-by: David Howells cc: Herbert Xu cc: Simon Horman cc: Chuck Lever cc: linux-afs@lists.infradead.org Reviewed-by: Jeffrey Altman Tested-by: Marc Dionne Link: https://patch.msgid.link/20260515230516.2718212-2-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2417df5e7bb4184b9d3a2988036bf2c46e594545 Author: Jakub Kicinski Date: Fri May 15 15:13:25 2026 -0700 net: shaper: rework the VALID marking (again) [ Upstream commit b8d7519352ba8c6df83259295d4a3bad093cae90 ] Recent commit changed the semantics from NOT_VALID to VALID. I didn't realize that the flags are not stored atomically with the entry in XArray. There's still a race of reader observing a VALID mark for a slot, getting interrupted, writer replacing the entry with a different one, reader continuing, fetching the entry which is now a different pointer than the pointer for which VALID was meant. The biggest consequence of this is that we may see a UAF since net_shaper_rollback() assumed that entries without VALID can be freed without observing RCU. Looks like the XArray marks are buying us nothing at this point. Let's convert the code to an explicit valid field. The smp_load_acquire() / smp_store_release() barriers are marginally cleaner. Reported-by: Sashiko Fixes: 93954b40f6a4 ("net-shapers: implement NL set and delete operations") Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260515221325.1685455-3-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5a2c2aa139c8da2dcda0bd24d415fa7471bf693b Author: Jakub Kicinski Date: Fri May 15 15:13:24 2026 -0700 net: shaper: annotate the data races [ Upstream commit a3442936dd0523277e20aaf86207c574e755c634 ] As previously discussed we don't care about making the shaper state fully RCU-compliant because the hierarchy itself can't be dumped in one go over Netlink. Let's annotate the reads and writes to make that clear. The field-by-field assignments will also be useful for the next commit which adds explicit "valid" field (which we don't want to override with the current full struct assignment). Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260515221325.1685455-2-kuba@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: b8d7519352ba ("net: shaper: rework the VALID marking (again)") Signed-off-by: Sasha Levin commit b5bd4249e430f5963d559708ee96a671716d2400 Author: Prathamesh Deshpande Date: Sun May 10 23:59:00 2026 +0100 net/mlx5e: Fix eswitch mode block underflow on IPsec acquire SA [ Upstream commit abe003b33223ff33552f291644bf35d9c2f992fb ] mlx5e_xfrm_add_state() handles acquire-flow temporary SAs by allocating software state and skipping hardware offload setup. That path jumps to the common success label before taking the eswitch mode block. After tunnel-mode validation was moved earlier, the common success label unconditionally calls mlx5_eswitch_unblock_mode(). For acquire SAs, this decrements esw->offloads.num_block_mode without a matching increment. Return directly after installing the acquire SA offload handle, so only the paths that successfully called mlx5_eswitch_block_mode() call the matching unblock. Fixes: 22239eb258bc ("net/mlx5e: Prevent tunnel reformat when tunnel mode not allowed") Signed-off-by: Prathamesh Deshpande Reviewed-by: Simon Horman Reviewed-by: Tariq Toukan Link: https://patch.msgid.link/20260510225903.13184-1-prathameshdeshpande7@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a0f5268c77eb73f84ba7c210ddfc54b1c73ff80c Author: Jiajia Liu Date: Mon May 18 10:24:02 2026 +0800 Bluetooth: btmtk: fix urb->setup_packet leak in error paths [ Upstream commit dd1dda6b8d6e1f4376a5b3055a04f0ecbdb4d6bd ] The setup_packet of control urb is not freed if usb_submit_urb fails or the submitted urb is killed. Add free in these two paths. Fixes: a1c49c434e150 ("Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices") Signed-off-by: Jiajia Liu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit c7860b6a6d2d69d18566f10dfa8751c874b23ef1 Author: Kiran K Date: Fri May 15 00:32:48 2026 +0530 Bluetooth: btintel_pcie: Fix incorrect MAC access programming [ Upstream commit 88365d04fdc821dc4e9eb0cc00fdf6905430d172 ] btintel_pcie_get_mac_access() and btintel_pcie_release_mac_access() were programming STOP_MAC_ACCESS_DIS and XTAL_CLK_REQ in addition to the MAC_ACCESS_REQ handshake. These bits are not part of the host MAC-access handshake on the supported parts; the driver was programming them incorrectly. Drop the writes so the register update contains only the bits the controller actually consumes. Fixes: b9465e6670a2 ("Bluetooth: btintel_pcie: Read hardware exception data") Signed-off-by: Kiran K Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit d6c8b3ebdcdb12b59ad4212acb137cc56cae453d Author: David Carlier Date: Fri May 8 20:57:47 2026 +0100 tracing: Avoid NULL return from hist_field_name() on truncation [ Upstream commit 576ec047d20b368b43c4d5db98c4f2e0f3c101ec ] hist_field_name() returns "" everywhere except the fully-qualified VAR_REF/EXPR case, where snprintf() truncation returns NULL early and bypasses the bottom NULL->"" guard. Callers don't expect NULL: strcat(expr, hist_field_name(field, 0)) at trace_events_hist.c:1758 and the strcmp() in the sort-key match loop at :4804 both deref it. system and event_name are bounded by MAX_EVENT_NAME_LEN, but the field name on a VAR_REF is kstrdup'd from a histogram variable name parsed out of the trigger string and has no length cap, so a long enough var name in a fully qualified reference can reach the truncation path. Keep the length check but leave field_name as "" on overflow. Link: https://patch.msgid.link/20260508195747.25492-1-devnexen@gmail.com Fixes: 5ec1d1e97de1 ("tracing: Rebuild full_name on each hist_field_name() call") Signed-off-by: David Carlier Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 8bf00d3ac425ac0df1c0b2a82e32cdd9789964c3 Author: Cunlong Li Date: Wed May 20 11:30:54 2026 +0800 cgroup: rstat: relax NMI guard after switch to try_cmpxchg [ Upstream commit 22572dbcd3486e6c4dced877125bbf50e4e24edf ] Commit 36df6e3dbd7e ("cgroup: make css_rstat_updated nmi safe") used this_cpu_cmpxchg() for the lockless insertion, and therefore required both ARCH_HAVE_NMI_SAFE_CMPXCHG and ARCH_HAS_NMI_SAFE_THIS_CPU_OPS in the NMI guard: on archs without the latter, this_cpu_cmpxchg() falls back to "local_irq_save() + plain cmpxchg", and local_irq_save() cannot mask NMIs. Commit 3309b63a2281 ("cgroup: rstat: use LOCK CMPXCHG in css_rstat_updated") later replaced this_cpu_cmpxchg() with plain try_cmpxchg() to fix cross-CPU lockless-list corruption, but left the NMI guard untouched. After that switch, css_rstat_updated() no longer performs any this_cpu_*() RMW operations and only relies on the arch having NMI-safe cmpxchg, so ARCH_HAS_NMI_SAFE_THIS_CPU_OPS is no longer required in the guard. Relax the guard accordingly so that archs which have HAVE_NMI and ARCH_HAVE_NMI_SAFE_CMPXCHG but not ARCH_HAS_NMI_SAFE_THIS_CPU_OPS (e.g. sparc, powerpc on PPC64/BOOK3S) can benefit from the existing CONFIG_MEMCG_NMI_SAFETY_REQUIRES_ATOMIC path. Without this, the css is never queued in NMI on those archs, and the atomics staged by account_{slab,kmem}_nmi_safe() are not drained by flush_nmi_stats(). Fixes: 3309b63a2281 ("cgroup: rstat: use LOCK CMPXCHG in css_rstat_updated") Signed-off-by: Cunlong Li Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 3aab4a58d23fb22dac5b558bbe5df1a8dad00b4b Author: Zhang Cen Date: Wed May 20 18:32:49 2026 +0800 ALSA: seq: Serialize UMP output teardown with event_input [ Upstream commit 60a1969fae6209644698fca91c185d153674f631 ] seq_ump_process_event() borrows client->out_rfile.output without synchronizing with the first-open and last-close transition in seq_ump_client_open() and seq_ump_client_close(). The last output unuse can therefore drop opened[STR_OUT] to zero and release the rawmidi file while an in-flight event_input callback is still inside snd_rawmidi_kernel_write(). That leaves the rawmidi substream runtime exposed to teardown before the write path has taken its own buffer reference. Add a per-client rwlock for the event_input-visible output file. Publish a newly opened output file under the write side, and hold the read side from the output lookup through snd_rawmidi_kernel_write(). The last output close copies and clears the visible output file under the write side, then drops the lock and releases the saved rawmidi file. Use IRQ-safe rwlock guards because event_input can also be reached from atomic sequencer delivery. The buggy scenario involves two paths, with each column showing the order within that path: path A label: event_input path path B label: last unuse path 1. seq_ump_process_event() reads 1. seq_ump_client_close() client->out_rfile.output. drops opened[STR_OUT] to zero. 2. snd_rawmidi_kernel_write1() 2. snd_rawmidi_kernel_release() has not yet pinned runtime. closes the output file. 3. The writer continues using 3. close_substream() frees the borrowed substream. substream->runtime. This keeps the output substream and runtime alive for the full event_input write while keeping rawmidi release outside the rwlock. KASAN reproduced this as a slab-use-after-free in snd_rawmidi_kernel_write1(), with allocation through seq_ump_use()/snd_seq_port_connect() and free through seq_ump_unuse()/snd_seq_port_disconnect(). Suggested-by: Takashi Iwai Validation reproduced this kernel report: KASAN slab-use-after-free in snd_rawmidi_kernel_write1+0x9d/0x400 RIP: 0033:0x7f5528af837f Read of size 8 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_rawmidi_kernel_write1+0x9d/0x400 (?:?) __asan_load8+0x82/0xb0 (?:?) update_stack_state+0x1ef/0x2d0 (?:?) snd_rawmidi_kernel_write+0x1a/0x20 (?:?) seq_ump_process_event+0xd4/0x120 (sound/core/seq/seq_ump_client.c:82) __snd_seq_deliver_single_event+0x8a/0xe0 (?:?) snd_seq_deliver_from_ump+0x2b2/0xd60 (?:?) lock_acquire+0x14e/0x2e0 (?:?) find_held_lock+0x31/0x90 (?:?) snd_seq_port_use_ptr+0xa6/0xe0 (?:?) __kasan_check_write+0x18/0x20 (?:?) do_raw_read_unlock+0x32/0xa0 (?:?) _raw_read_unlock+0x26/0x50 (?:?) snd_seq_deliver_single_event+0x45c/0x4b0 (?:?) snd_seq_deliver_event+0x10d/0x1b0 (?:?) snd_seq_client_enqueue_event+0x192/0x240 (?:?) snd_seq_write+0x2cd/0x450 (?:?) apparmor_file_permission+0x20/0x30 (?:?) security_file_permission+0x51/0x60 (?:?) vfs_write+0x1ce/0x850 (?:?) __fget_files+0x12b/0x220 (?:?) lock_release+0xc8/0x2a0 (?:?) __rcu_read_unlock+0x74/0x2d0 (?:?) __fget_files+0x135/0x220 (?:?) ksys_write+0x15a/0x180 (?:?) rcu_is_watching+0x24/0x60 (?:?) __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: 81fd444aa371 ("ALSA: seq: Bind UMP device") Signed-off-by: Zhang Cen Link: https://patch.msgid.link/20260520103249.3048345-1-rollkingzzc@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 95c82d498d74c4e587db30021ca1aec90e29b5a5 Author: Shitalkumar Gandhi Date: Mon May 11 09:57:32 2026 +0530 wifi: wilc1000: fix dma_buffer leak on bus acquire failure [ Upstream commit dd7b6a8671939708cc4b7a46786d8c11297e8f69 ] wilc_wlan_firmware_download() allocates dma_buffer with kmalloc() at the top of the function and uses a 'fail:' label to free it via kfree(dma_buffer) on error. All later error paths correctly use 'goto fail' to route through this cleanup. However, the early failure path after the first acquire_bus() call uses a bare 'return ret;', which leaks dma_buffer whenever the bus acquire fails. Replace the early return with goto fail so the existing cleanup path runs. Found via a custom Coccinelle semantic patch hunting for kmalloc'd locals leaked on early-return error paths in driver firmware-download code. Fixes: 1241c5650ff7 ("wifi: wilc1000: Fill in missing error handling") Signed-off-by: Shitalkumar Gandhi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260511042732.998311-1-shitalkumar.gandhi@cambiumnetworks.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 55c479aae99b120489a432db9c717484e523dfd6 Author: Johannes Berg Date: Fri May 8 09:10:31 2026 +0200 wifi: mac80211: fix MLE defragmentation [ Upstream commit a74e893f30db64cdce0fc7a96d3baa417bcd55f5 ] If either reconf or EPCS multi-link element (MLE) is contained in a non-transmitted profile, the defragmentation routine is called with a pointer to the defragmented copy, but the original elements. This is incorrect for two reasons: - if the original defragmentation was needed, it will not find the correct data - if the original frame is at a higher address, the parsing will potentially overrun the heap data (though given the layout of the buffers, only into the new defragmentation buffer, and then it has to stop and fail once that's filled with copied data. Fix it by tracking the container along with the pointer and in doing so also unify the two almost identical defragmentation routines. Fixes: 4d70e9c5488d ("wifi: mac80211: defragment reconfiguration MLE when parsing") Reviewed-by: Miriam Rachel Korenblit Reviewed-by: Ilan Peer Link: https://patch.msgid.link/20260508091031.8a6c34613178.I4de16ebbce2d27f2f8f98fc49949c7a376c2fe8d@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 2d8379834800c30602f24c71ab7c40f5fe84d200 Author: Alexandru Hossu Date: Fri May 15 12:29:08 2026 +0200 wifi: mac80211: bounds-check link_id in ieee80211_ml_epcs [ Upstream commit f718506edd2d9c6a308ded9d13c632bf7b7d5a2c ] IEEE80211_MLE_STA_EPCS_CONTROL_LINK_ID is 0x000f, so link_id extracted from a PRIO_ACCESS ML element PER_STA_PROFILE subelement can be 0..15. sdata->link[] has IEEE80211_MLD_MAX_NUM_LINKS (15) entries (indices 0..14), making index 15 out-of-bounds. A connected WiFi 7 AP can trigger this by sending an EPCS Enable Response action frame with a PER_STA_PROFILE subelement where link_id = 15. The unsolicited-notification path (dialog_token = 0) is reachable any time EPCS is already enabled, without any prior client request. sdata->link[15] reads into the first word of sdata->activate_links_work (a wiphy_work whose embedded list_head is non-NULL after INIT_LIST_HEAD), so the NULL check on the result does not catch the invalid access. The garbage pointer is then passed to ieee80211_sta_wmm_params(), which dereferences link->sdata and crashes the kernel. The same class of bug was fixed for ieee80211_ml_reconfiguration() by commit 162d331d833d ("wifi: mac80211: bounds-check link_id in ieee80211_ml_reconfiguration"). Fixes: de86c5f60839 ("wifi: mac80211: Add support for EPCS configuration") Signed-off-by: Alexandru Hossu Link: https://patch.msgid.link/20260515102908.1653088-1-hossu.alexandru@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 425d32d6288d7d845e486af9419bbedccd8c9103 Author: Gao Xiang Date: Tue Apr 28 12:34:31 2026 +0800 erofs: fix managed cache race for unaligned extents [ Upstream commit 649932fc3815eda2f24eb4de4b3a5e94886ee0b9 ] After unaligned compressed extents were introduced, the following race could occur: [Thread 1] [Thread 2] (z_erofs_fill_bio_vec) ... filemap_add_folio (1) (z_erofs_bind_cache) .. .. folio_attach_private (2) filemap_add_folio (3) again Since (1) is executed but (2) hasn't been executed yet, it's possible that another thread finds the same managed folio in z_erofs_bind_cache() for a different pcluster and calls filemap_add_folio() again since folio->private is still Z_EROFS_PREALLOCATED_FOLIO. Fix this by explicitly clearing folio->private before making the folio visible in the managed cache so that another pcluster can simply wait on the locked managed folio as what we did for other shared cases [1]. This only impacts unaligned data compression (`-E48bit` with zstd, for example). [1] Commit 9e2f9d34dd12 ("erofs: handle overlapped pclusters out of crafted images properly") was originally introduced to handle crafted overlapped extents, but it addresses unaligned extents as well. Fixes: 7361d1e3763b ("erofs: support unaligned encoded data") Reported-by: Arseniy Krasnov Closes: https://lore.kernel.org/r/4a2f3801-fac1-42fe-ae75-da315822e088@salutedevices.com Tested-by: Arseniy Krasnov Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 91d13e92b983e6c6d7631012c2e20ae8057de9f2 Author: Nikhil P. Rao Date: Fri May 15 21:29:07 2026 +0000 pds_core: fix debugfs_lookup dentry leak and error handling [ Upstream commit dc416e32baaeb620b9809e9e25fc7b30889686e9 ] debugfs_lookup() returns a dentry with an elevated reference count that must be released with dput(). The current code discards the returned dentry without calling dput(), causing a reference leak on every firmware reset recovery. Additionally, when CONFIG_DEBUG_FS is disabled, debugfs_lookup() returns ERR_PTR(-ENODEV), not NULL. The current check passes for error pointers and would call dput() on an invalid pointer, causing a crash. Fixes: bc90fbe0c318 ("pds_core: Rework teardown/setup flow to be more common") Signed-off-by: Nikhil P. Rao Link: https://patch.msgid.link/20260515212907.998028-3-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 784dd2bdc622ed3cc6ef8e113aa1852e252de36f Author: Nikhil P. Rao Date: Fri May 15 21:29:05 2026 +0000 pds_core: fix error handling in pdsc_devcmd_wait [ Upstream commit 0e46b6635b03d29807f810c3b415c4755a3f958d ] Fix two cases where pdsc_devcmd_wait() returns stale success from the completion register instead of an error: 1. FW crash: If firmware stops running, the wait loop breaks early with running=false. The condition "if ((!done || timeout) && running)" is false, so error handling is bypassed and stale status is returned. Check !running first and return -ENXIO. 2. Timeout: If a command times out, err is set to -ETIMEDOUT but then overwritten by pdsc_err_to_errno(status) which reads stale status. Return -ETIMEDOUT immediately after cleaning up. Both errors now propagate to pdsc_devcmd_locked() which queues health_work for recovery. Fixes: 45d76f492938 ("pds_core: set up device and adminq") Signed-off-by: Nikhil P. Rao Link: https://patch.msgid.link/20260515212907.998028-1-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ce23832071aff284dc928775c0f8042c50b35cba Author: Christian Marangi Date: Mon May 18 15:44:57 2026 +0200 net: airoha: Fix NPU RX DMA descriptor bits [ Upstream commit 0cb5a74faa3bdcfa3b18735d554e12c0f615e35d ] In an internal review from Airoha, it was notice that the RX DMA descriptor bits and mask are wrong. These values probably refer to an old NPU firmware never published. The previous value works correctly but it was reported that in some specific condition in mixed scenario with both Ethernet and WiFi offload it's possible that RX DMA descriptor signal wrong value with the problem to the RX ring or packets getting dropped. To handle these specific scenario, apply the new suggested bits mask from Airoha. Correct functionality of both AN7581 NPU and MT7996 variant were verified and confirmed working. Fixes: a7fc8c641cab ("net: airoha: Fix npu rx DMA definitions") Signed-off-by: Christian Marangi Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260518134530.3683-1-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0c277d203684c27bff62d6bd997a9fd77c88884f Author: Nicolai Buchwitz Date: Mon May 18 10:23:10 2026 +0200 net: phy: honor eee_disabled_modes in phy_advertise_eee_all() [ Upstream commit 8baa7506d793f0636e3f6f01b01ef7be19674d06 ] phy_advertise_eee_all() copies supported_eee into advertising_eee unconditionally, overwriting any filtering applied during phy_probe() based on DT eee-broken-* properties or driver-populated eee_disabled_modes. genphy_c45_ethtool_set_eee() calls this helper when user space passes an empty advertisement, undoing the filtering. Apply the same eee_disabled_modes mask in phy_advertise_eee_all() so the filtering survives the copy, matching the pattern in phy_probe() and phy_support_eee(). Fixes: b64691274f5d ("net: phy: add helper phy_advertise_eee_all") Signed-off-by: Nicolai Buchwitz Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260518-devel-phy-support-eee-fix-v2-2-05b52626fa68@tipi-net.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bd731994cff13aba2a1786f5b5c2c042f6d903d1 Author: Nicolai Buchwitz Date: Mon May 18 10:23:09 2026 +0200 net: phy: honor eee_disabled_modes in phy_support_eee() [ Upstream commit 3655063e083889ed4b79b7dda9cec65478dce09a ] phy_support_eee() copies supported_eee into advertising_eee unconditionally, overwriting any filtering applied during phy_probe() based on DT eee-broken-* properties or driver-populated eee_disabled_modes. MAC drivers that call phy_support_eee() after probe (e.g. bcmgenet, fec, lan743x, lan78xx, r8169) then cause the PHY to advertise EEE for modes the user marked as broken. The symptom is that ethtool --show-eee on the local interface reports "not supported" (supported & ~eee_disabled_modes is empty) while the link partner sees EEE negotiated and active. phy_probe() already filters advertising_eee via eee_disabled_modes after calling of_set_phy_eee_broken(). Apply the same mask in phy_support_eee() so the filtering survives the copy. Fixes: 49168d1980e2 ("net: phy: Add phy_support_eee() indicating MAC support EEE") Signed-off-by: Nicolai Buchwitz Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260518-devel-phy-support-eee-fix-v2-1-05b52626fa68@tipi-net.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a9224862d597d0eed0a34bbb27343f703fc4113f Author: Ido Schimmel Date: Sun May 17 15:11:21 2026 +0300 bridge: mcast: Fix a possible use-after-free when removing a bridge port [ Upstream commit 4df78ff02629c7729168f0696a7a2123c389818d ] When per-VLAN multicast snooping is enabled, the bridge iterates over all the bridge ports, disables the per-port multicast context on each port and enables the per-{port, VLAN} multicast contexts instead. The reverse happens when per-VLAN multicast snooping is disabled. When global multicast snooping is enabled, the bridge iterates over all the bridge ports and enables the per-port multicast context on each port. The reverse happens when multicast snooping is disabled. The above scheme can result in a situation where both types of contexts (per-port and per-{port, VLAN}) are enabled on a single bridge port: # ip link add name br1 up type bridge mcast_snooping 1 mcast_querier 1 vlan_filtering 1 # ip link add name dummy1 up master br1 type dummy # ip link set dev br1 type bridge mcast_vlan_snooping 1 # ip link set dev br1 type bridge mcast_snooping 0 # ip link set dev br1 type bridge mcast_snooping 1 This is not intended and it is a problem since the commit cited below. Prior to this commit, when removing a bridge port, br_multicast_disable_port() would disable the per-port multicast context and the per-{port, VLAN} multicast contexts would get disabled when flushing VLANs. After this commit, br_multicast_disable_port() only disables the per-port multicast context if per-VLAN multicast snooping is disabled. If both types of contexts were enabled on the port when it was removed, the per-port multicast context would remain enabled when freeing the bridge port, leading to a use-after-free [1]. Fix by preventing the bridge from enabling / disabling the per-port multicast contexts when toggling global multicast snooping if per-VLAN multicast snooping is enabled. [1] ODEBUG: free active (active state 0) object: ffff88810f8bda78 object type: timer_list hint: br_ip6_multicast_port_query_expired (net/bridge/br_multicast.c:1927) WARNING: lib/debugobjects.c:629 at debug_print_object+0x1b1/0x3e0, CPU#5: swapper/5/0 [...] Call Trace: __debug_check_no_obj_freed (lib/debugobjects.c:1116) kfree (mm/slub.c:2620 mm/slub.c:6250 mm/slub.c:6565) kobject_cleanup (lib/kobject.c:689) rcu_do_batch (kernel/rcu/tree.c:2617) rcu_core (kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) __irq_exit_rcu (kernel/softirq.c:656 kernel/softirq.c:496 kernel/softirq.c:735) irq_exit_rcu (kernel/softirq.c:752) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1061 (discriminator 47) arch/x86/kernel/apic/apic.c:1061 (discriminator 47)) Fixes: 4b30ae9adb04 ("net: bridge: mcast: re-implement br_multicast_{enable, disable}_port functions") Reported-by: syzbot+ae231e0552fa77b26ea1@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/87qznowlfs.ffs@tglx/ Reported-by: Thomas Gleixner Acked-by: Nikolay Aleksandrov Signed-off-by: Ido Schimmel Link: https://patch.msgid.link/20260517121122.188333-2-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 981aea2099770509aa41969c179afe52f87d20da Author: Petr Machata Date: Thu Oct 23 16:45:37 2025 +0200 net: bridge: Flush multicast groups when snooping is disabled [ Upstream commit 68800bbf583f26f71491141e4b3c8582f9cfcbde ] When forwarding multicast packets, the bridge takes MDB into account when IGMP / MLD snooping is enabled. Currently, when snooping is disabled, the MDB is retained, even though it is not used anymore. At the same time, during the time that snooping is disabled, the IGMP / MLD control packets are obviously ignored, and after the snooping is reenabled, the administrator has to assume it is out of sync. In particular, missed join and leave messages would lead to traffic being forwarded to wrong interfaces. Keeping the MDB entries around thus serves no purpose, and just takes memory. Note also that disabling per-VLAN snooping does actually flush the relevant MDB entries. This patch flushes non-permanent MDB entries as global snooping is disabled. Signed-off-by: Petr Machata Reviewed-by: Ido Schimmel Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/5e992df1bb93b88e19c0ea5819e23b669e3dde5d.1761228273.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski Stable-dep-of: 4df78ff02629 ("bridge: mcast: Fix a possible use-after-free when removing a bridge port") Signed-off-by: Sasha Levin commit eae62c5451e67e8b033c1681fd3b85d7e9a9a28f Author: Guangshuo Li Date: Thu May 14 19:38:34 2026 +0800 RDMA/rtrs: Fix use-after-free in path file creation cleanup [ Upstream commit 5b74373390113fba798a76b483837029ab010fef ] In the error path of rtrs_srv_create_path_files(), the sysfs root folders may already have been created and srv_path->kobj may already have been initialized. If a later step fails, the cleanup currently calls kobject_put(&srv_path->kobj) before rtrs_srv_destroy_once_sysfs_root_folders(srv_path). kobject_put() may drop the last reference to srv_path->kobj and invoke the release callback, rtrs_srv_release(), which frees srv_path. The following call to rtrs_srv_destroy_once_sysfs_root_folders(srv_path) then dereferences srv_path internally to access srv_path->srv, resulting in a use-after-free. This failure path is reached before rtrs_srv_create_path_files() returns success, so the successful-path lifetime handling is not involved. Fix this by destroying the sysfs root folders before calling kobject_put(&srv_path->kobj), so srv_path is still valid while the helper accesses it. This issue was found by a static analysis tool I am developing. Fixes: ae4c81644e91 ("RDMA/rtrs-srv: Rename rtrs_srv_sess to rtrs_srv_path") Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260514113834.865530-1-lgs201920130244@gmail.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 8c63698737b4bdf333c3a2920f29988ee06eb19e Author: Shiraz Saleem Date: Tue May 12 02:42:09 2026 -0700 RDMA/mana_ib: Report max_msg_sz in mana_ib_query_port [ Upstream commit c9a40f6531b81baa9619bcc2697ff86896afcce7 ] Report max_msg_sz for mana_ib, which is 16MB. Fixes: 4bda1d5332ec ("RDMA/mana_ib: Implement port parameters") Signed-off-by: Shiraz Saleem Signed-off-by: Konstantin Taranov Link: https://patch.msgid.link/20260512094209.264955-1-kotaranov@linux.microsoft.com Reviewed-by: Long Li Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit d5b11e15ee676438a93a45b854a19b2177011084 Author: Robertus Diawan Chris Date: Tue May 19 12:40:24 2026 +0700 ASoC: soc-utils: Add missing va_end in snd_soc_ret() [ Upstream commit 298a43b54432fbc3a32949a94c72544ee18c8c00 ] The default case in snd_soc_ret() use va_start without va_end to cleanup "args" object which can cause undefined behavior. So, add missing va_end to cleanup "args" object. This is reported by Coverity Scan as "Missing varargs init or cleanup". Fixes: 943116ba2a6a ("ASoC: add common snd_soc_ret() and use it") Signed-off-by: Robertus Diawan Chris Link: https://patch.msgid.link/20260519054024.274741-1-robertusdchris@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 09deb063eecf43b91b04401f7452c58f1b9cd453 Author: Rafael J. Wysocki Date: Tue May 12 17:16:22 2026 +0200 platform/x86: intel-vbtn: Check ACPI_HANDLE() against NULL [ Upstream commit a9f305c5a355efeb240d406d378491d9eec02d07 ] 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_HANDLE() check against NULL to the platform/x86 intel-vbtn driver. Fixes: 26173179fae1 ("platform/x86: intel-vbtn: Eval VBDL after registering our notifier") Signed-off-by: Rafael J. Wysocki Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/3426431.aeNJFYEL58@rafael.j.wysocki Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit f6dfd64bfd9b20e7adda533ed3cf3bed528ae4e5 Author: Rafael J. Wysocki Date: Tue May 12 17:13:28 2026 +0200 platform/x86: intel-hid: Check ACPI_HANDLE() against NULL [ Upstream commit 5c69e090ae5dd93d910f70db0796357080707d26 ] 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_HANDLE() check against NULL to the platform/x86 intel-hid driver. Fixes: ecc83e52b28c ("intel-hid: new hid event driver for hotkeys") Signed-off-by: Rafael J. Wysocki Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/1971512.tdWV9SEqCh@rafael.j.wysocki Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit ed864a7b881c82fd2ce74695afc3fccfab6fbe15 Author: Rafael J. Wysocki Date: Tue May 12 17:12:40 2026 +0200 platform/x86: hp_accel: Check ACPI_COMPANION() against NULL [ Upstream commit abfbe5ee8ae89f1f5449790423d5dd3e423545bd ] 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 platform/x86 hp_accel driver. Fixes: 8ebcb6c94c71 ("platform/x86: hp_accel: Convert to be a platform driver") Signed-off-by: Rafael J. Wysocki Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/2425918.ElGaqSPkdT@rafael.j.wysocki Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 7ea5aad8d351a8791b86f49bdc39ec67e277c35c Author: Rafael J. Wysocki Date: Tue May 12 17:11:49 2026 +0200 platform/x86: adv_swbutton: Check ACPI_HANDLE() against NULL [ Upstream commit e7a9a6ea40e352cd7977f6a8c80bdeadf65ad838 ] 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_HANDLE() check against NULL to the platform/x86 adv_swbutton driver. Fixes: 3d904005f686 ("platform/x86: add support for Advantech software defined button") Signed-off-by: Rafael J. Wysocki Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/5115425.31r3eYUQgx@rafael.j.wysocki Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 098419a4b0623a195ab1d88cfebf4a9f96a7598d Author: Oliver White Date: Thu Apr 9 15:43:47 2026 +1200 platform/surface: aggregator_registry: omit battery & AC nodes on Surface Laptop 7 [ Upstream commit 0488073a6c84571dd3cffe581a4a73a5fceb099d ] Surface Laptop 7 exposes battery and AC status via Qualcomm PMIC GLINK qcom_battmgr. Registering the standard SSAM battery and AC client devices on this platform causes duplicate power-supply devices to appear. Drop the SSAM battery and AC nodes from the Surface Laptop 7 registry group so that only the qcom_battmgr power supplies are instantiated. Fixes: b27622f13172 ("platform/surface: Add OF support") Signed-off-by: Oliver White Link: https://patch.msgid.link/20260409034347.17381-1-oliverjwhite07@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 09ec063d87c2dd3fa6f3561361a017bd882e9f37 Author: Erni Sri Satya Vennela Date: Thu May 14 12:41:51 2026 -0700 net: mana: Fix TOCTOU double-fetch of hwc_msg_id from DMA buffer [ Upstream commit 35f0f0a2536a4d604b4dbad92c85c4a8fdebb870 ] In mana_hwc_rx_event_handler(), resp->response.hwc_msg_id is read from DMA-coherent memory and bounds-checked, then mana_hwc_handle_resp() re-reads the same field from the same DMA buffer for test_bit() and pointer arithmetic. DMA-coherent memory is mapped uncacheable on x86 and is shared, unencrypted, in Confidential VMs (SEV-SNP/TDX), so each load goes directly to host-visible memory. A H/W can modify the value between the check and the use, bypassing the bounds validation. Fix this by reading hwc_msg_id exactly once using READ_ONCE() into a stack-local variable in mana_hwc_rx_event_handler(), and passing the validated value as a parameter to mana_hwc_handle_resp(). Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Signed-off-by: Erni Sri Satya Vennela Link: https://patch.msgid.link/20260514194156.466823-1-ernis@linux.microsoft.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f71fc35b5e45973bf62543f6e91a8cceae6bfb3b Author: Daniel Golle Date: Thu May 14 15:04:35 2026 +0100 net: dsa: mt7530: preserve VLAN tags on trapped link-local frames [ Upstream commit 3ac85bcfd404b588298c95c6fba8aad4ad334f57 ] The BPC, RGAC1 and RGAC2 registers control the handling of link-local frames with reserved MAC DAs (01:80:C2:00:00:0x). These frames are correctly trapped to the CPU port, but the egress VLAN tag attribute was set to MT7530_VLAN_EG_UNTAGGED which causes the switch to strip any VLAN tags from trapped frames before they reach the CPU. This causes VLAN-tagged link-local frames (STP BPDUs, LLDP, PTP Peer Delay Requests) to arrive at the CPU without their VLAN tag, so they are delivered to the base network interface instead of the VLAN sub-interface. The DSA local_termination selftest confirms this: all link-local protocol tests on VLAN upper interfaces fail. Set the EG_TAG attribute to MT7530_VLAN_EG_DISABLED (system default) so that the switch does not modify VLAN tags in trapped frames. This way VLAN-tagged frames retain their original tag and are delivered to the correct VLAN sub-interface, matching the behavior of non-trapped frames which pass through without VLAN tag modification. Fixes: 69ddba9d170b ("net: dsa: mt7530: fix handling of all link-local frames") Signed-off-by: Daniel Golle Acked-by: Chester A. Unal Link: https://patch.msgid.link/891e0cd34db2a5fe20ceb73283a81fb5f71427ca.1778766629.git.daniel@makrotopia.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 89bed786f23182fdf975668538bfee9df38aaaee Author: Daniel Golle Date: Thu May 14 15:04:21 2026 +0100 net: dsa: mt7530: fix FDB entries not aging out with short timeout [ Upstream commit e824e40d0e841fab66ab7897d6c7b14dc81c66a7 ] The DSA forwarding selftests bridge_vlan_aware.sh and bridge_vlan_unaware.sh configure the bridge with ageing_time set to LOW_AGEING_TIME (1000 centiseconds, i.e. 10 seconds) and then run learning_test() in lib.sh, which expects a learned FDB entry to be removed after ageing_time + 10 seconds. On MT7530/MT7531 the entry persisted past the deadline and the "Found FDB record when should not" assertion failed. With msecs=10000, the algorithm in mt7530_set_ageing_time() finds AGE_CNT=0 and AGE_UNIT=9 as the first exact match (starting the search from tmp_age_count=0). The per-entry aging counter is initialized to AGE_CNT when a MAC address is learned, so with AGE_CNT=0 new entries start with a counter value of 0, which the hardware treats as "already aged" and never removes, effectively disabling aging. Fix this by starting the search from tmp_age_count=1 to ensure entries always have a non-zero initial aging counter. For a 10-second ageing time this yields AGE_CNT=1 and AGE_UNIT=4 instead: the timer ticks every 5 seconds and entries are removed after 2 ticks. Starting the search at AGE_CNT=1 raises the minimum representable ageing time from 1 to 2 seconds. Without bounds, a stale ageing_time of 1 second would now make the loop fall through without setting age_count and age_unit, leaving them uninitialized when written to the MT7530_AAC hardware register. Set ds->ageing_time_min and ds->ageing_time_max so the DSA core validates the range before the callback is invoked, and drop the now-redundant range check from mt7530_set_ageing_time(). Fixes: ea6d5c924e39 ("net: dsa: mt7530: support setting ageing time") Signed-off-by: Daniel Golle Link: https://patch.msgid.link/7788ded12dc07b1bce329ec35fa70f4b45f3f9b7.1778766629.git.daniel@makrotopia.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f1739debda62d8ed591ec8635857265ca6eef77d Author: Viktor Jägersküpper Date: Fri May 15 23:58:45 2026 +0200 kbuild: pacman-pkg: make "rc" releases adhere to pacman versioning scheme [ Upstream commit 202550713128da20d9381d6d2dc0f6b73839f434 ] The package versioning scheme does not enable smooth upgrades from "rc" releases to the corresponding stable releases (e.g. 7.0.0-rc7 -> 7.0.0) because pacman considers that a downgrade due to the underscore in pkgver (e.g. 7.0.0_rc7), see e.g. vercmp(8) for an explanation of the package version comparison used by pacman. Package versions which are derived from said releases (e.g. built from git revisions) are similarly affected. Fix this by modifying pkgver in order to remove the hyphen from kernel versions containing "-rcN", where N is a non-negative integer. Acked-by: Thomas Weißschuh Signed-off-by: Viktor Jägersküpper Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor Link: https://patch.msgid.link/20260515215913.92481-1-viktor_jaegerskuepper@freenet.de Fixes: c8578539deba ("kbuild: add script and target to generate pacman package") Signed-off-by: Nicolas Schier Signed-off-by: Sasha Levin commit ad8e3d096fa1e2f8b1009731c6e0cdae7ebedf79 Author: Ankit Nautiyal Date: Mon May 11 18:02:15 2026 +0530 drm/i915/dp: Fix readback for target_rr in Adaptive Sync SDP [ Upstream commit f87abd0c6604fb6cc31cc86fc7ccc6a576924352 ] Correct the bit-shift logic to properly readback the 10 bit target_rr from DB3 and DB4. v2: Align the style with readback for vtotal. (Ville) Fixes: 12ea89291603 ("drm/i915/dp: Add Read/Write support for Adaptive Sync SDP") Cc: Mitul Golani Cc: Ankit Nautiyal Signed-off-by: Ankit Nautiyal Reviewed-by: Ville Syrjälä Link: https://patch.msgid.link/20260511123218.1589830-2-ankit.k.nautiyal@intel.com (cherry picked from commit f7abc4af2b19240a145a221461dfe756cc01d74a) Signed-off-by: Tvrtko Ursulin Signed-off-by: Sasha Levin commit 1f83545f432d106d5fc71d3997b2d382104ebcc4 Author: Kohei Enju Date: Fri May 15 11:24:15 2026 -0700 igc: set tx buffer type for SMD frames [ Upstream commit 5acc641e590e008caaed480ed9ffae47cf7ecbdf ] Sashiko pointed out that igc_fpe_init_smd_frame() initializes igc_tx_buffer fields for an SMD skb, but does not set the buffer type: https://sashiko.dev/#/patchset/20260415025226.114115-1-kohei%40enjuk.jp Since igc_tx_buffer entries are reused, a stale XDP or XSK type can remain and make TX completion use the wrong cleanup path. Set the buffer type to IGC_TX_BUFFER_TYPE_SKB. Fixes: 5422570c0010 ("igc: add support for frame preemption verification") Signed-off-by: Kohei Enju Reviewed-by: Aleksandr Loktionov Reviewed-by: Simon Horman Tested-by: Avigail Dahan Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260515182419.1597859-9-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 89964ddb322a65979ef867e240915223352922e2 Author: Grzegorz Nitka Date: Fri May 15 11:24:12 2026 -0700 ice: ptp: use primary NAC semaphore on E825 [ Upstream commit 7b28523546c7e4adbb8436f2986efcfc8382985e ] For E825 2xNAC configurations, PTP semaphore operations must hit the primary NAC register block so both sides coordinate on the same lock. Commit e2193f9f9ec9 ("ice: enable timesync operation on 2xNAC E825 devices") updated other primary-only PTP register accesses to use the primary NAC on non-primary functions, but left ice_ptp_lock() and ice_ptp_unlock() operating on the local NAC. As a result, secondary NAC PTP paths can take a different semaphore than the primary side. Select the primary hardware in ice_ptp_lock() and ice_ptp_unlock() when the current function is not primary, keeping semaphore operations symmetric and consistent with the rest of the 2xNAC PTP register access path. Fixes: e2193f9f9ec9 ("ice: enable timesync operation on 2xNAC E825 devices") Reviewed-by: Arkadiusz Kubalewski Signed-off-by: Grzegorz Nitka Reviewed-by: Aleksandr Loktionov Tested-by: Alexander Nowlin Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260515182419.1597859-6-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0010296879dfec8e9f1aa8292510b03499370210 Author: Grzegorz Nitka Date: Fri May 15 11:24:11 2026 -0700 ice: ptp: serialize E825 PHY timer start with PTP lock [ Upstream commit 781ff8f2d575a794a2a4f11605288ae06757f5eb ] ice_start_phy_timer_eth56g() programs TIMETUS registers and issues INIT_INCVAL without holding the global PTP semaphore. This allows concurrent PTP command paths to interleave with PHY timer start, which can make the sequence fail and leave timer initialization inconsistent. Take the PTP lock around TIMETUS registers programming and INIT_INCVAL command execution, and make sure the lock is released on all error paths. Keep the subsequent sync step outside of this critical section, since ice_sync_phy_timer_eth56g() takes the same semaphore internally. Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products") Reviewed-by: Arkadiusz Kubalewski Signed-off-by: Grzegorz Nitka Reviewed-by: Aleksandr Loktionov Tested-by: Alexander Nowlin Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260515182419.1597859-5-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6a01413a4e8fcb0263d7bef5075c5f8f4eb3a8b6 Author: Qing Ming Date: Sat May 16 15:08:49 2026 +0800 cgroup/rstat: validate cpu before css_rstat_cpu() access [ Upstream commit 8817005efbdfdf5d4e4814cb5dc52b53d12917d7 ] css_rstat_updated() is exposed as a BPF kfunc and accepts a caller-provided cpu argument. The function uses cpu for per-cpu rstat lookups without checking whether it refers to a valid possible CPU. A BPF iter/cgroup program with CAP_BPF and CAP_PERFMON can pass an invalid cpu value. On an unfixed UBSCAN_BOUNDS test kernel, cpu == 0x7fffffff triggers: UBSAN: array-index-out-of-bounds in kernel/cgroup/rstat.c:31:9 index 2147483647 is out of range for type 'long unsigned int [64]' Call Trace: css_rstat_updated bpf_iter_run_prog cgroup_iter_seq_show bpf_seq_read Add cpu validation to the BPF-facing css_rstat_updated() kfunc and move the common implementation to __css_rstat_updated() for in-kernel callers. Fixes: a319185be9f5 ("cgroup: bpf: enable bpf programs to integrate with rstat") Signed-off-by: Qing Ming Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 83b8a0f72ecc08bf71655a49b94fd69f7f06b5f1 Author: Louis-Alexis Eyraud Date: Wed Apr 29 11:59:02 2026 +0200 drm/mediatek: mtk_hdmi_ddc: Fix non-static global variable [ Upstream commit 87ed4e845d5a90bba1a56c0a5c580a13982e8648 ] The struct 'mtk_hdmi_ddc_driver' is not used outside of the mtk_hdmi_ddc.c file, so make it static to silence sparse warning: ``` drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c:331:24: sparse: warning: symbol 'mtk_hdmi_ddc_driver' was not declared. Should it be static? ``` Fixes: c241118b6216 ("drm/mediatek: mtk_hdmi_ddc: Switch to register as module_platform_driver") Signed-off-by: Louis-Alexis Eyraud Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/dri-devel/patch/20260429-mediatek-drm-fix-sparse-warnings-v1-4-d95c4d118b83@collabora.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 8ea34da689646a1261445e1e40f25bdee2df14a6 Author: Louis-Alexis Eyraud Date: Wed Apr 29 11:59:01 2026 +0200 drm/mediatek: mtk_cec: Fix non-static global variable [ Upstream commit 571f00a5fb725984049bd532ee8193cc34ff2994 ] The struct 'mtk_cec_driver' is not used outside of the mtk_cec.c file, so make it static to silence sparse warning: ``` drivers/gpu/drm/mediatek/mtk_cec.c:243:24: sparse: warning: symbol 'mtk_cec_driver' was not declared. Should it be static? ``` Fixes: 1e914a89ab7e ("drm/mediatek: mtk_cec: Switch to register as module_platform_driver") Signed-off-by: Louis-Alexis Eyraud Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/dri-devel/patch/20260429-mediatek-drm-fix-sparse-warnings-v1-3-d95c4d118b83@collabora.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 926a08cf19be32f9c9e25e0b00cc7f211f4f85a3 Author: Matthew Leach Date: Fri Apr 24 10:50:35 2026 +0100 wifi: ath11k: fix peer resolution on rx path when peer_id=0 [ Upstream commit 2a2451a34afdf563b3102d36a4b6cf335cf813e2 ] It has been observed that on certain chipsets a peer can be assigned peer_id=0. For reception of non-aggregated MPDUs this is fine as ath11k_dp_rx_h_find_peer() has a fallback case where it locates the peer based upon the source MAC address. On an aggregated link, the mpdu_start header is only populated by hardware on the first sub-MSDU. This causes the peer resolution to be skipped for the subsequent MSDUs and the encryption type of these frames to be set to an incorrect value, resulting in these MSDUs being dropped by ieee80211. ath11k_pci 0000:03:00.0: data rx skb 000000002f4b704d len 1534 peer xx:xx:xx:xx:xx:xx 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d1a fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 1 last_msdu 0 ath11k_pci 0000:03:00.0: data rx skb 0000000038acd580 len 1534 peer (null) 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d00 fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 0 last_msdu 1 Remove the null peer_id checks in ath11k_dp_rx_h_find_peer() and ath11k_hal_rx_parse_mon_status_tlv(), allowing peers with an assigned ID of 0 to be resolved. Tested-on: QCA2066 hw2.1 PCI WLAN.HSP.1.1-03926.13-QCAHSPSWPL_V2_SILICONZ_CE-2.52297.9 Fixes: 2167fa606c0f ("ath11k: Add support for RX decapsulation offload") Reviewed-by: Baochen Qiang Signed-off-by: Matthew Leach Reviewed-by: P Praneesh Link: https://patch.msgid.link/20260424-ath11k-null-peerid-workaround-v4-1-252b224d3cf6@collabora.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 6c9e9272bc37f1bebab59f244c3e4c296a573dbc Author: Mohanram Meenakshisundaram Date: Thu May 14 23:19:18 2026 +0530 drm/xe/pf: Fix CFI failure in debugfs access [ Upstream commit 96bf49b526e2d03a2b7f6e861925a08f46ed0d28 ] Reading debugfs file (/sys/kernel/debug/dri/0/gt*/pf/adverse_events) with CFI (Control Flow Integrity) enabled, the kernel panics at xe_gt_debugfs_simple_show+0x82/0xc0. xe_gt_debugfs_simple_show() declare a function pointer expecting int return type, but xe_gt_sriov_pf_monitor_print_events() is void return type, leading to CFI failure and kernel panic. [507620.973657] CFI failure at xe_gt_debugfs_simple_show+0x82/0xc0 [xe] (target: xe_gt_sriov_pf_monitor_print_events+0x0/0x130 [xe]; expected type: 0xd72c7139) Fix xe_gt_sriov_pf_monitor_print_events() function by updating to return an int type. Fixes: 1c99d3d3edab ("drm/xe/pf: Expose PF monitor details via debugfs") Signed-off-by: Mohanram Meenakshisundaram Reviewed-by: Michal Wajdeczko Signed-off-by: Michal Wajdeczko Link: https://patch.msgid.link/20260514174918.1556357-2-mohanram.meenakshisundaram@intel.com (cherry picked from commit ff1d386a8359746d9699ac30336e3b0684c68958) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit dc26e00860a15e5fbe000a74276dccd1690a0420 Author: Michal Wajdeczko Date: Thu May 14 17:57:26 2026 +0200 drm/xe/vf: Fix signature of print functions [ Upstream commit 9bb2f1d7e6e58b8e434ddc2048c661bf87ccdf2a ] We have plugged-in existing VF print functions into our GT debugfs show helper as-is, but we missed that the helper expects functions to return int, while they were defined as void. This can lead to errors being reported when CFI is enabled. Fixes: 63d8cb8fe3dd ("drm/xe/vf: Expose SR-IOV VF attributes to GT debugfs") Signed-off-by: Michal Wajdeczko Cc: Mohanram Meenakshisundaram Reviewed-by: Shuicheng Lin Link: https://patch.msgid.link/20260514155726.7165-1-michal.wajdeczko@intel.com (cherry picked from commit 314e31c9a8a1c421ee4f7f755b9348aefbbca090) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 2c890e71ae26fa32f5a96c3694b71a2c310940e7 Author: Shuicheng Lin Date: Mon May 11 15:41:34 2026 +0000 drm/xe/gsc: Fix double-free of managed BO in error path [ Upstream commit d3ded53fab90996e7d94a39049e11962dd066725 ] The error path in xe_gsc_init_post_hwconfig() 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: 2e5d47fe7839 ("drm/xe/uc: Use managed bo for HuC and GSC objects") Reviewed-by: Daniele Ceraolo Spurio Assisted-by: Claude:claude-opus-4.6 Link: https://patch.msgid.link/20260511154134.223696-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin (cherry picked from commit 71d61e3e299a17139e47f980a4d6f425b2c59bf7) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 181e67bc11c5ec5b87c6c512c2078752b23ca8d4 Author: Jianpeng Chang Date: Wed May 13 15:22:09 2026 +0800 dma-mapping: move dma_map_resource() sanity check into debug code [ Upstream commit af0c3f05866237f7592219bfe05387bc3bfc99b5 ] dma_map_resource() uses pfn_valid() to ensure the range is not RAM. However, pfn_valid() only checks for availability of the memory map for a PFN but it does not ensure that the PFN is actually backed by RAM. On ARM64 with SPARSEMEM (128MB section granularity), MMIO addresses that share a section with RAM will falsely trigger the WARN_ON_ONCE and cause dma_map_resource() to return DMA_MAPPING_ERROR. This causes a WARNING on Raspberry Pi 4 during spi_bcm2835 probe because the SPI FIFO register (0xfe204004) falls in the same sparsemem section as the end of RAM (0xf8000000-0xfbffffff), both in section 31 (0xf8000000-0xffffffff). Move the sanity check from dma_map_resource() into debug_dma_map_phys() and replace the unreliable pfn_valid() with pfn_valid() && !PageReserved(), which correctly identifies actual usable RAM without false positives for MMIO regions that happen to have struct pages. Since dma_map_resource() is dma_map_phys(DMA_ATTR_MMIO), the check applies equally to both APIs. Any non-reserved page represents kernel memory to a sufficient degree that using DMA_ATTR_MMIO on it is almost certainly wrong and risks breaking coherency on non-coherent platforms. ZONE_DEVICE pages used for PCI P2P DMA (MEMORY_DEVICE_PCI_P2PDMA) have PageReserved set, so they will not trigger a false positive. The check no longer blocks the mapping and uses err_printk() to integrate with dma-debug filtering. Fixes: f7326196a781 ("dma-mapping: export new dma_*map_phys() interface") Reviewed-by: Robin Murphy Signed-off-by: Jianpeng Chang Reviewed-by: Leon Romanovsky Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20260513072209.1486986-1-jianpeng.chang.cn@windriver.com Signed-off-by: Sasha Levin commit 3a74aaad047353da3344aed32e9042d4f334f926 Author: Miri Korenblit Date: Fri May 15 15:14:56 2026 +0300 wifi: iwlwifi: mld: don't dereference a pointer before NULL checking it [ Upstream commit d733ed481fd20a8e7bfe5119c4e77761ba3f87ee ] In iwl_mld_remove_link, the link->fw_id is saved at the beginning of the function so we have it after we freed the link. But the link pointer can be NULL, and is not checked when the fw_id is stored. Fix it by simply freeing the link at the end of the function. fFixes: 0e66a39f4f0e ("wifi: iwlwifi: fix potential use after free in iwl_mld_remove_link()") Reviewed-by: Johannes Berg Link: https://patch.msgid.link/20260515151351.371f40fc6711.I6a82cfe9655564e9c5731af91c36493b26b1208e@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 9e360e610a73f62432e986775023d5382773f045 Author: Cole Leavitt Date: Sat Apr 4 22:41:44 2026 -0700 wifi: iwlwifi: mld: fix TSO segmentation explosion when AMSDU is disabled [ Upstream commit 92cee08dc4f00e77fd1317e4343c5d458b0abab7 ] When the TLC notification disables AMSDU for a TID, the MLD driver sets max_tid_amsdu_len to the sentinel value 1. The TSO segmentation path in iwl_mld_tx_tso_segment() checks for zero but not for this sentinel, allowing it to reach the num_subframes calculation: num_subframes = (max_tid_amsdu_len + pad) / (subf_len + pad) = (1 + 2) / (1534 + 2) = 0 This zero propagates to iwl_tx_tso_segment() which sets: gso_size = num_subframes * mss = 0 Calling skb_gso_segment() with gso_size=0 creates over 32000 tiny segments from a single GSO skb. This floods the TX ring with ~1024 micro-frames (the rest are purged), creating a massive burst of TX completion events that can lead to memory corruption and a subsequent use-after-free in TCP's retransmit queue (refcount underflow in tcp_shifted_skb, NULL deref in tcp_rack_detect_loss). The MVM driver is immune because it checks mvmsta->amsdu_enabled before reaching the num_subframes calculation. The MLD driver has no equivalent bitmap check and relies solely on max_tid_amsdu_len, which does not catch the sentinel value. Fix this by detecting the sentinel value (max_tid_amsdu_len == 1) at the existing check and falling back to non-AMSDU TSO segmentation. Also add a WARN_ON_ONCE guard after the num_subframes division as defense-in-depth to catch any future code paths that produce zero through a different mechanism. Suggested-by: Miriam Rachel Korenblit Fixes: d1e879ec600f ("wifi: iwlwifi: add iwlmld sub-driver") Signed-off-by: Cole Leavitt Link: https://patch.msgid.link/20260405054145.1064152-3-cole@unwrap.rs Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit bed1fc32e0eb653806fa98afcf55f9a311fc4ce2 Author: Guenter Roeck Date: Thu May 14 14:41:00 2026 -0700 hwmon: (lm90) Add lock protection to lm90_alert [ Upstream commit 873e919e3101063a7a75989510ccfc125a4391cf ] Sashiko reports: lm90_alert() executes in the smbus alert context and calls lm90_update_confreg() to disable the hardware alert line, without acquiring hwmon_lock. Concurrently, sysfs write operations (such as lm90_write_convrate) hold the hwmon_lock, temporarily modify data->config, and then restore it. If an alert interrupt occurs concurrently with a sysfs write, the sysfs path will overwrite the alert handler's modifications to data->config and the hardware register. This unintentionally re-enables the hardware alert line while the alarm is still active, causing an interrupt storm. Add the missing lock to lm90_alert() to solve the problem. Fixes: 7a1d220ccb0cc ("hwmon: (lm90) Introduce function to update configuration register") Reported-by: Sashiko Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit c98107817b0f6cdf51adc5e84e75c39ee25d8b28 Author: Guenter Roeck Date: Thu May 14 14:31:49 2026 -0700 hwmon: (lm90) Stop work before releasing hwmon device [ Upstream commit b09a45601094c7f4ec4db8090b825fa61e169d93 ] Sashiko reports: In lm90_probe(), the devm action to cancel the alert_work and report_work (lm90_restore_conf) is registered in lm90_init_client() before devm_hwmon_device_register_with_info() is called. Because devm executes cleanup actions in reverse order during module unbind or probe failure, the hwmon device is unregistered and freed first. If lm90_alert_work() or lm90_report_alarms() runs in the window between the hwmon device being freed and the delayed works being cancelled, lm90_update_alarms() will dereference the freed data->hwmon_dev here. Fix the problem by canceling the workers separately after registering the hwmon device and before registering the interrupt handler. This ensures that the workers are canceled after interrupts are disabled and before the hwmon device is released. Add "shutdown" flag to indicate that device shutdown is in progress to prevent workers from being re-armed. Fixes: f6d0775119fb9 ("hwmon: (lm90) Rework alarm/status handling") Reported-by: Sashiko Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit cdd1aaf0ee962f50810b9aef7928f2313989d55f Author: Dmitry Baryshkov Date: Sat May 16 14:53:45 2026 +0300 drm/msm/snapshot: fix dumping of the unaligned regions [ Upstream commit 76824d2467feb1828b745d6add2541918d7be3da ] The snapshotting code internally aligns data segment to 16 bytes. This works fine for DPU code (where most of the regions are aligned), but fails for snapshotting of the DSI data (because DSI data region is shifted by 4 bytes). Fix the code by removing length alignment and by accurately printing last registers in the region. While reworking the code also fix the 16x memory overallocation in msm_disp_state_dump_regs(). Fixes: 98659487b845 ("drm/msm: add support to take dpu snapshot") Reported-by: Salendarsingh Gaud Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/725449/ Message-ID: <20260516-msm-fix-dsi-dump-2-v2-1-9e49fb2d240e@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 0c9e4d9484cc33a3e1425bb505145d80d1b09401 Author: Eric Naim Date: Sat May 16 19:15:31 2026 +0800 ALSA: hda/realtek: Use ALC287_FIXUP_TXNW2781_I2C for ASUS Strix Gxx5 [ Upstream commit 4372286ac774536e8e68bc6dfa0f0b0152b31fce ] These devices were incorrectly using the ALC287_FIXUP_TAS2781_I2C quirk leading to errors: [ 18.765990] Serial bus multi instantiate pseudo device driver TXNW2781:00: error -ENXIO: IRQ index 0 not found [ 18.768153] Serial bus multi instantiate pseudo device driver TXNW2781:00: error -ENXIO: IRQ index 0 not found [ 18.768476] Serial bus multi instantiate pseudo device driver TXNW2781:00: error -ENXIO: IRQ index 0 not found [ 18.768899] Serial bus multi instantiate pseudo device driver TXNW2781:00: Instantiated 3 I2C devices. Use the ALC287_FIXUP_TXNW2781_I2C quirk instead to fix this and restore speaker audio on affected devices. Fixes: 1e9c708dc3ae ("ALSA: hda/tas2781: Add new quirk for Lenovo, ASUS, Dell projects") Link: https://lore.kernel.org/59fd4aa4-76b9-4984-8db9-a60e55ec6e80@losource.net/ Closes: https://lore.kernel.org/CACB9z7kjs8rhLstEc8fV29BCTb5dd881JwGozoKdO5cwCb=YwQ@mail.gmail.com Signed-off-by: Eric Naim Link: https://patch.msgid.link/20260516111532.111463-1-dnaim@cachyos.org Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit df19b6af171695a1352314597c9a4311d48d5171 Author: Florian Westphal Date: Tue May 12 11:30:49 2026 +0200 netfilter: nft_inner: release local_lock before re-enabling softirqs [ Upstream commit a6cb3ff979855f7f0ee9450a947fe8f96c2ba37a ] Quoting sashiko: In the error path, local_bh_enable() is called before local_unlock_nested_bh(). Fixes: ba36fada9ab4 ("netfilter: nft_inner: Use nested-BH locking for nft_pcpu_tun_ctx") Signed-off-by: Florian Westphal Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 0fa225896f4b4cb24c519e1173e9e3347189bc23 Author: Felix Gu Date: Sun May 10 01:55:37 2026 +0800 spi: mtk-snfi: Fix resource leak in mtk_snand_read_page_cache() [ Upstream commit 496ba79b9496b8b3747cbc764ebd33ee7325e806 ] When DMA read times out in mtk_snand_read_page_cache(), the original code erroneously jumped to cleanup label which skips DMA unmapping and ECC disable, causing a resource leak. Fixes: 764f1b748164 ("spi: add driver for MTK SPI NAND Flash Interface") Signed-off-by: Felix Gu Link: https://patch.msgid.link/20260510-snfi-v1-1-bc375cf1af8e@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fecfed41da734c006aff722ab67f1e6fe0c77eec Author: Cássio Gabriel Date: Mon May 11 13:42:02 2026 -0300 ASoC: amd: acp-sdw-legacy: check CPU DAI name before logging [ Upstream commit 1afd8f06dcb1d561af3b239c5b14a88b87c13454 ] devm_kasprintf() can fail and return NULL. The legacy AMD SoundWire machine driver logs cpus->dai_name before checking the allocation result. Move the debug print after the NULL check, matching the ordering used by the SOF AMD SoundWire path after commit 5726b68473f7 ("ASoC: amd/sdw_utils: avoid NULL deref when devm_kasprintf() fails"). Fixes: 2981d9b0789c ("ASoC: amd: acp: add soundwire machine driver for legacy stack") Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260511-asoc-amd-acp-sdw-legacy-dai-name-null-v1-1-dc6151b6da8a@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7e91d3a1a98a3748e079b24379873b0318d10178 Author: Boris Burkov Date: Mon May 11 19:53:46 2026 -0700 btrfs: fix squota accounting during enable generation [ Upstream commit d7c600554816b8ef70adffe078a0e360c055d82b ] The first transaction that enables squotas is special and a bit tricky. We have to set BTRFS_FS_QUOTA_ENABLED after the transaction to avoid a deadlock, so any delayed refs that run before we set the bit are not squota accounted. For data this is fine, we don't get an owner_ref, so there is no real harm, it's as if the extent predated squotas. However for metadata, the tree block will have gen == enable_gen so when we free it later, we will decrement the squota accounting, which can result in an underflow. Before it is freed, btrfs check shows errors, as we have mismatched usage between the node generations/owners and the squota values. There are two angles to this fix: 1. For extents that come in delayed_refs that run during the enable_gen transaction, we must actually set enable_gen to the *next* transaction. That is the first transaction that we can really properly account in any way. 2. For extents that come in between the end of our transaction handle and the time we set the BTRFS_FS_QUOTA_ENABLED bit, we need an additional bit, BTRFS_FS_SQUOTA_ENABLING which only affects recording squota deltas, so we do pick up those extents. Otherwise, we would miss them, even for enable_gen + 1. Fixes: bd7c1ea3a302 ("btrfs: qgroup: check generation when recording simple quota delta") Reviewed-by: Qu Wenruo Signed-off-by: Boris Burkov Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit ca56ffdb017b33e68c69d1b59428b7466f5a4a13 Author: Boris Burkov Date: Mon May 11 13:07:11 2026 -0700 btrfs: check for subvolume before deleting squota qgroup [ Upstream commit 1e92637722ae4bd417f7a37e8d1485dc23b93935 ] The invariant that we want to maintain with subvolume qgroups is that the qgroup can only be deleted if there is no root. With squotas, we thought that it was sufficient to just check the usage, because we assumed that deleting a subvolume will drive it's qgroups usage to 0, and thus 0 usage implies no subvolume. However, this is false, for two reasons: - A subvol whose extents are all from before squotas was enabled. - A subvol that was created in this transaction and for which we have not yet run any delayed refs. In both cases, deleting the qgroup breaks the desired invariant and we are left with a subvolume with no qgroup but squotas are enabled. Fix this by unifying the deletion check logic between full qgroups and squotas. Squotas do all the same checks *and* the additional usage == 0 check, which is the one extra rule peculiar to squotas. Link: https://lore.kernel.org/linux-btrfs/adnBhWfJQ1n3hZC8@merlins.org/ Fixes: a8df35619948 ("btrfs: forbid deleting live subvol qgroup") Reviewed-by: Qu Wenruo Signed-off-by: Boris Burkov Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit b422609291f6158d0c12e8503124b1a3221d6d8d Author: Boris Burkov Date: Mon Dec 1 15:35:02 2025 -0800 btrfs: relax squota parent qgroup deletion rule [ Upstream commit adb0af40fe89fd42f1ef277bf60d9cfa7c2ae472 ] Currently, with squotas, we do not allow removing a parent qgroup with no members if it still has usage accounted to it. This makes it really difficult to recover from accounting bugs, as we have no good way of getting back to 0 usage. Instead, allow deletion (it's safe at 0 members..) while still warning about the inconsistency by adding a squota parent check. Reviewed-by: Qu Wenruo Signed-off-by: Boris Burkov Signed-off-by: David Sterba Stable-dep-of: 1e92637722ae ("btrfs: check for subvolume before deleting squota qgroup") Signed-off-by: Sasha Levin commit 22d558df51d90e62894b1b7320857ad47dc23d6b Author: Boris Burkov Date: Mon Dec 1 15:33:49 2025 -0800 btrfs: check squota parent usage on membership change [ Upstream commit 9c46bcda5f347febdbb4d117fb21a37ffcec5fa4 ] We could have detected the quick inherit bug more directly if we had an extra warning about squota hierarchy consistency while modifying the hierarchy. In squotas, the parent usage always simply adds up to the sum of its children, so we can just check for that when changing membership and detect more accounting bugs. Reviewed-by: Qu Wenruo Signed-off-by: Boris Burkov Signed-off-by: David Sterba Stable-dep-of: 1e92637722ae ("btrfs: check for subvolume before deleting squota qgroup") Signed-off-by: Sasha Levin commit a1296bb9f44a446ba3f8e06a7cec575979e988a4 Author: David Sterba Date: Tue Nov 18 17:06:46 2025 +0100 btrfs: remaining BTRFS_PATH_AUTO_FREE conversions [ Upstream commit 10934c131f9bcfb616dd8be9456f11efd6b240ec ] Do the remaining btrfs_path conversion to the auto cleaning, this seems to be the last one. Most of the conversions are trivial, only adding the declaration and removing the freeing, or changing the goto patterns to return. There are some functions with many changes, like __btrfs_free_extent(), btrfs_remove_from_free_space_tree() or btrfs_add_to_free_space_tree() but it still follows the same pattern. Signed-off-by: David Sterba Stable-dep-of: 1e92637722ae ("btrfs: check for subvolume before deleting squota qgroup") Signed-off-by: Sasha Levin commit 76ad957a72c713d48a4232bb56d6e19477d32094 Author: Josef Bacik Date: Tue Nov 18 17:08:43 2025 +0100 btrfs: don't search back for dir inode item in INO_LOOKUP_USER [ Upstream commit 70085399b1a1623ef488d96b4c2d0c67be1d0607 ] We don't need to search back to the inode item, the directory inode number is in key.offset, so simply use that. If we can't find the directory we'll get an ENOENT at the iget(). Note: The patch was taken from v5 of fscrypt patchset (https://lore.kernel.org/linux-btrfs/cover.1706116485.git.josef@toxicpanda.com/) which was handled over time by various people: Omar Sandoval, Sweet Tea Dorminy, Josef Bacik. Reviewed-by: Johannes Thumshirn Signed-off-by: Josef Bacik Signed-off-by: Daniel Vacek Reviewed-by: David Sterba [ add note ] Signed-off-by: David Sterba Stable-dep-of: 1e92637722ae ("btrfs: check for subvolume before deleting squota qgroup") Signed-off-by: Sasha Levin commit 16141bef6fb1a72bb11a5e46965facc9846c9d42 Author: Filipe Manana Date: Wed Oct 15 13:16:26 2025 +0100 btrfs: use the key format macros when printing keys [ Upstream commit af1e800c0244a04f5eb0993745c23d974f262628 ] Change all locations that print a key to use the new macros to print them in order to ensure a consistent style and avoid repetitive code. Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Stable-dep-of: 1e92637722ae ("btrfs: check for subvolume before deleting squota qgroup") Signed-off-by: Sasha Levin commit 35f69e993d002b22b108b1785c5a2b2c0a14acde Author: Filipe Manana Date: Wed Oct 15 12:40:06 2025 +0100 btrfs: add macros to facilitate printing of keys [ Upstream commit 95de4b097e25225d4deb5a33a4bfc27bb441f2d8 ] There's a lot of places where we need to print a key, and it's tiresome to type the format specifier, typically "(%llu %u %llu)", as well as passing 3 arguments to a prink family function (key->objectid, key->type, key->offset). So add a couple macros for this just like we have for csum values in btrfs_inode.h (CSUM_FMT and CSUM_FMT_VALUE). This also ensures that we consistently print a key in the same format, always as "(%llu %llu %llu)", which is the most common format we use, but we have a few variations such as "[%llu %llu %llu]" for no good reason. This patch introduces the macros while the next one makes use of it. This is to ease backports of future patches, since then we can backport this patch which is simple and short and then backport those future patches, as the next patch in the series that makes use of these new macros is quite large and may have some dependencies. Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Stable-dep-of: 1e92637722ae ("btrfs: check for subvolume before deleting squota qgroup") Signed-off-by: Sasha Levin commit 76b995bc57bd90cb6e954e1966fbd8786da47f0d Author: Stefano Garzarella Date: Thu May 14 11:29:48 2026 +0200 vsock/virtio: fix zerocopy completion for multi-skb sends [ Upstream commit ae38d9179190a956e2a87a69ef1dd6f451b51c4d ] When a large message is fragmented into multiple skbs, the zerocopy uarg is only allocated and attached to the last skb in the loop. Non-final skbs carry pinned user pages with no completion tracking, so the kernel has no way to notify userspace when those pages are safe to reuse. If the loop breaks early the uarg is never allocated at all, leaking pinned pages with no completion notification. Fix this by following the approach used by TCP: allocate the zerocopy uarg (if not provided by the caller) before the send loop and attach it to every skb via skb_zcopy_set(), which takes a reference per skb. Each skb's completion properly decrements the refcount, and the notification only fires after the last skb is freed. On failure, if no data was sent, the uarg is cleanly aborted via net_zcopy_put_abort(). This issue was initially discovered by sashiko while reviewing commit 1cb36e252211 ("vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting") but was pre-existing. Fixes: 581512a6dc93 ("vsock/virtio: MSG_ZEROCOPY flag support") Closes: https://sashiko.dev/#/patchset/20260420132051.217589-1-sgarzare%40redhat.com Reported-by: Maher Azzouzi Signed-off-by: Stefano Garzarella Acked-by: Michael S. Tsirkin Acked-by: Arseniy Krasnov Link: https://patch.msgid.link/20260514092948.268720-1-sgarzare@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 782693eb53f8111bd736026448847faa01b8c30b Author: Jens Axboe Date: Fri May 15 10:19:09 2026 -0600 io_uring/net: punt IORING_OP_BIND async if it needs file create [ Upstream commit ccd25890f73c082fe2657ed227b497d6ac5fdc40 ] For two reasons: 1) An opcode cannot block inside io_uring_enter() doing submissions, as it'll stall the submission side pipeline. 2) Ending up in sb_start_write() -> __sb_start_write() -> percpu_down_read_freezable() introduces a new lockdep edge, which it correctly complains about. Check if the socket type is AF_UNIX and has a non-empty pathname. If it does, mark it REQ_F_FORCE_ASYNC to punt the submission to io-wq rather than attempt to do it inline. Fixes: 7481fd93fa0a ("io_uring: Introduce IORING_OP_BIND") Reviewed-by: Gabriel Krisman Bertazi Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c53cac053d625b3e54bce39b996a2434bb62801f Author: Robertus Diawan Chris Date: Fri May 8 10:39:14 2026 +0700 ALSA: scarlett2: Add missing error check when initialise Autogain Status [ Upstream commit c0e4fffc0f474b7ed10adee4ab2bc1a66d36fc72 ] When initialise new control with scarlett2_add_new_ctl() function for Autogain Status, scarlett2_add_new_ctl() might throw an error. So, add error check after initialise new control for Autogain Status. This is reported by Coverity Scan with CID 1598781 as UNUSED_VALUE. Fixes: 0a995e38dc44 ("ALSA: scarlett2: Add support for software-controllable input gain") Signed-off-by: Robertus Diawan Chris Link: https://patch.msgid.link/20260508033914.111596-1-robertusdchris@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 1ddf678bb75b6383c775ece61d40956c441d8a26 Author: Alexander A. Klimov Date: Wed May 13 21:08:52 2026 +0200 ASoC: codecs: fs210x: fix possible buffer overflow [ Upstream commit 0d435a7ebcd4e97e47673c1ab6fb27f973a053ec ] In fs210x_effect_scene_info(), a string was copied like this: strscpy(DST, SRC, strlen(SRC) + 1); A buffer overflow would happen if strlen(SRC) >= sizeof(DST). Actually, strscpy() must be used this way: strscpy(DST, SRC, sizeof(DST)); strscpy(DST, SRC); // defaults to sizeof(DST) Fixes: 756117701779 ("ASoC: codecs: Add FourSemi FS2104/5S audio amplifier driver") Signed-off-by: Alexander A. Klimov Link: https://patch.msgid.link/20260513190852.196723-2-grandmaster@al2klimov.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 36de63965464026ebc520c30d4634ae8be513212 Author: Mike Christie Date: Mon May 11 12:53:17 2026 -0500 scsi: sd: Fix return code handling in sd_spinup_disk() [ Upstream commit 6ea68a8dc7d2711504d944811981a5304af7d7a9 ] As found by smatch-ci, scsi_execute_cmd() can return negative or positve values so we should use a int instead of unsigned int. Fixes: b4d0c33a32c3 ("scsi: sd: Fix sshdr use in sd_spinup_disk") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/linux-scsi/agFbI7E6JQwd3wGW@stanley.mountain/T/#u Signed-off-by: Mike Christie Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260511175317.114007-1-michael.christie@oracle.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b4dc0056397fe8c94cd440ae219ae2b68b875625 Author: Jeroen Massar Date: Wed May 13 09:33:02 2026 +0300 net/mlx5: Do not restore destination-less TC rules [ Upstream commit 8d0a5af8b1ba598e7340761729801624e7a9330e ] After IPsec policy/state TX rules are added, any TC flow rule, which forwards packets to uplink, is modified to forward to IPsec TX tables. As these tables are destroyed dynamically, whenever there is no reference to them, the destinations of this kind of rules must be restored to uplink, unless there is no destination for that rule. The flow rules FLOW_ACTION_ACCEPT, DROP, TRAP, GOTO and SAMPLE do not have a destination port, and thus out_count = 0. At cleanup time of the rules in mlx5_esw_ipsec_modify_flow_dests we call mlx5_eswitch_restore_ipsec_rule but as the above types do not have a destination we get an underflow of out_count, as the port is passed, which is esw_attr->out_count - 1. This change avoids calling mlx5_eswitch_restore_ipsec_rule when there are no output destinations and thus avoids the underflow. Fixes: d1569537a837 ("net/mlx5e: Modify and restore TC rules for IPSec TX rules") Signed-off-by: Jeroen Massar Reviewed-by: Jianbo Liu Reviewed-by: Cosmin Ratiu Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260513063302.333761-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 81c8a9f75a4268f2b4756107b298c69be9248c0d Author: Chuck Lever Date: Wed May 13 08:58:25 2026 -0400 tls: Preserve sk_err across recvmsg() when data has been copied [ Upstream commit f508262ae9f21fe0e6c0749948b9dc7dd5a62a70 ] The sk_err check in tls_rx_rec_wait() consumes the error via sock_error(), which clears sk_err atomically. When the caller (tls_sw_recvmsg, tls_sw_splice_read, or tls_sw_read_sock) already has bytes copied to userspace, it returns those bytes and discards the error from this call. sk_err is now zero on the socket, so the next read syscall observes only RCV_SHUTDOWN and reports a clean EOF instead of the actual error (typically -ECONNRESET). The race is reachable when tls_read_flush_backlog()'s periodic sk_flush_backlog() triggers tcp_reset() in the middle of a multi-record read. Pass a has_copied flag to tls_rx_rec_wait(). When has_copied is false, consume sk_err via sock_error() as before. When has_copied is true, report the error from READ_ONCE() but leave sk_err set: the caller returns the byte count and discards the err from this call, and the next read syscall surfaces the preserved sk_err. This mirrors the tcp_recvmsg() preserve-and-surface pattern. The decrypt-abort path is unaffected: tls_err_abort() raises sk_err to EBADMSG after tls_rx_rec_wait() returns, and nothing on the caller's return path consumes it, so the EBADMSG surfaces on the next read. tls_sw_splice_read() passes has_copied=false: it processes one record per call, so no bytes have been copied within the function when tls_rx_rec_wait() runs. A reset that arrives between iterations of splice_direct_to_actor() (the sendfile() path) is still consumed by sock_error() in the later call, and the outer loop returns the prior iterations' byte count and drops the error. tcp_splice_read() exhibits the same pattern at the iteration boundary; addressing it belongs at the splice_direct_to_actor() layer and is out of scope here. Fixes: c46b01839f7a ("tls: rx: periodically flush socket backlog") Suggested-by: Jakub Kicinski Signed-off-by: Chuck Lever Link: https://patch.msgid.link/20260513125825.205189-1-cel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1370acb8bc390de37ea50d9c414eba3cc0b90f9f Author: Ralf Lici Date: Wed May 13 15:26:10 2026 +0200 ovpn: disable BHs when updating device stats [ Upstream commit 0c0dddc07d272a8d25922e48041e8e4d2434df7e ] ovpn updates dev->dstats from both process and softirq contexts. In particular, TCP paths may run from socket callbacks, workqueues or strparser work, while UDP receive and ovpn's ndo_start_xmit path may update the same per-device dstats from BH context. Add ovpn device drop-stat helpers that disable BHs around dev_dstats_rx_dropped() and dev_dstats_tx_dropped(), and use them for drop accounting. The successful RX dev_dstats_rx_add() update is already covered by the BH-disabled section around gro_cells_receive(). For the successful TCP TX dev_dstats_tx_add() update, replace the existing preempt-disabled section with a BH-disabled one. Fixes: 11851cbd60ea ("ovpn: implement TCP transport") Signed-off-by: Ralf Lici Signed-off-by: Antonio Quartulli Signed-off-by: Sasha Levin commit f7808b7ddcf21486776cf6e39902e4de7446e7a1 Author: Juergen Gross Date: Tue May 5 12:24:17 2026 +0200 x86/xen: Fix xen_e820_swap_entry_with_ram() [ Upstream commit 28e03f78e69cf6628b81f24777799778528a84c1 ] When swapping a not page-aligned E820 map entry with RAM, the start address of the modified entry is calculated wrong (the offset into the page is subtracted instead of being added to the page address). Fixes: be35d91c8880 ("xen: tolerate ACPI NVS memory overlapping with Xen allocated memory") Reported-by: Jan Beulich Reviewed-by: Jan Beulich Signed-off-by: Juergen Gross Message-ID: <20260505102417.208138-1-jgross@suse.com> Signed-off-by: Sasha Levin commit 2378d25675dacf29b2074dd5a010d7883f6a621a Author: Kees Cook Date: Sat Mar 14 14:24:56 2026 +0100 gcc-plugins: Always define CONST_CAST_GIMPLE and CONST_CAST_TREE [ Upstream commit 905c559e51497b8bfdbb68df8be56d2f70f0de8e ] For gcc-16, the CONST_CAST macro family was removed. Add back what we were using in gcc-common.h, as they are simple wrappers. See GCC commits: c3d96ff9e916c02584aa081f03ab999292efbb50 458c7926d48959abcb2c1adaa22458e27459a551 Suggested-by: Ingo Saitz Link: https://lore.kernel.org/lkml/ab6OKoay0OWkywjK@spatz.zoo Fixes: 6b90bd4ba40b ("GCC plugin infrastructure") Tested-by: Ivan Bulatovic Tested-by: Christopher Cradock Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 097d62df38314c14b88fab9096f3461baf158e2b Author: Antonio Quartulli Date: Tue Mar 17 14:47:56 2026 +0100 ovpn: fix race between deleting interface and adding new peer [ Upstream commit 982422b11e6f95f766a8cd2c2b1cbdb77e234a61 ] While deleting an existing ovpn interface, there is a very narrow window where adding a new peer via netlink may cause the netdevice to hang and prevent its unregistration. It may happen during ovpn_dellink(), when all existing peers are freed and the device is queued for deregistration, but a CMD_PEER_NEW message comes in adding a new peer that takes again a reference to the netdev. At this point there is no way to release the device because we are under the assumption that all peers were already released. Fix the race condition by releasing all peers in ndo_uninit(), when the netdevice has already been removed from the netdev list. Also ovpn_peer_add() has now an extra check that forces the function to bail out if the device reg_state is not REGISTERED. This way any incoming CMD_PEER_NEW racing with the interface deletion routine will simply stop before adding the peer. Note that the above check happens while holding the netdev_lock to prevent racing netdev state changes. ovpn_dellink() is now empty and can be removed. Reported-by: Hyunwoo Kim Closes: https://lore.kernel.org/netdev/aaVgJ16edTfQkYbx@v4bel/ Suggested-by: Sabrina Dubroca Fixes: 80747caef33d ("ovpn: introduce the ovpn_peer object") Reviewed-by: Sabrina Dubroca Signed-off-by: Antonio Quartulli Signed-off-by: Sasha Levin commit 8298834912d76dbc82c12b6b4ab7590ed2bb8ae5 Author: David Carlier Date: Wed May 13 11:55:21 2026 +0100 ovpn: respect peer refcount in CMD_NEW_PEER error path [ Upstream commit 1fef6614673ff0846d30acdeeaf3cf98bb5f6116 ] ovpn_nl_peer_new_doit()'s error path calls ovpn_peer_release() directly rather than ovpn_peer_put(), bypassing the kref. The accompanying comment ("peer was not yet hashed, thus it is not used in any context") holds for UDP but not for TCP. For UDP, the ovpn_socket union uses the .ovpn arm and never points back at a peer; UDP encap_recv looks up peers via the not-yet-populated hashtables, so the new peer is unreachable until ovpn_peer_add() publishes it. For TCP, ovpn_socket_new() sets ovpn_sock->peer and ovpn_tcp_socket_attach() publishes ovpn_sock via rcu_assign_sk_user_data(). From that moment until ovpn_socket_release() detaches in the error path, the TCP fd is fully wired: userspace recvmsg / sendmsg / close / poll on the fd, as well as the strparser-driven ovpn_tcp_rcv() path, can reach the peer through sk_user_data -> ovpn_sock->peer and bump its refcount via ovpn_peer_hold(). ovpn_tcp_socket_wait_finish() (called inside ovpn_socket_release()) drains strparser and the tx work, but does not synchronize with userspace syscall callers that already hold a peer reference. If ovpn_nl_peer_modify() or ovpn_peer_add() returns an error while such a caller is in flight - notably an ovpn_tcp_recvmsg() blocked in __skb_recv_datagram() on peer->tcp.user_queue - the direct ovpn_peer_release() destroys the peer while the caller still holds the reference, and the eventual ovpn_peer_put() from that caller operates on freed memory. Replace the direct destructor call with ovpn_peer_put() so the kref correctly defers destruction until the last reference is dropped. In the common case where no concurrent user is present, behaviour is unchanged: the kref hits zero immediately and ovpn_peer_release_kref() runs the same destructor. With this conversion ovpn_peer_release() has no callers outside peer.c - ovpn_peer_release_kref() in the same translation unit is the only remaining user - so make it static and drop its declaration from peer.h. Fixes: 11851cbd60ea ("ovpn: implement TCP transport") Reviewed-by: Sabrina Dubroca Assisted-by: Claude:claude-opus-4-7 Signed-off-by: David Carlier Signed-off-by: Antonio Quartulli Signed-off-by: Sasha Levin commit e5460eb7238c19d651a9b22b2378b587033a4095 Author: David Carlier Date: Wed May 13 11:55:20 2026 +0100 ovpn: tcp - use cached peer pointer in ovpn_tcp_close() [ Upstream commit 775d8d7ad02aa345e1588424a6a8b9ae49fb9012 ] ovpn_tcp_close() loads the ovpn_socket via rcu_dereference_sk_user_data() under rcu_read_lock(), takes a reference on sock->peer, caches the peer pointer in a local, and drops the read lock. It then passes sock->peer (rather than the cached local) to ovpn_peer_del(), re-dereferencing the ovpn_socket after the RCU read section has ended. Unlike ovpn_tcp_sendmsg(), which uses the same "load under RCU, use after unlock" pattern but is protected by lock_sock() held across the function, ovpn_tcp_close() runs without the socket lock: inet_release() invokes sk_prot->close() without taking lock_sock first. ovpn_socket_release() can therefore complete its kref_put -> detach -> synchronize_rcu -> kfree(sock) sequence concurrently, in the window after ovpn_tcp_close() drops rcu_read_lock() but before it dereferences sock->peer. The synchronize_rcu() in ovpn_socket_release() protects readers that use the dereferenced pointer inside the RCU read section, not those that escape the pointer to a local and use it afterwards. A reproducer follows the pattern of commit 94560267d6c4 ("ovpn: tcp - don't deref NULL sk_socket member after tcp_close()"): trigger a peer removal (keepalive expiration or netlink OVPN_CMD_DEL_PEER) at the same moment userspace closes the TCP fd. That commit fixed the detach-side of the same race window; this one fixes the close-side at a different victim. Tighten the entry block to read sock->peer exactly once into the cached peer local, and route all subsequent uses (the hold check, the ovpn_peer_del() call, and the prot->close() invocation) through that local. sock->peer is only ever written once in ovpn_socket_new() under lock_sock(), before rcu_assign_sk_user_data() publishes the ovpn_socket, and is never reassigned afterwards - but the previous multi-read pattern made that invariant implicit rather than explicit. The same multi-read shape exists in ovpn_tcp_recvmsg(), ovpn_tcp_sendmsg(), ovpn_tcp_data_ready() and ovpn_tcp_write_space(); those will be cleaned up via a dedicated helper in a follow-up net-next series. Fixes: 11851cbd60ea ("ovpn: implement TCP transport") Reviewed-by: Sabrina Dubroca Assisted-by: Claude:claude-opus-4-7 Signed-off-by: David Carlier Signed-off-by: Antonio Quartulli Signed-off-by: Sasha Levin commit 2bc34520ce5cf0c49151fe5f1fa403f5f097751c Author: Sven Schuchmann Date: Tue May 12 09:19:47 2026 +0200 net: phy: DP83TC811: add reading of abilities [ Upstream commit c78bdba7b9666020c0832150a4fc4c0aebc7c6ac ] At this time the driver is not listing any speeds it supports. This should be ETHTOOL_LINK_MODE_100baseT1_Full_BIT for DP83TC811. Add the missing call for phylib to read the abilities. Fixes: b753a9faaf9a ("net: phy: DP83TC811: Introduce support for the DP83TC811 phy") Suggested-by: Andrew Lunn Signed-off-by: Sven Schuchmann Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260512071949.6218-1-schuchmann@schleissheimer.de [pabeni@redhat.com: dropped revision history] Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit af855f4c966afafef74faf8390c7b86568c0d46d Author: Jakub Kicinski Date: Mon May 11 10:49:18 2026 -0700 net: tls: prevent chain-after-chain in plain text SG [ Upstream commit ff26a0e8377dec07e4a7230db7675bed1b9a6d03 ] Sashiko points out that if end = 0 (start != 0) the current code will create a chain link to content type right after the wrap link: This would create a chain where the wrap link points directly to another chain link. The scatterlist API sg_next iterator does not recursively resolve consecutive chain links. meaning this is illegal input to crypto. The wrapping link is unnecessary if end = 0. end is the entry after the last one used so end = 0 means there's nothing pushed after the wrap: end start i v v v [ ]...[ ][ d ][ d ][ d ][ d ][rsv for wrap] Skip the wrapping in this case. TLS 1.3 can use the "wrapping slot" for it's chaining if end = 0. This avoids the chain-after-chain. Move the wrap chaining before marking END and chaining off content type, that feels like more logical ordering to me, but should not matter from functional perspective. Reported-by: Sashiko Fixes: 9aaaa56845a0 ("bpf: Sockmap/tls, skmsg can have wrapped skmsg that needs extra chaining") Signed-off-by: Jakub Kicinski Link: https://patch.msgid.link/20260511174920.433155-3-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit eca989eab4b2599dcb02f72140a7c08f08838520 Author: Jakub Kicinski Date: Mon May 11 10:49:17 2026 -0700 net: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring [ Upstream commit 285943c6e7ca309bbea84b253745154241d9788a ] When an sk_msg scatterlist ring wraps (sg.end < sg.start), tls_push_record() chains the tail portion of the ring to the head using sg_chain(). An extra entry in the sg array is reserved for this: struct sk_msg_sg { [...] /* The extra two elements: * 1) used for chaining the front and sections when the list becomes * partitioned (e.g. end < start). The crypto APIs require the * chaining; * 2) to chain tailer SG entries after the message. */ struct scatterlist data[MAX_MSG_FRAGS + 2]; The current code uses MAX_SKB_FRAGS + 1 as the ring size: sg_chain(&msg_pl->sg.data[msg_pl->sg.start], MAX_SKB_FRAGS - msg_pl->sg.start + 1, msg_pl->sg.data); This places the chain pointer at sg_chain(data[start], (MAX_SKB_FRAGS - msg_start + 1) .. = &data[start] + (MAX_SKB_FRAGS - msg_start + 1) - 1 = data[start + (MAX_SKB_FRAGS - start + 1) - 1] = data[MAX_SKB_FRAGS] instead of the true last entry. This is likely due to a "race" of the commit under Fixes landing close to commit 031097d9e079 ("bpf: sk_msg, zap ingress queue on psock down") Convert to ARRAY_SIZE and drop the data[start] / - start (as suggested by Sabrina). Reported-by: 钱一铭 Fixes: 9aaaa56845a0 ("bpf: Sockmap/tls, skmsg can have wrapped skmsg that needs extra chaining") Signed-off-by: Jakub Kicinski Reviewed-by: Sabrina Dubroca Link: https://patch.msgid.link/20260511174920.433155-2-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit afa9036b8c9963947b487c36e332df6a42c96fcb Author: Xiang Mei Date: Sun May 10 23:21:38 2026 -0700 net/smc: reject CHID-0 ACCEPT that matches an empty ism_dev slot [ Upstream commit 277740023def559a4a2ddc3e8e784ee37a0f16a9 ] On the SMC-D client, slot 0 of ini->ism_dev[]/ini->ism_chid[] is reserved for an SMC-Dv1 device. smc_find_ism_v2_device_clnt() populates V2 entries starting at index 1, so when no V1 device is selected slot 0 is left in its kzalloc()'ed state with ism_dev[0] == NULL and ism_chid[0] == 0. smc_v2_determine_accepted_chid() then matches the peer's CHID against the array starting from index 0 using the CHID alone. A malicious peer replying to a SMC-Dv2-only proposal with d1.chid == 0 matches the empty slot, ini->ism_selected becomes 0, and the subsequent ism_dev[0]->lgr_lock dereference in smc_conn_create() faults at offsetof(struct smcd_dev, lgr_lock) == 0x68: BUG: KASAN: null-ptr-deref in _raw_spin_lock_bh+0x79/0xe0 Write of size 4 at addr 0000000000000068 by task exploit/144 Call Trace: _raw_spin_lock_bh smc_conn_create (net/smc/smc_core.c:1997) __smc_connect (net/smc/af_smc.c:1447) smc_connect (net/smc/af_smc.c:1720) __sys_connect __x64_sys_connect do_syscall_64 Require ism_dev[i] to be non-NULL before accepting a CHID match. Fixes: a7c9c5f4af7f ("net/smc: CLC accept / confirm V2") Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Xiang Mei Link: https://patch.msgid.link/20260511062138.2839584-1-xmei5@asu.edu Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 6dcd072a5ae3aed336e4a67a7d4cc5205b240065 Author: Sayali Patil Date: Wed May 13 13:44:13 2026 +0530 powerpc/time: Remove redundant preempt_disable|enable() calls from arch_irq_work_raise() [ Upstream commit 31467b23823ffec1f6fff407f8e3ca9af8b7491a ] A kernel panic is observed when handling machine check exceptions from real mode. BUG: Unable to handle kernel data access on read at 0xc00000006be21300 Oops: Kernel access of bad area, sig: 11 [#1] MSR: 8000000000001003 CR: 88222248 XER: 00000005 CFAR: c00000000003ffc4 DAR: c00000006be21300 DSISR: 40000000 IRQMASK: 0 NIP [c000000000029e40] arch_irq_work_raise+0x10/0x70 LR [c00000000003ffc8] machine_check_queue_event+0xa8/0x150 Call Trace: [c0000000179d3c70] [c00000000003ff64] machine_check_queue_event+0x44/0x150 [c0000000179d3d30] [c0000000000084e0] machine_check_early_common+0x1f0/0x2c0 The crash occurs because arch_irq_work_raise() calls preempt_disable() from machine check exception (MCE) handlers running in real mode. In this context, accessing the preempt_count can fault, leading to the panic. The preempt_disable()/preempt_enable() pair in arch_irq_work_raise() was originally added by commit 0fe1ac48bef0 ("powerpc/perf_event: Fix oops due to perf_event_do_pending call") to avoid races while raising irq work from exception context. Later, commit 471ba0e686cb ("irq_work: Do not raise an IPI when queueing work on the local CPU") added preemption protection in irq_work_queue() path, while commit 20b876918c06 ("irq_work: Use per cpu atomics instead of regular atomics") added equivalent protection in irq_work_queue_on() before reaching arch_irq_work_raise(): irq_work_queue() / irq_work_queue_on() -> preempt_disable() -> __irq_work_queue_local() -> irq_work_raise() -> arch_irq_work_raise() As a result, callers other than mce_irq_work_raise() already execute with preemption disabled, making the additional preempt_disable()/preempt_enable() pair in arch_irq_work_raise() redundant. The arch_irq_work_raise() function executes in NMI context when called from MCE handler. Hence we will not be preempted or scheduled out since we are in NMI context with MSR[EE]=0. Therefore, it is safe to remove the preempt_disable()/preempt_enable() calls from here. Remove it to avoid accessing preempt_count from real mode context. Fixes: cc15ff327569 ("powerpc/mce: Avoid using irq_work_queue() in realmode") Suggested-by: Mahesh Salgaonkar Acked-by: Shrikanth Hegde Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Sayali Patil [Maddy: Fixed the commit title] Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260513081413.222490-1-sayalip@linux.ibm.com Signed-off-by: Sasha Levin commit f4e37f3df436c2bdd2621c21f9c72c8f149a221d Author: Mikko Perttunen Date: Tue Apr 21 13:02:38 2026 +0900 drm/msm: Fix iommu_map_sgtable() return value check and avoid WARN [ Upstream commit 55e0f0d1c1a4ee1e46da7da4d443eb3044fb3851 ] 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. Store the return value in the appropriate type and in case of error, return it rather than WARNing. Fixes: ad8f36e4b6b1 ("iommu: return full error code from iommu_map_sg[_atomic]()") Signed-off-by: Mikko Perttunen Patchwork: https://patchwork.freedesktop.org/patch/719685/ Message-ID: <20260421-iommu_map_sgtable-return-v1-3-fb484c07d2a1@nvidia.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit eea43d5ed45089705bc5d70971c39076962d5951 Author: Dmitry Baryshkov Date: Sat Apr 11 17:59:15 2026 +0300 drm/msm/adreno: fix userspace-triggered crash on a2xx-a4xx [ Upstream commit 2b4abf879360ea00a9e2b46d2d15dcdbc0687eed ] Before a5xx Adreno driver will not try fetching UBWC params (because those generations didn't support UBWC anyway), however it's still possible to query UBWC-related params from the userspace, triggering possible NULL pointer dereference. Check for UBWC config in adreno_get_param() and return sane defaults if there is none. Fixes: a452510aad53 ("drm/msm/adreno: Switch to the common UBWC config struct") Signed-off-by: Dmitry Baryshkov Reviewed-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/717778/ Message-ID: <20260411-adreno-fix-ubwc-v3-1-4983156f3f80@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 3a7b59d2385d477526cb5b5822754def29953ac0 Author: Ricardo Neri Date: Fri Apr 24 14:41:13 2026 -0700 Documentation: intel_pstate: Fix description of asymmetric packing with SMT [ Upstream commit ee047fc7a2da90554410128195058c409a391d43 ] Patchset [1], including commits 046a5a95c3b0 ("x86/sched/itmt: Give all SMT siblings of a core the same priority") 995998ebdebd ("x86/sched: Remove SD_ASYM_PACKING from the SMT domain flags") overhauled asym_packing handling in the scheduler on x86 hybrid processors with SMT. It removed SD_ASYM_PACKING from the x86 SMT scheduling domain and made all SMT siblings of a core share the same priority. As a result, asym_packing operates only across physical cores, spreading tasks among them and only using idle SMT siblings once all physical cores are busy. Fix the documentation to reflect this behavior. Fixes: f20af84c29b2 ("cpufreq: intel_pstate: Document hybrid processor support") Link: https://lore.kernel.org/r/20230406203148.19182-1-ricardo.neri-calderon@linux.intel.com [1] Signed-off-by: Ricardo Neri [ rjw: Changelog edits ] Link: https://patch.msgid.link/20260424-rneri-fix-intel-pstate-doc-smt-asym-packing-v1-1-317bf7d5c362@linux.intel.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 3ad2d8be6e4ddf7d26d27f56e2f58b9b81537f2c Author: Borislav Petkov (AMD) Date: Mon Mar 16 16:12:00 2026 +0100 x86/mce: Restore MCA polling interval halving [ Upstream commit ea324444ece9f301b5c4ff71b258cc68990c4d61 ] RongQing reported that the MCA polling interval doesn't halve when an error gets logged. It was traced down to the commit in Fixes:, because: mce_timer_fn() |-> mce_poll_banks() |-> machine_check_poll() |-> mce_log() which will queue the work and return. Now, back in mce_timer_fn(): /* * Alert userspace if needed. If we logged an MCE, reduce the polling * interval, otherwise increase the polling interval. */ if (mce_notify_irq()) <--- here we haven't ran the notifier chain yet so mce_need_notify is not set yet so this won't hit and we won't halve the interval iv. Now the notifier chain runs. mce_early_notifier() sets the bit, does mce_notify_irq(), that clears the bit and then the notifier chain a little later logs the error. So this is a silly timing issue. But, that's all unnecessary. All it needs to happen here is, the "should we notify of a logged MCE" mce_notify_irq() asks, should be simply a question to the mce gen pool: "Are you empty?" And that then turns into a simple yes or no answer and it all JustWorks(tm). So do that and also distribute the functionality where it belongs: - Print that MCE events have been logged in mce_log() - Trigger the mcelog tool specific work in the first notifier As a result, mce_notify_irq() can go now. Fixes: 011d82611172 ("RAS: Add a Corrected Errors Collector") Reported-by: Li RongQing Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Qiuxu Zhuo Tested-by: Qiuxu Zhuo Link: https://lore.kernel.org/r/20260112082747.2842-1-lirongqing@baidu.com Signed-off-by: Sasha Levin commit 15dba511d5694dea40dce263be3fa655a1a65f3f Author: Ming Lei Date: Wed May 13 18:19:40 2026 +0800 selftests: ublk: cap nthreads to kernel's actual nr_hw_queues [ Upstream commit 87d0740b7c4cc847be1b6f307ab6d8547cb1a726 ] dev->nthreads is derived from the user-requested queue count before the ADD command, but the kernel may reduce nr_hw_queues (capped to nr_cpu_ids). When the VM has fewer CPUs than requested queues, the daemon creates more handler threads than there are kernel queues. In non-batch mode, the extra threads access uninitialized queues (q_depth=0), submit zero io_uring SQEs, and block forever in io_cqring_wait. In batch mode, the extra threads cause similar hangs during device removal. In both cases, the stuck threads prevent the daemon from closing the char device, holding the last ublk_device reference and causing ublk_ctrl_del_dev() to hang in wait_event_interruptible(). Fix by capping dev->nthreads to the kernel-returned nr_hw_queues after the ADD command completes. per_io_tasks mode is excluded because threads interleave across all queues, so nthreads > nr_hw_queues is valid. Fixes: abe54c160346 ("selftests: ublk: kublk: decouple ublk_queues from ublk server threads") Signed-off-by: Ming Lei Link: https://patch.msgid.link/20260513101941.1373998-1-tom.leiming@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ff58e5ef1b46ce614af048d2d04986df05ffab90 Author: Dmitry Baryshkov Date: Tue May 5 03:24:58 2026 +0300 drm/msm/dpu: don't mix devm and drmm functions [ Upstream commit c0c70a11365cba7fba25a77463582bcec0f7846e ] Mixing devm and drmm functions will result in a use-after-free on msm driver teardown if userspace keeps a reference on the drm device: The WB connector data will be destroyed because of the use of devm_kzalloc()), while the usersoace still can try interacting with the WB connector (which uses drmm_ functions). Change dpu_writeback_init() to use drmm_. Fixes: 0b37ac63fc9d ("drm/msm/dpu: use drmm_writeback_connector_init()") Reported-by: Christophe JAILLET Closes: https://lore.kernel.org/r/78c764b8-44cf-4db5-88e7-807a85954518@wanadoo.fr Signed-off-by: Dmitry Baryshkov Reviewed-by: John.Harrison@Igalia.com Patchwork: https://patchwork.freedesktop.org/patch/722656/ Link: https://lore.kernel.org/r/20260505-wb-drop-encoder-v5-1-42567b7c7af2@oss.qualcomm.com Signed-off-by: Sasha Levin commit a184aec790135938b0fadb415e55accd1f8685a0 Author: Dmitry Baryshkov Date: Tue Apr 28 20:21:38 2026 +0300 drm/msm/dsi: don't dump registers past the mapped region [ Upstream commit 5b49a46baa853b26dbefa65c6c75dd9ff69f63d4 ] On DSI 6G platforms the IO address space is internally adjusted by io_offset. Later this adjusted address might be used for memory dumping. However the size that is used for memory dumping isn't adjusted to account for the io_offset, leading to the potential access to the unmapped region. Lower ctrl_size by the io_offset value to prevent access past the mapped area. msm_disp_snapshot_add_block+0x1d4/0x3c8 [msm] (P) msm_dsi_host_snapshot+0x4c/0x78 [msm] msm_dsi_snapshot+0x28/0x50 [msm] msm_disp_snapshot_capture_state+0x74/0x140 [msm] msm_disp_snapshot_state_sync+0x60/0x90 [msm] _msm_disp_snapshot_work+0x30/0x90 [msm] kthread_worker_fn+0xdc/0x460 kthread+0x120/0x140 Fixes: bac2c6a62ed9 ("drm/msm: get rid of msm_iomap_size") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/721747/ Link: https://lore.kernel.org/r/20260428-msm-fix-dsi-dump-v1-1-5d4cb5ccfac7@oss.qualcomm.com Signed-off-by: Sasha Levin commit d235f8f7b2644934a6aeac6e3e0fdc1108b3ac08 Author: Chenguang Zhao Date: Mon May 11 09:43:43 2026 +0800 ethtool: fix ethnl_bitmap32_not_zero() bit interval semantics [ Upstream commit 3d042592ebd4c7e44974d556de0b727cb7db4dab ] ethnl_bitmap32_not_zero() should return true if some bit in [start, end) is set: - Fix inverted memchr_inv() sense: return true when the scan finds a non-zero byte, not when the middle words are all zero. - Return false for an empty interval (end <= start). - When end is 32-bit aligned, indices in [start, end) do not include any bits from map[end_word]; return false after earlier checks found no non-zero data. Fixes: 10b518d4e6dd ("ethtool: netlink bitset handling") Signed-off-by: Chenguang Zhao Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d2ea0b8aef8746e147602eac87ca8538f4bc7e66 Author: Xiang Mei Date: Sun May 10 15:26:40 2026 -0700 net/smc: avoid NULL deref of conn->lnk in smc_msg_event tracepoint [ Upstream commit 7bf563badd37cb796df5477d2b78bb64148a1268 ] The smc_msg_event tracepoint class, shared by smc_tx_sendmsg and smc_rx_recvmsg, unconditionally dereferences smc->conn.lnk: __string(name, smc->conn.lnk->ibname) conn->lnk is only set for SMC-R; for SMC-D it is NULL. Other code on these paths already handles this (e.g. !conn->lnk in SMC_STAT_RMB_TX_SIZE_SMALL()). With the tracepoint enabled, the first sendmsg()/recvmsg() on an SMC-D socket crashes: Oops: general protection fault, probably for non-canonical address KASAN: null-ptr-deref in range [...] RIP: 0010:strlen+0x1e/0xa0 Call Trace: trace_event_raw_event_smc_msg_event (net/smc/smc_tracepoint.h:44) smc_rx_recvmsg (net/smc/smc_rx.c:515) smc_recvmsg (net/smc/af_smc.c:2859) __sys_recvfrom (net/socket.c:2315) __x64_sys_recvfrom (net/socket.c:2326) do_syscall_64 The faulting address 0x3e0 is offsetof(struct smc_link, ibname), confirming the NULL ->lnk deref. Enabling the tracepoint requires root, but the trigger itself is unprivileged: socket(AF_SMC, ...) has no capability check, and SMC-D negotiation needs no admin step on s390 or on x86 with the loopback ISM device loaded. Log an empty device name for SMC-D instead of dereferencing NULL. Fixes: aff3083f10bf ("net/smc: Introduce tracepoints for tx and rx msg") Reported-by: Weiming Shi Signed-off-by: Xiang Mei Reviewed-by: Dust Li Reviewed-by: Sidraya Jayagond Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 97a8e89cdef36207a8776edc03d6931763a06ad0 Author: Zack McKevitt Date: Thu Apr 30 12:39:01 2026 -0700 accel/qaic: Add overflow check to remap_pfn_range during mmap [ Upstream commit aa16b2bc0f02709919e2435f531406531e5bcc69 ] The call to remap_pfn_range in qaic_gem_object_mmap is susceptible to (re)mapping beyond the VMA if the BO is too large. This can cause use after free issues when munmap() unmaps only the VMA region and not the additional mappings. To prevent this, check the remaining size of the VMA before remapping and truncate the remapped length if sg->length is too large. Reported-by: Lukas Maar Fixes: ff13be830333 ("accel/qaic: Add datapath") Reviewed-by: Karol Wachowski Signed-off-by: Zack McKevitt Reviewed-by: Jeff Hugo [jhugo: fix braces from checkpatch --strict] Signed-off-by: Jeff Hugo Link: https://patch.msgid.link/20260430193858.1178641-1-zachary.mckevitt@oss.qualcomm.com Signed-off-by: Sasha Levin commit 76410790f1491c8e06a451045ae223a61c652455 Author: Sungwoo Kim Date: Tue May 12 01:09:29 2026 -0400 block: bio-integrity: Fix null-ptr-deref in bio_integrity_map_user() [ Upstream commit 8582792cf23b3d94674d4d838f7cde9a28d0fcaf ] pin_user_pages_fast() can partially succeed and return the number of pages that were actually pinned. However, the bio_integrity_map_user() does not handle this partial pinning. This leads to a general protection fault since bvec_from_pages() dereferences an unpinned page address, which is 0. To fix this, add a check to verify that all requested memory is pinned. If partial pinning occurs, unpin the memory and return -EFAULT. Kernel Oops: 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: 0 PID: 1061 Comm: nvme-passthroug Not tainted 7.0.0-11783-g90957f9314e8-dirty #16 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 RIP: 0010:bio_integrity_map_user.cold+0x1b0/0x9d6 Fixes: 492c5d455969 ("block: bio-integrity: directly map user buffers") Acked-by: Chao Shi Acked-by: Weidong Zhu Acked-by: Dave Tian Signed-off-by: Sungwoo Kim Tested-by: Shin'ichiro Kawasaki Link: https://github.com/linux-blktests/blktests/pull/244 Link: https://patch.msgid.link/20260512050929.541397-2-iam@sung-woo.kim Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 086695145000cc518b69811164ce4aa8e45211b1 Author: Lukas Bulwahn Date: Thu Feb 5 09:11:31 2026 +0100 HID: quirks: really enable the intended work around for appledisplay [ Upstream commit 5f90dcfa8dc32a488581b78e575cdd7808ba5c78 ] Commit c7fabe4ad921 ("HID: quirks: work around VID/PID conflict for appledisplay") intends to add a quirk for kernels built with Apple Cinema Display support, but it refers to the non-existing config option CONFIG_APPLEDISPLAY, whereas the config option for Apple Cinema Display support is named CONFIG_USB_APPLEDISPLAY. Refer to the intended config option CONFIG_USB_APPLEDISPLAY in the ifdef directive. Fixes: c7fabe4ad921 ("HID: quirks: work around VID/PID conflict for appledisplay") Signed-off-by: Lukas Bulwahn Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 0943f81e1b3176f27dbaf6db268fc69d8a94f0ba Author: Casey Chen Date: Mon May 11 15:22:30 2026 -0600 block: recompute nr_integrity_segments in blk_insert_cloned_request [ Upstream commit 2c6e6a18a37b905cb584eb0dda3ae482162a81ca ] blk_insert_cloned_request() already recomputes nr_phys_segments against the bottom queue, because "the queue settings related to segment counting may differ from the original queue." The exact same reasoning applies to integrity segments: a stacked driver's underlying queue can have tighter virt_boundary_mask, seg_boundary_mask, or max_segment_size than the top queue, in which case blk_rq_count_integrity_sg() against the bottom queue produces a different count than the cached rq->nr_integrity_segments inherited from the source request by blk_rq_prep_clone(). When the cached count is lower than the bottom queue's actual count, blk_rq_map_integrity_sg() trips BUG_ON(segments > rq->nr_integrity_segments); on dispatch. The same families of stacked setups that motivated the existing nr_phys_segments recompute -- dm-multipath fanning out to nvme-rdma in particular -- can produce this. Mirror the nr_phys_segments handling: when the request carries integrity, recompute nr_integrity_segments against the bottom queue and reject the request if it exceeds the bottom queue's max_integrity_segments. blk_rq_count_integrity_sg() and queue_max_integrity_segments() are both already available via , which blk-mq.c includes. This closes a latent gap in the stacking contract and brings the integrity-segment accounting in line with the existing phys-segment accounting. Fixes: 76c313f658d2 ("blk-integrity: improved sg segment mapping") Signed-off-by: Casey Chen Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260511212230.27511-1-cachen@purestorage.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 0d48654af4d1390c888389206cc13b51b82c30e6 Author: David Carlier Date: Mon May 11 22:51:51 2026 +0100 block: don't overwrite bip_vcnt in bio_integrity_copy_user() [ Upstream commit 637ad3a56a3b889527d1dacea6fea2a8bd648140 ] bio_integrity_add_page() already sets bip_vcnt to 1 for the bounce segment. Overwriting it with nr_vecs breaks bip_vcnt <= bip_max_vcnt on WRITE (bip_max_vcnt is 1), so the gap-merge checks in block/blk.h read past the bip_vec[] flex array. On READ the read is in bounds but lands on a saved user bvec instead of the bounce. The line was added for split propagation, but bio_integrity_clone() doesn't copy bip_vcnt and BIP_CLONE_FLAGS excludes BIP_COPY_USER. Fixes: 3991657ae707 ("block: set bip_vcnt correctly") Signed-off-by: David Carlier Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260511215151.346228-1-devnexen@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a524863944933e883ff3743d0607e84abd62f377 Author: Jakub Kicinski Date: Sun May 10 12:29:04 2026 -0700 net: shaper: reject QUEUE scope handle with missing id [ Upstream commit ce372e869f9f492f3d5aa9a0ae75ed52c61d2d6f ] net_shaper_parse_handle() does not enforce that the user provides the handle ID. For NODE the ID defaults to UNSPEC for all other cases it defaults to 0. For NETDEV 0 is the only option. For QUEUE defaulting to 0 makes less intuitive sense. Specifically because the behavior should (IMHO) be the same for all cases where there may be more than one ID (QUEUE and NODE). We should either document this as intentional or reject. I picked the latter with no strong conviction. Fixes: 4b623f9f0f59 ("net-shapers: implement NL get operation") Signed-off-by: Jakub Kicinski Link: https://patch.msgid.link/20260510192904.3987113-11-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 77ec90d41c5955b88f5c5d9ee21d0650b9fd7c12 Author: Jakub Kicinski Date: Sun May 10 12:29:03 2026 -0700 net: shaper: enforce singleton NETDEV scope with id 0 [ Upstream commit b62b29e6de6711f5918940aa6ff2bbab6d6af502 ] The NETDEV scope represents a singleton root shaper in the per-device hierarchy. All code assumes NETDEV shapers have id 0: net_shaper_default_parent() hardcodes parent->id = 0 when returning the NETDEV parent for QUEUE/NODE children, and the UAPI documentation describes NETDEV scope as "the main shaper" (singular, not plural). Make sure we reject non-0 IDs. Fixes: 4b623f9f0f59 ("net-shapers: implement NL get operation") Signed-off-by: Jakub Kicinski Link: https://patch.msgid.link/20260510192904.3987113-10-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit d7c2bbbaa2c428fbcf4697ff949de5426ae42d12 Author: Jakub Kicinski Date: Sun May 10 12:29:00 2026 -0700 net: shaper: fix undersized reply skb allocation in GROUP command [ Upstream commit 0f9a857e34d0f8c018a3e4435c6f0e92e8d2f38c ] net_shaper_group_send_reply() writes both the NET_SHAPER_A_IFINDEX attribute (via net_shaper_fill_binding()) and the nested NET_SHAPER_A_HANDLE attribute (via net_shaper_fill_handle()), but the reply skb at the call site in net_shaper_nl_group_doit() is allocated using net_shaper_handle_size(), which only accounts for the nested handle. The allocation is therefore short by nla_total_size(sizeof(u32)) (8 bytes) for the IFINDEX attribute. In practice the slab allocator rounds up the small allocation so the bug is latent, but the size accounting is wrong and could bite if the reply grew further. Introduce net_shaper_group_reply_size() that accounts for the full reply payload and use it both at the genlmsg_new() call site and in the defensive WARN_ONCE message. Fixes: 5d5d4700e75d ("net-shapers: implement NL group operation") Signed-off-by: Jakub Kicinski Link: https://patch.msgid.link/20260510192904.3987113-7-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f817ce8d1943841949a322408bf9b7ec31368ad5 Author: Jakub Kicinski Date: Sun May 10 12:28:59 2026 -0700 net: shaper: set ret to -ENOMEM when genlmsg_new() fails in group_doit [ Upstream commit 8054f85b83f42a37d482fc77ea7c9ff06a9407d9 ] genlmsg_new() alloc failure path in net_shaper_nl_group_doit() forgets to set ret before jumping to error handling. Fixes: 5d5d4700e75d ("net-shapers: implement NL group operation") Signed-off-by: Jakub Kicinski Link: https://patch.msgid.link/20260510192904.3987113-6-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 5098b223f0f0c5c18a3884a8b0ea5bd4a0c7bd75 Author: Jakub Kicinski Date: Sun May 10 12:28:57 2026 -0700 net: shaper: reject duplicate leaves in GROUP request [ Upstream commit a9a2fa1da619f276580b0d4c5d12efac89e8642b ] net_shaper_nl_group_doit() does not deduplicate NET_SHAPER_A_LEAVES entries. When userspace supplies the same leaf handle twice, the same old-parent pointer lands twice in old_nodes[]. The cleanup loop double frees the parent. Of course the same parent may still be in old_nodes[] twice if we are moving multiple of its leaves. Note that this patch also implicitly fixes the fact that the i >= leaves_count path forgets to set ret. Fixes: 5d5d4700e75d ("net-shapers: implement NL group operation") Signed-off-by: Jakub Kicinski Link: https://patch.msgid.link/20260510192904.3987113-4-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit d6128451c5918dbdd6777425e701fbf8bc5c07aa Author: Jakub Kicinski Date: Sun May 10 12:28:56 2026 -0700 net: shaper: fix trivial ordering issue in net_shaper_commit() [ Upstream commit 235fb5376139c3419f2218349f1fa2f06f24f7ad ] We should update the entry before we mark it as valid. Fixes: 93954b40f6a4 ("net-shapers: implement NL set and delete operations") Signed-off-by: Jakub Kicinski Link: https://patch.msgid.link/20260510192904.3987113-3-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit d947e6685ff4bb379dd7c5c14aaf511c689f561f Author: Jakub Kicinski Date: Sun May 10 12:28:55 2026 -0700 net: shaper: flip the polarity of the valid flag [ Upstream commit 7cee43fcb0c3f71441d2faaa8c2202b6a88b6bef ] The usual way of inserting entries which are not yet fully ready into XArray is to have a VALID flag. The shaper code has a NOT_VALID flag. Since XArray code does not let us create entries with marks already set - the creation of entries is currently not atomic. Flip the polarity of the VALID flag. This closes the tiny race in net_shaper_pre_insert() of entries being created without the NOT_VALID flag. Fixes: 93954b40f6a4 ("net-shapers: implement NL set and delete operations") Signed-off-by: Jakub Kicinski Link: https://patch.msgid.link/20260510192904.3987113-2-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit e1b429d8e712e656d25915548f621244e9fb2223 Author: Kang Yang Date: Tue Apr 28 14:17:37 2026 +0800 wifi: ath10k: skip WMI and beacon transmission when device is wedged [ Upstream commit 54a5b38e4396530e5b2f12b54d3844e860ab6784 ] In ath10k_wmi_cmd_send(), the current code detects ATH10K_STATE_WEDGED and sets ret to -ESHUTDOWN, but still proceeds to transmit pending beacons and calls ath10k_wmi_cmd_send_nowait(). This can lead to incorrect behavior, as WMI commands and beacons are still sent after the device has been marked as wedged, and the original -ESHUTDOWN return value may be overwritten by the result of the send path. The wedged state indicates the hardware is already unreliable, and no further interaction with firmware is expected or meaningful in this state. Fix this by skipping beacon transmission and the WMI send path entirely once ATH10K_STATE_WEDGED is detected, ensuring consistent return values and avoiding unnecessary firmware interaction. Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1 Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189 Fixes: c256a94d1b1b ("wifi: ath10k: shutdown driver when hardware is unreliable") Signed-off-by: Kang Yang Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260428061737.37-1-kang.yang@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit d94127d04017f48408a1d0378b173f4ce4d7f72b Author: Nicolas Escande Date: Wed May 6 15:42:40 2026 +0200 wifi: ath11k: fix error path leak in ath11k_tm_cmd_wmi_ftm() [ Upstream commit 7320d6eb861e9913193a7801834c661381756a79 ] This is similar to what was fixed by previous patches. We have a call to ath11k_wmi_cmd_send() which does check the return value, but forgot to free the related skb on error. Fixes: b43310e44edc ("wifi: ath11k: factory test mode support") Signed-off-by: Nicolas Escande Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260506134240.2284016-4-nico.escande@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit acde4692afcdaea6de3e2996ddfaeaa7ae6b0130 Author: Nicolas Escande Date: Wed May 6 15:42:38 2026 +0200 wifi: ath11k: fix error path leaks in some WMI WOW calls [ Upstream commit 55dda532bbc261aef495e403c8900c5e2ab5fa34 ] Fix two instances where we used to directly return the result of ath11k_wmi_cmd_send(...). Because we did not check the return value, we also did not free the skb in the error path. Fixes: 79802b13a492 ("ath11k: implement WoW enable and wakeup commands") Signed-off-by: Nicolas Escande Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260506134240.2284016-2-nico.escande@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 9bc70fe995da15dab1de93174f8a7e6db9b55c88 Author: Ethan Nelson-Moore Date: Fri May 8 19:37:28 2026 -0700 net: ethernet: cs89x0: remove stale CONFIG_MACH_MX31ADS reference [ Upstream commit 36a8d04a8293afcb9304cf0cd3741f67698f2a1a ] The legacy ARM board file for MACH_MX31ADS was removed in commit c93197b0041d ("ARM: imx: Remove i.MX31 board files"), but a reference to it remained in the cs89x0 driver. Drop this unused code. Signed-off-by: Ethan Nelson-Moore Fixes: c93197b0041d ("ARM: imx: Remove i.MX31 board files") Link: https://patch.msgid.link/20260509023732.42256-1-enelsonmoore@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c373b34877afea61c89e0dd2e38948c624249b9b Author: Linus Walleij Date: Sat May 9 00:13:38 2026 +0200 net: ethernet: cortina: Carry over frag counter [ Upstream commit ebd8ec2b309e3a447851b456ccaf8fb39f3661e7 ] The gmac_rx() NAPI poll function assembles packets in an SKB from a ring buffer. If the ring buffer gets completely emptied during a poll cycle, we exit gmac_rx(), but the packet is not yet completely assembled in the SKB, yet the fragment counter frag_nr is reset to zero on the next invocation. Solve this by making the RX fragment counter a part of the port struct, and carry it over between invocations. Reset the fragment counter only right after calling napi_gro_frags(), on error (after calling napi_free_frags()) or if stopping the port. Reset it in some place where not strictly necessary just to emphasize what is going on. This was found by Sashiko during normal patch review. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Link: https://sashiko.dev/#/patchset/20260505-gemini-ethernet-fix-v2-1-997c31d06079%40kernel.org Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260509-gemini-ethernet-fixes-v1-3-6c5d20ddc35b@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 3cd05250a2dfa9f17035f51a0b23d0b70dfa9209 Author: Andreas Haarmann-Thiemann Date: Tue May 5 23:52:17 2026 +0200 net: ethernet: cortina: Drop half-assembled SKB [ Upstream commit b266bacba796ff5c4dcd2ae2fc08aacf7ab39153 ] In gmac_rx() (drivers/net/ethernet/cortina/gemini.c), when gmac_get_queue_page() returns NULL for the second page of a multi-page fragment, the driver logs an error and continues — but does not free the partially assembled skb that was being assembled via napi_build_skb() / napi_get_frags(). Free the in-progress partially assembled skb via napi_free_frags() and increase the number of dropped frames appropriately and assign the skb pointer NULL to make sure it is not lingering around, matching the pattern already used elsewhere in the driver. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Signed-off-by: Andreas Haarmann-Thiemann Signed-off-by: Linus Walleij Reviewed-by: Alexander Lobakin Link: https://patch.msgid.link/20260505-gemini-ethernet-fix-v2-1-997c31d06079@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cfd62907f3cdbc3b6da8f49ba907c0390018fe5e Author: Linus Walleij Date: Sat May 9 00:13:37 2026 +0200 net: ethernet: cortina: Make RX SKB per-port [ Upstream commit 06937db21ee311ed07eba47954447245041a982d ] The SKB used to assemble packets from fragments in gmac_rx() is static local, but the Gemini has two ethernet ports, meaning there can be races between the ports on a bad day if a device is using both. Make the RX SKB a per-port variable and carry it over between invocations in the port struct instead. Zero the pointer once we call napi_gro_frags(), on error (after calling napi_free_frags()) or if the port is stopped. Zero it in some place where not strictly necessary just to emphasize what is going on. This was found by Sashiko during normal patch review. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Link: https://sashiko.dev/#/patchset/20260505-gemini-ethernet-fix-v2-1-997c31d06079%40kernel.org Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260509-gemini-ethernet-fixes-v1-2-6c5d20ddc35b@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 77bb293049d61e04c12b24ebbffafaf5ab36af90 Author: David Howells Date: Tue May 12 13:34:00 2026 +0100 netfs, afs: Fix write skipping in dir/link writepages [ Upstream commit 9871938f99cc6cb266a77265491660e2375271f5 ] Fix netfs_write_single() and afs_single_writepages() to better handle a write that would be skipped due to lock contention and WB_SYNC_NONE by returning 1 from netfs_write_single() if it skipped and making afs_single_writepages() skip also. If a skip occurs, the inode must be re-marked as the VFS may have cleared the mark. This is really only theoretical for directories in netfs_write_single() as the only path to that is through afs_single_writepages() that takes the ->validate_lock around it, thereby serialising it. Fixes: 6dd80936618c ("afs: Use netfslib for directories") Signed-off-by: David Howells Link: https://patch.msgid.link/20260512123404.719402-24-dhowells@redhat.com cc: Marc Dionne cc: linux-afs@lists.infradead.org cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit f17b9121bb99f88188ec9be2db5da1d561f4c01b Author: David Howells Date: Tue May 12 13:33:59 2026 +0100 netfs: Fix netfs_read_folio() to wait on writeback [ Upstream commit ded0c6f1606061148c202825f7e53d711f9f84cf ] Fix netfs_read_folio() to wait for an ongoing writeback to complete so that it can trust the dirty flag and whatever is attached to folio->private (folio->private may get cleaned up by the collector before it clears the writeback flag). Fixes: ee4cdf7ba857 ("netfs: Speed up buffered reading") Closes: https://sashiko.dev/#/patchset/20260414082004.3756080-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260512123404.719402-23-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 Signed-off-by: Sasha Levin commit 551b5c71ee312ca7646ddb605231c1016e8cbb18 Author: David Howells Date: Tue May 12 13:33:58 2026 +0100 netfs: Fix folio->private handling in netfs_perform_write() [ Upstream commit ccde2ac757c713535b224233a296de40efe5212d ] Under some circumstances, netfs_perform_write() doesn't correctly manipulate folio->private between NULL, NETFS_FOLIO_COPY_TO_CACHE, pointing to a group and pointing to a netfs_folio struct, leading to potential multiple attachments of private data with associated folio ref leaks and also leaks of netfs_folio structs or netfs_group refs. Fix this by consolidating the place at which a folio is marked uptodate in one place and having that look at what's attached to folio->private and decide how to clean it up and then set the new group. Also, the content shouldn't be flushed if group is NULL, even if a group is specified in the netfs_group parameter, as that would be the case for a new folio. A filesystem should always specify netfs_group or never specify netfs_group. The Sashiko auto-review tool noted that it was theoretically possible that the fpos >= ctx->zero_point section might leak if it modified a streaming write folio. This is unlikely, but with a network filesystem, third party changes can happen. It also pointed out that __netfs_set_group() would leak if called multiple times on the same folio from the "whole folio modify section". Fixes: 8f52de0077ba ("netfs: Reduce number of conditional branches in netfs_perform_write()") Closes: https://sashiko.dev/#/patchset/20260414082004.3756080-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260512123404.719402-22-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 Signed-off-by: Sasha Levin commit 3d9601c029b934b5b6a10f99791467b10eb6b211 Author: David Howells Date: Tue May 12 13:33:57 2026 +0100 netfs: Fix partial invalidation of streaming-write folio [ Upstream commit 6d91acc7fb85d33ea58fca9b964a32a453937f4b ] In netfs_invalidate_folio(), if the region of a partial invalidation overlaps the front (but not all) of a dirty write cached in a streaming write page (dirty, but not uptodate, with the dirty region tracked by a netfs_folio struct), the function modifies the dirty region - but incorrectly as it moves the region forward by setting the start to the start, not the end, of the invalidation region. Fix this by setting finfo->dirty_offset to the end of the invalidation region (iend). Fixes: cce6bfa6ca0e ("netfs: Fix trimming of streaming-write folios in netfs_inval_folio()") Closes: https://sashiko.dev/#/patchset/20260414082004.3756080-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260512123404.719402-21-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 Signed-off-by: Sasha Levin commit 6080fa3ecfbb4448a3b47368629534c09b6ec750 Author: David Howells Date: Tue May 12 13:33:56 2026 +0100 netfs: Fix potential UAF in netfs_unlock_abandoned_read_pages() [ Upstream commit dbe556972100fabb8e5a1b3d2163831ff07b1e8e ] netfs_unlock_abandoned_read_pages(rreq) accesses the index of the folios it is wanting to unlock and compares that to rreq->no_unlock_folio so that it doesn't unlock a folio being read for netfs_perform_write() or netfs_write_begin(). However, given that netfs_unlock_abandoned_read_pages() is called _after_ NETFS_RREQ_IN_PROGRESS is cleared, the one folio that it's not allowed to dereference is the one specified by ->no_unlock_folio as ownership immediately reverts to the caller. Fix this by storing the folio pointer instead and using that rather than the index. Also fix netfs_unlock_read_folio() where the same applies. Fixes: ee4cdf7ba857 ("netfs: Speed up buffered reading") Closes: https://sashiko.dev/#/patchset/20260414082004.3756080-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260512123404.719402-20-dhowells@redhat.com cc: Paulo Alcantara cc: Viacheslav Dubeyko cc: Matthew Wilcox cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 22ae28aae43623be235ff455558cdd13fbe2daeb Author: David Howells Date: Tue May 12 13:33:55 2026 +0100 netfs: Fix leak of request in netfs_write_begin() error handling [ Upstream commit 5046a34f0643441f05b0253ea64e1a3af87efe14 ] Fix netfs_write_begin() to not leak our ref on the request in the event that we get an error from netfs_wait_for_read(). Fixes: 4090b31422a6 ("netfs: Add a function to consolidate beginning a read") Closes: https://sashiko.dev/#/patchset/20260414082004.3756080-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260512123404.719402-19-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 Signed-off-by: Sasha Levin commit d4f4bc87c76511cf2532448b0fa40c25e894bd7d Author: David Howells Date: Tue May 12 13:33:54 2026 +0100 netfs: Fix early put of sink folio in netfs_read_gaps() [ Upstream commit 3e5dd91b87a8b1450217b56a336bee315f40da7d ] Fix netfs_read_gaps() to release the sink page it uses after waiting for the request to complete. The way the sink page is used is that an ITER_BVEC-class iterator is created that has the gaps from the target folio at either end, but has the sink page tiled over the middle so that a single read op can fill in both gaps. The bug was found by KASAN detecting a UAF on the generic/075 xfstest in the cifsd kernel thread that handles reception of data from the TCP socket: BUG: KASAN: use-after-free in _copy_to_iter+0x48a/0xa20 Write of size 885 at addr ffff888107f92000 by task cifsd/1285 CPU: 2 UID: 0 PID: 1285 Comm: cifsd Not tainted 7.0.0 #6 PREEMPT(lazy) Call Trace: dump_stack_lvl+0x5d/0x80 print_report+0x17f/0x4f1 kasan_report+0x100/0x1e0 kasan_check_range+0x10f/0x1e0 __asan_memcpy+0x3c/0x60 _copy_to_iter+0x48a/0xa20 __skb_datagram_iter+0x2c9/0x430 skb_copy_datagram_iter+0x6e/0x160 tcp_recvmsg_locked+0xce0/0x1130 tcp_recvmsg+0xeb/0x300 inet_recvmsg+0xcf/0x3a0 sock_recvmsg+0xea/0x100 cifs_readv_from_socket+0x3a6/0x4d0 [cifs] cifs_read_iter_from_socket+0xdd/0x130 [cifs] cifs_readv_receive+0xaad/0xb10 [cifs] cifs_demultiplex_thread+0x1148/0x1740 [cifs] kthread+0x1cf/0x210 Fixes: ee4cdf7ba857 ("netfs: Speed up buffered reading") Reported-by: Steve French Signed-off-by: David Howells Link: https://patch.msgid.link/20260512123404.719402-18-dhowells@redhat.com Reviewed-by: Paulo Alcantara (Red Hat) cc: Paulo Alcantara cc: Matthew Wilcox cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 616578e40dcba3f94810d841c5a52b7e3bc8ede7 Author: David Howells Date: Tue May 12 13:33:53 2026 +0100 netfs: Fix write streaming disablement if fd open O_RDWR [ Upstream commit 70a7b9193bbbfceaab5974de66834c64ccc875dd ] In netfs_perform_write(), "write streaming" (the caching of dirty data in dirty but !uptodate folios) is performed to avoid the need to read data that is just going to get immediately overwritten. However, this is/will be disabled in three circumstances: if the fd is open O_RDWR, if fscache is in use (as we need to round out the blocks for DIO) or if content encryption is enabled (again for rounding out purposes). The idea behind disabling it if the fd is open O_RDWR is that we'd need to flush the write-streaming page before we could read the data, particularly through mmap. But netfs now fills in the gaps if ->read_folio() is called on the page, so that is unnecessary. Further, this doesn't actually work if a separate fd is open for reading. Fix this by removing the check for O_RDWR, thereby allowing streaming writes even when we might read. This caused a number of problems with the generic/522 xfstest, but those are now fixed. Fixes: c38f4e96e605 ("netfs: Provide func to copy data to pagecache for buffered write") Signed-off-by: David Howells Link: https://patch.msgid.link/20260512123404.719402-17-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 Signed-off-by: Sasha Levin commit 0b18cd70ebab7ea13e9883e4e9a62011e65c7d3b Author: David Howells Date: Tue May 12 13:33:52 2026 +0100 netfs: Fix read-gaps to remove netfs_folio from filled folio [ Upstream commit a41168aef634356a9b87ec44349e3c82835700a5 ] Fix netfs_read_gaps() to remove the netfs_folio record from the folio record before marking the folio uptodate if it successfully fills the gaps around the dirty data in a streaming write folio (dirty, but not uptodate). Found with: fsx -q -N 1000000 -p 10000 -o 128000 -l 600000 \ /xfstest.test/junk --replay-ops=junk.fsxops using the following as junk.fsxops: truncate 0x0 0x138b1 0x8b15d * write 0x507ee 0x10df7 0x927c0 write 0x19993 0x10e04 0x927c0 * mapwrite 0x66214 0x1a253 0x927c0 copy_range 0xb704 0x89b9 0x24429 0x79380 write 0x2402b 0x144a2 0x90660 * mapwrite 0x204d5 0x140a0 0x927c0 * copy_range 0x1f72c 0x137d0 0x7a906 0x927c0 * read 0 0x9157c 0x9157c on cifs with the default cache option. It shows folio 0x24 misbehaving if the FMODE_READ check is commented out in netfs_perform_write(): if (//(file->f_mode & FMODE_READ) || netfs_is_cache_enabled(ctx)) { and no fscache. This was initially found with the generic/522 xfstest. Signed-off-by: David Howells Link: https://patch.msgid.link/20260512123404.719402-16-dhowells@redhat.com Fixes: ee4cdf7ba857 ("netfs: Speed up buffered reading") cc: Paulo Alcantara cc: Matthew Wilcox cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 003aa0dd26c964025acd6d1213bcdbd674db2ca9 Author: David Howells Date: Tue May 12 13:33:51 2026 +0100 netfs: Fix potential deadlock in write-through mode [ Upstream commit b6a4ae1634b3ad2aaa05222e53d36da532852faf ] Fix netfs_advance_writethrough() to always unlock the supplied folio and to mark it dirty if it isn't yet written to the end. Unfortunately, it can't be marked for writeback until the folio is done with as that may cause a deadlock against mmapped reads and writes. Even though it has been marked dirty, premature writeback can't occur as the caller is holding both inode->i_rwsem (which will prevent concurrent truncation, fallocation, DIO and other writes) and ictx->wb_lock (which will cause flushing to wait and writeback to skip or wait). Note that this may be easier to deal with once the queuing of folios is split from the generation of subrequests. Fixes: 288ace2f57c9 ("netfs: New writeback implementation") Closes: https://sashiko.dev/#/patchset/20260427154639.180684-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260512123404.719402-15-dhowells@redhat.com cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit ef9b521212e4863814ef7dfe19889abaf55ca840 Author: David Howells Date: Tue May 12 13:33:50 2026 +0100 netfs: Fix streaming write being overwritten [ Upstream commit 7b4dcf1b9455a6e52ac7478b4057dbe10359576d ] In order to avoid reading whilst writing, netfslib will allow "streaming writes" in which dirty data is stored directly into folios without reading them first. Such folios are marked dirty but may not be marked uptodate. If a folio is entirely written by a streaming write, uptodate will be set, otherwise it will have a netfs_folio struct attached to ->private recording the dirty region. In the event that a partially written streaming write page is to be overwritten entirely by a single write(), netfs_perform_write() will try to copy over it, but doesn't discard the netfs_folio if it succeeds; further, it doesn't correctly handle a partial copy that overwrites some of the dirty data. Fix this by the following: (1) If the folio is successfully overwritten, free the netfs_folio struct before marking the page uptodate. (2) If the copy to the folio partially fails, but short of the dirty data, just ignore the copy. (3) If the copy partially fails and overwrites some of the dirty data, accept the copy, update the netfs_folio struct to record the new data. If the folio is now filled, free the netfs_folio and set uptodate, otherwise return a partial write. Found with: fsx -q -N 1000000 -p 10000 -o 128000 -l 600000 \ /xfstest.test/junk --replay-ops=junk.fsxops using the following as junk.fsxops: truncate 0x0 0 0x927c0 write 0x63fb8 0x53c8 0 copy_range 0xb704 0x19b9 0x24429 0x79380 write 0x2402b 0x144a2 0x90660 * write 0x204d5 0x140a0 0x927c0 * copy_range 0x1f72c 0x137d0 0x7a906 0x927c0 * read 0x00000 0x20000 0x9157c read 0x20000 0x20000 0x9157c read 0x40000 0x20000 0x9157c read 0x60000 0x20000 0x9157c read 0x7e1a0 0xcfb9 0x9157c on cifs with the default cache option. It shows folio 0x24 misbehaving if the FMODE_READ check is commented out in netfs_perform_write(): if (//(file->f_mode & FMODE_READ) || netfs_is_cache_enabled(ctx)) { and no fscache. This was initially found with the generic/522 xfstest. Fixes: 8f52de0077ba ("netfs: Reduce number of conditional branches in netfs_perform_write()") Signed-off-by: David Howells Link: https://patch.msgid.link/20260512123404.719402-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 Signed-off-by: Sasha Levin commit 185ded4112cd4e2969ca2b80e83caefb94a353fc Author: David Howells Date: Tue May 12 13:33:49 2026 +0100 netfs: Defer the emission of trace_netfs_folio() [ Upstream commit daeb443b92817021c1234e8eded219e164b7c35d ] Change netfs_perform_write() to keep the netfs_folio trace value in a variable and emit it later to make it easier to choose the value displayed. This is a prerequisite for a subsequent patch. Closes: https://sashiko.dev/#/patchset/20260414082004.3756080-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260512123404.719402-13-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 Stable-dep-of: 7b4dcf1b9455 ("netfs: Fix streaming write being overwritten") Signed-off-by: Sasha Levin commit fb6ec883b48b8789e5e690dcd440d2db941e840c Author: David Howells Date: Tue May 12 13:33:48 2026 +0100 netfs: Fix netfs_invalidate_folio() to clear dirty bit if all changes gone [ Upstream commit 156ac2ec2ee77c44c4eb7439d6d165247ba12247 ] If a streaming write is made, this will leave the relevant modified folio in a not-uptodate, but dirty state with a netfs_folio struct hung off of folio->private indicating the dirty range. Subsequently truncating the file such that the dirty data in the folio is removed, but the first part of the folio theoretically remains will cause the netfs_folio struct to be discarded... but will leave the dirty flag set. If the folio is then read via mmap(), netfs_read_folio() will see that the page is dirty and jump to netfs_read_gaps() to fill in the missing bits. netfs_read_gaps(), however, expects there to be a netfs_folio struct present and can oops because truncate removed it. Fix this by calling folio_cancel_dirty() in netfs_invalidate_folio() in the event that all the dirty data in the folio is erased (as nfs does). Also add some tracepoints to log modifications to a dirty page. This can be reproduced with something like: dd if=/dev/zero of=/xfstest.test/foo bs=1M count=1 umount /xfstest.test mount /xfstest.test xfs_io -c "w 0xbbbf 0xf96c" \ -c "truncate 0xbbbf" \ -c "mmap -r 0xb000 0x11000" \ -c "mr 0xb000 0x11000" \ /xfstest.test/foo with fscaching disabled (otherwise streaming writes are suppressed) and a change to netfs_perform_write() to disallow streaming writes if the fd is open O_RDWR: if (//(file->f_mode & FMODE_READ) || <--- comment this out netfs_is_cache_enabled(ctx)) { It should be reproducible even without this change, but if prevents the above trivial xfs_io command from reproducing it. Note that the initial dd is important: the file must start out sufficiently large that the zero-point logic doesn't just clear the gaps because it knows there's nothing in the file to read yet. Unmounting and mounting is needed to clear the pagecache (there are other ways to do that that may also work). This was initially reproduced with the generic/522 xfstest on some patches that remove the FMODE_READ restriction. Fixes: 9ebff83e6481 ("netfs: Prep to use folio->private for write grouping and streaming write") Reported-by: Marc Dionne Signed-off-by: David Howells Link: https://patch.msgid.link/20260512123404.719402-12-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 Signed-off-by: Sasha Levin commit afeb32d9bf9aaeea51d0f723a19f14afb73bd94d Author: David Howells Date: Tue May 12 13:33:47 2026 +0100 netfs: Fix overrun check in netfs_extract_user_iter() [ Upstream commit 0ef37eef83fad3542ee06db2940433ae1a92b39d ] Fix netfs_extract_user_iter() so that if iov_iter_extract_pages() overfills pages[], then those pages don't get included in the iterator constructed at the end of the function. If there was an overfill, memory corruption has already happened. Fixes: 85dd2c8ff368 ("netfs: Add a function to extract a UBUF or IOVEC into a BVEC iterator") Closes: https://sashiko.dev/#/patchset/20260427154639.180684-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260512123404.719402-11-dhowells@redhat.com cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit b63971238beb79cf701dac33c6cefc56c07c89fa Author: Viacheslav Dubeyko Date: Tue May 12 13:33:44 2026 +0100 netfs: fix VM_BUG_ON_FOLIO() issue in netfs_write_begin() call [ Upstream commit dc7832d05deb4d632e8035e3299e31a3528fa0d0 ] The multiple runs of generic/013 test-case is capable to reproduce a kernel BUG at mm/filemap.c:1504 with probability of 30%. while true; do sudo ./check generic/013 done [ 9849.452376] page: refcount:3 mapcount:0 mapping:00000000e58ff252 index:0x10781 pfn:0x1c322 [ 9849.452412] memcg:ffff8881a1915800 [ 9849.452417] aops:ceph_aops ino:1000058db9e dentry name(?):"f9XXXXXX" [ 9849.452432] flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff) [ 9849.452441] raw: 0017ffffc0000000 0000000000000000 dead000000000122 ffff88816110d248 [ 9849.452445] raw: 0000000000010781 0000000000000000 00000003ffffffff ffff8881a1915800 [ 9849.452447] page dumped because: VM_BUG_ON_FOLIO(!folio_test_locked(folio)) [ 9849.452474] ------------[ cut here ]------------ [ 9849.452476] kernel BUG at mm/filemap.c:1504! [ 9849.478635] Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI [ 9849.481772] CPU: 2 UID: 0 PID: 84223 Comm: fsstress Not tainted 7.0.0-rc1+ #18 PREEMPT(full) [ 9849.482881] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-9.fc43 06/1 0/2025 [ 9849.484539] RIP: 0010:folio_unlock+0x85/0xa0 [ 9849.485076] Code: 89 df 31 f6 e8 1c f3 ff ff 48 8b 5d f8 c9 31 c0 31 d2 31 f6 31 ff c3 cc cc cc cc 48 c7 c6 80 6c d9 a7 48 89 df e8 4b b3 10 00 <0f> 0b 48 89 df e8 21 e6 2c 00 eb 9d 0f 1f 40 00 66 66 2e 0f 1f 84 [ 9849.493818] RSP: 0018:ffff8881bb8076b0 EFLAGS: 00010246 [ 9849.495740] RAX: 0000000000000000 RBX: ffffea00070c8980 RCX: 0000000000000000 [ 9849.498678] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 9849.500559] RBP: ffff8881bb8076b8 R08: 0000000000000000 R09: 0000000000000000 [ 9849.501097] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000010782000 [ 9849.502108] R13: ffff8881935de738 R14: ffff88816110d010 R15: 0000000000001000 [ 9849.502516] FS: 00007e36cbe94740(0000) GS:ffff88824a899000(0000) knlGS:0000000000000000 [ 9849.502996] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9849.503810] CR2: 000000c0002b0000 CR3: 000000011bbf6004 CR4: 0000000000772ef0 [ 9849.504459] PKRU: 55555554 [ 9849.504626] Call Trace: [ 9849.505242] [ 9849.505379] netfs_write_begin+0x7c8/0x10a0 [ 9849.505877] ? __kasan_check_read+0x11/0x20 [ 9849.506384] ? __pfx_netfs_write_begin+0x10/0x10 [ 9849.507178] ceph_write_begin+0x8c/0x1c0 [ 9849.507934] generic_perform_write+0x391/0x8f0 [ 9849.508503] ? __pfx_generic_perform_write+0x10/0x10 [ 9849.509062] ? file_update_time_flags+0x19a/0x4b0 [ 9849.509581] ? ceph_get_caps+0x63/0xf0 [ 9849.510259] ? ceph_get_caps+0x63/0xf0 [ 9849.510530] ceph_write_iter+0xe79/0x1ae0 [ 9849.511282] ? __pfx_ceph_write_iter+0x10/0x10 [ 9849.511839] ? lock_acquire+0x1ad/0x310 [ 9849.512334] ? ksys_write+0xf9/0x230 [ 9849.512582] ? lock_is_held_type+0xaa/0x140 [ 9849.513128] vfs_write+0x512/0x1110 [ 9849.513634] ? __fget_files+0x33/0x350 [ 9849.513893] ? __pfx_vfs_write+0x10/0x10 [ 9849.514143] ? mutex_lock_nested+0x1b/0x30 [ 9849.514394] ksys_write+0xf9/0x230 [ 9849.514621] ? __pfx_ksys_write+0x10/0x10 [ 9849.514887] ? do_syscall_64+0x25e/0x1520 [ 9849.515122] ? __kasan_check_read+0x11/0x20 [ 9849.515366] ? trace_hardirqs_on_prepare+0x178/0x1c0 [ 9849.515655] __x64_sys_write+0x72/0xd0 [ 9849.515885] ? trace_hardirqs_on+0x24/0x1c0 [ 9849.516130] x64_sys_call+0x22f/0x2390 [ 9849.516341] do_syscall_64+0x12b/0x1520 [ 9849.516545] ? do_syscall_64+0x27c/0x1520 [ 9849.516783] ? do_syscall_64+0x27c/0x1520 [ 9849.517003] ? lock_release+0x318/0x480 [ 9849.517220] ? __x64_sys_io_getevents+0x143/0x2d0 [ 9849.517479] ? percpu_ref_put_many.constprop.0+0x8f/0x210 [ 9849.517779] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 9849.518073] ? do_syscall_64+0x25e/0x1520 [ 9849.518291] ? __kasan_check_read+0x11/0x20 [ 9849.518519] ? trace_hardirqs_on_prepare+0x178/0x1c0 [ 9849.518799] ? do_syscall_64+0x27c/0x1520 [ 9849.519024] ? local_clock_noinstr+0xf/0x120 [ 9849.519262] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 9849.519544] ? do_syscall_64+0x25e/0x1520 [ 9849.519781] ? __kasan_check_read+0x11/0x20 [ 9849.520008] ? trace_hardirqs_on_prepare+0x178/0x1c0 [ 9849.520273] ? do_syscall_64+0x27c/0x1520 [ 9849.520491] ? trace_hardirqs_on_prepare+0x178/0x1c0 [ 9849.520767] ? irqentry_exit+0x10c/0x6c0 [ 9849.520984] ? trace_hardirqs_off+0x86/0x1b0 [ 9849.521224] ? exc_page_fault+0xab/0x130 [ 9849.521472] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 9849.521766] RIP: 0033:0x7e36cbd14907 [ 9849.521989] Code: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 [ 9849.523057] RSP: 002b:00007ffff2d2a968 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 9849.523484] RAX: ffffffffffffffda RBX: 000000000000e549 RCX: 00007e36cbd14907 [ 9849.523885] RDX: 000000000000e549 RSI: 00005bd797ec6370 RDI: 0000000000000004 [ 9849.524277] RBP: 0000000000000004 R08: 0000000000000047 R09: 00005bd797ec6370 [ 9849.524652] R10: 0000000000000078 R11: 0000000000000246 R12: 0000000000000049 [ 9849.525062] R13: 0000000010781a37 R14: 00005bd797ec6370 R15: 0000000000000000 [ 9849.525447] [ 9849.525574] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass ghash_clmulni_intel aesni_intel input_leds rapl mac_hid psmouse vga16fb serio_raw vgastate floppy i2c_piix4 bochs qemu_fw_cfg i2c_smbus pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 9849.529150] ---[ end trace 0000000000000000 ]--- [ 9849.529502] RIP: 0010:folio_unlock+0x85/0xa0 [ 9849.530813] Code: 89 df 31 f6 e8 1c f3 ff ff 48 8b 5d f8 c9 31 c0 31 d2 31 f6 31 ff c3 cc cc cc cc 48 c7 c6 80 6c d9 a7 48 89 df e8 4b b3 10 00 <0f> 0b 48 89 df e8 21 e6 2c 00 eb 9d 0f 1f 40 00 66 66 2e 0f 1f 84 [ 9849.534986] RSP: 0018:ffff8881bb8076b0 EFLAGS: 00010246 [ 9849.536198] RAX: 0000000000000000 RBX: ffffea00070c8980 RCX: 0000000000000000 [ 9849.537718] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 9849.539321] RBP: ffff8881bb8076b8 R08: 0000000000000000 R09: 0000000000000000 [ 9849.540862] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000010782000 [ 9849.542438] R13: ffff8881935de738 R14: ffff88816110d010 R15: 0000000000001000 [ 9849.543996] FS: 00007e36cbe94740(0000) GS:ffff88824b899000(0000) knlGS:0000000000000000 [ 9849.545854] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9849.547092] CR2: 00007e36cb3ff000 CR3: 000000011bbf6006 CR4: 0000000000772ef0 [ 9849.548679] PKRU: 55555554 The race sequence: 1. Read completes -> netfs_read_collection() runs 2. netfs_wake_rreq_flag(rreq, NETFS_RREQ_IN_PROGRESS, ...) 3. netfs_wait_for_read() returns -EFAULT to netfs_write_begin() 4. The netfs_unlock_abandoned_read_pages() unlocks the folio 5. netfs_write_begin() calls folio_unlock(folio) -> VM_BUG_ON_FOLIO() The key reason of the issue that netfs_unlock_abandoned_read_pages() doesn't check the flag NETFS_RREQ_NO_UNLOCK_FOLIO and executes folio_unlock() unconditionally. This patch implements in netfs_unlock_abandoned_read_pages() logic similar to netfs_unlock_read_folio(). Fixes: ee4cdf7ba857 ("netfs: Speed up buffered reading") Signed-off-by: Viacheslav Dubeyko Signed-off-by: David Howells Link: https://patch.msgid.link/20260512123404.719402-8-dhowells@redhat.com Reviewed-by: Paulo Alcantara (Red Hat) cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org cc: Ceph Development Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 884c4c4f35e577aba6a0593c80cbea9ca5e6e2b8 Author: David Howells Date: Tue May 12 13:33:41 2026 +0100 netfs: Fix netfs_read_to_pagecache() to pause on subreq failure [ Upstream commit 8a8c0cfdf4658fc5b295b7fc87be56e0d76741f4 ] Fix netfs_read_to_pagecache() so that it pauses the generation of new subrequests if an already-issued subrequest fails. Fixes: ee4cdf7ba857 ("netfs: Speed up buffered reading") Closes: https://sashiko.dev/#/patchset/20260425125426.3855807-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260512123404.719402-5-dhowells@redhat.com cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 5366199be46fb53de62861721d34ba816e7e440e Author: David Howells Date: Tue May 12 13:33:38 2026 +0100 netfs: Fix cancellation of a DIO and single read subrequests [ Upstream commit 6f0f7ac1915abc0d202f0eb4b003a6548a5ba60d ] When the preparation of a new subrequest for a read fails, if the subrequest has already been added to the stream->subrequests list, it can't simply be put and abandoned as the collector may see it. Also, if it hasn't been queued yet, it has two outstanding refs that both need to be put. Both DIO read and single-read dispatch fail at this; further, both differ in the order they do things to the way buffered read works. Fix cancellation of both DIO-read and single-read subrequests that failed preparation by the following steps: (1) Harmonise all three reads (buffered, dio, single) to queue the subreq before prepping it. (2) Make all three call netfs_queue_read() to do the queuing. (3) Set NETFS_RREQ_ALL_QUEUED independently of the queuing as we don't know the length of the subreq at this point. (4) In all cases, set the error and NETFS_SREQ_FAILED flag on the subreq and then call netfs_read_subreq_terminated() to deal with it. This will pass responsibility off to the collector for dealing with it. Fixes: e2d46f2ec332 ("netfs: Change the read result collector to only use one work item") Closes: https://sashiko.dev/#/patchset/20260425125426.3855807-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260512123404.719402-2-dhowells@redhat.com cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 9c6f23cf3a07483ae180a382cea8cf33b45df1f9 Author: Julian Braha Date: Sun Apr 5 17:15:45 2026 +0100 powerpc: fix dead default for GUEST_STATE_BUFFER_TEST [ Upstream commit aef656a0e6c01796190bb5bd2bdba1c644ed7811 ] The GUEST_STATE_BUFFER_TEST config option should default to KUNIT_ALL_TESTS so that if all tests are enabled then it is included, but currently the 'default KUNIT_ALL_TESTS' statement is shadowed by 'def_tristate n', meaning that this second default statement is currently dead code. It looks to me like the commit 6ccbbc33f06a ("KVM: PPC: Add helper library for Guest State Buffers") intended to set the default to KUNIT_ALL_TESTS, but mistakenly missed the def_tristate. This dead code was found by kconfirm, a static analysis tool for Kconfig. Fixes: 6ccbbc33f06a ("KVM: PPC: Add helper library for Guest State Buffers") Signed-off-by: Julian Braha Tested-by: Gautam Menghani Reviewed-by: Amit Machhiwal Reviewed-by: Harsh Prateek Bora Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260405161545.161006-1-julianbraha@gmail.com Signed-off-by: Sasha Levin commit 822bb1614ec4198562a6ce86dbcbab684e260595 Author: Ally Heev Date: Sun Nov 16 19:55:44 2025 +0530 powerpc: 82xx: fix uninitialized pointers with free attribute [ Upstream commit acd1e47db03d4b528fd5efb8565dd0de1c79f62a ] Uninitialized pointers with `__free` attribute can cause undefined behavior as the memory allocated to the pointer is freed automatically when the pointer goes out of scope. powerpc/km82xx doesn't have any bugs related to this as of now, but, it is better to initialize and assign pointers with `__free` attribute in one statement to ensure proper scope-based cleanup Reported-by: Dan Carpenter Closes: https://lore.kernel.org/all/aPiG_F5EBQUjZqsl@stanley.mountain/ Signed-off-by: Ally Heev Fixes: 4aa5cc1e0012 ("powerpc-km82xx.c: replace of_node_put() with __free") Reviewed-by: Christophe Leroy (CS GROUP) Reviewed-by: Krzysztof Kozlowski Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20251116-aheev-uninitialized-free-attr-km82xx-v2-1-4307e2b5300d@gmail.com Signed-off-by: Sasha Levin commit aed60070ed7b072f71f048c99e6e76145ddc1224 Author: Mario Limonciello Date: Mon May 11 10:36:36 2026 -0500 ASoC: SOF: amd: Fix error code handling in psp_send_cmd() [ Upstream commit 2c7b1227e582e88db7917412dca4e752c1aff691 ] The smn_read_register() helper returns negative error codes on failure or the register value on success. When used with read_poll_timeout(), the return value is stored in the 'data' variable. Currently 'data' is declared as u32, which causes negative error codes to be cast to large positive values. This makes the condition 'data > 0' incorrectly treat errors as success. Fix by changing 'data' from u32 to int, matching the pattern used in psp_mbox_ready() which correctly handles the same helper function. Reported-by: Dan Carpenter Closes: https://lore.kernel.org/linux-sound/agGES8vWrLOrBu28@stanley.mountain/ Fixes: f120cf33d232 ("ASoC: SOF: amd: Use AMD_NODE") Signed-off-by: Mario Limonciello Link: https://patch.msgid.link/20260511153638.724810-1-mario.limonciello@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 510db031ba6eb40134f84c90ef963ea4b6dfb878 Author: Kuniyuki Iwashima Date: Fri May 8 12:08:46 2026 +0000 tcp: Fix out-of-bounds access for twsk in tcp_ao_established_key(). [ Upstream commit 03cb001ef87b3f8d859cf7f96329acf3d6235d29 ] lockdep_sock_is_held() was added in tcp_ao_established_key() by the cited commit. It can be called from tcp_v[46]_timewait_ack() with twsk. Since it does not have sk->sk_lock, the lockdep annotation results in out-of-bound access. $ pahole -C tcp_timewait_sock vmlinux | grep size /* size: 288, cachelines: 5, members: 8 */ $ pahole -C sock vmlinux | grep sk_lock socket_lock_t sk_lock; /* 440 192 */ Let's not use lockdep_sock_is_held() for TCP_TIME_WAIT. Fixes: 6b2d11e2d8fc ("net/tcp: Add missing lockdep annotations for TCP-AO hlist traversals") Reported-by: Damiano Melotti Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260508120853.4098365-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit eba8af785fde3cb2e9aeabd3fe66a478827eda72 Author: Johannes Thumshirn Date: Wed Apr 29 22:58:15 2026 +0200 zonefs: handle integer overflow in zonefs_fname_to_fno [ Upstream commit 3a8389d42bdf4213730f4067f8bfa78bae6564ef ] In zonefs the file name in one of the two directories corresponds to the zone number. Here Alexey reported a possible integer overflow in zonefs_fname_to_fno(), where the parsing of the zone number from the file name can overflow the 'long' data type. Add a check for integer overflows and if the fno 'long' did overflow return -ENOENT. Reported-by: Alexey Dobriyan Fixes: d207794ababe ("zonefs: Dynamically create file inodes when needed") Signed-off-by: Johannes Thumshirn Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit 9525e3a6fbb1d126a22ab2ee86ddea25af581a7c Author: Chia-Lin Kao (AceLan) Date: Wed Apr 29 16:11:16 2026 +0800 nvme-pci: fix use-after-free in nvme_free_host_mem() [ Upstream commit b35a13036755c5803168a7cb93bc66035c3e65b8 ] nvme_free_host_mem() frees dev->hmb_sgt via dma_free_noncontiguous() but never clears the pointer afterward. This leads to a use-after-free if nvme_free_host_mem() is called twice in the same error path. This can happen during nvme_probe() when nvme_setup_host_mem() succeeds in allocating the HMB (setting dev->hmb_sgt) but nvme_set_host_mem() fails with an I/O error: nvme_setup_host_mem() nvme_alloc_host_mem_single() -> sets dev->hmb_sgt nvme_set_host_mem() -> fails with -EIO nvme_free_host_mem() -> frees hmb_sgt, but does NOT NULL it return error nvme_probe() error path: nvme_free_host_mem() -> dev->hmb_sgt is stale, use-after-free The second call dereferences the freed sgt, causing a NULL pointer dereference in iommu_dma_free_noncontiguous() when it accesses sgt->sgl->dma_address (the backing memory has been freed and zeroed). This is reproducible on Thunderbolt-attached NVMe devices (e.g., OWC Envoy Express behind a Dell WD22TB4 dock) where the device intermittently returns I/O errors during HMB setup due to PCIe link instability. BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: 0010:iommu_dma_free_noncontiguous+0x22/0x80 Call Trace: dma_free_noncontiguous+0x3b/0x130 nvme_free_host_mem+0x30/0xf0 [nvme] nvme_probe.cold+0xcc/0x275 [nvme] local_pci_probe+0x43/0xa0 pci_device_probe+0xeea/0x290 really_probe+0xf9/0x3b0 __driver_probe_device+0x8b/0x170 driver_probe_device+0x24/0xd0 __driver_attach_async_helper+0x6b/0x110 async_run_entry_fn+0x37/0x170 process_one_work+0x1ac/0x3d0 worker_thread+0x1b8/0x360 kthread+0xf7/0x130 ret_from_fork+0x2d8/0x3a0 ret_from_fork_asm+0x1a/0x30 Fix this by setting dev->hmb_sgt to NULL after freeing it, so the second call takes the multi-descriptor path which safely handles the already-cleaned-up state. Fixes: 63a5c7a4b4c4 ("nvme-pci: use dma_alloc_noncontigous if possible") Signed-off-by: Chia-Lin Kao (AceLan) Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit fea4b46f84c50caf93c6c0f2a54b1be2edfb4491 Author: Keith Busch Date: Wed May 6 06:16:02 2026 -0700 nvme: fix bio leak on mapping failure [ Upstream commit 2279cd9c61a330e5de4d6eb0bc422820dd6fdf36 ] The local bio is always NULL, so we'd leak the bio if the integrity mapping failed. Just get it directly from the request. Fixes: d0d1d522316e91f ("blk-map: provide the bdev to bio if one exists") Reviewed-by: Sagi Grimberg Reviewed-by: John Garry Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 18c0456ea2615b1a743a6db739c74411c3b42bc6 Author: Jiayuan Chen Date: Mon Mar 30 15:32:29 2026 +0800 irq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT [ Upstream commit 91840be8f710370607f949a627e070896faeddb8 ] On PREEMPT_RT, non-HARD irq_work runs in per-CPU kthreads via run_irq_workd(), so irq_work_sync() uses rcuwait() to wait for BUSY==0. After irq_work_single() clears BUSY via atomic_cmpxchg(), it still dereferences @work for irq_work_is_hard() and rcuwait_wake_up(). An irq_work_sync() caller on another CPU that enters after BUSY is cleared can observe BUSY==0 immediately, return, and free the work before those accesses complete — causing a use-after-free. Fix this by wrapping run_irq_workd() in guard(rcu)() so that the entire irq_work_single() execution is within an RCU read-side critical section. Then add synchronize_rcu() in irq_work_sync() after rcuwait_wait_event() to ensure the caller waits for the RCU grace period before returning, preventing premature frees. Fixes: 810979682ccc ("irq_work: Allow irq_work_sync() to sleep if irq_work() no IRQ support.") Suggested-by: Sebastian Andrzej Siewior Suggested-by: Steven Rostedt Signed-off-by: Jiayuan Chen Signed-off-by: Thomas Gleixner Reviewed-by: Sebastian Andrzej Siewior Link: https://patch.msgid.link/20260330073234.303732-1-jiayuan.chen@linux.dev Signed-off-by: Sasha Levin commit 06ee55f78fbe2e103cc01c62c18e9c55f3a9b019 Author: Zhihao Cheng Date: Thu May 7 19:23:01 2026 +0800 nsfs: fix wrong error code returned for pidns ioctls [ Upstream commit 725ecd80688bf3c57ca9205431f2c06174ff0756 ] When executing NS_GET_PID_FROM_PIDNS (or similar pidns ioctls), if the target task cannot be found in the corresponding pid_ns, the error code should be ESRCH instead of ENOTTY. This bug was introduced when the extensible ioctl handling was added. Without proper return, ret would be overwritten by the default case in the extensible ioctl switch statement. Fixes: a1d220d9dafa8 ("nsfs: iterate through mount namespaces") Signed-off-by: Zhihao Cheng Link: https://patch.msgid.link/20260507112301.1042757-1-chengzhihao1@huawei.com Reviewed-by: Yang Erkun Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit d168a71fc1d6dd3e30d0d66aae098ebcda91db65 Author: Ming Lei Date: Sun May 10 22:48:43 2026 +0800 ublk: reject max_sectors smaller than PAGE_SECTORS in parameter validation [ Upstream commit 1860c2f85922917d8a46f16a6f4bd2298ffa0fb5 ] blk_validate_limits() requires max_hw_sectors >= PAGE_SECTORS and fires a WARN_ON_ONCE if this invariant is violated. ublk_validate_params() only checked the upper bound of max_sectors against max_io_buf_bytes, allowing userspace to pass small values (including zero) that trigger the warning when blk_mq_alloc_disk() is called from ublk_ctrl_start_dev(). Before 494ea040bcb5, ublk used blk_queue_max_hw_sectors() which silently clamped small values up to PAGE_SECTORS. The conversion to passing queue_limits directly to blk_mq_alloc_disk() lost that clamping and now hits blk_validate_limits()'s WARN_ON_ONCE instead. Validate that max_sectors is at least PAGE_SECTORS in ublk_validate_params() so invalid values are rejected early with -EINVAL instead of reaching the block layer. Fixes: 494ea040bcb5 ("ublk: pass queue_limits to blk_mq_alloc_disk") Signed-off-by: Ming Lei Link: https://patch.msgid.link/20260510144843.769031-1-tom.leiming@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 617a2564d8634c06d19097dc0f89bd3a72bcb1b4 Author: Rosen Penev Date: Wed May 6 01:55:22 2026 -0700 irqchip/ath79-cpu: Remove unused function [ Upstream commit 0fa10fb77069fb67aa51384868ef3702b7791465 ] ath79_cpu_irq_init() was part of the legacy pre-OF code that got removed a while back. Remove it to get rid of a missing prototype warning, reported by the kernel test robot. [ tglx: Fix the subject prefix. Sigh ... ] Fixes: 51fa4f8912c0 ("MIPS: ath79: drop legacy IRQ code") Reported-by: kernel test robot Signed-off-by: Rosen Penev Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260506085522.1210143-1-rosenp@gmail.com Closes: https://lore.kernel.org/oe-kbuild-all/202412011509.kGQkDr1y-lkp@intel.com/ Signed-off-by: Sasha Levin commit ace6b3e033c6337a7a7c5eebe671270f0fa0d377 Author: Hongling Zeng Date: Fri May 1 15:10:58 2026 +0800 fs: Fix return in jfs_mkdir and orangefs_mkdir [ Upstream commit a7cf1da7ac016490d6a1106f2aa6b602d34e9a12 ] Return NULL instead of passing to ERR_PTR while err is zero Fixes these smatch warnings: - fs/jfs/namei.c:311 jfs_mkdir() warn: passing zero to 'ERR_PTR' - fs/orangefs/namei.c:369 orangefs_mkdir() warn: passing zero to 'ERR_PTR' Fixes: 88d5baf69082 ("Change inode_operations.mkdir to return struct dentry *") Signed-off-by: Hongling Zeng Link: https://patch.msgid.link/20260501071058.1243245-1-zenghongling@kylinos.cn Reviewed-by: Jori Koolstra Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit e37ea2c6f17f273813ea4e8e94c102591d598ce1 Author: Junyoung Jang Date: Mon May 4 20:26:49 2026 +0900 fs/statmount: fix slab out-of-bounds write in statmount_mnt_idmap [ Upstream commit a3bf0f28d4ba16e1f35f8c983bb04426b87e2a78 ] statmount_mnt_idmap() writes one mapping with seq_printf() and then manually advances seq->count to include the NUL separator. If seq_printf() overflows, seq_set_overflow() sets seq->count to seq->size. The manual seq->count++ changes this to seq->size + 1. seq_has_overflowed() then no longer detects the overflow. The corrupted count returns to statmount_string(), which later executes: seq->buf[seq->count++] = '\0'; This causes a 1-byte NULL out-of-bounds write on the dynamically allocated seq buffer. Fix this by checking for overflow immediately after seq_printf(). Fixes: 37c4a9590e1e ("statmount: allow to retrieve idmappings") Signed-off-by: Junyoung Jang Link: https://patch.msgid.link/20260504112649.1862936-1-graypanda.inzag@gmail.com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 56b4cfcf1518245493c60fd39c56978f508f1816 Author: Masami Hiramatsu (Google) Date: Thu May 7 16:46:29 2026 +0900 fprobe: Fix unregister_fprobe() to wait for RCU grace period [ Upstream commit 657b594b2084b39a4bc6d8493aa2140cb00cea49 ] Commit 4346ba1604093 ("fprobe: Rewrite fprobe on function-graph tracer") changed fprobe to register struct fprobe to an rcu-hlist, but it forgot to wait for RCU GP. Thus there can be use-after-free if the fprobe is released right after unregistering. This can be happened on fprobe event and sample module code. To fix this issue, add synchronize_rcu() in unregister_fprobe(). Note that BPF is OK because fprobe is used as a part of bpf_kprobe_multi_link. This unregisters its fprobe in bpf_kprobe_multi_link_release() and it is deallocated via bpf_kprobe_multi_link_dealloc(), which is invoked from bpf_link_defer_dealloc_rcu_gp() RCU callback. For BPF, this also introduced unregister_fprobe_async() which does NOT wait for RCU grace priod. Link: https://lore.kernel.org/all/177813998919.256460.2809243930741138224.stgit@mhiramat.tok.corp.google.com/ Fixes: 4346ba1604093 ("fprobe: Rewrite fprobe on function-graph tracer") Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin commit 36dc0cea30db09a21512a4094dee2de4cc5ff558 Author: Mac Chiang Date: Fri May 8 17:32:24 2026 +0800 ASoC: sdw_utils: Add quirk to ignore RT721 CODEC_MIC [ Upstream commit fa749a77bdc50f0d695aaf81f1bd55967d77d10f ] Add a quirk to skip the CODEC_MIC DAI when it is not present. This ensures PCH_DMIC is used as the fallback; otherwise, CODEC_MIC remains the default. Fixes: 846a8d3cf3ba ("ASoC: Intel: soc-acpi-intel-ptl-match: Add rt721 support") Signed-off-by: Mac Chiang Signed-off-by: Bard Liao Link: https://patch.msgid.link/20260508093224.1246282-3-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5afefecfe054c5315a02e2d8c62aada80c93bdb1 Author: Mac Chiang Date: Fri May 8 17:32:23 2026 +0800 ASoC: sdw_utils: Add quirk to ignore RT712 CODEC_MIC [ Upstream commit 9c37daee7c17fa17e8d41089ee1f658b06cb672a ] Some devices do not use CODEC_MIC but use the host PCH_DMIC instead. Add a quirk to skip the CODEC_MIC DAI when it is not present in disco table, ensuring the correct capture device is used. If CODEC_MIC is present, it continues to be used as default. Fixes: 9489db97f6f0 ("ASoC: sdw_utils: add SmartMic DAI for RT712 VB") Signed-off-by: Mac Chiang Signed-off-by: Bard Liao Link: https://patch.msgid.link/20260508093224.1246282-2-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fe59ae27d7346245f5d8d97220f374e63efd28b5 Author: Chuck Lever Date: Sun Apr 19 14:52:59 2026 -0400 NFSD: Fix infinite loop in layout state revocation [ Upstream commit 4f8ef58c10bfe5f86a643c7c8331b37e69e3dae1 ] find_one_sb_stid() skips stids whose sc_status is non-zero, but the SC_TYPE_LAYOUT case in nfsd4_revoke_states() never sets sc_status before calling nfsd4_close_layout(). The retry loop therefore finds the same layout stid on every iteration, hanging the revoker indefinitely. Fixes: 1e33e1414bec ("nfsd: allow layout state to be admin-revoked.") Reported-by: Dai Ngo Reviewed-by: Jeff Layton Tested-by: Dai Ngo Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit e9405f7041271e119134c23438738de1476e7c92 Author: Gabor Juhos Date: Sat Mar 21 15:42:32 2026 +0100 phy: marvell: mvebu-a3700-utmi: fix incorrect USB2_PHY_CTRL register access [ Upstream commit 91ddf6f722084383fb05be731c0107814b055c0c ] The mvebu_a3700_utmi_phy_power_off() function tries to modify the USB2_PHY_CTRL register by using the IO address of the PHY IP block along with the readl/writel IO accessors. However, the register exist in the USB miscellaneous register space, and as such it must be accessed via regmap like it is done in the mvebu_a3700_utmi_phy_power_on() function. Change the code to use regmap_update_bits() for modífying the register to fix this. Fixes: cc8b7a0ae866 ("phy: add A3700 UTMI PHY driver") Signed-off-by: Gabor Juhos Reviewed-by: Miquel Raynal Link: https://patch.msgid.link/20260321-a3700-utmi-fix-usb2_phy_ctrl-access-v1-1-6005ff4b5058@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 994358adc0982d17731ffea7dfacd25afcc89773 Author: Shitalkumar Gandhi Date: Thu May 7 01:28:13 2026 +0530 net: ti: icssm-prueth: fix eth_ports_node leak in probe [ Upstream commit 6635fa84403c3a59455b66007c019a7cc632db30 ] The error path on of_property_read_u32() failure inside icssm_prueth_probe() returns without putting eth_ports_node, which was acquired before the for_each_child_of_node() loop. Drop it before returning. Fixes: 511f6c1ae093 ("net: ti: icssm-prueth: Adds ICSSM Ethernet driver") Signed-off-by: Shitalkumar Gandhi Link: https://patch.msgid.link/20260506195813.641610-1-shitalkumar.gandhi@cambiumnetworks.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7df3e1dfee5362fddee7b13585055403192f57ca Author: Myeonghun Pak Date: Wed May 6 21:43:11 2026 +0900 net: lan966x: avoid unregistering netdev on register failure [ Upstream commit c4f3d6eb1fcf6cd9ce4644f604d5aad1ce594dfc ] lan966x_probe_port() stores the newly allocated net_device in the port before calling register_netdev(). If register_netdev() fails, the probe error path calls lan966x_cleanup_ports(), which sees port->dev and calls unregister_netdev() for a device that was never registered. Destroy the phylink instance created for this port and clear port->dev before returning the registration error. The common cleanup path now skips ports without port->dev before reaching the registered netdev cleanup, so it only handles ports that reached the registered-netdev lifetime. This also avoids treating an uninitialized FDMA netdev and the failed port as a NULL == NULL match in the common cleanup path. Fixes: d28d6d2e37d1 ("net: lan966x: add port module support") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Link: https://patch.msgid.link/20260506124331.31945-1-mhun512@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d91a9a0496986eac19ab142b38938b6ec43310fb Author: Bart Van Assche Date: Wed May 6 14:48:15 2026 -0700 ice: fix locking in ice_dcb_rebuild() [ Upstream commit 0ded1f36ba4021cba50513e80be6b6e173710168 ] Move the mutex_lock() call up to prevent that DCB settings change after the first ice_query_port_ets() call. The second ice_query_port_ets() call in ice_dcb_rebuild() is already protected by pf->tc_mutex. This also fixes a bug in an error path, as before taking the first "goto dcb_error" in the function jumped over mutex_lock() to mutex_unlock(). This bug has been detected by the clang thread-safety analyzer. Cc: intel-wired-lan@lists.osuosl.org Fixes: 242b5e068b25 ("ice: Fix DCB rebuild after reset") Signed-off-by: Bart Van Assche Reviewed-by: Aleksandr Loktionov Reviewed-by: Przemek Kitszel Tested-by: Arpana Arland Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260506-jk-iwl-net-2026-05-04-v2-6-a5ea4dc837a9@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 34ad3c782644710beb3c5548faaf763711d5b975 Author: Marcin Szycik Date: Wed May 6 14:48:14 2026 -0700 ice: fix setting RSS VSI hash for E830 [ Upstream commit b3cda96feb60d91fe88d52b974ff110dcfa91239 ] ice_set_rss_hfunc() performs a VSI update, in which it sets hashing function, leaving other VSI options unchanged. However, ::q_opt_flags is mistakenly set to the value of another field, instead of its original value, probably due to a typo. What happens next is hardware-dependent: On E810, only the first bit is meaningful (see ICE_AQ_VSI_Q_OPT_PE_FLTR_EN) and can potentially end up in a different state than before VSI update. On E830, some of the remaining bits are not reserved. Setting them to some unrelated values can cause the firmware to reject the update because of invalid settings, or worse - succeed. Reproducer: sudo ethtool -X $PF1 equal 8 Output in dmesg: Failed to configure RSS hash for VSI 6, error -5 Fixes: 352e9bf23813 ("ice: enable symmetric-xor RSS for Toeplitz hash function") Reviewed-by: Aleksandr Loktionov Reviewed-by: Przemek Kitszel Signed-off-by: Marcin Szycik Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260506-jk-iwl-net-2026-05-04-v2-5-a5ea4dc837a9@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit eb5991d4c8ba2e8153dfcda3e66a9608377b7dce Author: Emil Tantilov Date: Wed May 6 14:48:12 2026 -0700 idpf: fix read_dev_clk_lock spinlock init in idpf_ptp_init() [ Upstream commit da4f76b6a84ede14a71282ef841768299ead0221 ] In idpf_ptp_init(), read_dev_clk_lock is initialized after ptp_schedule_worker() had already been called (and after idpf_ptp_settime64() could reach the lock). The PTP aux worker fires immediately upon scheduling and can call into idpf_ptp_read_src_clk_reg_direct(), which takes spin_lock(&ptp->read_dev_clk_lock) on an uninitialized lock, triggering the lockdep "non-static key" warning: [12973.796587] idpf 0000:83:00.0: Device HW Reset initiated [12974.094507] INFO: trying to register non-static key. ... [12974.097208] Call Trace: [12974.097213] [12974.097218] dump_stack_lvl+0x93/0xe0 [12974.097234] register_lock_class+0x4c4/0x4e0 [12974.097249] ? __lock_acquire+0x427/0x2290 [12974.097259] __lock_acquire+0x98/0x2290 [12974.097272] lock_acquire+0xc6/0x310 [12974.097281] ? idpf_ptp_read_src_clk_reg+0xb7/0x150 [idpf] [12974.097311] ? lockdep_hardirqs_on_prepare+0xde/0x190 [12974.097318] ? finish_task_switch.isra.0+0xd2/0x350 [12974.097330] ? __pfx_ptp_aux_kworker+0x10/0x10 [ptp] [12974.097343] _raw_spin_lock+0x30/0x40 [12974.097353] ? idpf_ptp_read_src_clk_reg+0xb7/0x150 [idpf] [12974.097373] idpf_ptp_read_src_clk_reg+0xb7/0x150 [idpf] [12974.097391] ? kthread_worker_fn+0x88/0x3d0 [12974.097404] ? kthread_worker_fn+0x4e/0x3d0 [12974.097411] idpf_ptp_update_cached_phctime+0x26/0x120 [idpf] [12974.097428] ? _raw_spin_unlock_irq+0x28/0x50 [12974.097436] idpf_ptp_do_aux_work+0x15/0x20 [idpf] [12974.097454] ptp_aux_kworker+0x20/0x40 [ptp] [12974.097464] kthread_worker_fn+0xd5/0x3d0 [12974.097474] ? __pfx_kthread_worker_fn+0x10/0x10 [12974.097482] kthread+0xf4/0x130 [12974.097489] ? __pfx_kthread+0x10/0x10 [12974.097498] ret_from_fork+0x32c/0x410 [12974.097512] ? __pfx_kthread+0x10/0x10 [12974.097519] ret_from_fork_asm+0x1a/0x30 [12974.097540] Move the call to spin_lock_init() up a bit to make sure read_dev_clk_lock is not touched before it's been initialized. Fixes: 5cb8805d2366 ("idpf: negotiate PTP capabilities and get PTP clock") Signed-off-by: Emil Tantilov Reviewed-by: Madhu Chittim Reviewed-by: Aleksandr Loktionov Reviewed-by: Simon Horman Tested-by: Samuel Salin Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260506-jk-iwl-net-2026-05-04-v2-3-a5ea4dc837a9@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a248793f00ab589d26cdf603ea09487b1533cd17 Author: Mohsin Bashir Date: Wed May 6 16:37:45 2026 -0700 net: shaper: Reject reparenting of existing nodes [ Upstream commit a77d5a069d959dc45f5f472d48cba37d8cba0f1c ] When an existing node-scope shaper is moved to a different parent via the group operation, the framework fails to update the leaves count on both the old and new parent shapers. Only newly created nodes (handle.id == NET_SHAPER_ID_UNSPEC) trigger the parent leaves increment at line 1039. This causes the parent's leaves counter to diverge from the actual number of children in the xarray. When the node is later deleted, pre_del_node() allocates an array sized by the stale leaves count, but the xarray iteration finds more children than expected, hitting the WARN_ON_ONCE guard and returning -EINVAL. Rather than adding reparenting support with complex leaves count bookkeeping, reject group calls that attempt to change an existing node's parent. Updates to an existing node's rate or leaves under the same parent remain permitted. We expect that for any modification of the topology user should always create new groups and let the kernel garbage collect the leaf-less nodes. Fixes: 5d5d4700e75d ("net-shapers: implement NL group operation") Signed-off-by: Mohsin Bashir Link: https://patch.msgid.link/20260506233745.111895-1-mohsin.bashr@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bfe08fe5624b341aa2e23a1be0e3c6d10a9456ac Author: Dragos Tatulea Date: Wed May 6 09:08:08 2026 +0000 net: napi: Avoid gro timer misfiring at end of busypoll [ Upstream commit 58e2330bd45572a6e3d46ea94cf7a9641f43591a ] When in irq deferral mode (defer-hard-irqs > 0), a short enough gro-flush timeout can trigger before NAPI_STATE_SCHED is cleared if the last poll in busy_poll_stop() takes too long. This can have the effect of leaving the queue stuck with interrupts disabled and no timer armed which results in a tx timeout if there is no subsequent busypoll cycle. To prevent this, defer the gro-flush timer arm after the last poll. Fixes: 7fd3253a7de6 ("net: Introduce preferred busy-polling") Co-developed-by: Martin Karsten Signed-off-by: Martin Karsten Signed-off-by: Dragos Tatulea Reviewed-by: Tariq Toukan Reviewed-by: Cosmin Ratiu Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260506090808.820559-2-dtatulea@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 77e7818eb3473f342bf297b30d6eb8d92f3dfe97 Author: Kuniyuki Iwashima Date: Wed May 6 03:59:19 2026 +0000 tcp: Fix imbalanced icsk_accept_queue count. [ Upstream commit 7eca3292cac7c26dad4c236f51ba225c39a0523f ] When TCP socket migration happens in reqsk_timer_handler(), @sk_listener will be updated with the new listener. When we call __inet_csk_reqsk_queue_drop(), the listener must be the one stored in req->rsk_listener. The cited commit accidentally replaced oreq->rsk_listener with sk_listener, leading to imbalanced icsk_accept_queue count. Let's pass the correct listener to __inet_csk_reqsk_queue_drop(). Fixes: e8c526f2bdf1 ("tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().") Reported-by: Damiano Melotti Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260506035954.1563147-3-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1c24cf1fd67f6702c719ab73499392cb7af956ae Author: Martin Kaiser Date: Fri May 8 09:56:36 2026 +0900 test_kprobes: clear kprobes between test runs [ Upstream commit ef5581bb30efb939cc2bf093475c6cc85258e5cd ] Running the kprobes sanity tests twice makes all tests fail and eventually crashes the kernel. [root@martin-riscv-1 ~]# echo 1 > /sys/kernel/debug/kunit/kprobes_test/run ... # Totals: pass:5 fail:0 skip:0 total:5 ok 1 kprobes_test [root@martin-riscv-1 ~]# echo 1 > /sys/kernel/debug/kunit/kprobes_test/run ... # test_kprobe: EXPECTATION FAILED at lib/tests/test_kprobes.c:64 Expected 0 == register_kprobe(&kp), but register_kprobe(&kp) == -22 (0xffffffffffffffea) ... Unable to handle kernel paging request ... The testsuite defines several kprobes and kretprobes as static variables that are preserved across test runs. After register_kprobe and unregister_kprobe, a kprobe contains some leftover data that must be cleared before the kprobe can be registered again. The tests are setting symbol_name to define the probe location. Address and flags must be cleared. The existing code clears some of the probes between subsequent tests, but not between two test runs. The leftover data from a previous test run makes the registrations fail in the next run. Move the cleanups for all kprobes into kprobes_test_init, this function is called before each single test (including the first test of a test run). Link: https://lore.kernel.org/all/20260507134615.1010905-1-martin@kaiser.cx/ Fixes: e44e81c5b90f ("kprobes: convert tests to kunit") Signed-off-by: Martin Kaiser Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin commit ae8a5c6b0316ce7b3f7b2c8d13daaf2ffa5be6c7 Author: Jianpeng Chang Date: Fri May 8 09:56:36 2026 +0900 kprobes: skip non-symbol addresses in kprobe_add_ksym_blacklist() [ Upstream commit 307abfac04a254c09c5705d816b33354acee97a0 ] When kprobe_add_area_blacklist() iterates through a section like .kprobes.text, the start address may not correspond to a named symbol. On ARM64 with CONFIG_DYNAMIC_FTRACE_WITH_CALL_OPS=y (introduced by commit baaf553d3bc3 ("arm64: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS")), the compiler flag -fpatchable-function-entry=4,2 inserts 2 NOPs before each function entry point for ftrace call_ops. These pre-function NOPs sit at the section base address, before the first named function symbol. The compiler emits a $x mapping symbol at offset 0x00 to mark the start of code, but find_kallsyms_symbol() ignores mapping symbols. Without CONFIG_DYNAMIC_FTRACE_WITH_CALL_OPS (e.g. defconfig), no pre-function NOPs are inserted, the first function starts at offset 0x00, and the bug does not trigger. This only affects modules that have a .kprobes.text section (i.e. those using the __kprobes annotation). Modules using NOKPROBE_SYMBOL() instead (like kretprobe_example.ko) blacklist exact function addresses via the _kprobe_blacklist section and are not affected. For kprobe_example.ko on ARM64 with -fpatchable-function-entry=4,2, the .kprobes.text section layout is: offset 0x00: $x + 2 NOPs (mapping symbol + ftrace preamble) offset 0x08: handler_post (64 bytes) offset 0x50: handler_pre (68 bytes) kprobe_add_area_blacklist() starts iterating from the section base address (offset 0x00), which only has the $x mapping symbol. kprobe_add_ksym_blacklist() then calls kallsyms_lookup_size_offset() for this address, which goes through: kallsyms_lookup_size_offset() -> module_address_lookup() -> find_kallsyms_symbol() find_kallsyms_symbol() scans all module symbols to find the closest preceding symbol. Since no named text symbol exists at offset 0x00, find_kallsyms_symbol() picks __UNIQUE_ID_vermagic (a .modinfo symbol whose address is in the temporary image) as the "best" match. The computed "size" = next_text_symbol - modinfo_symbol spans across these two unrelated memory regions, creating a blacklist entry with a bogus range of tens of terabytes. Whether this causes a visible failure depends on address randomization, here is what happens on Raspberry Pi 4/5: - On RPi5, the bogus size was ~35 TB. start + size stayed within 64-bit range, so the blacklist entry covered the entire kernel text. register_kprobe() in the module's own init function failed with -EINVAL. - On RPi4, the bogus size was ~75 TB. start + size overflowed 64 bits and wrapped to a small address near zero. The range check (addr >= start && addr < end) then failed because end wrapped around, so the bogus entry was accidentally harmless and kprobes worked by luck. The same bug exists on both machines, but randomization determines whether the integer overflow masks it or not. Fix this by adding notrace to the __kprobes macro. Functions in .kprobes.text are kprobe infrastructure handlers that should never be traced by ftrace. With notrace, the compiler stops inserting them and the non-symbol gap at the section start disappears entirely. Link: https://lore.kernel.org/all/20260506012706.2785785-1-jianpeng.chang.cn@windriver.com/ Fixes: baaf553d3bc3 ("arm64: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS") Signed-off-by: Jianpeng Chang Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin commit c647e2a21bbbaceda6cdb8a44a56f44d231dc4b4 Author: Florian Westphal Date: Thu May 7 11:19:22 2026 +0200 netfilter: bridge: eb_tables: close module init race [ Upstream commit 27414ff1b287ea9a2a11675149ec28e05539f3cc ] sashiko reports for unrelated patch: Does the core ebtables initialization in ebtables.c suffer from a similar race? Once nf_register_sockopt() completes, the sockopts are exposed globally. sockopt has to be registered last, just like in ip/ip6/arptables. Fixes: 5b53951cfc85 ("netfilter: ebtables: use net_generic infra") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 524b6337277aabb162bc9c3f018e55fc4b8b8882 Author: Florian Westphal Date: Wed May 6 12:07:20 2026 +0200 netfilter: x_tables: close dangling table module init race [ Upstream commit 16bc4b6686b2c112c10e67d6b493adc3607256d3 ] Similar to the previous ebtables patch: template add exposes the table to userspace, we must do this last to rnsure the pernet ops are set up (contain the destructors). Fixes: fdacd57c79b7 ("netfilter: x_tables: never register tables by default") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit cc989ef1c04425fd64d025f9c9df50dc031fc21a Author: Florian Westphal Date: Wed May 6 12:07:19 2026 +0200 netfilter: ebtables: close dangling table module init race [ Upstream commit 92c603fa07bc0d6a17345de3ad7954730b8de44b ] sashiko reported for a related patch: In modules like iptable_raw.c, [..], if register_pernet_subsys() fails, the rollback might call kfree(rawtable_ops) before [..] During this window, could a concurrent userspace process find the globally visible template, trigger table_init(), [..] The table init functions must always register the template last. Otherwise, set/getsockopt can instantiate a table in a namespace while the required pernet ops (contain the destructor) isn't available. This change is also required in x_tables, handled in followup change. Fixes: 87663c39f898 ("netfilter: ebtables: do not hook tables by default") Reviewed-by: Tristan Madani Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 739d5dac7b2da44a756aa4d758ee3f1ccf5a27f1 Author: Florian Westphal Date: Wed May 6 12:07:18 2026 +0200 netfilter: ebtables: move to two-stage removal scheme [ Upstream commit b7f0544d86d439cb946515d2ef6a0a75e8626710 ] Like previous patches for x_tables, follow same pattern in ebtables. We can't reuse xt helpers: ebt_table struct layout is incompatible. table->ops assignment is now done while still holding the ebt mutex to make sure we never expose partially-filled table struct. Fixes: 87663c39f898 ("netfilter: ebtables: do not hook tables by default") Reviewed-by: Tristan Madani Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 86ee5bc9c0f0e652e19f395675a432de11b75514 Author: Florian Westphal Date: Wed May 6 12:07:17 2026 +0200 netfilter: x_tables: add and use xtables_unregister_table_exit [ Upstream commit b4597d5fd7d2f8cebfffd40dffb5e003cc78964c ] Previous change added xtables_unregister_table_pre_exit to detach the table from the packetpath and to unlink it from the active table list. In case of rmmod, userspace that is doing set/getsockopt for this table will not be able to re-instantiate the table: 1. The larval table has been removed already 2. existing instantiated table is no longer on the xt pernet table list. This adds the second stage helper: unlink the table from the dying list, free the hook ops (if any) and do the audit notification. It replaces xt_unregister_table(). Fixes: fdacd57c79b7 ("netfilter: x_tables: never register tables by default") Reported-by: Tristan Madani Reviewed-by: Tristan Madani Closes: https://lore.kernel.org/netfilter-devel/20260429175613.1459342-1-tristmd@gmail.com/ Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 89ebafe7910d51c745185f55ed663f38b8e43d89 Author: Florian Westphal Date: Wed May 6 12:07:15 2026 +0200 netfilter: x_tables: add and use xt_unregister_table_pre_exit [ Upstream commit 527d6931473b75d90e38942aae6537d1a527f1fd ] Remove the copypasted variants of _pre_exit and add one single function in the xtables core. ebtables is not compatible with x_tables and therefore unchanged. This is a preparation patch to reduce noise in the followup bug fixes. Reviewed-by: Tristan Madani Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Stable-dep-of: b4597d5fd7d2 ("netfilter: x_tables: add and use xtables_unregister_table_exit") Signed-off-by: Sasha Levin commit a9b2f73f6ba7c3f92ae483686b9a92797a290071 Author: Florian Westphal Date: Wed May 6 12:07:16 2026 +0200 netfilter: x_tables: unregister the templates first [ Upstream commit d338693d778579b676a61346849bebd892427158 ] When the module is going away we need to zap the template first. Else there is a small race window where userspace could instantiate a new table after the pernet exit function has removed the current table. Fixes: fdacd57c79b7 ("netfilter: x_tables: never register tables by default") Reported-by: Tristan Madani Reviewed-by: Tristan Madani Closes: https://lore.kernel.org/netfilter-devel/20260429175613.1459342-1-tristmd@gmail.com/ Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit c32a7e0e3c73c1c0768556a56bd78de9f7b83780 Author: Filipe Manana Date: Tue Apr 28 16:58:56 2026 +0100 btrfs: tracepoints: fix sleep while in atomic context in btrfs_sync_file() [ Upstream commit c73370c677646e86fc4b1780fb07027bdf847375 ] The trace event btrfs_sync_file() is called in an atomic context (all trace events are) and its call to dput(), which is needed due to the call to dget_parent(), can sleep, triggering a kernel splat. This can be reproduced by enabling the trace event and running btrfs/056 from fstests for example. The splat shown in dmesg is the following: [53.919] BUG: sleeping function called from invalid context at fs/dcache.c:970 [53.947] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 32773, name: xfs_io [53.988] preempt_count: 2, expected: 0 [53.967] RCU nest depth: 0, expected: 0 [53.943] Preemption disabled at: [53.944] [<0000000000000000>] 0x0 [54.078] CPU: 0 UID: 0 PID: 32773 Comm: xfs_io Tainted: G W 7.1.0-rc1-btrfs-next-232+ #1 PREEMPT(full) [54.070] Tainted: [W]=WARN [54.071] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [54.072] Call Trace: [54.074] [54.076] dump_stack_lvl+0x56/0x80 [54.079] __might_resched.cold+0xd6/0x10f [54.072] dput.part.0+0x24/0x110 [54.078] trace_event_raw_event_btrfs_sync_file+0x75/0x140 [btrfs] [54.089] btrfs_sync_file+0x1ed/0x530 [btrfs] [54.087] ? __handle_mm_fault+0x8ae/0xed0 [54.089] btrfs_do_write_iter+0x172/0x210 [btrfs] [54.091] vfs_write+0x21f/0x450 [54.094] __x64_sys_pwrite64+0x8d/0xc0 [54.096] ? do_user_addr_fault+0x20c/0x670 [54.099] do_syscall_64+0x60/0xf20 [54.092] ? clear_bhb_loop+0x60/0xb0 [54.094] entry_SYSCALL_64_after_hwframe+0x76/0x7e So stop using dget_parent() and dput() and access the parent dentry directly as dentry->d_parent. This is also what ext4 is doing in its equivalent trace event ext4_sync_file_enter(). Fixes: a85b46db143f ("btrfs: tracepoints: get correct superblock from dentry in event btrfs_sync_file()") Reviewed-by: Boris Burkov Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 373f65b448ed4d7ced253724aa36babb808c72ff Author: Shuhao Fu Date: Tue Apr 28 16:12:38 2026 +0800 ALSA: hda: cs35l41: Put ACPI device on missing physical node [ Upstream commit fca7401fe37f7abc6e54147ea560f37279231137 ] acpi_dev_get_first_match_dev() returns a refcounted ACPI device and callers must balance it with acpi_dev_put(). cs35l41_hda_read_acpi() stores the returned ACPI device in cs35l41->dacpi. That reference is normally released by the later probe cleanup or the remove path, but the NULL-check on physdev exits before either of those paths can run. Drop the lookup reference before returning -ENODEV. Fixes: c34b04cc6178 ("ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi()") Signed-off-by: Shuhao Fu Tested-by: Simon Trimmer Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260428081238.GA1659932@chcpu16 Signed-off-by: Sasha Levin commit fecae8b1fb2d3790e19a134fead83cee51189644 Author: Shuhao Fu Date: Tue Apr 28 16:01:39 2026 +0800 ALSA: hda: cs35l56: Put ACPI device after setting companion [ Upstream commit aa2fbece1b07954ef26488c800d126a36a8ab93e ] acpi_dev_get_first_match_dev() returns a refcounted ACPI device and callers are expected to balance it with acpi_dev_put(). When no companion is already attached, cs35l56_hda_read_acpi() looks up an ACPI device and sets it with ACPI_COMPANION_SET(), but leaves the lookup reference held. ACPI_COMPANION_SET() does not take ownership of that reference, so drop it with acpi_dev_put() after attaching the companion. Fixes: 73cfbfa9caea ("ALSA: hda/cs35l56: Add driver for Cirrus Logic CS35L56 amplifier") Signed-off-by: Shuhao Fu Tested-by: Simon Trimmer Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260428080139.GA1649104@chcpu16 Signed-off-by: Sasha Levin commit e984dc22e2c24dc34d6728e338c82b1ce7862753 Author: Guenter Roeck Date: Tue May 5 21:15:37 2026 +0200 ARM: integrator: Fix early initialization [ Upstream commit 90d77b30a666049ad24df463f52e5d529c44e8cd ] Starting with commit bdb249fce9ad4 ("ARM: integrator: read counter using syscon/regmap"), intcp_init_early calls syscon_regmap_lookup_by_compatible which in turn calls of_syscon_register. This function allocates memory. Since the memory management code has not been initialized at that time, the call always fails. It either returns -ENOMEM or crashes as follows. Unable to handle kernel NULL pointer dereference at virtual address 0000000c when read [0000000c] *pgd=00000000 Internal error: Oops: 5 [#1] ARM Modules linked in: CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.15.0-rc5-00026-g5fcc9bf84ee5 #1 PREEMPT Hardware name: ARM Integrator/CP (Device Tree) PC is at __kmalloc_cache_noprof+0xec/0x39c LR is at __kmalloc_cache_noprof+0x34/0x39c ... Call trace: __kmalloc_cache_noprof from of_syscon_register+0x7c/0x310 of_syscon_register from device_node_get_regmap+0xa4/0xb0 device_node_get_regmap from intcp_init_early+0xc/0x40 intcp_init_early from start_kernel+0x60/0x688 start_kernel from 0x0 The crash is seen due to a dereferenced pointer which is not supposed to be NULL but is NULL if the memory management subsystem has not been initialized. The crash is not seen with all versions of gcc. Some versions such as gcc 9.x apparently do not dereference the pointer, presumably if tracing is disabled. The problem has been reproduced with gcc 10.x, 11.x, and 13.x. Either case, if the crash is not seen, the call to syscon_regmap_lookup_by_compatible returns -ENOMEM, and sched_clock_register is never called. Fix the problem by moving the early initialization code into the standard machine initialization code. Fixes: bdb249fce9ad4 ("ARM: integrator: read counter using syscon/regmap") Cc: Linus Walleij Signed-off-by: Guenter Roeck Link: https://lore.kernel.org/20250518164118.3859567-1-linux@roeck-us.net Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20260505-integrator-fixes-v1-1-56ab9aac59db@kernel.org Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 9e472874c9541a34ad2f3377177b28d9adb8e2f5 Author: Sudeep Holla Date: Tue Apr 28 19:33:35 2026 +0100 firmware: arm_ffa: Fix sched-recv callback partition lookup [ Upstream commit a6848a50404eefb6f0b131c21881a2d8d21b31a9 ] ffa_sched_recv_cb_update() used list_for_each_entry_safe() to search for a matching partition and then tested the iterator against NULL. That is not a valid end-of-list check for circular lists and can fall through with an invalid pointer. Use a normal iterator and detect the not-found case correctly before touching the partition state. Fixes: be61da938576 ("firmware: arm_ffa: Allow multiple UUIDs per partition to register SRI callback") Link: https://patch.msgid.link/20260428-ffa_fixes-v2-11-8595ae450034@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit d1e38551fadea230649bc428f0f35c9ee062a072 Author: Sudeep Holla Date: Tue Apr 28 19:33:34 2026 +0100 firmware: arm_ffa: Snapshot notifier callbacks under lock [ Upstream commit 38290b180a4d5746baed796d49f88d56d2f336cd ] Both notification handlers currently look up a notifier callback under notify_lock, drop the lock, and then dereference the returned notifier entry. A concurrent unregister can delete and free that entry in the gap, leaving the handler to dereference stale memory. Copy the callback pointer and callback data while notify_lock is still held and invoke the callback only after the lock is dropped. This keeps the existing callback execution model while removing the use-after-free window in both the framework and non-framework notification paths. Fixes: 285a5ea0f542 ("firmware: arm_ffa: Add support for handling framework notifications") Link: https://patch.msgid.link/20260428-ffa_fixes-v2-10-8595ae450034@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 419cef661ae86a591c6c5d8534b2909706399824 Author: Sudeep Holla Date: Tue Apr 28 19:33:33 2026 +0100 firmware: arm_ffa: Align RxTx buffer size before mapping [ Upstream commit 0399e3f872ca3d78044bb715a73ea645806d2c7b ] Commit 83210251fd70 ("firmware: arm_ffa: Use the correct buffer size during RXTX_MAP") advertises PAGE_ALIGN(rxtx_bufsz) to firmware when mapping the buffers but the driver continues to stores the minimum FF-A buffer size in drv_info->rxtx_bufsz which is used elsewhere in the driver. Align the size before storing it so that the allocation, validation and FFA_RXTX_MAP all use the same buffer size. Fixes: 83210251fd70 ("firmware: arm_ffa: Use the correct buffer size during RXTX_MAP") Cc: Sebastian Ene Link: https://sashiko.dev/#/patchset/20260402113939.930221-1-sebastianene@google.com Reviewed-by: Sebastian Ene Link: https://patch.msgid.link/20260428-ffa_fixes-v2-9-8595ae450034@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 3c51d99449dc5a01c08a7fce6071d6721f5aac83 Author: Sudeep Holla Date: Tue Apr 28 19:33:32 2026 +0100 firmware: arm_ffa: Validate framework notification message layout [ Upstream commit 4a1cc9e96b311d2609a6f963a5e35bd4ae730d97 ] Framework notifications carry an indirect message in the shared RX buffer. Validate the reported offset and size before using them, reject zero-length payloads, and ensure that any non-header payload starts at the UUID field rather than in the middle of the message header. Use the validated offset and size values for both kmemdup() and the UUID parsing path so malformed firmware data cannot drive an out-of-bounds read or an oversized allocation. Fixes: 285a5ea0f542 ("firmware: arm_ffa: Add support for handling framework notifications") Link: https://patch.msgid.link/20260428-ffa_fixes-v2-8-8595ae450034@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 0a5dbac5ef53a8f953164e1da471b698de3d1bb0 Author: Sudeep Holla Date: Tue Apr 28 19:33:31 2026 +0100 firmware: arm_ffa: Keep framework RX release under lock [ Upstream commit 2af18f8e36b277730527cacc2256b1332f56aa28 ] The framework notification handler drops rx_lock before issuing FFA_RX_RELEASE, leaving a window where another RX-buffer user can start a new FF-A transaction before ownership has actually been returned to firmware. Move the FFA_RX_RELEASE calls so they execute while rx_lock is still held on both the kmemdup() failure path and the normal success path. While doing that, switch the handler to scoped_guard() to keep the critical section explicit. Fixes: 285a5ea0f542 ("firmware: arm_ffa: Add support for handling framework notifications") Link: https://patch.msgid.link/20260428-ffa_fixes-v2-7-8595ae450034@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit f39bc7ebe75e2186b417a024a7f7e2fd4cc7eb95 Author: Sudeep Holla Date: Tue Apr 28 19:33:30 2026 +0100 firmware: arm_ffa: Bound PARTITION_INFO_GET_REGS copies [ Upstream commit 3974ea1938406f9bfa7c1f48d4e43533f447bb08 ] The register-based PARTITION_INFO_GET path trusted the firmware-provided indices when copying partition descriptors into the caller buffer. Reject inconsistent counts or index progressions so the copy loop cannot write past the allocated array. Fixes: ba85c644ac8d ("firmware: arm_ffa: Add support for FFA_PARTITION_INFO_GET_REGS") Link: https://patch.msgid.link/20260428-ffa_fixes-v2-6-8595ae450034@kernel.org (fixed cur_idx when exactly one descriptor in the first fragment) Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit fd2b01637e56d1098ab0dc9a2f0f64090e4a6e25 Author: Maulik Shah Date: Tue Apr 28 17:44:58 2026 +0530 pinctrl: qcom: Fix wakeirq map by removing disconnected irqs for sm8150 [ Upstream commit 52ac35b8a151446481496404af3a8e5e889b3c5a ] PDC interrupts 122-125 were meant for ibi_i3c wakeup but sm8150 do not support i3c. GPIOs 39,51,88 and 144 are also connected to different PDC pin and already reflected in the wake irq map. Remove the unsupported wakeup interrupts from the map. Fixes: 90337380c809 ("pinctrl: qcom: sm8150: Specify PDC map") Reviewed-by: Konrad Dybcio Signed-off-by: Maulik Shah Signed-off-by: Navya Malempati Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 3f4d827800017ed5244b8cd1b9d0f8217e1417ff Author: David Gow Date: Sat Apr 25 11:41:54 2026 +0800 kunit: config: KUNIT_DEBUGFS should depend on DEBUG_FS [ Upstream commit 8f80b5b227ef9ea422080487715c841856339aed ] CONFIG_KUNIT_DEBUGFS is totally useless without debugfs, so it should depend on CONFIG_DEBUG_FS. Link: https://lore.kernel.org/r/20260425034155.53913-2-david@davidgow.net Fixes: e2219db280e3 ("kunit: add debugfs /sys/kernel/debug/kunit//results display") Signed-off-by: David Gow Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 91e4446b35f657915db0a6623aeeb0ea4c27a1f0 Author: David Gow Date: Sat Apr 25 11:41:53 2026 +0800 kunit: config: Enable KUNIT_DEBUGFS by default [ Upstream commit 17e4c68ff35090d8cb743e3c82c09f92fda1ebda ] The KUNIT_DEBUGFS option is currently enabled based on the value of KUNIT_ALL_TESTS, but it really doesn't have anything to do with the set of enabled tests, so just enable it by default anyway. In particular, this shouldn't be only visible if KUNIT_ALL_TESTS is set, which is quite confusing. Link: https://lore.kernel.org/r/20260425034155.53913-1-david@davidgow.net Fixes: beaed42c427d ("kunit: default KUNIT_* fragments to KUNIT_ALL_TESTS") Signed-off-by: David Gow Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 96b8b9d0dead730ede84e81df473552cd4127c70 Author: Guo Ren (Alibaba DAMO Academy) Date: Sun Jan 25 00:52:12 2026 -0500 riscv: mm: Fixup no5lvl failure when vaddr is invalid [ Upstream commit db909bd7986c10da074917af3dae83a60fa65093 ] Unlike no4lvl, no5lvl still continues to detect satp, which requires va=pa mapping. When pa=0x800000000000, no5lvl would fail in Sv48 mode due to an illegal VA value of 0x800000000000. So, prevent detecting the satp flow for no5lvl, when vaddr is invalid. Add the is_vaddr_valid() function for checking. Fixes: 26e7aacb83df ("riscv: Allow to downgrade paging mode from the command line") Cc: Alexandre Ghiti Cc: Björn Töpel Signed-off-by: Guo Ren (Alibaba DAMO Academy) Tested-by: Fangyu Yu Link: https://patch.msgid.link/20260125055212.433163-1-guoren@kernel.org [pjw@kernel.org: cleaned up commit message] Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit f3216d930c0fa99ed6bbfb1e13c193cee0bea788 Author: Michael Neuling Date: Thu Apr 9 09:11:39 2026 +0000 riscv: errata: Fix bitwise vs logical AND in MIPS errata patching [ Upstream commit 4d2b03699460b8fd5df34408a03a84a1a7ff8aa1 ] The condition checking whether a specific errata needs patching uses logical AND (&&) instead of bitwise AND (&). Since logical AND only checks that both operands are non-zero, this causes all errata patches to be applied whenever any single errata is detected, rather than only applying the matching one. The SiFive errata implementation correctly uses bitwise AND for the same check. Fixes: 0b0ca959d206 ("riscv: errata: Fix the PAUSE Opcode for MIPS P8700") Signed-off-by: Michael Neuling Assisted-by: Cursor:claude-4.6-opus-high-thinking Link: https://patch.msgid.link/20260409091143.1348853-2-mikey@neuling.org [pjw@kernel.org: fixed checkpatch warning] Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit 1aa01b46fe3ba0d36c2d0bac382a62a740b6eb80 Author: Sudeep Holla Date: Tue Apr 28 19:33:29 2026 +0100 firmware: arm_ffa: Unregister bus notifier on teardown for FF-A v1.0 [ Upstream commit 6d3daa9b8d313f42d52e75590310f26a29b61b44 ] For FF-A v1.0 the driver registers a bus notifier to backfill UUID matching, but the notifier was never unregistered on cleanup paths. Track the registration state and unregister it during teardown and early partition-setup failure. Fixes: 9dd15934f60d ("firmware: arm_ffa: Move the FF-A v1.0 NULL UUID workaround to bus notifier") Link: https://patch.msgid.link/20260428-ffa_fixes-v2-5-8595ae450034@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 07907b897bb72c580bc6432b8fd652e8f2d47857 Author: Sudeep Holla Date: Tue Apr 28 19:33:28 2026 +0100 firmware: arm_ffa: Fix per-vcpu self notifications handling in workqueue [ Upstream commit 9985d5357ed93af0d1933969c247e966957730e1 ] Per-vcpu notification handling already runs from a per-cpu work item on the target cpu. Routing that path back through smp_call_function_single() re-enters the call-function IPI path and executes the notification handler with interrupts disabled. That makes the framework path unsafe, since it takes a mutex, allocates memory with GFP_KERNEL, and invokes client callbacks. Handle per-vcpu self notifications directly from the existing per-cpu work item instead. This keeps the per-vcpu path in task context and avoids the extra IPI hop entirely. Fixes: 3a3e2b83e805 ("firmware: arm_ffa: Avoid queuing work when running on the worker queue") Link: https://patch.msgid.link/20260428-ffa_fixes-v2-4-8595ae450034@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 1418765d28ab11efd1abbee8b691d2a3e50fd20e Author: Sudeep Holla Date: Tue Apr 28 19:33:26 2026 +0100 firmware: arm_ffa: Skip free_pages on RX buffer alloc failure [ Upstream commit 09527e2c534911619d7e098729711100290bc3e1 ] If the RX buffer allocation fails in ffa_init(), the error path jumps to free_pages even though no buffer has been allocated yet. Route that case directly to free_drv_info so the cleanup path is only used after at least one RX/TX buffer allocation has succeeded. Fixes: 3bbfe9871005 ("firmware: arm_ffa: Add initial Arm FFA driver support") Link: https://patch.msgid.link/20260428-ffa_fixes-v2-2-8595ae450034@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 820245d86ce58898fb48b4fefc77d0cafc02801d Author: Sudeep Holla Date: Tue Apr 28 19:33:25 2026 +0100 firmware: arm_ffa: Check for NULL FF-A ID table while driver registration [ Upstream commit 0a5e695095c557d2380131b613dea4e8d90371be ] The bus match callback assumes that every FF-A driver provides an id_table and dereferences it unconditionally. Enforce that contract at registration time so a buggy client driver cannot crash the bus during match. Fixes: 92743071464f ("firmware: arm_ffa: Ensure drivers provide a probe function") Link: https://patch.msgid.link/20260428-ffa_fixes-v2-1-8595ae450034@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 4894847fcec140636c1a8f9c719a9652ef1c1b6c Author: Takashi Iwai Date: Tue Apr 28 10:33:16 2026 +0200 HID: uclogic: Fix regression of input name assignment [ Upstream commit 487359284509a6745e14b8c0518768bc277809b0 ] The previous fix for adding the devm_kasprintf() return check in the commit bd07f751208b ("HID: uclogic: Add NULL check in uclogic_input_configured()") changed the condition of hi->input->name assignment, and it resulted in missing the proper input device name when no custom suffix is defined. Restore the conditional to the original content to address the regression. Fixes: bd07f751208b ("HID: uclogic: Add NULL check in uclogic_input_configured()") Signed-off-by: Takashi Iwai Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit e912d5dc00965e69fe95554769b2032ab728d212 Author: Dan Carpenter Date: Thu Apr 23 10:10:02 2026 +0300 HID: intel-thc-hid: Intel-quickspi: Fix some error codes [ Upstream commit ae4ac077332ea3341a0f4c0973556c6b7ac5b7a1 ] If we have a partial read that is supposed to be treated as failure but in this code we forgot to set the error code. Return -EINVAL. Fixes: 9d8d51735a3a ("HID: intel-thc-hid: intel-quickspi: Add HIDSPI protocol implementation") Signed-off-by: Dan Carpenter Reviewed-by: Even Xu Reviewed-by: Mark Pearson Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 1fce9dcb3a662059011b4ce341a9cfb947bf2e1d Author: Maulik Shah Date: Thu Apr 23 16:55:24 2026 +0530 pinctrl: qcom: Fix GPIO to PDC wake irq map for qcs615 [ Upstream commit 9d69033ad967b6e09b1e5b30d1a32c6c4876465d ] PDC interrupts 122-125 were meant for ibi_i3c wakeup but qcs615 do not support i3c. GPIOs 39,51,88 and 89 are also connected to different PDC pin to support non-ibi wakeup. Update the wakeirq map to reflect same. Fixes: b698f36a9d40 ("pinctrl: qcom: add the tlmm driver for QCS615 platform") Signed-off-by: Maulik Shah Signed-off-by: Navya Malempati Reviewed-by: Konrad Dybcio Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit e917713f013423069782ff554935c7a5d4266783 Author: Xianwei Zhao Date: Wed Apr 22 11:44:13 2026 +0000 pinctrl: meson: amlogic-a4: fix deadlock issue [ Upstream commit e72ce029810390eb987a036fb2c8a5da9a23b685 ] Accessing the pinconf-pins sysfs node may deadlock. pinconf_pins_show() holds pctldev->mutex, and the platform driver calls pinctrl_find_gpio_range_from_pin(), which tries to acquire the same mutex again, leading to a deadlock. Use pinctrl_find_gpio_range_from_pin_nolock() to fix this issue. 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 8d1c6b603327b22f151de7fbeb7f9f64bec31ccf Author: Lad Prabhakar Date: Mon Apr 13 19:24:51 2026 +0100 pinctrl: renesas: rzg2l: Fix SMT register cache handling [ Upstream commit c88ab9407986836820848128ce1f90f2fa49da95 ] Store SMT register cache per bank instead of using a single array. On RZ/V2H(P), RZ/V2N, and RZ/G3E, the SMT register is split across two 32-bit registers: bits 0/8/16/24 control pins 0-3, while pins 4-7 are controlled by the corresponding bits in the next register. The previous implementation cached only a single SMT register, leading to incomplete save/restore of SMT state. Convert cache->smt to a per-bank array and allocate storage for both halves. Update suspend/resume handling to save and restore both SMT registers when present. Fixes: 837afa592c623 ("pinctrl: renesas: rzg2l: Add suspend/resume support for Schmitt control registers") Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260413182456.811543-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit c4cfa8ee77374630017b9cbd20ba2f6f46c08084 Author: Biju Das Date: Sat Mar 28 09:05:45 2026 +0000 pinctrl: renesas: rzg2l: Fix incorrect PUPD register offset for high pins during suspend/resume [ Upstream commit 6dba9b7268cc50166bce47608670192fd874e363 ] When saving/restoring pull-up/down register state during suspend/resume, the second PUPD register access was incorrectly using the same base offset as the first, effectively reading/writing the same register twice instead of the adjacent one. Add the correct + 4 byte offset to the second RZG2L_PCTRL_REG_ACCESS32 call so that pupd[1][port] is properly saved and restored from the next 32-bit register in the PUPD register pair, covering pins 4–7 of ports with 4 or more pins. Fixes: b2bd65fbb617 ("pinctrl: renesas: rzg2l: Add suspend/resume support for pull up/down") Signed-off-by: Biju Das Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260328090548.84124-1-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit a7fee132268376ac706605a4526bda60e6e1d7ee Author: Marek Vasut Date: Sat Mar 28 00:42:11 2026 +0100 ARM: dts: renesas: rskrza1: Drop superfluous cells [ Upstream commit ab83176d3cf1cf1c1f6e604432905bda4515d17f ] Drop superfluous address-cells and size-cells to fix DTC W=1 warning: arch/arm/boot/dts/renesas/r7s72100-rskrza1.dts:32.17-72.4: Warning (avoid_unnecessary_addr_size): /flash@18000000: unnecessary #address-cells/#size-cells without "ranges", "dma-ranges" or child "reg" or "ranges" property Signed-off-by: Marek Vasut Fixes: 98537eb77d3ef185 ("ARM: dts: renesas: rskrza1: Add FLASH nodes") Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260327234244.91707-7-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit d27b29e474a6274cf34eb3afb59e137025ced83c Author: Marek Vasut Date: Sat Mar 28 00:42:10 2026 +0100 ARM: dts: renesas: genmai: Drop superfluous cells [ Upstream commit 714e1d6bba0e0abe5c87c8e189a35fa690540df4 ] Drop superfluous address-cells and size-cells to fix DTC W=1 warning: arch/arm/boot/dts/renesas/r7s72100-genmai.dts:28.17-55.4: Warning (avoid_unnecessary_addr_size): /flash@18000000: unnecessary #address-cells/#size-cells without "ranges", "dma-ranges" or child "reg" or "ranges" property Signed-off-by: Marek Vasut Fixes: 30e0a8cf886cb459 ("ARM: dts: renesas: genmai: Add FLASH nodes") Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260327234244.91707-6-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 00aca89f5e3453b30b73e31aa31099b1433f8370 Author: Til Kaiser Date: Mon Apr 13 15:52:34 2026 +0200 pinctrl: qcom: ipq4019: mark gpio as a GPIO pin function [ Upstream commit b51d33ea8a164bb5f0eec8ad817fa9730ac2b577 ] The qcom pinctrl core supports marking functions that represent GPIO mode via PINCTRL_GPIO_PINFUNCTION(), so that strict pinmuxing does not reject GPIO requests for pins that are muxed to the GPIO function. ipq4019 still describes its gpio function with QCA_PIN_FUNCTION(gpio), so it is not treated as a GPIO pin function. As a result, GPIO consumers can still conflict with pinctrl states that select the "gpio" function. Add a QCA_GPIO_PIN_FUNCTION() helper and use it for the ipq4019 gpio function, matching how the msm-based qcom drivers handle this. This allows ipq4019 to keep the GPIO-related pin configuration in DTS without tripping over strict pinmux ownership checks. Fixes: cc85cb96e2e4 ("pinctrl: qcom: make the pinmuxing strict") Signed-off-by: Til Kaiser Reviewed-by: Dmitry Baryshkov Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit eb3cd9bb590460c6127145cb245be925d23f5232 Author: Abdurrahman Hussain Date: Mon May 18 17:52:27 2026 -0700 hwmon: (pmbus/adm1266) reject short block-read responses in the GPIO accessors commit a7232f68c43ca62f545049b7f5fbfc75137b843b upstream. adm1266_gpio_get() and adm1266_gpio_get_multiple() both compose the pin-status word as pins_status = read_buf[0] + (read_buf[1] << 8); right after i2c_smbus_read_block_data(), guarding only against an error return. A well-behaved device returns 2 bytes for GPIO_STATUS/PDIO_STATUS, but the helper happily reports a 0- or 1-byte response too. If the device returns 0 bytes, both read_buf slots are uninitialized stack memory; if it returns 1 byte, read_buf[1] is. The composed value then flows through set_bit() into the caller's *bits in adm1266_gpio_get_multiple(), or into the return value of adm1266_gpio_get(), and ends up in userspace via gpiolib (sysfs and the char-dev ioctls). That leaks a few bits of kernel stack per request on any device whose firmware glitch, bus error, or hostile slave produces a short block-read response. Add the missing length check to both call sites and surface a short response as -EIO. Fixes: d98dfad35c38 ("hwmon: (pmbus/adm1266) Add support for GPIOs") Cc: stable@vger.kernel.org Signed-off-by: Abdurrahman Hussain Reviewed-by: Bartosz Golaszewski Link: https://lore.kernel.org/r/20260518-adm1266-gpio-fixes-v3-3-e425e4f88139@nexthop.ai Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit dd12c6dbe2ac1c16e4d86af7b8a5a3858977c54c Author: Abdurrahman Hussain Date: Mon May 18 17:52:29 2026 -0700 hwmon: (pmbus/adm1266) register the nvmem device after pmbus_do_probe() commit 6af713af91d5c34ec049eb3cc2c5b3f5eba953b8 upstream. adm1266_probe() calls adm1266_config_nvmem() -- which goes on to devm_nvmem_register() and exposes adm1266_nvmem_read() to userspace -- before pmbus_do_probe() has initialised the per-client PMBus state. Same latent hazard as the gpio_chip one fixed in the previous patch: once the nvmem device is registered, gpiolib's nvmem char-dev / sysfs interface is reachable, and any concurrent read triggers adm1266_nvmem_read() -> adm1266_nvmem_read_blackbox(), which issues PMBus traffic that races pmbus_do_probe()'s own device accesses with no serialisation. Move adm1266_config_nvmem() down past pmbus_do_probe() so the nvmem device isn't reachable from userspace until the PMBus state the nvmem accessors depend on is fully initialised. Fixes: 15609d189302 ("hwmon: (pmbus/adm1266) read blackbox") Cc: stable@vger.kernel.org Signed-off-by: Abdurrahman Hussain Link: https://lore.kernel.org/r/20260518-adm1266-gpio-fixes-v3-5-e425e4f88139@nexthop.ai Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit a203125c0e818809b206f269a6386c827c3286ff Author: Abdurrahman Hussain Date: Mon May 18 17:52:28 2026 -0700 hwmon: (pmbus/adm1266) register the gpio_chip after pmbus_do_probe() commit 491403b9b76cf66abd81301c5901aa4a4549f1e8 upstream. adm1266_probe() calls adm1266_config_gpio() -- which goes on to devm_gpiochip_add_data() and exposes the gpio_chip callbacks to gpiolib -- before pmbus_do_probe() has initialised the per-client PMBus state (notably the pmbus_lock mutex the core hands out via pmbus_get_data()). That ordering is already a latent hazard: any GPIO access that lands between adm1266_config_gpio() and the end of pmbus_do_probe() (for example a sysfs read from a user space agent that opens the gpiochip the instant gpiolib advertises it) races pmbus_do_probe()'s own device accesses with no serialisation. Move adm1266_config_gpio() down past pmbus_do_probe() so the chip isn't reachable from userspace until the PMBus state it depends on is fully initialised. Fixes: d98dfad35c38 ("hwmon: (pmbus/adm1266) Add support for GPIOs") Cc: stable@vger.kernel.org Signed-off-by: Abdurrahman Hussain Reviewed-by: Bartosz Golaszewski Link: https://lore.kernel.org/r/20260518-adm1266-gpio-fixes-v3-4-e425e4f88139@nexthop.ai Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit b2998ae903315af553d4860312d5189084eeedd9 Author: Abdurrahman Hussain Date: Mon May 18 17:52:26 2026 -0700 hwmon: (pmbus/adm1266) don't clobber GPIO bits before PDIO read in get_multiple commit 3327a12aee9e10ffa903e28b8445dfd1af5307c0 upstream. adm1266_gpio_get_multiple() zeroes *bits before the GPIO_STATUS loop and then a second time before the PDIO_STATUS loop: *bits = 0; for_each_set_bit(gpio_nr, mask, ADM1266_GPIO_NR) { ... set_bit(gpio_nr, bits); } ret = i2c_smbus_read_block_data(data->client, ADM1266_PDIO_STATUS, ...); ... *bits = 0; for_each_set_bit_from(gpio_nr, mask, ADM1266_GPIO_NR + ADM1266_PDIO_NR) { ... set_bit(gpio_nr, bits); } The second *bits = 0 throws away every GPIO bit the first loop just populated, so callers asking for any combination of GPIO and PDIO pins always see the GPIO portion of the returned bits as zero. Drop the redundant second assignment so both halves of the result survive. Fixes: d98dfad35c38 ("hwmon: (pmbus/adm1266) Add support for GPIOs") Cc: stable@vger.kernel.org Signed-off-by: Abdurrahman Hussain Reviewed-by: Bartosz Golaszewski Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20260518-adm1266-gpio-fixes-v3-2-e425e4f88139@nexthop.ai Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit fa7ca363069a70b0d1aa51e8892e3095fe2ac1ec Author: Abdurrahman Hussain Date: Mon May 18 17:52:25 2026 -0700 hwmon: (pmbus/adm1266) cap PDIO scan in get_multiple at ADM1266_PDIO_NR commit d7834d92251baade796812876e95555e2066fa9f upstream. adm1266_gpio_get_multiple() iterates the PDIO portion of the caller-supplied mask using for_each_set_bit_from(gpio_nr, mask, ADM1266_GPIO_NR + ADM1266_PDIO_STATUS) { ... } where ADM1266_PDIO_STATUS is the PMBus command code (0xE9, i.e. 233), not the number of PDIO pins. The intended upper bound is ADM1266_GPIO_NR + ADM1266_PDIO_NR = 25. gpiolib hands in a mask sized for gc.ngpio (= 25 bits on this chip), so the iteration walks find_next_bit() up to 242, reading up to 217 extra bits (a handful of unsigned-long words: four on 64-bit, seven on 32-bit) of whatever lives past the end of the mask in the caller's stack. Any incidental set bit in that range then drives a set_bit(gpio_nr, bits) call that writes past the end of the caller-supplied bits array too -- both out-of-bounds. Substitute ADM1266_PDIO_NR for the constant so the scan stops at the last real PDIO bit. Fixes: d98dfad35c38 ("hwmon: (pmbus/adm1266) Add support for GPIOs") Cc: stable@vger.kernel.org Signed-off-by: Abdurrahman Hussain Reviewed-by: Bartosz Golaszewski Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20260518-adm1266-gpio-fixes-v3-1-e425e4f88139@nexthop.ai Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 97a9cf2a8217ca1cdaf48cb9ab26e471632c7e7f Author: Abdurrahman Hussain Date: Fri May 15 15:11:51 2026 -0700 hwmon: (pmbus/adm1266) bounce blackbox records through a protocol-sized buffer commit 43cae21424ff8e33894a0f86c6b80b840c049fd7 upstream. adm1266_pmbus_block_xfer() copies the device-supplied block payload into the caller-provided buffer using the device-supplied length: memcpy(data_r, &msgs[1].buf[1], msgs[1].buf[0]); The helper does not know how large data_r is and trusts the device to return at most one record's worth of bytes. adm1266_nvmem_read_blackbox() violates that contract: it advances read_buff inside data->dev_mem in ADM1266_BLACKBOX_SIZE (64-byte) strides while the helper is willing to write up to ADM1266_PMBUS_BLOCK_MAX (255) bytes. A device that returns more than 64 bytes on the trailing record (read_buff offset 1984 in the 2048-byte dev_mem allocation) overflows dev_mem by up to 191 bytes before the post-call if (ret != ADM1266_BLACKBOX_SIZE) return -EIO; can reject the response. Contain the fix in the caller without changing the helper signature: read each record into a 255-byte local bounce buffer that matches the helper's maximum output, validate the returned length, and only then copy exactly ADM1266_BLACKBOX_SIZE bytes into the dev_mem slot. Fixes: 407dc802a9c0 ("hwmon: (pmbus/adm1266) Add Block process call") Cc: stable@vger.kernel.org Signed-off-by: Abdurrahman Hussain Link: https://lore.kernel.org/r/20260515-adm1266-fixes-v1-5-1c1ea1349cfe@nexthop.ai Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 2279c342d94eca225bf9f301c8806a05a1c81619 Author: Abdurrahman Hussain Date: Fri May 15 15:11:50 2026 -0700 hwmon: (pmbus/adm1266) include PEC byte in pmbus_block_xfer read buffer commit 487566cb1ccdf3756fdd7bf8d875e612ff3169bb upstream. adm1266_pmbus_block_xfer() sets up the read transaction with .buf = data->read_buf, .len = ADM1266_PMBUS_BLOCK_MAX + 2, but read_buf in struct adm1266_data is declared as u8 read_buf[ADM1266_PMBUS_BLOCK_MAX + 1]; For a max-length block response (length byte = 255 + up to 1 PEC byte), the i2c controller is told to write 257 bytes into a 256-byte buffer, putting one byte past the end of read_buf. The same response also makes the subsequent PEC compare if (crc != msgs[1].buf[msgs[1].buf[0] + 1]) read a byte beyond the array. Bump the read_buf declaration to ADM1266_PMBUS_BLOCK_MAX + 2 so the buffer can hold the length byte, up to 255 payload bytes, and the PEC byte the i2c_msg length already accounts for. Fixes: 407dc802a9c0 ("hwmon: (pmbus/adm1266) Add Block process call") Cc: stable@vger.kernel.org Signed-off-by: Abdurrahman Hussain Link: https://lore.kernel.org/r/20260515-adm1266-fixes-v1-4-1c1ea1349cfe@nexthop.ai Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 75c862adf3d3caab4f49bb3530723c215376e37c Author: Abdurrahman Hussain Date: Fri May 15 15:11:49 2026 -0700 hwmon: (pmbus/adm1266) reject implausible blackbox record_count commit 4afca954622d672ea65ed961bed01cf91caa034e upstream. adm1266_nvmem_read_blackbox() loops over a record_count that comes straight from byte 3 of the BLACKBOX_INFO response. The destination buffer is data->dev_mem, sized for the nvmem cell's declared 2048 bytes (ADM1266_BLACKBOX_MAX_RECORDS * ADM1266_BLACKBOX_SIZE = 32 * 64). A device that reports a record_count greater than 32 -- whether due to firmware bugs, bus corruption, or a non-responsive slave returning 0xff -- would walk read_buff past the end of the dev_mem allocation on the trailing iterations. Cap record_count at ADM1266_BLACKBOX_MAX_RECORDS (introduced here) before entering the loop and return -EIO on any larger value, so a malformed BLACKBOX_INFO response cannot drive the loop out of bounds. Fixes: 15609d189302 ("hwmon: (pmbus/adm1266) read blackbox") Cc: stable@vger.kernel.org Signed-off-by: Abdurrahman Hussain Link: https://lore.kernel.org/r/20260515-adm1266-fixes-v1-3-1c1ea1349cfe@nexthop.ai Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit e9b8f85daebffc34506c4705e34eb0f152ac88bf Author: Abdurrahman Hussain Date: Fri May 15 15:11:47 2026 -0700 hwmon: (pmbus/adm1266) seed timestamp from the real-time clock commit b86095e3d7dcf2bf80c747349a35912a87a85098 upstream. adm1266_set_rtc() seeds the chip's SET_RTC register from ktime_get_seconds(), which returns CLOCK_MONOTONIC -- i.e. seconds since the host last booted, not seconds since the Unix epoch. The chip stamps that value into every blackbox record it captures. Userspace reading those timestamps back expects wall-clock seconds: that's what the SET_RTC frame layout documents (datasheet Rev. D, Table 84) and what every other consumer of "seconds since epoch" assumes. Seeding from CLOCK_MONOTONIC gives blackbox records a timestamp that is only meaningful within a single boot of the host and silently resets to small values on every reboot. Switch to ktime_get_real_seconds() so the seed matches what the register is documented to hold. Fixes: 15609d189302 ("hwmon: (pmbus/adm1266) read blackbox") Cc: stable@vger.kernel.org Signed-off-by: Abdurrahman Hussain Link: https://lore.kernel.org/r/20260515-adm1266-fixes-v1-1-1c1ea1349cfe@nexthop.ai Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit e37dbe150515ff70113c7117a50c981978f5d3a1 Author: Sven Eckelmann Date: Sat May 2 21:25:19 2026 +0200 batman-adv: tt: prevent TVLV entry number overflow commit 99d9958fa10fb684b2a8e2c48a8d704122721420 upstream. The helpers to prepare the buffers for the local and global TT based replies are trying to sum up all TT entries which can be found for each VLAN. In theory, this sum can be too big for an u16 and therefore overflow. A too small buffer would then be allocated for the TVLV. The too small buffer will be handled gracefully by batadv_tt_tvlv_generate() and is not causing a buffer overflow - just a truncated reply. But this overflow shouldn't have happened in the first and the too small buffer should never have been allocated when an overflow was detected. Cc: stable@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 730de8733dd90f70d7580a9b329b971f8e1474a2 Author: Sven Eckelmann Date: Sat May 2 19:53:21 2026 +0200 batman-adv: tt: fix negative tt_buff_len commit b64963a2ceeb7529310b6cf253a1e540784422f4 upstream. batadv_orig_node::tt_buff_len was declared as s16, but the field is never intended to hold a negative value. When a value greater than 32767 is assigned, it wraps to a negative signed integer. In batadv_send_other_tt_response(), tt_buff_len is temporarily widened to s32. The incorrectly negative s16 value propagates into the s32, causing batadv_tt_prepare_tvlv_global_data() to allocate a full sized buffer but populates only a small portion of it with the collected changeset. All remaining bits are kept uninitialized. Using an u16 avoids this type confusion and ensures that no (negative) sign extension is performed in batadv_send_other_tt_response(). Cc: stable@kernel.org Fixes: a73105b8d4c7 ("batman-adv: improved client announcement mechanism") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 179eb62506a02d00370bd6478898cb632e10986c Author: Sven Eckelmann Date: Sat May 2 19:53:21 2026 +0200 batman-adv: tt: fix negative last_changeset_len commit fc92cdfcb295cefa4344d71a527d61b638b7bfc4 upstream. batadv_piv_tt::last_changeset_len len was declared as s16, but the field is never intended to hold a negative value. When a value greater than 32767 is assigned, it wraps to a negative signed integer. In batadv_send_my_tt_response(), last_changeset_len is temporarily widened to s32. The incorrectly negative s16 value propagates into the s32, causing batadv_tt_prepare_tvlv_local_data() to allocate a full sized buffer but populates only a small portion of it with the collected changeset. All remaining bits are kept uninitialized. Using an u16 avoids this type confusion and ensures that no (negative) sign extension is performed in batadv_send_my_tt_response(). Cc: stable@kernel.org Fixes: a73105b8d4c7 ("batman-adv: improved client announcement mechanism") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit b93ca6012712ecab2b551e120d7c95038d6a89e5 Author: Sven Eckelmann Date: Sat May 2 20:47:34 2026 +0200 batman-adv: tt: avoid empty VLAN responses commit fa1bd704940b5bcbc32c0b28db9167405c8ee5e0 upstream. The commit 16116dac2339 ("batman-adv: prevent TT request storms by not sending inconsistent TT TLVLs") added checks to the local (direct) TT response code. But the response can also be done indirectly by another node using the global TT state. To avoid such inconsistency states reported in the original fix, also avoid sending empty VLANs for replies from the global TT state. Cc: stable@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 7cac9c9ef4b7fa3e4959098b9801723fa9f25908 Author: Sven Eckelmann Date: Sat May 2 19:08:37 2026 +0200 batman-adv: tt: reject oversized local TVLV buffers commit 1e9fab756f8395096d5bba7be0c373c4c8f5d165 upstream. The commit 3a359bf5c61d ("batman-adv: reject oversized global TT response buffers") added a check to ensure that a global return buffer size can be stored in an u16. The same buffer handling also exists for the local data buffer but was not touched. A similar check should be also be in place for the local TVLV buffer. It doesn't have the similar attack surface because it is only generated from locally discovered MAC addresses but the dynamic nature could still cause temporarily to large buffers. Cc: stable@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 4cc85aec8d3c9ab4dc716dc9f1ed36fca16b227f Author: Sven Eckelmann Date: Sat May 2 19:47:11 2026 +0200 batman-adv: tt: fix TOCTOU race for reported vlans commit 94d27005016be15ffc638b2ecbc4d58805ad7b48 upstream. The local TT based TVLV is generated by first checking the number of VLANs which have at least one TT entry. A new buffer with the correct size for the VLANs is then allocated. Only then, the list of VLANs s used to fill the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock is held. But the actual number of TT entries of each VLAN can still increase during this time - just not the number of VLANs in the list. But the prefilter used in the buffer size calculation might still cause an increase of the number of VLANs which need to be stored. Simply because a VLAN might now suddenly have at least one entry when it had none in the pre-alloc check - and then needs to occupy space which was not allocated. It is better to overestimate the buffer size at the beginning and then fill the buffer only with the VLANs which are not empty. Cc: stable@kernel.org Fixes: 16116dac2339 ("batman-adv: prevent TT request storms by not sending inconsistent TT TLVLs") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 2d2d365d0b9d0987e37c6172f8c4b9f7a2ba569f Author: Sven Eckelmann Date: Sat May 16 12:33:41 2026 +0200 batman-adv: tp_meter: avoid role confusion in tp_list commit ff24f2ecfd94c07a2b89bac497433e3b23271cac upstream. Session lookups in tp_list matched only on destination address (and optionally session ID), leaving role validation to the caller. If two sessions with the same other_end coexisted (one as sender, one as receiver) a lookup could silently return the wrong one, causing the caller's role to bail out early, potentially skipping necessary cleanup. Move the role check into the lookup functions themselves so the correct entry is always returned, or none at all. Since batadv_tp_start() legitimately needs to detect any active session to a destination regardless of role, introduce a dedicated helper for that case rather than bending the existing lookup semantics. Cc: stable@kernel.org Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 72d670d7a4928003dd2e8c1dfedd424a8d4f9804 Author: Sven Eckelmann Date: Wed May 13 23:38:54 2026 +0200 batman-adv: tp_meter: fix race condition in send error reporting commit 71dce47f0758537fff78fddb5fb0d4632d29b29f upstream. batadv_tp_sender_shutdown() previously used two separate variables to track session state: sending (an atomic flag indicating whether the session was active) and reason (a plain enum storing the stop reason). This introduced a race window between the two writes: after sending was cleared to 0, batadv_tp_send() could observe the stopped state and call batadv_tp_sender_end() before reason was written, causing the wrong stop reason to be reported to the caller. Fix this by consolidating both variables into a single atomic send_result, which holds 0 while the session is running and the stop reason once it ends. Cc: stable@kernel.org Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit b285bc0a97f43823a4967fb6d286de4c7f53d541 Author: Sven Eckelmann Date: Sun May 10 11:31:03 2026 +0200 batman-adv: tp_meter: fix tp_vars reference leak in receiver shutdown commit 77098e4bea37af51d3962efa88a5af2ea5e1ac57 upstream. The receiver shutdown timer handler, batadv_tp_receiver_shutdown(), is responsible for releasing the tp_vars reference it holds. However, the existing logic for coordinating this release with batadv_tp_stop_all() was flawed. timer_shutdown_sync() guarantees the timer will not fire again after it returns, but it returns non-zero only when the timer was pending at the time of the call. If the timer had already expired (and batadv_tp_stop_all() would unsucessfully try to rearm itself), batadv_tp_stop_all() skips its batadv_tp_vars_put(), and batadv_tp_receiver_shutdown() fails to put its own reference as well. Fix this by introducing a new atomic variable receiving that is set to 1 when the receiver is initialized and cleared atomically with atomic_xchg() by whichever side claims it first. Only the side that observes the transition from 1 to 0 is responsible for releasing the tp_vars timer reference, eliminating the uncertainty. Cc: stable@kernel.org Fixes: 3d3cf6a7314a ("batman-adv: stop tp_meter sessions during mesh teardown") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 770bf0a35f0620b526fd4193889d1e77084e4c43 Author: Sven Eckelmann Date: Wed May 13 10:43:54 2026 +0200 batman-adv: tp_meter: directly shut down timer on cleanup commit d5487249a81ea658717614009c8f46acc5b7101a upstream. batadv_tp_sender_cleanup() was calling timer_delete_sync() followed by timer_delete() to guard against the timer handler re-arming itself between the two calls. This double-deletion hack relied on the sending status being set to 0 to suppress re-arming. Replace both calls with a single timer_shutdown_sync(). This function both waits for any running timer callback to complete (like timer_delete_sync()) and permanently disarms the timer so it cannot be re-armed afterwards, making re-arming prevention unconditional and self-documenting. The re-arming property is also required because otherwise: 1. context 0 (batadv_tp_recv_ack()) checks in batadv_tp_reset_sender_timer() if sending is still 1 -> it is 2. context 1 changes in batadv_tp_sender_shutdown() sending to 0 and in this process forces the kthread to stop timer in batadv_tp_sender_cleanup() 3. context 0 continues in batadv_tp_reset_sender_timer() and rearms the timer -> but the reference for it is already gone Cc: stable@kernel.org Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit dc2ae5fbd2dadc26735092f140b246841d969a11 Author: Sven Eckelmann Date: Wed May 13 09:01:35 2026 +0200 batman-adv: tp_meter: avoid use of uninit sender vars commit 6c65cf23d4c6170fcf5714c32aa64689718cb142 upstream. batadv_tp_recv_ack() and batadv_tp_stop() are only valid for tp_vars in the BATADV_TP_SENDER role. When called with a BATADV_TP_RECEIVER role, it proceeds to read sender-only members that were never initialized, leading to undefined behavior. This can be triggered when a node that is currently acting as a receiver in an ongoing tp_meter session receives a malicious ACK packet. Guard against this by checking tp_vars->role immediately after the lookup and bailing out if it is not BATADV_TP_SENDER, before any of those members are accessed. Cc: stable@kernel.org Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation") Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Reviewed-by: Yuan Tan Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 6921a7683ae9ad0208d829e71f725a9e25ccff49 Author: Sven Eckelmann Date: Tue May 19 09:23:49 2026 +0200 batman-adv: bla: avoid NULL-ptr deref for claim via dropped interface commit f80d3d98d2ff78d9e2fe5d68b1f45948c4f7bd24 upstream. Without rtnl_lock held, a hardif might be retrieved as primary interface of a meshif, but then (while operating on this interface) getting decoupled from the mesh interface. In this case, the meshif still exists but the pointer from the primary hardif to the meshif is set to NULL. The mesh_iface must be checked first to be non-NULL before continuing to send an ARP request using meshif. Cc: stable@kernel.org Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code") Reported-by: Ido Schimmel Reported-by: syzbot+9fdcc9f05a98a540b816@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9fdcc9f05a98a540b816 Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 45384612f29692fbf0c770200361a7acff90125c Author: Sven Eckelmann Date: Tue May 12 09:13:31 2026 +0200 batman-adv: bla: avoid double decrement of bla.num_requests commit 83ab69bd12b80f6ea169c8bea6977701b53a043d upstream. The bla.num_requests is increased when no request_sent was in progress. And it is decremented in various places (announcement was received, backbone is purged, periodic work). But the check if the request_sent is actually set to a specific state and the atomic_dec/_inc are not safe because they are not atomic (TOCTOU) and multiple such code portions can run concurrently. At the same time, it is necessary to modify request_sent (state) and bla.num_requests atomically. Otherwise batadv_bla_send_request() might set request_sent to 1 and is interrupted. batadv_handle_announce() can then set request_sent back to 0 and decrement num_requests before batadv_bla_send_request() incremented it. The two operations must therefore be locked. And since state (request_sent) and wait_periods are only accessed inside this lock, they can be converted to simpler datatypes. And to avoid that the bla.num_requests is touched by a parallel running context with a valid backbone_gw reference after batadv_bla_purge_backbone_gw() ran, a third state "stopped" is required to correctly signal that a backbone_gw is in the state of being cleaned up. Cc: stable@kernel.org Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit c6de1a5a9c406e30b91f1515a6ce05cc84023baa Author: Sven Eckelmann Date: Sun May 10 11:43:20 2026 +0200 batman-adv: bla: fix report_work leak on backbone_gw purge commit 0459430add32ea41f3e2ef9351610e6d33627a6b upstream. batadv_bla_purge_backbone_gw() removes stale backbone gateway entries, but fails to properly handle their associated report_work: - If report_work is running, the purge must wait for it to finish before freeing the backbone_gw, otherwise the worker may access freed memory (e.g. bat_priv). - If report_work is pending, the purge must cancel it and release the reference held for that pending work item. The previous implementation called hlist_for_each_entry_safe() inside a spin_lock_bh() section, but cancel_work_sync() may sleep and therefore cannot be called from within a spinlock-protected region. Restructure the loop to handle one entry per spinlock critical section: acquire the lock, find the next entry to purge, remove it from the hash list, then release the lock before calling cancel_work_sync() and dropping the hash_entry reference. Repeat until no more entries require purging. Cc: stable@kernel.org Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code") Reviewed-by: Simon Wunderlich Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 5895ad21c7059a652da83fb817510f7a1e962abf Author: Sven Eckelmann Date: Wed May 13 09:01:36 2026 +0200 batman-adv: frag: disallow unicast fragment in fragment commit bc62216dc8e221e3781afa14430f45208bfa9af9 upstream. batadv_frag_skb_buffer() is called by batadv_batman_skb_recv() when a BATADV_UNICAST_FRAG packet is received. Once all fragments are collected and the packet is reassembled, batadv_recv_frag_packet() calls batadv_batman_skb_recv() again to process the defragmented payload. A malicious sender can craft a BATADV_UNICAST_FRAG packet whose reassembled payload is itself a BATADV_UNICAST_FRAG packet (matryoshka-style nesting). Each nesting level recurses through batadv_batman_skb_recv() without bound, growing the kernel stack until it is exhausted. Since refragmentation or fragments in fragments are not actually allowed, discard all packets which are still BATADV_UNICAST_FRAG packets after the defragmentation process. Cc: stable@kernel.org Fixes: 610bfc6bc99b ("batman-adv: Receive fragmented packets and merge") Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Reviewed-by: Yuan Tan Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 90ae3eae06b7b8ab9f6250b9497c860915b4c17b Author: Luxiao Xu Date: Mon May 11 18:52:09 2026 +0200 batman-adv: fix tp_meter counter underflow during shutdown commit 94f3b133168d1c49895e7cc6afbcf1cc0b354602 upstream. batadv_tp_sender_shutdown() unconditionally decrements the "sending" atomic counter. If multiple paths (e.g. timeout, user cancel, and normal finish) call this function, the counter can underflow to -1. Since the sender logic treats any non-zero value as "still sending", a negative value causes the sender kthread to loop indefinitely. This leads to a use-after-free when the interface is removed while the zombie thread is still active. Fix this by using atomic_xchg() to ensure the counter only transitions from 1 to 0 once. Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Luxiao Xu Signed-off-by: Ren Wei [sven: added missing change in batadv_tp_send] Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 3eb8bcb823391bd58997831b3c9c152a4ba8e255 Author: Ruide Cao Date: Wed May 13 11:58:15 2026 +0800 batman-adv: fix fragment reassembly length accounting commit 9cd3f16c320bfdadd4509358122368deb56a5741 upstream. batman-adv keeps a running payload length for queued fragments and uses it to validate a fragment chain before reassembly. That accounting currently allows the accumulated fragment length to be truncated during updates. As a result, malformed fragment chains can bypass the intended validation and drive reassembly with inconsistent length state, leading to a local denial of service. Fix the accounting by storing the accumulated length in a length-typed field and rejecting update overflows before the existing validation logic runs. The fix was verified against the original reproducer and against valid fragment reassembly paths. Fixes: 610bfc6bc99b ("batman-adv: Receive fragmented packets and merge") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Ruide Cao Tested-by: Ren Wei Signed-off-by: Ren Wei Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 9cceea8eeba710def2a5707ee00f00c74a9a1cac Author: Sven Eckelmann Date: Wed May 13 09:01:34 2026 +0200 batman-adv: dat: handle forward allocation error commit 2d8826a2d3657cea66fb0370f9e521575a673871 upstream. batadv_dat_forward_data() calls pskb_copy_for_clone() to duplicate an skb for each DHT candidate, but does not check the return value before passing it to batadv_send_skb_prepare_unicast_4addr(). That function dereferences the skb unconditionally, so a failed allocation triggers a NULL pointer dereference. Skip forwarding to the current DHT candidate on allocation failure. Cc: stable@kernel.org Fixes: 785ea1144182 ("batman-adv: Distributed ARP Table - create DHT helper functions") Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Reviewed-by: Yuan Tan Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit ae7aeb0ce3c0ebbe357ed525779acac197a18086 Author: Ruijie Li Date: Thu May 14 16:13:25 2026 +0800 batman-adv: clear current gateway during teardown commit a340a51ed801eab7bb454150c226323b865263cc upstream. batadv_gw_node_free() removes the gateway list entries during mesh teardown, but it does not clear the currently selected gateway. This leaves stale gateway state behind across cleanup and can break a later mesh recreation. Clear bat_priv->gw.curr_gw before walking the gateway list so the selected gateway reference is dropped as part of teardown. Fixes: 2265c1410864 ("batman-adv: gateway election code refactoring") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Ruijie Li Signed-off-by: Zhanpeng Li Signed-off-by: Ren Wei Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 8a3707653ab658e082ccd992e92594e01b09a3fc Author: Sven Eckelmann Date: Thu May 14 19:22:02 2026 +0200 batman-adv: mcast: fix use-after-free in orig_node RCU release commit 20c2d6a20ca936f5aaa6dd40f73f262ac45c87cc upstream. batadv_mcast_purge_orig() removes entries from RCU-protected hlists but does not wait for an RCU grace period before returning. Concurrent RCU readers may still accesses references to those entries at the point of removal. RCU-protected readers trying to operate on entries like orig->mcast_want_all_ipv6_node will then access already freed memory. Fix this by moving batadv_mcast_purge_orig() to batadv_orig_node_release(), just before the call_rcu() invocation. This ensures RCU readers that were active at purge time have drained before the orig_node memory is reclaimed. Cc: stable@kernel.org Fixes: ab49886e3da7 ("batman-adv: Add IPv4 link-local/IPv6-ll-all-nodes multicast support") Acked-by: Linus Lüssing Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit ca3ff3d2a0af42a1636f4c01087bc50923ce50d4 Author: Sven Eckelmann Date: Fri May 15 22:00:40 2026 +0200 batman-adv: iv: recover OGM scheduling after forward packet error commit aa3153bd139a6c48667dcd02608d3b2c80bff02c upstream. When batadv_iv_ogm_schedule_buff() fails to allocate and queue a forward packet for OGM transmission, the work item that drives periodic OGM scheduling is never re-armed. This silently halts transmission of the node's own OGMs on the affected interface — only OGMs from other peers continue to be aggregated and forwarded. Fix this by tracking whether batadv_iv_ogm_queue_add() (and transitively batadv_iv_ogm_aggregate_new()) successfully scheduled a forward packet. When scheduling fails, batadv_iv_ogm_schedule_buff() falls back to queuing a dedicated recovery work item (reschedule_work) that fires after one originator interval and calls batadv_iv_ogm_schedule() again. Cc: stable@kernel.org Fixes: c6c8fea29769 ("net: Add batman-adv meshing protocol") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit ede47988ac5687793745b17c1634a496a2299919 Author: Sven Eckelmann Date: Sat May 9 21:55:29 2026 +0200 batman-adv: tvlv: reject oversized TVLV packets commit f50487e3566358b2b982b7801945e858c78ad9ab upstream. batadv_tvlv_container_ogm_append() builds a TVLV packet section from the tvlv.container_list. The total size of this section is computed by batadv_tvlv_container_list_size(), which sums the sizes of all registered containers. The return type and accumulator in batadv_tvlv_container_list_size() were u16. If the accumulated size exceeds U16_MAX, the value wraps around, causing the subsequent allocation in batadv_tvlv_container_ogm_append() to be undersized. The memcpy-style copy that follows would then write beyond the end of the allocated buffer, corrupting kernel memory. Fix this by widening the return type of batadv_tvlv_container_list_size() to size_t. In batadv_tvlv_container_ogm_append(), check the computed length against U16_MAX before proceeding, and bail out as if the allocation had failed when the limit is exceeded. Cc: stable@kernel.org Fixes: ef26157747d4 ("batman-adv: tvlv - basic infrastructure") Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Reviewed-by: Yuan Tan Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 23d4ce84df4d614f39ec3244f2a5a731d185d08d Author: Sven Eckelmann Date: Thu May 14 16:33:12 2026 +0200 batman-adv: tvlv: abort OGM send on tvlv append failure commit 501368506563e151b322c8c3f228b796e615b90d upstream. batadv_tvlv_container_ogm_append() could fail in two ways: a memory allocation failure when resizing the packet buffer, or the tvlv data exceeding U16_MAX bytes. In both cases the function previously returned the old (now stale) tvlv_value_len rather than signalling an error, causing the OGM/OGM2 send path to transmit a packet whose TVLV length field no longer matched the actual buffer contents. And because it also didn't fill in the new TVLV data, sending either uninitialized or corrupted data on the wire. All errors in batadv_tvlv_container_ogm_append() must be forwarded to the caller. And the caller must abort the send of the OGM2. For B.A.T.M.A.N. IV, it is currently not allowed to abort the send. The non-TVLV part of the OGM must be queued up instead. Cc: stable@kernel.org Fixes: ef26157747d4 ("batman-adv: tvlv - basic infrastructure") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 1be1e99cbd5b74a69d3f92200ca87cf1bce852db Author: Sven Eckelmann Date: Sat May 9 22:44:12 2026 +0200 batman-adv: v: stop OGMv2 on disabled interface commit f8ce8b8331a1bc44ad4905886a482214d428b253 upstream. When a batadv_hard_iface is disabled, its mesh_iface pointer is set to NULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs via batadv_v_ogm_queue_on_if() for interfaces that have since lost their mesh_iface association. This results in a NULL pointer dereference when batadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on the now NULL hard_iface->mesh_iface to retrieve the batadv_priv. It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks that it is using the same mesh_iface for which batadv_v_ogm_send_meshif() was called. Cc: stable@kernel.org Fixes: 0da0035942d4 ("batman-adv: OGMv2 - add basic infrastructure") Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Reviewed-by: Yuan Tan Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 1ecde19bfce6535bffddad1139ff466b6d401b8e Author: Harry Wentland Date: Thu May 7 16:26:31 2026 -0400 drm/amd/display: Validate payload length and link_index in dc_process_dmub_aux_transfer_async commit 6c92f6d9600efa3ef0d9e560a2b52776d9803c29 upstream. [Why&How] dc_process_dmub_aux_transfer_async() copies payload->length bytes into a 16-byte stack buffer (dpaux.data[16]) guarded only by an ASSERT(), which is a no-op in release builds. If a caller ever passes length > 16 this results in a stack buffer overflow via memcpy. Additionally, link_index is used to dereference dc->links[] without bounds checking against dc->link_count, risking an out-of-bounds access. Replace the ASSERT with a hard runtime check that returns false when payload->length exceeds the destination buffer size, and add a bounds check for link_index before it is used. Assisted-by: GitHub Copilot:Claude claude-4-opus Reviewed-by: Alex Hung Signed-off-by: Harry Wentland Signed-off-by: Ivan Lipski Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit ba4caa9fecdf7a38f98c878ad05a8a64148b6881) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 7ca695b3122297b06a3ed605bbe1cd32c85d9f5a Author: Harry Wentland Date: Mon May 4 16:14:11 2026 -0400 drm/amd/display: Validate GPIO pin LUT table size before iterating commit 86d2b20644b11d21fe52c596e6e922b4590a3e3f upstream. [Why&How] The GPIO pin table parsers in get_gpio_i2c_info() and bios_parser_get_gpio_pin_info() derive an element count from the VBIOS table_header.structuresize field, then iterate over gpio_pin[] entries. However, GET_IMAGE() only validates that the table header itself fits within the BIOS image. If the VBIOS reports a structuresize larger than the actual mapped data, the loop reads past the end of the BIOS image, causing an out-of-bounds read. Fix this by calling bios_get_image() to validate that the full claimed structuresize is accessible within the BIOS image before entering the loop in both functions. Assisted-by: GitHub Copilot:claude-opus-4-6 Reviewed-by: Alex Hung Signed-off-by: Harry Wentland Signed-off-by: Ivan Lipski Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 6bbd703ea1c141d7ac0e7f7e82ff5fd237b67a17 Author: Harry Wentland Date: Mon May 4 11:14:45 2026 -0400 drm/amd/display: Fix integer overflow in bios_get_image() commit cd86529ec61474a38c3837fb7823790a7c3f8cce upstream. [Why&How] The bounds check in bios_get_image() computes 'offset + size' using unsigned 32-bit arithmetic before comparing against bios_size. If a VBIOS image contains a near-UINT32_MAX offset the addition wraps to a small value, the comparison passes, and the function returns a wild pointer past the VBIOS mapping. Additionally, the comparison uses '<' (strict), which incorrectly rejects the valid exact-fit case where offset + size == bios_size. Fix both issues by restructuring the check to avoid the addition entirely: first reject if offset alone exceeds bios_size, then check size against the remaining space (bios_size - offset). This eliminates the overflow and correctly permits exact-fit accesses. Assisted-by: GitHub Copilot:claude-opus-4.6 Reviewed-by: Alex Hung Signed-off-by: Harry Wentland Signed-off-by: Ivan Lipski Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit d40fb392af659c4a02b560319f226842f6ec1a95) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit d35563813296ec7e965ad87415a0f82944bc41a2 Author: Osama Abdelkader Date: Thu Apr 30 21:56:59 2026 +0200 drm/bridge: megachips: remove bridge when irq request fails commit d45d5c819f2cd0b6b5d76a194a537a5f4aeefecb upstream. If devm_request_threaded_irq() fails after drm_bridge_add(), remove the bridge before returning. Keep drm_bridge_add() rather than devm_drm_bridge_add(): registration is tied to the STDP4028 device while ge_b850v3_register() may complete from either I2C probe; devm would not unwind the bridge if the other client's probe fails. Signed-off-by: Osama Abdelkader Fixes: fcfa0ddc18ed ("drm/bridge: Drivers for megachips-stdpxxxx-ge-b850v3-fw (LVDS-DP++)") Cc: stable@vger.kernel.org Reviewed-by: Luca Ceresoli Tested-by: Ian Ray Link: https://patch.msgid.link/20260430195700.80317-1-osama.abdelkader@gmail.com Signed-off-by: Luca Ceresoli Signed-off-by: Greg Kroah-Hartman commit 95306db11956dd8d82f56a20452c13008519388a Author: Julien Chauveau Date: Tue Mar 24 20:30:11 2026 +0100 drm/bridge: it66121: acquire reset GPIO in probe commit e02b5262fd288cc235f14e12233ea54e78c04611 upstream. The it66121_ctx structure has a gpio_reset field, and it66121_hw_reset() calls gpiod_set_value() on it. However, the GPIO descriptor is never acquired via devm_gpiod_get(), leaving gpio_reset as NULL throughout the driver lifetime. gpiod_set_value() silently returns when passed a NULL descriptor, so the hardware reset sequence in it66121_hw_reset() is a no-op. This leaves the chip in an undefined state at probe time, which can prevent it from responding on the I2C bus. The DT binding marks reset-gpios as a required property, so all compliant device trees provide this GPIO. Add the missing devm_gpiod_get() call after enabling power supplies and before the hardware reset, so the chip is properly reset with power applied. Fixes: 988156dc2fc9 ("drm: bridge: add it66121 driver") Cc: stable@vger.kernel.org Signed-off-by: Julien Chauveau Reviewed-by: Javier Martinez Canillas Tested-by: Javier Martinez Canillas Link: https://patch.msgid.link/20260324193011.16583-1-chauveau.julien@gmail.com Signed-off-by: Javier Martinez Canillas Signed-off-by: Greg Kroah-Hartman commit 3ed448c1dc78ddbf2e1f29dc00788c028ccdbb82 Author: Alan Liu Date: Fri May 1 12:35:48 2026 +0800 drm/amdgpu/vpe: Force collaborate sync after TRAP commit b6074630a461b1322a814988779005cbc43612ea upstream. VPE1 could possibly hang and fail to power off at the end of commands in collaboration mode. This workaround adds a COLLAB_SYNC after TRAP to force instances synchronized to avoid VPE1 fail to power off. Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Alan liu Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5171 Signed-off-by: Alex Deucher (cherry picked from commit a8b749c5c5afb7e5daa2bfb95d958fb3c6b8f055) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 8fadd01cf461fee5bb11506621339c548447e5c7 Author: Deepanshu Kartikey Date: Tue May 19 13:52:47 2026 +0530 drm/virtio: use uninterruptible resv lock for plane updates commit 9af1b6e175c82daf4b423da339a722d8e67a735a upstream. virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush() lock the framebuffer BO's dma_resv via virtio_gpu_array_lock_resv() and ignore its return value. The function can fail with -EINTR from dma_resv_lock_interruptible() (signal during lock wait) or with -ENOMEM from dma_resv_reserve_fences() (fence slot allocation), leaving the resv lock not held. The queue path then walks the object array and calls dma_resv_add_fence(), which requires the lock held; with lockdep enabled this trips dma_resv_assert_held(): WARNING: drivers/dma-buf/dma-resv.c:296 at dma_resv_add_fence+0x71e/0x840 Call Trace: virtio_gpu_array_add_fence virtio_gpu_queue_ctrl_sgs virtio_gpu_queue_fenced_ctrl_buffer virtio_gpu_cursor_plane_update drm_atomic_helper_commit_planes drm_atomic_helper_commit_tail commit_tail drm_atomic_helper_commit drm_atomic_commit drm_atomic_helper_update_plane __setplane_atomic drm_mode_cursor_universal drm_mode_cursor_common drm_mode_cursor_ioctl drm_ioctl __x64_sys_ioctl Beyond the WARN, mutating the dma_resv fence list without the lock races with concurrent readers/writers and can corrupt the list. Both call sites run inside the .atomic_update plane callback, which DRM atomic helpers do not allow to fail (by the time it runs, the commit has been signed off to userspace and there is no clean rollback path). Moving the lock acquisition to .prepare_fb was rejected because the broader lock scope deadlocks against other BO locking paths in the same atomic commit. Introduce virtio_gpu_lock_one_resv_uninterruptible() that uses dma_resv_lock() instead of dma_resv_lock_interruptible(). This eliminates the -EINTR failure mode -- the realistic syzbot trigger -- without extending the lock hold across the commit. The helper locks a single BO and rejects nents > 1 with -EINVAL; both fix sites lock exactly one BO. Use it from virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush(); check the return value to handle the remaining -ENOMEM case from dma_resv_reserve_fences() by freeing the objs and skipping the plane update for that frame. The framebuffer BOs touched here are not shared with other contexts and lock contention is expected to be brief, so the loss of signal-interruptibility is acceptable. Other callers of virtio_gpu_array_lock_resv() (the ioctl paths) continue to use the interruptible variant. The bug was reported by syzbot, triggered via fault injection (fail_nth) on the DRM_IOCTL_MODE_CURSOR path, which forces the -ENOMEM branch in dma_resv_reserve_fences(). Reported-by: syzbot+72bd3dd3a5d5f39a0271@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=72bd3dd3a5d5f39a0271 Fixes: 5cfd31c5b3a3 ("drm/virtio: fix virtio_gpu_cursor_plane_update().") Cc: stable@vger.kernel.org Signed-off-by: Deepanshu Kartikey Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/20260519082247.34470-1-kartikey406@gmail.com Signed-off-by: Greg Kroah-Hartman commit 35671087a272cd236ff2785eff16970b0ee9b112 Author: Maíra Canal Date: Fri May 15 12:07:15 2026 -0300 drm/v3d: Release indirect CSD GEM reference on CPU job free commit 6eb6e5acafa46854d4363e6c34981289995f3ace upstream. v3d_get_cpu_indirect_csd_params() takes a reference to the indirect BO via drm_gem_object_lookup() and stashes it in cpu_job->indirect_csd.indirect, but nothing on the CPU job teardown path ever drops that reference. Drop the extra reference in v3d_cpu_job_free(). The NULL check covers ioctl errors before the lookup ran and CPU job types other than V3D_CPU_JOB_TYPE_INDIRECT_CSD, which leave the field zero-initialised. Cc: stable@vger.kernel.org Fixes: 18b8413b25b7 ("drm/v3d: Create a CPU job extension for a indirect CSD job") Assisted-by: Claude:claude-opus-4.7 Reviewed-by: Iago Toral Quiroga Link: https://patch.msgid.link/20260515-v3d-cpu-job-leaks-v1-2-7f147cbbf935@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Greg Kroah-Hartman commit 0f8efc45740b0628a787d1b0be8a0ddabd700625 Author: Maíra Canal Date: Fri May 15 12:07:14 2026 -0300 drm/v3d: Fix use-after-free of CPU job query arrays on error path commit b0fe80c0b9250b35e2211bf3117e7aca814a21b0 upstream. The CPU job ioctl's fail label calls kvfree() on cpu_job's timestamp and performance query arrays after v3d_job_cleanup(), which drops the job's last reference and frees cpu_job. Reading cpu_job at that point is a use-after-free. Also, on the early v3d_job_init() failure path, it is a NULL dereference, since v3d_job_deallocate() zeroes the local pointer. In the success path, the arrays are released from the scheduler's .free_job callback, but on the error path, they are freed manually, as the job was never pushed to the scheduler. While the success path deals with this correctly, the fail path doesn't. On top of that, the manual kvfree() calls only free the array storage; they don't drm_syncobj_put() the per-query syncobjs that v3d_timestamp_query_info_free() and v3d_performance_query_info_free() release on the success path. So the same fail path that triggers the use-after-free also leaks one syncobj reference per query. Unify the CPU job teardown into the CPU job's kref destructor, mirroring v3d_render_job_free(). The scheduler's .free_job slot reverts to the generic v3d_sched_job_free() and the fail label drops the manual kvfree() calls, leaving a single teardown path that is reached from both the scheduler and the ioctl error path. That removes the use-after-free, the NULL dereference, and the syncobj leak by construction. Cc: stable@vger.kernel.org Fixes: 9ba0ff3e083f ("drm/v3d: Create a CPU job extension for the timestamp query job") Assisted-by: Claude:claude-opus-4.7 Reviewed-by: Iago Toral Quiroga Link: https://patch.msgid.link/20260515-v3d-cpu-job-leaks-v1-1-7f147cbbf935@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Greg Kroah-Hartman commit 942968260e61d4a5d7552b20814b6277f9c553df Author: Daniel J Blueman Date: Fri May 8 14:57:21 2026 +0800 drm/msm: Fix shrinker deadlock commit 3392291fc509d8ad6e4ad90f15b0a193f721cbc9 upstream. With PROVE_LOCKING on an Snapdragon X1 and VM reclaim pressure, we see: ====================================================== WARNING: possible circular locking dependency detected 7.0.0-debug+ #43 Tainted: G W ------------------------------------------------------ kswapd0/82 is trying to acquire lock: ffff800080ec3870 (reservation_ww_class_acquire){+.+.}-{0:0}, at: msm_gem_shrinker_scan+0x17c/0x400 [msm] but task is already holding lock: ffffc31709b263b8 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x88/0x988 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (fs_reclaim){+.+.}-{0:0}: __lock_acquire+0x4d0/0xad0 lock_acquire.part.0+0xc4/0x248 lock_acquire+0x8c/0x248 fs_reclaim_acquire+0xd0/0xf0 dma_resv_lockdep+0x224/0x348 do_one_initcall+0x84/0x5d0 do_initcalls+0x194/0x1d8 kernel_init_freeable+0x128/0x180 kernel_init+0x2c/0x160 ret_from_fork+0x10/0x20 -> #1 (reservation_ww_class_mutex){+.+.}-{4:4}: __lock_acquire+0x4d0/0xad0 lock_acquire.part.0+0xc4/0x248 lock_acquire+0x8c/0x248 dma_resv_lockdep+0x1a8/0x348 do_one_initcall+0x84/0x5d0 do_initcalls+0x194/0x1d8 kernel_init_freeable+0x128/0x180 kernel_init+0x2c/0x160 ret_from_fork+0x10/0x20 -> #0 (reservation_ww_class_acquire){+.+.}-{0:0}: check_prev_add+0x114/0x790 validate_chain+0x594/0x6f0 __lock_acquire+0x4d0/0xad0 lock_acquire.part.0+0xc4/0x248 lock_acquire+0x8c/0x248 drm_gem_lru_scan+0x1ac/0x440 msm_gem_shrinker_scan+0x17c/0x400 [msm] do_shrink_slab+0x150/0x4a0 shrink_slab+0x144/0x460 shrink_one+0x9c/0x1b0 shrink_many+0x27c/0x5c0 shrink_node+0x344/0x550 balance_pgdat+0x2c0/0x988 kswapd+0x11c/0x318 kthread+0x10c/0x128 ret_from_fork+0x10/0x20 other info that might help us debug this: Chain exists of: reservation_ww_class_acquire --> reservation_ww_class_mutex --> fs_reclaim Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs_reclaim); lock(reservation_ww_class_mutex); lock(fs_reclaim); lock(reservation_ww_class_acquire); *** DEADLOCK *** 1 lock held by kswapd0/82: #0: ffffc31709b263b8 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x88/0x988 stack backtrace: CPU: 4 UID: 0 PID: 82 Comm: kswapd0 Tainted: G W 7.0.0-debug+ #43 PREEMPT(full) Tainted: [W]=WARN Hardware name: LENOVO 21BX0016US/21BX0016US, BIOS N3HET94W (1.66 ) 09/15/2025 Call trace: show_stack+0x20/0x40 (C) dump_stack_lvl+0x9c/0xd0 dump_stack+0x18/0x30 print_circular_bug+0x114/0x120 check_noncircular+0x178/0x198 check_prev_add+0x114/0x790 validate_chain+0x594/0x6f0 __lock_acquire+0x4d0/0xad0 lock_acquire.part.0+0xc4/0x248 lock_acquire+0x8c/0x248 drm_gem_lru_scan+0x1ac/0x440 msm_gem_shrinker_scan+0x17c/0x400 [msm] do_shrink_slab+0x150/0x4a0 shrink_slab+0x144/0x460 shrink_one+0x9c/0x1b0 shrink_many+0x27c/0x5c0 shrink_node+0x344/0x550 balance_pgdat+0x2c0/0x988 kswapd+0x11c/0x318 kthread+0x10c/0x128 ret_from_fork+0x10/0x20 kswapd0 holding fs_reclaim calls the MSM shrinker, which calls dma_resv_lock. This in turn acquires fs_reclaim. Fix this deadlock by using dma_resv_trylock() instead, dropping the subsequently unused passed wait-wound lock 'ticket'. Cc: stable@vger.kernel.org Signed-off-by: Daniel J Blueman Fixes: fe4952b5f27c ("drm/msm: Convert vm locking") Patchwork: https://patchwork.freedesktop.org/patch/723564/ Message-ID: <20260508065722.18785-1-daniel@quora.org> [rob: fixup compile errors, replace lockdep splat with something legible] Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit 508fd8ab158abd04b7f7d0f707cd6d6c405df4ea Author: Bartosz Golaszewski Date: Wed May 6 13:57:00 2026 +0200 device property: set fwnode->secondary to NULL in fwnode_init() commit 215c90ee656114f5e8c32408228d97082f8e0eef upstream. 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 uninitalized 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. Cc: stable Fixes: 01bb86b380a3 ("driver core: Add fwnode_init()") Signed-off-by: Bartosz Golaszewski Reviewed-by: Rafael J. Wysocki (Intel) Reviewed-by: Andy Shevchenko Reviewed-by: Sakari Ailus Link: https://patch.msgid.link/20260506115701.23035-1-bartosz.golaszewski@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 22d9b9739b8ead1445ad4b3aa514b181b29b6893 Author: Huacai Chen Date: Thu May 21 20:58:40 2026 +0800 LoongArch: Remove unused code to avoid build warning commit 0ccc9d47cf020994097ff51827cebd04aa2b0bf4 upstream. After commit feee6b2989165631b1 ("mm/memory_hotplug: shrink zones when offlining memory"), __remove_pages() doesn't need the "zone" parameter so the "page" variable is also unused. Remove the unused code to avoid such build warning: arch/loongarch/mm/init.c: In function 'arch_remove_memory': arch/loongarch/mm/init.c:134:22: warning: variable 'page' set but not used [-Wunused-but-set-variable=] 134 | struct page *page = pfn_to_page(start_pfn); Cc: Reviewed-by: Guo Ren Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit f27a3b9aadfb53150a1b033f1d463f63ad800cf6 Author: Tiezhu Yang Date: Fri May 22 15:05:07 2026 +0800 LoongArch: kprobes: Use larch_insn_text_copy() to patch instructions commit e3ef9a28f558d1cbf0b42d6dcd16c60da557562b upstream. On SMP systems, kprobe handlers would occasionally fail to execute on certain CPU cores. The issue is hard to reproduce and typically occurs randomly under high system load. The root cause is a software-side instruction hazard. According to the LoongArch Reference Manual, while the cache coherency is maintained by hardware, software must explicitly use the "IBAR" instruction to ensure the instruction fetch unit (IFU) observes the effects of recent stores. The current arch_arm_kprobe() and arch_disarm_kprobe() only execute the "IBAR" barrier (via flush_insn_slot -> local_flush_icache_range) on the local CPU. This leaves a vulnerable window where remote CPU cores may continue executing stale instructions from their pipelines or prefetch buffers, as they have not executed an "IBAR" since the code modification. Switch to larch_insn_text_copy() to fix this: 1. Synchronization: It uses stop_machine_cpuslocked() to synchronize all online CPUs, ensuring no CPU is executing the target code area during modification. 2. Visibility: By passing cpu_online_mask to stop_machine_cpuslocked(), the callback text_copy_cb() is executed on all online cores. Each CPU core invokes local_flush_icache_range() to execute "IBAR", clearing instruction hazards system-wide and ensuring the "break" instruction is visible to the fetch units of all cores. 3. Robustness: It properly manages memory write permissions (ROX/RW) for the kernel text segment during patching, ensuring compatibility with CONFIG_STRICT_KERNEL_RWX. Cc: # 6.18+ Fixes: 6d4cc40fb5f5 ("LoongArch: Add kprobes support") Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 9e3f18883a98420a3b8873c6f894bc57e9b98e41 Author: Heechan Kang Date: Sun May 17 15:22:32 2026 +0900 fwctl: pds: Validate RPC input size before parsing commit e7537735028c3ad4b0bfc02ff8fa2a1a28aa04fe upstream. The fwctl core allocates the device-specific RPC input buffer with fwctl_rpc.in_len and passes that buffer to the driver callback. pdsfc_fw_rpc() casts the buffer to struct fwctl_rpc_pds and then calls pdsfc_validate_rpc(), which reads fields from that structure before checking that the input buffer is large enough to contain it. A short in_len can make pds_fwctl read beyond the allocation. Reject pds RPC buffers that are smaller than struct fwctl_rpc_pds before parsing any pds-specific fields. Fixes: 92c66ee829b9 ("pds_fwctl: add rpc and query support") Link: https://patch.msgid.link/r/20260517062232.1858747-1-gganji11@naver.com Cc: stable@vger.kernel.org # v6.15+ Signed-off-by: Heechan Kang Reviewed-by: Dave Jiang Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 1012896f4225e8f801ff3c1648023845b66dfb11 Author: Michael Bommarito Date: Wed May 13 13:53:24 2026 -0400 RDMA/siw: Reject MPA FPDU length underflow before signed receive math commit 0ce1bc9e46ecabe84772bb561e373c0d9876d6f2 upstream. A malicious connected siw peer can send an iWARP FPDU whose MPA length field (c_hdr->mpa_len, 16 bit big-endian, peer-controlled) is smaller than the fixed DDP/RDMAP header for the announced opcode. Soft-iWARP parses the full header in siw_get_hdr() based on iwarp_pktinfo[opcode] .hdr_len, but never compares mpa_len against that header length. siw_tcp_rx_data() then derives srx->fpdu_part_rem = be16_to_cpu(mpa_len) - fpdu_part_rcvd + MPA_HDR_SIZE; where fpdu_part_rcvd equals iwarp_pktinfo[opcode].hdr_len at this point. For a tagged WRITE (hdr_len 16, MPA_HDR_SIZE 2) the smallest on-wire mpa_len of 0 yields fpdu_part_rem = -14, and any mpa_len below hdr_len - MPA_HDR_SIZE underflows to a negative int. The signed value then flows into siw_proc_write()/siw_proc_rresp() as bytes = min(srx->fpdu_part_rem, srx->skb_new); is handed to siw_check_mem() as an int len (whose interval check addr + len > mem->va + mem->len is satisfied for a valid base when len is negative), and reaches siw_rx_data() -> siw_rx_kva() / siw_rx_umem() -> skb_copy_bits() as a signed copy length. The header copy branch in skb_copy_bits() promotes that to size_t, producing a multi-gigabyte read. KASAN under a KUnit harness that drives the real kernel TCP receive path -- a loopback AF_INET socketpair, the malformed FPDU written via kernel_sendmsg, sk_data_ready firing in softirq, tcp_read_sock dispatching to siw_tcp_rx_data -- reports: BUG: KASAN: use-after-free in skb_copy_bits+0x284/0x480 Read of size 4294967295 at addr ffff888... Call Trace: skb_copy_bits siw_rx_kva siw_rx_data siw_check_mem siw_proc_write siw_tcp_rx_data __tcp_read_sock siw_qp_llp_data_ready tcp_data_ready tcp_data_queue Add the missing invariant at the earliest point where the peer header is fully assembled. iwarp_pktinfo[*].hdr_len - MPA_HDR_SIZE is exactly the value the siw transmitter uses as the minimum mpa_len for each opcode (drivers/infiniband/sw/siw/siw_qp.c:33), so this matches the protocol contract. Out-of-range FPDUs terminate the connection with TERM_ERROR_LAYER_LLP / LLP_ETYPE_MPA / LLP_ECODE_FPDU_START -- which is RFC 5044 Section 8 error code 3 ("Marker and ULPDU Length fields do not agree on the start of an FPDU"), the correct framing-error class for this inconsistency. Fixes: 8b6a361b8c48 ("rdma/siw: receive path") Link: https://patch.msgid.link/r/20260513175325.2042630-2-michael.bommarito@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Assisted-by: Claude:claude-opus-4-7 Acked-by: Bernard Metzler Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit d7a076fb596c7b408ed6df74793a597990a6d860 Author: Johan Hovold Date: Tue May 12 09:48:09 2026 +0200 spi: ti-qspi: fix use-after-free after DMA setup failure commit ea6ec3343e05f7937a53eb6d7617b3abdb4abc19 upstream. The driver falls back to PIO mode if DMA setup fails during probe. Make sure to clear the DMA channel pointer also if buffer allocation fails to avoid passing a pointer to the released channel to the DMA engine (or trying to free the channel a second time on late probe errors or driver unbind). This issue was flagged by Sashiko when reviewing a devres allocation conversion patch. Fixes: c687c46e9e45 ("spi: spi-ti-qspi: Use bounce buffer if read buffer is not DMA'ble") Link: https://sashiko.dev/#/patchset/20260505072909.618363-1-johan%40kernel.org?part=17 Cc: stable@vger.kernel.org # 4.12 Cc: Vignesh R Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260512074809.915084-1-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit be409d2bbe9ca7da7b05cc7dde7499bc481f0766 Author: Johan Hovold Date: Tue May 12 09:47:33 2026 +0200 spi: sprd: fix error pointer deref after DMA setup failure commit 3d67fffb74267772d461c02c67f1eff893ad547d upstream. The driver falls back to PIO mode if DMA setup fails during probe. Make sure to check the dma.enabled flag before trying to release the DMA channels also on late probe errors to avoid dereferencing an error pointer (or attempting to release a channel a second time). This issue was flagged by Sashiko when reviewing a devres allocation conversion patch. Fixes: 386119bc7be9 ("spi: sprd: spi: sprd: Add DMA mode support") Link: https://sashiko.dev/#/patchset/20260505072909.618363-1-johan%40kernel.org?part=10 Cc: stable@vger.kernel.org # 5.1 Cc: Lanqing Liu Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260512074733.915029-1-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 8e027db9fa310b1d5e7ad928510be800c4f004d9 Author: Johan Hovold Date: Tue May 12 09:48:49 2026 +0200 spi: ep93xx: fix error pointer deref after DMA setup failure commit 5e121a81667a83e9a01d62b429e340f5a4a84abc upstream. The driver falls back to PIO mode if DMA setup fails during probe. Make sure to the clear the DMA channel pointers on setup failure to avoid dereferencing an error pointer on later probe errors or driver unbind. This issue was flagged by Sashiko when reviewing a devres allocation conversion patch. Fixes: e79e7c2df627 ("spi: ep93xx: add DT support for Cirrus EP93xx") Link: https://sashiko.dev/#/patchset/20260429091333.165363-1-johan%40kernel.org?part=10 Cc: stable@vger.kernel.org # 6.12 Cc: Nikita Shubin Signed-off-by: Johan Hovold Acked-by: Nikita Shubin Link: https://patch.msgid.link/20260512074849.915143-1-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b9ff8631006233ba246828ac70409d2cb2da38d3 Author: Michael Bommarito Date: Sun Apr 19 17:04:20 2026 -0400 scsi: isci: Fix use-after-free in device removal path commit b52a8d52c3125ec9a93106ed816582368de34426 upstream. The ISCI completion tasklet is initialized in isci_host_alloc() (drivers/scsi/isci/init.c:496) and scheduled from both MSI-X and legacy interrupt handlers (drivers/scsi/isci/host.c:223,613). isci_host_deinit() stops the controller and waits for stop completion, but it never kills completion_tasklet before teardown continues. A top-of-function tasklet_kill() is not sufficient here: interrupts are only disabled when isci_host_stop_complete() runs, so until wait_for_stop() returns the IRQ handlers can still requeue the tasklet. The tasklet callback also re-enables interrupts after draining completions, so killing the tasklet before the source is quiesced leaves the same race open. Once wait_for_stop() returns, no further IRQ-driven scheduling can occur. Kill completion_tasklet there so teardown cannot race a queued tasklet running on a dead ihost. On remove or unload, the stale callback can otherwise dereference ihost and touch ihost->smu_registers after the host lifetime ends. A UML + KASAN analogue reproduced the failure class both with no tasklet_kill() and with tasklet_kill() placed before source quiesce, and stayed clean once the kill happened after quiescing the scheduling source. This mirrors commit f6ab594672d4 ("scsi: aic94xx: fix use-after-free in device removal path"), but ISCI needs the kill after wait_for_stop(). Fixes: 6f231dda6808 ("isci: Intel(R) C600 Series Chipset Storage Control Unit Driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Assisted-by: Codex:gpt-5-4 Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260419210420.2134639-1-michael.bommarito@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 78a369a065f1fa821b50730877d88aeaf9459974 Author: Nitin Rawat Date: Wed Apr 15 16:18:51 2026 +0530 phy: qcom-qmp-ufs: Fix kaanapali PHY PLL lock failure after SM8650 G4 fix commit 80305760d7a55b884fb9023c490b75568d1ea0b1 upstream. Commit 81af9e40e2e4 ("phy: qcom: qmp-ufs: Fix SM8650 PCS table for Gear 4") moved QPHY_V6_PCS_UFS_PLL_CNTL register configuration from the shared sm8650_ufsphy_g5_pcs table to the SM8650-specific sm8650_ufsphy_pcs base table to fix Gear 4 operation on SM8650. However, this change inadvertently broke kaanapali and SM8750 SoCs which also rely on the shared sm8650_ufsphy_g5_pcs table for Gear 5 configuration but use their own sm8750_ufsphy_pcs base table. After the change, kaanapali PHYs are left without the required PLL_CNTL = 0x33 setting, causing the PHY PLL to remain at its hardware reset default value, preventing PLL lock and resulting in DME_LINKSTARTUP timeouts. Fix this by adding the missing QPHY_V6_PCS_UFS_PLL_CNTL = 0x33 entry to the sm8750_ufsphy_pcs table, mirroring what the original commit already did for sm8650_ufsphy_pcs. Cc: stable@vger.kernel.org # v6.19.12 Fixes: 81af9e40e2e4 ("phy: qcom: qmp-ufs: Fix SM8650 PCS table for Gear 4") Signed-off-by: Nitin Rawat Reviewed-by: Abel Vesa Reviewed-by: Konrad Dybcio Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260415104851.2763238-1-nitin.rawat@oss.qualcomm.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 58f4a7bd8d73d3c27d7d3e88cc0b309fede40eb0 Author: Wayne Chang Date: Mon May 4 11:33:05 2026 +0800 phy: tegra: xusb: Fix per-pad high-speed termination calibration commit da110228b54f2e2143d97ea7151e0dc22e539d67 upstream. The existing code reads a single hs_term_range_adj value from bit field [10:7] of FUSE_SKU_CALIB_0 and applies it to all USB2 pads uniformly. However, on SoCs that support per-pad termination, each pad has its own hs_term_range_adj field: pad 0 in FUSE_SKU_CALIB_0[10:7], and pads 1-3 in FUSE_USB_CALIB_EXT_0 at bit offsets [8:5], [12:9], and [16:13] respectively. Fix the calibration by reading per-pad values from the appropriate fuse registers. For SoCs that do not support per-pad termination, replicate pad 0's value to all pads to maintain existing behavior. Add a has_per_pad_term flag to the SoC data to indicate whether per-pad termination values are available in FUSE_USB_CALIB_EXT_0. Fixes: 1ef535c6ba8e ("phy: tegra: xusb: Add Tegra194 support") Cc: stable@vger.kernel.org Signed-off-by: Wayne Chang Signed-off-by: Wei-Cheng Chen Reviewed-by: Jon Hunter Tested-by: Jon Hunter Link: https://patch.msgid.link/20260504033305.2283145-1-weichengc@nvidia.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit a1f50f5aaa695417c0bc45636020e9310cc4ecc0 Author: Łukasz Lebiedziński Date: Mon Apr 6 15:56:27 2026 +0200 phy: exynos5-usbdrd: fix USB 2.0 HS PHY tuning values for Exynos7870 commit 5a759b120e31aa3ed914d98b51eb1755235250f2 upstream. The existing PHYPARAM0 tuning values for Exynos7870 are incorrect, causing the USB 2.0 PHY to fail high-speed negotiation and fall back to full-speed (12Mbps) operation. Fix TXVREFTUNE (transmitter voltage reference) from 14 to 3, TXRESTUNE (transmitter impedance) from 3 to 2, and SQRXTUNE (squelch threshold) from 6 to 5. Also explicitly set TXPREEMPPULSETUNE to 0, which was previously missing from the tuning table despite being included in the register mask. All values are derived from the vendor kernel for the Samsung Galaxy A6 (SM-A600FN), as no public hardware documentation is available for the Exynos7870 USB DRD PHY. With these corrections, the PHY successfully negotiates high-speed (480Mbps) operation. Fixes: 588d5d20ca8d ("phy: exynos5-usbdrd: add exynos7870 USBDRD support") Cc: stable@vger.kernel.org Tested-by: Kaustabh Chakraborty Reviewed-by: Krzysztof Kozlowski Signed-off-by: Łukasz Lebiedziński Link: https://patch.msgid.link/20260406135627.234835-1-kernel@lvkasz.us Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 4bb4764f2c51f03f657a28029eb0595d8223aab5 Author: Johan Hovold Date: Tue May 12 09:43:34 2026 +0200 spi: qup: fix error pointer deref after DMA setup failure commit a7e8f3efd50a165ba0189f6dc57f7e51a7d149db upstream. The driver falls back to PIO mode if DMA setup fails during probe. Make sure to the clear the DMA channel pointers on setup failure to avoid dereferencing an error pointer (or attempting to release a channel a second time) on later probe errors or driver unbind. This issue was flagged by Sashiko when reviewing a devres allocation conversion patch. Fixes: 612762e82ae6 ("spi: qup: Add DMA capabilities") Link: https://sashiko.dev/#/patchset/20260505072909.618363-1-johan%40kernel.org?part=4 Cc: stable@vger.kernel.org # 4.1 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260512074334.914735-1-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit ecdf21536c6d8ad079700fd3312225cd6b1e52bd Author: Osama Abdelkader Date: Thu Apr 30 21:49:42 2026 +0200 drm/bridge: chipone-icn6211: use devm_drm_bridge_add in i2c probe commit 73d01051e8040c0b1de7fd26b3b8d0c2ffa6895c upstream. Use devm_drm_bridge_add() so the bridge is released if probe fails after registration, and drop drm_bridge_remove() in chipone_i2c_probe. Signed-off-by: Osama Abdelkader Fixes: 8dde6f7452a1 ("drm: bridge: icn6211: Add I2C configuration support") Cc: stable@vger.kernel.org Reviewed-by: Luca Ceresoli Link: https://patch.msgid.link/20260430194944.78119-1-osama.abdelkader@gmail.com Signed-off-by: Luca Ceresoli Signed-off-by: Greg Kroah-Hartman commit bee400ad4f4259c9c0758e4f1960a1eed6f6f9f0 Author: Carlos López Date: Tue May 12 12:00:42 2026 +0200 virt: sev-guest: Explicitly leak pages in unknown state commit fd948c3f96b18ff9ba7d3e8eae13d196593e1aaf upstream. When set_memory_{encrypted,decrypted}() fail, the user cannot know at which point the function failed, meaning that the pages are left in an unknown state from the point of view of the caller. Since the pages may be left in an unencrypted state, they are not suitable for general use, and cannot be returned safely to the buddy allocator. Avoid the issue by never freeing the pages, and then do the proper accounting by calling snp_leak_pages(). Fixes: 3e385c0d6ce8 ("virt: sev-guest: Move SNP Guest Request data pages handling under snp_cmd_mutex") Signed-off-by: Carlos López Signed-off-by: Borislav Petkov (AMD) Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 4f087193b5ff0211ce5fa567db3184fb31a53f65 Author: Osama Abdelkader Date: Thu May 14 19:36:41 2026 +0200 riscv: kvm: return SBI_ERR_FAILURE for pmu_event_info() when OOM commit 0e9d0e7a7c78db7aa1c13796c65cfe0aefa54a5b upstream. kvm_riscv_vcpu_pmu_event_info() returned -ENOMEM from the SBI extension handler, which caused kvm_riscv_vcpu_sbi_ecall() to abort KVM_RUN and surface the error to userspace instead of completing the ECALL with a negative SBI error in a0. Use SBI_ERR_FAILURE and the normal retdata path, matching other PMU handlers and kvm_sbi_ext_pmu_handler comment. Fixes: e309fd113b9f ("RISC-V: KVM: Implement get event info function") Cc: stable@vger.kernel.org Signed-off-by: Osama Abdelkader Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20260514173642.41448-2-osama.abdelkader@gmail.com Signed-off-by: Anup Patel Signed-off-by: Greg Kroah-Hartman commit 77071943c752e2133dd6ea1f9933368246a49358 Author: Osama Abdelkader Date: Thu May 14 19:36:40 2026 +0200 riscv: kvm: return SBI_ERR_FAILURE for pmu_snapshot_set_shmem() when OOM commit 0835ee26938e15eccd70f7d33da386b6490f9449 upstream. kvm_riscv_vcpu_pmu_snapshot_set_shmem() returned -ENOMEM from the SBI extension handler, which caused kvm_riscv_vcpu_sbi_ecall() to abort KVM_RUN and surface the error to userspace instead of ompleting the ECALL with a negative SBI error in a0. Use SBI_ERR_FAILURE and the normal retdata path, matching other PMU handlers and kvm_sbi_ext_pmu_handler comment. Fixes: c2f41ddbcdd7 ("RISC-V: KVM: Implement SBI PMU Snapshot feature") Cc: stable@vger.kernel.org Signed-off-by: Osama Abdelkader Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20260514173642.41448-1-osama.abdelkader@gmail.com Signed-off-by: Anup Patel Signed-off-by: Greg Kroah-Hartman commit 94ade38f317ea086a181db0e6b69c574b3b70a5e Author: Tina Zhang Date: Fri May 22 12:00:14 2026 +0800 KVM: SVM: Disable AVIC IPI virtualization on Hygon Family 18h (erratum #1235) commit 9a12fa5213cfc391e0eed63902d3be98f0913765 upstream. Hygon Family 18h CPUs are derived from AMD Family 17h (Zen1) silicon and share the same erratum #1235: hardware may read a stale IsRunning=1 bit during ICR write emulation and silently fail to generate an AVIC_IPI_FAILURE_TARGET_NOT_RUNNING VM-Exit on the sending vCPU. The absence of the VM-Exit causes KVM to miss the required wakeup of blocking target vCPUs, leading to hung vCPUs and unbounded delays in guest execution. Extend the existing AMD Family 17h erratum #1235 workaround to also cover Hygon Family 18h. With IPI virtualization disabled, KVM never sets IsRunning=1 in the Physical ID table, so every non-self IPI generates a VM-Exit and is correctly emulated. Fixes: 8de4a1c8164e ("KVM: SVM: Disable (x2)AVIC IPI virtualization if CPU has erratum #1235") Cc: Signed-off-by: Tina Zhang Message-ID: <20260522040014.3380201-1-zhang_wei@open-hieco.net> Signed-off-by: Greg Kroah-Hartman commit 7023900b4988fb6f4a59d304d878003ff562e98d Author: Michael Bommarito Date: Tue May 19 09:50:42 2026 -0400 KVM: arm64: vgic: Free private_irqs when init fails after allocation commit f19c354dbd457759dfcf1195ab4bdba2bb568323 upstream. Companion to commit 250f25367b58 ("KVM: arm64: Tear down vGIC on failed vCPU creation"), which added the missing kvm_vgic_vcpu_destroy() call to the kvm_share_hyp() failure path in kvm_arch_vcpu_create(). The kvm_vgic_vcpu_init() failure path immediately above it has the same shape and still needs the same cleanup. Call kvm_vgic_vcpu_destroy() when kvm_vgic_vcpu_init() fails so private IRQs allocated before a redistributor iodev registration failure are released before the failed vCPU is freed. Fixes: 03b3d00a70b5 ("KVM: arm64: vgic: Allocate private interrupts on demand") Cc: stable@vger.kernel.org Cc: Will Deacon Reviewed-by: Yuan Yao Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Link: https://lore.kernel.org/r/20260519135042.2219239-1-michael.bommarito@gmail.com Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 0680f511926589206f81f57f76ce131d7741a316 Author: Michael Bommarito Date: Tue May 19 09:25:19 2026 -0400 KVM: arm64: vgic-its: Reject restored DTE with out-of-range num_eventid_bits commit 9ce754ed8e7ab4e3999767ce1505f85c449ccb07 upstream. Userspace can restore an ITS Device Table Entry whose Size field encodes more EventID bits than the virtual ITS supports. The live MAPD path rejects that state, but vgic_its_restore_dte() accepts it and stores the out-of-range value in dev->num_eventid_bits. Reject restored DTEs with num_eventid_bits > VITS_TYPER_IDBITS before allocating the device. This mirrors the MAPD check and prevents the restored state from reaching vgic_its_restore_itt(), where the unchecked value can be converted into an oversized scan_its_table() range. Fixes: 57a9a117154c ("KVM: arm64: vgic-its: Device table save/restore") Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Link: https://lore.kernel.org/r/20260519132519.2142458-1-michael.bommarito@gmail.com Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 240373425e2d09928af534089f5c569ae2084a7b Author: Vladimir Murzin Date: Fri May 15 14:37:29 2026 +0100 arm64: probes: Handle probes on hinted conditional branch instructions commit 2ccd8ff980b50e842481bae71102fa3883fc4377 upstream. BC.cond instructions introduced by FEAT_HBC cannot be executed out-of-line, like other branch instructions. However, they can be simulated in the same way as B.cond instructions. Extend the B.cond decoder mask to match BC.cond instructions as well, and handle them using the existing B.cond simulation path. Fixes: 7f86d128e437 ("arm64: add HWCAP for FEAT_HBC (hinted conditional branches)") Cc: Signed-off-by: Vladimir Murzin Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 798183376d9d3e278a270ea0e75a5769c8f145d9 Author: Masami Hiramatsu (Google) Date: Thu May 21 13:49:14 2026 +0900 tracing: Do not call map->ops->elt_free() if elt_alloc() fails commit 8f0f5c4fb9df0e19a341e0c6ed8dc4fda9124f03 upstream. In paths where tracing_map_elt_alloc() failed to allocate objects, the map->ops->elt_alloc() call was never successful. In this case, map->ops->elt_free() should not be called. Link: https://sashiko.dev/#/patchset/20260520223101.34710-1-rosenp%40gmail.com Cc: stable@vger.kernel.org Cc: Tom Zanussi Cc: Mathieu Desnoyers Cc: Rosen Penev Reported-by: Sashiko Fixes: 2734b629525a ("tracing: Add per-element variable support to tracing_map") Link: https://patch.msgid.link/177933895460.108746.5396070821443932634.stgit@devnote2 Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 5e7d9d0805e58fa3760894e73115b7a74024fd07 Author: Zhihao Cheng Date: Tue May 19 17:18:05 2026 +0800 cifs: Fix busy dentry used after unmounting commit c68337442f03953237a94577beb468ab2662a851 upstream. Since commit 340cea84f691c ("cifs: open files should not hold ref on superblock"), cifs file only holds the dentry ref_cnt, the cifs file close work(cfile->deferred) could be executed after unmounting, which will trigger a warning in generic_shutdown_super: BUG: Dentry 00000000a14a6845{i=c,n=file} still in use (1) [unmount of cifs cifs] The detailed processs is: process A process B kworker fd = open(PATH) vfs_open file->__f_path = *path // dentry->d_lockref.count = 1 cifs_open cifs_new_fileinfo cfile->dentry = dget(dentry) // dentry->d_lockref.count = 2 close(fd) __fput cifs_close queue_delayed_work(deferredclose_wq, cfile->deferred) dput(dentry) // dentry->d_lockref.count = 1 smb2_deferred_work_close _cifsFileInfo_put list_del(&cifs_file->flist) umount cleanup_mnt deactivate_super cifs_kill_sb cifs_close_all_deferred_files_sb cifs_close_all_deferred_files // cannot find cfile, skip _cifsFileInfo_put kill_anon_super generic_shutdown_super shrink_dcache_for_umount umount_check WARN ! // dentry->d_lockref.count = 1 cifsFileInfo_put_final dput(cifs_file->dentry) // dentry->d_lockref.count = 0 Fix it by flushing 'deferredclose_wq' before calling kill_anon_super. Fetch a reproducer in https://bugzilla.kernel.org/show_bug.cgi?id=221548. Fixes: 340cea84f691c ("cifs: open files should not hold ref on superblock") Cc: stable@vger.kernel.org Reviewed-by: Shyam Prasad N Signed-off-by: Zhihao Cheng Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 2dd9304727c7041df0a599595910bdbe02ad03c5 Author: Michael Bommarito Date: Fri May 15 11:17:18 2026 -0400 wifi: mac80211: consume only present negotiated TTLM maps commit a6e6ccd5bd07155c2add6c74ce1a5e68ad3b95ea upstream. ieee80211_tid_to_link_map_size_ok() validates negotiated TTLM elements against the number of link-map entries indicated by link_map_presence. ieee80211_parse_neg_ttlm() must consume the same layout. The parser advanced its cursor for every TID, including TIDs whose presence bit is clear and therefore have no map bytes in the element. A sparse map can then make a later present TID read past the validated element. The bad bytes land in neg_ttlm->{up,down}link[tid] but are gated by valid_links before being applied to driver state, so a peer cannot turn the read into a policy change. Under KUnit + KASAN with an exact-sized element allocation the OOB read is reported as a slab-out-of-bounds; whether the same trigger fires under the production RX path depends on surrounding allocator state. Advance the cursor only when the current TID has a map present. Fixes: 8f500fbc6c65 ("wifi: mac80211: process and save negotiated TID to Link mapping request") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260515151719.1317659-2-michael.bommarito@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit acdff9907478e82208475b1151700d0b71dcdc63 Author: Jann Horn Date: Mon May 18 18:51:30 2026 +0200 af_unix: Fix UAF read of tail->len in unix_stream_data_wait() commit be309f8eae8b474a4a617eaae01324da996fc719 upstream. unix_stream_data_wait() does skb_peek_tail(&sk->sk_receive_queue) without holding any lock that prevents SKBs on that queue from being dequeued and freed. This has been the case since commit 79f632c71bea ("unix/stream: fix peeking with an offset larger than data in queue"). The first consequence of this is that the pointer comparison `tail != last` can be false even if `last` semantically refers to an already-freed SKB while `tail` is a new SKB allocated at the same address; which can cause unix_stream_data_wait() to wrongly keep blocking after new data has arrived, but only in a weird scenario where a peeking recv() and a normal recv() on the same socket are racing, which is probably not a real problem. But since commit 2b514574f7e8 ("net: af_unix: implement splice for stream af_unix sockets"), `tail` is actually dereferenced, which can cause UAF in the following race scenario (where test_setup() runs single-threaded, and afterwards, test_thread1() and test_thread2() run concurrently in two threads: ``` static int socks[2]; void test_setup(void) { socketpair(AF_UNIX, SOCK_STREAM, 0, socks); send(socks[1], "A", 1, 0); int peekoff = 1; setsockopt(socks[0], SOL_SOCKET, SO_PEEK_OFF, &peekoff, sizeof(peekoff)); } void test_thread1(void) { char dummy; recv(socks[0], &dummy, 1, MSG_PEEK); } void test_thread2(void) { char dummy; recv(socks[0], &dummy, 1, 0); shutdown(socks[1], SHUT_WR); } ``` when racing like this: ``` thread1 thread2 unix_stream_read_generic mutex_lock(&u->iolock) skb_peek(&sk->sk_receive_queue) skb_peek_next(skb, &sk->sk_receive_queue) mutex_unlock(&u->iolock) unix_stream_read_generic unix_state_lock(sk) skb_peek(&sk->sk_receive_queue) unix_state_unlock(sk) unix_stream_data_wait unix_state_lock(sk) tail = skb_peek_tail(&sk->sk_receive_queue) spin_lock(&sk->sk_receive_queue.lock) __skb_unlink(skb, &sk->sk_receive_queue) spin_unlock(&sk->sk_receive_queue.lock) consume_skb(skb) [frees the SKB] `tail != last`: false `tail`: true `tail->len != last_len` ***UAF*** ``` Fix the UAF by removing the read of tail->len; checking tail->len would only make sense if SKBs in the receive queue of a UNIX socket could grow, which can no longer happen. Kuniyuki explained: > When commit 869e7c62486e ("net: af_unix: implement stream sendpage > support") added sendpage() support, data could be appended to the last > skb in the receiver's queue. > > That's why we needed to check if the length of the last skb was changed > while waiting for new data in unix_stream_data_wait(). > > However, commit a0dbf5f818f9 ("af_unix: Support MSG_SPLICE_PAGES") and > commit 57d44a354a43 ("unix: Convert unix_stream_sendpage() to use > MSG_SPLICE_PAGES") refactored sendmsg(), and now data is always added > to a new skb. That means this fix is not suitable for kernels before 6.5. Fixes: 2b514574f7e8 ("net: af_unix: implement splice for stream af_unix sockets") Cc: stable@vger.kernel.org # 6.5.x Signed-off-by: Jann Horn Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260518-b4-unix-recv-wait-hotfix-v2-1-83e29ce8ad31@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6cfae4914439878b8acb35c7e3b40096eeb2ad9c Author: John Walker Date: Thu May 7 17:07:20 2026 -0600 wifi: cfg80211: advance loop vars in cfg80211_merge_profile() commit 7666dbb1bacc4ba522b96740cba7283d243d16e1 upstream. cfg80211_merge_profile() reassembles a Multi-BSSID non-transmitted BSS profile that has been split across multiple consecutive MBSSID elements. Its while-loop calls cfg80211_get_profile_continuation(ie, ielen, mbssid_elem, sub_elem) but never advances mbssid_elem or sub_elem inside the body. Each iteration therefore searches for a continuation that follows the same fixed pair; the helper returns the same next_mbssid; and the same next_sub bytes are memcpy()'d into merged_ie at a growing offset until the buffer fills. Advance both mbssid_elem and sub_elem to the just-consumed continuation so the next call to cfg80211_get_profile_continuation() searches for a further continuation beyond it (or returns NULL when none exists). A specially-crafted malicious beacon can take advantage of this bug to cause the kernel to spend an excessive amount of time in cfg80211_merge_profile (up to as much as 2ms per beacon received), which could theoretically be abused in some way. Cc: stable@vger.kernel.org Fixes: fe806e4992c9 ("cfg80211: support profile split between elements") Signed-off-by: John Walker Link: https://patch.msgid.link/20260507230720.64783-1-johnwalker0@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 50884c2afd7a016ef56667c4079c2d27a261bbb3 Author: Grzegorz Nitka Date: Fri May 15 11:24:13 2026 -0700 ice: restore PTP Rx timestamp config after ethtool set-channels commit 975b564d195b13ca6ee1ef5e6a9561734898eb17 upstream. When ethtool -L changes queue counts, ice_vsi_recfg_qs() closes and rebuilds the VSI, reallocating Rx rings. The newly allocated rings have ptp_rx cleared, so RX hardware timestamps are no longer attached to skb until hwtstamp configuration is applied again. Restore timestamp mode after ice_vsi_open() in the queue reconfiguration path, matching reset/rebuild behavior and ensuring newly rebuilt Rx rings have PTP RX timestamping re-enabled. Testing hints: - run ptp4l application in client synchronization mode: ptp4l -i ethX -m -s - run PTP traffic - change queue number on ethX netdev interface: ethtool -L ethX combined new_queue_size - observe ptp4l output - expected result: no "received DELAY_REQ without timestamp" messages Fixes: 77a781155a65 ("ice: enable receive hardware timestamping") Cc: stable@vger.kernel.org Reviewed-by: Aleksandr Loktionov Signed-off-by: Grzegorz Nitka Reviewed-by: Simon Horman Tested-by: Alexander Nowlin Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260515182419.1597859-7-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0b9431b972a0d0933b5b2f31079a037fe17d01dc Author: Marcin Szycik Date: Fri May 15 11:24:10 2026 -0700 ice: fix setting promisc mode while adding VID filter commit ebc8de716c9ec2be384abdc2dd866da26c6580d1 upstream. There are at least two paths through which VSI promiscuous mode can be independently configured via ice_fltr_set_vsi_promisc(): - ice_vlan_rx_add_vid() (netdev op) - ice_service_task() -> ... -> ice_set_promisc() Both paths may try to program promiscuous mode concurrently. One such scenario is: 1. Add ice netdev to bond 2. Add the bond netdev to bridge 3. ice netdev enters allmulticast mode (IFF_ALLMULTI) 4. Service task programs promisc mode filter 5. Bridge -> bond calls ice_vlan_rx_add_vid() Crucially, ice_vlan_rx_add_vid() fails if ice_fltr_set_vsi_promisc() returns any error, including -EEXIST. This causes VLAN filtering setup to fail on the bond interface. ice_set_promisc() already handles -EEXIST correctly. Fix by adding the same -EEXIST check to ice_vlan_rx_add_vid(): if the promisc filter is already programmed, continue without returning error. Fixes: 1273f89578f2 ("ice: Fix broken IFF_ALLMULTI handling") Cc: stable@vger.kernel.org Signed-off-by: Marcin Szycik Signed-off-by: Aleksandr Loktionov Reviewed-by: Simon Horman Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260515182419.1597859-4-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9c9d00d81b41cb637dd0440e4d995861d052e5c8 Author: Jacob Keller Date: Fri May 15 11:24:08 2026 -0700 ice: fix locking around wait_event_interruptible_locked_irq commit 89bbff099bfc94888eb942d5b981592bbbe0c856 upstream. Commit 50327223a8bb ("ice: add lock to protect low latency interface") introduced a wait queue used to protect the low latency timer interface. The queue is used with the wait_event_interruptible_locked_irq macro, which unlocks the wait queue lock while sleeping. The irq variant uses spin_lock_irq and spin_unlock_irq to manage this. The wait queue lock was previously locked using spin_lock_irqsave. This difference in lock variants could lead to issues, since wait_event would unlock the wait queue and restore interrupts while sleeping. The ice_read_phy_tstamp_ll_e810() function is ultimately called through ice_read_phy_tstamp, which is called from ice_ptp_process_tx_tstamp or ice_ptp_clear_unexpected_tx_ready. The former is called through the miscellaneous IRQ thread function, while the latter is called from the service task work queue thread. Neither of these functions has interrupts disabled, so use spin_lock_irq instead of spin_lock_irqsave. Fixes: 50327223a8bb ("ice: add lock to protect low latency interface") Cc: stable@vger.kernel.org Reported-by: Jakub Kicinski Closes: https://lore.kernel.org/netdev/20250109181823.77f44c69@kernel.org/ Signed-off-by: Jacob Keller Signed-off-by: Aleksandr Loktionov Reviewed-by: Simon Horman Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260515182419.1597859-2-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f1bafd35f11b3aca1c7bb38da173b8787364a04c Author: Kohei Enju Date: Fri May 15 11:24:16 2026 -0700 igc: fix potential skb leak in igc_fpe_xmit_smd_frame() commit e935c37b8a94bb256fada6395a5d05e1c0c6bdaf upstream. When igc_fpe_init_tx_descriptor() fails, no one takes care of an allocated skb, leaking it. [1] Use dev_kfree_skb_any() on failure. Tested on an I226 adapter with the following command, while injecting faults in igc_fpe_init_tx_descriptor() to trigger the error path. # ethtool --set-mm $DEV verify-enabled on tx-enabled on pmac-enabled on [1] unreferenced object 0xffff888113c6cdc0 (size 224): ... backtrace (crc be3d3fda): kmem_cache_alloc_node_noprof+0x3b1/0x410 __alloc_skb+0xde/0x830 igc_fpe_xmit_smd_frame.isra.0+0xad/0x1b0 igc_fpe_send_mpacket+0x37/0x90 ethtool_mmsv_verify_timer+0x15e/0x300 Cc: stable@vger.kernel.org Fixes: 5422570c0010 ("igc: add support for frame preemption verification") Signed-off-by: Kohei Enju Reviewed-by: Simon Horman Reviewed-by: Faizal Rahim Tested-by: Avigail Dahan Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260515182419.1597859-10-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8864b664d0443ecb8e56690e5546fcda5fe5e81b Author: Dawei Feng Date: Wed May 13 23:13:20 2026 +0800 octeontx2-pf: fix double free in rvu_rep_rsrc_init() commit e8fb3de2a8effcaf62bec2c56b93d8bb480371d1 upstream. rvu_rep_rsrc_init() allocates queue memory before calling otx2_init_hw_resources(). When hardware resource setup fails, otx2_init_hw_resources() already unwinds the partially initialized SQ, CQ, and aura state before returning an error. The representor error path then calls otx2_free_hw_resources() again and can free the same resources a second time. Fix this by splitting the cleanup labels so that a failure from otx2_init_hw_resources() only releases queue memory. Keep the otx2_free_hw_resources() call for failures that happen after hardware resource initialization completed successfully. 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-rc3. Runtime validation was not performed because reproducing this path requires OcteonTX2 representor hardware. Fixes: 3937b7308d4f ("octeontx2-pf: Create representor netdev") Cc: stable@vger.kernel.org # v6.13+ Signed-off-by: Zilin Guan Signed-off-by: Dawei Feng Reviewed-by: Geetha sowjanya Link: https://patch.msgid.link/20260513151320.213260-1-dawei.feng@seu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 47a4cf2229be379cf88f92e32e1240337cd6273f Author: Sam Daly Date: Wed May 13 18:42:53 2026 +0200 octeontx2-af: CGX: add bounds check to cgx_speed_mbps index commit c0bf0a4f3f1f5f57aa83e1400ba4f56f0abfd542 upstream. cgx_speed_mbps has 13 elements but RESP_LINKSTAT_SPEED can yield values 0-15. If it returns a value >= 13, this causes an out-of-bounds array access. Add a bounds check and default to speed 0 if the index is out of range. Fixes: 61071a871ea6 ("octeontx2-af: Forward CGX link notifications to PFs") Cc: Sunil Goutham Cc: Linu Cherian Cc: Geetha sowjanya Cc: hariprasad Cc: Subbaraya Sundeep Cc: Andrew Lunn Cc: stable Signed-off-by: Sam Daly Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2026051352-refined-demise-e88d@gregkh Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5b906f31e977286888a9e31282589b545b249139 Author: Stephen Smalley Date: Wed May 13 14:05:06 2026 -0400 lsm: hold cred_guard_mutex for lsm_set_self_attr() commit 4a9b16541ad3faf8bccb398532bf3f8b6bbf1188 upstream. Just as proc_pid_attr_write() already does before calling the LSM hook. This only matters for SELinux and AppArmor which check whether the process is being ptraced and if so, whether to allow the transition. Cc: stable@vger.kernel.org Signed-off-by: Stephen Smalley Acked-by: Casey Schaufler Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 9dcd4f5c99b491c37be90b0bd9988db48225fb75 Author: Ilya Dryomov Date: Tue May 19 23:07:26 2026 +0200 rbd: eliminate a race in lock_dwork draining on unmap commit 9fc75b71fdd38465c76c6f6a884cdd4ae3c72d90 upstream. Given how rbd_lock_add_request() and rbd_img_exclusive_lock() are written, lock_dwork may be (re)queued more than it's actually needed: for example in case a new I/O request comes in while we are in the middle of rbd_acquire_lock() on behalf of another I/O request. This is expected and with rbd_release_lock() preemptively canceling lock_dwork is benign under normal operation. A more problematic example is maybe_kick_acquire(): if (have_requests || delayed_work_pending(&rbd_dev->lock_dwork)) { dout("%s rbd_dev %p kicking lock_dwork\n", __func__, rbd_dev); mod_delayed_work(rbd_dev->task_wq, &rbd_dev->lock_dwork, 0); } It's not unrealistic for lock_dwork to get canceled right after delayed_work_pending() returns true and for mod_delayed_work() to requeue it right there anyway. This is a classic TOCTOU race. When it comes to unmapping the image, there is an implicit assumption of no self-initiated exclusive lock activity past the point of return from rbd_dev_image_unlock() which unlocks the lock if it happens to be held. This unlock is assumed to be final and lock_dwork (as well as all other exclusive lock tasks, really) isn't expected to get queued again. However, lock_dwork is canceled only in cancel_tasks_sync() (i.e. later in the unmap sequence) and on top of that the cancellation can get in effect nullified by maybe_kick_acquire(). This may result in rbd_acquire_lock() executing after rbd_dev_device_release() and rbd_dev_image_release() run and free and/or reset a bunch of things. One of the possible failure modes then is a violated rbd_assert(rbd_image_format_valid(rbd_dev->image_format)); in rbd_dev_header_info() which is called via rbd_dev_refresh() from rbd_post_acquire_action(). Redo exclusive lock task draining to provide saner semantics and try to meet the assumptions around rbd_dev_image_unlock(). Cc: stable@vger.kernel.org Signed-off-by: Ilya Dryomov Reviewed-by: Viacheslav Dubeyko Signed-off-by: Greg Kroah-Hartman commit dfef79e09ed2f5df975c98547f97f5d7f8982a24 Author: Michael Bommarito Date: Fri May 15 11:24:14 2026 -0700 ixgbevf: fix use-after-free in VEPA multicast source pruning commit 5d49b568c188dc77199d8d2b959c91da8cc27cf1 upstream. ixgbevf_clean_rx_irq() prunes frames whose source MAC matches the VF's own address (VEPA multicast workaround) by freeing the skb and continuing to the next descriptor: dev_kfree_skb_irq(skb); continue; The skb pointer is declared outside the while loop and persists across iterations. Because the continue skips the "skb = NULL" reset at the bottom of the loop, the next iteration enters the "else if (skb)" path and calls ixgbevf_add_rx_frag() on the freed skb, dereferencing skb_shinfo(skb)->nr_frags - a use-after-free in NAPI softirq context. The sibling driver iavf already handles this correctly by nulling the pointer before continuing. Apply the same pattern here. I do not have ixgbevf hardware; the bug was found by static analysis (scan_drop_continue_loops.py + semgrep drop_continue_in_loop, multi-tool corroboration with the highest score in the scan). The UAF was confirmed under KASAN by loading a test module that reproduces the exact code pattern (alloc skb, kfree_skb, then read skb_shinfo(skb)->nr_frags): BUG: KASAN: slab-use-after-free in ixgbevf_uaf_test_init+0x100/0x1000 Read of size 8 at addr 000000006163ae78 by task insmod/30 freed 208-byte region [000000006163adc0, 000000006163ae90) QEMU emulates igb (82576) but not ixgbe (82599), and the igbvf VF driver does not include the VEPA source pruning path, so a full end-to-end reproduction with emulated hardware was not possible. Fixes: bad17234ba70 ("ixgbevf: Change receive model to use double buffered page based receives") Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Reviewed-by: Simon Horman Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260515182419.1597859-8-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7725cd3b471740fd23d25ed1da722c671fb2a5d3 Author: Michael Bommarito Date: Tue May 12 16:51:14 2026 -0400 ipv4: raw: reject IP_HDRINCL packets with ihl < 5 commit 915fab69823a14c170dbaa3b41978768e0fe62fc upstream. raw_send_hdrinc() validates that the caller-supplied IPv4 header fits within the message length: iphlen = iph->ihl * 4; err = -EINVAL; if (iphlen > length) goto error_free; if (iphlen >= sizeof(*iph)) { /* fix up saddr, tot_len, id, csum, transport_header */ } It does not, however, reject ihl < 5. For such a packet the "if (iphlen >= sizeof(*iph))" branch is skipped, leaving the crafted iphdr untouched, but the packet is still handed to __ip_local_out() and onward. Downstream consumers that read iph->ihl assume a sane value: net/ipv4/ah4.c:ah_output() in particular subtracts sizeof(struct iphdr) from top_iph->ihl * 4 and passes the (signed-int-negative, then cast to size_t) result to memcpy(), producing an OOB access of length close to SIZE_MAX and a host kernel panic. An IPv4 header with ihl < 5 is malformed by definition (RFC 791: "Internet Header Length is the length of the internet header in 32 bit words ... Note that the minimum value for a correct header is 5."). The kernel should not be willing to inject such a packet into its own output path. Reject "iphlen < sizeof(*iph)" alongside the existing "iphlen > length" check. This matches the principle that locally constructed packets that re-enter the IP stack must pass the same basic sanity tests that a foreign packet would be subjected to. Once this lands, the "if (iphlen >= sizeof(*iph))" wrapper around the fixup branch becomes redundant; left in place to keep the patch minimal and backport-friendly. A follow-up can unwrap it. Note that commit 86f4c90a1c5c ("ipv4, ipv6: ensure raw socket message is big enough to hold an IP header") ensures the message buffer is large enough to hold an iphdr, but does not constrain the self-reported iph->ihl. Reachability: the malformed packet source is any caller with CAP_NET_RAW, including an unprivileged process in a user+net namespace on a kernel with CONFIG_USER_NS=y. The reproduced AH crash also requires a matching xfrm AH policy on the outgoing route; a container granted CAP_NET_ADMIN can install that state and policy in its netns. Loopback bypasses xfrm_output, so the trigger uses a real netdev. Reproduced on UML + KASAN: kernel-mode fault at addr 0x0 with memcpy_orig at the crash site. Same shape reproduces inside a rootless Docker container with --cap-add NET_ADMIN on a stock distro kernel. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Suggested-by: Herbert Xu Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/77ec2b5e8111961c2c39883c92e8aa2709039c17.1778614451.git.michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit dc31c69476520bb4c2a208211a8d3c310a62c4d0 Author: Sheroz Juraev Date: Sun Mar 15 13:12:21 2026 +0500 wifi: iwlwifi: mld: stop TX during firmware restart commit 2becb38a3e217ef2b2f42fddd7db7a25905ec291 upstream. When iwlwifi firmware crashes (e.g., NMI_INTERRUPT_UNKNOWN on Intel BE201/Wi-Fi 7), iwl_mld_nic_error() sets mld->fw_status.in_hw_restart to true. However, iwl_mld_tx_from_txq() does not check this flag before dequeuing frames from mac80211 and pushing them to the transport layer. Since the firmware is dead, iwl_trans_tx() returns -EIO for each frame, which then gets freed immediately. Under high-throughput conditions (e.g., Tailscale UDP traffic or active SSH sessions), this creates a tight dequeue-send-fail-free loop that wastes CPU cycles and generates rapid skb allocation churn, leading to memory pressure from slab fragmentation. The RX path already has this guard (iwl_mld_rx_mpdu checks in_hw_restart at rx.c:1906), and so does the TXQ allocation worker (iwl_mld_add_txqs_wk at tx.c:156). Add the same guard to iwl_mld_tx_from_txq() to stop all TX during firmware restart. Frames left in mac80211's TXQs are naturally drained after restart completes, when queue reallocation triggers iwl_mld_tx_from_txq() via iwl_mld_add_txq_list(), or when new upper-layer traffic invokes wake_tx_queue. Tested on ASUS Zenbook 14 UX3405CA with Intel BE201 (Wi-Fi 7) on kernel 6.19.5 where the firmware crashes approximately every 10-15 minutes under Tailscale traffic. Fixes: d1e879ec600f ("wifi: iwlwifi: add iwlmld sub-driver") Cc: stable@vger.kernel.org Signed-off-by: Sheroz Juraev Link: https://patch.msgid.link/20260315081221.2678478-1-goodmartiandev@gmail.com Signed-off-by: Miri Korenblit Signed-off-by: Greg Kroah-Hartman commit 6fe92651b44fd3cfc8dcfdaad0e82885c384dada Author: Johannes Berg Date: Fri May 15 15:14:57 2026 +0300 wifi: iwlwifi: mvm: fix driver-set TX rates on old devices commit fb84b5cbcaab3ca0f4e961d92a40ed7f3aac483b upstream. On old devices such as 7265D, rates are still encoded in version 1 format, which doesn't use the CCK/OFDM rate index (0-3/0-7) but rather their PLCP value (e.g. 10 for 1 Mbps CCK rate.) While introducing v3 rates, I changed the driver from internally handling v1 rates and converting to v2, to internally handling v3 and converting to v1 or v2 according to the firmware. I accordingly changed the code in iwl_mvm_mac80211_idx_to_hwrate() to no longer have different values for different APIs. This was correct. However, I later reverted this part of the change, because it was reported that I had broken beacon rates, causing a FW assert/crash. This caused TX_CMD rates to be set incorrectly, potentially causing a warning when reported back from the device as having been used. Fix this (hopefully correctly now) by handling beacon rates in the TX_CMD that's embedded in the beacon template command separately. Restore iwl_mvm_mac80211_idx_to_hwrate() to return only the rate index, not PLCP value, fixing the real TX_CMD. Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg Link: https://patch.msgid.link/20260515151351.7407e293dff7.I4ea1a17f8fe99c933d3f3e30d077cf4246125c3e@changeid Signed-off-by: Miri Korenblit Signed-off-by: Greg Kroah-Hartman commit 614cacec60fe92d50abe532f011a7549a1c94169 Author: Kyle Farnung Date: Wed May 13 21:52:12 2026 -0700 wifi: ath11k: clear shared SRNG pointer state on restart commit f51e4b3b5574ad8cb5b16b11f8a1452147ece87a upstream. LMAC rings reuse the shared rdp/wrp pointer buffers without going through the normal SRNG hw-init path that zeros non-LMAC ring pointers. After restart, ath11k_hal_srng_clear() can therefore hand stale hp/tp state from the previous firmware instance back to the new one. Clear the shared pointer buffers while keeping the allocations in place so restart still avoids reallocating SRNG DMA memory, but starts with fresh ring-pointer state. Fixes: 32be3ca4cf78b ("wifi: ath11k: HAL SRNG: don't deinitialize and re-initialize again") Cc: stable@vger.kernel.org Closes: https://lore.kernel.org/all/CAOPSVF04q6uvVdq8GTRLHBrVMdpt9=o9wVcFMc6f-yhmSBcZqQ@mail.gmail.com/ Signed-off-by: Kyle Farnung Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260513-kfarnung-ath11k-srng-clear-pointer-state-v1-1-bc700dd8b333@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Greg Kroah-Hartman commit a3529032afe2253117dcda3920af7cb2b40ed272 Author: Jose Ignacio Tornos Martinez Date: Fri May 15 11:24:09 2026 -0700 ice: fix VF queue configuration with low MTU values commit 3ba4dd024d26372733d1c02e13e076c6016e3320 upstream. The ice driver's VF queue configuration validation rejects databuffer_size values below 1024 bytes, which prevents VFs from using MTU values below 871 bytes. The iavf driver calculates databuffer_size based on the MTU using: databuffer_size = ALIGN(MTU + LIBETH_RX_LL_LEN, 128) where LIBETH_RX_LL_LEN = 26 (ETH_HLEN + 2*VLAN_HLEN + ETH_FCS_LEN). For MTU values below 871: MTU 870: 870 + 26 = 896, aligned to 128 = 896 (< 1024, rejected) MTU 871: 871 + 26 = 897, aligned to 128 = 1024 (>= 1024, accepted) The 1024-byte minimum seems unnecessarily restrictive, because the hardware supports databuffer_size as low as 128 bytes (the alignment boundary), which should allow MTU values down to the standard minimum of 68 bytes. I haven't found the reason why the limit was configured in the commit 9c7dd7566d18 ("ice: add validation in OP_CONFIG_VSI_QUEUES VF message"), so with no more information and since it is working, change the minimum databuffer_size validation from 1024 to 128 bytes to allow standard low MTU values while still preventing invalid configurations. Fixes: 9c7dd7566d18 ("ice: add validation in OP_CONFIG_VSI_QUEUES VF message") cc: stable@vger.kernel.org Signed-off-by: Jose Ignacio Tornos Martinez Reviewed-by: Jacob Keller Reviewed-by: Michal Swiatkowski Reviewed-by: Paul Menzel Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260515182419.1597859-3-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c618cf8926c0574c32649c56331f6ecee674928e Author: Stefano Garzarella Date: Mon May 18 11:06:55 2026 +0200 vsock/virtio: reset connection on receiving queue overflow commit a4f0b001782b21663d10df983b4b208195bec66c upstream. When there is no more space to queue an incoming packet, the packet is silently dropped. This causes data loss without any notification to either peer, since there is no retransmission. Under normal circumstances, this should never happen. However, it could happen if the other peer doesn't respect the credit, or if the skb overhead, which we recently began to take into account with commit 059b7dbd20a6 ("vsock/virtio: fix potential unbounded skb queue"), is too high. Fix this by resetting the connection and setting the local socket error to ENOBUFS when virtio_transport_recv_enqueue() can no longer queue a packet, so both peers are explicitly notified of the failure rather than silently losing data. Fixes: ae6fcfbf5f03 ("vsock/virtio: discard packets if credit is not respected") Cc: stable@vger.kernel.org Signed-off-by: Stefano Garzarella Link: https://patch.msgid.link/20260518090656.134588-2-sgarzare@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 440447699c681e26ed58e9c309cad718270a18b4 Author: Minh Nguyen Date: Tue May 19 17:23:10 2026 +0700 vsock/vmci: fix UAF when peer resets connection during handshake commit 99e22ddf4edb63dc8382bc028af928056d3450cf upstream. vmci_transport_recv_connecting_server() returned err = 0 for a peer RST in its default switch arm: err = pkt->type == VMCI_TRANSPORT_PACKET_TYPE_RST ? 0 : -EINVAL; That made vmci_transport_recv_listen() skip vsock_remove_pending(), leaving the pending socket on the listener's pending_links with sk_state = TCP_CLOSE while destroy: still dropped the explicit reference taken before schedule_delayed_work(). One second later vsock_pending_work() observed is_pending=true and performed full cleanup: vsock_remove_pending() then the two trailing sock_put(sk) calls -- the first reached refcount 0 and __sk_freed the socket, and the second wrote into the freed object: BUG: KASAN: slab-use-after-free in refcount_warn_saturate Write of size 4 at addr ffff88800b1cac80 by task kworker Workqueue: events vsock_pending_work Treat peer RST like any other unexpected packet type (err = -EINVAL). All destroy: arms now return err < 0, so vmci_transport_recv_listen() removes pending from pending_links synchronously and vsock_pending_work() takes the is_pending=false / !rejected branch, dropping only its own work reference. This also closes the multi-packet race Sashiko reported on v2: pending is removed from the list before any subsequent packet can find it. The pre-existing sk_acceptq_removed() gap on the err < 0 path of vmci_transport_recv_listen() that Sashiko also noted is not introduced or changed by this patch. Tested on lts-6.12.79 with KASAN: 52/100 unpatched -> 0/100 patched. Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Cc: stable@vger.kernel.org Signed-off-by: Minh Nguyen Acked-by: Bryan Tan Link: https://patch.msgid.link/20260519102310.237181-1-minhnguyen.080505@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 29b6433510127e19f67378f92af6c0cb2ec1c4d4 Author: Li Xiasong Date: Fri May 15 06:27:33 2026 +0200 mptcp: pm: fix ADD_ADDR timer infinite retry on option space insufficient commit 51e398a3b8961b26a8c0a4ba9a777c5339791707 upstream. When TCP option space is insufficient (e.g., when sending ADD_ADDR with an IPv6 address and port while tcp_timestamps is enabled), the original code jumped to out_unlock without clearing the addr_signal flag. This caused mptcp_pm_add_timer to keep rescheduling indefinitely, not sending ADD_ADDR, preventing subsequent addresses in the endpoint list from being announced. Handle this case by clearing the ADD_ADDR signal and skipping the matching ADD_ADDR retransmission entry. The skip path cancels the matching timer (with id check) and advances PM state progression, preserving forward progress to subsequent PM work. This cancellation is inherently best-effort. A concurrent add_timer callback may already be running and may acquire pm.lock before the cancel path updates entry state. In that case, one final ADD_ADDR transmit attempt can still be executed. Once the cancel path sets entry->retrans_times to ADD_ADDR_RETRANS_MAX, the callback-side retrans_times check suppresses further ADD_ADDR retransmissions. Note that when an ADD_ADDR is being prepared, a pure-ACK is queued. On the output side, it means that it is fine to skip non-pure-ACK packets, when drop_other_suboptions is set: a pure-ACK will be processed soon after. Fixes: 00cfd77b9063 ("mptcp: retransmit ADD_ADDR when timeout") Cc: stable@vger.kernel.org Signed-off-by: Li Xiasong Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260515-net-mptcp-misc-fixes-7-1-rc4-v2-2-701e96419f2f@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit abdd03229414b5a52943b65a60f34b84cea5ac59 Author: Justin Iurman Date: Sun May 17 20:30:59 2026 +0200 ipv6: ioam: add NULL check for idev in ipv6_hop_ioam() commit d4ea0dfd75011b78cebf3808f98ac4c4f51a6fb9 upstream. Reported by Sashiko: The function ipv6_hop_ioam() accesses __in6_dev_get(skb->dev)->cnf.ioam6_enabled without validating the returned idev pointer. Because addrconf_ifdown() can concurrently clear dev->ip6_ptr via RCU, __in6_dev_get() can return NULL during interface teardown, which could cause a NULL pointer dereference when processing an IOAM Hop-by-Hop option. Let's add a check and use SKB_DROP_REASON_IPV6DISABLED accordingly. Fixes: 9ee11f0fff20 ("ipv6: ioam: Data plane support for Pre-allocated Trace") Cc: stable@vger.kernel.org Signed-off-by: Justin Iurman Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260517183059.29140-1-justin.iurman@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2bc60c175568ecf0e8b7803dcbf54bd61f3cf76e Author: Masami Hiramatsu (Google) Date: Thu Apr 30 12:28:16 2026 +0900 ring-buffer: Flush and stop persistent ring buffer on panic commit a494d3c8d5392bcdff83c2a593df0c160ff9f322 upstream. On real hardware, panic and machine reboot may not flush hardware cache to memory. This means the persistent ring buffer, which relies on a coherent state of memory, may not have its events written to the buffer and they may be lost. Moreover, there may be inconsistency with the counters which are used for validation of the integrity of the persistent ring buffer which may cause all data to be discarded. To avoid this issue, stop recording of the ring buffer on panic and flush the cache of the ring buffer's memory. Fixes: e645535a954a ("tracing: Add option to use memmapped memory for trace boot instance") Cc: stable@vger.kernel.org Cc: Will Deacon Cc: Mathieu Desnoyers Cc: Ian Rogers Link: https://patch.msgid.link/177751969602.2136606.12031934362587643488.stgit@mhiramat.tok.corp.google.com Signed-off-by: Masami Hiramatsu (Google) Acked-by: Catalin Marinas Acked-by: Geert Uytterhoeven Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 610ff6bc2f44b8beb70ab7913e1da305a1ebfa13 Author: Steven Rostedt Date: Wed May 20 22:08:01 2026 -0400 ring-buffer: Fix reporting of missed events in iterator commit a254b6d13b0edd6272926674d2afc46d46e496b7 upstream. When tracing is active while reading the trace file, if the iterator reading the buffer detects that the writer has passed the iterator head, it will reset and set a "missed events" flag. This flag is passed to the output processing to show the user that events were missed: CPU:4 [LOST EVENTS] The problem is that the flag is reset after it is checked in ring_buffer_iter_dropped(). But the "trace" file iterates over all the CPU ring buffers and it will check if they are dropped when figuring out which buffer to print next. This prematurely clears the missed_events flag if the CPU buffer with the missed events is not the one that is printed next. On the iteration where the CPU buffer with the missed events is printed, the check if it had missed events would return false and the output does not show that events were missed. Do not reset the missed_events flag when checking if there were missed events, but instead clear it when moving the iterator head to the next event. Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Link: https://patch.msgid.link/20260520220801.4fd09d13@fedora Fixes: c9b7a4a72ff64 ("ring-buffer/tracing: Have iterator acknowledge dropped events") Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 0e47fc1c9181ae029e0e35a865cbf2adcbae626c Author: Dawei Feng Date: Wed May 20 15:03:23 2026 +0800 qed: fix double free in qed_cxt_tables_alloc() commit 2bccfb8476ca5f3548afbd623dc7a6980d4e77de upstream. If one of the later PF or VF CID bitmap allocations fails, qed_cid_map_alloc() jumps to cid_map_fail and frees the previously allocated CID bitmaps before returning an error. qed_cxt_tables_alloc() then calls qed_cxt_mngr_free(), which invokes qed_cid_map_free() again. Fix this by setting each CID bitmap pointer to NULL after bitmap_free() to avoid double free. 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-rc3. Runtime reproduction was not attempted because exercising the failing allocation path requires device-specific setup. Fixes: fe56b9e6a8d9 ("qed: Add module with basic common support") Cc: stable@vger.kernel.org Signed-off-by: Zilin Guan Signed-off-by: Dawei Feng Link: https://patch.msgid.link/20260520070323.2762379-1-dawei.feng@seu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e0c3dd7b30cc5ee42ab502da140cda93d794a20b Author: Michael Bommarito Date: Mon May 18 14:34:47 2026 -0400 l2tp: use list_del_rcu in l2tp_session_unhash commit 979c017803c40829b03acd9e5236e354b7622360 upstream. An unprivileged local user can pin a host CPU indefinitely in l2tp_session_get_by_ifname() by issuing L2TP_CMD_SESSION_GET on L2TP_ATTR_IFNAME concurrently with L2TP_CMD_SESSION_CREATE and L2TP_CMD_SESSION_DELETE on the same tunnel. All three commands take GENL_UNS_ADMIN_PERM, so CAP_NET_ADMIN in the netns user namespace suffices; on any host that has l2tp_core loaded the trigger is reachable from a standard `unshare -Urn` sandbox. l2tp_session_unhash() removes a session from tunnel->session_list with list_del_init(), but that list is walked by l2tp_session_get_by_ifname() with list_for_each_entry_rcu() under rcu_read_lock_bh(). list_del_init() leaves the deleted entry's next/prev self-pointing; a reader that has loaded the entry and then advances pos->list.next reads &session->list, container_of()s back to the same session, and list_for_each_entry_rcu() never reaches the list head. The CPU stays in strcmp() inside the walker, with BH and preemption disabled, so RCU grace periods on the host stall behind it and the wedged thread cannot be killed (SIGKILL is delivered on syscall return). Use list_del_rcu() to match the existing list_add_rcu() in l2tp_session_register(); the deleted session remains visible to in-flight walkers with consistent next/prev pointers until kfree_rcu() in l2tp_session_free() releases it. tunnel->session_list has exactly one list_del_init() call site; the list_del_init (&session->clist) at l2tp_core.c:533 operates on the per-collision list, which is not walked under RCU. list_empty(&session->list) is not used anywhere in net/l2tp/ after the unhash point, so dropping the post-delete self-init is safe; the fix has no userspace-visible behavior change. Fixes: 89b768ec2dfef ("l2tp: use rcu list add/del when updating lists") Cc: stable@vger.kernel.org # 6.11+ Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260518183447.64078-1-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d73dcd1520d65a34420761641a36b951b14c8c53 Author: Konstantin Komarov Date: Thu May 28 11:20:28 2026 +0800 fs/ntfs3: handle attr_set_size() errors when truncating files [ Upstream commit 576248a34b927e93b2fd3fff7df735ba73ad7d01 ] If attr_set_size() fails while truncating down, the error is silently ignored and the inode may be left in an inconsistent state. Signed-off-by: Konstantin Komarov [ Minor context conflict resolved. ] Signed-off-by: Bin Lan Signed-off-by: Greg Kroah-Hartman commit 3586924625559e6f9876d726c80ff0a75f0d5849 Author: David Carlier Date: Fri May 22 09:03:00 2026 -0400 net: ethtool: phy: avoid NULL deref when PHY driver is unbound [ Upstream commit e3adf69f8eb121a9128c2b0029efd050d3649153 ] phydev->drv can become NULL while the phy_device is still attached to its net_device, namely after the PHY driver is unbound via sysfs: echo > /sys/bus/mdio_bus/drivers//unbind phy_remove() clears phydev->drv but doesn't call phy_detach(), so the phy_device stays in the link topology xarray and ethnl_req_get_phydev() still hands it back. ETHTOOL_MSG_PHY_GET then oopses on: rep_data->drvname = kstrdup(phydev->drv->name, GFP_KERNEL); drvname is already treated as optional by phy_reply_size(), phy_fill_reply() and phy_cleanup_data(), so just skip the allocation when there is no driver bound. Fixes: 9dd2ad5e92b9 ("net: ethtool: phy: Convert the PHY_GET command to generic phy dump") Cc: stable@vger.kernel.org # 6.13.x Signed-off-by: David Carlier Reviewed-by: Maxime Chevallier Tested-by: Maxime Chevallier Link: https://patch.msgid.link/20260509215046.107157-1-devnexen@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 61f53c1e58d68723bc1db10912a53f1991f08719 Author: Quan Sun <2022090917019@std.uestc.edu.cn> Date: Fri May 22 09:02:59 2026 -0400 net: ethtool: fix NULL pointer dereference in phy_reply_size [ Upstream commit 4908f1395fb1b832ceec11584af649874a2732ea ] In phy_prepare_data(), several strings such as 'name', 'drvname', 'upstream_sfp_name', and 'downstream_sfp_name' are allocated using kstrdup(). However, these allocations were not checked for failure. If kstrdup() fails for 'name', it returns NULL while the function continues. This leads to a kernel NULL pointer dereference and panic later in phy_reply_size() when it unconditionally calls strlen() on the NULL pointer. While other strings like 'upstream_sfp_name' might be checked before access in certain code paths, failing to handle these allocations consistently can lead to incomplete data reporting or hidden bugs. Fix this by adding proper NULL checks for all kstrdup() calls in phy_prepare_data() and implement a centralized error handling path using goto labels to ensure all previously allocated resources are freed on failure. Fixes: 9dd2ad5e92b9 ("net: ethtool: phy: Convert the PHY_GET command to generic phy dump") Signed-off-by: Quan Sun <2022090917019@std.uestc.edu.cn> Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260507131738.1173835-1-2022090917019@std.uestc.edu.cn Signed-off-by: Jakub Kicinski Stable-dep-of: e3adf69f8eb1 ("net: ethtool: phy: avoid NULL deref when PHY driver is unbound") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 752ea4a105e6f42cabbb70e335baab3b5b2ddafd Author: Guopeng Zhang Date: Fri May 22 08:54:20 2026 -0400 cgroup/cpuset: Reset DL migration state on can_attach() failure [ Upstream commit 4a39eda5fdd867fc39f3c039714dd432cee00268 ] cpuset_can_attach() accumulates temporary SCHED_DEADLINE migration state in the destination cpuset while walking the taskset. If a later task_can_attach() or security_task_setscheduler() check fails, cgroup_migrate_execute() treats cpuset as the failing subsystem and does not call cpuset_cancel_attach() for it. The partially accumulated state is then left behind and can be consumed by a later attach, corrupting cpuset DL task accounting and pending DL bandwidth accounting. Reset the pending DL migration state from the common error exit when ret is non-zero. Successful can_attach() keeps the state for cpuset_attach() or cpuset_cancel_attach(). Fixes: 2ef269ef1ac0 ("cgroup/cpuset: Free DL BW in case can_attach() fails") Cc: stable@vger.kernel.org # v6.10+ Signed-off-by: Guopeng Zhang Signed-off-by: Tejun Heo Reviewed-by: Chen Ridong Reviewed-by: Waiman Long [ omitted upstream context line `cs->dl_bw_cpu = cpu;` ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1aed73795392d64193a4d8f30bbe355bca7d92fd Author: Masami Hiramatsu (Google) Date: Thu May 21 08:58:13 2026 -0400 tracing/fprobe: Check the same type fprobe on table as the unregistered one [ Upstream commit 0ac0058a74ac5765c7ce09ea630f4fdeaf4d80fa ] Commit 2c67dc457bc6 ("tracing: fprobe: optimization for entry only case") introduced a different ftrace_ops for entry-only fprobes. However, when unregistering an fprobe, the kernel only checks if another fprobe exists at the same address, without checking which type of fprobe it is. If different fprobes are registered at the same address, the same address will be registered in both fgraph_ops and ftrace_ops, but only one of them will be deleted when unregistering. (the one removed first will not be deleted from the ops). This results in junk entries remaining in either fgraph_ops or ftrace_ops. For example: ======= cd /sys/kernel/tracing # 'Add entry and exit events on the same place' echo 'f:event1 vfs_read' >> dynamic_events echo 'f:event2 vfs_read%return' >> dynamic_events # 'Enable both of them' echo 1 > events/fprobes/enable cat enabled_functions vfs_read (2) ->arch_ftrace_ops_list_func+0x0/0x210 # 'Disable and remove exit event' echo 0 > events/fprobes/event2/enable echo -:event2 >> dynamic_events # 'Disable and remove all events' echo 0 > events/fprobes/enable echo > dynamic_events # 'Add another event' echo 'f:event3 vfs_open%return' > dynamic_events cat dynamic_events f:fprobes/event3 vfs_open%return echo 1 > events/fprobes/enable cat enabled_functions vfs_open (1) tramp: 0xffffffffa0001000 (ftrace_graph_func+0x0/0x60) ->ftrace_graph_func+0x0/0x60 subops: {ent:fprobe_fgraph_entry+0x0/0x620 ret:fprobe_return+0x0/0x150} vfs_read (1) tramp: 0xffffffffa0001000 (ftrace_graph_func+0x0/0x60) ->ftrace_graph_func+0x0/0x60 subops: {ent:fprobe_fgraph_entry+0x0/0x620 ret:fprobe_return+0x0/0x150} ======= As you can see, an entry for the vfs_read remains. To fix this issue, when unregistering, the kernel should also check if there is the same type of fprobes still exist at the same address, and if not, delete its entry from either fgraph_ops or ftrace_ops. Link: https://lore.kernel.org/all/177669367993.132053.10553046138528674802.stgit@mhiramat.tok.corp.google.com/ Fixes: 2c67dc457bc6 ("tracing: fprobe: optimization for entry only case") Cc: stable@vger.kernel.org Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f0ad68d2f0adbeae50140c944d5676a58bf92aa6 Author: Masami Hiramatsu (Google) Date: Thu May 21 08:58:12 2026 -0400 tracing/fprobe: Avoid kcalloc() in rcu_read_lock section [ Upstream commit aa72812b49104bb5a38272fc9541feb62ca6fd32 ] fprobe_remove_node_in_module() is called under RCU read locked, but this invokes kcalloc() if there are more than 8 fprobes installed on the module. Sashiko warns it because kcalloc() can sleep [1]. [1] https://sashiko.dev/#/patchset/177552432201.853249.5125045538812833325.stgit%40mhiramat.tok.corp.google.com To fix this issue, expand the batch size to 128 and do not expand the fprobe_addr_list, but just cancel walking on fprobe_ip_table, update fgraph/ftrace_ops and retry the loop again. Link: https://lore.kernel.org/all/177669367206.132053.1493637946869032744.stgit@mhiramat.tok.corp.google.com/ Fixes: 0de4c70d04a4 ("tracing: fprobe: use rhltable for fprobe_ip_table") Cc: stable@vger.kernel.org Signed-off-by: Masami Hiramatsu (Google) Stable-dep-of: 0ac0058a74ac ("tracing/fprobe: Check the same type fprobe on table as the unregistered one") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bb92f356d2b73bc65ea20919a0e39efdf538f5cd Author: Menglong Dong Date: Thu May 21 08:58:11 2026 -0400 tracing: fprobe: use ftrace if CONFIG_DYNAMIC_FTRACE_WITH_ARGS [ Upstream commit cd06078a38aaedfebbf8fa0c009da0f99f4473fb ] For now, we will use ftrace for the fprobe if fp->exit_handler not exists and CONFIG_DYNAMIC_FTRACE_WITH_REGS is enabled. However, CONFIG_DYNAMIC_FTRACE_WITH_REGS is not supported by some arch, such as arm. What we need in the fprobe is the function arguments, so we can use ftrace for fprobe if CONFIG_DYNAMIC_FTRACE_WITH_ARGS is enabled. Therefore, use ftrace if CONFIG_DYNAMIC_FTRACE_WITH_REGS or CONFIG_DYNAMIC_FTRACE_WITH_ARGS enabled. Link: https://lore.kernel.org/all/20251103063434.47388-1-dongml2@chinatelecom.cn/ Signed-off-by: Menglong Dong Signed-off-by: Masami Hiramatsu (Google) Stable-dep-of: 0ac0058a74ac ("tracing/fprobe: Check the same type fprobe on table as the unregistered one") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 52cc572c95655ad71cdde4e494abf770efe9e233 Author: Masami Hiramatsu (Google) Date: Thu May 21 08:58:10 2026 -0400 tracing: fprobe: Remove unused local variable [ Upstream commit 90e69d291d195d35215b578d210fd3ce0e5a3f42 ] The 'ret' local variable in fprobe_remove_node_in_module() was used for checking the error state in the loop, but commit dfe0d675df82 ("tracing: fprobe: use rhltable for fprobe_ip_table") removed the loop. So we don't need it anymore. Link: https://lore.kernel.org/all/175867358989.600222.6175459620045800878.stgit@devnote2/ Fixes: e5a4cc28a052 ("tracing: fprobe: use rhltable for fprobe_ip_table") Signed-off-by: Masami Hiramatsu (Google) Acked-by: Menglong Dong Stable-dep-of: 0ac0058a74ac ("tracing/fprobe: Check the same type fprobe on table as the unregistered one") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 45c7c4e3db8b700307313c035ea08be829a7f21b Author: Tejun Heo Date: Thu May 21 09:53:58 2026 -0400 sched_ext: Avoid UAF in scx_root_enable_workfn() init failure path [ Upstream commit 9a415cc53711f2238e0f0ca8a6bcc796c003b127 ] In scx_root_enable_workfn(), put_task_struct(p) is called before scx_error() dereferences p->comm and p->pid. If the iterator's reference is the last drop, the task is freed synchronously and the deref becomes a UAF. Move put_task_struct() past scx_error(). Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260511214031.AF5E9C2BCB0@smtp.kernel.org/ Fixes: f0e1a0643a59 ("sched_ext: Implement BPF extensible scheduler class") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Tejun Heo [ kept `scx_init_task()` call site instead of `__scx_init_task()`/`task_rq_lock` ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6e73ec10b2a32b1126423a71f2c4247041048d81 Author: Samuele Mariotti Date: Thu May 21 09:53:57 2026 -0400 sched_ext: Fix missing warning in scx_set_task_state() default case [ Upstream commit b905ee77d5f557a83a485b4146210f54f13365fc ] In scx_set_task_state(), the default case was setting the warn flag, but then returning immediately. This is problematic because the only purpose of the warn flag is to trigger WARN_ONCE, but the early return prevented it from ever firing, leaving invalid task states undetected and untraced. To fix this, a WARN_ONCE call is now added directly in the default case. The fix addresses two aspects: - Guarantees the invalid task states are properly logged and traced. - Provides a distinct warning message ("sched_ext: Invalid task state") specifically for states outside the defined scx_task_state enum values, making it easier to distinguish from other transition warnings. This ensures proper detection and reporting of invalid states. Signed-off-by: Samuele Mariotti Signed-off-by: Paolo Valente Reviewed-by: Andrea Righi Signed-off-by: Tejun Heo Stable-dep-of: 9a415cc53711 ("sched_ext: Avoid UAF in scx_root_enable_workfn() init failure path") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 689bbf48c1f45130086ae1c46ab83ea4c753c601 Author: Yizhou Zhao Date: Tue May 12 01:30:41 2026 +0800 netfilter: nft_inner: Fix IPv6 inner_thoff desync commit b6a91f68ebfed9c38e0e9150f58a9b85da07181c upstream. In nft_inner_parse_l2l3(), when processing inner IPv6 packets, ipv6_find_hdr() correctly computes the transport header offset traversing all extension headers, but the result is immediately overwritten with nhoff + sizeof(_ip6h) (40 bytes), which only accounts for the IPv6 base header. This creates a desync between inner_thoff (wrong — points to extension header start) and l4proto (correct — e.g., IPPROTO_TCP), enabling transport header forgery and potential firewall bypass. This issue affects stable versions from Linux 6.2. For comparison, the normal (non-inner) IPv6 path correctly preserves ipv6_find_hdr()'s result. Removing the incorrect overwrite ensures that ipv6_find_hdr()'s calculated transport header offset is preserved, thereby fixing the desynchronization. Fixes: 3a07327d10a0 ("netfilter: nft_inner: support for inner tunnel header matching") Cc: stable@vger.kernel.org Reported-by: Yizhou Zhao Reported-by: Yuxiang Yang Reported-by: Xuewei Feng Reported-by: Qi Li Reported-by: Ke Xu Assisted-by: GLM:5.1 Z.ai Signed-off-by: Yizhou Zhao Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 952e988163c2ab9939c3db9f0f8e77af6a1bb436 Author: Nan Li Date: Tue May 12 16:50:01 2026 +0800 netfilter: ipset: stop hash:* range iteration at end commit 0d3a282ab5f165fc207ff49ea5b6ad8f54616bd6 upstream. The following hash set variants: hash:ip,mark hash:ip,port hash:ip,port,ip hash:ip,port,net iterate IPv4 ranges with a 32-bit iterator. The iterator must stop once the last address in the requested range has been processed. Advancing it once more can move the traversal state past the end of the request, so a later retry may continue from an unintended position. Handle the iterator increment explicitly at the end of the loop and stop once the upper bound has been processed. This keeps the existing retry behaviour intact for valid ranges while preventing traversal from continuing past the original boundary. Fixes: 48596a8ddc46 ("netfilter: ipset: Fix adding an IPv4 range containing more than 2^31 addresses") 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: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 15d464265120ab9818bd673af301deee09bedab2 Author: Haoze Xie Date: Fri May 15 11:19:02 2026 +0800 netfilter: nf_queue: hold bridge skb->dev while queued commit e196115ec330a18de415bdb9f5071aa9f08e53ce upstream. br_pass_frame_up() rewrites skb->dev from the ingress port to the bridge master before queueing bridge LOCAL_IN packets. NFQUEUE only holds references on state.in/out and bridge physdevs, so a queued bridge packet can retain a freed bridge master in skb->dev until reinjection. When the verdict is reinjected later, br_netif_receive_skb() re-enters the receive path with skb->dev still pointing at the freed bridge master, triggering a use-after-free. Store skb->dev in the queue entry, hold a reference on it for the queue lifetime, and use the saved device when dropping queued packets during NETDEV_DOWN handling. Fixes: ac2863445686 ("netfilter: bridge: add nf_afinfo to enable queuing to userspace") 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 57b0ac5e1b46f1f0338dff392ef2092e2871b412 Author: Zhengchuan Liang Date: Wed May 13 15:57:17 2026 +0800 netfilter: ip6t_hbh: reject oversized option lists commit 4322dcde6b4173c2d8e8e6118ed290794263bcc8 upstream. struct ip6t_opts stores at most IP6T_OPTS_OPTSNR option descriptors, but hbh_mt6_check() does not reject larger optsnr values supplied from userspace. Validate optsnr in the rule setup path so only match data that fits the fixed-size opts array can be installed. This follows the existing xtables pattern of rejecting invalid user-provided counts in checkentry() and keeps the packet matching path unchanged. `struct ip6t_opts` has a fixed `opts[IP6T_OPTS_OPTSNR]` array, where `IP6T_OPTS_OPTSNR` is 16, then off-by-one array access is possible: [ 137.924693][ T8692] UBSAN: array-index-out-of-bounds in ../net/ipv6/netfilter/ip6t_hbh.c:110:29 [ 137.926167][ T8692] index 16 is out of range for type '__u16 [16]' Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Zhengchuan Liang Signed-off-by: Ren Wei Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit dac025c4e8f9c5cf9467eeac8be4639469aa5ac5 Author: Jonas Jelonek Date: Fri May 15 14:31:03 2026 +0000 net: pse-pd: fix sign on -ENOENT check in of_load_pse_pis() commit 33d35975cbead3fa6b738ee57e5e45e14fbe0886 upstream. of_count_phandle_with_args() returns the count on success and a negative errno on failure, including -ENOENT when the "pairsets" property is absent. The existing comparison in of_load_pse_pis() checks against ENOENT (positive 2) instead of -ENOENT, so the branch is taken for any error return: legitimate DTs that omit "pairsets" trigger a spurious "wrong number of pairsets" error and probe fails with -EINVAL. Compare against -ENOENT so a missing "pairsets" property is correctly treated as "this PI has no pairsets, continue". Fixes: 9be9567a7c59 ("net: pse-pd: Add support for PSE PIs") Cc: stable@vger.kernel.org Signed-off-by: Jonas Jelonek Acked-by: Oleksij Rempel Link: https://patch.msgid.link/20260515143103.1721888-1-jelonek.jonas@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f8a5a76b4a683043c6eff2a060bcaa17f9316ad5 Author: Michael Bommarito Date: Wed May 13 21:37:39 2026 -0400 net: ifb: report ethtool stats over num_tx_queues commit 5db89c99566fc4728cc92e941d8e1975711e24b5 upstream. ifb_dev_init() allocates dp->tx_private to dev->num_tx_queues entries via kzalloc_objs(*txp, dev->num_tx_queues). Both IFB per-queue RX and TX stats live in those entries: ifb_xmit() updates txp->rx_stats using the skb queue mapping, ifb_ri_tasklet() updates txp->tx_stats, and ifb_stats64() aggregates both over dev->num_tx_queues. The ethtool stats callbacks instead size and walk the per-queue stats with dev->real_num_rx_queues and dev->real_num_tx_queues. With an asymmetric device where the RX queue count exceeds the TX queue count, for example: ip link add name ifb10 numtxqueues 1 numrxqueues 8 type ifb ethtool -S ifb10 ifb_get_ethtool_stats() indexes past the tx_private allocation and copies adjacent slab data through ETHTOOL_GSTATS. Use dev->num_tx_queues consistently for the stats strings, the stats count, and the stats data walks. This reports one RX stats group and one TX stats group for each backing ifb_q_private entry, which is the queue set IFB can actually populate. Reproduced under UML+KASAN at v7.1-rc2: BUG: KASAN: slab-out-of-bounds in ifb_fill_stats_data+0x3c/0xae Read of size 8 at addr 0000000062dbd228 by task ethtool/36 ifb_fill_stats_data+0x3c/0xae ifb_get_ethtool_stats+0xc0/0x129 __dev_ethtool+0x1ca5/0x363c dev_ethtool+0x123/0x1b3 dev_ioctl+0x56c/0x744 sock_do_ioctl+0x15f/0x1b2 sock_ioctl+0x4d5/0x50a sys_ioctl+0xd8b/0xde9 With the patch applied, the same UML+KASAN repro is silent and ethtool -S ifb10 reports only the stats backed by the single allocated tx_private entry. Fixes: a21ee5b2fcb8 ("net: ifb: support ethtools stats") Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260514013739.3549624-1-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1604a2d68414aa4cc34faac0b7faa9c14455e8d3 Author: Matt Fleming Date: Wed May 13 12:22:26 2026 +0100 net/mlx5e: Fix use-after-free in mlx5e_tx_reporter_timeout_recover commit 7d260c5d2d89eb2c8c528d54b576b3aae3e20231 upstream. mlx5e_tx_reporter_timeout_recover() accesses sq->netdev after mlx5e_safe_reopen_channels() has torn down and freed the channel (and its embedded SQs). Replace the three sq->netdev references with priv->netdev which is safe because priv outlives channel teardown. The netdev_err() call already used priv->netdev for this reason; make the trylock/unlock and health_channel_eq_recover calls consistent. This fixes the following KASAN splat: BUG: KASAN: use-after-free in mlx5e_tx_reporter_timeout_recover+0x1dd/0x360 [mlx5_core] Read of size 8 at addr ffff889860ed0b28 by task kworker/u113:2/5277 Call Trace: mlx5e_tx_reporter_timeout_recover+0x1dd/0x360 [mlx5_core] devlink_health_reporter_recover+0xa2/0x150 devlink_health_report+0x254/0x7c0 mlx5e_reporter_tx_timeout+0x297/0x380 [mlx5_core] mlx5e_tx_timeout_work+0x109/0x170 [mlx5_core] process_one_work+0x677/0xf20 worker_thread+0x51f/0xd90 kthread+0x3a5/0x810 ret_from_fork+0x208/0x400 ret_from_fork_asm+0x1a/0x30 Fixes: 83ac0304a2d7 ("net/mlx5e: Fix deadlocks between devlink and netdev instance locks") Cc: stable@vger.kernel.org Reviewed-by: Cosmin Ratiu Reviewed-by: Tariq Toukan Signed-off-by: Matt Fleming Link: https://patch.msgid.link/20260513112226.140512-1-matt@readmodwrite.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 49eff79967fd6ea45a9d028710bb852c950baef9 Author: Nerijus Bendžiūnas Date: Sat May 16 18:02:51 2026 +0300 net: phy: skip EEE advertisement write when autoneg is disabled commit 960e77ce14a83ef7f226e8e4b4d75765633ba48b upstream. genphy_c45_an_config_eee_aneg() writes the EEE advertisement to the auto-negotiation device's MMD register space (MDIO_MMD_AN, register MDIO_AN_EEE_ADV). These registers are read by the link partner only during auto-negotiation, so writing them while autoneg is disabled cannot influence the link. On some PHYs (e.g. Broadcom BCM54213PE) the write nevertheless reaches the chip and disturbs the receive datapath. Concretely, running ethtool -s eth0 speed 100 duplex full autoneg off ethtool --set-eee eth0 eee off leaves eth0 with TX working and RX completely silent on a Raspberry Pi 4 / CM4 board (bcmgenet + BCM54213PE in rgmii-rxid). Switching back to autoneg recovers the link. Prior to commit f26a29a038ee ("net: phy: ensure that genphy_c45_an_config_eee_aneg() sees new value of phydev->eee_cfg.eee_enabled"), the disable path was effectively a no-op because the helper read the stale eee_cfg.eee_enabled, so the underlying PHY behavior never surfaced. Bisected on rpi-6.12.y between commits 83943264 (good) and effcbc88 (bad) to f26a29a038ee. Fixes: f26a29a038ee ("net: phy: ensure that genphy_c45_an_config_eee_aneg() sees new value of phydev->eee_cfg.eee_enabled") Cc: stable@vger.kernel.org Signed-off-by: Nerijus Bendžiūnas Reviewed-by: Nicolai Buchwitz Tested-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260516150251.879680-1-nerijus.bendziunas@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3d4ef05266ab16d8ef7dd21658a557801eb78704 Author: Nicolai Buchwitz Date: Wed May 20 20:43:20 2026 +0200 net: bcmgenet: keep RBUF EEE/PM disabled commit 9a1730245e416d11ad5c0f2c100061d61cc43f60 upstream. Setting RBUF_EEE_EN | RBUF_PM_EN in RBUF_ENERGY_CTRL breaks the RX path on GENET hardware once MAC EEE becomes active. RX traffic stops flowing while the link stays up and the usual descriptor/RX error counters remain quiet. In that state the MAC still accepts frames (rbuf_ovflow_cnt keeps climbing) but RBUF no longer forwards them to DMA, so rx_packets is no longer incremented at the netdev level. On some boards the corruption ends up as a paging fault in skb_release_data via bcmgenet_rx_poll on an LPI exit. Reproduced on Pi 4B (BCM2711 + BCM54213PE) and confirmed by Florian Fainelli on an internal Broadcom 4908-family board with the same crash signature. RBUF_PM_EN is not publicly documented. This shows up more often now that phy_support_eee() enables EEE by default, but it also affects older kernels as soon as TX LPI is turned on via ethtool, so it is not specific to recent changes. Always clear RBUF_EEE_EN | RBUF_PM_EN in bcmgenet_eee_enable_set so the bits stay off across resets. UMAC and TBUF setup is left alone so TX-side EEE keeps working. Link: https://github.com/raspberrypi/linux/issues/7304 Fixes: 6ef398ea60d9 ("net: bcmgenet: add EEE support") Cc: stable@vger.kernel.org Signed-off-by: Nicolai Buchwitz Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260520184320.652053-1-nb@tipi-net.de Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 84bc87beb4cd77670939b446326788e4c9b3db37 Author: Zijing Yin Date: Tue May 19 10:26:33 2026 -0700 phonet/pep: disable BH around forwarded sk_receive_skb() commit dbc81608e3a653dea6cf403f20cae35468b8ab9c upstream. The networking receive path is usually run from softirq context, but protocols that take the socket lock may have packets stored in the backlog and processed later from process context. In that case release_sock() -> __release_sock() drops the slock with spin_unlock_bh() and then calls sk->sk_backlog_rcv() with bottom halves enabled. Typical sk_backlog_rcv handlers process the socket whose backlog is being drained, so the BH state at entry is irrelevant for the slocks they touch. pep_do_rcv() is different: when the inbound skb targets an existing PEP pipe, it forwards the skb to a different *child* socket via sk_receive_skb(). That helper takes the child slock with bh_lock_sock_nested(), which is just spin_lock_nested() and assumes BH is already off. The same child slock therefore ends up acquired with BH on (process path) and with BH off (softirq path): process context softirq context --------------- --------------- release_sock(listener) __netif_receive_skb() __release_sock() phonet_rcv() spin_unlock_bh() __sk_receive_skb(listener) [BH now ENABLED] [BH already disabled] sk_backlog_rcv: sk_backlog_rcv: pep_do_rcv() pep_do_rcv() sk_receive_skb(child) sk_receive_skb(child) bh_lock_sock_nested(child) bh_lock_sock_nested(child) => SOFTIRQ-ON-W => IN-SOFTIRQ-W Lockdep flags this as inconsistent lock state, and it can become a real self-deadlock if a softirq on the same CPU tries to receive to the same child socket while its slock is held in the BH-enabled path: WARNING: inconsistent lock state inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. (slock-AF_PHONET/1){+.?.}-{3:3}, at: __sk_receive_skb+0x1cf/0x900 __sk_receive_skb net/core/sock.c:563 sk_receive_skb include/net/sock.h:2022 [inline] pep_do_rcv net/phonet/pep.c:675 sk_backlog_rcv include/net/sock.h:1190 __release_sock net/core/sock.c:3216 release_sock net/core/sock.c:3815 pep_sock_accept net/phonet/pep.c:879 Wrap the forwarded sk_receive_skb() in local_bh_disable() / local_bh_enable() so the child slock is always acquired with BH off. local_bh_disable() nests safely on the softirq path. Discovered via in-house syzkaller fuzzing; the same root cause also on the linux-6.1.y syzbot dashboard as extid 44f0626dd6284f02663c. Reproduced under KASAN + LOCKDEP + PROVE_LOCKING, reproducer: https://pastebin.com/A3t8xzCR Fixes: 9641458d3ec4 ("Phonet: Pipe End Point for Phonet Pipes protocol") Link: https://syzkaller.appspot.com/bug?extid=44f0626dd6284f02663c Cc: stable@vger.kernel.org Signed-off-by: Zijing Yin Acked-by: Rémi Denis-Courmont Reported-by: syzbot+9f4a135646b66c509935@syzkaller.appspotmail.com Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260519172635.86304-1-yzjaurora@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8b4c412e001b0c670eb937beab491af974da55b3 Author: Jiexun Wang Date: Wed May 6 19:43:30 2026 +0800 Bluetooth: serialize accept_q access commit e83f5e24da741fa9405aeeff00b08c5ee7c37b88 upstream. bt_sock_poll() walks the accept queue without synchronization, while child teardown can unlink the same socket and drop its last reference. The unsynchronized accept queue walk has existed since the initial Bluetooth import. Protect accept_q with a dedicated lock for queue updates and polling. Also rework bt_accept_dequeue() to take temporary child references under the queue lock before dropping it and locking the child socket. Fixes: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Jann Horn Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Jiexun Wang Signed-off-by: Ren Wei Signed-off-by: Jiexun Wang Reviewed-by: Jann Horn Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit f1febe93ef075314615f970a87681d9ab86691d1 Author: Michael Bommarito Date: Fri May 15 10:38:19 2026 -0400 Bluetooth: MGMT: validate Add Extended Advertising Data length commit d3f7d17960ed50df3a6709c5158caff989c8c905 upstream. MGMT_OP_ADD_EXT_ADV_DATA is registered as a variable-length command, with MGMT_ADD_EXT_ADV_DATA_SIZE as the fixed header size. The handler then uses cp->adv_data_len and cp->scan_rsp_len to validate and copy cp->data, but it never checks that those bytes are part of the mgmt command payload. A short command can therefore make add_ext_adv_data() pass an out-of-bounds pointer into tlv_data_is_valid(). If the bytes beyond the command buffer are addressable, they can also be copied into the advertising instance as scan response data, where the caller can read them back via MGMT_OP_GET_ADV_INSTANCE. The trigger requires CAP_NET_ADMIN in the initial user namespace; KASAN reports an 8-byte slab-out-of-bounds read. Reject commands whose length does not match the fixed header plus both advertising data lengths before parsing cp->data. Fixes: 12410572833a ("Bluetooth: Break add adv into two mgmt commands") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 051922ab709c0a6917eae765c22481dfc68379e5 Author: Michael Bommarito Date: Mon May 11 08:26:41 2026 -0400 Bluetooth: L2CAP: ecred_reconfigure: send packed pdu, not stack pointer commit 3374ef8cf99368a40f7efd51a2a375a4c5dc6f0d upstream. Commit 1c08108f3014 ("Bluetooth: L2CAP: Avoid -Wflex-array-member-not-at-end warnings") converted the on-stack request PDU in l2cap_ecred_reconfigure() from an explicit packed struct to DEFINE_RAW_FLEX(), but did not adjust the size and source-pointer arguments to l2cap_send_cmd(): - struct { - struct l2cap_ecred_reconf_req req; - __le16 scid; - } pdu; + DEFINE_RAW_FLEX(struct l2cap_ecred_reconf_req, pdu, scid, 1); ... l2cap_send_cmd(conn, chan->ident, L2CAP_ECRED_RECONF_REQ, sizeof(pdu), &pdu); After the conversion, DEFINE_RAW_FLEX() expands to declare an anonymous union pdu_u plus a local pointer "pdu" pointing at it. Therefore: - sizeof(pdu) is now sizeof(struct l2cap_ecred_reconf_req *) = 8 on 64-bit (4 on 32-bit), not the 6 bytes of (mtu, mps, scid[1]). - &pdu is the address of the local pointer's stack storage, not the address of the request payload. l2cap_send_cmd() forwards (data, count) to l2cap_build_cmd(), which calls skb_put_data(skb, data, count). The L2CAP_ECRED_RECONFIGURE_REQ packet body therefore contains 8 bytes copied from the kernel stack starting at &pdu -- the 8 bytes overlap the pdu pointer's value, leaking a kernel stack address to the paired Bluetooth peer. The intended (mtu, mps, scid) fields are not transmitted at all, so the peer rejects the request as malformed and the L2CAP_ECRED_RECONFIGURE feature itself has been broken for the local-side initiator since the introducing commit landed. The sibling site l2cap_ecred_conn_req() in the same commit was converted correctly (sizeof(*pdu) + len, pdu); only this site was missed. Restore the original semantics: pass the full flex-struct size via struct_size(pdu, scid, 1) and the pdu pointer (the struct address) as the source. Validated on a stock 7.0-based host kernel via the real call path: setsockopt(SOL_BLUETOOTH, BT_RCVMTU, ...) on a BT_CONNECTED L2CAP_MODE_EXT_FLOWCTL socket emits an L2CAP_ECRED_RECONFIGURE_REQ whose body is 8 bytes (the on-stack pdu local's value) rather than the expected 6. Three captures from fresh socket / fresh hciemu peer on the same host -- low bytes vary per call, high 0xffff confirms a kernel virtual address (KASLR-randomised stack slot, not a fixed string): RECONF_REQ body (ident=0x02 len=8): 42 fb 54 af 0e ca ff ff RECONF_REQ body (ident=0x02 len=8): 52 3d 2e af 0e ca ff ff RECONF_REQ body (ident=0x02 len=8): b2 fc 5b af 0e ca ff ff After this patch the body is 6 bytes carrying the expected little-endian (mtu, mps, scid). Cc: stable@vger.kernel.org Fixes: 1c08108f3014 ("Bluetooth: L2CAP: Avoid -Wflex-array-member-not-at-end warnings") Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 192cb0f1ca706d9a1bc36ae0ad5f666d1e4fd894 Author: Mingyu Wang <25181214217@stu.xidian.edu.cn> Date: Mon May 18 10:49:49 2026 +0800 Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths commit c1bb9336ae6b54a5f6a353c4bd4ed9a4307e429b upstream. Vulnerabilities leading to Use-After-Free (UAF) and Null Pointer Dereference (NPD) conditions were observed in the lifecycle management of hci_uart. The primary issue arises because the workqueues (init_ready and write_work) are only flushed/cancelled if the HCI_UART_PROTO_READY flag is set during TTY close. If a hangup occurs before setup completes, hci_uart_tty_close() skips the teardown of these workqueues and proceeds to free the `hu` struct. When the scheduled work executes later, it blindly dereferences the freed `hu` struct. Furthermore, several data races and UAFs were identified in the teardown sequence: 1. Calling hci_uart_flush() from hci_uart_close() without effectively disabling write_work causes a race condition where both can concurrently double-free hu->tx_skb. This happens because protocol timers can concurrently invoke hci_uart_tx_wakeup() and requeue write_work. 2. Calling hci_free_dev(hdev) before hu->proto->close(hu) causes a UAF when vendor specific protocol close callbacks dereference hu->hdev. 3. In the initialization error paths, failing to take the proto_lock write lock before clearing PROTO_READY leads to races with active readers. Additionally, hci_uart_tty_receive() accesses hu->hdev outside the read lock, leading to UAFs if the initialization error path frees hdev concurrently. Fix these synchronization and lifecycle issues by: 1. Re-ordering hci_uart_tty_close() to clear HCI_UART_PROTO_READY first, followed immediately by a cancel_work_sync(&hu->write_work). Clearing the flag locks out concurrent protocol timers from successfully invoking hci_uart_tx_wakeup(), effectively rendering the cancellation permanent and preventing the tx_skb double-free. 2. Note: Clearing PROTO_READY early causes hci_uart_close() to skip hu->proto->flush(). This is perfectly safe in the tty_close path because hu->proto->close() executes shortly after, which intrinsically purges all protocol SKB queues and tears down the state. 3. Relocating hu->proto->close(hu) strictly prior to hci_free_dev(hdev) across all close and error paths to prevent vendor-level UAFs. 4. Moving the hdev->stat.byte_rx increment in hci_uart_tty_receive() inside the proto_lock read-side critical section to safely synchronize with device unregistration. 5. Adding cancel_work_sync(&hu->write_work) to hci_uart_close() to safely flush the workqueue before hci_uart_flush() is invoked via the HCI core. 6. Utilizing cancel_work_sync() instead of disable_work_sync() across all paths to prevent permanently breaking user-space retry capabilities. Fixes: 3b799254cf6f ("Bluetooth: hci_uart: Cancel init work before unregistering") Cc: stable@vger.kernel.org Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 5506aec795135cdd4cbf4e845929155663b25055 Author: Jann Horn Date: Tue May 12 22:15:39 2026 +0200 Bluetooth: bnep: Fix UAF read of dev->name commit 59e932ded949fa6f0340bf7c6d7818f962fa4fd2 upstream. bnep_add_connection() needs to keep holding the bnep_session_sem while reading dev->name (just like bnep_get_connlist() does); otherwise the bnep_session() thread can concurrently free the net_device, which can for example be triggered by a concurrent bnep_del_connection(). (This UAF is fairly uninteresting from a security perspective; calling bnep_add_connection() requires passing a capable(CAP_NET_ADMIN) check. It also requires completely tearing down a netdev during a fairly tight race window.) Cc: stable@vger.kernel.org Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Jann Horn Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 61f2410a96dee808029e2ae4d6ef2dd635f3477f Author: David Carlier Date: Fri May 15 07:25:25 2026 +0100 Bluetooth: ISO: drop ISO_END frames received without prior ISO_START commit 84c24fb151fc1179355296d7ff29129ac7c42129 upstream. ISO data PDUs carry a packet-boundary flag indicating START, CONT, END or SINGLE. The ISO_CONT branch of iso_recv() guards against a missing ISO_START by checking conn->rx_len before touching conn->rx_skb, but ISO_END does not. If a peer sends an ISO_END as the first packet on a fresh ISO connection, conn->rx_skb is still NULL and conn->rx_len is zero, so skb_put(conn->rx_skb, ...) dereferences NULL and oopses. For BIS, where receivers sync to a broadcaster without pairing, any broadcaster on the air can trigger this. Mirror the ISO_CONT check at the top of ISO_END so a stray end fragment is logged and dropped instead of crashing the host. Fixes: ccf74f2390d6 ("Bluetooth: Add BTPROTO_ISO socket type") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: David Carlier Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit added1213395071470a900cc845a042fb51882a6 Author: Safa Karakuş Date: Sat May 16 21:15:04 2026 +0300 Bluetooth: fix UAF in l2cap_sock_cleanup_listen() vs l2cap_conn_del() commit ab1513597c6cf17cd1ad2a21e3b045421b48e022 upstream. bt_accept_dequeue() unlinks a not-yet-accepted child from the parent accept queue and release_sock()s it before returning, so the returned sk has no caller reference and is unlocked. l2cap_sock_cleanup_listen() walks these children on listening-socket close. A concurrent HCI disconnect drives hci_rx_work -> l2cap_conn_del() which runs l2cap_chan_del() + l2cap_sock_kill() and frees the child sk and its l2cap_chan; cleanup_listen() then uses both: BUG: KASAN: slab-use-after-free in l2cap_sock_kill l2cap_sock_kill / l2cap_sock_cleanup_listen / __x64_sys_close Freed by: l2cap_conn_del -> l2cap_sock_close_cb -> l2cap_sock_kill This is distinct from the two fixes already in this area: commit e83f5e24da741 ("Bluetooth: serialize accept_q access") serialises the accept_q list/poll and takes temporary refs inside bt_accept_dequeue(), and CVE-2025-39860 serialises the userspace close()/accept() race by calling cleanup_listen() under lock_sock() in l2cap_sock_release(). Neither covers l2cap_conn_del() running from hci_rx_work, so this UAF still reproduces on current bluetooth/master. Take the reference at the source: bt_accept_dequeue() does sock_hold() while sk is still locked, before release_sock(); callers sock_put(). cleanup_listen() pins the chan with l2cap_chan_hold_unless_zero() under a brief child sk lock (serialising vs l2cap_sock_teardown_cb()), drops it before l2cap_chan_lock(), and skips a duplicate l2cap_sock_kill() on SOCK_DEAD. conn->lock is not taken here: cleanup_listen() runs under the parent sk lock and that would invert conn->lock -> chan->lock -> sk_lock (lockdep). KASAN/SMP: an unprivileged listen/close vs HCI-disconnect race produced 12 use-after-free reports per run before this change; 0, and no lockdep report, over 1600+ raced iterations after it on bluetooth/master. Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode") Cc: stable@vger.kernel.org Reported-by: Siwei Zhang Reviewed-by: Siwei Zhang Signed-off-by: Safa Karakuş Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit ffb6dbb49c96be82f07c7b112e3ebc3e6fdd8dd5 Author: Abdun Nihaal Date: Tue May 19 11:57:39 2026 +0530 net: wwan: iosm: fix potential memory leaks in ipc_imem_init() commit c5d93b2c40355e999715262a824965aac025a427 upstream. The memory allocated in ipc_protocol_init() is not freed on the error paths that follow in ipc_imem_init(). Fix that by calling the corresponding release function ipc_protocol_deinit() in the error path. Fixes: 3670970dd8c6 ("net: iosm: shared memory IPC interface") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Link: https://patch.msgid.link/20260519062815.55545-1-nihaal@cse.iitm.ac.in Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0fa24311bd42df98296ec2ae94d602e55ff0eb2a Author: Luiz Capitulino Date: Mon Apr 27 12:03:51 2026 -0400 selftests/mm: run_vmtests.sh: fix destructive tests invocation commit 3432cbb291aabf85f8af4b9d1ec37179168ff999 upstream. Destructive tests should be invoked with -d command-line option, but this won't work today since 'd' is missing in getopts command-line. This commit fixes it. Link: https://lore.kernel.org/214fd9e4-5398-4c26-859e-c982c2e277c3@redhat.com Fixes: f16ff3b692ad ("selftests/mm: run_vmtests.sh: add missing tests") Signed-off-by: Luiz Capitulino Reviewed-by: Mike Rapoport (Microsoft) Reviewed-by: SeongJae Park Cc: David Hildenbrand Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 738d18f1da3513d17b6f7bf30146cc4ac2480ffd Author: David Hildenbrand (Arm) Date: Tue Apr 21 17:39:07 2026 +0200 mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free commit 6a288a4ddb4a994490505ab5f41c445f8e6b6467 upstream. __GFP_ZEROTAGS semantics are currently a bit weird, but effectively this flag is only ever set alongside __GFP_ZERO and __GFP_SKIP_KASAN. If we run with init_on_free, we will zero out pages during __free_pages_prepare(), to skip zeroing on the allocation path. However, when allocating with __GFP_ZEROTAG set, post_alloc_hook() will consequently not only skip clearing page content, but also skip clearing tag memory. Not clearing tags through __GFP_ZEROTAGS is irrelevant for most pages that will get mapped to user space through set_pte_at() later: set_pte_at() and friends will detect that the tags have not been initialized yet (PG_mte_tagged not set), and initialize them. However, for the huge zero folio, which will be mapped through a PMD marked as special, this initialization will not be performed, ending up exposing whatever tags were still set for the pages. The docs (Documentation/arch/arm64/memory-tagging-extension.rst) state that allocation tags are set to 0 when a page is first mapped to user space. That no longer holds with the huge zero folio when init_on_free is enabled. Fix it by decoupling __GFP_ZEROTAGS from __GFP_ZERO, passing to tag_clear_highpages() whether we want to also clear page content. Invert the meaning of the tag_clear_highpages() return value to have clearer semantics. Reproduced with the huge zero folio by modifying the check_buffer_fill arm64/mte selftest to use a 2 MiB area, after making sure that pages have a non-0 tag set when freeing (note that, during boot, we will not actually initialize tags, but only set KASAN_TAG_KERNEL in the page flags). $ ./check_buffer_fill 1..20 ... not ok 17 Check initial tags with private mapping, sync error mode and mmap memory not ok 18 Check initial tags with private mapping, sync error mode and mmap/mprotect memory ... This code needs more cleanups; we'll tackle that next, like decoupling __GFP_ZEROTAGS from __GFP_SKIP_KASAN. [akpm@linux-foundation.org: s/__GPF_ZERO/__GFP_ZERO/, per David] Link: https://lore.kernel.org/20260421-zerotags-v2-1-05cb1035482e@kernel.org Fixes: adfb6609c680 ("mm/huge_memory: initialise the tags of the huge zero folio") Signed-off-by: David Hildenbrand (Arm) Reviewed-by: Catalin Marinas Tested-by: Lance Yang Cc: Brendan Jackman Cc: Dev Jain Cc: Johannes Weiner Cc: Liam Howlett Cc: Lorenzo Stoakes (Oracle) Cc: Mark Brown Cc: Michal Hocko Cc: Mike Rapoport Cc: Ryan Roberts Cc: Suren Baghdasaryan Cc: Will Deacon Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 09ce923071e7852ece60d7368e05249bf32c7967 Author: Muchun Song Date: Tue Apr 28 16:52:17 2026 +0800 mm/memory_hotplug: fix memory block reference leak on remove commit 93866f55f7e292fe3d47d36c9efe5ee10213a06b upstream. Patch series "mm: Fix memory block leaks and locking", v2. This series fixes two memory block device reference leaks and one locking issue around the per-memory_block hwpoison counter. This patch (of 2): remove_memory_blocks_and_altmaps() looks up each memory block with find_memory_block(), which acquires a reference to the memory block device. That reference is never dropped on this path, resulting in a leaked device reference when removing memory blocks and their altmaps. Drop the reference after retrieving mem->altmap and clearing mem->altmap, before removing the memory block device. Link: https://lore.kernel.org/20260428085219.1316047-1-songmuchun@bytedance.com Link: https://lore.kernel.org/20260428085219.1316047-2-songmuchun@bytedance.com Fixes: 6b8f0798b85a ("mm/memory_hotplug: split memmap_on_memory requests across memblocks") Signed-off-by: Muchun Song Acked-by: Oscar Salvador Acked-by: David Hildenbrand (Arm) Cc: Danilo Krummrich Cc: Greg Kroah-Hartman Cc: "Huang, Ying" Cc: Miaohe Lin Cc: Naoya Horiguchi Cc: "Rafael J. Wysocki" Cc: Vishal Verma Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 62153767e8fc3889bc6508e9ffe927aaf64c4334 Author: David Hildenbrand (Arm) Date: Thu Apr 30 13:31:22 2026 +0200 mm: fix __vm_normal_page() to handle missing support for pmd_special()/pud_special() commit c0c6ccd9828c3a1950623b546fa57292a77b5c73 upstream. On x86 32-bit with THP enabled, zap_huge_pmd() is seen to generate a "WARNING: mm/memory.c:735 at __vm_normal_page+0x6a/0x7d", from the VM_WARN_ON_ONCE(is_zero_pfn(pfn) || is_huge_zero_pfn(pfn)); followed by "BUG: Bad rss-counter state"s, then later "BUG: Bad page state"s when reclaim gets to call shrink_huge_zero_folio_scan(). It's as if the _PAGE_SPECIAL bit never got set in the huge_zero pmd: and indeed, whereas pte_special() and pte_mkspecial() are subject to a dedicated CONFIG_ARCH_HAS_PTE_SPECIAL, pmd_special() and pmd_mkspecial() are subject to CONFIG_ARCH_SUPPORTS_PMD_PFNMAP, which is never enabled on any 32-bit architecture. While the problem was exposed through commit d80a9cb1a64a ("mm/huge_memory: add and use normal_or_softleaf_folio_pmd()"), it was an oversight in commit af38538801c6 ("mm/memory: factor out common code from vm_normal_page_*()") and would result in other problems: * huge zero folio accounted in smaps, pagemap (PAGE_IS_FILE) and numamaps as file-backed THP * folio_walk_start() returning the folio even without FW_ZEROPAGE set. Callers seem to tolerate that, though. ... and triggering the VM_WARN_ON_ONE(), although never reported so far. To fix it, teach vm_normal_page_pmd()/vm_normal_page_pud() to consider whether pmd_special/pud_special is actually implemented. Link: https://lore.kernel.org/20260430-pmd_special-v1-1-dbcbcfd72c20@kernel.org Fixes: af38538801c6 ("mm/memory: factor out common code from vm_normal_page_*()") Signed-off-by: David Hildenbrand (Arm) Reported-by: Hugh Dickins Closes: https://lore.kernel.org/r/74a75b59-2e13-3985-ee99-d5521f39df2a@google.com Reported-by: Bibo Mao Closes: https://lore.kernel.org/r/20260430041121.2839350-1-maobibo@loongson.cn Debugged-by: Hugh Dickins Reviewed-by: Lance Yang Tested-by: Bibo Mao Reviewed-by: Baolin Wang Reviewed-by: Oscar Salvador Reviewed-by: Lorenzo Stoakes Cc: Liam R. Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 2fff0cdd942261497fb8922a194b4da3315ae864 Author: Alistair Popple Date: Fri May 1 16:51:16 2026 +1000 mm/memory: fix spurious warning when unmapping device-private/exclusive pages commit be3f38d05cc5a7c3f13e51994c5dd043ab604d28 upstream. Device private and exclusive entries are only supported for anonymous folios. This condition is tested in __migrate_device_pages() and make_device_exclusive() using folio_test_anon(). However the unmap path tests this assumption using vma_is_anonymous(). This is wrong because whilst anonymous VMAs can only contain folios where folio_test_anon() is true the opposite relation does not hold. A folio for which folio_test_anon() is true does not imply vma_is_anonymous() is true. Such a condition can occur if for example a folio is part of a private filebacked mapping. In this case vma_is_anonymous() is false as the mapping is filebacked, but folio_test_anon() may be true, thus permitting devices to migrate the folio to device private memory. This can lead to the following spurious warnings during process teardown: [ 772.737706] ------------[ cut here ]------------ [ 772.739201] WARNING: mm/memory.c:1754 at unmap_page_range.cold+0x26/0x18a, CPU#17: hmm-tests/2041 [ 772.742050] Modules linked in: test_hmm nvidia_uvm(O) nvidia(O) [ 772.743959] CPU: 17 UID: 0 PID: 2041 Comm: hmm-tests Tainted: G W O 7.0.0+ #387 PREEMPT(full) [ 772.747104] Tainted: [W]=WARN, [O]=OOT_MODULE [ 772.748509] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 772.752117] RIP: 0010:unmap_page_range.cold+0x26/0x18a [ 772.753780] Code: 7e fe ff ff 48 89 4c 24 78 4c 89 44 24 38 e8 f2 ff b1 00 48 8b 4c 24 78 4c 8b 44 24 38 48 8b 44 24 18 48 83 78 48 00 74 04 90 <0f> 0b 90 48 89 ca b8 ff ff 37 00 48 c1 ea 03 48 c1 e0 2a 80 3c 02 [ 772.759602] RSP: 0018:ffff888112607550 EFLAGS: 00010286 [ 772.761310] RAX: ffff88811bbf4dc0 RBX: dffffc0000000000 RCX: ffffea03e9bfffd8 [ 772.763583] RDX: 1ffff1102377e9c1 RSI: 0000000000000008 RDI: ffff88811bbf4e08 [ 772.765914] RBP: 0000000000000006 R08: ffff8881059f7448 R09: ffffed10224c0e68 [ 772.768184] R10: ffff888112607347 R11: 0000000000000001 R12: 0000000000000001 [ 772.770461] R13: ffffea03e9bfffc0 R14: ffff888112607908 R15: ffffea03e9bfffc0 [ 772.772782] FS: 00007f327caa2780(0000) GS:ffff888427b7d000(0000) knlGS:0000000000000000 [ 772.775328] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 772.777187] CR2: 00007f327ca89000 CR3: 00000001994d5000 CR4: 00000000000006f0 [ 772.779135] Call Trace: [ 772.779792] [ 772.780317] ? dmirror_interval_invalidate+0x1a3/0x290 [test_hmm] [ 772.781873] ? vm_normal_page_pud+0x2b0/0x2b0 [ 772.782992] ? __rwlock_init+0x150/0x150 [ 772.784006] ? lock_release+0x216/0x2b0 [ 772.785008] ? __mmu_notifier_invalidate_range_start+0x505/0x6e0 [ 772.786522] ? lock_release+0x216/0x2b0 [ 772.787498] ? unmap_single_vma+0xb6/0x210 [ 772.788573] unmap_vmas+0x27d/0x520 [ 772.789506] ? unmap_single_vma+0x210/0x210 [ 772.790607] ? mas_update_gap.part.0+0x620/0x620 [ 772.791834] unmap_region+0x19e/0x350 [ 772.792769] ? remove_vma+0x130/0x130 [ 772.793684] ? mas_alloc_nodes+0x1f2/0x300 [ 772.794730] vms_complete_munmap_vmas+0x8c1/0xe20 [ 772.795926] ? unmap_region+0x350/0x350 [ 772.796917] do_vmi_align_munmap+0x36a/0x4e0 [ 772.798018] ? lock_release+0x216/0x2b0 [ 772.799024] ? vma_shrink+0x620/0x620 [ 772.799983] do_vmi_munmap+0x150/0x2c0 [ 772.800939] __vm_munmap+0x161/0x2c0 [ 772.801872] ? expand_downwards+0xd60/0xd60 [ 772.802948] ? clockevents_program_event+0x1ef/0x540 [ 772.804217] ? lock_release+0x216/0x2b0 [ 772.805158] __x64_sys_munmap+0x59/0x80 [ 772.805776] do_syscall_64+0xfc/0x670 [ 772.806336] ? irqentry_exit+0xda/0x580 [ 772.806976] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 772.807772] RIP: 0033:0x7f327cbb2717 [ 772.808323] Code: 73 01 c3 48 8b 0d f9 76 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 0b 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c9 76 0d 00 f7 d8 64 89 01 48 [ 772.811337] RSP: 002b:00007ffde7f57d38 EFLAGS: 00000202 ORIG_RAX: 000000000000000b [ 772.812564] RAX: ffffffffffffffda RBX: 00007f327cc9c000 RCX: 00007f327cbb2717 [ 772.813733] RDX: 0000000000000000 RSI: 0000000000400000 RDI: 00007f327c289000 [ 772.814867] RBP: 0000000000421360 R08: 000000000000001a R09: 0000000000000000 [ 772.815991] R10: 0000000000000003 R11: 0000000000000202 R12: 00007ffde7f57d74 [ 772.817121] R13: 00007f327c689010 R14: 0000000000100000 R15: 00007f327c289000 [ 772.818272] [ 772.818614] irq event stamp: 0 [ 772.819159] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [ 772.820174] hardirqs last disabled at (0): [] copy_process+0x19f3/0x6440 [ 772.821511] softirqs last enabled at (0): [] copy_process+0x1a40/0x6440 [ 772.822869] softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 772.823871] ---[ end trace 0000000000000000 ]--- Fix this by using the same check for folio_test_anon() in zap_nonpresent_ptes(). Also add a hmm-test case for this. Link: https://lore.kernel.org/20260501065116.2057242-1-apopple@nvidia.com Fixes: 999dad824c39 ("mm/shmem: persist uffd-wp bit across zapping for file-backed") Signed-off-by: Alistair Popple Reported-by: Arsen Arsenović Reviewed-by: Balbir Singh Cc: David Hildenbrand Cc: Jason Gunthorpe Cc: John Hubbard Cc: Leon Romanovsky Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Peter Xu Cc: Matthew Brost Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Thomas Hellström Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 24de676da63c1122d2c13b0d546238b66d1b4e62 Author: Justin Iurman Date: Wed May 20 14:42:42 2026 +0200 ipv6: ioam: refresh hdr pointer before ioam6_event() commit e46e6bc97fb1f339730ff1ba74267fbf48e7a422 upstream. Reported by Sashiko: In ipv6_hop_ioam(), the hdr pointer is initialized to point into the skb's linear data buffer. Later, the code calls skb_ensure_writable(), which might reallocate the buffer: if (skb_ensure_writable(skb, optoff + 2 + hdr->opt_len)) goto drop; /* Trace pointer may have changed */ trace = (struct ioam6_trace_hdr *)(skb_network_header(skb) + optoff + sizeof(*hdr)); ioam6_fill_trace_data(skb, ns, trace, true); ioam6_event(IOAM6_EVENT_TRACE, dev_net(skb->dev), GFP_ATOMIC, (void *)trace, hdr->opt_len - 2); If the skb is cloned or lacks sufficient linear headroom, skb_ensure_writable() will invoke pskb_expand_head(), which reallocates the skb's data buffer and frees the old one, invalidating pointers to it. While the code recalculates the trace pointer immediately after the call to skb_ensure_writable(), it fails to recalculate the hdr pointer. This patch fixes the above by recalculating the hdr pointer before passing hdr->opt_len to ioam6_event(), so that we avoid any UaF. Fixes: f655c78d6225 ("net: exthdrs: ioam6: send trace event") Cc: stable@vger.kernel.org Signed-off-by: Justin Iurman Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260520124242.32320-1-justin.iurman@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 24840b3139d7415144b81e4f9f4c44670d15bed9 Author: Muchun Song Date: Tue Apr 28 16:52:18 2026 +0800 drivers/base/memory: fix memory block reference leak in poison accounting commit 03a2cc1756a0570f887d624cd6c535ea0cbd4951 upstream. memblk_nr_poison_inc() and memblk_nr_poison_sub() look up a memory block via find_memory_block_by_id(), which acquires a reference to the memory block device. Both helpers use the returned memory block without dropping that reference, leaking the device reference on each successful lookup. Drop the reference after updating nr_hwpoison. Link: https://lore.kernel.org/20260428085219.1316047-3-songmuchun@bytedance.com Fixes: 5033091de814 ("mm/hwpoison: introduce per-memory_block hwpoison counter") Signed-off-by: Muchun Song Reviewed-by: Miaohe Lin Acked-by: Oscar Salvador Acked-by: David Hildenbrand (Arm) Cc: Danilo Krummrich Cc: Greg Kroah-Hartman Cc: "Huang, Ying" Cc: Naoya Horiguchi Cc: "Rafael J. Wysocki" Cc: Vishal Verma Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b737c6612c60c23b40a9f31749b99e6f61943847 Author: Heechan Kang Date: Sun May 17 03:47:09 2026 +0900 io_uring/waitid: clear waitid info before copying it to userspace commit 93d93f5f8da791e98159795c6ef683f45bd95d13 upstream. IORING_OP_WAITID stores its result fields in struct io_waitid::info and later copies them to userspace siginfo. The prep path initializes the request arguments, but it does not initialize info itself. If the wait operation completes without reporting a child event, the common wait code can return without writing wo_info. In that case io_waitid_finish() still copies iw->info to userspace, exposing stale bytes from the reused io_kiocb command storage. Clear the result storage during prep so the io_uring path matches the regular waitid syscall, which uses a zero-initialized struct waitid_info. Fixes: f31ecf671ddc ("io_uring: add IORING_OP_WAITID support") Cc: stable@vger.kernel.org # 6.7+ Signed-off-by: Heechan Kang Link: https://patch.msgid.link/20260516184709.852814-1-gganji11@naver.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 5fb947ddae55f82358967aa620679f572572f844 Author: Krishnamoorthi M Date: Thu May 7 23:30:51 2026 +0530 spi: amd: Set correct bus number in ACPI probe path commit 422bd00b71ab42163aa3b8f8370276fe4c1581e7 upstream. On platforms where the HID2 SPI controller (AMDI0063) is enumerated via ACPI instead of PCI, amd_spi_probe() unconditionally sets bus_num to 0, while the PCI probe path assigns bus_num 2 for HID2 controller. Align the ACPI probe path to use the same bus number so that userspace and SPI client drivers see a consistent bus assignment regardless of the enumeration method. Fixes: b644c2776652 ("spi: spi_amd: Add PCI-based driver for AMD HID2 SPI controller") Cc: stable@vger.kernel.org # v6.16+ Signed-off-by: Krishnamoorthi M Link: https://patch.msgid.link/20260507180051.4158674-1-krishnamoorthi.m@amd.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c32a1fbe0f9a48453a552bb315cc4f1e7a74084e Author: Ard Biesheuvel Date: Tue May 19 10:03:00 2026 +0200 efi: Allocate runtime workqueue before ACPI init commit 13c6da02e767152c9ac4330962247a5e47011035 upstream. Since commit 5894cf571e14 ("acpi/prmt: Use EFI runtime sandbox to invoke PRM handlers") ACPI PRM calls are delegated to a workqueue which runs in a kernel thread, making it easier to detect and mitigate faulting memory accesses performed by the firmware. Rafael reports that such PRM accesses may occur before efisubsys_init() executes, which is where the workqueue is allocated, leading to NULL pointer dereferences. Since acpi_init() [which triggers the early PRM accesses] executes as a subsys_initcall() as well, and has its own dependencies that may be sensitive to initcall ordering, deferring acpi_init() is not an option. So instead, split off the workqueue allocation into its own postcore initcall, as this is the only missing piece to allow EFI runtime calls to be made. This ensures that EFI runtime call (including PRM calls) are accessible to all code running at subsys_initcall() level. Cc: Fixes: 5894cf571e14 ("acpi/prmt: Use EFI runtime sandbox to invoke PRM handlers") Reviewed-by: Rafael J. Wysocki (Intel) Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit fcbd0a5fd812e9c19733de1a3c271e5b4aa8b06f Author: Cássio Gabriel Date: Tue May 19 11:46:19 2026 -0300 ALSA: scarlett2: Allow flash writes ending at segment boundary commit a69b677e47a80319ce148d61cc29a2b57006e78d upstream. scarlett2_hwdep_write() rejects writes when offset + count is greater than or equal to the selected flash segment size. That incorrectly treats a write ending exactly at the end of the segment as out of space, although the last byte written is still within the segment. Split invalid argument checks from the segment-space check, keep zero-length writes as no-ops, and compare count against the remaining segment size. This permits exact-end writes and avoids relying on offset + count before deciding whether the request is in bounds. Fixes: 1abfbd3c9527 ("ALSA: scarlett2: Add support for uploading new firmware") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260519-alsa-scarlett2-flash-write-boundary-v1-1-b550480e92da@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 61c5017c64e2ac9e10b70b14b17a079dbc0a805f Author: Takashi Iwai Date: Fri May 15 10:55:58 2026 +0200 ALSA: asihpi: Fix potential OOB array access at reading cache commit 7b7d6572145c1dab2dd9bfb550b188e5f0ff3c3f upstream. find_control() to retrieve a cached info accesses the array with the given index blindly, which may lead to an OOB array access. Add a sanity check for avoiding it. Link: https://sashiko.dev/#/patchset/20260511230121.28606-1-rosenp%40gmail.com Cc: Link: https://patch.msgid.link/20260515085606.242284-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit feff0251386aa6bb180a0a1cf7c1f91ba868113d Author: Takashi Iwai Date: Sun May 17 18:51:20 2026 +0200 ALSA: pcm: Don't setup bogus iov_iter for silencing commit e4d3386b74fba8e01280484b67ee481ece00201e upstream. At transition to the iov_iter for PCM data transfer, we blindly applied the iov_iter setup also for silencing (i.e. data = NULL), and it leads to a calculation of bogus iov_iter. Fortunately this didn't cause troubles on most of architectures but it goes wrong on RISC-V now, causing a NULL dereference. Handle the NULL data case to treat the silencing in interleaved_copy() for addressing the bug above. noninterleaved_copy() has already the NULL data handling, so it doesn't need changes. Reported-by: Jiakai Xu Closes: https://lore.kernel.org/20260515051516.3103036-1-xujiakai24@mails.ucas.ac.cn Fixes: cf393babb37a ("ALSA: pcm: Add copy ops with iov_iter") Cc: Link: https://patch.msgid.link/20260517165121.31399-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit cba8dab72e9b480f6bc07d83974afb1648c6573f Author: Cássio Gabriel Date: Tue May 19 00:32:15 2026 -0300 ALSA: ua101: Reject too-short USB descriptors commit b59d5c51bb328a60749b4dd5fe7e649bfb4089b4 upstream. find_format_descriptor() walks the class-specific interface extras by advancing with bLength. It rejects descriptors that extend past the remaining buffer, but it does not reject descriptor lengths smaller than a USB descriptor header. Reject too-short descriptors before using bLength to advance the local scan. This keeps the UA-101 parser robust against malformed descriptor data and matches the usual USB descriptor walking rules. Fixes: 63978ab3e3e9 ("sound: add Edirol UA-101 support") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260519-alsa-ua101-desc-len-v1-1-4307d1a5e054@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ca560f7566df7e2826c2999e959e6b94eb938f76 Author: Abdurrahman Hussain Date: Fri May 15 15:11:48 2026 -0700 hwmon: (pmbus/adm1266) widen blackbox-info buffer to I2C_SMBUS_BLOCK_MAX commit eee213daa1e1b402eb631bcd1b8c5aa340a6b081 upstream. adm1266_nvmem_read_blackbox() declares a 5-byte stack buffer and passes it to i2c_smbus_read_block_data() to retrieve the 4-byte BLACKBOX_INFO response. i2c_smbus_read_block_data() does not honour caller buffer sizes -- it memcpy()s data.block[0] bytes from the SMBus transaction (where data.block[0] is the length byte returned by the slave device, up to I2C_SMBUS_BLOCK_MAX = 32): memcpy(values, &data.block[1], data.block[0]); If the device returns any block length above 5, the call overflows the caller's 5-byte stack buffer before the post-call if (ret != 4) return -EIO; check has a chance to reject the response. Widen the local buffer to I2C_SMBUS_BLOCK_MAX so the helper has room for any well-formed SMBus block response, matching the convention used by the other i2c_smbus_read_block_data() callers in this driver. Fixes: 15609d189302 ("hwmon: (pmbus/adm1266) read blackbox") Cc: stable@vger.kernel.org Signed-off-by: Abdurrahman Hussain Link: https://lore.kernel.org/r/20260515-adm1266-fixes-v1-2-1c1ea1349cfe@nexthop.ai Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 9803e75c9813a7cbebb258e47719ed9055b708ef Author: ChenXiaoSong Date: Mon May 18 15:23:22 2026 +0000 smb/server: promote S_DEL_ON_CLS to S_DEL_PENDING when close commit 4ec9c8e023c79f613fe4d5ad8cc737112efb2e44 upstream. Reproducer: 1. server: systemctl start ksmbd 2. client: mount -t cifs //${server_ip}/export /mnt 3. client: C program: openat(AT_FDCWD, "/mnt", O_RDWR | O_TMPFILE, 0600) Do not treat `FILE_DELETE_ON_CLOSE_LE` as delete pending while files remain open. This patch fixes xfstests generic/004. Cc: stable@vger.kernel.org Link: https://chenxiaosong.com/en/smb-xfstests-generic-004.html Co-developed-by: Huiwen He Signed-off-by: Huiwen He Signed-off-by: ChenXiaoSong Tested-by: Steve French Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit d65104a4a81573994be43718f10e1c18110b9e07 Author: Jeremy Erazo Date: Fri May 15 19:31:41 2026 +0000 smb: client: use data_len for SMB2 READ encrypted folioq copy commit d4d76c9ee1997cc8c977a63f6c43551c253c1066 upstream. In handle_read_data() the encrypted/folioq branch (buf_len <= data_offset, reached via receive_encrypted_read for transform PDUs > CIFSMaxBufSize + MAX_HEADER_SIZE) copies the READ payload using buffer_len rather than data_len: rdata->result = cifs_copy_folioq_to_iter(buffer, buffer_len, cur_off, &rdata->subreq.io_iter); ... rdata->got_bytes = buffer_len; buffer_len comes from the SMB3 transform header OriginalMessageSize field (OriginalMessageSize - read_rsp_size); it represents the size of the decrypted message after the SMB2 header. data_len comes from the SMB2 READ response DataLength field; it represents the actual READ payload size and may be smaller than buffer_len when the decrypted message contains padding or other trailing bytes after the READ payload. The existing check `data_len > buffer_len - pad_len` only enforces an upper bound, so a server that emits OriginalMessageSize larger than read_rsp_size + pad_len + data_len passes the check and the kernel copies buffer_len bytes per response, ignoring the server-asserted DataLength. Two observable failures with a crafted server (DataLength=4, buffer_len=20000): - the kernel returns 20000 bytes per sub-request to userspace and sets got_bytes = buffer_len, even though the response claimed only 4 bytes of payload; - on a partial netfs sub-request whose iterator is sized to data_len, the over-large copy_folio_to_iter() short-reads, cifs_copy_folioq_to_iter() returns -EIO via the n != len path, and the entire netfs read collapses to -EIO even though the leading sub-requests succeeded. Use data_len for the copy length and for got_bytes so the kernel honours the server-asserted READ payload size. For well-formed servers (where buffer_len == pad_len + data_len) the change is behaviour-equivalent. Cc: stable@vger.kernel.org Signed-off-by: Jeremy Erazo Acked-by: David Howells Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit bf4ebdb19ff9b3cdf992b50715fe61633327416a Author: Henrique Carvalho Date: Thu May 14 20:18:25 2026 -0300 smb: client: protect tc_count increment in smb2_find_smb_sess_tcon_unlocked() commit 4d8690dace005a38e6dbde9ecce2da3ad85c7c41 upstream. Commit 96c4af418586 ("cifs: Fix locking usage for tcon fields") refactored cifs code to change cifs_tcp_ses_lock for tc_lock around tc_count changes. There was missing lock around tc_count increment inside smb2_find_smb_sess_tcon_unlocked(). Cc: stable@vger.kernel.org Fixes: 96c4af418586 ("cifs: Fix locking usage for tcon fields") Reviewed-by: Shyam Prasad N Signed-off-by: Henrique Carvalho Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit a8d17d22db591099519a89f14dd24810daba74c3 Author: Michael Bommarito Date: Sun May 17 20:11:50 2026 -0400 smb: client: require net admin for CIFS SWN netlink commit d1ebfce2c1d161186a82e77590bf7da2ea1bce91 upstream. CIFS_GENL_CMD_SWN_NOTIFY is the userspace witness-notify command. The intended sender is the cifs.witness helper, but the generic-netlink operation currently has no capability flag, so any local process can send RESOURCE_CHANGE or CLIENT_MOVE notifications to the in-kernel witness handler. The same family exposes CIFS_GENL_MCGRP_SWN without multicast-group capability flags. Register messages sent to that group include the witness registration id and, for NTLM-authenticated mounts, the username, domain, and password attributes copied from the CIFS session. An unprivileged local process should not be able to join that group and receive those messages. Require CAP_NET_ADMIN for incoming SWN_NOTIFY commands with GENL_ADMIN_PERM, and require CAP_NET_ADMIN over the network namespace for joining the SWN multicast group with GENL_MCAST_CAP_NET_ADMIN. The cifs.witness service runs with the privileges needed for both operations. Fixes: fed979a7e082 ("cifs: Set witness notification handler for messages from userspace daemon") Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 6827647fd2dcf4e7f355478a42e82f51e0b5344c Author: Alexander Sverdlin Date: Mon May 18 10:31:11 2026 +0200 regulator: tps65219: fix irq_data.rdev not being assigned commit f9b2d3b703d13df50c630997dfdc25648e96db0d upstream. Commit 64a6b577490c ("regulator: tps65219: Remove debugging helper function") removed the tps65219_get_rdev_by_name() helper along with the irq_data.rdev assignment that depended on it. This left irq_data.rdev uninitialized for all IRQs, causing undefined behavior when regulator_notifier_call_chain() is called from the IRQ handler: Internal error: Oops: 0000000096000004 pc : regulator_notifier_call_chain lr : tps65219_regulator_irq_handler Call trace: regulator_notifier_call_chain tps65219_regulator_irq_handler handle_nested_irq regmap_irq_thread irq_thread_fn irq_thread kthread ret_from_fork Instead of restoring a dedicated lookup array, restructure the probe function to combine regulator registration with IRQ registration in the same loop. This way the rdev returned by devm_regulator_register() is naturally available for assigning to irq_data.rdev without any auxiliary data structure. Non-regulator IRQs (SENSOR, TIMEOUT) that don't correspond to any registered regulator are registered with rdev=NULL, and the IRQ handler is protected with a NULL check to avoid crashing. Cc: stable@vger.kernel.org Closes: https://lore.kernel.org/all/aBDSTxALaOc-PD7X@gaggiata.pivistrello.it/ Reported-by: Francesco Dolcini Fixes: 64a6b577490c ("regulator: tps65219: Remove debugging helper function") Signed-off-by: Alexander Sverdlin Link: https://patch.msgid.link/20260518083113.2063368-1-alexander.sverdlin@siemens.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 18d8db24b0a5b7be4829238dd4022236df02d421 Author: Junyi Liu Date: Tue May 19 16:12:04 2026 +0900 ksmbd: validate SID in parent security descriptor during ACL inheritance commit 69f030cf95488ae1186c72ac8c66fd279664ea7f upstream. Introduce smb_validate_ntsd_sid() helper to safely validate Owner SID and Group SID inside the NT Security Descriptor (smb_ntsd) retrieved from the parent directory. Cc: stable@vger.kernel.org Signed-off-by: Junyi Liu Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 0e198f09cb2a554c04de0fea4e790f1250a943ca Author: Ferry Meng Date: Mon May 11 21:18:16 2026 +0800 ksmbd: fix SID memory leak in set_posix_acl_entries_dacl() on overflow commit af92ee994cc7f7e83a41c2025f32257a2f82a7ef upstream. Commit 299f962c0b02 ("ksmbd: use check_add_overflow() to prevent u16 DACL size overflow") added check_add_overflow() guards that break out of the ACE-building loops in set_posix_acl_entries_dacl() when the accumulated DACL size would wrap past 65535. However, each iteration allocates a struct smb_sid via kmalloc_obj() at the top of the loop and relies on the kfree(sid) call at the end of the loop body (the 'pass_same_sid' label in the first loop, and the explicit kfree at the tail of the second loop) to release it. The newly introduced 'break' statements bypass those kfree() calls, leaking the sid buffer every time an overflow is detected. A malicious or malformed file with enough POSIX ACL entries to trip the overflow check will leak one or more struct smb_sid allocations on every request that touches the file's DACL, providing a trivial kernel memory exhaustion vector. Free sid before breaking out of the loops to plug the leak. Fixes: 299f962c0b02 ("ksmbd: use check_add_overflow() to prevent u16 DACL size overflow") Cc: stable@vger.kernel.org Signed-off-by: Ferry Meng Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit cd5c1b75d2f454f625d7dc55bd3ae21d0855f6ad Author: Jeremy Laratro Date: Wed May 13 08:26:16 2026 +0900 ksmbd: fix null pointer dereference in compare_guid_key() commit 4b83cbc4c15f09b000cc06f033f64b0824b6dc87 upstream. session_fd_check() walks the per-inode m_op_list during durable-handle session teardown and sets op->conn = NULL for every opinfo whose conn matched the closing session's connection. The matching opinfo, however, stays linked in its per-ClientGuid lease_table_list entry's lb->lease_list because destroy_lease_table() only runs on full TCP-connection teardown, not on SESSION_LOGOFF. If the same TCP connection then negotiates a fresh session with the same ClientGuid (ClientGuid is bound to NEGOTIATE, not the session, and is unchanged across LOGOFF + SETUP) and issues a SMB2 CREATE with a lease context on a different inode, find_same_lease_key() walks lb->lease_list, reaches the stale opinfo, and calls compare_guid_key(), which unconditionally dereferences opinfo->conn->ClientGUID. The conn pointer is NULL and the kernel panics. Reproducer requires only a successful SMB2 SESSION_SETUP and a share configured with 'durable handles = yes'. KASAN report on mainline 70390501d194: general protection fault, probably for non-canonical address 0xdffffc0000000069: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000348-0x000000000000034f] Workqueue: ksmbd-io handle_ksmbd_work RIP: 0010:bcmp+0x5b/0x230 Call Trace: compare_guid_key+0x4b/0xd0 find_same_lease_key+0x324/0x690 smb2_open+0x6aea/0x8e60 handle_ksmbd_work+0x796/0xee0 ... Faulting address 0x348 is the offset of ClientGUID within struct ksmbd_conn, confirming opinfo->conn was NULL. Read opinfo->conn once and bail out if it has been cleared by a concurrent session_fd_check(). A half-detached opinfo cannot be the owner of an active lease, so returning 0 is the correct match result. Fixes: c8efcc786146 ("ksmbd: add support for durable handles v1/v2") Cc: stable@vger.kernel.org Signed-off-by: Jeremy Laratro Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 302e02f9ba49f81418ec2a749ae6f5cac1d424e9 Author: SeongJae Park Date: Sun Apr 26 10:36:12 2026 -0700 mm/damon/sysfs-schemes: call missing mem_cgroup_iter_break() commit d4e7b5c4cc353f154d5ab8bb2e1ce7714d77a6e9 upstream. damon_sysfs_memcg_path_to_id() breaks mem_cgroup_iter() loop without calling mem_cgroup_iter_break(). This leaks the cgroup reference. Fix the issue by calling mem_cgroup_iter_break() before the break. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260426173625.86521-1-sj@kernel.org Link: https://lore.kernel.org/20260423004148.74722-1-sj@kernel.org [1] Fixes: 29cbb9a13f05 ("mm/damon/sysfs-schemes: implement scheme filters") Signed-off-by: SeongJae Park Cc: # 6.3.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 48fa96538bd2868034d33429e4565fda384d0736 Author: Greg Kroah-Hartman Date: Wed May 20 15:05:04 2026 +0200 sysfs: don't remove existing directory on update failure commit 237557b8a81ab948e8332f7c0058e758f081c0a3 upstream. When sysfs_update_group() is called for a named group and create_files() fails (e.g. -ENOMEM), internal_create_group() calls kernfs_remove(kn) on the group directory. In the update path, kn was obtained via kernfs_find_and_get() and refers to a directory that already existed before this call. Removing it silently destroys a sysfs group that the caller did not create. Only remove the directory if we created it ourselves. On update failure the directory remains as it is left empty by remove_files() inside create_files(), but can be repopulated by a retry. Cc: Rajat Jain Fixes: c855cf2759d2 ("sysfs: Fix internal_create_group() for named group updates") Cc: stable Assisted-by: gkh_clanker_t1000 Reviewed-by: Rafael J. Wysocki (Intel) Reviewed-by: Danilo Krummrich Link: https://patch.msgid.link/2026052003-uniquely-hastily-c093@gregkh Signed-off-by: Greg Kroah-Hartman commit 141ffb83abe97db88df8822c82cd53ae5e38221a Author: Thomas Zimmermann Date: Tue May 26 21:31:23 2026 +0800 drm/vblank: Fix kernel docs for vblank timer [ Upstream commit 3946d3ba99342f3b9996e621f05e7003d4308171 ] Fix documentation for drm_crtc_vblank_start_timer(), which referred to drm_crtc_vblank_cancel_timer(). Signed-off-by: Thomas Zimmermann Reported-by: Stephen Rothwell Closes: https://lore.kernel.org/dri-devel/20251106152201.6f248c09@canb.auug.org.au/ Fixes: 74afeb812850 ("drm/vblank: Add vblank timer") Cc: Thomas Zimmermann Cc: Louis Chauvet Cc: Javier Martinez Canillas Cc: David Airlie Cc: Simona Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: dri-devel@lists.freedesktop.org Reviewed-by: Louis Chauvet Link: https://patch.msgid.link/20251106073207.11192-1-tzimmermann@suse.de Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> Signed-off-by: Sasha Levin commit ed39ecd3a96cdf94589aef46f2f711cf93baa0d3 Author: Thomas Zimmermann Date: Tue May 26 21:31:22 2026 +0800 drm/atomic: Increase timeout in drm_atomic_helper_wait_for_vblanks() [ Upstream commit 79ae8510b5b81b9500370f89c619b50ca9c0990f ] Increase the timeout for vblank events from 100 ms to 1000 ms. This is the same fix as in commit f050da08a4ed ("drm/vblank: Increase timeout in drm_wait_one_vblank()") for another vblank timeout. After merging generic DRM vblank timers [1] and converting several DRM drivers for virtual hardware, these drivers synchronize their vblank events to the display refresh rate. This can trigger timeouts within the DRM framework. Signed-off-by: Thomas Zimmermann Link: https://lore.kernel.org/dri-devel/20250904145806.430568-1-tzimmermann@suse.de/ # [1] Reported-by: syzbot+fcede535e7eb57cf5b43@syzkaller.appspotmail.com Closes: https://lore.kernel.org/dri-devel/69381d6c.050a0220.4004e.0017.GAE@google.com/ Reviewed-by: Ville Syrjälä Fixes: 74afeb812850 ("drm/vblank: Add vblank timer") Link: https://patch.msgid.link/20251209143325.102056-1-tzimmermann@suse.de Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> Signed-off-by: Sasha Levin commit a0582cc923985c6b72fe871b5f7aa7c682bfc230 Author: Thomas Zimmermann Date: Tue May 26 21:31:21 2026 +0800 drm/vkms: Convert to DRM's vblank timer [ Upstream commit 02e2681ffe1addde1fc8c35d05657b16bfa79613 ] Replace vkms' vblank timer with the DRM implementation. The DRM code is identical in concept, but differs in implementation. Vblank timers are covered in vblank helpers and initializer macros, so remove the corresponding hrtimer in struct vkms_output. The vblank timer calls vkms' custom timeout code via handle_vblank_timeout in struct drm_crtc_helper_funcs. Signed-off-by: Thomas Zimmermann Tested-by: Louis Chauvet Reviewed-by: Louis Chauvet Reviewed-by: Javier Martinez Canillas Link: https://lore.kernel.org/r/20250916083816.30275-4-tzimmermann@suse.de Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> Signed-off-by: Sasha Levin commit 60918357456d39f640de25845890614caa44a30a Author: Thomas Zimmermann Date: Tue May 26 21:31:20 2026 +0800 drm/vblank: Add CRTC helpers for simple use cases [ Upstream commit d54dbb5963bdbdf8559903fe2b2343e871adcb30 ] Implement atomic_flush, atomic_enable and atomic_disable of struct drm_crtc_helper_funcs for vblank handling. Driver with no further requirements can use these functions instead of adding their own. Also simplifies the use of vblank timers. The code has been adopted from vkms, which added the funtionality in commit 3a0709928b17 ("drm/vkms: Add vblank events simulated by hrtimers"). v3: - mention vkms (Javier) v2: - fix docs Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Tested-by: Michael Kelley Link: https://lore.kernel.org/r/20250916083816.30275-3-tzimmermann@suse.de Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> Signed-off-by: Sasha Levin commit fa4b91eea4331e7c24aa2d7855583d062a73e4ea Author: Thomas Zimmermann Date: Tue May 26 21:31:19 2026 +0800 drm/vblank: Add vblank timer [ Upstream commit 74afeb8128502a529041a2566febd26053a7be11 ] The vblank timer simulates a vblank interrupt for hardware without support. Rate-limits the display update frequency. DRM drivers for hardware without vblank support apply display updates ASAP. A vblank event informs DRM clients of the completed update. Userspace compositors immediately schedule the next update, which creates significant load on virtualization outputs. Display updates are usually fast on virtualization outputs, as their framebuffers are in regular system memory and there's no hardware vblank interrupt to throttle the update rate. The vblank timer is a HR timer that signals the vblank in software. It limits the update frequency of a DRM driver similar to a hardware vblank interrupt. The timer is not synchronized to the actual vblank interval of the display. The code has been adopted from vkms, which added the funtionality in commit 3a0709928b17 ("drm/vkms: Add vblank events simulated by hrtimers"). The new implementation is part of the existing vblank support, which sets up the timer automatically. Drivers only have to start and cancel the vblank timer as part of enabling and disabling the CRTC. The new vblank helper library provides callbacks for struct drm_crtc_funcs. The standard way for handling vblank is to call drm_crtc_handle_vblank(). Drivers that require additional processing, such as vkms, can init handle_vblank_timeout in struct drm_crtc_helper_funcs to refer to their timeout handler. There's a possible deadlock between drm_crtc_handle_vblank() and hrtimer_cancel(). [1] The implementation avoids to call hrtimer_cancel() directly and instead signals to the timer function to not restart itself. v4: - fix possible race condition between timeout and atomic commit (Michael) v3: - avoid deadlock when cancelling timer (Ville, Lyude) v2: - implement vblank timer entirely in vblank helpers - downgrade overrun warning to debug - fix docs Signed-off-by: Thomas Zimmermann Tested-by: Louis Chauvet Reviewed-by: Louis Chauvet Reviewed-by: Javier Martinez Canillas Tested-by: Michael Kelley Link: https://lore.kernel.org/all/20250510094757.4174662-1-zengheng4@huawei.com/ # [1] Link: https://lore.kernel.org/r/20250916083816.30275-2-tzimmermann@suse.de Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> Signed-off-by: Sasha Levin commit 18a08b87db713d50b4fb0ff3e971c36f6610c666 Author: Sasha Levin Date: Wed May 27 12:43:10 2026 -0400 Revert "ice: Remove jumbo_remove step from TX path" This reverts commit 55500245ec0420df96b2a89444aabf0cff2c60bc. Signed-off-by: Sasha Levin commit 523cd0ea0324202704f24bd27eacd742916c8b8b Author: Sasha Levin Date: Wed May 27 12:43:10 2026 -0400 Revert "ice: fix double-free of tx_buf skb" This reverts commit 7cb19ec8ac087f33bee60f5d6054b284a5b9bb6f. Signed-off-by: Sasha Levin commit 515de0a3b6c12577dcd7ed7c7b2875b18a316935 Author: Niklas Cassel Date: Thu May 14 09:39:02 2026 +0200 ata: libata-scsi: do not needlessly defer commands when using PMP with FBS commit 759e8756da00aa115d504a18155b1d1ee1cc12e8 upstream. The ACS specification does not allow a non-NCQ command to be issued while an NCQ command is outstanding. Commit 0ea84089dbf6 ("ata: libata-scsi: avoid Non-NCQ command starvation") introduced a feature where a deferred non-NCQ command gets issued from a workqueue. The design stores a single non-NCQ command per port. However, when using Port Multipliers (PMPs), specifically PMPs that support FIS-Based Switching (FBS), non-NCQ and NCQ commands can be mixed on the same port, just not for the same link, see e.g. ata_std_qc_defer() which is, and always has operated on a per-link basis. Therefore, move the deferred_qc from struct ata_port to struct ata_link. This way, when using a PMP with FBS, we will not needlessly defer commands to all other links, just because one link issued a non-NCQ command while having an NCQ command outstanding. Only commands for that specific link will be deferred. This is in line with how PMPs with FBS worked before commit 0ea84089dbf6 ("ata: libata-scsi: avoid Non-NCQ command starvation"). Fixes: 0ea84089dbf6 ("ata: libata-scsi: avoid Non-NCQ command starvation") Tested-by: Tommy Kelly Reviewed-by: Damien Le Moal Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit 4e6eada8de381aaa7c8d8abc724327a48e2205de Author: Niklas Cassel Date: Thu May 14 09:39:01 2026 +0200 ata: libata-scsi: do not use the deferred QC feature on PMPs with CBS commit f233124fb36cd57ef09f96d517a38ab4b902e15e upstream. When using Port Multipliers (PMPs) with Command-Based Switching (CBS), you can only issue commands to one link at a time. For PMPs with CBS, there is already code to handle commands being sent to different links in sata_pmp_qc_defer_cmd_switch() using ap->excl_link. sata_sil24 also makes use of ap->excl_link. A user on the list reported that commit 0ea84089dbf6 ("ata: libata-scsi: avoid Non-NCQ command starvation") broke PMPs with CBS. The commit introduced code that stores a deferred qc in ap->deferred_qc, to later be issued via a workqueue. It turns out that this change is incompatible with the existing ap->excl_link handling used by PMPs with CBS. Thus, modify sata_pmp_qc_defer_cmd_switch() and sil24_qc_defer() to return ATA_DEFER_LINK_EXCL, and make sure that the deferred QC handling via workqueue is not used for this return value. This way, PMPs with CBS will work once again. Note that the starvation referenced in commit 0ea84089dbf6 ("ata: libata-scsi: avoid Non-NCQ command starvation") can only happen on libsas ports, and libsas does not support Port Multipliers, thus there is no harm of reverting back to the previous way of deferring commands for PMPs with CBS. Non-libsas ports connected to anything but a PMP with CBS (e.g. a normal drive or a PMP with FBS) will continue using the deferred workqueue, since it does result in lower completion latencies for non-NCQ commands, even though the workqueue is not strictly needed to avoid starvation for non-libsas ports. If we want to modify the scope of the workqueue issuing to also handle PMPs with CBS, then we should ensure that we can save both NCQ and non-NCQ commands in ap->deferred_qc, while also removing the existing PMP CBS handling using ap->excl_link, such that we don't duplicate features. While at it, also add a comment explaining how the ap->excl_link mechanism works. Fixes: 0ea84089dbf6 ("ata: libata-scsi: avoid Non-NCQ command starvation") Tested-by: Tommy Kelly Reported-by: Tommy Kelly Closes: https://lore.kernel.org/linux-ide/ce09cc21-a8e9-4845-b205-35411e22fba9@tkel.ly/ Reviewed-by: Damien Le Moal Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit f207ebd5656e7eadb6b17e23ed763f4c3ac8637c Author: Niklas Cassel Date: Thu May 14 09:39:00 2026 +0200 ata: libata-scsi: do not use the deferred QC feature for ATA_DEFER_PORT commit ce4548807d2e4ae48fd0dbe38865467369877913 upstream. The deferred QC feature was meant to handle mixed NCQ and non-NCQ commands, i.e. for return value ATA_DEFER_LINK. ATA_DEFER_PORT is returned by PATA drivers, but also certain SATA drivers like sata_mv and sata_sil24 that uses ap->excl_link to workaround hardware bugs in these HBAs. Regardless of the reason, using the deferred QC feature for ATA_DEFER_PORT is always wrong, and will break the ap->excl_link usage of the SATA drivers that rely on that feature. Modify ata_scsi_qc_issue() to only use the deferred QC feature when mixing NCQ and non-NCQ commands, i.e. ATA_DEFER_LINK. Fixes: 0ea84089dbf6 ("ata: libata-scsi: avoid Non-NCQ command starvation") Tested-by: Tommy Kelly Reviewed-by: Damien Le Moal Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit 62ee00c1042ca9e0c4c1f9587d49197a6c1c6bac Author: Niklas Cassel Date: Thu May 14 09:38:59 2026 +0200 ata: libata-scsi: improve readability of ata_scsi_qc_issue() commit 360190bd965f93794d5f5685a6de22ce6da2b672 upstream. Improve readability of ata_scsi_qc_issue(). No functional changes. Tested-by: Tommy Kelly Reviewed-by: Damien Le Moal Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit 9d11e4b1db1ce4057251d90ea1a670f2339ab664 Author: Stanimir Varbanov Date: Wed Sep 17 09:32:32 2025 +0300 mfd: bcm2835-pm: Add support for BCM2712 commit 30ed024fb0768e9353f21d1d9e6960b7028acdfa upstream. The BCM2712 SoC has PM block but lacks the "asb" and "rpivid_asb" register spaces, and doesn't need clock(s). Add a compatible string for bcm2712 to allow probe of bcm2835-wdt and bcm2835-power drivers. Signed-off-by: Stanimir Varbanov Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250917063233.1270-4-svarbanov@suse.de Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit ed915823d4692aa4fc9d8ece4746ea1a7269cfde Author: Stanimir Varbanov Date: Fri Oct 31 20:33:09 2025 +0200 arm64: dts: broadcom: bcm2712: Add watchdog DT node commit 37c3a91e9730e274fe2eca9703033ae0f154cb62 upstream. Add watchdog device-tree node for bcm2712 SoC. Signed-off-by: Stanimir Varbanov Link: https://lore.kernel.org/r/20251031183309.1163384-5-svarbanov@suse.de Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit 375d5a17dc8d7668c2479dc4cd329838c58d8e4f Author: Stanimir Varbanov Date: Fri Oct 31 20:33:07 2025 +0200 dt-bindings: soc: bcm: Add bcm2712 compatible commit 34194cb385033656d347ebe45c241e4739a58125 upstream. Add bcm2712-pm compatible and update the bindings to satisfy it's requirements. The PM hardware block inside bcm2712 lacks the "asb" and "rpivid_asb" register ranges and also does not have clocks, update the bindings accordingly. Signed-off-by: Stanimir Varbanov Reviewed-by: Florian Fainelli Acked-by: Conor Dooley Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 91f89c1d83e80417629791fcef6af8140d7d01c8 Author: Asim Viladi Oglu Manizada Date: Sat May 16 21:15:39 2026 +0000 smb: client: reject userspace cifs.spnego descriptions commit 3da1fdf4efbc490041eb4f836bf596201203f8f2 upstream. cifs.spnego key descriptions contain authority-bearing fields such as pid, uid, creduid, and upcall_target that cifs.upcall treats as kernel-originating inputs. However, userspace can also create keys of this type through request_key(2) or add_key(2), allowing those fields to be supplied without CIFS origin. Only accept cifs.spnego descriptions while CIFS is using its private spnego_cred to request the key. Fixes: f1d662a7d5e5 ("[CIFS] Add upcall files for cifs to use spnego/kerberos") Assisted-by: avom-custom-harness:gpt-5.5-qwen3.6-mod-mix Reviewed-by: David Howells Signed-off-by: Asim Viladi Oglu Manizada Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 5da69a65b282d2276de22e5194ba0f88c836170c Author: DaeMyung Kang Date: Tue Apr 28 23:08:56 2026 +0900 ksmbd: close durable scavenger races against m_fp_list lookups [ Upstream commit bf736184d063da1a552ffeff0481813599a182cc ] ksmbd_durable_scavenger() has two related races against any walker that iterates f_ci->m_fp_list, including ksmbd_lookup_fd_inode() (used by ksmbd_vfs_rename) and the share-mode checks in fs/smb/server/smb_common.c. (1) fp->node list-head reuse. Durable-preserved handles can remain linked on f_ci->m_fp_list after session teardown so share-mode checks still see them while the handle is reconnectable. The scavenger collected expired handles by adding fp->node to a local scavenger_list after removing them from the global durable idr. Because fp->node is the same list_head used by m_fp_list, list_add(&fp->node, &scavenger_list) overwrites the m_fp_list links and corrupts both lists. CONFIG_DEBUG_LIST can report this on the share-mode walk path. (2) Refcount race against m_fp_list walkers. The scavenger qualifies an expired durable handle with atomic_read(&fp->refcount) > 1 and fp->conn under global_ft.lock, removes fp from global_ft, then drops global_ft.lock before unlinking fp from m_fp_list and freeing it. During that gap fp is still linked on m_fp_list with f_state == FP_INITED. ksmbd_lookup_fd_inode() under m_lock read calls ksmbd_fp_get() (atomic_inc_not_zero on refcount that is still 1) and takes a live reference; the scavenger then unlinks and frees fp while the holder owns a reference, leading to UAF on the holder's subsequent ksmbd_fd_put() and on any field reads performed by a concurrent share-mode walker that iterates m_fp_list without taking ksmbd_fp_get() (smb_check_perm_dleases-like paths). Fix both: * Stop reusing fp->node as a scavenger-private list node. Remove one expired handle from global_ft under global_ft.lock, take an explicit transient reference, drop the lock, unlink fp->node from m_fp_list under f_ci->m_lock, then drop both the durable lifetime and transient references with atomic_sub_and_test(2, &fp->refcount). If the scavenger is the last putter the close runs there; otherwise an in-flight holder that already raced through the m_fp_list lookup owns the final close via its ksmbd_fd_put() path. The one-at-a-time disposal can rescan the durable idr when multiple handles expire in the same pass, but durable scavenging is a background expiration path and the final full scan recomputes min_timeout before the next wait. * Clear fp->persistent_id inside __ksmbd_remove_durable_fd() right after idr_remove(), so a delayed final close from a holder that snatched fp does not re-issue idr_remove() on a persistent id that idr_alloc_cyclic() in ksmbd_open_durable_fd() may have already handed out to a brand-new durable handle. * Bypass the per-conn open_files_count decrement in __put_fd_final() when fp is detached from any session table (fp->conn cleared by session_fd_check() at durable preserve -- paired with the volatile_id clear at unpublish, so checking fp->conn alone is sufficient). The walker that owns the final close runs from an unrelated work->conn whose stats.open_files_count never tracked this durable fp; without this guard the holder would underflow that unrelated counter. The two races are folded into one patch because patch (1) alone cleans up the corrupted list but leaves a deterministic UAF window for m_fp_list walkers that the transient-reference and persistent_id discipline in (2) close; bisecting onto an intermediate state would land on a UAF that pre-patch chaos merely made less reproducible. Validation: * CONFIG_DEBUG_LIST coverage for the list_head reuse path. * KASAN-enabled direct SMB2 durable-handle coverage that exercised ksmbd_durable_scavenger() and non-NULL ksmbd_lookup_fd_inode() returns while durable handles expired under concurrent rename lookups, with no KASAN, UAF, list-corruption, ODEBUG, or WARNING reports. * checkpatch --strict * make -j$(nproc) M=fs/smb/server Fixes: d484d621d40f ("ksmbd: add durable scavenger timer") Signed-off-by: DaeMyung Kang Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit aae4a47073b12c23eb1d2c5401bda442fbe27bd1 Author: Vladimir Yakovlev Date: Tue Mar 3 01:20:17 2026 +0300 spi: spi-dw-dma: fix print error log when wait finish transaction [ Upstream commit 3b46d61890632c8f8b117147b6923bff4b42ccb7 ] If an error occurs, the device may not have a current message. In this case, the system will crash. In this case, it's better to use dev from the struct ctlr (struct spi_controller*). Signed-off-by: Vladimir Yakovlev Link: https://patch.msgid.link/20260302222017.992228-2-vovchkir@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e8ec80430bfa520e7352155d6ac632e527cba7aa Author: Xiang Mei Date: Fri Mar 27 23:30:00 2026 -0700 bridge: mrp: reject zero test interval to avoid OOM panic [ Upstream commit fa6e24963342de4370e3a3c9af41e38277b74cf3 ] br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied interval value from netlink without validation. When interval is 0, usecs_to_jiffies(0) yields 0, causing the delayed work (br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule itself with zero delay. This creates a tight loop on system_percpu_wq that allocates and transmits MRP test frames at maximum rate, exhausting all system memory and causing a kernel panic via OOM deadlock. The same zero-interval issue applies to br_mrp_start_in_test_parse() for interconnect test frames. Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both IFLA_BRIDGE_MRP_START_TEST_INTERVAL and IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the netlink attribute parsing layer before the value ever reaches the workqueue scheduling code. This is consistent with how other bridge subsystems (br_fdb, br_mst) enforce range constraints on netlink attributes. Fixes: 20f6a05ef635 ("bridge: mrp: Rework the MRP netlink interface") Fixes: 7ab1748e4ce6 ("bridge: mrp: Extend MRP netlink interface for configuring MRP interconnect") Reported-by: Weiming Shi Signed-off-by: Xiang Mei Acked-by: Nikolay Aleksandrov Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260328063000.1845376-1-xmei5@asu.edu Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 0638bf16b7a73a2fe63624bd0d16d9fd904805c3 Author: Juri Lelli Date: Mon Mar 2 16:45:40 2026 +0100 sched/deadline: Fix missing ENQUEUE_REPLENISH during PI de-boosting [ Upstream commit d658686a1331db3bb108ca079d76deb3208ed949 ] Running stress-ng --schedpolicy 0 on an RT kernel on a big machine might lead to the following WARNINGs (edited). sched: DL de-boosted task PID 22725: REPLENISH flag missing WARNING: CPU: 93 PID: 0 at kernel/sched/deadline.c:239 dequeue_task_dl+0x15c/0x1f8 ... (running_bw underflow) Call trace: dequeue_task_dl+0x15c/0x1f8 (P) dequeue_task+0x80/0x168 deactivate_task+0x24/0x50 push_dl_task+0x264/0x2e0 dl_task_timer+0x1b0/0x228 __hrtimer_run_queues+0x188/0x378 hrtimer_interrupt+0xfc/0x260 ... The problem is that when a SCHED_DEADLINE task (lock holder) is changed to a lower priority class via sched_setscheduler(), it may fail to properly inherit the parameters of potential DEADLINE donors if it didn't already inherit them in the past (shorter deadline than donor's at that time). This might lead to bandwidth accounting corruption, as enqueue_task_dl() won't recognize the lock holder as boosted. The scenario occurs when: 1. A DEADLINE task (donor) blocks on a PI mutex held by another DEADLINE task (holder), but the holder doesn't inherit parameters (e.g., it already has a shorter deadline) 2. sched_setscheduler() changes the holder from DEADLINE to a lower class while still holding the mutex 3. The holder should now inherit DEADLINE parameters from the donor and be enqueued with ENQUEUE_REPLENISH, but this doesn't happen Fix the issue by introducing __setscheduler_dl_pi(), which detects when a DEADLINE (proper or boosted) task gets setscheduled to a lower priority class. In case, the function makes the task inherit DEADLINE parameters of the donoer (pi_se) and sets ENQUEUE_REPLENISH flag to ensure proper bandwidth accounting during the next enqueue operation. Fixes: 2279f540ea7d ("sched/deadline: Fix priority inheritance with multiple scheduling classes") Reported-by: Bruno Goncalves Signed-off-by: Juri Lelli Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260302-upstream-fix-deadline-piboost-b4-v3-1-6ba32184a9e0@redhat.com Signed-off-by: Sasha Levin commit 3f0543bdf446a62b7293c445377a1e5741817dfd Author: Peter Zijlstra Date: Wed Oct 30 13:43:43 2024 +0100 sched: Employ sched_change guards [ Upstream commit e9139f765ac7048cadc9981e962acdf8b08eabf3 ] As proposed a long while ago -- and half done by scx -- wrap the scheduler's 'change' pattern in a guard helper. Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Juri Lelli Acked-by: Tejun Heo Acked-by: Vincent Guittot Stable-dep-of: d658686a1331 ("sched/deadline: Fix missing ENQUEUE_REPLENISH during PI de-boosting") Signed-off-by: Sasha Levin commit dc184ac2f0ba77ae19725ee06ad3ab36bb9d1f61 Author: Davidlohr Bueso Date: Thu Feb 19 16:16:17 2026 -0800 cxl/mbox: validate payload size before accessing contents in cxl_payload_from_user_allowed() [ Upstream commit 60b5d1f68338aff2c5af0113f04aefa7169c50c2 ] cxl_payload_from_user_allowed() casts and dereferences the input payload without first verifying its size. When a raw mailbox command is sent with an undersized payload (ie: 1 byte for CXL_MBOX_OP_CLEAR_LOG, which expects a 16-byte UUID), uuid_equal() reads past the allocated buffer, triggering a KASAN splat: BUG: KASAN: slab-out-of-bounds in memcmp+0x176/0x1d0 lib/string.c:683 Read of size 8 at addr ffff88810130f5c0 by task syz.1.62/2258 CPU: 2 UID: 0 PID: 2258 Comm: syz.1.62 Not tainted 6.19.0-dirty #3 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xab/0xe0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xce/0x650 mm/kasan/report.c:482 kasan_report+0xce/0x100 mm/kasan/report.c:595 memcmp+0x176/0x1d0 lib/string.c:683 uuid_equal include/linux/uuid.h:73 [inline] cxl_payload_from_user_allowed drivers/cxl/core/mbox.c:345 [inline] cxl_mbox_cmd_ctor drivers/cxl/core/mbox.c:368 [inline] cxl_validate_cmd_from_user drivers/cxl/core/mbox.c:522 [inline] cxl_send_cmd+0x9c0/0xb50 drivers/cxl/core/mbox.c:643 __cxl_memdev_ioctl drivers/cxl/core/memdev.c:698 [inline] cxl_memdev_ioctl+0x14f/0x190 drivers/cxl/core/memdev.c:713 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa8/0x330 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fdaf331ba79 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fdaf1d77038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fdaf3585fa0 RCX: 00007fdaf331ba79 RDX: 00002000000001c0 RSI: 00000000c030ce02 RDI: 0000000000000003 RBP: 00007fdaf33749df R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fdaf3586038 R14: 00007fdaf3585fa0 R15: 00007ffced2af768 Add 'in_size' parameter to cxl_payload_from_user_allowed() and validate the payload is large enough. Fixes: 6179045ccc0c ("cxl/mbox: Block immediate mode in SET_PARTITION_INFO command") Fixes: 206f9fa9d555 ("cxl/mbox: Add Clear Log mailbox command") Signed-off-by: Davidlohr Bueso Reviewed-by: Alison Schofield Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260220001618.963490-2-dave@stgolabs.net Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit da3d241c5b925f17a9d8051d7a9e0d454d8e01f6 Author: Luis Henriques Date: Mon Feb 16 14:48:30 2026 +0000 fuse: fix uninit-value in fuse_dentry_revalidate() commit 5a6baf204610589f8a5b5a1cd69d1fe661d9d3cd upstream. fuse_dentry_revalidate() may be called with a dentry that didn't had ->d_time initialised. The issue was found with KMSAN, where lookup_open() calls __d_alloc(), followed by d_revalidate(), as shown below: ===================================================== BUG: KMSAN: uninit-value in fuse_dentry_revalidate+0x150/0x13d0 fs/fuse/dir.c:394 fuse_dentry_revalidate+0x150/0x13d0 fs/fuse/dir.c:394 d_revalidate fs/namei.c:1030 [inline] lookup_open fs/namei.c:4405 [inline] open_last_lookups fs/namei.c:4583 [inline] path_openat+0x1614/0x64c0 fs/namei.c:4827 do_file_open+0x2aa/0x680 fs/namei.c:4859 [...] Uninit was created at: slab_post_alloc_hook mm/slub.c:4466 [inline] slab_alloc_node mm/slub.c:4788 [inline] kmem_cache_alloc_lru_noprof+0x382/0x1280 mm/slub.c:4807 __d_alloc+0x55/0xa00 fs/dcache.c:1740 d_alloc_parallel+0x99/0x2740 fs/dcache.c:2604 lookup_open fs/namei.c:4398 [inline] open_last_lookups fs/namei.c:4583 [inline] path_openat+0x135f/0x64c0 fs/namei.c:4827 do_file_open+0x2aa/0x680 fs/namei.c:4859 [...] ===================================================== Reported-by: syzbot+fdebb2dc960aa56c600a@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/69917e0d.050a0220.340abe.02e2.GAE@google.com Fixes: 2396356a945b ("fuse: add more control over cache invalidation behaviour") Signed-off-by: Luis Henriques Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 488d2c76bd9f78433a70690d1054bfae3d39a407 Author: Eder Zulian Date: Fri Apr 10 14:55:50 2026 +0200 iommu/amd: Remove latent out-of-bounds access in IOMMU debugfs [ Upstream commit 8dfd3d8d74435344ee8dc9237596959c8b2a6cbe ] In iommu_mmio_write() and iommu_capability_write(), the variables dbg_mmio_offset and dbg_cap_offset are declared as int. However, they are populated using kstrtou32_from_user(). If a user provides a sufficiently large value, it can become a negative integer. Prior to this patch, the AMD IOMMU debugfs implementation was already protected by different mechanisms. 1. #define OFS_IN_SZ 8 ensures the user string <= 8 bytes, so e.g. 0xffffffff isn't a valid input. if (cnt > OFS_IN_SZ) return -EINVAL; 2. Implicit type promotion in iommu_mmio_write(), dbg_mmio_offset is int and iommu->mmio_phys_end is u64 if (dbg_mmio_offset > iommu->mmio_phys_end - sizeof(u64)) return -EINVAL; 3. The show handlers would currently catch the negative number and refuse to perform the read. Replace kstrtou32_from_user() with kstrtos32_from_user() to parse the input, and check for negative values to explicitly prevent out-of-bounds memory accesses directly in iommu_mmio_write() and iommu_capability_write(). Signed-off-by: Eder Zulian Fixes: 7a4ee419e8c1 ("iommu/amd: Add debugfs support to dump IOMMU MMIO registers") Cc: stable@vger.kernel.org Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit b9a4184271b9c10144b3490a18f59a756a73542c Author: Guanghui Feng Date: Thu Mar 19 15:37:54 2026 +0800 iommu/amd: Fix illegal cap/mmio access in IOMMU debugfs [ Upstream commit 0e59645683b7b6fa20eceb21a6f420e4f7412943 ] In the current AMD IOMMU debugfs, when multiple processes simultaneously access the IOMMU mmio/cap registers using the IOMMU debugfs, illegal access issues can occur in the following execution flow: 1. CPU1: Sets a valid access address using iommu_mmio/capability_write, and verifies the access address's validity in iommu_mmio/capability_show 2. CPU2: Sets an invalid address using iommu_mmio/capability_write 3. CPU1: accesses the IOMMU mmio/cap registers based on the invalid address, resulting in an illegal access. This patch modifies the execution process to first verify the address's validity and then access it based on the same address, ensuring correctness and robustness. Signed-off-by: Guanghui Feng Signed-off-by: Joerg Roedel Stable-dep-of: 8dfd3d8d7443 ("iommu/amd: Remove latent out-of-bounds access in IOMMU debugfs") Signed-off-by: Sasha Levin commit 814326e86e929b865020ff44f4576dbdfe3f7ff3 Author: Gustavo Sousa Date: Fri May 22 15:47:22 2026 -0300 drm/xe/hdcp: Add NULL check for media_gt in intel_hdcp_gsc_check_status() commit 60a1e131a811b68703da58fd805ab359b704ab03 upstream. When media GT is disabled via configfs, there is no allocation for media_gt, which is kept as NULL. In such scenario, intel_hdcp_gsc_check_status() results in a kernel pagefault error due to >->uc.gsc being evaluated as an invalid memory address. Fix that by introducing a NULL check on media_gt and bailing out early if so. While at it, also drop the NULL check for gsc, since it can't be NULL if media_gt is not NULL. v2: - Get address for gsc only after checking that gt is not NULL. (Shuicheng) - Drop the NULL check for gsc. (Shuicheng) v3: - Add "Fixes" and "Cc: " tags. (Matt) Fixes: 4af50beb4e0f ("drm/xe: Use gsc_proxy_init_done to check proxy status") Cc: # v6.10+ Reviewed-by: Matt Roper Reviewed-by: Shuicheng Lin Link: https://patch.msgid.link/20260416-check-for-null-media_gt-in-intel_hdcp_gsc_check_status-v2-1-9adb9fd3b621@intel.com Signed-off-by: Gustavo Sousa (cherry picked from commit bfaf87e84ca3ca3f6e275f9ae56da47a8b55ffd1) Signed-off-by: Matthew Brost Signed-off-by: Sasha Levin commit e469a636f608b08e0eff7b6e5f8c79f5bbdbca65 Author: Alexandre Frade Date: Sat May 23 18:18:30 2026 +0000 Linux 6.18.33-xanmod1 Signed-off-by: Alexandre Frade commit b1dc0d89228b68797d0cd47330672a0f8f11c389 Author: Oleksandr Natalenko Date: Mon Oct 13 08:33:45 2025 +0200 tcp_bbr: v3: update TCP 'bbr' congestion control module to BBRv3 [v6.18.33+] Original patchset Link: https://github.com/google/bbr/tree/v3 Signed-off-by: Oleksandr Natalenko Signed-off-by: Alexandre Frade commit bddb6a8ebea6b8a5797af648028bb87f04222ec0 Merge: ac95f57c40f3 83657f418961 Author: Alexandre Frade Date: Sat May 23 17:54:25 2026 +0000 Merge tag 'v6.18.33' into 6.18 This is the 6.18.33 stable release commit ac95f57c40f339f50855d742a437e804c16a6e37 Author: Alexandre Frade Date: Sat May 23 17:24:34 2026 +0000 Revert "tcp_bbr: v3: update TCP 'bbr' congestion control module to BBRv3 [v6.18.14+]" This reverts commit 4f4158992d8c335f5c9691a92175cabdde577320. commit 83657f4189612e5cbcabc3058acd36c0bd120729 Author: Greg Kroah-Hartman Date: Sat May 23 13:07:21 2026 +0200 Linux 6.18.33 Link: https://lore.kernel.org/r/20260520162134.554764788@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Wentao Guan Tested-by: Pavel Machek (CIP) Tested-by: Jon Hunter Tested-by: Peter Schneider Tested-by: Mark Brown Tested-by: Brett A C Sheffield Tested-by: Ron Economos Signed-off-by: Greg Kroah-Hartman commit 664736cc1f95198438aa69ae82df9f42c64d0e1c Author: David Howells Date: Tue May 12 13:33:45 2026 +0100 netfs: Fix potential uninitialised var in netfs_extract_user_iter() commit 7e3d8db899d54af39fafb2eb3392b0cdae9973b5 upstream. In netfs_extract_user_iter(), if it's given a zero-length iterator, it will fall through the loop without setting ret, and so the error handling behaviour will be undefined, depending on whether ret happens to be negative. The value of ret then propagates back up the callstack. Fix this by presetting ret to 0. Fixes: 85dd2c8ff368 ("netfs: Add a function to extract a UBUF or IOVEC into a BVEC iterator") Closes: https://sashiko.dev/#/patchset/20260414082004.3756080-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260512123404.719402-9-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 Signed-off-by: Greg Kroah-Hartman commit e9a23ec9461e9e76f0f8e02821627478a576b5ee Author: Venkat Rao Bagalkote Date: Fri Apr 10 16:24:04 2026 +0530 selftests/bpf: Remove test_access_variable_array commit aacee214d57636fa1f63007c65f333b5ea75a7a0 upstream. test_access_variable_array relied on accessing struct sched_domain::span to validate variable-length array handling via BTF. Recent scheduler refactoring removed or hid this field, causing the test to fail to build. Given that this test depends on internal scheduler structures that are subject to refactoring, and equivalent variable-length array coverage already exists via bpf_testmod-based tests, remove test_access_variable_array entirely. Link: https://lore.kernel.org/all/177434340048.1647592.8586759362906719839.tip-bot2@tip-bot2/ Signed-off-by: Venkat Rao Bagalkote Tested-by: Naveen Kumar Thummalapenta Link: https://lore.kernel.org/r/20260410105404.91126-1-venkat88@linux.ibm.com Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit ff375cc75f9167168db38e0464a482d5fbc8d81d Author: Hyunwoo Kim Date: Sat May 16 07:28:53 2026 +0900 net: skbuff: propagate shared-frag marker through frag-transfer helpers commit 48f6a5356a33dd78e7144ae1faef95ffc990aae0 upstream. Two frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) fail to propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags when moving frags from source to destination. __pskb_copy_fclone() defers the rest of the shinfo metadata to skb_copy_header() after copying frag descriptors, but that helper only carries over gso_{size,segs, type} and never touches skb_shinfo()->flags; skb_shift() moves frag descriptors directly and leaves flags untouched. As a result, the destination skb keeps a reference to the same externally-owned or page-cache-backed pages while reporting skb_has_shared_frag() as false. The mismatch is harmful in any in-place writer that uses skb_has_shared_frag() to decide whether shared pages must be detoured through skb_cow_data(). ESP input is one such writer (esp4.c, esp6.c), and a single nft 'dup to ' rule -- or any other nf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()'d skb in esp_input() with the marker stripped, letting an unprivileged user write into the page cache of a root-owned read-only file via authencesn-ESN stray writes. Set SKBFL_SHARED_FRAG on the destination whenever frag descriptors were actually moved from the source. skb_copy() and skb_copy_expand() share skb_copy_header() too but linearize all paged data into freshly allocated head storage and emerge with nr_frags == 0, so skb_has_shared_frag() returns false on its own; they need no change. The same omission exists in skb_gro_receive() and skb_gro_receive_list(). The former moves the incoming skb's frag descriptors into the accumulator's last sub-skb via two paths (a direct frag-move loop and the head_frag + memcpy path); the latter chains the incoming skb whole onto p's frag_list. Downstream skb_segment() reads only skb_shinfo(p)->flags, and skb_segment_list() reuses each sub-skb's shinfo as the nskb -- both p and lp must carry the marker. The same omission also exists in tcp_clone_payload(), which builds an MTU probe skb by moving frag descriptors from skbs on sk_write_queue into a freshly allocated nskb. The helper falls into the same family and warrants the same fix for consistency; no TCP TX-side in-place writer is currently known to reach a user page through this gap, but a future consumer depending on the marker would regress silently. The same omission exists in skb_segment(): the per-iteration flag merge takes only head_skb's flag, and the inner switch that rebinds frag_skb to list_skb on head_skb-frags exhaustion does not fold the new frag_skb's flag into nskb. Fold frag_skb's flag at both sites so segments drawing frags from frag_list members carry the marker. Fixes: cef401de7be8 ("net: fix possible wrong checksum generation") Fixes: f4c50a4034e6 ("xfrm: esp: avoid in-place decrypt on shared skb frags") Suggested-by: Sabrina Dubroca Suggested-by: Sultan Alsawaf Suggested-by: Ben Hutchings Suggested-by: Lin Ma Suggested-by: Jingguo Tan Suggested-by: Aaron Esau Cc: stable@vger.kernel.org Signed-off-by: Hyunwoo Kim Tested-by: Rajat Gupta Link: https://patch.msgid.link/ageeJfJHwgzmKXbh@v4bel Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 3bd9e113d50034db99d7ef69fd8e5242d15e414a Author: William Bowling Date: Wed May 13 04:16:35 2026 +0000 net: skbuff: preserve shared-frag marker during coalescing commit f84eca5817390257cef78013d0112481c503b4a3 upstream. skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors. Fixes: cef401de7be8 ("net: fix possible wrong checksum generation") Fixes: f4c50a4034e6 ("xfrm: esp: avoid in-place decrypt on shared skb frags") Signed-off-by: William Bowling Reviewed-by: Eric Dumazet Tested-by: Jiayuan Chen Link: https://patch.msgid.link/20260513041635.1289541-1-vakzz@zellic.io Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 640e37f58f991546a87540d067279c2c1fa9fe51 Author: Allison Henderson Date: Tue May 5 16:43:36 2026 -0700 net/rds: reset op_nents when zerocopy page pin fails commit e174929793195e0cd6a4adb0cad731b39f9019b4 upstream. When iov_iter_get_pages2() fails in rds_message_zcopy_from_user(), the pinned pages are released with put_page(), and rm->data.op_mmp_znotifier is cleared. But we fail to properly clear rm->data.op_nents. Later when rds_message_purge() is called from rds_sendmsg() the cleanup loop iterates over the incorrectly non zero number of op_nents and frees them again. Fix this by properly resetting op_nents when it should be in rds_message_zcopy_from_user(). Fixes: 0cebaccef3ac ("rds: zerocopy Tx support.") Signed-off-by: Allison Henderson Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260505234336.2132721-1-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6bf4253af8142a47aa66cb1ffbe5e8ad7065a32a Author: Johan Hovold Date: Wed May 20 09:11:28 2026 -0400 spi: sifive: fix controller deregistration [ Upstream commit 0f25236694a2854627c1597465a071e6bb6fe572 ] Make sure to deregister the controller before disabling underlying resources like interrupts during driver unbind. Note that clocks were also disabled before the recent commit 140039c23aca ("spi: sifive: Simplify clock handling with devm_clk_get_enabled()"). Fixes: 484a9a68d669 ("spi: sifive: Add driver for the SiFive SPI controller") Cc: stable@vger.kernel.org # 5.1 Cc: Yash Shah Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-15-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 27fcf3dd04df2defeff4c00ff3d2a2ae4b3d4831 Author: Pei Xiao Date: Wed May 20 09:11:27 2026 -0400 spi: sifive: Simplify clock handling with devm_clk_get_enabled() [ Upstream commit 140039c23aca067b9ff0242e3c0ce96276bb95f3 ] Replace devm_clk_get() followed by clk_prepare_enable() with devm_clk_get_enabled() for the bus clock. This reduces boilerplate code and error handling, as the managed API automatically disables the clock when the device is removed or if probe fails. Remove the now-unnecessary clk_disable_unprepare() calls from the probe error path and the remove callback. Adjust the error handling to use the existing put_host label. Signed-off-by: Pei Xiao Link: https://patch.msgid.link/73d0d8ecb4e1af5a558d6a7866c0f886d94fe3d1.1773885292.git.xiaopei01@kylinos.cn Signed-off-by: Mark Brown Stable-dep-of: 0f25236694a2 ("spi: sifive: fix controller deregistration") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fac9cfad2f90fa21d81327028c7125889442c005 Author: Chao Yu Date: Tue May 19 07:53:09 2026 -0400 f2fs: fix false alarm of lockdep on cp_global_sem lock [ Upstream commit 6a5e3de9c2bb0b691d16789a5d19e9276a09b308 ] lockdep reported a potential deadlock: a) TCMU device removal context: - call del_gendisk() to get q->q_usage_counter - call start_flush_work() to get work_completion of wb->dwork b) f2fs writeback context: - in wb_workfn(), which holds work_completion of wb->dwork - call f2fs_balance_fs() to get sbi->gc_lock c) f2fs vfs_write context: - call f2fs_gc() to get sbi->gc_lock - call f2fs_write_checkpoint() to get sbi->cp_global_sem d) f2fs mount context: - call recover_fsync_data() to get sbi->cp_global_sem - call f2fs_check_and_fix_write_pointer() to call blkdev_report_zones() that goes down to blk_mq_alloc_request and get q->q_usage_counter Original callstack is in Closes tag. However, I think this is a false alarm due to before mount returns successfully (context d), we can not access file therein via vfs_write (context c). Let's introduce per-sb cp_global_sem_key, and assign the key for cp_global_sem, so that lockdep can recognize cp_global_sem from different super block correctly. A lot of work are done by Shin'ichiro Kawasaki, thanks a lot for the work. Fixes: c426d99127b1 ("f2fs: Check write pointer consistency of open zones") Cc: stable@kernel.org Reported-and-tested-by: Shin'ichiro Kawasaki Closes: https://lore.kernel.org/linux-f2fs-devel/20260218125237.3340441-1-shinichiro.kawasaki@wdc.com Signed-off-by: Shin'ichiro Kawasaki Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim [ adapted context to use plain `init_f2fs_rwsem` instead of mainline's `init_f2fs_rwsem_trace` macro ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a4a0340d20abe7c2b9c5c310db221045acef2652 Author: Tejun Heo Date: Mon May 18 07:48:25 2026 -0400 sched_ext: Pass held rq to SCX_CALL_OP() for core_sched_before [ Upstream commit 4155fb489fa175ec74eedde7d02219cf2fe74303 ] scx_prio_less() runs from core-sched's pick_next_task() path with rq locked but invokes ops.core_sched_before() with NULL locked_rq, leaving scx_locked_rq_state NULL. If the BPF callback calls a kfunc that re-acquires rq based on scx_locked_rq() - e.g. scx_bpf_cpuperf_set(cpu) - it re-acquires the already-held rq. Pass task_rq(a). Fixes: 7b0888b7cc19 ("sched_ext: Implement core-sched support") Cc: stable@vger.kernel.org # v6.12+ Reported-by: Chris Mason Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi [ adapted call to use stable's single `sch`/`SCX_KF_REST` mask and `scx_rq_bypassing(task_rq(a))` signature ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 255c3998dae8c492ec3cc6ac550f27b233161e02 Author: Tejun Heo Date: Sun May 17 22:11:00 2026 -0400 sched_ext: Guard scx_dsq_move() against NULL kit->dsq after failed iter_new [ Upstream commit 4fda9f0e7c950da4fe03cedeb2ac818edf5d03e9 ] bpf_iter_scx_dsq_new() clears kit->dsq on failure and bpf_iter_scx_dsq_{next,destroy}() guard against that. scx_dsq_move() doesn't - it dereferences kit->dsq immediately, so a BPF program that calls scx_bpf_dsq_move[_vtime]() after a failed iter_new oopses the kernel. Return false if kit->dsq is NULL. Fixes: 4c30f5ce4f7a ("sched_ext: Implement scx_bpf_dispatch[_vtime]_from_dsq()") Cc: stable@vger.kernel.org # v6.12+ Reported-by: Chris Mason Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi [ dropped upstream `sch = src_dsq->sched` reordering since stable initializes `sch` from `scx_root` instead ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a3c44e77f3796f62b890c8a72eb1161efd525a8b Author: Dapeng Mi Date: Sun May 17 21:23:15 2026 -0400 perf/x86/intel: Disable PMI for self-reloaded ACR events [ Upstream commit 1271aeccc307066315b2d3b0d5af2510e27018b5 ] On platforms with Auto Counter Reload (ACR) support, such as NVL, a "NMI received for unknown reason 30" warning is observed when running multiple events in a group with ACR enabled: $ perf record -e '{instructions/period=20000,acr_mask=0x2/u,\ cycles/period=40000,acr_mask=0x3/u}' ./test The warning occurs because the Performance Monitoring Interrupt (PMI) is enabled for the self-reloaded event (the cycles event in this case). According to the Intel SDM, the overflow bit (IA32_PERF_GLOBAL_STATUS.PMCn_OVF) is never set for self-reloaded events. Since the bit is not set, the perf NMI handler cannot identify the source of the interrupt, leading to the "unknown reason" message. Furthermore, enabling PMI for self-reloaded events is unnecessary and can lead to extraneous records that pollute the user's requested data. Disable the interrupt bit for all events configured with ACR self-reload. Fixes: ec980e4facef ("perf/x86/intel: Support auto counter reload") Reported-by: Andi Kleen Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260430002558.712334-4-dapeng1.mi@linux.intel.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b6437e6f8f3df87b3fea6d808775d88ee4b5b437 Author: Qu Wenruo Date: Sat May 16 15:09:07 2026 -0400 btrfs: do not mark inode incompressible after inline attempt fails [ Upstream commit 2e0e3716c7b6f8d71df2fbe709b922e54700f71b ] [BUG] The following sequence will set the file with nocompress flag: # mkfs.btrfs -f $dev # mount $dev $mnt -o max_inline=4,compress # xfs_io -f -c "pwrite 0 2k" -c sync $mnt/foobar The inode will have NOCOMPRESS flag, even if the content itself (all 0xcd) can still be compressed very well: item 4 key (257 INODE_ITEM 0) itemoff 15879 itemsize 160 generation 9 transid 10 size 2097152 nbytes 1052672 block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0 sequence 257 flags 0x8(NOCOMPRESS) Please note that, this behavior is there even before commit 59615e2c1f63 ("btrfs: reject single block sized compression early"). [CAUSE] At compress_file_range(), after btrfs_compress_folios() call, we try making an inlined extent by calling cow_file_range_inline(). But cow_file_range_inline() calls can_cow_file_range_inline() which has more accurate checks on if the range can be inlined. One of the user configurable conditions is the "max_inline=" mount option. If that value is set low (like the example, 4 bytes, which cannot store any header), or the compressed content is just slightly larger than 2K (the default value, meaning a 50% compression ratio), cow_file_range_inline() will return 1 immediately. And since we're here only to try inline the compressed data, the range is no larger than a single fs block. Thus compression is never going to make it a win, we fall back to marking the inode incompressible unavoidably. [FIX] Just add an extra check after inline attempt, so that if the inline attempt failed, do not set the nocompress flag. As there is no way to remove that flag, and the default 50% compression ratio is way too strict for the whole inode. CC: stable@vger.kernel.org # 6.12+ Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2647b8fe2f1f85194092a94d7ca0c4679795da87 Author: Piyush Sachdeva Date: Fri May 15 17:35:02 2026 -0400 smb: client: Use FullSessionKey for AES-256 encryption key derivation [ Upstream commit 5be7a0cef3229fb3b63a07c0d289daf752545424 ] When Kerberos authentication is used with AES-256 encryption (AES-256-CCM or AES-256-GCM), the SMB3 encryption and decryption keys must be derived using the full session key (Session.FullSessionKey) rather than just the first 16 bytes (Session.SessionKey). Per MS-SMB2 section 3.2.5.3.1, when Connection.Dialect is "3.1.1" and Connection.CipherId is AES-256-CCM or AES-256-GCM, Session.FullSessionKey must be set to the full cryptographic key from the GSS authentication context. The encryption and decryption key derivation (SMBC2SCipherKey, SMBS2CCipherKey) must use this FullSessionKey as the KDF input. The signing key derivation continues to use Session.SessionKey (first 16 bytes) in all cases. Previously, generate_key() hardcoded SMB2_NTLMV2_SESSKEY_SIZE (16) as the HMAC-SHA256 key input length for all derivations. When Kerberos with AES-256 provides a 32-byte session key, the KDF for encryption/decryption was using only the first 16 bytes, producing keys that did not match the server's, causing mount failures with sec=krb5 and require_gcm_256=1. Add a full_key_size parameter to generate_key() and pass the appropriate size from generate_smb3signingkey(): - Signing: always SMB2_NTLMV2_SESSKEY_SIZE (16 bytes) - Encryption/Decryption: ses->auth_key.len when AES-256, otherwise 16 Also fix cifs_dump_full_key() to report the actual session key length for AES-256 instead of hardcoded CIFS_SESS_KEY_SIZE, so that userspace tools like Wireshark receive the correct key for decryption. Cc: Reviewed-by: Bharath SM Signed-off-by: Piyush Sachdeva Signed-off-by: Piyush Sachdeva Signed-off-by: Steve French Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 244575d0c695862bfd59ea3b1754c1e7f88ed454 Author: David Carlier Date: Fri May 15 11:36:49 2026 -0400 eventfs: Use list_add_tail_rcu() for SRCU-protected children list [ Upstream commit f67950b2887fa10df50c4317a1fe98a65bc6875b ] Commit d2603279c7d6 ("eventfs: Use list_del_rcu() for SRCU protected list variable") converted the removal side to pair with the list_for_each_entry_srcu() walker in eventfs_iterate(). The insertion in eventfs_create_dir() was left as a plain list_add_tail(), which on weakly-ordered architectures can expose a new entry to the SRCU reader before its list pointers and fields are observable. Use list_add_tail_rcu() so the publication pairs with the existing list_del_rcu() and list_for_each_entry_srcu(). Fixes: 43aa6f97c2d0 ("eventfs: Get rid of dentry pointers without refcounts") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260418152251.199343-1-devnexen@gmail.com Signed-off-by: David Carlier Signed-off-by: Steven Rostedt [ adapted scoped_guard(mutex, &eventfs_mutex) block to explicit mutex_lock()/mutex_unlock() pair ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4fa42a249e8cd6ed17aea04e5695b6e9001f2433 Author: Ashutosh Desai Date: Wed Apr 15 05:00:00 2026 +0000 drm/v3d: Reject empty multisync extension to prevent infinite loop commit fb44d589bf3148e13452185a6e772a7efbf2d684 upstream. v3d_get_extensions() walks a userspace-provided singly-linked list of ioctl extensions without any bound on the chain length. A local user can craft a self-referential extension (ext->next == &ext) with zero in_sync_count and out_sync_count, which bypasses the existing duplicate- extension guard: if (se->in_sync_count || se->out_sync_count) return -EINVAL; The guard never fires because v3d_get_multisync_post_deps() returns immediately when count is zero, leaving both fields at zero on every iteration. The result is an infinite loop in kernel context, blocking the calling thread and pegging a CPU core indefinitely. Fix this by rejecting a multisync extension where both in_sync_count and out_sync_count are zero in v3d_get_multisync_submit_deps(). An empty multisync carries no synchronization information and serves no useful purpose, so returning -EINVAL for such an extension is the correct defense against this attack vector. Fixes: e4165ae8304e ("drm/v3d: add multiple syncobjs support") Cc: stable@vger.kernel.org Signed-off-by: Ashutosh Desai Link: https://patch.msgid.link/20260415050000.3816128-1-ashutoshdesai993@gmail.com Signed-off-by: Maíra Canal Signed-off-by: Greg Kroah-Hartman commit 4e003e2fb6d3f814a535d8fd44b17146e1c701a5 Author: Johan Hovold Date: Fri May 8 16:44:46 2026 +0200 drm/gma500/oaktrail_lvds: fix i2c adapter leaks on init commit 84d1c9b416d54afe760ca4c378bd95c89261254c upstream. The LVDS init code looks up an I2C adapter using i2c_get_adapter() and tries to read the EDID before falling back to allocating and registering its own adapter. Make sure to drop the references taken by i2c_get_adapter() when falling back to allocating an adapter as well as on late errors to allow the looked up adapter to be deregistered. Fixes: 1b082ccf5901 ("gma500: Add Oaktrail support") Cc: stable@vger.kernel.org # 3.3 Signed-off-by: Johan Hovold Signed-off-by: Patrik Jakobsson Link: https://patch.msgid.link/20260508144446.59722-4-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit ab9256936b58eb178caddcf5b5b1638f079909d2 Author: Johan Hovold Date: Fri May 8 16:44:45 2026 +0200 drm/gma500/oaktrail_lvds: fix hang on init failure commit 657a091ab6d01d0091b77660c75cfed573c9a53e upstream. The LVDS init code looks up an I2C adapter using i2c_get_adapter() and tries to read the EDID before falling back to allocating and registering its own adapter. The error handling does not separate these cases so on a late init failure it will try to deregister and free also an adapter that had previously been registered. Since i2c_get_adapter() takes another reference to the adapter, deregistration hangs indefinitely while waiting for the reference to be released. Fix this by only destroying adapters allocated during LVDS init on errors. Fixes: a57ebfc0b4da ("drm/gma500: Make oaktrail lvds use ddc adapter from drm_connector") Cc: stable@vger.kernel.org # 6.0 Cc: Patrik Jakobsson Signed-off-by: Johan Hovold Signed-off-by: Patrik Jakobsson Link: https://patch.msgid.link/20260508144446.59722-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 6d835a99474cd7a6a9f3f94e8b66b188b2a64b95 Author: Johan Hovold Date: Fri May 8 16:44:44 2026 +0200 drm/gma500/oaktrail_hdmi: fix i2c adapter leak on setup commit 950953f774b3f69da6f413e045ef075e1f3da2df upstream. Make sure to drop the reference taken to the I2C adapter (and its module) when setting up HDMI to allow the adapter to be deregistered. Fixes: 1b082ccf5901 ("gma500: Add Oaktrail support") Cc: stable@vger.kernel.org # 3.3 Signed-off-by: Johan Hovold Signed-off-by: Patrik Jakobsson Link: https://patch.msgid.link/20260508144446.59722-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 9a34b94832c374543ce553d4cec6eda6955397d1 Author: Thomas Hellström Date: Fri May 8 18:09:20 2026 +0200 drm/ttm: Convert -EAGAIN from dmem_cgroup_try_charge to -ENOSPC commit 591711b32681a04b57d00c2a404658f8419a081c upstream. dmem_cgroup_try_charge() returns -EAGAIN when the cgroup limit is hit and the charge fails. TTM has no concept of -EAGAIN from resource allocation; -ENOSPC is the canonical error meaning "no space, try eviction". Convert at the source in ttm_resource_alloc() so no caller needs to handle an unexpected error code, and clean up the now-redundant -EAGAIN check in ttm_bo_alloc_resource(). Without this, -EAGAIN escaping ttm_resource_alloc() during an eviction walk causes the walk to terminate early instead of continuing to the next candidate. Cc: Friedrich Vock Cc: Maarten Lankhorst Cc: Tejun Heo Cc: Maxime Ripard Cc: Christian Koenig Cc: dri-devel@lists.freedesktop.org Cc: # v6.14+ Fixes: 2b624a2c1865 ("drm/ttm: Handle cgroup based eviction in TTM") Assisted-by: GitHub_Copilot:claude-sonnet-4.6 Signed-off-by: Thomas Hellström Reviewed-by: Maarten Lankhorst Link: https://patch.msgid.link/20260508160920.230339-1-thomas.hellstrom@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 39fdac6be02eb7c3460518c1c4085f75f935c4ce Author: Matthew Auld Date: Fri May 8 11:26:37 2026 +0100 drm/xe/dma-buf: fix UAF with retry loop commit 155a372a1cc50fa93387c5d3cdfd614a61e1afd1 upstream. Retry doesn't work here, since bo will be freed on error, leading to UAF. However, now that we do the alloc & init before the attach, we can now combine this as one unit and have the init do the alloc for us. This should make the retry safe. Reported by Sashiko. v2: Fix up the error unwind (CI) Closes: https://sashiko.dev/#/patchset/20260506184332.86743-2-matthew.auld%40intel.com Fixes: eb289a5f6cc6 ("drm/xe: Convert xe_dma_buf.c for exhaustive eviction") Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Matthew Brost Cc: # v6.18+ Reviewed-by: Thomas Hellström Link: https://patch.msgid.link/20260508102635.149172-4-matthew.auld@intel.com (cherry picked from commit 479669418253e0f27f8cf5db01a731352ea592e7) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 20a99ea1e2fd720856d6ba497ff26b82c604751f Author: Matthew Auld Date: Fri May 8 11:26:36 2026 +0100 drm/xe/dma-buf: handle empty bo and UAF races commit 981bedbbe61364fcc3a3b87ebaf648a66cd07108 upstream. There look to be some nasty races here when triggering the invalidate_mappings hook: 1) We do xe_bo_alloc() followed by the attach, before the actual full bo init step in xe_dma_buf_init_obj(). However the bo is visible on the attachments list after the attach. This is bad since exporter driver, say amdgpu, can at any time call back into our invalidate_mappings hook, with an empty/bogus bo, leading to potential bugs/crashes. 2) Similar to 1) but here we get a UAF, when the invalidate_mappings hook is triggered. For example, we get as far as xe_bo_init_locked() but this fails in some way. But here the bo will be freed on error, but we still have it attached from dma-buf pov, so if the invalidate_mappings is now triggered then the bo we access is gone and we trigger UAF and more bugs/crashes. To fix this, move the attach step until after we actually have a fully set up buffer object. Note that the bo is not published to userspace until later, so not sure what the comment "Don't publish the bo until we have a valid attachment", is referring to. We have at least two different customers reporting hitting a NULL ptr deref in evict_flags when importing something from amdgpu, followed by triggering the evict flow. Hit rate is also pretty low, which would hint at some kind of race, so something like 1) or 2) might explain this. v2: - Shuffle the order of the ops slightly (no functional change) - Improve the comment to better explain the ordering (Matt B) Assisted-by: Gemini:gemini-3 #debug Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7903 Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/4055 Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Matthew Brost Cc: # v6.8+ Reviewed-by: Matthew Brost Acked-by: Thomas Hellström Link: https://patch.msgid.link/20260508102635.149172-3-matthew.auld@intel.com (cherry picked from commit af1f2ad0c59fe4e2f924c526f66e968289d77971) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit c76273c3eba934f241e03056b9a9531dc92e4d7c Author: Gyeyoung Baek Date: Sun Apr 19 16:17:16 2026 +0900 drm/panfrost: Fix wait_bo ioctl leaking positive return from dma_resv_wait_timeout() commit 459d75523b71c0ec254d153d8850d0b7008af396 upstream. dma_resv_wait_timeout() returns a positive 'remaining jiffies' value on success, 0 on timeout, and -errno on failure. panfrost_ioctl_wait_bo() returns this 'long' result from an int-typed ioctl handler, so positive values reach userspace as bogus errors. Explicitly set ret to 0 on the success path. Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") Cc: stable@vger.kernel.org Signed-off-by: Gyeyoung Baek Reviewed-by: Adrián Larumbe Reviewed-by: Boris Brezillon Reviewed-by: Steven Price Link: https://patch.msgid.link/fe33f82fded7be1c18e2e0eb2db451d5a738cf39.1776581974.git.gye976@gmail.com Signed-off-by: Steven Price Signed-off-by: Greg Kroah-Hartman commit 65a3a1cf29ebe143a989bc1e96519a393e68ab65 Author: Sebastian Brzezinka Date: Thu Apr 16 13:31:18 2026 +0200 drm/i915: skip __i915_request_skip() for already signaled requests commit 4cfe4c0efbdcde742a47813180cc69b132d7598e upstream. After a GPU reset the HWSP is zeroed, so previously completed requests appear incomplete. If such a request is picked up during reset_rewind() and marked guilty, i915_request_set_error_once() returns early (fence already signaled), leaving fence.error without a fatal error code. The subsequent __i915_request_skip() then hits: ``` GEM_BUG_ON(!fatal_error(rq->fence.error)) ``` Fixes a kernel BUG observed on Sandy Bridge (Gen6) during heartbeat-triggered engine resets. ``` kernel BUG at drivers/gpu/drm/i915/i915_request.c:556! RIP: __i915_request_skip+0x15e/0x1d0 [i915] ... __i915_request_reset+0x212/0xa70 [i915] reset_rewind+0xe4/0x280 [i915] intel_gt_reset+0x30d/0x5b0 [i915] heartbeat+0x516/0x530 [i915] ``` Guard __i915_request_skip() with i915_request_signaled(), if the fence is already signaled, the ring content is committed and there is nothing left to skip. Fixes: 36e191f0644b ("drm/i915: Apply i915_request_skip() on submission") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/13729 Signed-off-by: Sebastian Brzezinka Cc: stable@vger.kernel.org # v5.7+ Reviewed-by: Krzysztof Karas Reviewed-by: Andi Shyti Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/fe76921d35b6ae85aa651822726d0d9815aa5362.1776339012.git.sebastian.brzezinka@intel.com (cherry picked from commit 5ba54393dcd7adf75a9f39f5a933b1538349cad5) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit 9022cb9ac0c2a72a57fa8ebf92ac74f953ca0153 Author: Zhenzhong Duan Date: Sat May 9 10:43:46 2026 +0800 iommu/vt-d: Avoid NULL pointer dereference or refcount corruption commit 79ea2feb917b05366b49d85573c9c5331f043b2c upstream. Commit 60f030f7418d ("iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE") fixed a NULL pointer dereference in an unlikely situation partly. If dev_pasid is not found in the dev_pasids list, it remains NULL. However, the teardown operations are executed unconditionally, this lead to a NULL pointer dereference or refcount corruption. If the domain was never attached to this IOMMU, info will be NULL, which would cause an immediate dereference when checking --info->refcnt. Even if info is not NULL, decrementing the refcount without having removed a valid PASID might unbalance the count. This could lead to premature dropping of the refcount to 0, potentially causing a use-after-free for the remaining active devices sharing the domain. Fix it by returning early if dev_pasid is NULL, before executing the teardown operations. Issue found by AI review and suggested by Kevin Tian. https://sashiko.dev/#/patchset/20260421031347.1408890-1-zhenzhong.duan%40intel.com Fixes: 60f030f7418d ("iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE") Cc: stable@vger.kernel.org Suggested-by: Kevin Tian Signed-off-by: Zhenzhong Duan Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20260422033538.95000-1-zhenzhong.duan@intel.com Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 88397fad7914ee74a7880fa5ce01f9eb6bfe0743 Author: Zhenzhong Duan Date: Sat May 9 10:43:45 2026 +0800 iommu/vt-d: Fix oops due to out of scope access commit a6dea58d8625c06b9654c0555f101742481335c3 upstream. Below oops triggers when kill QEMU process: Oops: general protection fault, probably for non-canonical address 0x7fffffff844eaaa7: 0000 [#1] SMP NOPTI Call Trace: do_raw_spin_lock+0xaa/0xc0 _raw_spin_lock_irqsave+0x21/0x40 domain_remove_dev_pasid+0x52/0x160 intel_nested_set_dev_pasid+0x1b9/0x1e0 __iommu_set_group_pasid+0x56/0x120 pci_dev_reset_iommu_done+0xe3/0x180 pcie_flr+0x65/0x160 __pci_reset_function_locked+0x5b/0x120 vfio_pci_core_close_device+0x63/0xe0 [vfio_pci_core] vfio_df_close+0x4f/0xa0 vfio_df_unbind_iommufd+0x2d/0x60 vfio_device_fops_release+0x3e/0x40 __fput+0xe5/0x2c0 task_work_run+0x58/0xa0 do_exit+0x2c8/0x600 do_group_exit+0x2f/0xa0 get_signal+0x863/0x8c0 arch_do_signal_or_restart+0x24/0x100 exit_to_user_mode_loop+0x87/0x380 do_syscall_64+0x2ff/0x11e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The global static blocked domain is a dummy domain without corresponding dmar_domain structure, accessing beyond iommu_domain structure triggers oops easily. Fix it by return early in domain_remove_dev_pasid() like identity domain. Fixes: 7d0c9da6c150 ("iommu/vt-d: Add set_dev_pasid callback for dma domain") Cc: stable@vger.kernel.org Signed-off-by: Zhenzhong Duan Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20260421031347.1408890-1-zhenzhong.duan@intel.com Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 637b7ce89e543284857c68ef66d04dd1f34008cc Author: Naval Alcalá Date: Sat May 9 10:43:44 2026 +0800 iommu/vt-d: Disable DMAR for Intel Q35 IGFX commit 2cda2e10dc8343ae01eae9e999a876b7e7d37861 upstream. Intel Q35 integrated graphics (8086:29b2) exhibits broken DMAR behaviour similar to other G4x/GM45 devices for which DMAR is already disabled via quirks. When DMAR is enabled, the system may hard lock up during boot or early device initialization, requiring a reset. Add the missing PCI ID to the existing quirk list to disable DMAR for this device. Fixes: 1f76249cc3be ("iommu/vt-d: Declare Broadwell igfx dmar support snafu") Cc: stable@vger.kernel.org Closes: https://bugzilla.kernel.org/show_bug.cgi?id=201185 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=216064 Signed-off-by: Naval Alcalá Link: https://lore.kernel.org/r/20260410161622.13549-1-ari@naval.cat Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 4d2b37abda9536808655830d683dc491d31741a8 Author: Raphael Zimmer Date: Tue May 12 09:29:30 2026 +0200 libceph: handle rbtree insertion error in decode_choose_args() commit d289478cfc0bcf81c7914200d6abdcb78bd04ded upstream. A message of type CEPH_MSG_OSD_MAP contains an OSD map that itself contains a CRUSH map. The received CRUSH map may optionally contain choose_args that get decoded in decode_choose_args(). In this function, num_choose_arg_maps is read from the message, and a corresponding number of crush_choose_arg_maps gets decoded afterwards. Each crush_choose_arg_map has a choose_args_index, which serves as the key when inserting it into the choose_args rbtree of the decoded crush_map. If a (potentially corrupted) message contains two crush_choose_arg_maps with the same index, the assertion in insert_choose_arg_map() triggers a kernel BUG when trying to insert the second crush_choose_arg_map. This patch fixes the issue by switching to the non-asserting rbtree insertion function and rejecting the message if the insertion fails. [ idryomov: changelog ] Cc: stable@vger.kernel.org Signed-off-by: Raphael Zimmer Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 0f3604cbe4df14c5e58288ac9f57511e726a222d Author: Raphael Zimmer Date: Wed Apr 22 10:47:13 2026 +0200 libceph: Fix potential out-of-bounds access in crush_decode() commit 4c79fc2d598694bda845b46229c9d48b65042970 upstream. A message of type CEPH_MSG_OSD_MAP containing a crush map with at least one bucket has two fields holding the bucket algorithm. If the values in these two fields differ, an out-of-bounds access can occur. This is the case because the first algorithm field (alg) is used to allocate the correct amount of memory for a bucket of this type, while the second algorithm field inside the bucket (b->alg) is used in the subsequent processing. This patch fixes the issue by adding a check that compares alg and b->alg and aborts the processing in case they differ. Furthermore, b->alg is set to 0 in this case, because the destruction of the crush map also uses this field to determine the bucket type, which can again result in an out-of-bounds access when trying to free the memory pointed to by the fields of the bucket. To correctly free the memory allocated for the bucket in such a case, the corresponding call to kfree is moved from the algorithm-specific crush_destroy_bucket functions to the generic crush_destroy_bucket(). Cc: stable@vger.kernel.org Signed-off-by: Raphael Zimmer Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit f2f95e6d4b97e70bb876139b0583fc8079983f85 Author: Raphael Zimmer Date: Tue May 12 18:16:40 2026 +0200 libceph: Fix potential null-ptr-deref in decode_choose_args() commit 28b0a2ab8c82d0bbdeb8013029c67c978ce6e4bf upstream. A message of type CEPH_MSG_OSD_MAP contains an OSD map that itself contains a CRUSH map. When decoding this CRUSH map in crush_decode(), an array of max_buckets CRUSH buckets is decoded, where some indices may not refer to actual buckets and are therefore set to NULL. The received CRUSH map may optionally contain choose_args that get decoded in decode_choose_args(). When decoding a crush_choose_arg_map, a series of choose_args for different buckets is decoded, with the bucket_index being read from the incoming message. It is only checked that the bucket index does not exceed max_buckets, but not that it doesn't point to an index with a NULL bucket. If a (potentially corrupted) message contains a crush_choose_arg_map including such a bucket_index, a null pointer dereference may occur in the subsequent processing when attempting to access the bucket with the given index. This patch fixes the issue by extending the affected check. Now, it is only attempted to access the bucket if it is not NULL. Cc: stable@vger.kernel.org Signed-off-by: Raphael Zimmer Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 48df98d12b15360cd56af5c1f460307b340c1197 Author: Raphael Zimmer Date: Tue May 5 11:08:12 2026 +0200 libceph: Fix potential out-of-bounds access in osdmap_decode() commit 35d0ed82d03e5ee77ea4f31f20e29562a7721649 upstream. When decoding osd_state and osd_weight from an incoming osdmap in osdmap_decode(), both are decoded for each osd, i.e., map->max_osd times. The ceph_decode_need() check only accounts for sizeof(*map->osd_weight) once. This can potentially result in an out-of-bounds memory access if the incoming message is corrupted such that the max_osd value exceeds the actual content of the osdmap message. This patch fixes the issue by changing the corresponding part in the ceph_decode_need() check to account for map->max_osd*sizeof(*map->osd_weight). Cc: stable@vger.kernel.org Fixes: dcbc919a5dc8 ("libceph: switch osdmap decoding to use ceph_decode_entity_addr") Signed-off-by: Raphael Zimmer Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 0de5cb2d61d053e34f416466c06fd9a5c3388f25 Author: Sascha Bischoff Date: Wed May 6 09:37:43 2026 +0000 irqchip/gic-v5: Allocate ITS parent LPIs as a range commit a7c7e42654b6a8676610ee09d22901432c4851af upstream. The ITS MSI domain no longer manages LPI allocation directly. LPIs are allocated and freed by the parent LPI domain, which can now handle a full range of interrupts and unwind partial allocations internally. Make the ITS domain request and release the parent IRQs as a single range instead of iterating over each interrupt. The ITS allocation path then only needs to reserve EventIDs, allocate the parent range, and fill in the ITS irq_data for each MSI. Since no operation in the per-MSI loop can fail, the partial parent-free unwind becomes unnecessary. On teardown, reset the ITS irq_data for the range and then release the parent range in one call, leaving LPI teardown to the LPI domain. Fixes: 0f0101325876 ("irqchip/gic-v5: Add GICv5 LPI/IPI support") Signed-off-by: Sascha Bischoff Signed-off-by: Thomas Gleixner Reviewed-by: Marc Zyngier Reviewed-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260506093634.382062-4-sascha.bischoff@arm.com Signed-off-by: Greg Kroah-Hartman commit 2cbd4abe413e7444372f7fdf5af7046740e63329 Author: Sascha Bischoff Date: Wed May 6 09:37:23 2026 +0000 irqchip/gic-v5: Support range allocation for LPIs commit eb6f6d523813ead9dc2799194a2839d42c049734 upstream. The per-IPI parent allocation loop returns immediately on failure and leaks any parent interrupts allocated by earlier iterations. The GICv5 LPI domain now owns LPI allocation and teardown internally, but its irq_domain callbacks still reject requests where nr_irqs is greater than one. This forces child domains to allocate and free LPIs one at a time even when the interrupt core requests a contiguous range. Handle multi-interrupt allocation and teardown in the LPI domain by iterating over the requested range and unwinding any partially allocated state on failure. Allocate the parent LPIs for the IPI domain with a single range request as well, which cures the leakage problem. Fixes: 0f0101325876 ("irqchip/gic-v5: Add GICv5 LPI/IPI support") Signed-off-by: Sascha Bischoff Signed-off-by: Thomas Gleixner Reviewed-by: Marc Zyngier Reviewed-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260506093634.382062-3-sascha.bischoff@arm.com Signed-off-by: Greg Kroah-Hartman commit e6550b17cc0eed83e41bccff729a7402667d4f57 Author: Sascha Bischoff Date: Wed May 6 09:37:02 2026 +0000 irqchip/gic-v5: Move LPI allocation into the LPI domain commit dec85d2fbd20de3711a71e65397dfdb40c3fa953 upstream. The IPI and ITS MSI domains currently allocate and release LPIs directly, then pass the selected LPI ID to the parent LPI domain. This leaks the LPI domain's allocation policy into its child domains and forces each child to duplicate part of the parent domain's teardown. Make the LPI domain allocate LPIs in its .alloc() callback and release them in a matching .free() callback. Child domains can then request a parent interrupt without passing an implementation-specific LPI ID, and the LPI lifetime is tied to the domain that owns the LPI namespace. Remove the gicv5_alloc_lpi() and gicv5_free_lpi() wrappers now that no external caller needs to manage LPIs directly. This is a preparatory change for an actual leakage problem in the allocation code and therefore tagged with the same Fixes tag. Fixes: 0f0101325876 ("irqchip/gic-v5: Add GICv5 LPI/IPI support") Signed-off-by: Sascha Bischoff Signed-off-by: Thomas Gleixner Reviewed-by: Marc Zyngier Reviewed-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260506093634.382062-2-sascha.bischoff@arm.com Signed-off-by: Greg Kroah-Hartman commit 84ff9ae64d9b1ede5ed18b1d6bd979f270da92a8 Author: Xianwei Zhao Date: Fri May 8 07:36:54 2026 +0000 irqchip/meson-gpio: Use the correct register in meson_s4_gpio_irq_set_type() commit 5363b67ac8ebcc3e227dbf59fc8061949109841d upstream. meson_s4_gpio_irq_set_type() uses the both-edge trigger register for configuring level type and single edge mode interrupts, which is not correct. Use REG_EDGE_POL instead. Fixes: bbd6fcc76b39 ("irqchip: Add support for Amlogic A4 and A5 SoCs") Signed-off-by: Xianwei Zhao Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260508-a9-gpio-irqchip-v1-1-9dc5f3e022e0@amlogic.com Signed-off-by: Greg Kroah-Hartman commit 5b0756b6b757ba5952343df6b8b84d4c5b33c345 Author: Yong-Xuan Wang Date: Fri May 8 02:31:21 2026 -0700 irqchip/riscv-imsic: Clear interrupt move state during CPU offlining commit cefafbd561402b0fe6447449364a30315b9b1570 upstream. Affinity changes of IMSIC interrupts have to be careful to not lose an interrupt in the process. Each vector keeps track of an affinity change in progress with two pointers in struct imsic_vector. imsic_vector::move_prev points to the previous CPU target data and imsic_vector::move_next to the designated new CPU target data. imsic_vector::move_prev on the new CPU can only be cleared after the previous CPU has cleared imsic_vector::move_next, which ususally happens in __imsic_remote_sync(). In case of CPU hot-unplug __imsic_remote_sync() is not invoked because the CPU is already marked offline. That means imsic_vector::move_prev becomes stale until the CPU is onlined again. The stale pointer prevents further affinity changes for the affected interrupts. Solve this by clearing the imsic_vector::move_prev pointers in the CPU hotplug offline path. [ tglx: Replace word salad in change log ] Fixes: 0f67911e821c ("irqchip/riscv-imsic: Separate next and previous pointers in IMSIC vector") Signed-off-by: Yong-Xuan Wang Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260508-imsic-v2-1-e9f08dd46cf5@sifive.com Signed-off-by: Greg Kroah-Hartman commit 42558732af4a4d814fce31f1fc1a90660ddc50d7 Author: Scott Mayhew Date: Tue Apr 7 18:08:57 2026 -0400 nfsd: fix file change detection in CB_GETATTR commit 304d81a2fbf2b454def4debcb38ea173911b72cd upstream. RFC 8881, section 10.4.3 doesn't say anything about caching the file size in the delegation record, nor does it say anything about comparing a cached file size with the size reported by the client in the CB_GETATTR reply for the purpose of determining if the client holds modified data for the file. What section 10.4.3 of RFC 8881 does say is that the server should compare the *current* file size with the size reported by the client holding the delegation in the CB_GETATTR reply, and if they differ to treat it as a modification regardless of the change attribute retrieved via the CB_GETATTR. Doing otherwise would cause the server to believe the client holding the delegation has a modified version of the file, even if the client flushed the modifications to the server prior to the CB_GETATTR. This would have the added side effect of subsequent CB_GETATTRs causing updates to the mtime, ctime, and change attribute even if the client holding the delegation makes no further updates to the file. Modify nfsd4_deleg_getattr_conflict() to obtain the current file size via i_size_read(). Retain the ncf_cur_fsize field, since it's a convenient way to return the file size back to nfsd4_encode_fattr4(), but don't use it for the purpose of detecting file changes. Remove the unnecessary initialization of ncf_cur_fsize in nfs4_open_delegation(). Also, if we recall the delegation (because the client didn't respond to the CB_GETATTR), then skip the logic that checks the nfs4_cb_fattr fields. Fixes: c5967721e106 ("NFSD: handle GETATTR conflict with write delegation") Cc: stable@vger.kernel.org Signed-off-by: Scott Mayhew Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit fc6db1e47c5551fd594511df69c3265fd6f71a80 Author: Paulo Alcantara Date: Tue May 12 13:33:46 2026 +0100 netfs: fix error handling in netfs_extract_user_iter() commit 0aad5704c6b4d14007d4eab15883e8524e4310f4 upstream. In netfs_extract_user_iter(), if iov_iter_extract_pages() failed to extract user pages, bail out on -ENOMEM, otherwise return the error code only if @npages == 0, allowing short DIO reads and writes to be issued. This fixes mmapstress02 from LTP tests against CIFS. Fixes: 85dd2c8ff368 ("netfs: Add a function to extract a UBUF or IOVEC into a BVEC iterator") Reported-by: Xiaoli Feng Signed-off-by: Paulo Alcantara (Red Hat) Signed-off-by: David Howells Link: https://patch.msgid.link/20260512123404.719402-10-dhowells@redhat.com Cc: netfs@lists.linux.dev Cc: stable@vger.kernel.org Cc: linux-cifs@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit 1a78bea6a5e9ecac37554648261d3f424b1dd3eb Author: Ma Ke Date: Sun Nov 16 10:44:11 2025 +0800 powerpc/warp: Fix error handling in pika_dtm_thread commit 108d7f951271cbd36ca36efc5e5d106966f5180c upstream. pika_dtm_thread() acquires client through of_find_i2c_device_by_node() but fails to release it in error handling path. This could result in a reference count leak, preventing proper cleanup and potentially leading to resource exhaustion. Add put_device() to release the reference in the error handling path. Found by code review. Cc: stable@vger.kernel.org Fixes: 3984114f0562 ("powerpc/warp: Platform fix for i2c change") Signed-off-by: Ma Ke Reviewed-by: Christophe Leroy Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20251116024411.21968-1-make24@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit 3f6fb0211b39aaa1b841260681dd02ca6b693ed5 Author: Carlos López Date: Tue May 12 12:00:41 2026 +0200 virt: sev-guest: Do not use host-controlled page order in cleanup path commit 23e6a1ca04ae44806439a5a446e62e4d42e80bb4 upstream. When issuing an extended guest request (SVM_VMGEXIT_EXT_GUEST_REQUEST), get_ext_report() allocates a buffer to retrieve a certificate blob from the host, keeping track of its size in report_req->certs_len. However, the host may return SNP_GUEST_VMM_ERR_INVALID_LEN, indicating an invalid buffer size, as well as the expected length of such buffer. get_ext_report() subsequently updates report_req->certs_len with the host-controlled value, and cleans up the buffer by computing a page order from such value. This is incorrect, as the host-provided length may not match the page order of the original allocation, potentially resulting in corruption in the page allocator. Fix this by using alloc_pages_exact() instead, and reusing @npages to compute the size passed to free_pages_exact(). For consistency, also use @npages to compute the size when allocating the pages, even though this last change has no functional effect. Fixes: 3e385c0d6ce8 ("virt: sev-guest: Move SNP Guest Request data pages handling under snp_cmd_mutex") Signed-off-by: Carlos López Signed-off-by: Borislav Petkov (AMD) Tested-by: Michael Roth Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 690b7ca1f9b343b505ff6d02226d40d1911a9d16 Author: Wilfred Mallawa Date: Wed Apr 15 09:45:14 2026 +1000 xfs: fix memory leak on error in xfs_alloc_zone_info() commit 592975da8c3ca87b043077e6eafa37665eae7936 upstream. Currently, the 0th index of the zi_used_bucket_bitmap array is not freed on error due to the pre-decrement then evaluate semantic of the while loop used in xfs_alloc_zone_info(). Fix it by allowing for the i == 0 case to be covered. Fixes: 080d01c41d44 ("xfs: implement zoned garbage collection") Cc: stable@vger.kernel.org # v6.15 Reviewed-by: Damien Le Moal Reviewed-by: Carlos Maiolino Signed-off-by: Wilfred Mallawa Reviewed-by: Hans Holmberg Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit b0bd7a850e1f082560959707dbf57b0402071646 Author: David Woodhouse Date: Tue Apr 28 21:59:52 2026 +0100 x86/kexec: Push kjump return address even for non-kjump kexec commit 786a45757dcdf8f2beb9d4a6db605db16c18b2b4 upstream. The version of purgatory code shipped by kexec-tools attempts to look above the top of its stack to find a return address for a kjump, even in a non-kjump kexec. After the commit in Fixes: the word above the stack might not be there, leading to a fault (which is at least now caught by my exception-handling code in kexec). That commit fixed things for the actual kjump path, but no longer "gratuitously" pushes the unused return address to the stack in the non-kjump path. Put that *back* in the non-kjump path, to prevent purgatory from crashing when trying to access it. Fixes: 2cacf7f23a02 ("x86/kexec: Fix stack and handling of re-entry point for ::preserve_context") Reported-by: Rohan Kakulawaram Signed-off-by: David Woodhouse Signed-off-by: Borislav Petkov (AMD) Acked-by: Dave Hansen Tested-by: Rohan Kakulawaram Cc: Link: https://patch.msgid.link/32d627134143ffd957891cb697138e839c623211.camel@infradead.org Signed-off-by: Greg Kroah-Hartman commit f0a0f01787ecece814414b0665df879b69849d09 Author: Jose Fernandez (Anthropic) Date: Tue Apr 21 19:26:13 2026 +0000 iommu/amd: Bounds-check devid in __rlookup_amd_iommu() commit 07d0f496fe7ec5abe3bee7e38be709521567bb33 upstream. iommu_device_register() walks every device on the PCI bus via bus_for_each_dev() and calls amd_iommu_probe_device() for each. The inlined check_device() path computes the device's sbdf, calls rlookup_amd_iommu() to find the owning IOMMU, and only afterwards verifies devid <= pci_seg->last_bdf. __rlookup_amd_iommu() indexes rlookup_table[devid] with no bounds check of its own, so for a PCI device whose BDF is not described by the IVRS, the lookup reads past the end of the allocation before the caller's bounds check can run. This was harmless before commit e874c666b15b ("iommu/amd: Change rlookup, irq_lookup, and alias to use kvalloc()"): the table was a zeroed page-order allocation, so the over-read returned NULL and the caller's NULL check skipped the device. After that commit the table is a tight kvcalloc() and the over-read returns adjacent slab contents, which check_device() then dereferences as a struct amd_iommu *, causing a boot-time GPF. Seen on Google Compute Engine ct6e VMs, where the virtualized IVRS describes only the four TPU endpoints 00:04.0-07.0; the gVNIC at 00:08.0 (devid 0x40) indexes 56 bytes past the 456-byte allocation, into the adjacent kmalloc-512 slab object: pci 0000:00:04.0: Adding to iommu group 0 pci 0000:00:05.0: Adding to iommu group 1 pci 0000:00:06.0: Adding to iommu group 2 pci 0000:00:07.0: Adding to iommu group 3 Oops: general protection fault, probably for non-canonical address 0x3a64695f78746382: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.22 #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/06/2025 RIP: 0010:amd_iommu_probe_device+0x54/0x3a0 Call Trace: __iommu_probe_device+0x107/0x520 probe_iommu_group+0x29/0x50 bus_for_each_dev+0x7e/0xe0 iommu_device_register+0xc9/0x240 iommu_go_to_state+0x9c0/0x1c60 amd_iommu_init+0x14/0x40 pci_iommu_init+0x16/0x60 do_one_initcall+0x47/0x2f0 Guard the array access in __rlookup_amd_iommu(). With the fix applied on 6.18.22, the gVNIC at 00:08.0 is skipped cleanly and the VM boots. Fixes: e874c666b15b ("iommu/amd: Change rlookup, irq_lookup, and alias to use kvalloc()") Cc: stable@vger.kernel.org Reported-by: Ziyuan Chen Tested-by: Ziyuan Chen Reviewed-by: Josef Bacik Assisted-by: Claude:unspecified Signed-off-by: Jose Fernandez (Anthropic) Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 252c5051dba9c709b6a72f2866f93e5e618b3f06 Author: Nicholas Carlini Date: Mon May 11 18:02:16 2026 +0000 io-wq: check that the predecessor is hashed in io_wq_remove_pending() commit d6a2d7b04b5a093021a7a0e2e69e9d5237dfa8cc upstream. io_wq_remove_pending() needs to fix up wq->hash_tail[] if the cancelled work was the tail of its hash bucket. When doing this, it checks whether the preceding entry in acct->work_list has the same hash value, but never checks that the predecessor is hashed at all. io_get_work_hash() is simply atomic_read(&work->flags) >> IO_WQ_HASH_SHIFT, and the hash bits are never set for non-hashed work, so it returns 0. Thus, when a hashed bucket-0 work is cancelled while a non-hashed work is its list predecessor, the check spuriously passes and a pointer to the non-hashed io_kiocb is stored in wq->hash_tail[0]. Because non-hashed work is dequeued via the fast path in io_get_next_work(), which never touches hash_tail[], the stale pointer is never cleared. Therefore, after the non-hashed io_kiocb completes and is freed back to req_cachep, wq->hash_tail[0] is a dangling pointer. The io_wq is per-task (tctx->io_wq) and survives ring open/close, so the dangling pointer persists for the lifetime of the task; the next hashed bucket-0 enqueue dereferences it in io_wq_insert_work() and wq_list_add_after() writes through freed memory. Add the missing io_wq_is_hashed() check so a non-hashed predecessor never inherits a hash_tail[] slot. Cc: stable@vger.kernel.org Fixes: 204361a77f40 ("io-wq: fix hang after cancelling pending hashed work") Signed-off-by: Nicholas Carlini Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit d5bd8b4e39cfa8b087448adcd48088065cd629d5 Author: Viacheslav Dubeyko Date: Thu Apr 9 12:43:40 2026 -0700 ceph: fix BUG_ON in __ceph_build_xattrs_blob() due to stale blob size commit 0c22d9511cbde746622f8e4c11aaa63fe76d45f9 upstream. The generic/642 test-case can reproduce the kernel crash: [40243.605254] ------------[ cut here ]------------ [40243.605956] kernel BUG at fs/ceph/xattr.c:918! [40243.607142] Oops: invalid opcode: 0000 [#1] SMP PTI [40243.608067] CPU: 7 UID: 0 PID: 498762 Comm: kworker/7:1 Not tainted 7.0.0-rc7+ #3 PREEMPT(full) [40243.609700] Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [40243.611820] Workqueue: ceph-msgr ceph_con_workfn [40243.612715] RIP: 0010:__ceph_build_xattrs_blob+0x1b8/0x1e0 [40243.613731] Code: 0f 84 82 fe ff ff e9 cf 8e 56 ff 48 8d 65 e8 31 c0 5b 41 5c 41 5d 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 c3 cc cc cc cc <0f> 0b 4c 8b 62 08 41 8b 85 24 07 00 00 49 83 c4 04 41 89 44 24 fc [40243.616888] RSP: 0018:ffffcc80c4d4b688 EFLAGS: 00010287 [40243.617773] RAX: 0000000000010026 RBX: 0000000000000001 RCX: 0000000000000000 [40243.618928] RDX: ffff8a773798dee0 RSI: 0000000000000000 RDI: 0000000000000000 [40243.620158] RBP: ffffcc80c4d4b6a0 R08: 0000000000000000 R09: 0000000000000000 [40243.621573] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a75f3b58000 [40243.622907] R13: ffff8a75f3b58000 R14: 0000000000000080 R15: 000000000000bffd [40243.624054] FS: 0000000000000000(0000) GS:ffff8a787d1b4000(0000) knlGS:0000000000000000 [40243.625331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [40243.626269] CR2: 000072f390b623c0 CR3: 000000011c02a003 CR4: 0000000000372ef0 [40243.627408] Call Trace: [40243.627839] [40243.628188] __prep_cap+0x3fd/0x4a0 [40243.628789] ? do_raw_spin_unlock+0x4e/0xe0 [40243.629474] ceph_check_caps+0x46a/0xc80 [40243.630094] ? __lock_acquire+0x4a2/0x2650 [40243.630773] ? find_held_lock+0x31/0x90 [40243.631347] ? handle_cap_grant+0x79f/0x1060 [40243.632068] ? lock_release+0xd9/0x300 [40243.632696] ? __mutex_unlock_slowpath+0x3e/0x340 [40243.633429] ? lock_release+0xd9/0x300 [40243.634052] handle_cap_grant+0xcf6/0x1060 [40243.634745] ceph_handle_caps+0x122b/0x2110 [40243.635415] mds_dispatch+0x5bd/0x2160 [40243.636034] ? ceph_con_process_message+0x65/0x190 [40243.636828] ? lock_release+0xd9/0x300 [40243.637431] ceph_con_process_message+0x7a/0x190 [40243.638184] ? kfree+0x311/0x4f0 [40243.638749] ? kfree+0x311/0x4f0 [40243.639268] process_message+0x16/0x1a0 [40243.639915] ? sg_free_table+0x39/0x90 [40243.640572] ceph_con_v2_try_read+0xf58/0x2120 [40243.641255] ? lock_acquire+0xc8/0x300 [40243.641863] ceph_con_workfn+0x151/0x820 [40243.642493] process_one_work+0x22f/0x630 [40243.643093] ? process_one_work+0x254/0x630 [40243.643770] worker_thread+0x1e2/0x400 [40243.644332] ? __pfx_worker_thread+0x10/0x10 [40243.645020] kthread+0x109/0x140 [40243.645560] ? __pfx_kthread+0x10/0x10 [40243.646125] ret_from_fork+0x3f8/0x480 [40243.646752] ? __pfx_kthread+0x10/0x10 [40243.647316] ? __pfx_kthread+0x10/0x10 [40243.647919] ret_from_fork_asm+0x1a/0x30 [40243.648556] [40243.648902] Modules linked in: overlay hctr2 libpolyval chacha libchacha adiantum libnh libpoly1305 essiv intel_rapl_msr intel_rapl_common intel_uncore_frequency_common skx_edac_common nfit kvm_intel kvm irqbypass joydev ghash_clmulni_intel aesni_intel rapl input_leds mac_hid psmouse vga16fb serio_raw vgastate floppy i2c_piix4 pata_acpi bochs qemu_fw_cfg i2c_smbus sch_fq_codel rbd dm_crypt msr parport_pc ppdev lp parport efi_pstore [40243.654766] ---[ end trace 0000000000000000 ]--- Commit d93231a6bc8a ("ceph: prevent a client from exceeding the MDS maximum xattr size") moved the required_blob_size computation to before the __build_xattrs() call, introducing a race. __build_xattrs() releases and reacquires i_ceph_lock during execution. In that window, handle_cap_grant() may update i_xattrs.blob with a newer MDS-provided blob and bump i_xattrs.version. When __build_xattrs() detects that index_version < version, it destroys and rebuilds the entire xattr rb-tree from the new blob, potentially increasing count, names_size, and vals_size. The prealloc_blob size check that follows still uses the stale required_blob_size computed before the rebuild, so it passes even when prealloc_blob is too small for the now-larger tree. After __set_xattr() adds one more xattr on top, __ceph_build_xattrs_blob() is called from the cap flush path and hits: BUG_ON(need > ci->i_xattrs.prealloc_blob->alloc_len); Fix this by recomputing required_blob_size after __build_xattrs() returns, using the current tree state. Also re-validate against m_max_xattr_size to fall back to the sync path if the rebuilt tree now exceeds the MDS limit. Cc: stable@vger.kernel.org Fixes: d93231a6bc8a ("ceph: prevent a client from exceeding the MDS maximum xattr size") Signed-off-by: Viacheslav Dubeyko Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 3fa13ceefbc5f36131110342743994cb3de80637 Author: Viacheslav Dubeyko Date: Thu Apr 9 12:26:02 2026 -0700 ceph: fix a buffer leak in __ceph_setxattr() commit 5d3cc36b4e77a27ce7b686b7c59c7072bcb3fa8e upstream. The old_blob in __ceph_setxattr() can store ci->i_xattrs.prealloc_blob value during the retry. However, it is never called the ceph_buffer_put() for the old_blob object. This patch fixes the issue of the buffer leak. Cc: stable@vger.kernel.org Signed-off-by: Viacheslav Dubeyko Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 9ebb7eba1237dc198768b9c76506a79f924c82bb Author: Qu Wenruo Date: Thu Apr 30 10:37:22 2026 +0930 btrfs: only release the dirty pages io tree after successful writes commit 4066c55e109475a06d18a1f127c939d551211956 upstream. [WARNING] With extra warning on dirty extent buffers at umount (aka, the next patch in the series), test case generic/388 can trigger the following warning about dirty extent buffers at unmount time: BTRFS critical (device dm-2 state E): emergency shutdown BTRFS error (device dm-2 state E): error while writing out transaction: -30 BTRFS warning (device dm-2 state E): Skipping commit of aborted transaction. BTRFS error (device dm-2 state EA): Transaction 9 aborted (error -30) BTRFS: error (device dm-2 state EA) in cleanup_transaction:2068: errno=-30 Readonly filesystem BTRFS info (device dm-2 state EA): forced readonly BTRFS info (device dm-2 state EA): last unmount of filesystem 4fbf2e15-f941-49a0-bc7c-716315d2777c ------------[ cut here ]------------ WARNING: disk-io.c:3311 at invalidate_and_check_btree_folios+0xfd/0x1ca [btrfs], CPU#8: umount/914368 CPU: 8 UID: 0 PID: 914368 Comm: umount Tainted: G OE 7.1.0-rc1-custom+ #372 PREEMPT(full) 2de38db8d1deae71fde295430a0ff3ab98ccf596 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:invalidate_and_check_btree_folios+0xfd/0x1ca [btrfs] Call Trace: close_ctree+0x52e/0x574 [btrfs d2f0b1cd330d1287e7a9919d112eadfc0e914efd] generic_shutdown_super+0x89/0x1a0 kill_anon_super+0x16/0x40 btrfs_kill_super+0x16/0x20 [btrfs d2f0b1cd330d1287e7a9919d112eadfc0e914efd] deactivate_locked_super+0x2d/0xb0 cleanup_mnt+0xdc/0x140 task_work_run+0x5a/0xa0 exit_to_user_mode_loop+0x123/0x4b0 do_syscall_64+0x243/0x7c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---[ end trace 0000000000000000 ]--- BTRFS warning (device dm-2 state EA): unable to release extent buffer 30539776 owner 9 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30621696 owner 257 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30638080 owner 258 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30654464 owner 7 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30703616 owner 2 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30720000 owner 10 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30736384 owner 4 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30752768 owner 11 gen 9 refs 2 flags 0x7 I'm using a stripped down version, which seems to trigger the warning more reliably: _fsstress_pid="" workload() { dmesg -C mkfs.btrfs -f -K $dev > /dev/null echo 1 > /sys/kernel/debug/clear_warn_once mount $dev $mnt $fsstress -w -n 1024 -p 4 -d $mnt & _fsstress_pid=$! sleep 0 $godown $mnt pkill --echo -PIPE fsstress > /dev/null wait $_fsstress_pid unset _fsstress_pid umount $mnt if dmesg | grep -q "WARNING"; then fail fi } for (( i = 0; i < $runtime; i++ )); do echo "=== $i/$runtime ===" workload done [CAUSE] Inside btrfs_write_and_wait_transaction(), we first try to write all dirty ebs, then wait for them to finish. After that we call btrfs_extent_io_tree_release() to free all extent states from dirty_pages io tree. However if we hit an error from btrfs_write_marked_extent(), then we still call btrfs_extent_io_tree_release() to clear that dirty_pages io tree, which may contain dirty records that we haven't yet submitted. Furthermore, the later transaction cleanup path will utilize that dirty_pages io tree to properly cleanup those dirty ebs, but since it's already empty, no dirty ebs are properly cleaned up, thus will later trigger the warnings inside invalidate_btree_folios(). [FIX] Normally such dirty ebs won't cause problems, as when the iput() is called on the btree inode, the dirty ebs will be forcibly written back, and since the fs is already in an error status, such writeback will not reach disk and finish immediately. But it's still better to get rid of such dirty ebs, if we ended up with dirty ebs but the fs is not in an error status, then such writeback at iput() time will be too late, as all workers are already stopped but writeback will utilize workers, which will lead to NULL pointer dereferences. Instead of unconditionally calling btrfs_extent_io_tree_release(), only call it if btrfs_write_and_wait_transaction() finished successfully, so that @dirty_pages extent io tree is kept untouched for transaction cleanup. CC: stable@vger.kernel.org # 6.1+ Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit d7b2de5d98628062426d618be509de611b433111 Author: Cássio Gabriel Date: Mon May 11 01:36:37 2026 -0300 ALSA: usb-audio: qcom: Check offload mapping failures commit 814b2c9b30e56074e11fc0a6e5419b3fee0639bc upstream. uaudio_transfer_buffer_setup() calls dma_get_sgtable() and then passes the sg_table to uaudio_iommu_map_xfer_buf() without checking whether sg table construction succeeded. If dma_get_sgtable() fails, the sg_table contents are not valid. uaudio_iommu_map_pa() also ignores iommu_map() failures for the event and transfer rings and still returns the allocated IOVA to the QMI response. That can expose an unmapped IOVA to the audio DSP. For transfer rings, the failed mapping also leaves the IOVA allocator state marked in use. Check both operations. Free the coherent transfer buffer when sg table construction fails, free the sg table when transfer-buffer IOMMU mapping fails, and release the transfer-ring IOVA if iommu_map() fails. Also return the existing event-ring IOVA when the event ring is already mapped, matching the pre-split helper behavior. Fixes: 326bbc348298 ("ALSA: usb-audio: qcom: Introduce QC USB SND offloading support") Fixes: 44499ecb4f28 ("ALSA: usb: qcom: Fix false-positive address space check") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260511-alsa-usb-qcom-offload-map-errors-v1-1-6502695e58bc@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 09141583bd97f4bbd7358e29fd138fe798467cdb Author: Cássio Gabriel Date: Thu May 7 00:40:51 2026 -0300 ALSA: usb-audio: Bound MIDI endpoint descriptor scans commit d6854daa67be623860f4e1873fd3d3c275aba4ed upstream. snd_usbmidi_get_ms_info() validates the internal MIDIStreaming endpoint descriptor size before using baAssocJackID[], but the descriptor walker can still return a class-specific endpoint descriptor whose bLength exceeds the remaining bytes in the endpoint-extra scan. That leaves later flexible-array reads bounded by bLength, but not by the remaining bytes in the endpoint-extra scan. Stop walking when bLength is zero or extends past the remaining endpoint-extra scan. Fixes: 5c6cd7021a05 ("ALSA: usb-audio: Fix case when USB MIDI interface has more than one extra endpoint descriptor") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260507-usb-midi-endpoint-scan-bounds-v1-1-329d7348160e@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f9c184a83574549a36ea69b755f650e57d164c78 Author: Cássio Gabriel Date: Thu May 7 00:40:52 2026 -0300 ALSA: usb-audio: Bound MIDI 2.0 endpoint descriptor scans commit 918be519c7876329e1b6e2ea1c59f0b75e792dca upstream. The USB MIDI 2.0 endpoint parser has the same descriptor walking pattern as the legacy MIDI parser. It validates bLength against bNumGrpTrmBlock before reading baAssoGrpTrmBlkID[], but not against the remaining bytes in the endpoint-extra scan. A malformed device can therefore make later baAssoGrpTrmBlkID[] reads consume bytes past the walked descriptor. Reject zero-length and overlong descriptors while walking endpoint extras. Fixes: ff49d1df79ae ("ALSA: usb-audio: USB MIDI 2.0 UMP support") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260507-usb-midi-endpoint-scan-bounds-v1-2-329d7348160e@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 651760f57fe0fce3c3c77e5099a8c81df31181af Author: Markus Kramer Date: Thu May 14 00:28:18 2026 +0200 ALSA: hda/realtek: Add quirk for Samsung Galaxy Book5 360 headphone commit fd87b510f5f543125ecf51e7c706a9f4bc3352be upstream. The Samsung Galaxy Book5 360 (NP750QHA, PCI subsystem ID 0x144d:0xc902) has severe audio distortion on the 3.5mm headphone jack. Applying ALC256_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET corrects the output path configuration, consistent with fixes already applied to other Samsung Galaxy Book models using the same ALC256 codec. Cc: stable@vger.kernel.org Link: https://github.com/thesofproject/linux/issues/5648 Signed-off-by: Markus Kramer Link: https://patch.msgid.link/20260513222818.14351-1-linux@markus-kramer.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a424946e00f2e99d5a9fe6dadd095971a3f576b1 Author: Adrien Burnett Date: Thu May 14 18:59:05 2026 +0200 ALSA: hda/realtek: Add mute LED quirk for HP Pavilion Laptop 16-ag0xxx commit 7d1051ad68df3d584b5f24bfa1fb19f3a24db278 upstream. Add a SND_PCI_QUIRK entry for the HP Pavilion Laptop 16-ag0xxx (subsystem 0x103c:0x8cbc, Realtek ALC245). The ALC245_FIXUP_HP_X360_MUTE_LEDS fixup is already used by the neighbouring HP Pavilion Aero Laptop 13-bg0xxx (0x103c:0x8cbd); it chains the master-mute COEF handler with the GPIO mic-mute LED handler, which is what this machine needs. Tested on the affected hardware: both the mute and mic-mute key LEDs respond correctly to the keyboard hotkeys after this change. Cc: Signed-off-by: Adrien Burnett Link: https://patch.msgid.link/20260514165905.21175-1-an.arctic.pigeon@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d3e03c25d520d717a65b82c52dd22ec662fe5580 Author: Gyeyoung Baek Date: Sun Apr 19 16:17:15 2026 +0900 accel/rocket: Fix prep_bo ioctl leaking positive return from dma_resv_wait_timeout() commit 74570e12b4705ea11dcdfbfbd0a0b0fdaeff3059 upstream. dma_resv_wait_timeout() returns a positive 'remaining jiffies' value on success, 0 on timeout, and -errno on failure. rocket_ioctl_prep_bo() returns this 'long' result from an int-typed ioctl handler, so positive values reach userspace as bogus errors. Explicitly set ret to 0 on the success path. Fixes: 525ad89dd904 ("accel/rocket: Add IOCTLs for synchronizing memory accesses") Cc: stable@vger.kernel.org Signed-off-by: Gyeyoung Baek Reviewed-by: Tomeu Vizoso Link: https://patch.msgid.link/c0ebf83b345721701b22d8f5bc41c52c0ecf5e16.1776581974.git.gye976@gmail.com Signed-off-by: Steven Price Signed-off-by: Greg Kroah-Hartman commit 9b718ebe0e9725e4040bda129a01d2dab86c15eb Author: Derek J. Clark Date: Sun May 10 04:25:35 2026 +0000 platform/x86: lenovo-wmi-other: Fix tunable_attr_01 struct members commit 71f3843e0f81e3c097a088c1121154bb9a44da0a upstream. In struct tunable_attr_01 the capdata pointer is unused and the size of the id members is u32 when it should be u8. Fix these prior to adding additional members. No functional change intended. Reviewed-by: Mark Pearson Cc: stable@vger.kernel.org Reviewed-by: Rong Zhang Tested-by: Rong Zhang Signed-off-by: Derek J. Clark Link: https://patch.msgid.link/20260510042546.436874-6-derekjohn.clark@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit b6c0f545c8f94b447e554e57b66d28b163b48837 Author: Derek J. Clark Date: Sun May 10 04:25:37 2026 +0000 platform/x86: lenovo-wmi-helpers: Move gamezone enums to wmi-helpers commit 7e27896e16a1c450085c3fe020eeb1b223880f37 upstream. In a later patch in the series the thermal mode enum will be accessed across three separate drivers (wmi-capdata, wmi-gamezonem and wmi-other). An additional patch in the series will also add a function prototype that needs to reference this enum in wmi-helpers.h. To avoid having all these drivers begin to import each others headers, and to avoid declaring an opaque enum to hande the second case, move the thermal mode enum to helpers where it can be safely accessed by everything that needs it from a single import. While at it, since the gamezone_events_type enum is the only remaining item in the header, move that as well and remove the gamezone header entirely. Cc: stable@vger.kernel.org Reviewed-by: Mark Pearson Reviewed-by: Rong Zhang Tested-by: Rong Zhang Signed-off-by: Derek J. Clark Link: https://patch.msgid.link/20260510042546.436874-8-derekjohn.clark@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 1b2dca1f9b5adc39bc976542262437aa408c245a Author: Srinivas Pandruvada Date: Thu Apr 30 08:11:01 2026 -0700 platform/x86: intel: Move debugfs register before creating devices commit ad3bff944c0f4f2e913298a9664391af32f87491 upstream. It is possible that the driver handling device is enumerated before registering debugfs. If the driver wants to access debugfs by calling tpmi_get_debugfs_dir(), this will return error in this case. Hence register debugfs before creating devices. Fixes: 811f67c51636 ("platform/x86/intel/tpmi: Add new auxiliary driver for performance limits") Signed-off-by: Srinivas Pandruvada Cc: Stable@vger.kernel.org Link: https://patch.msgid.link/20260430151103.1549733-2-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit d25b863e2dff42cf3533ca8d7e08c6eec910bc11 Author: Chaitanya Kumar Borah Date: Tue May 5 14:39:20 2026 +0530 drm/i915/dp: Fix VSC dynamic range signaling for RGB formats commit 1ae15b6c7965d137eef21f2cc7d367b29cb88369 upstream. For RGB, set dynamic_range to CTA or VESA based on crtc_state->limited_color_range so sinks apply correct quantization. YCbCr remains limited (CTA) range. (DP v1.4, Table 5-1) v2: - Added Reported-by and Tested-by tags v3: - Add back YCbCr comment(Suraj) Cc: stable@vger.kernel.org #v5.8+ Reported-by: DeepChirp Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15874 Tested-by: DeepChirp Fixes: 9799c4c3b76e ("drm/i915/dp: Add compute routine for DP VSC SDP") Assisted-by: GitHub-Copilot:GPT-5.4 Signed-off-by: Chaitanya Kumar Borah Reviewed-by: Suraj Kandpal Signed-off-by: Suraj Kandpal Link: https://patch.msgid.link/20260505090920.2479112-1-chaitanya.kumar.borah@intel.com (cherry picked from commit 38e10ddae6f8d42a2e8437fcd25a1cac51106c64) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit 318b995cffcfcaa69a234d28123a3f4ae186a9df Author: Edward Adam Davis Date: Wed May 13 12:30:50 2026 +0800 drm: Replace old pointer to new idr commit dc366607c41c45fd0ae6f3db090f31dd611b644a upstream. Commit 5e28b7b94408 introduced a logical error by failing to replace the newly generated IDR pointer to old id's pointer at the correct location within the "change handle" logic; this resulted in the issue reported by syzbot [1]. Specifically, the new IDR object pointer is intended to replace the original id's pointer during the normal execution flow. Additionally, an unnecessary conditional check for the ret exit path has been removed. [1] !RB_EMPTY_ROOT(&prime_fpriv->dmabufs) WARNING: drivers/gpu/drm/drm_prime.c:224 at drm_prime_destroy_file_private+0x48/0x60 drivers/gpu/drm/drm_prime.c:224, CPU#0: syz.0.17/5833 Call Trace: drm_file_free.part.0+0x7e6/0xcc0 drivers/gpu/drm/drm_file.c:269 drm_file_free drivers/gpu/drm/drm_file.c:237 [inline] drm_close_helper.isra.0+0x186/0x200 drivers/gpu/drm/drm_file.c:290 drm_release+0x1ab/0x360 drivers/gpu/drm/drm_file.c:438 Fixes: 5e28b7b94408 ("drm: Set old handle to NULL before prime swap in change_handle") Reported-by: syzbot+d7c9eed171647e421013@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d7c9eed171647e421013 Cc: stable@vger.kernel.org Tested-by: syzbot+d7c9eed171647e421013@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Signed-off-by: Dave Airlie Link: https://patch.msgid.link/tencent_C267296443AAA4567771176886DFF364A305@qq.com Signed-off-by: Greg Kroah-Hartman commit d31c6b3342158ebfcc92c17004e2095f27cc52ab Author: Myeonghun Pak Date: Wed May 13 15:57:00 2026 +0900 drm/loongson: Use managed KMS polling commit 0a9c56dd387605d17dabeedd9fdd2c4c1d0bab7b upstream. lsdc_pci_probe() initializes KMS polling before setting up vblank support, requesting the IRQ and registering the DRM device. If any of those later steps fails, probe returns without finalizing polling. The driver also never finalizes polling on regular removal. Use drmm_kms_helper_poll_init() so polling is tied to the DRM device lifetime and automatically finalized on probe failure and device removal. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: f39db26c5428 ("drm: Add kms driver for loongson display controller") Cc: stable@vger.kernel.org Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Reviewed-by: Thomas Zimmermann Acked-by: Jianmin Lv Reviewed-by: Huacai Chen Signed-off-by: Myeonghun Pak Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260513065706.23803-1-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit 97a05b0ae9ea5ec052be2eef0f9cc7ce03501bbb Author: Ye Bin Date: Thu May 14 21:14:18 2026 +0800 smb/client: fix possible infinite loop and oob read in symlink_data() commit 7d9a7f1f96cd617ee9e75bb22217c709038e26b8 upstream. On 32-bit architectures, the infinite loop is as follows: len = p->ErrorDataLength == 0xfffffff8 u8 *next = p->ErrorContextData + len next == p On 32-bit architectures, the out-of-bounds read is as follows: len = p->ErrorDataLength == 0xfffffff0 u8 *next = p->ErrorContextData + len next == (u8 *)p - 8 Reported-by: ChenXiaoSong Fixes: 76894f3e2f71 ("cifs: improve symlink handling for smb2+") Cc: stable@vger.kernel.org Signed-off-by: Ye Bin Reviewed-by: ChenXiaoSong Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 0ea9d6e036bee5c3bf1c8a820524b9a8a95c30eb Author: Nick Chan Date: Thu May 14 21:16:01 2026 +0800 nvme-apple: Reset q->sq_tail during queue init commit a6ab75639e23169a741b0b2e12191fd8acb32c73 upstream. Fixes a "duplicate tag error for tag 0" firmware crash during controller reset while setting up a queue on Apple A11 / T8015 caused by stale entries in the submission queue due to an invalid sq_tail offset after reset. Fixes: 04d8ecf37b5e ("nvme: apple: Add Apple A11 support") Cc: stable@vger.kernel.org Suggested-by: Yuriy Havrylyuk Reviewed-by: Sven Peter Signed-off-by: Nick Chan Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 527cb4a5515561ab8cc2b976396173fefbc85389 Author: Pauli Virtanen Date: Fri Apr 24 22:24:29 2026 +0300 Bluetooth: btmtk: accept too short WMT FUNC_CTRL events commit e3ac0d9f1a205f33a43fba3b79ef74d2f604c78b upstream. MT7925 (USB ID 0e8d:e025) on fw version 20260106153314 sends WMT FUNC_CTRL events that are missing the status field. Prior to commit 006b9943b982 ("Bluetooth: btmtk: validate WMT event SKB length before struct access") the status was read from out-of-bounds of SKB data, which usually would result to success with BTMTK_WMT_ON_UNDONE, although I don't know the intent here. The bounds check added in that commit returns with error instead, producing "Bluetooth: hci0: Failed to send wmt func ctrl (-22)" and makes the device unusable. Fix the regression by interpreting too short packet as status BTMTK_WMT_ON_UNDONE, which makes the device work normally again. Fixes: 634a4408c061 ("Bluetooth: btmtk: validate WMT event SKB length before struct access") Signed-off-by: Pauli Virtanen Tested-by: Mikhail Gavrilov # MT7922 (0489:e0e2) Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 151cfe527f0a38d9ed3a1e53837a1c8d46a9a283 Author: Michael Tretter Date: Tue May 19 16:14:36 2026 +0200 media: staging: imx: configure src_mux in csi_start [ Upstream commit ebeec2b000a90cd8aae86d1931ff5ef23af8284e ] After media_pipeline_start() was called, the media graph is assumed to be validated. It won't be validated again if a second stream starts. The imx-media-csi driver, however, changes hardware configuration in the link_validate() callback. This can result in started streams with misconfigured hardware. In the concrete example, the ipu2_csi1 is driven by a parallel video input. After the media pipeline has been started with this configuration, a second stream is configured to use ipu1_csi0 with MIPI-CSI input from imx6-mipi-csi2. This may require the reconfiguration of ipu1_csi0 with ipu_set_csi_src_mux(). Since the media pipeline is already running, link_validate won't be called, and the ipu1_csi0 won't be reconfigured. The resulting video is broken, because the ipu1_csi0 is misconfigured, but no error is reported. Move ipu_set_csi_src_mux from csi_link_validate to csi_start to ensure that input to ipu1_csi0 is configured correctly when starting the stream. This is a local reconfiguration in ipu1_csi0 and is possible while the media pipeline is running. Since csi_start() is called with priv->lock already locked, csi_set_src() must not lock priv->lock again. Thus, the mutex_lock() is dropped. Signed-off-by: Michael Tretter Fixes: 4a34ec8e470c ("[media] media: imx: Add CSI subdev driver") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Reviewed-by: Philipp Zabel Signed-off-by: Frank Li Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 7c96f2e5b6fbb870062c9cdde98a2dabefba6ad8 Author: Igor Pylypiv Date: Sun Apr 12 08:36:37 2026 -0700 ata: libata-scsi: fix requeue of deferred ATA PASS-THROUGH commands [ Upstream commit 8ebf408e7d463eee02c348a3c8277b95587b710d ] Commit 0ea84089dbf6 ("ata: libata-scsi: avoid Non-NCQ command starvation") introduced ata_scsi_requeue_deferred_qc() to handle commands deferred during resets or NCQ failures. This deferral logic completed commands with DID_SOFT_ERROR to trigger a retry in the SCSI mid-layer. However, DID_SOFT_ERROR is subject to scsi_cmd_retry_allowed() checks. ATA PASS-THROUGH commands sent via SG_IO ioctl have scmd->allowed set to zero. This causes the mid-layer to fail the command immediately instead of retrying, even though the command was never actually issued to the hardware. Switch to DID_REQUEUE to ensure these commands are inserted back into the request queue regardless of retry limits. Fixes: 0ea84089dbf6 ("ata: libata-scsi: avoid Non-NCQ command starvation") Reviewed-by: Damien Le Moal Signed-off-by: Igor Pylypiv Signed-off-by: Niklas Cassel Signed-off-by: Sasha Levin commit d92229dfa3f9fdf91d9158a5854693511f1b1f2c Author: Vlad Poenaru Date: Tue May 19 10:48:16 2026 -0700 fuse: avoid 0x10 fault in fuse_readahead when max_pages == 0 [ Upstream commit 4ea907108a5c ("fuse: use iomap for readahead") ] The upstream fix is the iomap conversion in commit 4ea907108a5c ("fuse: use iomap for readahead"), which rewrote fuse_readahead() entirely and removed the buggy loop along with it. That refactor is too invasive to backport to the pre-iomap readahead path still used by 6.18.y (and earlier stable branches), so this is a minimal, equivalent fix to the same bug on those branches. When fc->max_read is smaller than PAGE_SIZE (common on aarch64 with 64K base pages if the FUSE server advertises a small max_read in INIT), max_pages = min(fc->max_pages, fc->max_read / PAGE_SIZE) is 0, so cur_pages is 0 on every outer iteration. fuse_io_alloc(NULL, 0) then calls fuse_folios_alloc(0, ...), which calls kzalloc(0, ...) and gets back ZERO_SIZE_PTR == (void *)16. The "if (!ia->ap.folios)" guard in fuse_io_alloc does not catch ZERO_SIZE_PTR, so fuse_io_alloc happily returns an ia whose ap.folios is 0x10. The inner "while (pages < cur_pages)" loop runs zero times, then fuse_send_readpages(ia, ...) dereferences ap->folios[0] in folio_pos(), faulting at virtual address 0x10: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 fuse_readahead+0x14c/0x490 read_pages+0x80/0x318 page_cache_ra_unbounded+0x1c0/0x2b0 page_cache_ra_order+0xb8/0x368 page_cache_sync_ra+0x210/0x320 filemap_get_pages+0x290/0xdb0 generic_file_read_iter+0xd0/0x540 fuse_file_read_iter+0x8c/0x158 __arm64_sys_read+0x1a0/0x488 addr2line on the aarch64 vmlinux maps fuse_readahead+0x14c to fs/fuse/file.c:897 inlined into :999, i.e. "folio_pos(ap->folios[0])" inside fuse_send_readpages. The faulting instruction "ldr x8, [x8]" loads ap->folios[0]; ap->folios was previously loaded as 0x10 (ZERO_SIZE_PTR). Without this fix the function would also spin forever, since "nr_pages -= pages" makes no progress when pages stays 0; in practice the NULL deref masks the spin. Bail out of the outer loop if cur_pages is 0 -- there is no work we can issue via FUSE in this iteration, and remaining folios will be handled by read_pages() falling back to ->read_folio. Fixes: 3eab9d7bc2f4 ("fuse: convert readahead to use folios") Reported-by: Breno Leitao Reviewed-by: Joanne Koong Signed-off-by: Vlad Poenaru Signed-off-by: Sasha Levin commit 3ab135238832446399614e7a4bb796d620717806 Author: Nathan Chancellor Date: Sun May 17 13:51:01 2026 +0900 HID: core: Fix size_t specifier in hid_report_raw_event() [ Upstream commit 4d3a2a466b8d68d852a1f3bbf11204b718428dc4 ] When building for 32-bit platforms, for which 'size_t' is 'unsigned int', there are warnings around using the incorrect format specifier to print bsize in hid_report_raw_event(): drivers/hid/hid-core.c:2054:29: error: format specifies type 'long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat] 2053 | hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %ld)\n", | ~~~ | %zu 2054 | report->id, csize, bsize); | ^~~~~ drivers/hid/hid-core.c:2076:29: error: format specifies type 'long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat] 2075 | hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %ld)\n", | ~~~ | %zu 2076 | report->id, rsize, bsize); | ^~~~~ Use the proper 'size_t' format specifier, '%zu', to clear up the warnings. Cc: stable@vger.kernel.org Fixes: 2c85c61d1332 ("HID: pass the buffer size to hid_report_raw_event") Reported-by: Miguel Ojeda Closes: https://lore.kernel.org/20260516020430.110135-1-ojeda@kernel.org/ Signed-off-by: Nathan Chancellor Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 301338b8edadc67a42b1c86add975091e66768d9 Author: Benjamin Tissoires Date: Mon May 4 10:47:23 2026 +0200 HID: core: introduce hid_safe_input_report() [ Upstream commit 206342541fc887ae919774a43942dc883161fece ] hid_input_report() is used in too many places to have a commit that doesn't cross subsystem borders. Instead of changing the API, introduce a new one when things matters in the transport layers: - usbhid - i2chid This effectively revert to the old behavior for those two transport layers. Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()") Cc: stable@vger.kernel.org Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 509c2605065004fc4cd86ee50a9350d402785307 Author: Benjamin Tissoires Date: Mon May 4 10:47:22 2026 +0200 HID: pass the buffer size to hid_report_raw_event [ Upstream commit 2c85c61d1332e1e16f020d76951baf167dcb6f7a ] commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()") enforced the provided data to be at least the size of the declared buffer in the report descriptor to prevent a buffer overflow. However, we can try to be smarter by providing both the buffer size and the data size, meaning that hid_report_raw_event() can make better decision whether we should plaining reject the buffer (buffer overflow attempt) or if we can safely memset it to 0 and pass it to the rest of the stack. Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()") Cc: stable@vger.kernel.org Signed-off-by: Benjamin Tissoires Acked-by: Johan Hovold Reviewed-by: Greg Kroah-Hartman Signed-off-by: Jiri Kosina Stable-dep-of: 206342541fc8 ("HID: core: introduce hid_safe_input_report()") Signed-off-by: Sasha Levin commit 8adc988e9f2061501340697d9ef581f09891253b Author: Qiang Ma Date: Tue May 12 09:53:13 2026 +0800 KVM: x86: Fix Xen hypercall tracepoint argument assignment commit 2b72f1674e427c56e3772c5ccf785fdda2138820 upstream. TRACE_EVENT(kvm_xen_hypercall) stores a5 in __entry->a4 instead of __entry->a5. That overwrites the recorded a4 argument and leaves a5 unset in the trace entry. Fix the typo so both arguments are captured correctly. Signed-off-by: Qiang Ma Link: https://patch.msgid.link/20260512015313.1685784-1-maqianga@uniontech.com/ Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit b22a2da8792a7bfe743c1a922e77fa499ddedbe8 Author: Junrui Luo Date: Wed Apr 15 17:26:55 2026 +0800 KVM: s390: pci: fix GAIT table indexing due to double-scaling pointer arithmetic commit 16d990a15491cf76cd6eef0846e1b4100e63261a upstream. kvm_s390_pci_aif_enable(), kvm_s390_pci_aif_disable(), and aen_host_forward() index the GAIT by manually multiplying the index with sizeof(struct zpci_gaite). Since aift->gait is already a struct zpci_gaite pointer, this double-scales the offset, accessing element aisb*16 instead of aisb. This causes out-of-bounds accesses when aisb >= 32 (with ZPCI_NR_DEVICES=512) Fix by removing the erroneous sizeof multiplication. Fixes: 3c5a1b6f0a18 ("KVM: s390: pci: provide routines for enabling/disabling interrupt forwarding") Fixes: 73f91b004321 ("KVM: s390: pci: enable host forwarding of Adapter Event Notifications") Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Reviewed-by: Christian Borntraeger Reviewed-by: Matthew Rosato Tested-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 0d419c23bb11b5c9664de777c47c1f04a235882d Author: Aaron Sacks Date: Tue May 12 02:07:42 2026 -0400 KVM: Reject wrapped offset in kvm_reset_dirty_gfn() commit 577a8d3bae0531f0e5ccfac919cd8192f920a804 upstream. kvm_reset_dirty_gfn() guards the gfn range with if (!memslot || (offset + __fls(mask)) >= memslot->npages) return; but offset is u64 and the addition is unchecked. The check can be silently bypassed by a u64 wrap. The dirty ring backing those entries is MAP_SHARED at KVM_DIRTY_LOG_PAGE_OFFSET of the vcpu fd, so the VMM can rewrite the slot and offset fields of any entry between when the kernel pushes them and when KVM_RESET_DIRTY_RINGS consumes them. On reset, kvm_dirty_ring_reset() re-reads the values via READ_ONCE() and feeds them straight back into this check; only the flags handshake is treated as the handover, the slot/offset payload is taken on trust. Crafting two entries entry[i].offset = 0xffffffffffffffc1 entry[i+1].offset = 0 makes the coalescing loop in kvm_dirty_ring_reset() compute delta = (s64)(0 - 0xffffffffffffffc1) = 63 which falls in [0, BITS_PER_LONG), so it folds entry[i+1] into the existing mask by setting bit 63. The trailing kvm_reset_dirty_gfn() call then sees offset = 0xffffffffffffffc1 and __fls(mask) = 63; the sum is 0 in u64 and the bounds check passes. That offset propagates into kvm_arch_mmu_enable_log_dirty_pt_masked() unchanged. On the legacy MMU path -- kvm_memslots_have_rmaps() == true, i.e. shadow paging, any VM that has allocated shadow roots, or a write-tracked slot -- it reaches gfn_to_rmap(), which indexes slot->arch.rmap[0][] with a near-U64_MAX gfn. That is an out-of-bounds load of a kvm_rmap_head, followed by a conditional clear of PT_WRITABLE_MASK in whatever the loaded pointer points at. The path is reachable from any process holding /dev/kvm. Range-check offset on its own first, so the addition cannot wrap. memslot->npages is bounded well below U64_MAX, so once offset < npages holds, offset + __fls(mask) (with __fls(mask) < BITS_PER_LONG) stays in range. Fixes: fb04a1eddb1a ("KVM: X86: Implement ring-based dirty memory tracking") Cc: stable@vger.kernel.org Signed-off-by: Aaron Sacks Link: https://patch.msgid.link/20260512060742.1628959-1-contact@xchglabs.com/ Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit d9017d2332582dfd6357606f11d3347c902c3e3a Author: Sergio Correia Date: Tue May 12 14:28:59 2026 +0100 audit: enforce AUDIT_LOCKED for AUDIT_TRIM and AUDIT_MAKE_EQUIV commit f9e1c1324b4d98d591a6f7568fdebf5cf456dfc2 upstream. AUDIT_ADD_RULE and AUDIT_DEL_RULE correctly check for AUDIT_LOCKED and return -EPERM, but AUDIT_TRIM and AUDIT_MAKE_EQUIV do not. This allows a process with CAP_AUDIT_CONTROL to modify directory tree watches and equivalence mappings even when the audit configuration has been locked, undermining the purpose of the lock. Add AUDIT_LOCKED checks to both commands. Cc: stable@vger.kernel.org Reviewed-by: Ricardo Robaina Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Sergio Correia Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit e029cbd8c06d0698aceb2141b3dfd997c9805c38 Author: Zoran Ilievski Date: Mon May 11 08:40:02 2026 +0200 net: atlantic: preserve PCI wake-from-D3 on shutdown when WOL enabled commit 2c308cf34284420963607d677d576a2b4124d8bd upstream. The shutdown handler aq_pci_shutdown() unconditionally calls pci_wake_from_d3(pdev, false), clearing the PCI PME_En bit even when wake-on-LAN has been configured. While aq_nic_shutdown() correctly programs the NIC firmware via aq_nic_set_power() to listen for magic packets, the PCI subsystem will not propagate the resulting PME wake event from D3, so the system never wakes after poweroff. WOL from suspend (S3) is unaffected because aq_suspend_common() does not touch pci_wake_from_d3() and relies on the PM core's wake configuration via device_may_wakeup(). This affects all atlantic-supported NICs (AQC107/108/111/112/113); users have reported that WOL works if the atlantic driver is never loaded, but breaks once it has run its shutdown path. Pass the configured WOL state to pci_wake_from_d3() instead of a literal false, so the PCI PME_En bit is preserved when the user has armed WOL via ethtool. Fixes: 90869ddfefeb ("net: aquantia: Implement pci shutdown callback") Cc: stable@vger.kernel.org Signed-off-by: Zoran Ilievski Reviewed-by: Sukhdeep Singh Link: https://patch.msgid.link/20260511064002.1857-1-goodboy@rexbytes.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1dced0725e2fae3ac3416274db20a7ff5a46931d Author: Li Xiasong Date: Thu May 7 22:04:23 2026 +0800 netfilter: nft_ct: fix missing expect put in obj eval commit 19f94b6fee75b3ef7fbc06f3745b9a771a8a19a4 upstream. nft_ct_expect_obj_eval() allocates an expectation and may call nf_ct_expect_related(), but never drops its local reference. Add nf_ct_expect_put(exp) before return to balance allocation. Fixes: 857b46027d6f ("netfilter: nft_ct: add ct expectations support") Cc: stable@vger.kernel.org Signed-off-by: Li Xiasong Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit a9f76de38ba32389f8c2e3bc3b7fb1d62e2f8f77 Author: Mario Limonciello Date: Mon May 4 18:01:37 2026 -0500 Revert "ACPI: CPPC: Adjust debug messages in amd_set_max_freq_ratio() to warn" commit db5dadb562cabb6da49959b473ed0d9645b6f2da upstream. Some older systems don't support CPPC in the firmware and this just makes noise for them when booting. Drop back to debug. This reverts commit 21fb59ab4b9767085f4fe1edbdbe3177fbb9ec97. Fixes: 21fb59ab4b976 ("ACPI: CPPC: Adjust debug messages in amd_set_max_freq_ratio() to warn") Suggested-by: Kim Phillips Signed-off-by: Mario Limonciello Tested-by: Kim Phillips Cc: All applicable Link: https://patch.msgid.link/20260504230141.484743-2-mario.limonciello@amd.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 722b91d5086a249318c9d0e2b36aeac80ba8c808 Author: Greg Kroah-Hartman Date: Wed May 6 14:48:13 2026 -0700 idpf: fix double free and use-after-free in aux device error paths commit 6c77b9510829a424d1b74409b7db9456e3522871 upstream. When auxiliary_device_add() fails in idpf_plug_vport_aux_dev() or idpf_plug_core_aux_dev(), the err_aux_dev_add label calls auxiliary_device_uninit() and falls through to err_aux_dev_init. The uninit call will trigger put_device(), which invokes the release callback (idpf_vport_adev_release / idpf_core_adev_release) that frees iadev. The fall-through then reads adev->id from the freed iadev for ida_free() and double-frees iadev with kfree(). Free the IDA slot and clear the back-pointer before uninit, while adev is still valid, then return immediately. Commit 65637c3a1811 ("idpf: fix UAF in RDMA core aux dev deinitialization") fixed the same use-after-free in the matching unplug path in this file but missed both probe error paths. Cc: Tony Nguyen Cc: Przemek Kitszel Cc: Andrew Lunn Cc: stable@kernel.org Fixes: be91128c579c ("idpf: implement RDMA vport auxiliary dev create, init, and destroy") Fixes: f4312e6bfa2a ("idpf: implement core RDMA auxiliary dev create, init, and destroy") Signed-off-by: Greg Kroah-Hartman Reviewed-by: Aleksandr Loktionov Reviewed-by: Paul Menzel Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260506-jk-iwl-net-2026-05-04-v2-4-a5ea4dc837a9@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c4a8998aafb87aeb2d3e0f00e01595e63126b4fb Author: Guopeng Zhang Date: Mon May 11 09:31:50 2026 +0800 cgroup/dmem: Return -ENOMEM on failed pool preallocation commit 796ad622040f7f955ccc3973085e953415920496 upstream. get_cg_pool_unlocked() handles allocation failures under dmemcg_lock by dropping the lock, preallocating a pool with GFP_KERNEL, and retrying the locked lookup and creation path. If the fallback allocation fails too, pool remains NULL. Since the loop condition is while (!pool), the function can keep retrying instead of propagating the allocation failure to the caller. Set pool to ERR_PTR(-ENOMEM) when the fallback allocation fails so the loop exits through the existing common return path. The callers already handle ERR_PTR() from get_cg_pool_unlocked(), so this restores the expected error path. Fixes: b168ed458dde ("kernel/cgroup: Add "dmem" memory accounting cgroup") Cc: stable@vger.kernel.org # v6.14+ Signed-off-by: Guopeng Zhang Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit bddf59818ae5102e6d82a4dae5add6df8da38fb0 Author: Arthur Kiyanovski Date: Thu May 7 00:35:15 2026 +0000 net: ena: PHC: Check return code before setting timestamp output commit 24a08d7d6218d60c033015cf4870b6096446e734 upstream. ena_phc_gettimex64() is setting the output parameter regardless of whether ena_com_phc_get_timestamp() succeeded or failed. When ena_com_phc_get_timestamp() returns an error, the timestamp parameter may contain uninitialized stack memory (e.g., when PHC is disabled or in blocked state) or invalid hardware values. Passing these to userspace via the PTP ioctl is both a security issue (information leak) and a correctness bug. Fix by checking the return code after releasing the lock and only setting the output timestamp on success. Fixes: e0ea34158ee8 ("net: ena: Add PHC support in the ENA driver") Cc: stable@vger.kernel.org Signed-off-by: Arthur Kiyanovski Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260507003518.22554-1-akiyano@amazon.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e35f3550c5b4fab33103c18654c293cee9850b0a Author: Sergio Correia Date: Tue May 12 14:28:33 2026 +0100 audit: fix incorrect inheritable capability in CAPSET records commit e4a640475e43f406fdfd56d370b1f34b0cbbc18d upstream. __audit_log_capset() records the effective capability set into the inheritable field due to a copy-paste error. Every CAPSET audit record therefore reports cap_pi (process inheritable) with the value of cap_effective instead of cap_inheritable. This silently corrupts audit data used for compliance and forensic analysis: an attacker who modifies inheritable capabilities to prepare for a privilege-escalating exec would have the change masked in the audit trail. The bug has been present since the original introduction of CAPSET audit records in 2008. Cc: stable@vger.kernel.org Fixes: e68b75a027bb ("When the capset syscall is used it is not possible for audit to record the actual capbilities being added/removed. This patch adds a new record type which emits the target pid and the eff, inh, and perm cap sets.") Reviewed-by: Ricardo Robaina Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Sergio Correia Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 430b05f6c9183b7d5dc64b2250aaae86c73c61f6 Author: Li Xiasong Date: Thu May 7 22:04:22 2026 +0800 netfilter: nf_conntrack_sip: get helper before allocating expectation commit eb6317739b1ea3ab28791e1f91b24781905fa815 upstream. process_register_request() allocates an expectation and then checks whether a conntrack helper is available. If helper lookup fails, the function returns early and the allocated expectation is left behind. Reorder the code to fetch and validate helper before calling nf_ct_expect_alloc(). This keeps the logic simpler and removes the leak path while preserving existing behavior. Fixes: e14575fa7529 ("netfilter: nf_conntrack: use rcu accessors where needed") Cc: stable@vger.kernel.org Signed-off-by: Li Xiasong Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 95e8ae9af2a61b4e72f5c585bf4c7d8aaf2a2c98 Author: Arthur Kiyanovski Date: Fri May 8 06:21:21 2026 +0000 net: ena: PHC: Fix potential use-after-free in get_timestamp commit e42c755582f0960e684298762f0ab927b3778376 upstream. Move the phc->active check and resp pointer assignment to after acquiring the spinlock. Previously, phc->active was checked without holding the lock, and resp was cached from ena_dev->phc.virt_addr before the lock was acquired. If ena_com_phc_destroy() runs between the lockless active check and the lock acquisition, it sets active=false, releases the lock, frees the DMA memory, and sets virt_addr=NULL. The get_timestamp path would then read a NULL virt_addr and dereference it. With both the active check and the pointer read under the lock, destroy cannot free the memory while get_timestamp is using it. Fixes: e0ea34158ee8 ("net: ena: Add PHC support in the ENA driver") Cc: stable@vger.kernel.org Signed-off-by: Arthur Kiyanovski Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260508062126.7273-1-akiyano@amazon.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 10addc25fa17c3404d6e4cfe7db0019a43e774b2 Author: Breno Leitao Date: Fri May 8 09:22:03 2026 -0700 workqueue: Fix wq->cpu_pwq leak in alloc_and_link_pwqs() WQ_UNBOUND path commit 0143033dc22cdff912cfc13419f5db92fea3b4cb upstream. For WQ_UNBOUND workqueues, alloc_and_link_pwqs() allocates wq->cpu_pwq via alloc_percpu() and then calls apply_workqueue_attrs_locked(). On failure it returns the error directly, bypassing the enomem: label which holds the only free_percpu(wq->cpu_pwq) in this function. The caller's error path kfree()s wq without touching wq->cpu_pwq, leaking one percpu pointer table (nr_cpu_ids * sizeof(void *) bytes) per failed call. If kmemleak is enabled, we can see: unreferenced object (percpu) 0xc0fffa5b121048 (size 8): comm "insmod", pid 776, jiffies 4294682844 backtrace (crc 0): pcpu_alloc_noprof+0x665/0xac0 __alloc_workqueue+0x33f/0xa20 alloc_workqueue_noprof+0x60/0x100 Route the error through the existing enomem: cleanup and any error before this one. Cc: stable@kernel.org Fixes: 636b927eba5b ("workqueue: Make unbound workqueues to use per-cpu pool_workqueues") Signed-off-by: Breno Leitao Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit f4324006879118b25b8e7d2bdb46c891d51b399d Author: Matt Vollrath Date: Wed May 6 14:48:11 2026 -0700 i40e: Cleanup PTP pins on probe failure commit 678b713ece1e853f11e670a84cb887c35e1381b7 upstream. PTP pin structs are allocated early in probe, but never cleaned up. Fix this by calling i40e_ptp_free_pins in the error path. To support this, i40e_ptp_free_pins is added to the header and pin_config is correctly nullified after being freed. This has been an issue since i40e_ptp_alloc_pins was introduced. Fixes: 1050713026a08 ("i40e: add support for PTP external synchronization clock") Reported-by: Kohei Enju Cc: stable@vger.kernel.org Signed-off-by: Matt Vollrath Reviewed-by: Paul Menzel Reviewed-by: Aleksandr Loktionov Reviewed-by: Kohei Enju Tested-by: Sunitha Mekala Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260506-jk-iwl-net-2026-05-04-v2-2-a5ea4dc837a9@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a1c5672faf8e93e38c2deac3979cc767ca5cf918 Author: Herbert Xu Date: Tue May 5 17:02:45 2026 +0800 crypto: af_alg - Cap AEAD AD length to 0x80000000 commit e4c06479d7059888adf2f22bc1ebcf053bf691a2 upstream. 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: Greg Kroah-Hartman commit b4e1c03b876c71b8567b190e66beab8293480763 Author: Vincent Guittot Date: Fri Jan 23 11:28:58 2026 +0100 sched/fair: Revert force wakeup preemption [ Upstream commit 15257cc2f905dbf5813c0bfdd3c15885f28093c4 ] This agressively bypasses run_to_parity and slice protection with the assumpiton that this is what waker wants but there is no garantee that the wakee will be the next to run. It is a better choice to use yield_to_task or WF_SYNC in such case. This increases the number of resched and preemption because a task becomes quickly "ineligible" when it runs; We update the task vruntime periodically and before the task exhausted its slice or at least quantum. Example: 2 tasks A and B wake up simultaneously with lag = 0. Both are eligible. Task A runs 1st and wakes up task C. Scheduler updates task A's vruntime which becomes greater than average runtime as all others have a lag == 0 and didn't run yet. Now task A is ineligible because it received more runtime than the other task but it has not yet exhausted its slice nor a min quantum. We force preemption, disable protection but Task B will run 1st not task C. Sidenote, DELAY_ZERO increases this effect by clearing positive lag at wake up. Fixes: e837456fdca8 ("sched/fair: Reimplement NEXT_BUDDY to align with EEVDF goals") Signed-off-by: Vincent Guittot Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260123102858.52428-1-vincent.guittot@linaro.org Signed-off-by: Sasha Levin commit ec4f6da3373d21993229ef9f1e16a92045e5acee Author: Vincent Guittot Date: Sun May 3 12:45:03 2026 +0200 sched/fair: Fix wakeup_preempt_fair() for not waking up task [ Upstream commit 9f6d929ee2c6f0266edb564bcd2bd47fd6e884a8 ] Make sure to only call pick_next_entity() on an non-empty cfs_rq. The assumption that p is always enqueued and not delayed, is only true for wakeup. If p was moved while delayed, pick_next_entity() will dequeue it and the cfs might become empty. Test if there are still queued tasks before trying again to determine if p could be the next one to be picked. There are at least 2 cases: When cfs becomes idle, it tries to pull tasks but if those pulled tasks are delayed, they will be dequeued when attached to cfs. attach_tasks() -> attach_task() -> wakeup_preempt(rq, p, 0); A misfit task running on cfs A triggers a load balance to be pulled on a better cpu, the load balance on cfs B starts an active load balance to pulled the running misfit task. If there is a delayed dequeue task on cfs A, it can be pulled instead of the previously running misfit task. attach_one_task() -> attach_task() -> wakeup_preempt(rq, p, 0); Fixes: ac8e69e69363 ("sched/fair: Fix wakeup_preempt_fair() vs delayed dequeue") Signed-off-by: Vincent Guittot Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260503104503.1732682-1-vincent.guittot@linaro.org Signed-off-by: Sasha Levin commit ce8ac8432fd72ad48b8445378980dd1a760b41b4 Author: Erni Sri Satya Vennela Date: Mon Apr 20 05:47:36 2026 -0700 net: mana: Init gf_stats_work before potential error paths in probe [ Upstream commit 6e8bc03349fe4f09567fa76235abf52bdaf83082 ] Move INIT_DELAYED_WORK(gf_stats_work) to before mana_create_eq(), while keeping schedule_delayed_work() at its original location. Previously, if any function between mana_create_eq() and the INIT_DELAYED_WORK call failed, mana_probe() would call mana_remove() which unconditionally calls cancel_delayed_work_sync(gf_stats_work) in __flush_work() or debug object warnings with CONFIG_DEBUG_OBJECTS_WORK enabled. Fixes: be4f1d67ec56 ("net: mana: Add standard counter rx_missed_errors") Signed-off-by: Erni Sri Satya Vennela Link: https://patch.msgid.link/20260420124741.1056179-3-ernis@linux.microsoft.com Reviewed-by: Simon Horman Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 45d6c6c10b8b3342cbb2e0b8d588d6d52039031b Author: Dipayaan Roy Date: Thu Dec 18 05:10:54 2025 -0800 net: mana: Fix use-after-free in reset service rescan path [ Upstream commit 3387a7ad478b46970ae8254049167d166e398aeb ] When mana_serv_reset() encounters -ETIMEDOUT or -EPROTO from mana_gd_resume(), it performs a PCI rescan via mana_serv_rescan(). mana_serv_rescan() calls pci_stop_and_remove_bus_device(), which can invoke the driver's remove path and free the gdma_context associated with the device. After returning, mana_serv_reset() currently jumps to the out label and attempts to clear gc->in_service, dereferencing a freed gdma_context. The issue was observed with the following call logs: [ 698.942636] BUG: unable to handle page fault for address: ff6c2b638088508d [ 698.943121] #PF: supervisor write access in kernel mode [ 698.943423] #PF: error_code(0x0002) - not-present page [S[ 698.943793] Pat Dec 6 07:GD5 100000067 P4D 1002f7067 PUD 1002f8067 PMD 101bef067 PTE 0 0:56 2025] hv_[n e 698.944283] Oops: Oops: 0002 [#1] SMP NOPTI tvsc f8615163-00[ 698.944611] CPU: 28 UID: 0 PID: 249 Comm: kworker/28:1 ... [Sat Dec 6 07:50:56 2025] R10: [ 699.121594] mana 7870:00:00.0 enP30832s1: Configured vPort 0 PD 18 DB 16 000000000000001b R11: 0000000000000000 R12: ff44cf3f40270000 [Sat Dec 6 07:50:56 2025] R13: 0000000000000001 R14: ff44cf3f402700c8 R15: ff44cf3f4021b405 [Sat Dec 6 07:50:56 2025] FS: 0000000000000000(0000) GS:ff44cf7e9fcf9000(0000) knlGS:0000000000000000 [Sat Dec 6 07:50:56 2025] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [Sat Dec 6 07:50:56 2025] CR2: ff6c2b638088508d CR3: 000000011fe43001 CR4: 0000000000b73ef0 [Sat Dec 6 07:50:56 2025] Call Trace: [Sat Dec 6 07:50:56 2025] [Sat Dec 6 07:50:56 2025] mana_serv_func+0x24/0x50 [mana] [Sat Dec 6 07:50:56 2025] process_one_work+0x190/0x350 [Sat Dec 6 07:50:56 2025] worker_thread+0x2b7/0x3d0 [Sat Dec 6 07:50:56 2025] kthread+0xf3/0x200 [Sat Dec 6 07:50:56 2025] ? __pfx_worker_thread+0x10/0x10 [Sat Dec 6 07:50:56 2025] ? __pfx_kthread+0x10/0x10 [Sat Dec 6 07:50:56 2025] ret_from_fork+0x21a/0x250 [Sat Dec 6 07:50:56 2025] ? __pfx_kthread+0x10/0x10 [Sat Dec 6 07:50:56 2025] ret_from_fork_asm+0x1a/0x30 [Sat Dec 6 07:50:56 2025] Fix this by returning immediately after mana_serv_rescan() to avoid accessing GC state that may no longer be valid. Fixes: 9bf66036d686 ("net: mana: Handle hardware recovery events when probing the device") Reviewed-by: Simon Horman Reviewed-by: Long Li Signed-off-by: Dipayaan Roy Link: https://patch.msgid.link/20251218131054.GA3173@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 80c025618524d47907a1cd0b3783f874c78ef924 Author: Lorenzo Bianconi Date: Sun Apr 12 09:57:29 2026 +0200 net: airoha: Fix VIP configuration for AN7583 SoC [ Upstream commit 1acdfbdb516b32165a8ecd1d5f8c68e4eac64637 ] EN7581 and AN7583 SoCs have different VIP definitions. Introduce get_vip_port callback in airoha_eth_soc_data struct in order to take into account EN7581 and AN7583 VIP register layout and definition differences. Introduce nbq parameter in airoha_gdm_port struct. At the moment nbq is set statically to value previously used in airhoha_set_gdm2_loopback routine and it will be read from device tree in subsequent patches. Fixes: e4e5ce823bdd ("net: airoha: Add AN7583 SoC support") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260412-airoha-7583-vip-fix-v1-1-c35e02b054bb@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 81a2a3607866b713220bdc39243300673b1040af Author: Lorenzo Bianconi Date: Mon Jan 5 10:40:47 2026 +0100 net: airoha: Use gdm port enum value whenever possible [ Upstream commit 4d513329b87c1bd0546d9f0288794e244322daa6 ] Use AIROHA_GDMx_IDX enum value whenever possible. This patch is just cosmetic changes and does not introduce any logic one. Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260105-airoha-use-port-idx-enum-v1-1-503ca5763858@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: 1acdfbdb516b ("net: airoha: Fix VIP configuration for AN7583 SoC") Signed-off-by: Sasha Levin commit 106581064439cde70cf9e1accea8c76bcbbe20a1 Author: Lorenzo Bianconi Date: Wed Oct 22 09:11:12 2025 +0200 net: airoha: Remove code duplication in airoha_regs.h [ Upstream commit 99ad2b6815f41acbec15ab051ccc79b11b05710a ] This patch does not introduce any logical change, it just removes duplicated code in airoha_regs.h. Fix naming conventions in airoha_regs.h. Reviewed-by: Simon Horman Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251022-airoha-regs-cosmetics-v2-1-e0425b3f2c2c@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: 1acdfbdb516b ("net: airoha: Fix VIP configuration for AN7583 SoC") Signed-off-by: Sasha Levin commit db9af8a2efada5a4c5c2c6768a1706eb5d0f3106 Author: Eric Dumazet Date: Thu Apr 30 08:00:56 2026 +0000 net/sched: sch_pie: annotate more data-races in pie_dump_stats() [ Upstream commit 6d4106e8df94c0c52cf3ca6a6a0d01567fb3844e ] My prior patch missed few READ_ONCE()/WRITE_ONCE() annotations. Fixes: 5154561d9b11 ("net/sched: sch_pie: annotate data-races in pie_dump_stats()") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260430080056.35104-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 90619fdedfb9cc8a80f217d882ee7a84d3703e72 Author: Lorenzo Bianconi Date: Fri Apr 17 08:36:31 2026 +0200 net: airoha: Move ndesc initialization at end of airoha_qdma_init_tx() [ Upstream commit f329924bb49458c65297f1361f545816a5b90998 ] If queue entry list allocation fails in airoha_qdma_init_tx_queue routine, airoha_qdma_cleanup_tx_queue() will trigger a NULL pointer dereference accessing the queue entry array. The issue is due to the early ndesc initialization in airoha_qdma_init_tx_queue(). Fix the issue moving ndesc initialization at end of airoha_qdma_init_tx routine. Fixes: 3f47e67dff1f7 ("net: airoha: Add the capability to consume out-of-order DMA tx descriptors") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260417-airoha_qdma_cleanup_tx_queue-fix-net-v4-1-e04bcc2c9642@kernel.org Reviewed-by: Simon Horman Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 7645ead02939e0caa9d1655981a371c8fc06b7ab Author: Lorenzo Bianconi Date: Wed Apr 29 14:02:31 2026 +0200 net: airoha: Move entries to queue head in case of DMA mapping failure in airoha_dev_xmit() [ Upstream commit 75df490c9e8457990c8b227650f6491218ce018b ] In order to respect the original descriptor order and avoid any potential IOMMU fault or memory corruption, move pending queue entries to the head of hw queue tx_list if the DMA mapping of current inflight packet fails in airoha_dev_xmit routine. Fixes: 3f47e67dff1f7 ("net: airoha: Add the capability to consume out-of-order DMA tx descriptors") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260429-airoha-xmit-unmap-error-path-v2-1-32e43b7c6d25@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 95fdee73c39c9f674e22eee4839e6698baa3ad28 Author: Costa Shulyupin Date: Mon Jan 12 21:26:41 2026 +0200 rtla: Fix parse_cpu_set() bug introduced by strtoi() [ Upstream commit 6ea8a206108fe8b5940c2797afc54ae9f5a7bbdd ] The patch 'Replace atoi() with a robust strtoi()' introduced a bug in parse_cpu_set(), which relies on partial parsing of the input string. The function parses CPU specifications like '0-3,5' by incrementing a pointer through the string. strtoi() rejects strings with trailing characters, causing parse_cpu_set() to fail on any CPU list with multiple entries. Restore the original use of atoi() in parse_cpu_set(). Fixes: 7e9dfccf8f11 ("rtla: Replace atoi() with a robust strtoi()") Signed-off-by: Costa Shulyupin Reviewed-by: Masami Hiramatsu (Google) Link: https://lore.kernel.org/r/20260112192642.212848-2-costa.shul@redhat.com Signed-off-by: Tomas Glozar Signed-off-by: Sasha Levin commit 26b4ea23f511e771a90efd394097c564360a5edc Author: Dan Carpenter Date: Fri Oct 24 14:23:35 2025 +0300 net: airoha: Fix a copy and paste bug in probe() [ Upstream commit 05e090620bacf317020f9591cfff8926093380bd ] This code has a copy and paste bug where it accidentally checks "if (err)" instead of checking if "xsi_rsts" is NULL. Also, as a free bonus, I changed the allocation from kzalloc() to kcalloc() which is a kernel hardening measure to protect against integer overflows. Fixes: 5863b4e065e2 ("net: airoha: Add airoha_eth_soc_data struct") Signed-off-by: Dan Carpenter Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/aPtht6y5DRokn9zv@stanley.mountain Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dbbd60129f7908d49c6de3a29d2059defeb7f9ec Author: Daniel Borkmann Date: Thu Mar 19 22:15:06 2026 +0100 bpf: Fix sync_linked_regs regarding BPF_ADD_CONST32 zext propagation [ Upstream commit bc308be380c136800e1e94c6ce49cb53141d6506 ] Jenny reported that in sync_linked_regs() the BPF_ADD_CONST32 flag is checked on known_reg (the register narrowed by a conditional branch) instead of reg (the linked target register created by an alu32 operation). Example case with reg: 1. r6 = bpf_get_prandom_u32() 2. r7 = r6 (linked, same id) 3. w7 += 5 (alu32 -- r7 gets BPF_ADD_CONST32, zero-extended by CPU) 4. if w6 < 0xFFFFFFFC goto safe (narrows r6 to [0xFFFFFFFC, 0xFFFFFFFF]) 5. sync_linked_regs() propagates to r7 but does NOT call zext_32_to_64() 6. Verifier thinks r7 is [0x100000001, 0x100000004] instead of [1, 4] Since known_reg above does not have BPF_ADD_CONST32 set above, zext_32_to_64() is never called on alu32-derived linked registers. This causes the verifier to track incorrect 64-bit bounds, while the CPU correctly zero-extends the 32-bit result. The code checking known_reg->id was correct however (see scalars_alu32_wrap selftest case), but the real fix needs to handle both directions - zext propagation should be done when either register has BPF_ADD_CONST32, since the linked relationship involves a 32-bit operation regardless of which side has the flag. Example case with known_reg (exercised also by scalars_alu32_wrap): 1. r1 = r0; w1 += 0x100 (alu32 -- r1 gets BPF_ADD_CONST32) 2. if r1 > 0x80 - known_reg = r1 (has BPF_ADD_CONST32), reg = r0 (doesn't) Hence, fix it by checking for (reg->id | known_reg->id) & BPF_ADD_CONST32. Moreover, sync_linked_regs() also has a soundness issue when two linked registers used different ALU widths: one with BPF_ADD_CONST32 and the other with BPF_ADD_CONST64. The delta relationship between linked registers assumes the same arithmetic width though. When one register went through alu32 (CPU zero-extends the 32-bit result) and the other went through alu64 (no zero-extension), the propagation produces incorrect bounds. Example: r6 = bpf_get_prandom_u32() // fully unknown if r6 >= 0x100000000 goto out // constrain r6 to [0, U32_MAX] r7 = r6 w7 += 1 // alu32: r7.id = N | BPF_ADD_CONST32 r8 = r6 r8 += 2 // alu64: r8.id = N | BPF_ADD_CONST64 if r7 < 0xFFFFFFFF goto out // narrows r7 to [0xFFFFFFFF, 0xFFFFFFFF] At the branch on r7, sync_linked_regs() runs with known_reg=r7 (BPF_ADD_CONST32) and reg=r8 (BPF_ADD_CONST64). The delta path computes: r8 = r7 + (delta_r8 - delta_r7) = 0xFFFFFFFF + (2 - 1) = 0x100000000 Then, because known_reg->id has BPF_ADD_CONST32, zext_32_to_64(r8) is called, truncating r8 to [0, 0]. But r8 used a 64-bit ALU op -- the CPU does NOT zero-extend it. The actual CPU value of r8 is 0xFFFFFFFE + 2 = 0x100000000, not 0. The verifier now underestimates r8's 64-bit bounds, which is a soundness violation. Fix sync_linked_regs() by skipping propagation when the two registers have mixed ALU widths (one BPF_ADD_CONST32, the other BPF_ADD_CONST64). Lastly, fix regsafe() used for path pruning: the existing checks used "& BPF_ADD_CONST" to test for offset linkage, which treated BPF_ADD_CONST32 and BPF_ADD_CONST64 as equivalent. Fixes: 7a433e519364 ("bpf: Support negative offsets, BPF_SUB, and alu32 for linked register tracking") Reported-by: Jenny Guanni Qu Co-developed-by: Puranjay Mohan Signed-off-by: Puranjay Mohan Signed-off-by: Daniel Borkmann Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260319211507.213816-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 22f72b1dccfe98e886cfddc5e6598d16d6613f39 Author: Samiullah Khawaja Date: Tue May 5 23:43:27 2026 +0000 PCI: Initialize temporary device in new_id_store() [ Upstream commit f45a49a2380a47332817b7248c61a0ebbc6f0d00 ] When setting new_id of a PCI device driver using sysfs a lockdep splat occurs. This is because new_id_store() builds a temporary pci_dev for pci_match_device(), which calls device_match_driver_override(). That depends on the driver_override.lock added by cb3d1049f4ea ("driver core: generalize driver_override in struct device"). The new driver_override.lock was not initialized in the temporary pci_dev, resulting in this lockdep splat. Initialize the temporary pci_dev to fix this. Repro: Build with CONFIG_LOCKDEP=y, boot with QEMU, and add a new ID: # echo "8086 10f5" > /sys/bus/pci/drivers/e1000e/new_id INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 2 UID: 0 PID: 177 Comm: liveupdate-iomm Not tainted 7.0.0+ #9 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x5d/0x80 register_lock_class+0x77e/0x790 lock_acquire+0xbf/0x2e0 pci_match_device+0x24/0x180 new_id_store+0x189/0x1d0 kernfs_fop_write_iter+0x14f/0x210 vfs_write+0x263/0x5e0 ksys_write+0x79/0xf0 do_syscall_64+0x117/0xf80 Fixes: 10a4206a2401 ("PCI: use generic driver_override infrastructure") Fixes: 8895d3bcb8ba ("PCI: Fail new_id for vendor/device values already built into driver") Signed-off-by: Samiullah Khawaja [bhelgaas: add commit log details and repro, trim backtrace] Signed-off-by: Bjorn Helgaas Reviewed-by: Danilo Krummrich Link: https://patch.msgid.link/20260505234327.716630-1-skhawaja@google.com Signed-off-by: Sasha Levin commit 735439394dde8462f9b50566727fbe333beaadaf Author: Sasha Levin Date: Mon May 18 11:13:17 2026 -0400 Revert "papr-hvpipe: convert papr_hvpipe_dev_create_handle() to FD_PREPARE()" This reverts commit 09c15bbbed533903e600660ea09098b3b0524f48. Signed-off-by: Sasha Levin commit d66dc9505935c4c2c0b349407b37066dcbed48a8 Author: Sasha Levin Date: Mon May 18 11:13:17 2026 -0400 Revert "pseries/papr-hvpipe: Fix race with interrupt handler" This reverts commit 6542e180fa6e1c701aba446a555c65556e6fd1a5. Signed-off-by: Sasha Levin commit 1dcd36420af2da5bd59306dba9caf78e3d248b1d Author: Davidlohr Bueso Date: Fri May 1 12:41:23 2026 -0700 futex: Drop CLONE_THREAD requirement for private default hash alloc [ Upstream commit ee9dce44362b2d8132c32964656ab6dff7dfbc6a ] Currently need_futex_hash_allocate_default() depends on strict pthread semantics, abusing CLONE_THREAD. This breaks the non-concurrency assumptions when doing the mm->futex_ref pcpu allocations, leading to bugs[0] when sharing the mm in other ways; ie: BUG: KASAN: slab-use-after-free in futex_hash_put ... where the +1 bias can end up on a percpu counter that mm->futex_ref no longer points at. Loosen the check to cover any CLONE_VM clone, except vfork(). Excluding vfork keeps the existing paths untouched (no overhead), and we can't race in the first place: either the parent is suspended and the child runs alone, or mm->futex_ref is already allocated from an earlier CLONE_VM. Link: https://lore.kernel.org/all/CAL_bE8LsmCQ-FAtYDuwbJhOkt9p2wwYQwAbMh=PifC=VsiBM6A@mail.gmail.com/ [0] Fixes: d9b05321e21e ("futex: Move futex_hash_free() back to __mmput()") Reported-by: Yiming Qian Signed-off-by: Davidlohr Bueso Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit dcb89deed40ba55ff7020061712fdabf098cc2cc Author: Zhaoyang Huang Date: Thu Apr 30 16:58:08 2026 +0800 arm64: Reserve an extra page for early kernel mapping [ Upstream commit 4d8e74ad4585672489da6145b3328d415f50db82 ] The final part of [data, end) segment may overflow into the next page of init_pg_end[1] which is the gap page before early_init_stack[2]: [1] crash_arm64_v9.0.1> vtop ffffffed00601000 VIRTUAL PHYSICAL ffffffed00601000 83401000 PAGE DIRECTORY: ffffffecffd62000 PGD: ffffffecffd62da0 => 10000000833fb003 PMD: ffffff80033fb018 => 10000000833fe003 PTE: ffffff80033fe008 => 68000083401f03 PAGE: 83401000 PTE PHYSICAL FLAGS 68000083401f03 83401000 (VALID|SHARED|AF|NG|PXN|UXN) PAGE PHYSICAL MAPPING INDEX CNT FLAGS fffffffec00d0040 83401000 0 0 1 4000 reserved [2] ffffffed002c8000 (r) __pi__data ffffffed0054e000 (d) __pi___bss_start ffffffed005f5000 (b) __pi_init_pg_dir ffffffed005fe000 (b) __pi_init_pg_end ffffffed005ff000 (B) early_init_stack ffffffed00608000 (b) __pi__end For 4K pages, the early kernel mapping may use 2MB block entries but the kernel segments are only 64KB aligned. Segment boundaries that fall within a 2MB block therefore require a PTE table so that different attributes can be applied on either side of the boundary. KERNEL_SEGMENT_COUNT still correctly counts the five permanent kernel VMAs registered by declare_kernel_vmas(). However, since commit 5973a62efa34 ("arm64: map [_text, _stext) virtual address range non-executable+read-only"), the early mapper also maps [_text, _stext) separately from [_stext, _etext). This adds one more early-only split and can require one more page-table page than the existing EARLY_SEGMENT_EXTRA_PAGES allowance reserves. Increase the 4K-page early mapping allowance by one page to cover that additional split. Fixes: 5973a62efa34 ("arm64: map [_text, _stext) virtual address range non-executable+read-only") Assisted-by: TRAE:GLM-5.1 Suggested-by: Ard Biesheuvel Signed-off-by: Zhaoyang Huang [catalin.marinas@arm.com: rewrote part of the commit log] [catalin.marinas@arm.com: expanded the code comment] Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit b9d854388988ccaf0d3d4f674cffd731d246ad0c Author: Leo Yan Date: Wed Apr 29 15:30:10 2026 +0100 kselftest/arm64: Include for user_gcs definition [ Upstream commit bb7235e226888607e6aac1288062fcb1ac105589 ] kselftest includes kernel uAPI headers with option: -isystem $(top_srcdir)/usr/include Include in libc-gcs.c for the definition of struct user_gcs from the uAPI headers, and remove the redundant definition in gcs-util.h. This fixes a compilation error on systems where the toolchain defines NT_ARM_GCS. Fixes: a505a52b4e29 ("kselftest/arm64: Add a GCS test program built with the system libc") Signed-off-by: Leo Yan Reviewed-by: Mark Brown Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 5704a90c09708040067abcbd2d837865ec6a49a5 Author: Paolo Abeni Date: Wed Apr 29 09:39:11 2026 +0200 net/sched: cls_flower: revert unintended changes [ Upstream commit 1e01abec856593e02cd69fd95b784c10dd46880c ] While applying the blamed commit 4ca07b9239bd ("net: mctp i2c: check length before marking flow active"), I unintentionally included unrelated and unacceptable changes. Revert them. Fixes: 4ca07b9239bd ("net: mctp i2c: check length before marking flow active") Reported-by: Jeremy Kerr Closes: https://lore.kernel.org/netdev/bd8704fe0bd53e278add5cde4873256656623e2e.camel@codeconstruct.com.au/ Signed-off-by: Paolo Abeni Link: https://patch.msgid.link/043026a53ff84da88b17648c4b0d17f0331749cb.1777447863.git.pabeni@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 3f4a3f740c2337a5e9ad1a49726f62045a7f7c1e Author: Dan Carpenter Date: Wed Apr 29 09:48:17 2026 +0300 sfc: fix error code in efx_devlink_info_running_versions() [ Upstream commit 051ffb001b8a232cfa6e72f38bb5f51c4270a60b ] Return -EIO if efx_mcdi_rpc() doesn't return enough space. Fixes: 14743ddd2495 ("sfc: add devlink info support for ef100") Signed-off-by: Dan Carpenter Reviewed-by: Edward Cree Link: https://patch.msgid.link/afGpsbLRHL4_H0KS@stanley.mountain Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 9c54e76f8d6eb11735918777ef0e0509e089557d Author: Jakub Kicinski Date: Tue Apr 28 16:15:59 2026 -0700 net: tls: fix strparser anchor skb leak on offload RX setup failure [ Upstream commit 58689498ca3384851145a754dbb1d8ed1cf9fb54 ] When tls_set_device_offload_rx() fails at tls_dev_add(), the error path calls tls_sw_free_resources_rx() to clean up the SW context that was initialized by tls_set_sw_offload(). This function calls tls_sw_release_resources_rx() (which stops the strparser via tls_strp_stop()) and tls_sw_free_ctx_rx() (which kfrees the context), but never frees the anchor skb that was allocated by alloc_skb(0) in tls_strp_init(). Note that tls_sw_free_resources_rx() is exclusively used for this "failed to start offload" code path, there's no other caller. The leak did not exist before commit 84c61fe1a75b ("tls: rx: do not use the standard strparser"), because the standard strparser doesn't try to pre-allocate an skb. The normal close path in tls_sk_proto_close() handles cleanup by calling tls_sw_strparser_done() (which calls tls_strp_done()) after dropping the socket lock, because tls_strp_done() does cancel_work_sync() and the strparser work handler takes the socket lock. Fixes: 84c61fe1a75b ("tls: rx: do not use the standard strparser") Signed-off-by: Jakub Kicinski Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260428231559.1358502-1-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f5c5692a61f7d5bbc47086870c1660a87f2df29c Author: Petr Oros Date: Mon Apr 27 22:22:23 2026 -0700 ice: add dpll peer notification for paired SMA and U.FL pins [ Upstream commit 9e5dead140af10e8b5f975b8f04e46197d48d274 ] SMA and U.FL pins share physical signal paths in pairs (SMA1/U.FL1 and SMA2/U.FL2). When one pin's state changes via a PCA9575 GPIO write, the paired pin's state also changes, but no notification is sent for the peer pin. Userspace consumers monitoring the peer via dpll netlink subscribe never learn about the update. Add ice_dpll_sw_pin_notify_peer() which sends a change notification for the paired SW pin. Call it from ice_dpll_pin_sma_direction_set(), ice_dpll_sma_pin_state_set(), and ice_dpll_ufl_pin_state_set() after pf->dplls.lock is released. Use __dpll_pin_change_ntf() because dpll_lock is still held by the dpll netlink layer (dpll_pin_pre_doit). Fixes: 2dd5d03c77e2 ("ice: redesign dpll sma/u.fl pins control") Signed-off-by: Petr Oros Tested-by: Alexander Nowlin Reviewed-by: Arkadiusz Kubalewski Reviewed-by: Aleksandr Loktionov Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-11-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f5f1b59bdb129d3abd0d413d256dacf0a6b3e28c Author: Ivan Vecera Date: Mon Apr 27 22:22:21 2026 -0700 dpll: export __dpll_pin_change_ntf() for use under dpll_lock [ Upstream commit 620055cb1036a6125fd912e7a14b47a6572b809b ] Export __dpll_pin_change_ntf() so that drivers can send pin change notifications from within pin callbacks, which are already called under dpll_lock. Using dpll_pin_change_ntf() in that context would deadlock. Add lockdep_assert_held() to catch misuse without the lock held. Acked-by: Vadim Fedorenko Signed-off-by: Ivan Vecera Signed-off-by: Petr Oros Tested-by: Alexander Nowlin Reviewed-by: Arkadiusz Kubalewski Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-9-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni Stable-dep-of: 9e5dead140af ("ice: add dpll peer notification for paired SMA and U.FL pins") Signed-off-by: Sasha Levin commit 47e53940451c977313c4660cbc880904ef3fd8f1 Author: Petr Oros Date: Tue Feb 3 18:39:56 2026 +0100 dpll: Add notifier chain for dpll events [ Upstream commit 2be467588d6bc6ec5988fc254e62a44b865912a0 ] Currently, the DPLL subsystem reports events (creation, deletion, changes) to userspace via Netlink. However, there is no mechanism for other kernel components to be notified of these events directly. Add a raw notifier chain to the DPLL core protected by dpll_lock. This allows other kernel subsystems or drivers to register callbacks and receive notifications when DPLL devices or pins are created, deleted, or modified. Define the following: - Registration helpers: {,un}register_dpll_notifier() - Event types: DPLL_DEVICE_CREATED, DPLL_PIN_CREATED, etc. - Context structures: dpll_{device,pin}_notifier_info to pass relevant data to the listeners. The notification chain is invoked alongside the existing Netlink event generation to ensure in-kernel listeners are kept in sync with the subsystem state. Reviewed-by: Vadim Fedorenko Co-developed-by: Ivan Vecera Signed-off-by: Ivan Vecera Signed-off-by: Petr Oros Reviewed-by: Arkadiusz Kubalewski Reviewed-by: Aleksandr Loktionov Link: https://patch.msgid.link/20260203174002.705176-4-ivecera@redhat.com Signed-off-by: Paolo Abeni Stable-dep-of: 9e5dead140af ("ice: add dpll peer notification for paired SMA and U.FL pins") Signed-off-by: Sasha Levin commit 8bcfd78bbc329cb7f1e5b35322ac979e7c1e18cc Author: Ivan Vecera Date: Tue Feb 3 18:39:54 2026 +0100 dpll: Allow associating dpll pin with a firmware node [ Upstream commit d0f4771e2befbe8de3a16a564c6bbd1d5502cec3 ] Extend the DPLL core to support associating a DPLL pin with a firmware node. This association is required to allow other subsystems (such as network drivers) to locate and request specific DPLL pins defined in the Device Tree or ACPI. * Add a .fwnode field to the struct dpll_pin * Introduce dpll_pin_fwnode_set() helper to allow the provider driver to associate a pin with a fwnode after the pin has been allocated * Introduce fwnode_dpll_pin_find() helper to allow consumers to search for a registered DPLL pin using its associated fwnode handle * Ensure the fwnode reference is properly released in dpll_pin_put() Reviewed-by: Aleksandr Loktionov Reviewed-by: Vadim Fedorenko Signed-off-by: Ivan Vecera Reviewed-by: Arkadiusz Kubalewski Link: https://patch.msgid.link/20260203174002.705176-2-ivecera@redhat.com Signed-off-by: Paolo Abeni Stable-dep-of: 9e5dead140af ("ice: add dpll peer notification for paired SMA and U.FL pins") Signed-off-by: Sasha Levin commit a723643ee05542c6544fbb7e23bc1981f67381aa Author: Petr Oros Date: Mon Apr 27 22:22:22 2026 -0700 ice: fix missing dpll notifications for SW pins [ Upstream commit 1a41b58fd4dc80dca16c717e6e77c88b9d4e83a7 ] The SMA/U.FL pin redesign (commit 2dd5d03c77e2 ("ice: redesign dpll sma/u.fl pins control")) introduced software-controlled pins that wrap backing CGU input/output pins, but never updated the notification and data paths to propagate pin events to these SW wrappers. The periodic work sends dpll_pin_change_ntf() only for direct CGU input pins. SW pins that wrap these inputs never receive change or phase offset notifications, so userspace consumers such as synce4l monitoring SMA pins via dpll netlink never learn about state transitions or phase offset updates. Similarly, ice_dpll_phase_offset_get() reads the SW pin's own phase_offset field which is never updated; the PPS monitor writes to the backing CGU input's field instead. Fix by introducing ice_dpll_pin_ntf(), a wrapper around dpll_pin_change_ntf() that also notifies any registered SMA/U.FL pin whose backing CGU input matches. Replace all direct dpll_pin_change_ntf() calls in the periodic notification paths with this wrapper. Fix ice_dpll_phase_offset_get() to return the backing CGU input's phase_offset for input-direction SW pins. Fixes: 2dd5d03c77e2 ("ice: redesign dpll sma/u.fl pins control") Signed-off-by: Petr Oros Tested-by: Alexander Nowlin Reviewed-by: Arkadiusz Kubalewski Reviewed-by: Aleksandr Loktionov Reviewed-by: Ivan Vecera Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-10-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 3b3aab57e33f9d07bc2583a62b17c1539dadc77a Author: Petr Oros Date: Mon Apr 27 22:22:20 2026 -0700 ice: fix SMA and U.FL pin state changes affecting paired pin [ Upstream commit 6f9d8393c9f50fbc68b9c9e99f78ca5a7b43ff44 ] SMA and U.FL pins share physical signal paths in pairs (SMA1/U.FL1 and SMA2/U.FL2) controlled by the PCA9575 GPIO expander. Each pair can only have one active pin at a time: SMA1 output and U.FL1 output share the same CGU output, SMA2 input and U.FL2 input share the same CGU input. The PCA9575 register bits determine which connector in each pair owns the signal path. The driver does not account for this pairing in two places: ice_dpll_ufl_pin_state_set() modifies PCA9575 bits and disables the backing CGU pin without checking whether the U.FL pin is currently active. Disconnecting an already inactive U.FL pin flips bits that the paired SMA pin relies on, breaking its connection. ice_dpll_sma_direction_set() does not propagate direction changes to the paired U.FL pin. For SMA2/U.FL2 the ICE_SMA2_UFL2_RX_DIS bit is never managed, so U.FL2 stays disconnected after SMA2 switches to output. For both pairs the backing CGU pin of the U.FL side is never enabled when a direction change activates it, so userspace sees the pin as disconnected even though the routing is correct. Fix by guarding the U.FL disconnect path against inactive pins and by updating the paired U.FL pin fully on SMA direction changes: manage ICE_SMA2_UFL2_RX_DIS for the SMA2/U.FL2 pair and enable the backing CGU pin whenever the peer becomes active. Fixes: 2dd5d03c77e2 ("ice: redesign dpll sma/u.fl pins control") Signed-off-by: Petr Oros Tested-by: Alexander Nowlin Reviewed-by: Arkadiusz Kubalewski Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-8-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 0c56810ce1ba61bfec4e1dab65691aeb7fbe2671 Author: Petr Oros Date: Mon Apr 27 22:22:19 2026 -0700 ice: fix missing SMA pin initialization in DPLL subsystem [ Upstream commit 56a643aed0f0af5c29ebb4593d4917b78344dd48 ] The DPLL SMA/U.FL pin redesign introduced ice_dpll_sw_pin_frequency_get() which gates frequency reporting on the pin's active flag. This flag is determined by ice_dpll_sw_pins_update() from the PCA9575 GPIO expander state. Before the redesign, SMA pins were exposed as direct HW input/output pins and ice_dpll_frequency_get() returned the CGU frequency unconditionally — the PCA9575 state was never consulted. The PCA9575 powers on with all outputs high, setting ICE_SMA1_DIR_EN, ICE_SMA1_TX_EN, ICE_SMA2_DIR_EN and ICE_SMA2_TX_EN. Nothing in the driver writes the register during initialization, so ice_dpll_sw_pins_update() sees all pins as inactive and ice_dpll_sw_pin_frequency_get() permanently returns 0 Hz for every SW pin. Fix this by writing a default SMA configuration in ice_dpll_init_info_sw_pins(): clear all SMA bits, then set SMA1 and SMA2 as active inputs (DIR_EN=0) with U.FL1 output and U.FL2 input disabled. Each SMA/U.FL pair shares a physical signal path so only one pin per pair can be active at a time. U.FL pins still report frequency 0 after this fix: U.FL1 (output-only) is disabled by ICE_SMA1_TX_EN which keeps the TX output buffer off, and U.FL2 (input-only) is disabled by ICE_SMA2_UFL2_RX_DIS. They can be activated by changing the corresponding SMA pin direction via dpll netlink. Fixes: 2dd5d03c77e2 ("ice: redesign dpll sma/u.fl pins control") Signed-off-by: Petr Oros Reviewed-by: Ivan Vecera Reviewed-by: Arkadiusz Kubalewski Tested-by: Alexander Nowlin Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-7-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c3cad2ae8088e384259c950ae92941318a5d9071 Author: Petr Oros Date: Mon Apr 27 22:22:18 2026 -0700 ice: fix infinite recursion in ice_cfg_tx_topo via ice_init_dev_hw [ Upstream commit 70ad216411e030f67b1743774e245601194aee6a ] On certain E810 configurations where firmware supports Tx scheduler topology switching (tx_sched_topo_comp_mode_en), ice_cfg_tx_topo() may need to apply a new 5-layer or 9-layer topology from the DDP package. If the AQ command to set the topology fails (e.g. due to invalid DDP data or firmware limitations), the global configuration lock must still be cleared via a CORER reset. Commit 86aae43f21cf ("ice: don't leave device non-functional if Tx scheduler config fails") correctly fixed this by refactoring ice_cfg_tx_topo() to always trigger CORER after acquiring the global lock and re-initialize hardware via ice_init_hw() afterwards. However, commit 8a37f9e2ff40 ("ice: move ice_deinit_dev() to the end of deinit paths") later moved ice_init_dev_hw() into ice_init_hw(), breaking the reinit path introduced by 86aae43f21cf. This creates an infinite recursive call chain: ice_init_hw() ice_init_dev_hw() ice_cfg_tx_topo() # topology change needed ice_deinit_hw() ice_init_hw() # reinit after CORER ice_init_dev_hw() # recurse ice_cfg_tx_topo() ... # stack overflow Fix by moving ice_init_dev_hw() back out of ice_init_hw() and calling it explicitly from ice_probe() and ice_devlink_reinit_up(). The third caller, ice_cfg_tx_topo(), intentionally does not need ice_init_dev_hw() during its reinit, it only needs the core HW reinitialization. This breaks the recursion cleanly without adding flags or guards. The deinit ordering changes from commit 8a37f9e2ff40 ("ice: move ice_deinit_dev() to the end of deinit paths") which fixed slow rmmod are preserved, only the init-side placement of ice_init_dev_hw() is reverted. Fixes: 8a37f9e2ff40 ("ice: move ice_deinit_dev() to the end of deinit paths") Signed-off-by: Petr Oros Reviewed-by: Paul Menzel Reviewed-by: Jacob Keller Reviewed-by: Aleksandr Loktionov Reviewed-by: Przemek Kitszel Tested-by: Alexander Nowlin Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-6-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1e9185b13ce57b86844447e092e58abb3be849b1 Author: Petr Oros Date: Mon Apr 27 22:22:17 2026 -0700 ice: fix NULL pointer dereference in ice_reset_all_vfs() [ Upstream commit 54ef02487914c24170c7e1c061e45212dc55365e ] ice_reset_all_vfs() ignores the return value of ice_vf_rebuild_vsi(). When the VSI rebuild fails (e.g. during NVM firmware update via nvmupdate64e), ice_vsi_rebuild() tears down the VSI on its error path, leaving txq_map and rxq_map as NULL. The subsequent unconditional call to ice_vf_post_vsi_rebuild() leads to a NULL pointer dereference in ice_ena_vf_q_mappings() when it accesses vsi->txq_map[0]. The single-VF reset path in ice_reset_vf() already handles this correctly by checking the return value of ice_vf_reconfig_vsi() and skipping ice_vf_post_vsi_rebuild() on failure. Apply the same pattern to ice_reset_all_vfs(): check the return value of ice_vf_rebuild_vsi() and skip ice_vf_post_vsi_rebuild() and ice_eswitch_attach_vf() on failure. The VF is left safely disabled (ICE_VF_STATE_INIT not set, VFGEN_RSTAT not set to VFACTIVE) and can be recovered via a VFLR triggered by a PCI reset of the VF (sysfs reset or driver rebind). Note that this patch does not prevent the VF VSI rebuild from failing during NVM update — the underlying cause is firmware being in a transitional state while the EMP reset is processed, which can cause Admin Queue commands (ice_add_vsi, ice_cfg_vsi_lan) to fail. This patch only prevents the subsequent NULL pointer dereference that crashes the kernel when the rebuild does fail. crash> bt PID: 50795 TASK: ff34c9ee708dc680 CPU: 1 COMMAND: "kworker/u512:5" #0 [ff72159bcfe5bb50] machine_kexec at ffffffffaa8850ee #1 [ff72159bcfe5bba8] __crash_kexec at ffffffffaaa15fba #2 [ff72159bcfe5bc68] crash_kexec at ffffffffaaa16540 #3 [ff72159bcfe5bc70] oops_end at ffffffffaa837eda #4 [ff72159bcfe5bc90] page_fault_oops at ffffffffaa893997 #5 [ff72159bcfe5bce8] exc_page_fault at ffffffffab528595 #6 [ff72159bcfe5bd10] asm_exc_page_fault at ffffffffab600bb2 [exception RIP: ice_ena_vf_q_mappings+0x79] RIP: ffffffffc0a85b29 RSP: ff72159bcfe5bdc8 RFLAGS: 00010206 RAX: 00000000000f0000 RBX: ff34c9efc9c00000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000010 RDI: ff34c9efc9c00000 RBP: ff34c9efc27d4828 R8: 0000000000000093 R9: 0000000000000040 R10: ff34c9efc27d4828 R11: 0000000000000040 R12: 0000000000100000 R13: 0000000000000010 R14: R15: ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ff72159bcfe5bdf8] ice_sriov_post_vsi_rebuild at ffffffffc0a85e2e [ice] #8 [ff72159bcfe5be08] ice_reset_all_vfs at ffffffffc0a920b4 [ice] #9 [ff72159bcfe5be48] ice_service_task at ffffffffc0a31519 [ice] #10 [ff72159bcfe5be88] process_one_work at ffffffffaa93dca4 #11 [ff72159bcfe5bec8] worker_thread at ffffffffaa93e9de #12 [ff72159bcfe5bf18] kthread at ffffffffaa946663 #13 [ff72159bcfe5bf50] ret_from_fork at ffffffffaa8086b9 The panic occurs attempting to dereference the NULL pointer in RDX at ice_sriov.c:294, which loads vsi->txq_map (offset 0x4b8 in ice_vsi). The faulting VSI is an allocated slab object but not fully initialized after a failed ice_vsi_rebuild(): crash> struct ice_vsi 0xff34c9efc27d4828 netdev = 0x0, rx_rings = 0x0, tx_rings = 0x0, q_vectors = 0x0, txq_map = 0x0, rxq_map = 0x0, alloc_txq = 0x10, num_txq = 0x10, alloc_rxq = 0x10, num_rxq = 0x10, The nvmupdate64e process was performing NVM firmware update: crash> bt 0xff34c9edd1a30000 PID: 49858 TASK: ff34c9edd1a30000 CPU: 1 COMMAND: "nvmupdate64e" #0 [ff72159bcd617618] __schedule at ffffffffab5333f8 #4 [ff72159bcd617750] ice_sq_send_cmd at ffffffffc0a35347 [ice] #5 [ff72159bcd6177a8] ice_sq_send_cmd_retry at ffffffffc0a35b47 [ice] #6 [ff72159bcd617810] ice_aq_send_cmd at ffffffffc0a38018 [ice] #7 [ff72159bcd617848] ice_aq_read_nvm at ffffffffc0a40254 [ice] #8 [ff72159bcd6178b8] ice_read_flat_nvm at ffffffffc0a4034c [ice] #9 [ff72159bcd617918] ice_devlink_nvm_snapshot at ffffffffc0a6ffa5 [ice] dmesg: ice 0000:13:00.0: firmware recommends not updating fw.mgmt, as it may result in a downgrade. continuing anyways ice 0000:13:00.1: ice_init_nvm failed -5 ice 0000:13:00.1: Rebuild failed, unload and reload driver Fixes: 12bb018c538c ("ice: Refactor VF reset") Signed-off-by: Petr Oros Tested-by: Rafal Romanowski Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-5-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit b166453d8d015df38eddcb147de64cbb07544531 Author: Petr Oros Date: Mon Apr 27 22:22:16 2026 -0700 iavf: add VIRTCHNL_OP_ADD_VLAN to success completion handler [ Upstream commit 34d33313b52eeac3a97ad2e3176d523ec70d9283 ] The V1 ADD_VLAN opcode had no success handler; filters sent via V1 stayed in ADDING state permanently. Add a fallthrough case so V1 filters also transition ADDING -> ACTIVE on PF confirmation. Critically, add an `if (v_retval) break` guard: the error switch in iavf_virtchnl_completion() does NOT return after handling errors, it falls through to the success switch. Without this guard, a PF-rejected ADD would incorrectly mark ADDING filters as ACTIVE, creating a driver/HW mismatch where the driver believes the filter is installed but the PF never accepted it. For V2, this is harmless: iavf_vlan_add_reject() in the error block already kfree'd all ADDING filters, so the success handler finds nothing to transition. Fixes: 968996c070ef ("iavf: Fix VLAN_V2 addition/rejection") Signed-off-by: Petr Oros Reviewed-by: Aleksandr Loktionov Tested-by: Rafal Romanowski Reviewed-by: Przemek Kitszel Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-4-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit e469b1ff33192f5ff2ed9f4e7bc0951e31ddcb83 Author: Petr Oros Date: Mon Apr 27 22:22:15 2026 -0700 iavf: wait for PF confirmation before removing VLAN filters [ Upstream commit bbcbe4ed70dea948849549af7edf44bd42bbd695 ] The VLAN filter DELETE path was asymmetric with the ADD path: ADD waits for PF confirmation (ADD -> ADDING -> ACTIVE), but DELETE immediately frees the filter struct after sending the DEL message without waiting for the PF response. This is problematic because: - If the PF rejects the DEL, the filter remains in HW but the driver has already freed the tracking structure, losing sync. - Race conditions between DEL pending and other operations (add, reset) cannot be properly resolved if the filter struct is already gone. Add IAVF_VLAN_REMOVING state to make the DELETE path symmetric: REMOVE -> REMOVING (send DEL) -> PF confirms -> kfree -> PF rejects -> ACTIVE In iavf_del_vlans(), transition filters from REMOVE to REMOVING instead of immediately freeing them. The new DEL completion handler in iavf_virtchnl_completion() frees filters on success or reverts them to ACTIVE on error. Update iavf_add_vlan() to handle the REMOVING state: if a DEL is pending and the user re-adds the same VLAN, queue it for ADD so it gets re-programmed after the PF processes the DEL. The !VLAN_FILTERING_ALLOWED early-exit path still frees filters directly since no PF message is sent in that case. Also update iavf_del_vlan() to skip filters already in REMOVING state: DEL has been sent to PF and the completion handler will free the filter when PF confirms. Without this guard, the sequence DEL(pending) -> user-del -> second DEL could cause the PF to return an error for the second DEL (filter already gone), causing the completion handler to incorrectly revert a deleted filter back to ACTIVE. Fixes: 968996c070ef ("iavf: Fix VLAN_V2 addition/rejection") Signed-off-by: Petr Oros Reviewed-by: Aleksandr Loktionov Tested-by: Rafal Romanowski Reviewed-by: Przemek Kitszel Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-3-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit b0173c36977c4e977e6f0a01ab3a8d4a9fde8371 Author: Petr Oros Date: Mon Apr 27 22:22:14 2026 -0700 iavf: stop removing VLAN filters from PF on interface down [ Upstream commit f2ce65b9b917474a1a6ce68d357e15fac2aca0f2 ] When a VF goes down, the driver currently sends DEL_VLAN to the PF for every VLAN filter (ACTIVE -> DISABLE -> send DEL -> INACTIVE), then re-adds them all on UP (INACTIVE -> ADD -> send ADD -> ADDING -> ACTIVE). This round-trip is unnecessary because: 1. The PF disables the VF's queues via VIRTCHNL_OP_DISABLE_QUEUES, which already prevents all RX/TX traffic regardless of VLAN filter state. 2. The VLAN filters remaining in PF HW while the VF is down is harmless - packets matching those filters have nowhere to go with queues disabled. 3. The DEL+ADD cycle during down/up creates race windows where the VLAN filter list is incomplete. With spoofcheck enabled, the PF enables TX VLAN filtering on the first non-zero VLAN add, blocking traffic for any VLANs not yet re-added. Remove the entire DISABLE/INACTIVE state machinery: - Remove IAVF_VLAN_DISABLE and IAVF_VLAN_INACTIVE enum values - Remove iavf_restore_filters() and its call from iavf_open() - Remove VLAN filter handling from iavf_clear_mac_vlan_filters(), rename it to iavf_clear_mac_filters() - Remove DEL_VLAN_FILTER scheduling from iavf_down() - Remove all DISABLE/INACTIVE handling from iavf_del_vlans() VLAN filters now stay ACTIVE across down/up cycles. Only explicit user removal (ndo_vlan_rx_kill_vid) or PF/VF reset triggers VLAN filter deletion/re-addition. Fixes: ed1f5b58ea01 ("i40evf: remove VLAN filters on close") Signed-off-by: Petr Oros Reviewed-by: Aleksandr Loktionov Tested-by: Rafal Romanowski Reviewed-by: Simon Horman Reviewed-by: Przemek Kitszel Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-2-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 033fa40dff770259c0819f76df1c67176d4e125c Author: Petr Oros Date: Mon Apr 27 22:22:13 2026 -0700 iavf: rename IAVF_VLAN_IS_NEW to IAVF_VLAN_ADDING [ Upstream commit 70d62b669f1f9080a25278fc90b64309f4ae8959 ] Rename the IAVF_VLAN_IS_NEW state to IAVF_VLAN_ADDING to better describe what the state represents: an ADD request has been sent to the PF and is waiting for a response. This is a pure rename with no behavioral change, preparing for a cleanup of the VLAN filter state machine. Signed-off-by: Petr Oros Reviewed-by: Aleksandr Loktionov Tested-by: Rafal Romanowski Reviewed-by: Simon Horman Reviewed-by: Przemek Kitszel Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-1-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni Stable-dep-of: f2ce65b9b917 ("iavf: stop removing VLAN filters from PF on interface down") Signed-off-by: Sasha Levin commit 864577384d7232c3fcbd6994e6c2864a5ef8b846 Author: Hasan Basbunar Date: Tue Apr 28 19:07:39 2026 +0200 page_pool: fix memory-provider leak in page_pool_create_percpu() error path [ Upstream commit 5ef343614db766acdc01c56d66e780a1b43c6ac6 ] When page_pool_create_percpu() fails on page_pool_list(), it falls through to its err_uninit: label, which calls page_pool_uninit(). At that point page_pool_init() has already taken two references when the user requested PP_FLAG_ALLOW_UNREADABLE_NETMEM: pool->mp_ops->init(pool) static_branch_inc(&page_pool_mem_providers); Neither is undone by page_pool_uninit(); both are only undone by __page_pool_destroy() (success-side teardown). The error path therefore leaks the per-provider reference taken by mp_ops->init (io_zcrx_ifq->refs in the io_uring zcrx provider, the dmabuf binding refcount in the devmem provider) plus one increment of the page_pool_mem_providers static branch on every failure of xa_alloc_cyclic() inside page_pool_list(). The leaked io_zcrx_ifq->refs in turn pins everything io_zcrx_ifq_free() would release on cleanup: ifq->user (uid), ifq->mm_account (mmdrop), ifq->dev (device refcount), ifq->netdev_tracker (netdev refcount), and the rbuf region. The leaked static branch increment forces all subsequent page_pool_alloc_netmems() and page_pool_return_page() callers to take the slow mp_ops branch for the lifetime of the kernel. Reachable via the io_uring zcrx path: io_uring_register(IORING_REGISTER_ZCRX_IFQ) /* CAP_NET_ADMIN */ -> __io_uring_register -> io_register_zcrx -> zcrx_register_netdev -> netif_mp_open_rxq -> driver ndo_queue_mem_alloc -> page_pool_create_percpu -> page_pool_init succeeds (mp_ops->init runs, branch++) -> page_pool_list fails (xa_alloc_cyclic -ENOMEM) -> goto err_uninit <-- leak The same shape applies to the devmem dmabuf provider via mp_dmabuf_devmem_init()/mp_dmabuf_devmem_destroy(). Restore the cleanup symmetry by moving the mp_ops->destroy() and static_branch_dec() calls out of __page_pool_destroy() and into page_pool_uninit(), so page_pool_uninit() is again the strict inverse of page_pool_init(). page_pool_uninit() has only two callers (the err_uninit: path and __page_pool_destroy()), so this preserves the single-call invariant on the success path while fixing the err path. The error path of page_pool_init() itself still skips the mp_ops cleanup correctly: mp_ops->init is the last action that takes a reference before page_pool_init() returns 0, so when it returns an error neither the refcount nor the static branch has been touched. Triggering the bug requires xa_alloc_cyclic() to fail with -ENOMEM, which under normal GFP_KERNEL retry behaviour is rare. It is deterministic under CONFIG_FAULT_INJECTION with fail_page_alloc / xa fault injection, or under sustained memory pressure. The leak is silent: there is no warning, and the released kernel build continues running with a permanently-incremented static branch. Fixes: 0f9214046893 ("memory-provider: dmabuf devmem memory provider") Signed-off-by: Hasan Basbunar Link: https://patch.msgid.link/20260428170739.34881-1-basbunarhasan@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c169c5837525ad842df6a542facf52b6f866a519 Author: Eric Dumazet Date: Tue Apr 28 12:32:07 2026 +0000 bonding: 3ad: implement proper RCU rules for port->aggregator [ Upstream commit c4f050ce06c56cfb5993268af4a5cb66ed1cd04e ] syzbot found a data-race in bond_3ad_get_active_agg_info / bond_3ad_state_machine_handler [1] which hints at lack of proper RCU implementation. Add __rcu qualifier to port->aggregator, and add proper RCU API. [1] BUG: KCSAN: data-race in bond_3ad_get_active_agg_info / bond_3ad_state_machine_handler write to 0xffff88813cf5c4b0 of 8 bytes by task 36 on cpu 0: ad_port_selection_logic drivers/net/bonding/bond_3ad.c:1659 [inline] bond_3ad_state_machine_handler+0x9d5/0x2d60 drivers/net/bonding/bond_3ad.c:2569 process_one_work kernel/workqueue.c:3302 [inline] process_scheduled_works+0x4f0/0x9c0 kernel/workqueue.c:3385 worker_thread+0x58a/0x780 kernel/workqueue.c:3466 kthread+0x22a/0x280 kernel/kthread.c:436 ret_from_fork+0x146/0x330 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 read to 0xffff88813cf5c4b0 of 8 bytes by task 22063 on cpu 1: __bond_3ad_get_active_agg_info drivers/net/bonding/bond_3ad.c:2858 [inline] bond_3ad_get_active_agg_info+0x8c/0x230 drivers/net/bonding/bond_3ad.c:2881 bond_fill_info+0xe0f/0x10f0 drivers/net/bonding/bond_netlink.c:853 rtnl_link_info_fill net/core/rtnetlink.c:906 [inline] rtnl_link_fill+0x1d7/0x4e0 net/core/rtnetlink.c:927 rtnl_fill_ifinfo+0xf8e/0x1380 net/core/rtnetlink.c:2168 rtmsg_ifinfo_build_skb+0x11c/0x1b0 net/core/rtnetlink.c:4453 rtmsg_ifinfo_event net/core/rtnetlink.c:4486 [inline] rtmsg_ifinfo+0x6d/0x110 net/core/rtnetlink.c:4495 __dev_notify_flags+0x76/0x390 net/core/dev.c:9790 netif_change_flags+0xac/0xd0 net/core/dev.c:9823 do_setlink+0x905/0x2950 net/core/rtnetlink.c:3180 rtnl_group_changelink net/core/rtnetlink.c:3813 [inline] __rtnl_newlink net/core/rtnetlink.c:3981 [inline] rtnl_newlink+0xf55/0x1400 net/core/rtnetlink.c:4109 rtnetlink_rcv_msg+0x64b/0x720 net/core/rtnetlink.c:6995 netlink_rcv_skb+0x123/0x220 net/netlink/af_netlink.c:2550 rtnetlink_rcv+0x1c/0x30 net/core/rtnetlink.c:7022 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x5a8/0x680 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x5c8/0x6f0 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:787 [inline] __sock_sendmsg net/socket.c:802 [inline] ____sys_sendmsg+0x563/0x5b0 net/socket.c:2698 ___sys_sendmsg+0x195/0x1e0 net/socket.c:2752 __sys_sendmsg net/socket.c:2784 [inline] __do_sys_sendmsg net/socket.c:2789 [inline] __se_sys_sendmsg net/socket.c:2787 [inline] __x64_sys_sendmsg+0xd4/0x160 net/socket.c:2787 x64_sys_call+0x194c/0x3020 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x12c/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f value changed: 0x0000000000000000 -> 0xffff88813cf5c400 Reported by Kernel Concurrency Sanitizer on: CPU: 1 UID: 0 PID: 22063 Comm: syz.0.31122 Tainted: G W syzkaller #0 PREEMPT(full) Tainted: [W]=WARN Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 Fixes: 47e91f56008b ("bonding: use RCU protection for 3ad xmit path") Reported-by: syzbot+9bb2ff2a4ab9e17307e1@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/69f0a82f.050a0220.3aadc4.0000.GAE@google.com/ Signed-off-by: Eric Dumazet Cc: Jay Vosburgh Cc: Andrew Lunn Link: https://patch.msgid.link/20260428123207.3809211-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f2edb41645bf0a8112ef806a7a34b803d2ce538c Author: Hangbin Liu Date: Tue Feb 24 02:02:14 2026 +0000 bonding: print churn state via netlink [ Upstream commit 4916f2e2f3fc9aef289fcd07949301e5c29094c2 ] Currently, the churn state is printed only in sysfs. Add netlink support so users could get the state via netlink. Signed-off-by: Hangbin Liu Link: https://patch.msgid.link/20260224020215.6012-1-liuhangbin@gmail.com Signed-off-by: Paolo Abeni Stable-dep-of: c4f050ce06c5 ("bonding: 3ad: implement proper RCU rules for port->aggregator") Signed-off-by: Sasha Levin commit c1e0b5eccdf09d8dbd849c459d03f969f4a01cd6 Author: Lorenzo Bianconi Date: Tue Apr 28 08:53:16 2026 +0200 net: airoha: Do not return err in ndo_stop() callback [ Upstream commit 4ca01292ea2f2363660610a65ba0285d7c3309ed ] Always complete the airoha_dev_stop() routine regardless of the airoha_set_vip_for_gdm_port() return value, since errors from ndo_stop() are ignored by the networking stack and the interface is always considered down after the call. Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260428-airoha-ndo-stop-not-err-v1-1-674506d29a91@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit aaad53a55812acd2355c0e5478896381e78b0110 Author: Lorenzo Bianconi Date: Tue Apr 21 08:35:11 2026 +0200 net: airoha: fix BQL imbalance in TX path [ Upstream commit 2d9f5a118205da2683ffcec78b9347f1f01a820e ] Fix a possible BQL imbalance in airoha_dev_xmit(), where inflight packets are accounted only for the AIROHA_NUM_TX_RING netdev TX queues. The queue index is computed as: qid = skb_get_queue_mapping(skb) % ARRAY_SIZE(qdma->q_tx) txq = netdev_get_tx_queue(dev, qid); However, airoha_qdma_tx_napi_poll() accounts completions across all netdev TX queues (num_tx_queues), leading to inconsistent BQL accounting. Also reset all netdev TX queues in the ndo_stop callback. Fixes: 1d304174106c ("net: airoha: Implement BQL support") Fixes: c9f947769b77 ("net: airoha: Reset BQL stopping the netdevice") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260421-airoha-fix-bql-v1-1-f135afe4275b@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: 4ca01292ea2f ("net: airoha: Do not return err in ndo_stop() callback") Signed-off-by: Sasha Levin commit d1469eb93af78191ac416962840d3323621c2e4b Author: Shuicheng Lin Date: Fri Apr 17 16:33:08 2026 +0000 drm/xe/gsc: Fix BO leak on error in query_compatibility_version() [ Upstream commit 3762d6c36549accea7068c4a175483fafdd03657 ] When xe_gsc_read_out_header() fails, query_compatibility_version() returns directly instead of jumping to the out_bo label. This skips the xe_bo_unpin_map_no_vm() call, leaving the BO pinned and mapped with no remaining reference to free it. Fix by using goto out_bo so the error path properly cleans up the BO, consistent with the other error handling in the same function. Fixes: 0881cbe04077 ("drm/xe/gsc: Query GSC compatibility version") Cc: Daniele Ceraolo Spurio Reviewed-by: Daniele Ceraolo Spurio Link: https://patch.msgid.link/20260417163308.3416147-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin (cherry picked from commit 8de86d0a843c32ca9d36864bdb92f0376a830bce) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit bebce43f34b5feb8a760aa832eba81e0f8a38871 Author: Shuicheng Lin Date: Wed Apr 15 22:54:28 2026 +0000 drm/xe/eustall: Fix drm_dev_put called before stream disable in close [ Upstream commit dc2d9842c67d883d3200ae33b9c3859dd9492408 ] In xe_eu_stall_stream_close(), drm_dev_put() is called before the stream is disabled and its resources are freed. If this drops the last reference, the device structures could be freed while the subsequent cleanup code still accesses them, leading to a use-after-free. Fix this by moving drm_dev_put() after all device accesses are complete. This matches the ordering in xe_oa_release(). Fixes: 9a0b11d4cf3b ("drm/xe/eustall: Add support to init, enable and disable EU stall sampling") Cc: Harish Chegondi Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Shuicheng Lin Reviewed-by: Harish Chegondi Link: https://patch.msgid.link/20260415225428.3399934-1-shuicheng.lin@intel.com Signed-off-by: Matt Roper (cherry picked from commit 35aff528f7297e949e5e19c9cd7fd748cf1cf21c) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 753b149d5a433eb19e0c1b0eb4526a6e26120d1f Author: Shuicheng Lin Date: Wed Apr 8 02:06:47 2026 +0000 drm/xe: Fix error cleanup in xe_exec_queue_create_ioctl() [ Upstream commit f3cc22d4df3ed58439ea7e21daa54c3608e03b78 ] Two error handling issues exist in xe_exec_queue_create_ioctl(): 1. When xe_hw_engine_group_add_exec_queue() fails, the error path jumps to put_exec_queue which skips xe_exec_queue_kill(). If the VM is in preempt fence mode, xe_vm_add_compute_exec_queue() has already added the queue to the VM's compute exec queue list. Skipping the kill leaves the queue on that list, leading to a dangling pointer after the queue is freed. 2. When xa_alloc() fails after xe_hw_engine_group_add_exec_queue() has succeeded, the error path does not call xe_hw_engine_group_del_exec_queue() to remove the queue from the hw engine group list. The queue is then freed while still linked into the hw engine group, causing a use-after-free. Fix both by: - Changing the xe_hw_engine_group_add_exec_queue() failure path to jump to kill_exec_queue so that xe_exec_queue_kill() properly removes the queue from the VM's compute list. - Adding a del_hw_engine_group label before kill_exec_queue for the xa_alloc() failure path, which removes the queue from the hw engine group before proceeding with the rest of the cleanup. Fixes: 7970cb36966c ("'drm/xe/hw_engine_group: Register hw engine group's exec queues") Cc: Francois Dugast Cc: Matthew Brost Cc: Niranjana Vishwanathapura Assisted-by: Claude:claude-opus-4.6 Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20260408020647.3397933-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin (cherry picked from commit 37c831f401746a45d510b312b0ed7a77b1e06ec8) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 2d8656c27ff60442e50d97205260aac3dc89acaa Author: Matt Roper Date: Wed Apr 8 15:27:44 2026 -0700 drm/xe/debugfs: Correct printing of register whitelist ranges [ Upstream commit 03f2499c51dffce611b065b2894406beb9f2ebe0 ] The register-save-restore debugfs prints whitelist entries as offset ranges. E.g., REG[0x39319c-0x39319f]: allow read access for a single dword-sized register. However the GENMASK value used to set the lower bits to '1' for the upper bound of the whitelist range incorrectly included one more bit than it should have, causing the whitelist ranges to sometimes appear twice as large as they really were. For example, REG[0x6210-0x6217]: allow rw access was also intended to be a single dword-sized register whitelist (with a range 0x6210-0x6213) but was printed incorrectly as a qword-sized range because one too many bits was flipped on. Similar 'off by one' logic was applied when printing 4-dword register ranges and 64-dword register ranges as well. Correct the GENMASK logic to print these ranges in debugfs correctly. No impact outside of correcting the misleading debugfs output. Fixes: d855d2246ea6 ("drm/xe: Print whitelist while applying") Reviewed-by: Stuart Summers Link: https://patch.msgid.link/20260408-regsr_wl_range-v1-1-e9a28c8b4264@intel.com Signed-off-by: Matt Roper (cherry picked from commit 1a2a722ff96749734a5585dfe7f0bea7719caa8b) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 8b85ffe5205262682b4dc9e2e35beaeb7365aceb Author: Timur Kristóf Date: Tue Apr 28 13:40:44 2026 +0200 drm/amd/display: Read EDID from VBIOS embedded panel info [ Upstream commit 9ea16f64189bf7b6ba50fc7f0325b3c1f836d105 ] Some board manufacturers hardcode the EDID for the embedded panel in the VBIOS. This EDID should be used when the panel doesn't have a DDC. For reference, see the legacy non-DC display code: amdgpu_atombios_encoder_get_lcd_info() This is necessary to support embedded connectors without DDC. Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/5192 Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher (cherry picked from commit eb105e63b474c11ef6a84a1c6b18100d851ff364) Signed-off-by: Sasha Levin commit 07822f1d9bdbd4a1809d0baac6856e36da1c1015 Author: Timur Kristóf Date: Tue Apr 28 13:40:43 2026 +0200 drm/amd/display: Allow constructing DCE8 link encoder without DDC [ Upstream commit 60af4605ef35ecb7ad649a8534b83a2f7c69576d ] When the DDC channel ID is set to CHANNEL_ID_UNKNOWN, pass NULL to the AUX regs array. This is necessary to support embedded connectors without DDC. Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/5192 Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher (cherry picked from commit 155baf3038c1af50b602723022ed869b38e86a99) Signed-off-by: Sasha Levin commit e0f874f209d4ce5825bc468dbc8f924676af0aac Author: Timur Kristóf Date: Tue Apr 28 13:40:42 2026 +0200 drm/amd/display: Allow constructing DCE6 link encoder without DDC [ Upstream commit 880498a1943f865529819f778df3b9945ca57262 ] When the DDC channel ID is set to CHANNEL_ID_UNKNOWN, pass NULL to the AUX regs array. This is necessary to support embedded connectors without DDC. Fixes: 7c15fd86aaec ("drm/amd/display: dc/dce: add initial DCE6 support (v10)") Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/5192 Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher (cherry picked from commit 38a70e50b22a188ff601740d64dd75f46213121f) Signed-off-by: Sasha Levin commit 9b84d67ce8c93770f5d42005ba82500ffa34dc39 Author: Timur Kristóf Date: Tue Apr 28 13:40:41 2026 +0200 drm/amd/display: Allow DCE link encoder without AUX registers [ Upstream commit ac27e3f99035f132f23bc0409d0e57f11f054c70 ] Allow constructing the DCE link encoder without DDC, which means the AUX registers array will be NULL. This is necessary to support embedded connectors without DDC. Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/5192 Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher (cherry picked from commit 87f30b101af62590faf6020d106da07efdda199b) Signed-off-by: Sasha Levin commit 69a7cfc66405aeaa2483147653d031b3592ffc9c Author: Sebastian Andrzej Siewior Date: Tue Apr 28 12:34:25 2026 +0200 futex: Prevent lockup in requeue-PI during signal/ timeout wakeup [ Upstream commit bc7304f3ae20972d11db6e0b1b541c63feda5f05 ] During wait-requeue-pi (task A) and requeue-PI (task B) the following race can happen: Task A Task B futex_wait_requeue_pi() futex_setup_timer() futex_do_wait() futex_requeue() CLASS(hb, hb1)(&key1); CLASS(hb, hb2)(&key2); *timeout* futex_requeue_pi_wakeup_sync() requeue_state = Q_REQUEUE_PI_IGNORE *blocks on hb->lock* futex_proxy_trylock_atomic() futex_requeue_pi_prepare() Q_REQUEUE_PI_IGNORE => -EAGAIN double_unlock_hb(hb1, hb2) *retry* Task B acquires both hb locks and attempts to acquire the PI-lock of the top most waiter (task B). Task A is leaving early due to a signal/ timeout and started removing itself from the queue. It updates its requeue_state but can not remove it from the list because this requires the hb lock which is owned by task B. Usually task A is able to swoop the lock after task B unlocked it. However if task B is of higher priority then task A may not be able to wake up in time and acquire the lock before task B gets it again. Especially on a UP system where A is never scheduled. As a result task A blocks on the lock and task B busy loops, trying to make progress but live locks the system instead. Tragic. This can be fixed by removing the top most waiter from the list in this case. This allows task B to grab the next top waiter (if any) in the next iteration and make progress. Remove the top most waiter if futex_requeue_pi_prepare() fails. Let the waiter conditionally remove itself from the list in handle_early_requeue_pi_wakeup(). Fixes: 07d91ef510fb1 ("futex: Prevent requeue_pi() lock nesting issue on RT") Reported-by: Moritz Klammler Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260428103425.dywXyPd3@linutronix.de Closes: https://lore.kernel.org/all/VE1PR06MB6894BE61C173D802365BE19DFF4CA@VE1PR06MB6894.eurprd06.prod.outlook.com Signed-off-by: Sasha Levin commit 24c22c644ea535f669bb4cdf1006a6df21874168 Author: Shenghao Ding Date: Wed Apr 29 13:42:06 2026 +0800 ALSA: hda/tas2781: Fix incorrect bit update for non-book-zero or book 0 pages >1 [ Upstream commit e052a1f7199260eda4d6ca08a59c3b98738f8491 ] In TAS2781 SPI mode, when accessing non-book-zero or page numbers greater than 1 in book 0, an additional byte must be read. The first byte in such cases is a dummy byte and should be ignored. Fixes: 9fa6a693ad8d ("ALSA: hda/tas2781: Remove tas2781_spi_fwlib.c and leverage SND_SOC_TAS2781_FMWLIB") Signed-off-by: Shenghao Ding Link: https://patch.msgid.link/20260429054206.429-1-shenghao-ding@ti.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 7e6f7ac79abe22d6a665903c0a539e7e0b43e54d Author: Richard Fitzgerald Date: Tue Apr 28 14:05:31 2026 +0100 ALSA: hda: cs35l56: Fix uninitialized value in cs35l56_hda_read_acpi() [ Upstream commit 90df4957a3271adf391b3432cd76a40887cf3273 ] Eliminate the uninitialized 'nval' in cs35l56_hda_read_acpi() if a system-specific quirk overrides processing of the dev-index property. The value is now stored in a new 'num_amps' member of struct cs35l56_hda so that the quirk handler can set the value. The quirk for the Lenovo Yoga Book 9i GenX replaces the values from the dev-index property with hardcoded indexes. So cs35l56_hda_read_acpi() would then skip reading the property. But this left the 'nval' local variable uninitialized when it is later passed to cirrus_scodec_get_speaker_id(). Fixes: 40b1c2f9b299 ("ALSA: hda/cs35l56: Workaround bad dev-index on Lenovo Yoga Book 9i GenX") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/linux-sound/aenFesLAStjrVNy8@stanley.mountain/T/#u Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260428130531.169600-1-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit f837c7b85143a7c54140ff41ad5c076b73cd9933 Author: wangdicheng Date: Tue Apr 28 16:04:50 2026 +0800 ALSA: hda/conexant: Fix missing error check for jack detection [ Upstream commit b0e2333a231107adedd38c6fcfe1adc6162716fc ] In cx_probe(), the return value of snd_hda_jack_detect_enable_callback() is ignored. This function returns a pointer, and if it fails (e.g., due to memory allocation failure), it returns an error pointer which must be checked using IS_ERR(). If the registration fails, the driver continues to probe, but the jack detection callback will not be registered. This can lead to a kernel crash later when the driver attempts to handle jack events or accesses the uninitialized structure. Check the return value using IS_ERR() and propagate the error via PTR_ERR() to the probe caller. Fixes: 7aeb25908648 ("ALSA: hda/conexant: Fix headset auto detect fail in cx8070 and SN6140") Signed-off-by: wangdicheng Link: https://patch.msgid.link/20260428080450.108801-1-wangdich9700@163.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 47984e9db9caaf76fc88c0080bd6402df58ff7ce Author: Breno Leitao Date: Mon Apr 27 07:30:37 2026 -0700 netconsole: propagate device name truncation in dev_name_store() [ Upstream commit 92ceb7bff62c2606f664c204750eca0b85d44112 ] dev_name_store() calls strscpy(nt->np.dev_name, buf, IFNAMSIZ) without checking the return value. If userspace writes an interface name longer than IFNAMSIZ - 1, strscpy() silently truncates and returns -E2BIG, but the function ignores it and reports a fully successful write back to userspace. If a real interface happens to match the truncated name, netconsole will bind to the wrong device on the next enable, sending kernel logs and panic output to an unintended network segment with no indication to userspace that anything was rewritten. Reject writes whose length cannot fit in nt->np.dev_name up front: if (count >= IFNAMSIZ) return -ENAMETOOLONG; This is not a big deal of a problem, but, it is still the correct approach. Fixes: 0bcc1816188e57 ("[NET] netconsole: Support dynamic reconfiguration using configfs") Signed-off-by: Breno Leitao Link: https://patch.msgid.link/20260427-netconsole_ai_fixes-v2-3-59965f29d9cc@debian.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b19a6804d4980e780a176de288d205bd29fb7c3b Author: Eric Dumazet Date: Mon Apr 27 08:36:06 2026 +0000 net/sched: sch_cake: annotate data-races in cake_dump_stats() (V) [ Upstream commit a6c95b833dc17e84d16a8ac0f40fd0931616a52d ] cake_dump_stats() runs without qdisc spinlock being held. In this final patch, I add READ_ONCE()/WRITE_ONCE() annotations for cparams.target and cparams.interval. Fixes: 046f6fd5daef ("sched: Add Common Applications Kept Enhanced (cake) qdisc") Signed-off-by: Eric Dumazet Acked-by: "Toke Høiland-Jørgensen" Link: https://patch.msgid.link/20260427083606.459355-6-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cd0401593b2d551df2677fd0102bc67daee93d78 Author: Eric Dumazet Date: Mon Apr 27 08:36:04 2026 +0000 net/sched: sch_cake: annotate data-races in cake_dump_stats() (III) [ Upstream commit 276a98a434964088fccd4745db5b34d6e831e358 ] cake_dump_stats() runs without qdisc spinlock being held. In this third patch, I add READ_ONCE()/WRITE_ONCE() annotations for the following fields: - packets - tin_dropped - tin_ecn_mark - ack_drops - peak_delay - avge_delay - base_delay Other annotations are added in following patches, to ease code review. Fixes: 046f6fd5daef ("sched: Add Common Applications Kept Enhanced (cake) qdisc") Signed-off-by: Eric Dumazet Acked-by: "Toke Høiland-Jørgensen" Link: https://patch.msgid.link/20260427083606.459355-4-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 74a02921c48fcd35a7881956c9e5c52b86595f5d Author: Weiming Shi Date: Sun Apr 26 09:53:51 2026 -0700 bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst() [ Upstream commit aa6c6d9ee064aabfede4402fd1283424e649ca19 ] bareudp_fill_metadata_dst() passes bareudp->sock to udp_tunnel6_dst_lookup() in the IPv6 path without a NULL check. The socket is only created in bareudp_open() and NULLed in bareudp_stop(), so calling this function while the device is down triggers a NULL dereference via sock->sk. BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:udp_tunnel6_dst_lookup (net/ipv6/ip6_udp_tunnel.c:160) Call Trace: bareudp_fill_metadata_dst (drivers/net/bareudp.c:532) do_execute_actions (net/openvswitch/actions.c:901) ovs_execute_actions (net/openvswitch/actions.c:1589) ovs_packet_cmd_execute (net/openvswitch/datapath.c:700) genl_family_rcv_msg_doit (net/netlink/genetlink.c:1114) genl_rcv_msg (net/netlink/genetlink.c:1209) netlink_rcv_skb (net/netlink/af_netlink.c:2550) Add a NULL check returning -ESHUTDOWN, consistent with the xmit paths in the same driver. Fixes: 571912c69f0e ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Reviewed-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260426165350.1663137-2-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ea9b4f07da5d163f201cd6699e6c6793ce565a8e Author: Xin Long Date: Sun Apr 26 10:46:41 2026 -0400 sctp: discard stale INIT after handshake completion [ Upstream commit 8a92cb475ca90d84db769e4d4383e631ace0d6e5 ] After an association reaches ESTABLISHED, the peer’s init_tag is already known from the handshake. Any subsequent INIT with the same init_tag is not a valid restart, but a delayed or duplicate INIT. Drop such INIT chunks in sctp_sf_do_unexpected_init() instead of processing them as new association attempts. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner Link: https://patch.msgid.link/5788c76c1ee122a3ed00189e88dcf9df1fba226c.1777214801.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 50c450bae38dbf01e8039d3b8fa1b61421f66423 Author: Xin Long Date: Sun Apr 26 10:46:40 2026 -0400 netfilter: skip recording stale or retransmitted INIT [ Upstream commit 576a5d2bad4814c881a829576b1261b9b8159d2b ] An INIT whose init_tag matches the peer's vtag does not provide new state information. It indicates either: - a stale INIT (after INIT-ACK has already been seen on the same side), or - a retransmitted INIT (after INIT has already been recorded on the same side). In both cases, the INIT must not update ct->proto.sctp.init[] state, since it does not advance the handshake tracking and may otherwise corrupt INIT/INIT-ACK validation logic. Allow INIT processing only when the conntrack entry is newly created (SCTP_CONNTRACK_NONE), or when the init_tag differs from the stored peer vtag. Note it skips the check for the ct with old_state SCTP_CONNTRACK_NONE in nf_conntrack_sctp_packet(), as it is just created in sctp_new() where it set ct->proto.sctp.vtag[IP_CT_DIR_REPLY] = ih->init_tag. Fixes: 9fb9cbb1082d ("[NETFILTER]: Add nf_conntrack subsystem.") Signed-off-by: Xin Long Reviewed-by: Marcelo Ricardo Leitner Acked-by: Florian Westphal Link: https://patch.msgid.link/ee56c3e416452b2a40589a2a85245ac2ad5e9f4b.1777214801.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 841133395b4214f40119ba6da35516e25999ea5d Author: Christian A. Ehrhardt Date: Tue Apr 28 21:22:49 2026 +0200 ASoC: codecs: ab8500: Fix casting of private data [ Upstream commit a201aef1a88b675e9eb8487e27d14e2eef3cef80 ] ab8500_filter_controls[i].private_value is initialized using .private_value = (unsigned long)&(struct filter_control) {.count = xcount, .min = xmin, .max = xmax} thus it's a pointer to a struct filter_control casted to unsigned long. So to get back that pointer .private_data must be cast back, not its address. Fixes: 679d7abdc754 ("ASoC: codecs: Add AB8500 codec-driver") Signed-off-by: Christian A. Ehrhardt Signed-off-by: Uwe Kleine-König (The Capable Hub) Link: https://patch.msgid.link/20260428192255.2294705-2-u.kleine-koenig@baylibre.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit aa1a08a4632af5d1117779e7ff0e32e3c69f29bd Author: Jakub Kicinski Date: Mon Apr 27 12:58:56 2026 -0700 net: psp: require admin permission for dev-set and key-rotate [ Upstream commit b718342a7fbaa2dff5fefc31988c07af8c6cbc21 ] The dev-set and key-rotate netlink operations modify shared device state (PSP version configuration and cryptographic key material, respectively) but do not require CAP_NET_ADMIN. The only access control is psp_dev_check_access() which merely verifies netns membership. Fixes: 00c94ca2b99e ("psp: base PSP device support") Reviewed-by: Daniel Zahka Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260427195856.401223-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d90df5ce6deb2424de3ad89bcc693ac1b67accc9 Author: Jakub Kicinski Date: Mon Apr 27 12:06:06 2026 -0700 net: psp: check for device unregister when creating assoc [ Upstream commit b89769f936a8fa9e66de72ddc1b71a9745a488e6 ] psp_assoc_device_get_locked() obtains a psp_dev reference via psp_dev_get_for_sock() (which uses psp_dev_tryget() under RCU); it then acquires psd->lock and drops the reference. Before the lock is taken, psp_dev_unregister() can run to completion: take psd->lock, clear out state, unlock, drop the registration reference. The expectation is that the lock prevents device unregistration, but much like with netdevs special care has to be taken when "upgrading" a reference to a locked device. Add the missing check if device is still alive. psp_dev_is_registered() exists already but had no callers, which makes me wonder if I either forgot to add this or lost the check during refactoring... Reported-by: Yiming Qian Fixes: 6b46ca260e22 ("net: psp: add socket security association code") Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260427190606.366101-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 39767f944a8c9e696566c37ad5b20131406c4b8d Author: Jens Axboe Date: Mon Apr 27 14:42:18 2026 -0600 io_uring/napi: cap busy_poll_to 10 msec [ Upstream commit df8599ee18c0e5fe343ffe0b4c379636b8bb839a ] Currently there's no cap on the maximum amount of time that napi is allowed to poll if no events are found, which can lead to kernel complaints on a task being stuck as there's no conditional rescheduling done within that loop. Just cap it to 10 msec in total, that's already way above any kind of sane value that will reap any benefits, yet low enough that it's nowhere near being able to trigger preemption complaints. Fixes: 8d0c12a80cde ("io-uring: add napi busy poll support") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit d0f6ae14c0452be4fc3aa5cf81c74e68b3243050 Author: Yinjie Yao Date: Mon Apr 27 11:46:11 2026 -0400 drm/amdgpu/jpeg: set no_user_fence for JPEG v5.0.1 ring [ Upstream commit 2f8e3da71a1b469b6e157aa3972f1448b3157840 ] JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: b8f57b69942b ("drm/amdgpu: Add JPEG5_0_1 support") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit 742a98e2e81702df8fe1b1eccee5223220a03dc2) Signed-off-by: Sasha Levin commit a7e63bb93a7fde3c8920984c3deee9acfe461562 Author: Yinjie Yao Date: Mon Apr 27 11:46:11 2026 -0400 drm/amdgpu/jpeg: set no_user_fence for JPEG v5.0.0 ring [ Upstream commit ea7c61c5f895e8f9ea0ffffa180498ef9c740152 ] JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: dfad65c65728 ("drm/amdgpu: Add JPEG5 support") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit 0f43893d3cd478fa57836697525b338817c9c23d) Signed-off-by: Sasha Levin commit f26e3f7186cd6ecc93e6af102744d64c798dea7e Author: Yinjie Yao Date: Mon Apr 27 11:46:11 2026 -0400 drm/amdgpu/jpeg: set no_user_fence for JPEG v4.0.5 ring [ Upstream commit b65b7f3f3c18f797f81a2af7c97e2079900ad6db ] JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: 8f98a715da8e ("drm/amdgpu/jpeg: add jpeg support for VCN4_0_5") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit f05d0a4f21fc720116d6e238f23308b199891058) Signed-off-by: Sasha Levin commit 8549b3933038e68dc61cb934b9a54223dd244a78 Author: Yinjie Yao Date: Mon Apr 27 11:46:11 2026 -0400 drm/amdgpu/jpeg: set no_user_fence for JPEG v4.0.3 ring [ Upstream commit 83e37c0987ca92f9e87789b46dd311dcf5a4a6c8 ] JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: e684e654eba9 ("drm/amdgpu/jpeg: add jpeg support for VCN4_0_3") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit 2f6afc97d259d530f4f86c7743efbc573a8da927) Signed-off-by: Sasha Levin commit 6876d05b899102f4dfdb9ad560132126144c1c72 Author: Yinjie Yao Date: Mon Apr 27 11:46:11 2026 -0400 drm/amdgpu/jpeg: set no_user_fence for JPEG v4.0 ring [ Upstream commit e7e90b5839aeb8805ec83bb4da610b8dab8e184d ] JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: b13111de32a9 ("drm/amdgpu/jpeg: add jpeg support for VCN4_0_0") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit 8d0cac9478a3f046279c657d6a2545de49ae675a) Signed-off-by: Sasha Levin commit 5ada37d7f736f9feeaa06a25e470a4c74e67a61a Author: Yinjie Yao Date: Mon Apr 27 11:46:10 2026 -0400 drm/amdgpu/jpeg: set no_user_fence for JPEG v3.0 ring [ Upstream commit a2baf12eec41f246689e6a3f8619af1200031576 ] JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: dfd57dbf44dd ("drm/amdgpu: add JPEG3.0 support for Sienna_Cichlid") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit 4d7d774f100efb5089c86a1fb8c5bf47c63fc9ef) Signed-off-by: Sasha Levin commit 3a96fee676fc0caf08f03ad915bec6fcd144d551 Author: Yinjie Yao Date: Mon Apr 27 11:46:10 2026 -0400 drm/amdgpu/jpeg: set no_user_fence for JPEG v2.5 ring [ Upstream commit 79405e774ede411c6b47ed41c651e40b92de64a2 ] JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: 14f43e8f88c5 ("drm/amdgpu: move JPEG2.5 out from VCN2.5") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit 3216a7f4e2642bda5fd14f57586e835ae9202587) Signed-off-by: Sasha Levin commit b41248d1c18384835f6532e68592ee07605da283 Author: Yinjie Yao Date: Mon Apr 27 11:46:10 2026 -0400 drm/amdgpu/jpeg: set no_user_fence for JPEG v2.0 ring [ Upstream commit e5f612dc91650561fe2b5b76dd6d2898ec9ad480 ] JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: 6ac27241106b ("drm/amdgpu: add JPEG v2.0 function supports") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit 96179da0c6b059eb31706a0abe8dd6381c533143) Signed-off-by: Sasha Levin commit 081ef0e46c9cdd26c0db0ef721470393d36b6655 Author: Yinjie Yao Date: Mon Apr 27 11:45:36 2026 -0400 drm/amdgpu/vcn: set no_user_fence for VCN v5.0.1 enc ring [ Upstream commit 8f4954722eab88e10c4ea0c0d3b1269c31421d3a ] VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: 346492f30ce3 ("drm/amdgpu: Add VCN_5_0_1 support") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit e16be95a2c3ee712b142cb27d2dca0b461181359) Signed-off-by: Sasha Levin commit 139a8a52ef4349c62129703b3a3e3a6ae4d634eb Author: Yinjie Yao Date: Mon Apr 27 11:45:36 2026 -0400 drm/amdgpu/vcn: set no_user_fence for VCN v5.0.0 enc ring [ Upstream commit 8cae0ce77de492d7c31c1532a2e80c0c6e7e58cb ] VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: b6d1a0632051 ("drm/amdgpu: add VCN_5_0_0 IP block support") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit 49b1fbbb5a071197ee71e2d70959b1cb29bdc317) Signed-off-by: Sasha Levin commit 6d9a98c5ed65ba92a09e4ca5a5f6941448145529 Author: Yinjie Yao Date: Mon Apr 27 11:45:36 2026 -0400 drm/amdgpu/vcn: set no_user_fence for VCN v4.0.5 enc ring [ Upstream commit 589a254bf3e88204c8402b9cbccd5e23a0af990f ] VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: 547aad32edac ("drm/amdgpu: add VCN4 ip block support") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit 084d94ac93707bdda07efb5cee786f632de4219b) Signed-off-by: Sasha Levin commit 9076a83e5adefd10dc5c967c7b8bde601c4c512a Author: Yinjie Yao Date: Mon Apr 27 11:45:36 2026 -0400 drm/amdgpu/vcn: set no_user_fence for VCN v4.0.3 enc ring [ Upstream commit 4532b52b34e4e4310386e6fdf6a643368599f522 ] VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: b889ef4ac988 ("drm/amdgpu/vcn: add vcn support for VCN4_0_3") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit ff1a5a125c5a70c328806b9bc01d7d942cf3f9aa) Signed-off-by: Sasha Levin commit 1286b6872de0aee1feeeaa6dbac86369806de9a5 Author: Yinjie Yao Date: Mon Apr 27 11:45:36 2026 -0400 drm/amdgpu/vcn: set no_user_fence for VCN v4.0 enc ring [ Upstream commit 51f694221047c84fa185be98210eb2c354ffb8c6 ] VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: 8da1170a16e4 ("drm/amdgpu: add VCN4 ip block support") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit fd852c048b46f9825e904a4f3f4538fe9d8827d9) Signed-off-by: Sasha Levin commit 2d6525e7b2504f5bbfe9417cddc1e8da858791dd Author: Yinjie Yao Date: Mon Apr 27 11:45:35 2026 -0400 drm/amdgpu/vcn: set no_user_fence for VCN v3.0 enc/dec rings [ Upstream commit f1e5a6660d7cbf006079126d9babbf0ccf538c6b ] VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: cf14826cdfb5 ("drm/amdgpu: add VCN3.0 support for Sienna_Cichlid") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit 663bed3c7b8b9a7624b0d95d300ddae034ad0614) Signed-off-by: Sasha Levin commit 602d4c5872b25ddd4d82fb2025efb9a05b187bb3 Author: Yinjie Yao Date: Mon Apr 27 11:45:35 2026 -0400 drm/amdgpu/vcn: set no_user_fence for VCN v2.5 enc/dec rings [ Upstream commit 4f317863a3ab212a027d8c8c3cc3af4e3fb95704 ] VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: 28c17d72072b ("drm/amdgpu: add VCN2.5 basic supports") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit efc9dd5590894109bce9a0bfe1fa5592dd6b20b1) Signed-off-by: Sasha Levin commit ac06ce5cac9e711281585d09d00c6efcd9b86396 Author: Yinjie Yao Date: Mon Apr 27 11:45:35 2026 -0400 drm/amdgpu/vcn: set no_user_fence for VCN v2.0 enc/dec rings [ Upstream commit 8d80b293b41fcb5e9396db93e788b0f4ebcbafb7 ] VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: 1b61de45dfaf ("drm/amdgpu: add initial VCN2.0 support (v2)") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit e2b5499fca55f1a32960a311bbb62e35891eaf73) Signed-off-by: Sasha Levin commit fb128a905f7a648bae6fe517ef8b406b579ebc71 Author: Heiko Schocher Date: Sat Apr 25 05:13:39 2026 +0200 net: phy: dp83869: fix setting CLK_O_SEL field. [ Upstream commit 46f74a3f7d57d9cc0110b09cbc8163fa0a01afa2 ] Table 7-121 in datasheet says we have to set register 0xc6 to value 0x10 before CLK_O_SEL can be modified. No more infos about this field found in datasheet. With this fix, setting of CLK_O_SEL field in IO_MUX_CFG register worked through dts property "ti,clk-output-sel" on a DP83869HMRGZR. Signed-off-by: Heiko Schocher Reviewed-by: Simon Horman Fixes: 01db923e8377 ("net: phy: dp83869: Add TI dp83869 phy") Link: https://patch.msgid.link/20260425031339.3318-1-hs@nabladev.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1c07b968a5d7bef0c0e2aaee820f8a85251bd1c8 Author: Heiko Carstens Date: Tue Apr 21 07:52:44 2026 +0200 s390/mm: Fix phys_to_folio() usage in do_secure_storage_access() [ Upstream commit b95e0e792822bad8fc9eb33ea3a90005e29e75e9 ] In case of a Secure-Storage-Access exception the effective aka virtual address which caused the exception is contained within the TEID. do_secure_storage_access() incorrectly uses phys_to_folio() instead of virt_to_folio() to translate the virtual address to the corresponding folio. Fix this by using virt_to_folio() instead of phys_to_folio(). Fixes: 084ea4d611a3 ("s390/mm: add (non)secure page access exceptions handlers") Reviewed-by: Christian Borntraeger Reviewed-by: Claudio Imbrenda Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit 0f5bca930f8d57725b3856eea80327b182869a3b Author: Yu Kuai Date: Sat Apr 25 10:46:15 2026 +0800 md/md-bitmap: add a none backend for bitmap grow [ Upstream commit f2926a533d03fe70d753b512b713e06a2aa174af ] Add a real none bitmap backend that exposes the common bitmap sysfs group and use it to keep bitmap/location available when an array has no bitmap. Then switch the bitmap location sysfs path to move only between none and the classic bitmap backend, using the no-sysfs bitmap helpers while merging or unmerging the internal bitmap sysfs group. This restores mdadm --grow bitmap addition through bitmap/location. Fixes: fb8cc3b0d9db ("md/md-bitmap: delay registration of bitmap_ops until creating bitmap") Reviewed-by: Su Yue Link: https://lore.kernel.org/r/20260425024615.1696892-4-yukuai@fnnas.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 7035caaa1b6f9344824060d4435d8a194195187e Author: Yu Kuai Date: Sat Apr 25 10:46:14 2026 +0800 md/md-bitmap: split bitmap sysfs groups [ Upstream commit aba3d6d6cb55c6e1116d1215140559dd7ecdf9a9 ] Split the classic bitmap sysfs files into a common bitmap group with the location attribute and a separate internal bitmap group for the remaining files. At the same time, convert bitmap operations from a single sysfs group to a sysfs group array so backends can share part of their sysfs layout while adding backend-specific attributes separately. Switch the bitmap sysfs helpers to use sysfs_update_groups() for the add and update path, and remove groups in reverse order so shared named groups are unmerged before the last group removes the directory. Also make bitmap operation lookup depend only on the currently selected bitmap id matching the installed backend. This prepares the lookup path for a later registered none backend. Reviewed-by: Su Yue Link: https://lore.kernel.org/r/20260425024615.1696892-3-yukuai@fnnas.com Signed-off-by: Yu Kuai Stable-dep-of: f2926a533d03 ("md/md-bitmap: add a none backend for bitmap grow") Signed-off-by: Sasha Levin commit 4d48143103919abc6b037a727256f9a366a78f9f Author: Yu Kuai Date: Sat Apr 25 10:46:13 2026 +0800 md: factor bitmap creation away from sysfs handling [ Upstream commit 8776d342cf8fa0b98ca5e6fb2d956966fb5ca364 ] Factor bitmap creation and destruction into helpers that do not touch bitmap sysfs registration. This prepares the bitmap sysfs rework so callers such as the sysfs bitmap location path can create or destroy a bitmap backend without coupling that to sysfs group lifetime management. Reviewed-by: Su Yue Link: https://lore.kernel.org/r/20260425024615.1696892-2-yukuai@fnnas.com Signed-off-by: Yu Kuai Stable-dep-of: f2926a533d03 ("md/md-bitmap: add a none backend for bitmap grow") Signed-off-by: Sasha Levin commit 00d5ae2b3b0f08c9ec17b40f1a83fc39aba9ba17 Author: Yu Kuai Date: Mon Mar 23 13:46:42 2026 +0800 md: add fallback to correct bitmap_ops on version mismatch [ Upstream commit 09af773650024279a60348e7319d599e6571b15c ] If default bitmap version and on-disk version doesn't match, and mdadm is not the latest version to set bitmap_type, set bitmap_ops based on the disk version. Link: https://lore.kernel.org/linux-raid/20260323054644.3351791-2-yukuai@fnnas.com/ Signed-off-by: Yu Kuai Stable-dep-of: f2926a533d03 ("md/md-bitmap: add a none backend for bitmap grow") Signed-off-by: Sasha Levin commit d934a2bbed534e995431f9e0f9bf17d285f5d109 Author: Keith Busch Date: Thu Apr 16 07:03:45 2026 -0700 md/raid1,raid10: don't fail devices for invalid IO errors [ Upstream commit f7b24c7b41f23b5f9caa8b913afe79cd4c397d39 ] BLK_STS_INVAL indicates the IO request itself was invalid, not that the device has failed. When raid1 treats this as a device error, it retries on alternate mirrors which fail the same way, eventually exceeding the read error threshold and removing the device from the array. This happens when stacking configurations bypass bio_split_to_limits() in the IO path: dm-raid calls md_handle_request() directly without going through md_submit_bio(), skipping the alignment validation that would otherwise reject invalid bios early. The invalid bio reaches the lower block layers, which fail the bio with BLK_STS_INVAL, and raid1 wrongly interprets this as a device failure. Add BLK_STS_INVAL to raid1_should_handle_error() so that invalid IO errors are propagated back to the caller rather than triggering device removal. This is consistent with the previous kernel behavior when alignment checks were done earlier in the direct-io path. Fixes: 5ff3f74e145adc7 ("block: simplify direct io validity check") Reported-by: Tomáš Trnka Closes: https://lore.kernel.org/linux-block/2982107.4sosBPzcNG@electra/ Signed-off-by: Keith Busch Tested-by: Tomáš Trnka Link: https://lore.kernel.org/r/20260416140345.3872265-1-kbusch@meta.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 8252ae66cfc4da6657d7dfee925970e6c301b821 Author: William A. Kennington III Date: Thu Apr 23 00:46:52 2026 -0700 net: mctp i2c: check length before marking flow active [ Upstream commit 4ca07b9239bd0478ae586632a2ed72be37ed8407 ] Currently, mctp_i2c_get_tx_flow_state() is called before the packet length sanity check. This function marks a new flow as active in the MCTP core. If the sanity check fails, mctp_i2c_xmit() returns early without calling mctp_i2c_lock_nest(). This results in a mismatched locking state: the flow is active, but the I2C bus lock was never acquired for it. When the flow is later released, mctp_i2c_release_flow() will see the active state and queue an unlock marker. The TX thread will then decrement midev->i2c_lock_count from 0, causing it to underflow to -1. This underflow permanently breaks the driver's locking logic, allowing future transmissions to occur without holding the I2C bus lock, leading to bus collisions and potential hardware hangs. Move the mctp_i2c_get_tx_flow_state() call to after the length sanity check to ensure we only transition the flow state if we are actually going to proceed with the transmission and locking. Fixes: f5b8abf9fc3d ("mctp i2c: MCTP I2C binding driver") Signed-off-by: William A. Kennington III Acked-by: Jeremy Kerr Link: https://patch.msgid.link/20260423074741.201460-1-william@wkennington.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f3c16e1f4a314a20717ab90a41885f8111a242ab Author: Zicheng Qu Date: Fri Apr 24 07:11:13 2026 +0000 sched/fair: Clear rel_deadline when initializing forked entities [ Upstream commit 3da56dc063cd77b9c0b40add930767fab4e389f3 ] A yield-triggered crash can happen when a newly forked sched_entity enters the fair class with se->rel_deadline unexpectedly set. The failing sequence is: 1. A task is forked while se->rel_deadline is still set. 2. __sched_fork() initializes vruntime, vlag and other sched_entity state, but does not clear rel_deadline. 3. On the first enqueue, enqueue_entity() calls place_entity(). 4. Because se->rel_deadline is set, place_entity() treats se->deadline as a relative deadline and converts it to an absolute deadline by adding the current vruntime. 5. However, the forked entity's deadline is not a valid inherited relative deadline for this new scheduling instance, so the conversion produces an abnormally large deadline. 6. If the task later calls sched_yield(), yield_task_fair() advances se->vruntime to se->deadline. 7. The inflated vruntime is then used by the following enqueue path, where the vruntime-derived key can overflow when multiplied by the entity weight. 8. This corrupts cfs_rq->sum_w_vruntime, breaks EEVDF eligibility calculation, and can eventually make all entities appear ineligible. pick_next_entity() may then return NULL unexpectedly, leading to a later NULL dereference. A captured trace shows the effect clearly. Before yield, the entity's vruntime was around: 9834017729983308 After yield_task_fair() executed: se->vruntime = se->deadline the vruntime jumped to: 19668035460670230 and the deadline was later advanced further to: 19668035463470230 This shows that the deadline had already become abnormally large before yield_task_fair() copied it into vruntime. rel_deadline is only meaningful when se->deadline really carries a relative deadline that still needs to be placed against vruntime. A freshly forked sched_entity should not inherit or retain this state. Clear se->rel_deadline in __sched_fork(), together with the other sched_entity runtime state, so that the first enqueue does not interpret the new entity's deadline as a stale relative deadline. Fixes: 82e9d0456e06 ("sched/fair: Avoid re-setting virtual deadline on 'migrations'") Analyzed-by: Hui Tang Analyzed-by: Zhang Qiao Signed-off-by: Zicheng Qu Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260424071113.1199600-1-quzicheng@huawei.com Signed-off-by: Sasha Levin commit 63273472430ea50b7e1ea1c4e2b4a385af4c78b1 Author: Vincent Guittot Date: Wed Apr 22 11:34:00 2026 +0200 sched/fair: Fix wakeup_preempt_fair() vs delayed dequeue [ Upstream commit ac8e69e693631689d74d8f1ebee6f84f737f797f ] Similar to how pick_next_entity() must dequeue delayed entities, so too must wakeup_preempt_fair(). Any delayed task being found means it is eligible and hence past the 0-lag point, ready for removal. Worse, by not removing delayed entities from consideration, it can skew the preemption decision, with the end result that a short slice wakeup will not result in a preemption. tip/sched/core tip/sched/core +this patch cyclictest slice (ms) (default)2.8 8 8 hackbench slice (ms) (default)2.8 20 20 Total Samples | 22559 22595 22683 Average (us) | 157 64( 59%) 59( 8%) Median (P50) (us) | 57 57( 0%) 58(- 2%) 90th Percentile (us) | 64 60( 6%) 60( 0%) 99th Percentile (us) | 2407 67( 97%) 67( 0%) 99.9th Percentile (us) | 3400 2288( 33%) 727( 68%) Maximum (us) | 5037 9252(-84%) 7461( 19%) Fixes: f12e148892ed ("sched/fair: Prepare pick_next_task() for delayed dequeue") Signed-off-by: Vincent Guittot Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260422093400.319251-1-vincent.guittot@linaro.org Signed-off-by: Sasha Levin commit 7ce7a08cde16bd28d406e870fa0baa076e0eb160 Author: Mel Gorman Date: Wed Nov 12 12:25:21 2025 +0000 sched/fair: Reimplement NEXT_BUDDY to align with EEVDF goals [ Upstream commit e837456fdca81899a3c8e47b3fd39e30eae6e291 ] Reimplement NEXT_BUDDY preemption to take into account the deadline and eligibility of the wakee with respect to the waker. In the event multiple buddies could be considered, the one with the earliest deadline is selected. Sync wakeups are treated differently to every other type of wakeup. The WF_SYNC assumption is that the waker promises to sleep in the very near future. This is violated in enough cases that WF_SYNC should be treated as a suggestion instead of a contract. If a waker does go to sleep almost immediately then the delay in wakeup is negligible. In other cases, it's throttled based on the accumulated runtime of the waker so there is a chance that some batched wakeups have been issued before preemption. For all other wakeups, preemption happens if the wakee has a earlier deadline than the waker and eligible to run. While many workloads were tested, the two main targets were a modified dbench4 benchmark and hackbench because the are on opposite ends of the spectrum -- one prefers throughput by avoiding preemption and the other relies on preemption. First is the dbench throughput data even though it is a poor metric but it is the default metric. The test machine is a 2-socket machine and the backing filesystem is XFS as a lot of the IO work is dispatched to kernel threads. It's important to note that these results are not representative across all machines, especially Zen machines, as different bottlenecks are exposed on different machines and filesystems. dbench4 Throughput (misleading but traditional) 6.18-rc1 6.18-rc1 vanilla sched-preemptnext-v5 Hmean 1 1268.80 ( 0.00%) 1269.74 ( 0.07%) Hmean 4 3971.74 ( 0.00%) 3950.59 ( -0.53%) Hmean 7 5548.23 ( 0.00%) 5420.08 ( -2.31%) Hmean 12 7310.86 ( 0.00%) 7165.57 ( -1.99%) Hmean 21 8874.53 ( 0.00%) 9149.04 ( 3.09%) Hmean 30 9361.93 ( 0.00%) 10530.04 ( 12.48%) Hmean 48 9540.14 ( 0.00%) 11820.40 ( 23.90%) Hmean 79 9208.74 ( 0.00%) 12193.79 ( 32.42%) Hmean 110 8573.12 ( 0.00%) 11933.72 ( 39.20%) Hmean 141 7791.33 ( 0.00%) 11273.90 ( 44.70%) Hmean 160 7666.60 ( 0.00%) 10768.72 ( 40.46%) As throughput is misleading, the benchmark is modified to use a short loadfile report the completion time duration in milliseconds. dbench4 Loadfile Execution Time 6.18-rc1 6.18-rc1 vanilla sched-preemptnext-v5 Amean 1 14.62 ( 0.00%) 14.69 ( -0.46%) Amean 4 18.76 ( 0.00%) 18.85 ( -0.45%) Amean 7 23.71 ( 0.00%) 24.38 ( -2.82%) Amean 12 31.25 ( 0.00%) 31.87 ( -1.97%) Amean 21 45.12 ( 0.00%) 43.69 ( 3.16%) Amean 30 61.07 ( 0.00%) 54.33 ( 11.03%) Amean 48 95.91 ( 0.00%) 77.22 ( 19.49%) Amean 79 163.38 ( 0.00%) 123.08 ( 24.66%) Amean 110 243.91 ( 0.00%) 175.11 ( 28.21%) Amean 141 343.47 ( 0.00%) 239.10 ( 30.39%) Amean 160 401.15 ( 0.00%) 283.73 ( 29.27%) Stddev 1 0.52 ( 0.00%) 0.51 ( 2.45%) Stddev 4 1.36 ( 0.00%) 1.30 ( 4.04%) Stddev 7 1.88 ( 0.00%) 1.87 ( 0.72%) Stddev 12 3.06 ( 0.00%) 2.45 ( 19.83%) Stddev 21 5.78 ( 0.00%) 3.87 ( 33.06%) Stddev 30 9.85 ( 0.00%) 5.25 ( 46.76%) Stddev 48 22.31 ( 0.00%) 8.64 ( 61.27%) Stddev 79 35.96 ( 0.00%) 18.07 ( 49.76%) Stddev 110 59.04 ( 0.00%) 30.93 ( 47.61%) Stddev 141 85.38 ( 0.00%) 40.93 ( 52.06%) Stddev 160 96.38 ( 0.00%) 39.72 ( 58.79%) That is still looking good and the variance is reduced quite a bit. Finally, fairness is a concern so the next report tracks how many milliseconds does it take for all clients to complete a workfile. This one is tricky because dbench makes to effort to synchronise clients so the durations at benchmark start time differ substantially from typical runtimes. This problem could be mitigated by warming up the benchmark for a number of minutes but it's a matter of opinion whether that counts as an evasion of inconvenient results. dbench4 All Clients Loadfile Execution Time 6.18-rc1 6.18-rc1 vanilla sched-preemptnext-v5 Amean 1 15.06 ( 0.00%) 15.07 ( -0.03%) Amean 4 603.81 ( 0.00%) 524.29 ( 13.17%) Amean 7 855.32 ( 0.00%) 1331.07 ( -55.62%) Amean 12 1890.02 ( 0.00%) 2323.97 ( -22.96%) Amean 21 3195.23 ( 0.00%) 2009.29 ( 37.12%) Amean 30 13919.53 ( 0.00%) 4579.44 ( 67.10%) Amean 48 25246.07 ( 0.00%) 5705.46 ( 77.40%) Amean 79 29701.84 ( 0.00%) 15509.26 ( 47.78%) Amean 110 22803.03 ( 0.00%) 23782.08 ( -4.29%) Amean 141 36356.07 ( 0.00%) 25074.20 ( 31.03%) Amean 160 17046.71 ( 0.00%) 13247.62 ( 22.29%) Stddev 1 0.47 ( 0.00%) 0.49 ( -3.74%) Stddev 4 395.24 ( 0.00%) 254.18 ( 35.69%) Stddev 7 467.24 ( 0.00%) 764.42 ( -63.60%) Stddev 12 1071.43 ( 0.00%) 1395.90 ( -30.28%) Stddev 21 1694.50 ( 0.00%) 1204.89 ( 28.89%) Stddev 30 7945.63 ( 0.00%) 2552.59 ( 67.87%) Stddev 48 14339.51 ( 0.00%) 3227.55 ( 77.49%) Stddev 79 16620.91 ( 0.00%) 8422.15 ( 49.33%) Stddev 110 12912.15 ( 0.00%) 13560.95 ( -5.02%) Stddev 141 20700.13 ( 0.00%) 14544.51 ( 29.74%) Stddev 160 9079.16 ( 0.00%) 7400.69 ( 18.49%) This is more of a mixed bag but it at least shows that fairness is not crippled. The hackbench results are more neutral but this is still important. It's possible to boost the dbench figures by a large amount but only by crippling the performance of a workload like hackbench. The WF_SYNC behaviour is important for these workloads and is why the WF_SYNC changes are not a separate patch. hackbench-process-pipes 6.18-rc1 6.18-rc1 vanilla sched-preemptnext-v5 Amean 1 0.2657 ( 0.00%) 0.2150 ( 19.07%) Amean 4 0.6107 ( 0.00%) 0.6060 ( 0.76%) Amean 7 0.7923 ( 0.00%) 0.7440 ( 6.10%) Amean 12 1.1500 ( 0.00%) 1.1263 ( 2.06%) Amean 21 1.7950 ( 0.00%) 1.7987 ( -0.20%) Amean 30 2.3207 ( 0.00%) 2.5053 ( -7.96%) Amean 48 3.5023 ( 0.00%) 3.9197 ( -11.92%) Amean 79 4.8093 ( 0.00%) 5.2247 ( -8.64%) Amean 110 6.1160 ( 0.00%) 6.6650 ( -8.98%) Amean 141 7.4763 ( 0.00%) 7.8973 ( -5.63%) Amean 172 8.9560 ( 0.00%) 9.3593 ( -4.50%) Amean 203 10.4783 ( 0.00%) 10.8347 ( -3.40%) Amean 234 12.4977 ( 0.00%) 13.0177 ( -4.16%) Amean 265 14.7003 ( 0.00%) 15.5630 ( -5.87%) Amean 296 16.1007 ( 0.00%) 17.4023 ( -8.08%) Processes using pipes are impacted but the variance (not presented) indicates it's close to noise and the results are not always reproducible. If executed across multiple reboots, it may show neutral or small gains so the worst measured results are presented. Hackbench using sockets is more reliably neutral as the wakeup mechanisms are different between sockets and pipes. hackbench-process-sockets 6.18-rc1 6.18-rc1 vanilla sched-preemptnext-v2 Amean 1 0.3073 ( 0.00%) 0.3263 ( -6.18%) Amean 4 0.7863 ( 0.00%) 0.7930 ( -0.85%) Amean 7 1.3670 ( 0.00%) 1.3537 ( 0.98%) Amean 12 2.1337 ( 0.00%) 2.1903 ( -2.66%) Amean 21 3.4683 ( 0.00%) 3.4940 ( -0.74%) Amean 30 4.7247 ( 0.00%) 4.8853 ( -3.40%) Amean 48 7.6097 ( 0.00%) 7.8197 ( -2.76%) Amean 79 14.7957 ( 0.00%) 16.1000 ( -8.82%) Amean 110 21.3413 ( 0.00%) 21.9997 ( -3.08%) Amean 141 29.0503 ( 0.00%) 29.0353 ( 0.05%) Amean 172 36.4660 ( 0.00%) 36.1433 ( 0.88%) Amean 203 39.7177 ( 0.00%) 40.5910 ( -2.20%) Amean 234 42.1120 ( 0.00%) 43.5527 ( -3.42%) Amean 265 45.7830 ( 0.00%) 50.0560 ( -9.33%) Amean 296 50.7043 ( 0.00%) 54.3657 ( -7.22%) As schbench has been mentioned in numerous bugs recently, the results are interesting. A test case that represents the default schbench behaviour is schbench Wakeup Latency (usec) 6.18.0-rc1 6.18.0-rc1 vanilla sched-preemptnext-v5 Amean Wakeup-50th-80 7.17 ( 0.00%) 6.00 ( 16.28%) Amean Wakeup-90th-80 46.56 ( 0.00%) 19.78 ( 57.52%) Amean Wakeup-99th-80 119.61 ( 0.00%) 89.94 ( 24.80%) Amean Wakeup-99.9th-80 3193.78 ( 0.00%) 328.22 ( 89.72%) schbench Requests Per Second (ops/sec) 6.18.0-rc1 6.18.0-rc1 vanilla sched-preemptnext-v5 Hmean RPS-20th-80 8900.91 ( 0.00%) 9176.78 ( 3.10%) Hmean RPS-50th-80 8987.41 ( 0.00%) 9217.89 ( 2.56%) Hmean RPS-90th-80 9123.73 ( 0.00%) 9273.25 ( 1.64%) Hmean RPS-max-80 9193.50 ( 0.00%) 9301.47 ( 1.17%) Signed-off-by: Mel Gorman Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20251112122521.1331238-3-mgorman@techsingularity.net Stable-dep-of: ac8e69e69363 ("sched/fair: Fix wakeup_preempt_fair() vs delayed dequeue") Signed-off-by: Sasha Levin commit 67bdf14af6b8fabd52df8ed20827e4ad7696abff Author: Takashi Iwai Date: Mon Apr 27 17:15:04 2026 +0200 ALSA: usb-audio: Fix potential leak of pd at parsing UAC3 streams [ Upstream commit c39f0bc03f84ba64c9144c95714df1dc36150f6d ] At parsing UAC3 streams, we allocate a PD object at each time, and either assign or free it. But there is a case where the PD object may be leaked; namely, in __snd_usb_parse_audio_interface() loop, when an audioformat shares the same endpoint with others, it's put to a link and returns from snd_usb_add_audio_stream(), but the PD is forgotten afterwards. Overall, the treatment of PD object in the parser code is a bit flaky, and we should be more careful about the object ownership. This patch tries to fix the above case and improve the code a bit. The pd object is now managed with the auto-cleanup in the loop, and the ownership is updated when the pd object gets assigned to the stream, which guarantees the release of the leftover object. Fixes: 7edf3b5e6a45 ("ALSA: usb-audio: AudioStreaming Power Domain parsing") Link: https://patch.msgid.link/20260427151508.12544-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit f9e6b2f22b1f70de3f2af2145b69a58dfa1d7b3e Author: Breno Leitao Date: Fri Apr 24 08:31:16 2026 -0700 netpoll: fix IPv6 local-address corruption [ Upstream commit 3bc179bc7146c26c9dff75d2943d10528274e301 ] netpoll_setup() decides whether to auto-populate the local source address by testing np->local_ip.ip, which only inspects the first 4 bytes of the union inet_addr storage. For an IPv6 netpoll whose caller-supplied local address has a zero high-32 bits (::1, ::, IPv4-mapped ::ffff:a.b.c.d, etc.), this misdetects the address as unset (which they are not, but the first 4 bytes are empty), calls netpoll_take_ipv6() and overwrites it with whatever matching link-local/global address the device happens to expose first. Introduce a helper netpoll_local_ip_unset() that picks the correct family-aware test (ipv6_addr_any() for IPv6, !.ip for IPv4) and use it from netpoll_setup(). Reproducer is something like: echo "::2" > local_ip echo 1 > enabled cat local_ip # before this fix: 2001:db8::1 (caller-supplied ::2 was clobbered) # after this fix: ::2 Fixes: b7394d2429c1 ("netpoll: prepare for ipv6") Signed-off-by: Breno Leitao Link: https://patch.msgid.link/20260424-netpoll_fix-v1-1-3a55348c625f@debian.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9544ca41e1ec6900610af46b3abebcb9d62ddea1 Author: Altan Hacigumus Date: Thu Apr 23 18:46:38 2026 -0700 tcp: make probe0 timer handle expired user timeout [ Upstream commit 2b9f6f7065d4cfb65ba19126e0b35ac4544c3f3a ] tcp_clamp_probe0_to_user_timeout() computes remaining time in jiffies using subtraction with an unsigned lvalue. If elapsed probing time exceeds the configured TCP_USER_TIMEOUT, the underflow yields a large value. This ends up re-arming the probe timer for a full backoff interval instead of expiring immediately, delaying connection teardown beyond the configured timeout. Fix this by preventing underflow so user-set timeout expiration is handled correctly without extending the probe timer. Fixes: 344db93ae3ee ("tcp: make TCP_USER_TIMEOUT accurate for zero window probes") Link: https://lore.kernel.org/r/20260414013634.43997-1-ahacigu.linux@gmail.com Signed-off-by: Altan Hacigumus Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260424014639.54110-1-ahacigu.linux@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 63063ba60d2dc334e34f1e3f9271d7f3f6f30307 Author: Florian Westphal Date: Fri Apr 24 16:58:38 2026 +0200 neigh: let neigh_xmit take skb ownership [ Upstream commit 4438113be604ee67a7bf4f81da6e1cca41332ce4 ] neigh_xmit always releases the skb, except when no neighbour table is found. But even the first added user of neigh_xmit (mpls) relied on neigh_xmit to release the skb (or queue it for tx). sashiko reported: If neigh_xmit() is called with an uninitialized neighbor table (for example, NEIGH_ND_TABLE when IPv6 is disabled), it returns -EAFNOSUPPORT and bypasses its internal out_kfree_skb error path. Because the return value of neigh_xmit() is ignored here, does this leak the SKB? Assume full ownership and remove the last code path that doesn't xmit or free skb. Fixes: 4fd3d7d9e868 ("neigh: Add helper function neigh_xmit") Signed-off-by: Florian Westphal Reviewed-by: Kuniyuki Iwashima Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260424145843.74055-1-fw@strlen.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 48b26d48e76221dc90b02bf5428bab53643461ca Author: Weiming Shi Date: Thu Apr 23 00:19:58 2026 +0800 net/sched: taprio: fix NULL pointer dereference in class dump [ Upstream commit 3d07ca5c0fae311226f737963984bd94bb159a87 ] When a TAPRIO child qdisc is deleted via RTM_DELQDISC, taprio_graft() is called with new == NULL and stores NULL into q->qdiscs[cl - 1]. Subsequent RTM_GETTCLASS dump operations walk all classes via taprio_walk() and call taprio_dump_class(), which calls taprio_leaf() returning the NULL pointer, then dereferences it to read child->handle, causing a kernel NULL pointer dereference. The bug is reachable with namespace-scoped CAP_NET_ADMIN on any kernel with CONFIG_NET_SCH_TAPRIO enabled. On systems with unprivileged user namespaces enabled, an unprivileged local user can trigger a kernel panic by creating a taprio qdisc inside a new network namespace, grafting an explicit child qdisc, deleting it, and requesting a class dump. The RTM_GETTCLASS dump itself requires no capability. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000007: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:taprio_dump_class (net/sched/sch_taprio.c:2478) Call Trace: tc_fill_tclass (net/sched/sch_api.c:1966) qdisc_class_dump (net/sched/sch_api.c:2326) taprio_walk (net/sched/sch_taprio.c:2514) tc_dump_tclass_qdisc (net/sched/sch_api.c:2352) tc_dump_tclass_root (net/sched/sch_api.c:2370) tc_dump_tclass (net/sched/sch_api.c:2431) rtnl_dumpit (net/core/rtnetlink.c:6864) netlink_dump (net/netlink/af_netlink.c:2325) rtnetlink_rcv_msg (net/core/rtnetlink.c:6959) netlink_rcv_skb (net/netlink/af_netlink.c:2550) Fix this by substituting &noop_qdisc when new is NULL in taprio_graft(), a common pattern used by other qdiscs (e.g., multiq_graft()) to ensure the q->qdiscs[] slots are never NULL. This makes control-plane dump paths safe without requiring individual NULL checks. Since the data-plane paths (taprio_enqueue and taprio_dequeue_from_txq) previously had explicit NULL guards that would drop/skip the packet cleanly, update those checks to test for &noop_qdisc instead. Without this, packets would reach taprio_enqueue_one() which increments the root qdisc's qlen and backlog before calling the child's enqueue; noop_qdisc drops the packet but those counters are never rolled back, permanently inflating the root qdisc's statistics. After this change *old can be a valid qdisc, NULL, or &noop_qdisc. Only call qdisc_put(*old) in the first case to avoid decreasing noop_qdisc's refcount, which was never increased. Fixes: 665338b2a7a0 ("net/sched: taprio: dump class stats for the actual q->qdiscs[]") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Acked-by: Jamal Hadi Salim Tested-by: Weiming Shi Link: https://patch.msgid.link/20260422161958.2517539-3-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cca14c404c0e1d58ed62f3a0c676138c8b238a0e Author: Paul Geurts Date: Wed Apr 22 12:09:30 2026 +0200 NFC: trf7970a: Ignore antenna noise when checking for RF field [ Upstream commit a9bc28aa4e64320668131349436a650bf42591a5 ] The main channel Received Signal Strength Indicator (RSSI) measurement is used to determine whether an RF field is present or not. RSSI != 0 is interpreted as an RF Field is present. This does not take RF noise and measurement inaccuracy into account, and results in false positives in the field. Define a noise level and make sure the RF field is only interpreted as present when the RSSI is above the noise level. Fixes: 851ee3cbf850 ("NFC: trf7970a: Don't turn on RF if there is already an RF field") Signed-off-by: Paul Geurts Reviewed-by: Krzysztof Kozlowski Reviewed-by: Mark Greer Link: https://patch.msgid.link/20260422100930.581237-1-paul.geurts@prodrive-technologies.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3dc58085988b5a1132182948bd8db02de5f0d1f4 Author: Felix Gu Date: Tue Apr 28 01:42:00 2026 +0800 spi: amlogic-spisg: initialize completion before requesting IRQ [ Upstream commit 8d0189c1ea98b56481eb809e3d1bdbf85557e819 ] Move init_completion(&spisg->completion) to before devm_request_irq() to avoid a potential race condition where an interrupt could fire before the completion structure is initialized. Fixes: cef9991e04ae ("spi: Add Amlogic SPISG driver") Signed-off-by: Felix Gu Link: https://patch.msgid.link/20260428-amlogic-spisg-v1-1-8eecc3b446d6@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 81fc967bf476d62fbbc0e77d7ce9546b13c39965 Author: Morduan Zang Date: Fri Apr 24 09:55:17 2026 +0800 net: usb: rtl8150: free skb on usb_submit_urb() failure in xmit [ Upstream commit adbe2cdf75461891e50dbe11896ac78e9af1f874 ] When rtl8150_start_xmit() fails to submit the tx URB, the URB is never handed to the USB core and write_bulk_callback() will not run. The driver returns NETDEV_TX_OK, which tells the networking stack that the skb has been consumed, but nothing actually frees the skb on this error path: dev->tx_skb = skb; ... if ((res = usb_submit_urb(dev->tx_urb, GFP_ATOMIC))) { ... /* no kfree_skb here */ } return NETDEV_TX_OK; This leaks the skb on every submit failure and also leaves dev->tx_skb pointing at memory that the driver itself may later free, which is fragile. Free the skb with dev_kfree_skb_any() in the error path and clear dev->tx_skb so no stale pointer is left behind. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reviewed-by: Andrew Lunn Signed-off-by: Morduan Zang Link: https://patch.msgid.link/E7D3E1C013C5A859+20260424015517.9574-1-zhangdandan@uniontech.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6999d70e0eda39af029fa1891c48f0a8832b09d5 Author: Zhan Jun Date: Thu Apr 23 08:49:12 2026 +0800 net: usb: rtl8150: fix use-after-free in rtl8150_start_xmit() [ Upstream commit 23f0e34c64acba15cad4d23e50f41f533da195fa ] syzbot reported a KASAN slab-use-after-free read in rtl8150_start_xmit() when accessing skb->len for tx statistics after usb_submit_urb() has been called: BUG: KASAN: slab-use-after-free in rtl8150_start_xmit+0x71f/0x760 drivers/net/usb/rtl8150.c:712 Read of size 4 at addr ffff88810eb7a930 by task kworker/0:4/5226 The URB completion handler write_bulk_callback() frees the skb via dev_kfree_skb_irq(dev->tx_skb). The URB may complete on another CPU in softirq context before usb_submit_urb() returns in the submitter, so by the time the submitter reads skb->len the skb has already been queued to the per-CPU completion_queue and freed by net_tx_action(): CPU A (xmit) CPU B (USB completion softirq) ------------ ------------------------------ dev->tx_skb = skb; usb_submit_urb() --+ |-------> write_bulk_callback() | dev_kfree_skb_irq(dev->tx_skb) | net_tx_action() | napi_skb_cache_put() <-- free netdev->stats.tx_bytes | += skb->len; <-- UAF read Fix it by caching skb->len before submitting the URB and using the cached value when updating the tx_bytes counter. The pre-existing tx_bytes semantics are preserved: the counter tracks the original frame length (skb->len), not the ETH_ZLEN/USB-alignment padded "count" value that is handed to the device. Changing that would be a user-visible accounting change and is out of scope for this UAF fix. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+3f46c095ac0ca048cb71@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/69e69ee7.050a0220.24bfd3.002b.GAE@google.com/ Closes: https://syzkaller.appspot.com/bug?extid=3f46c095ac0ca048cb71 Reviewed-by: Andrew Lunn Signed-off-by: Zhan Jun Link: https://patch.msgid.link/809895186B866C10+20260423004913.136655-1-zhangdandan@uniontech.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a7a97f2303e63ede105c1d55ef53dc497364e11d Author: Ido Schimmel Date: Thu Apr 23 09:36:07 2026 +0300 vrf: Fix a potential NPD when removing a port from a VRF [ Upstream commit 2674d603a9e6970463b2b9ebcf8e31e90beae169 ] RCU readers that identified a net device as a VRF port using netif_is_l3_slave() assume that a subsequent call to netdev_master_upper_dev_get_rcu() will return a VRF device. They then continue to dereference its l3mdev operations. This assumption is not always correct and can result in a NPD [1]. There is no RCU synchronization when removing a port from a VRF, so it is possible for an RCU reader to see a new master device (e.g., a bridge) that does not have l3mdev operations. Fix by adding RCU synchronization after clearing the IFF_L3MDEV_SLAVE flag. Skip this synchronization when a net device is removed from a VRF as part of its deletion and when the VRF device itself is deleted. In the latter case an RCU grace period will pass by the time RTNL is released. [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] RIP: 0010:l3mdev_fib_table_rcu (net/l3mdev/l3mdev.c:181) [...] Call Trace: l3mdev_fib_table_by_index (net/l3mdev/l3mdev.c:201 net/l3mdev/l3mdev.c:189) __inet_bind (net/ipv4/af_inet.c:499 (discriminator 3)) inet_bind_sk (net/ipv4/af_inet.c:469) __sys_bind (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:1951 (discriminator 1)) __x64_sys_bind (net/socket.c:1969 (discriminator 1) net/socket.c:1967 (discriminator 1) net/socket.c:1967 (discriminator 1)) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Fixes: fdeea7be88b1 ("net: vrf: Set slave's private flag before linking") Reported-by: Haoze Xie Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Yuan Tan Closes: https://lore.kernel.org/netdev/20260419145332.3988923-1-n05ec@lzu.edu.cn/ Signed-off-by: Ido Schimmel Reviewed-by: David Ahern Link: https://patch.msgid.link/20260423063607.1208202-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 02495cc4a33e2c98778d320dc2ab111d6fedd381 Author: Eric Dumazet Date: Thu Apr 23 06:35:27 2026 +0000 net/sched: sch_fq_pie: annotate data-races in fq_pie_dump_stats() [ Upstream commit 59b145771c7982cfe9020d4e9e22da92d6b5ae31 ] fq_codel_dump_stats() acquires the qdisc spinlock a bit too late. Move this acquisition before we fill tc_fq_pie_xstats with live data. Alternative would be to add READ_ONCE() and WRITE_ONCE() annotations, but the spinlock is needed anyway to scan q->new_flows and q->old_flows. Fixes: ec97ecf1ebe4 ("net: sched: add Flow Queue PIE packet scheduler") Signed-off-by: Eric Dumazet Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260423063527.2568262-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 10c242aa0c54872b3e77af33fb3d896adc8562a5 Author: Eric Dumazet Date: Thu Apr 23 06:28:39 2026 +0000 net/sched: sch_choke: annotate data-races in choke_dump_stats() [ Upstream commit d3aeb889dcbd78e95f500d383799a23d949796e0 ] choke_dump_stats() only runs with RTNL held. It reads fields that can be changed in qdisc fast path. Add READ_ONCE()/WRITE_ONCE() annotations. Fixes: edb09eb17ed8 ("net: sched: do not acquire qdisc spinlock in qdisc/class stats dump") Signed-off-by: Eric Dumazet Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260423062839.2524324-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f670fa4b19ceddc6d215dda4997888ccba9bbc61 Author: Lorenzo Bianconi Date: Fri Apr 24 11:00:28 2026 +0200 net: airoha: Do not read uninitialized fragment address in airoha_dev_xmit() [ Upstream commit bde34e84edc8b5571fbde7e941e175a4293ee1eb ] The transmit loop in airoha_dev_xmit() reads fragment address and length during its final iteration, when the loop index equals skb_shinfo(skb)->nr_frags, at which point the fragment data is uninitialized. While these values are never consumed, the read itself is unsafe and may trigger a page fault. Fix this by avoiding the fragment read on the last iteration. Additionally, move the skb pointer from the first to the last used packet descriptor, so that airoha_qdma_tx_napi_poll() defers freeing the skb until the final descriptor is processed. Fixes: 23020f0493270 ("net: airoha: Introduce ethernet support for EN7581 SoC") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260424-airoha-xmit-fix-read-frag-v1-1-fdc0a83c79e8@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f4b7ed23fae6ca595129810d8a1b9a70eb26818e Author: Lorenzo Bianconi Date: Tue Apr 21 10:53:33 2026 +0200 net: airoha: Do not wake all netdev TX queues in airoha_qdma_wake_netdev_txqs() [ Upstream commit e070aac63b42bf81f4dc565f9f841ff47e6c992f ] Do not wake every netdev TX queue across all ports sharing the QDMA running netif_tx_wake_all_queues routine in airoha_qdma_wake_netdev_txqs() but only the ones that are mapped the specific QDMA stopped hw TX queue. This patch can potentially avoid waking already stopped netdev TX queues that are mapped to a different QDMA hw TX queue. Introduce airoha_qdma_get_txq utility routine. Fixes: b94769eb2f30 ("net: airoha: Fix possible TX queue stall in airoha_qdma_tx_napi_poll()") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260421-airoha-wake_netdev_txqs-optmization-v1-1-e0be95115d53@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 546d998978dc20e36e19d29fe736f4a48c9e8827 Author: Zhengping Zhang Date: Thu Feb 26 10:37:08 2026 +0800 net: airoha: fix typo in function name [ Upstream commit aebf15e8eb09b01e99f043e9f5d423798aac9d32 ] Corrected the typo in the function name from `airhoa_is_lan_gdm_port` to `airoha_is_lan_gdm_port`. This change ensures consistency in the API naming convention. Signed-off-by: Zhengping Zhang Reviewed-by: Simon Horman Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/tencent_E4FD5D6BC0131E617D848896F5F9FCED6E0A@qq.com Signed-off-by: Jakub Kicinski Stable-dep-of: e070aac63b42 ("net: airoha: Do not wake all netdev TX queues in airoha_qdma_wake_netdev_txqs()") Signed-off-by: Sasha Levin commit b48399bc63ffde0d4be0c38320ece8b7d7b4326e Author: Lorenzo Bianconi Date: Tue Apr 21 08:43:07 2026 +0200 net: airoha: stop net_device TX queue before updating CPU index [ Upstream commit 3854de7b38be742cf7558476956d12414cb274f2 ] Currently, airoha_eth driver updates the CPU index register prior of verifying whether the number of free descriptors has fallen below the threshold. Move net_device TX queue length check before updating the TX CPU index in order to update TX CPU index even if there are more packets to be transmitted but the net_device TX queue is going to be stopped accounting the inflight packets. Fixes: 1d304174106c ("net: airoha: Implement BQL support") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260421-airoha-xmit-stop-condition-v1-1-e670d6a48467@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7a72efd117227faf9571decce2d211101f471a31 Author: Stephen Hemminger Date: Fri Apr 17 20:19:44 2026 -0700 net/sched: netem: check for negative latency and jitter [ Upstream commit 90be9fedb218ee95a1cf59050d1306fbfb0e8b87 ] Reject requests with negative latency or jitter. A negative value added to current timestamp (u64) wraps to an enormous time_to_send, disabling dequeue. The original UAPI used u32 for these values; the conversion to 64-bit time values via TCA_NETEM_LATENCY64 and TCA_NETEM_JITTER64 allowed signed values to reach the kernel without validation. Jitter is already silently clamped by an abs() in netem_change(); that abs() can be removed in a follow-up once this rejection is in place. Fixes: 99803171ef04 ("netem: add uapi to express delay and jitter in nanoseconds") Signed-off-by: Stephen Hemminger Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260418032027.900913-7-stephen@networkplumber.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fabf2b2bbfa1f6a9f609a1419791049fa13f6b71 Author: Stephen Hemminger Date: Fri Apr 17 20:19:43 2026 -0700 net/sched: netem: fix slot delay calculation overflow [ Upstream commit 51e94e1e2fef351c74d69eb53666df808d26af95 ] get_slot_next() computes a random delay between min_delay and max_delay using: get_random_u32() * (max_delay - min_delay) >> 32 This overflows signed 64-bit arithmetic when the delay range exceeds approximately 2.1 seconds (2^31 nanoseconds), producing a negative result that effectively disables slot-based pacing. This is a realistic configuration for WAN emulation (e.g., slot 1s 5s). Use mul_u64_u32_shr() which handles the widening multiply without overflow. Fixes: 0a9fe5c375b5 ("netem: slotting with non-uniform distribution") Signed-off-by: Stephen Hemminger Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260418032027.900913-6-stephen@networkplumber.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2e2a8b077699d31b083a318a513b1b477ff44f43 Author: Stephen Hemminger Date: Fri Apr 17 20:19:42 2026 -0700 net/sched: netem: validate slot configuration [ Upstream commit 01801c359a74737b9b1aa28568b60374d857241a ] Reject slot configurations that have no defensible meaning: - negative min_delay or max_delay - min_delay greater than max_delay - negative dist_delay or dist_jitter - negative max_packets or max_bytes Negative or out-of-order delays underflow in get_slot_next(), producing garbage intervals. Negative limits trip the per-slot accounting (packets_left/bytes_left <= 0) on the first packet of every slot, defeating the rate-limiting half of the slot feature. Note that dist_jitter has been silently coerced to its absolute value by get_slot() since the feature was introduced; rejecting negatives here converts that silent coercion into -EINVAL. The abs() can be removed in a follow-up. Fixes: 836af83b54e3 ("netem: support delivering packets in delayed time slots") Signed-off-by: Stephen Hemminger Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260418032027.900913-5-stephen@networkplumber.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 33cc6a26898aea8d7d7738bca1b2cbdd398ef3b0 Author: Stephen Hemminger Date: Fri Apr 17 20:19:41 2026 -0700 net/sched: netem: only reseed PRNG when seed is explicitly provided [ Upstream commit 986afaf809940577224a99c3a08d97a15eb37e93 ] netem_change() unconditionally reseeds the PRNG on every tc change command. If TCA_NETEM_PRNG_SEED is not specified, a new random seed is generated, destroying reproducibility for users who set a deterministic seed on a previous change. Move the initial random seed generation to netem_init() and only reseed in netem_change() when TCA_NETEM_PRNG_SEED is explicitly provided by the user. Fixes: 4072d97ddc44 ("netem: add prng attribute to netem_sched_data") Signed-off-by: Stephen Hemminger Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260418032027.900913-4-stephen@networkplumber.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8450462eaf91d5d2a9e863507b16d18e814baef3 Author: Stephen Hemminger Date: Fri Apr 17 20:19:40 2026 -0700 net/sched: netem: fix queue limit check to include reordered packets [ Upstream commit 4185701fcce6b426b6c3630b25330dddd9c47b0d ] The queue limit check in netem_enqueue() uses q->t_len which only counts packets in the internal tfifo. Packets placed in sch->q by the reorder path (__qdisc_enqueue_head) are not counted, allowing the total queue occupancy to exceed sch->limit under reordering. Include sch->q.qlen in the limit check. Fixes: f8d4bc455047 ("net/sched: netem: account for backlog updates from child qdisc") Signed-off-by: Stephen Hemminger Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260418032027.900913-3-stephen@networkplumber.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1633087d8a76a7a776740430685521b8fa0ffab3 Author: Stephen Hemminger Date: Fri Apr 17 20:19:39 2026 -0700 net/sched: netem: fix probability gaps in 4-state loss model [ Upstream commit 732b463449fd0ef90acd13cda68eab1c91adb00c ] The 4-state Markov chain in loss_4state() has gaps at the boundaries between transition probability ranges. The comparisons use: if (rnd < a4) else if (a4 < rnd && rnd < a1 + a4) When rnd equals a boundary value exactly, neither branch matches and no state transition occurs. The redundant lower-bound check (a4 < rnd) is already implied by being in the else branch. Remove the unnecessary lower-bound comparisons so the ranges are contiguous and every random value produces a transition, matching the GI (General and Intuitive) loss model specification. This bug goes back to original implementation of this model. Fixes: 661b79725fea ("netem: revised correlated loss generator") Signed-off-by: Stephen Hemminger Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260418032027.900913-2-stephen@networkplumber.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 750d0091bebf44975421268d37484ef87060d263 Author: Nikola Z. Ivanov Date: Sun Apr 26 23:14:34 2026 +0300 netdevsim: zero initialize struct iphdr in dummy sk_buff [ Upstream commit 35eaa6d8d6c2ee65e96f507add856e0eacf24591 ] Syzbot reports a KMSAN uninit-value originating from nsim_dev_trap_skb_build, with the allocation also being performed in the same function. Fix this by calling skb_put_zero instead of skb_put to guarantee zero initialization of the whole IP header. Closes: https://syzkaller.appspot.com/bug?extid=23d7fcd204e3837866ff Fixes: da58f90f11f5 ("netdevsim: Add devlink-trap support") Signed-off-by: Nikola Z. Ivanov Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260426201434.742030-1-zlatistiv@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c9553e0567b0b843c15cacac62e2ff87bfdaa3ea Author: Daan De Meyer Date: Mon Apr 27 22:01:39 2026 +0100 cdrom, scsi: sr: propagate read-only status to block layer via set_disk_ro() [ Upstream commit 0898a817621a2f0cddca8122d9b974003fe5036d ] The cdrom core never calls set_disk_ro() for a registered device, so BLKROGET on a CD-ROM device always returns 0 (writable), even when the drive has no write capabilities and writes will inevitably fail. This causes problems for userspace that relies on BLKROGET to determine whether a block device is read-only. For example, systemd's loop device setup uses BLKROGET to decide whether to create a loop device with LO_FLAGS_READ_ONLY. Without the read-only flag, writes pass through the loop device to the CD-ROM and fail with I/O errors. systemd-fsck similarly checks BLKROGET to decide whether to run fsck in no-repair mode (-n). The write-capability bits in cdi->mask come from two different sources: CDC_DVD_RAM and CDC_CD_RW are populated by the driver from the MODE SENSE capabilities page (page 0x2A) before register_cdrom() is called, while CDC_MRW_W and CDC_RAM require the MMC GET CONFIGURATION command and were only probed by cdrom_open_write() at device open time. This meant that any attempt to compute the writable state from the full mask at probe time was incorrect, because the GET CONFIGURATION bits were still unset (and cdi->mask is initialized such that capabilities are assumed present). Fix this by factoring the GET CONFIGURATION probing out of cdrom_open_write() into a new exported helper, cdrom_probe_write_features(), and having sr call it from sr_probe() right after get_capabilities() has populated the MODE SENSE bits. register_cdrom() then calls set_disk_ro() based on the full write-capability mask (CDC_DVD_RAM | CDC_MRW_W | CDC_RAM | CDC_CD_RW) so the block layer reflects the drive's actual write support. The feature queries used (CDF_MRW and CDF_RWRT via GET CONFIGURATION with RT=00) report drive-level capabilities that are persistent across media, so a single probe before register_cdrom() is sufficient and the redundant probe at open time is dropped. With set_disk_ro() now accurate, the long-vestigial cd->writeable flag in sr can go: get_capabilities() used to set cd->writeable based on the same four mask bits, but because CDC_MRW_W and CDC_RAM default to "capability present" in cdi->mask and aren't touched by MODE SENSE, the condition that gated cd->writeable was always true, making it unconditionally 1. Replace the corresponding gate in sr_init_command() with get_disk_ro(cd->disk), which turns a previously no-op check into a real one and also catches kernel-internal bio writers that bypass blkdev_write_iter()'s bdev_read_only() check. The sd driver (SCSI disks) does not have this problem because it checks the MODE SENSE Write Protect bit and calls set_disk_ro() accordingly. The sr driver cannot use the same approach because the MMC specification does not define the WP bit in the MODE SENSE device-specific parameter byte for CD-ROM devices. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Daan De Meyer Reviewed-by: Phillip Potter Reviewed-by: Martin K. Petersen Signed-off-by: Phillip Potter Link: https://patch.msgid.link/20260427210139.1400-2-phil@philpotter.co.uk Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 156f410cafa2266bbcdf365c60d4dd5487556c98 Author: Tony Luck Date: Tue Apr 21 08:02:16 2026 -0700 ACPI: APEI: EINJ: Fix EINJV2 memory error injection [ Upstream commit 0c00cfbcfcffa7085e4f0c7fd7a4caada4e7a90f ] Error types in EINJV2 use different bit positions for each flavor of injection from legacy EINJ. Two issues: 1) The address sanity checks in einj_error_inject() were skipped for EINJV2 injections. Noted by sashiko[1] 2) __einj_error_trigger() failed to drop the entry of the target physical address from the list of resources that need to be requested. Add a helper function that checks if an injection is to memory and use it to solve each of these issues. Note that the old test in __einj_error_trigger() checked that param2 was not zero. This isn't needed because the sanity checks in einj_error_inject() reject memory injections with param2 == 0. Fixes: b47610296d17 ("ACPI: APEI: EINJ: Enable EINJv2 error injections") Reported-by: sashiko Reported-by: Herman Li Signed-off-by: Tony Luck Tested-by: "Lai, Yi1" Link: https://sashiko.dev/#/patchset/20260415163620.12957-1-tony.luck%40intel.com # [1] Reviewed-by: Jiaqi Yan Reviewed-by: Zaid Alali Link: https://patch.msgid.link/20260421150216.11666-3-tony.luck@intel.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit f6553cca177509c60e8e22d60805aa3245d2a715 Author: Tony Luck Date: Tue Apr 21 08:02:15 2026 -0700 ACPICA: Provide #defines for EINJV2 error types [ Upstream commit 1f6008538384453eb4c13a3d7ff9e37ee8aee6b9 ] EINJV2 defined new error types by moving the severity (correctable, uncorrectable non-fatal, uncorrectable fatal) out of the "type". ACPI 6.5 introduced EINJV2 and defined a vendor defined error type using bit 31. This was dropped in ACPI 6.6. Link: https://github.com/acpica/acpica/commit/e82d2d2fd145 Signed-off-by: Tony Luck Link: https://patch.msgid.link/20260421150216.11666-2-tony.luck@intel.com Signed-off-by: Rafael J. Wysocki Stable-dep-of: 0c00cfbcfcff ("ACPI: APEI: EINJ: Fix EINJV2 memory error injection") Signed-off-by: Sasha Levin commit b69f420c98b2807e71ffb02cf6180da9494b01d3 Author: Wentao Guan Date: Mon Apr 13 17:54:59 2026 +0800 arm64/scs: Fix potential sign extension issue of advance_loc4 [ Upstream commit 4023b7424ecd5d38cc75b650d6c1bf630ef8cb40 ] The expression (*opcode++ << 24) and exp * code_alignment_factor may overflow signed int and becomes negative. Fix this by casting each byte to u64 before shifting. Also fix the misaligned break statement while we are here. Example of the result can be seen here: Link: https://godbolt.org/z/zhY8d3595 It maybe not a real problem, but could be a issue in future. Fixes: d499e9627d70 ("arm64/scs: Fix handling of advance_loc4") Signed-off-by: Wentao Guan Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 793bae6ce71c7265d0e92425b18b2a20c50507e8 Author: Geert Uytterhoeven Date: Tue Apr 21 09:48:32 2026 +0200 drm/color-mgmt: Typo s/R332/RGB332/ [ Upstream commit 9d5a2b8f6281f6090002517fb9272ea07038afe8 ] Fix a typo of "RGB332" in kerneldoc for the drm_crtc_fill_palette_332() helper. Fixes: 7ff61177b7116825 ("drm/color-mgmt: Prepare for RGB332 palettes") Signed-off-by: Geert Uytterhoeven Reviewed-by: Javier Martinez Canillas Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/c413e45c8f752a532a4ff377f7a8b9eaab4a082a.1776757681.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit df332876455c9176d84e3f56b1ed1796f666615c Author: Yuho Choi Date: Sun Apr 19 20:25:13 2026 -0400 drm/sysfb: ofdrm: fix PCI device reference leaks [ Upstream commit 4aa8110000b0d215deef8eed283565dd0c1def88 ] display_get_pci_dev_of() gets a referenced PCI device via pci_get_device(). Drop that reference when pci_enable_device() fails and release it during the managed teardown path after pci_disable_device(). Without that, ofdrm leaks the pci_dev reference on both the error path and the normal cleanup path. Fixes: c8a17756c425 ("drm/ofdrm: Add ofdrm for Open Firmware framebuffers") Co-developed-by: Myeonghun Pak Signed-off-by: Myeonghun Pak Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Co-developed-by: Taegyu Kim Signed-off-by: Taegyu Kim Signed-off-by: Yuho Choi Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260420002513.216-1-dbgh9129@gmail.com Signed-off-by: Sasha Levin commit f4343ddee93becbe549139d26d2d87f3f7cbc760 Author: James Calligeros Date: Sat Apr 25 10:44:05 2026 +1000 ASoC: tas2770: Fix order of operations for temperature calculation [ Upstream commit c7ecb6a61908c2604dda6e42da66724d256de7b9 ] The order of operations to derive the temperature from the temp register values was wrong, since 1000 / 16 is not an integer. This resulted in the calculated temperature value deviating from the value represented by the registers slightly, which was most obvious when the registers were zeroed (-92.265 *C vs the expected -93.000 *C). Scale the reading before dividing the whole thing by 16 to correct this. Fixes: ff73e2780169 ("ASoC: tas2770: expose die temp to hwmon") Signed-off-by: James Calligeros Link: https://patch.msgid.link/20260425-tas27xx-hwmon-fixes-v1-3-83c13b8e8f54@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6c06e9ba8753d0b9c0748fe919d237b367a5cbe1 Author: James Calligeros Date: Sat Apr 25 10:44:03 2026 +1000 ASoC: tas2764: Mark die temp register as volatile [ Upstream commit 4cfb5971c2fbfac061c23fb4224a3a008199de81 ] Reading the temperature register always returns the first value read from the chip due to regcache. Mark TAS2764_TEMP as volatile to prevent returning stale, cached values when reading the die temp. Fixes: 186dfc85f9a8 ("ASoC: tas2764: expose die temp to hwmon") Signed-off-by: James Calligeros Link: https://patch.msgid.link/20260425-tas27xx-hwmon-fixes-v1-1-83c13b8e8f54@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9834d8cc89feb6f8e39bb7c3247e03251fc44e59 Author: John Madieu Date: Sat Apr 25 09:29:34 2026 +0000 spi: rockchip: Read ISR, not IMR, to detect cs-inactive IRQ [ Upstream commit b4683a239a409d65f88052f5630c748a8ba070cd ] rockchip_spi_isr() decides whether the current interrupt was the cs-inactive event by reading IMR: if (rs->cs_inactive && readl_relaxed(rs->regs + ROCKCHIP_SPI_IMR) & INT_CS_INACTIVE) ctlr->target_abort(ctlr); IMR is the interrupt mask register: it tells which sources are enabled, not which one fired. In the PIO path, rockchip_spi_prepare_irq() enables both INT_RF_FULL and INT_CS_INACTIVE in IMR when rs->cs_inactive is true: if (rs->cs_inactive) writel_relaxed(INT_RF_FULL | INT_CS_INACTIVE, rs->regs + ROCKCHIP_SPI_IMR); so the IMR check is always true once cs_inactive is enabled, and every PIO interrupt - including normal RF_FULL completions - is dispatched to ctlr->target_abort(), aborting the transfer. The bug is reachable on ROCKCHIP_SPI_VER2_TYPE2 in target mode with a DMA-capable controller when the transfer is short enough to fall back to PIO (rockchip_spi_can_dma() returns false below fifo_len). Read ISR (which is RISR masked by IMR) so the check actually reflects which interrupt fired, and parenthesise the expression for clarity while at it. Fixes: 869f2c94db92 ("spi: rockchip: Stop spi slave dma receiver when cs inactive") Signed-off-by: John Madieu Link: https://patch.msgid.link/20260425092936.2590132-2-john.madieu@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6c554462a6add299de557e74bd3112f52c56c7aa Author: Guilherme G. Piccoli Date: Thu Apr 23 15:30:58 2026 -0300 ASoC: amd: acp: Add DMI quirk for Valve Steam Deck OLED [ Upstream commit b0f6f4ac7d5d04fe2adcdd63ed1cd1ad505b8958 ] Commit 671dd2ffbd8b ("ASoC: amd: acp: Add new cpu dai and dailink creation for I2S BT instance") introduced a change that "broke" Steam Deck's audio probe, in the OLED model, as observed in the following dmesg snippet: [...] snd_sof_amd_vangogh 0000:04:00.5: Topology: ABI 3:26:0 Kernel ABI 3:23:1 sof_mach nau8821-max: ASoC: physical link acp-bt-codec (id 2) not exist sof_mach nau8821-max: ASoC: topology: could not load header: -22 snd_sof_amd_vangogh 0000:04:00.5: tplg amd/sof-tplg/sof-vangogh-nau8821-max.tplg component load failed -22 snd_sof_amd_vangogh 0000:04:00.5: error: failed to load DSP topology -22 snd_sof_amd_vangogh 0000:04:00.5: ASoC error (-22): at snd_soc_component_probe() on 0000:04:00.5 sof_mach nau8821-max: ASoC: failed to instantiate card -22 sof_mach nau8821-max: error -EINVAL: Failed to register card(sof-nau8821-max) sof_mach nau8821-max: probe with driver sof_mach failed with error -22 [...] Notice the quotes in "broke": it's not really a bug in such commit, but instead a problem with a topology file from Steam Deck OLED. This was discussed to great extent in [1], and Cristian proposed a pretty simple and functional change that resolved the issue for the Deck's issue. That change, though, would break other devices, so it wasn't accepted upstream. And the proper suggested solution (fix the topology) was never implemented, so Valve's kernel (and anyone that wants to boot the mainline on Steam Deck OLED) is carrying that fix downstream. So, we propose hereby a different approach: a DMI quirk, as many already present in the sound drivers, to address this issue solely on Steam Deck OLED, not breaking other devices and as a bonus, allowing simple patch up in case eventually the topology file gets fixed (we'd just need to check against any DMI info reflecting that or the topology/FW versions). The motivation of such upstream quirk is related to users that want to test latest kernel trees on their devices and get no only non-working sound device, but seems some games (like Ori and the Blind Forest) can't properly work without a proper functional audio device. Example of such report can be seen at [2]. Cc: Mark Brown Cc: Robert Beckett Cc: Umang Jain Fixes: 671dd2ffbd8b ("ASoC: amd: acp: Add new cpu dai and dailink creation for I2S BT instance") Link: https://lore.kernel.org/r/20231209205351.880797-11-cristian.ciocaltea@collabora.com/ [1] Link: https://bugzilla.kernel.org/show_bug.cgi?id=218677 [2] Reviewed-by: Cristian Ciocaltea Reviewed-by: Mario Limonciello Tested-by: Melissa Wen Signed-off-by: Guilherme G. Piccoli Link: https://patch.msgid.link/20260423183505.116445-1-gpiccoli@igalia.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7df9863bf538a626e8a684e59cb2c43eac0ef3c8 Author: Florian Westphal Date: Thu Apr 23 02:19:11 2026 +0200 netfilter: nf_conntrack_sip: don't use simple_strtoul [ Upstream commit 8cf6809cddcbe301aedfc6b51bcd4944d45795f6 ] Replace unsafe port parsing in epaddr_len(), ct_sip_parse_header_uri(), and ct_sip_parse_request() with a new sip_parse_port() helper that validates each digit against the buffer limit, eliminating the use of simple_strtoul() which assumes NUL-terminated strings. The previous code dereferenced pointers without bounds checks after sip_parse_addr() and relied on simple_strtoul() on non-NUL-terminated skb data. A port that reaches the buffer limit without a trailing character is also rejected as malformed. Also get rid of all simple_strtoul() usage in conntrack, prefer a stricter version instead. There are intentional changes: - Bail out if number is > UINT_MAX and indicate a failure, same for too long sequences. While we do accept 05535 as port 5535, we will not accept e.g. 'sip:10.0.0.1:005060'. While its syntactically valid under RFC 3261, we should restrict this to not waste cycles when presented with malformed packets with 64k '0' characters. - Force base 10 in ct_sip_parse_numerical_param(). This is used to fetch 'expire=' and 'rports='; both are expected to use base-10. - In nf_nat_sip.c, only accept the parsed value if its within the 1k-64k range. - epaddr_len now returns 0 if the port is invalid, as it already does for invalid ip addresses. This is intentional. nf_conntrack_sip performs lots of guesswork to find the right parts of the message to parse. Being stricter could break existing setups. Connection tracking helpers are designed to allow traffic to pass, not to block it. Based on an earlier patch from Jenny Guanni Qu . Fixes: 05e3ced297fe ("[NETFILTER]: nf_conntrack_sip: introduce SIP-URI parsing helper") Reported-by: Klaudia Kloc Reported-by: Dawid Moczadło Reported-by: Jenny Guanni Qu . Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 938867e870fb5471bb16f442aeac81326e05bf65 Author: Jiexun Wang Date: Fri Apr 17 20:25:06 2026 +0800 netfilter: xt_policy: fix strict mode inbound policy matching [ Upstream commit 4b2b4d7d4e203c92db8966b163edfacb1f0e1e29 ] match_policy_in() walks sec_path entries from the last transform to the first one, but strict policy matching needs to consume info->pol[] in the same forward order as the rule layout. Derive the strict-match policy position from the number of transforms already consumed so that multi-element inbound rules are matched consistently. Fixes: c4b885139203 ("[NETFILTER]: x_tables: replace IPv4/IPv6 policy match by address family independant version") Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Jiexun Wang Signed-off-by: Ren Wei Acked-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit e0805ccf7917ddbab09700b296d6d9a40d445c8a Author: Timur Kristóf Date: Sat Apr 18 23:49:33 2026 +0200 drm/amdgpu/gfx6: Support harvested SI chips with disabled TCCs (v2) [ Upstream commit fe2b84f9228e2a0903221a4d0d8c350b018e9c0c ] This commit fixes amdgpu to work on the Radeon HD 7870 XT which has never worked with the Linux open source drivers before. Some boards have "harvested" chips, meaning that some parts of the chip are disabled and fused, and it's sold for cheaper and under a different marketing name. On a harvested chip, any of the following can be disabled: - CUs (Compute Units) - RBs (Render Backend, aka. ROP) - Memory channels (ie. the chip has a lower bandwidth) - TCCs (ie. less L2 cache) Handle chips with harvested TCCs by patching the registers that configure how TCCs are mapped. If some TCCs are disabled, we need to make sure that the disabled TCCs are not used, and the remaining TCCs are used optimally. TCP_CHAN_STEER_LO/HI control which TCC is used by TCP channels. TCP_ADDR_CONFIG.NUM_TCC_BANKS controls how many channels are used. Note that the TCC configuration is highly relevant to performance. Suboptimal configuration (eg. CHAN_STEER=0) can significantly reduce gaming performance. For optimal performance: - Rely on the CHAN_STEER from the golden registers table, only skip disabled TCCs but keep the mapping order. - Limit NUM_TCC_BANKS to number of active TCCs to avoid thrashing, which performs better than using the same TCC twice. v2: - Also consider CGTS_USER_TCC_DISABLE for disabled TCCs. Link: https://bugs.freedesktop.org/show_bug.cgi?id=60879 Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/2664 Fixes: 2cd46ad22383 ("drm/amdgpu: add graphic pipeline implementation for si v8") Signed-off-by: Timur Kristóf Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 00218d15528fab9f6b31241fe5904eea4fcaa30d) Signed-off-by: Sasha Levin commit 6d6cd5652c869ba1bb676c8631f108a699a2992c Author: Timur Kristóf Date: Sat Apr 18 23:49:31 2026 +0200 drm/amdgpu/uvd3.1: Don't validate the firmware when already validated [ Upstream commit 13e4cf116dbf7a1fb8123a59bea2c098f30d3736 ] UVD 3.1 firmware validation seems to always fail after attempting it when it had already been validated. (This works similarly with the VCE 1.0 as well.) Don't attempt repeating the validation when it's already done. This caused issues in situations when the system isn't able to suspend the GPU properly and so the GPU isn't actually powered down. Then amdgpu would fail when calling the IP block resume function. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/2887 Fixes: bb7978111dd3 ("drm/amdgpu: fix SI UVD firmware validate resume fail") Signed-off-by: Timur Kristóf Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 889a2cfd889c4a4dd9d0c89ce9a8e60b78be71dd) Signed-off-by: Sasha Levin commit a31c3feb54b15a90232e497ad0e27e8a82052d8d Author: Christian König Date: Fri Apr 17 15:52:45 2026 +0200 drm/amdgpu: fix AMDGPU_INFO_READ_MMR_REG [ Upstream commit 0ef196a208385b7d7da79f411c161b04e97283e2 ] There were multiple issues in that code. First of all the order between the reset semaphore and the mm_lock was wrong (e.g. copy_to_user) was called while holding the lock. Then we allocated memory while holding the reset semaphore which is also a pretty big bug and can deadlock. Then we used down_read_trylock() instead of waiting for the reset to finish. Signed-off-by: Christian König Fixes: 9e823f307074 ("drm/amdgpu: Block MMR_READ IOCTL in reset") Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 361b6e6b303d4b691f6c5974d3eaab67ca6dd90e) Signed-off-by: Sasha Levin commit 24c55a9aa2982c74f1b4e6c77b2362c507270555 Author: Timur Kristóf Date: Sat Apr 18 23:49:30 2026 +0200 drm/amdgpu/gmc: Fix AMDGPU_GART_PLACEMENT_LOW to not overlap with VRAM [ Upstream commit 36d65da7570bf72ce28504fa9a81abfc728e6d96 ] When the GART placement is set to AMDGPU_GART_PLACEMENT_LOW: Make sure that GART does not overlap with VRAM when VRAM is configured to be in the low address space. Solve this according to the following logic: - When GART fits before VRAM, use zero address for GART - Otherwise, put GART after the end of VRAM, aligned to 4 GiB Previously, I had assumed this was not possible so it was OK to not handle it, but now we got a report from a user who has a board that is configured this way. Fixes: 917f91d8d8e8 ("drm/amdgpu/gmc: add a way to force a particular placement for GART") Signed-off-by: Timur Kristóf Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 3d9de5d86a1658cadb311461b001eb1df67263ad) Signed-off-by: Sasha Levin commit 616af8df424c0a9dcd1064875a2f153fffe1f74a Author: Keith Busch Date: Tue Apr 21 09:14:02 2026 -0700 nvme-pci: fix missed admin queue sq doorbell write [ Upstream commit 1cc4cdae2a3b7730d462d69e30f213fd2efe7807 ] We can batch admin commands submitted through io_uring_cmd passthrough, which means bd->last may be false and skips the doorbell write to aggregate multiple commands per write. If a subsequent command can't be dispatched for whatever reason, we have to provide the blk-mq ops' commit_rqs callback in order to ensure we properly update the doorbell. Fixes: 58e5bdeb9c2b ("nvme: enable uring-passthrough for admin commands") Reviewed-by: Christoph Hellwig Reviewed-by: Kanchan Joshi Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 0bd93ce4f3c35e845532184331d7917d7e562c80 Author: Florian Westphal Date: Thu Apr 16 15:14:51 2026 +0200 netfilter: nf_tables: use list_del_rcu for netlink hooks [ Upstream commit f3224ee463f8f6f6ced7dcdf6081add4f8128527 ] nft_netdev_unregister_hooks and __nft_unregister_flowtable_net_hooks need to use list_del_rcu(), this list can be walked by concurrent dumpers. Add a new helper and use it consistently. Fixes: f9a43007d3f7 ("netfilter: nf_tables: double hook unregistration in netns path") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 1c55053f8ffdc060006df898fd3664e3d1bfac7b Author: Pablo Neira Ayuso Date: Mon Apr 20 23:15:32 2026 +0200 netfilter: arp_tables: fix IEEE1394 ARP payload parsing [ Upstream commit 1e8e3f449b1e73b73a843257635b9c50f0cc0f0a ] Weiming Shi says: "arp_packet_match() unconditionally parses the ARP payload assuming two hardware addresses are present (source and target). However, IPv4-over-IEEE1394 ARP (RFC 2734) omits the target hardware address field, and arp_hdr_len() already accounts for this by returning a shorter length for ARPHRD_IEEE1394 devices. As a result, on IEEE1394 interfaces arp_packet_match() advances past a nonexistent target hardware address and reads the wrong bytes for both the target device address comparison and the target IP address. This causes arptables rules to match against garbage data, leading to incorrect filtering decisions: packets that should be accepted may be dropped and vice versa. The ARP stack in net/ipv4/arp.c (arp_create and arp_process) already handles this correctly by skipping the target hardware address for ARPHRD_IEEE1394. Apply the same pattern to arp_packet_match()." Mangle the original patch to always return 0 (no match) in case user matches on the target hardware address which is never present in IEEE1394. Note that this returns 0 (no match) for either normal and inverse match because matching in the target hardware address in ARPHRD_IEEE1394 has never been supported by arptables. This is intentional, matching on the target hardware address should never evaluate true for ARPHRD_IEEE1394. Moreover, adjust arpt_mangle to drop the packet too as AI suggests: In arpt_mangle, the logic assumes a standard ARP layout. Because IEEE1394 (FireWire) omits the target hardware address, the linear pointer arithmetic miscalculates the offset for the target IP address. This causes mangling operations to write to the wrong location, leading to packet corruption. To ensure safety, this patch drops packets (NF_DROP) when mangling is requested for these fields on IEEE1394 devices, as the current implementation cannot correctly map the FireWire ARP payload. This omits both mangling target hardware and IP address. Even if IP address mangling should be possible in IEEE1394, this would require to adjust arpt_mangle offset calculation, which has never been supported. Based on patch from Weiming Shi . Fixes: 6752c8db8e0c ("firewire net, ipv4 arp: Extend hardware address and remove driver-level packet inspection.") Reported-by: Xiang Mei Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit c2a11441538bdbbc5aa003f190995eba93a89b88 Author: Maurizio Lombardi Date: Mon Mar 16 15:39:35 2026 +0100 nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers [ Upstream commit ea8e356acb165cb1fd75537a52e1f66e5e76c538 ] Currently, when nvmet_tcp_build_pdu_iovec() detects an out-of-bounds PDU length or offset, it triggers nvmet_tcp_fatal_error(cmd->queue) and returns early. However, because the function returns void, the callers are entirely unaware that a fatal error has occurred and that the cmd->recv_msg.msg_iter was left uninitialized. Callers such as nvmet_tcp_handle_h2c_data_pdu() proceed to blindly overwrite the queue state with queue->rcv_state = NVMET_TCP_RECV_DATA Consequently, the socket receiving loop may attempt to read incoming network data into the uninitialized iterator. Fix this by shifting the error handling responsibility to the callers. Fixes: 52a0a9854934 ("nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec") Reviewed-by: Hannes Reinecke Reviewed-by: Yunje Shin Reviewed-by: Chaitanya Kulkarni Signed-off-by: Maurizio Lombardi Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 119e84719f983b8aaf76e2893849ea8f4733da78 Author: Breno Leitao Date: Mon Apr 20 06:25:09 2026 -0700 tracing: branch: Fix inverted check on stat tracer registration [ Upstream commit 3b75dd76e64a04771861bb5647951c264919e563 ] init_annotated_branch_stats() and all_annotated_branch_stats() check the return value of register_stat_tracer() with "if (!ret)", but register_stat_tracer() returns 0 on success and a negative errno on failure. The inverted check causes the warning to be printed on every successful registration, e.g.: Warning: could not register annotated branches stats while leaving real failures silent. The initcall also returned a hard-coded 1 instead of the actual error. Invert the check and propagate ret so that the warning fires on real errors and the initcall reports the correct status. Cc: Mathieu Desnoyers Cc: Ingo Molnar Cc: Frederic Weisbecker Link: https://patch.msgid.link/20260420-tracing-v1-1-d8f4cd0d6af1@debian.org Fixes: 002bb86d8d42 ("tracing/ftrace: separate events tracing and stats tracing engine") Signed-off-by: Breno Leitao Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 1aa08e1fd60ab92a241992f322991ea2e01319ff Author: Petr Malat Date: Thu Apr 23 04:48:26 2026 -0500 cgroup: Increment nr_dying_subsys_* from rmdir context [ Upstream commit 13e786b64bd3fd81c7eb22aa32bf8305c32f2ccf ] Incrementing nr_dying_subsys_* in offline_css(), which is executed by cgroup_offline_wq worker, leads to a race where user can see the value to be 0 if he reads cgroup.stat after calling rmdir and before the worker executes. This makes the user wrongly expect resources released by the removed cgroup to be available for a new assignment. Increment nr_dying_subsys_* from kill_css(), which is called from the cgroup_rmdir() context. Fixes: ab0312526867 ("cgroup: Show # of subsystem CSSes in cgroup.stat") Signed-off-by: Petr Malat Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 64a5a3dfa8fd86511657799a30ab2f84bdd83fb0 Author: Mark Harmstone Date: Thu Apr 16 18:15:23 2026 +0100 btrfs: fix double-decrement of bytes_may_use in submit_one_async_extent() [ Upstream commit 82323b1a7088b7a5c3e528a5d634bff447fa286f ] submit_one_async_extent() calls btrfs_reserve_extent(), which decrements bytes_may_use. If the call btrfs_create_io_em() fails, we jump to out_free_reserve, which calls extent_clear_unlock_delalloc(). Because we're specifying EXTENT_DO_ACCOUNTING, i.e. EXTENT_CLEAR_META_RESV | EXTENT_CLEAR_DATA_RESV, this decreases bytes_may_use again. This can lead to problems later on, as an initial write can fail only for the writeback to silently ENOSPC. Fix this by replacing EXTENT_DO_ACCOUNTING with EXTENT_CLEAR_META_RESV. This parallels a4fe134fc1d8eb ("btrfs: fix a double release on reserved extents in cow_one_range()"), which is the same fix in cow_one_range(). Fixes: 151a41bc46df ("Btrfs: fix what bits we clear when erroring out from delalloc") Reviewed-by: Qu Wenruo Signed-off-by: Mark Harmstone Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit b740cc86816bbc87902ae9db74cd21abde3c8d63 Author: Amir Goldstein Date: Mon Apr 20 14:58:00 2026 +0200 fsnotify: fix inode reference leak in fsnotify_recalc_mask() [ Upstream commit 4aca914ac152f5d055ddcb36704d1e539ac08977 ] fsnotify_recalc_mask() fails to handle the return value of __fsnotify_recalc_mask(), which may return an inode pointer that needs to be released via fsnotify_drop_object() when the connector's HAS_IREF flag transitions from set to cleared. This manifests as a hung task with the following call trace: INFO: task umount:1234 blocked for more than 120 seconds. Call Trace: __schedule schedule fsnotify_sb_delete generic_shutdown_super kill_anon_super cleanup_mnt task_work_run do_exit do_group_exit The race window that triggers the iref leak: Thread A (adding mark) Thread B (removing mark) ────────────────────── ──────────────────────── fsnotify_add_mark_locked(): fsnotify_add_mark_list(): spin_lock(conn->lock) add mark_B(evictable) to list spin_unlock(conn->lock) return /* ---- gap: no lock held ---- */ fsnotify_detach_mark(mark_A): spin_lock(mark_A->lock) clear ATTACHED flag on mark_A spin_unlock(mark_A->lock) fsnotify_put_mark(mark_A) fsnotify_recalc_mask(): spin_lock(conn->lock) __fsnotify_recalc_mask(): /* mark_A skipped: ATTACHED cleared */ /* only mark_B(evictable) remains */ want_iref = false has_iref = true /* not yet cleared */ -> HAS_IREF transitions true -> false -> returns inode pointer spin_unlock(conn->lock) /* BUG: return value discarded! * iput() and fsnotify_put_sb_watched_objects() * are never called */ Fix this by deferring the transition true -> false of HAS_IREF flag from fsnotify_recalc_mask() (Thread A) to fsnotify_put_mark() (thread B). Fixes: c3638b5b1374 ("fsnotify: allow adding an inode mark without pinning inode") Signed-off-by: Xin Yin Signed-off-by: Amir Goldstein Link: https://patch.msgid.link/CAOQ4uxiPsbHb0o5voUKyPFMvBsDkG914FYDcs4C5UpBMNm0Vcg@mail.gmail.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit f7f5d83b0dc2f9edd03f2bd47c296aa61f220caf Author: Wolfram Sang Date: Fri Apr 17 09:42:36 2026 +0200 mailbox: mailbox-test: make data_ready a per-instance variable [ Upstream commit 6e937f4e769e60947909e3525965f0137b9039e8 ] While not the default case, multiple tests can be run simultaneously. Then, data_ready being a global variable will be overwritten and the per-instance lock will not help. Turn the global variable into a per-instance one to avoid this problem. Fixes: e339c80af95e ("mailbox: mailbox-test: don't rely on rx_buffer content to signal data ready") Signed-off-by: Wolfram Sang Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 3c791f6fb791f687f3cebf80e661af8d5d12cf5c Author: Wolfram Sang Date: Fri Apr 17 09:42:35 2026 +0200 mailbox: mailbox-test: initialize struct earlier [ Upstream commit bbcf9af68bfedb3d9cc3c7eae62f5c844d8b78b9 ] The waitqueue must be initialized before the debugfs files are created because from that time, requests from userspace can already be made. Similarily, drvdata and spinlock needs to be initialized before we request the channel, otherwise dangling irqs might run into problems like a NULL pointer exception. Fixes: 8ea4484d0c2b ("mailbox: Add generic mechanism for testing Mailbox Controllers") Signed-off-by: Wolfram Sang Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 82f6dcea46cf5de65c4ba7283f7c7b34de4a324d Author: Wolfram Sang Date: Fri Apr 17 09:42:34 2026 +0200 mailbox: mailbox-test: don't free the reused channel [ Upstream commit 88ebadbf0deefdaccdab868b44ff70a0a257f473 ] The RX channel can be aliased to the TX channel if it has a different MMIO. This special case needs to be handled when freeing the channels otherwise a double-free occurs. Fixes: 8ea4484d0c2b ("mailbox: Add generic mechanism for testing Mailbox Controllers") Signed-off-by: Wolfram Sang Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 9dd7489943324298bb0f385495795a82f1dd6507 Author: Wolfram Sang Date: Mon Apr 13 12:42:38 2026 +0200 mailbox: add sanity check for channel array [ Upstream commit c1aad75595fb67edc7fda8af249d3b886efa1be9 ] Fail gracefully if there is no channel array attached to the mailbox controller. Otherwise the later dereference will cause an OOPS which might not be seen because mailbox controllers might instantiate very early. Remove the comment explaining the obvious while here. Fixes: 2b6d83e2b8b7 ("mailbox: Introduce framework for mailbox") Signed-off-by: Wolfram Sang Reviewed-by: Geert Uytterhoeven Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 8d5e39df95ed07233e0c72a00ef17eea27faab1a Author: cuitao Date: Tue Apr 14 09:53:27 2026 +0800 cgroup/rdma: fix integer overflow in rdmacg_try_charge() [ Upstream commit c802f460dd485c1332b5a35e7adcfb2bc22536a2 ] The expression `rpool->resources[index].usage + 1` is computed in int arithmetic before being assigned to s64 variable `new`. When usage equals INT_MAX (the default "max" value), the addition overflows to INT_MIN. This negative value then passes the `new > max` check incorrectly, allowing a charge that should be rejected and corrupting usage to negative. Fix by casting usage to s64 before the addition so the arithmetic is done in 64-bit. Fixes: 39d3e7584a68 ("rdmacg: Added rdma cgroup controller") Signed-off-by: cuitao Reviewed-by: Michal Koutný Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 03dc070fa0fc3cb4068693f468ccd5f8a7e58282 Author: Edward Adam Davis Date: Tue Apr 14 14:15:43 2026 +0800 sched/psi: fix race between file release and pressure write [ Upstream commit a5b98009f16d8a5fb4a8ff9a193f5735515c38fa ] A potential race condition exists between pressure write and cgroup file release regarding the priv member of struct kernfs_open_file, which triggers the uaf reported in [1]. Consider the following scenario involving execution on two separate CPUs: CPU0 CPU1 ==== ==== vfs_rmdir() kernfs_iop_rmdir() cgroup_rmdir() cgroup_kn_lock_live() cgroup_destroy_locked() cgroup_addrm_files() cgroup_rm_file() kernfs_remove_by_name() kernfs_remove_by_name_ns() vfs_write() __kernfs_remove() new_sync_write() kernfs_drain() kernfs_fop_write_iter() kernfs_drain_open_files() cgroup_file_write() kernfs_release_file() pressure_write() cgroup_file_release() ctx = of->priv; kfree(ctx); of->priv = NULL; cgroup_kn_unlock() cgroup_kn_lock_live() cgroup_get(cgrp) cgroup_kn_unlock() if (ctx->psi.trigger) // here, trigger uaf for ctx, that is of->priv The cgroup_rmdir() is protected by the cgroup_mutex, it also safeguards the memory deallocation of of->priv performed within cgroup_file_release(). However, the operations involving of->priv executed within pressure_write() are not entirely covered by the protection of cgroup_mutex. Consequently, if the code in pressure_write(), specifically the section handling the ctx variable executes after cgroup_file_release() has completed, a uaf vulnerability involving of->priv is triggered. Therefore, the issue can be resolved by extending the scope of the cgroup_mutex lock within pressure_write() to encompass all code paths involving of->priv, thereby properly synchronizing the race condition occurring between cgroup_file_release() and pressure_write(). And, if an live kn lock can be successfully acquired while executing the pressure write operation, it indicates that the cgroup deletion process has not yet reached its final stage; consequently, the priv pointer within open_file cannot be NULL. Therefore, the operation to retrieve the ctx value must be moved to a point *after* the live kn lock has been successfully acquired. In another situation, specifically after entering cgroup_kn_lock_live() but before acquiring cgroup_mutex, there exists a different class of race condition: CPU0: write memory.pressure CPU1: write cgroup.pressure=0 =========================== ============================= kernfs_fop_write_iter() kernfs_get_active_of(of) pressure_write() cgroup_kn_lock_live(memory.pressure) cgroup_tryget(cgrp) kernfs_break_active_protection(kn) ... blocks on cgroup_mutex cgroup_pressure_write() cgroup_kn_lock_live(cgroup.pressure) cgroup_file_show(memory.pressure, false) kernfs_show(false) kernfs_drain_open_files() cgroup_file_release(of) kfree(ctx) of->priv = NULL cgroup_kn_unlock() ... acquires cgroup_mutex ctx = of->priv; // may now be NULL if (ctx->psi.trigger) // NULL dereference Consequently, there is a possibility that of->priv is NULL, the pressure write needs to check for this. Now that the scope of the cgroup_mutex has been expanded, the original explicit cgroup_get/put operations are no longer necessary, this is because acquiring/releasing the live kn lock inherently executes a cgroup get/put operation. [1] BUG: KASAN: slab-use-after-free in pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011 Call Trace: pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011 cgroup_file_write+0x36f/0x790 kernel/cgroup/cgroup.c:4311 kernfs_fop_write_iter+0x3b0/0x540 fs/kernfs/file.c:352 Allocated by task 9352: cgroup_file_open+0x90/0x3a0 kernel/cgroup/cgroup.c:4256 kernfs_fop_open+0x9eb/0xcb0 fs/kernfs/file.c:724 do_dentry_open+0x83d/0x13e0 fs/open.c:949 Freed by task 9353: cgroup_file_release+0xd6/0x100 kernel/cgroup/cgroup.c:4283 kernfs_release_file fs/kernfs/file.c:764 [inline] kernfs_drain_open_files+0x392/0x720 fs/kernfs/file.c:834 kernfs_drain+0x470/0x600 fs/kernfs/dir.c:525 Fixes: 0e94682b73bf ("psi: introduce psi monitor") Reported-by: syzbot+33e571025d88efd1312c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=33e571025d88efd1312c Tested-by: syzbot+33e571025d88efd1312c@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Reviewed-by: Chen Ridong Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 742001919653e7313b4e91780c5d108be1692365 Author: Wolfram Sang Date: Fri Apr 10 14:53:00 2026 +0200 mailbox: mailbox-test: free channels on probe error [ Upstream commit c02053a9055d5fdfd32432287cca8958db1d5bc5 ] On probe error, free the previously obtained channels. This not only prevents a leak, but also UAF scenarios because the client structure will be removed nonetheless because it was allocated with devm. Link: https://sashiko.dev/#/patchset/20260327151217.5327-2-wsa%2Brenesas%40sang-engineering.com Fixes: 8ea4484d0c2b ("mailbox: Add generic mechanism for testing Mailbox Controllers") Signed-off-by: Wolfram Sang Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit d3da3c85cdd6a76787a43990c9977b2538af3c31 Author: Jason-JH Lin Date: Mon Mar 23 17:07:11 2026 +0800 mailbox: mtk-cmdq: Fix CURR and END addr for task insert case [ Upstream commit d2591db9c8ef19fbb4d24ed15e0c6edfa6bc7917 ] Fix CURR and END address calculation for inserting a cmdq task into the task list by using cmdq_reg_shift_addr() for proper address converting. This ensures both CURR and END addresses are set correctly when enabling the thread. Fixes: a195c7ccfb7a ("mailbox: mtk-cmdq: Refine DMA address handling for the command buffer") Signed-off-by: Jason-JH Lin Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit d07bc4ce8e24fa3a88c07137f79488d539589f8a Author: Thomas Weißschuh Date: Wed Apr 22 17:10:27 2026 +0200 kbuild: Never respect CONFIG_WERROR / W=e to fixdep [ Upstream commit 75f7c47ccd78c947cf1b6ddb18ea453ff0555716 ] The fixdep hostprog may be built multiple times during a single build. Once during the configuration phase and later during the regular phase. As only the regular build phase respects CONFIG_WERROR / W=e, the compiler flags might change between the phases, leading to rebuilds. Example, the rebuilds will happen twice on each invocation of the build: $ make allyesconfig prepare make[1]: Entering directory '/tmp/deleteme' HOSTCC scripts/basic/fixdep # # No change to .config # HOSTCC scripts/basic/fixdep DESCEND objtool INSTALL libsubcmd_headers make[1]: Leaving directory '/tmp/deleteme' Fix the compilation flags used for scripts/basic/ before scripts/Makefile.warn is evaluated to stop CONFIG_WERROR / W=e influencing the fixdep build to avoid the spurious rebuilds. Fixes: 7ded7d37e5f5 ("scripts/Makefile.extrawarn: Respect CONFIG_WERROR / W=e for hostprogs") Signed-off-by: Thomas Weißschuh Reviewed-by: Nathan Chancellor Link: https://patch.msgid.link/20260422-kbuild-scripts-basic-werror-v1-1-8c6912ff22e0@weissschuh.net Signed-off-by: Nicolas Schier Signed-off-by: Sasha Levin commit 4d837117d45dea05e63e8606e434cd921aebea27 Author: David Arcari Date: Tue Apr 21 10:32:17 2026 -0400 tools/power turbostat: Fix unrecognized option '-P' [ Upstream commit ce012c966b518c53475ba9a4e979242d7322d819 ] The '-P' short option (shorthand for --no-perf) is not present in the optstring of the second call to getopt_long_only(). This results in the "unrecognized option" error when the tool reaches the main parsing loop. Add 'P' to the second getopt_long_only() call to ensure it is consistently recognized. Fixes: a0e86c90b83c ("tools/power turbostat: Add --no-perf option") Signed-off-by: David Arcari Signed-off-by: Len Brown Signed-off-by: Sasha Levin commit 262187aa6981dfd4af907f4458ade55bddb97527 Author: Len Brown Date: Fri Feb 13 13:26:12 2026 -0600 tools/power turbostat: Fix and document --header_iterations [ Upstream commit 96718ad296af4a6d984b3a09276b165ab6a3b0c8 ] The "header_iterations" option is commonly used to de-clutter the screen of redundant header label rows in an interactive session: Eg. every 10 rows: $ sudo turbostat --header_iterations 10 -S -q -i 1 But --header_iterations was missing from turbostat.8 Also turbostat help advertised the "-N" short option that did not actually work: $ turbostat --help -N, --header_iterations num print header every num iterations Repair "-N" Document "--header_iterations" on turbostat.8 Signed-off-by: Len Brown Stable-dep-of: ce012c966b51 ("tools/power turbostat: Fix unrecognized option '-P'") Signed-off-by: Sasha Levin commit 481dbda367f460c298e7ff8ce3c5a20b6a4917fc Author: Kaushlendra Kumar Date: Mon Dec 8 08:38:04 2025 +0530 tools/power turbostat: Use strtoul() for iteration parsing [ Upstream commit 8e5c0cc326f2e95a71bb6e6063e65caa60c8f951 ] Replace strtod() with strtoul() and check errno for -n/-N options, since num_iterations and header_iterations are unsigned long counters. Reject zero and conversion errors; negative inputs wrap to large positive values per standard unsigned semantics. Signed-off-by: Kaushlendra Kumar Signed-off-by: Len Brown Stable-dep-of: ce012c966b51 ("tools/power turbostat: Fix unrecognized option '-P'") Signed-off-by: Sasha Levin commit 8adeeef75597ec7bb8b6e13bebe161f3a5cb6020 Author: Len Brown Date: Wed Dec 10 13:33:29 2025 -0500 tools/power turbostat.8: Document the "--force" option [ Upstream commit 785953cf6e63aa5a9fcdfa9577b1411e0281c4bc ] Starting in turbostat v2025.01.14, turbostat refused to run on unsupported hardware, pointing to "RUN THE LATEST VERSION" on turbostat(8). At that time, turbostat supported and advertised the "--force" parameter to run anyway (with unsupported results). Also document "--force" on turbostat.8. Signed-off-by: Len Brown Stable-dep-of: ce012c966b51 ("tools/power turbostat: Fix unrecognized option '-P'") Signed-off-by: Sasha Levin commit c7a9cde132bfd7204c228214d24952ed833162aa Author: Yuho Choi Date: Sun Apr 19 21:01:18 2026 -0400 fbdev: offb: fix PCI device reference leak on probe failure [ Upstream commit 869b93ba04088713596e68453c1146f52f713290 ] offb_init_nodriver() gets a referenced PCI device with pci_get_device(). If pci_enable_device() fails, the function returns without dropping that reference. Release the PCI device reference before returning from the pci_enable_device() failure path. Fixes: 5bda8f7b5468 ("video: fbdev: offb: Call pci_enable_device() before using the PCI VGA device") Co-developed-by: Myeonghun Pak Signed-off-by: Myeonghun Pak Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Co-developed-by: Taegyu Kim Signed-off-by: Taegyu Kim Signed-off-by: Yuho Choi Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 4b238fb04bd2dda8442b015ffc153f14877a5793 Author: Mathias Krause Date: Thu Apr 2 16:51:16 2026 +0200 kbuild: builddeb - avoid recompiles for non-cross-compiles [ Upstream commit 2452dcf4d740effff5aa71b7f6529ee8c04fd8f6 ] Commit e2c318225ac1 ("kbuild: deb-pkg: add pkg.linux-upstream.nokernelheaders build profile") changed how install-extmod-build gets called, making it always rebuild the host programs below scripts/ if HOSTCC wasn't specified with its full triplet on the make command line. That is, apparently, needed to fix up commit f1d87664b82a ("kbuild: cross-compile linux-headers package when possible") for cross-compiles. However, in the much more common case of non-cross-compile builds this will lead to unnecessary rebuilding of host tools including gcc plugins. This, in turn, will lead to a full kernel rebuild on the next 'make bindeb-pkg' which is unfortunate. Avoid that by only triggering the rebuild of host tools for actual cross-compile builds. Signed-off-by: Mathias Krause Fixes: e2c318225ac1 ("kbuild: deb-pkg: add pkg.linux-upstream.nokernelheaders build profile") Cc: Masahiro Yamada Reviewed-by: Nathan Chancellor Reviewed-by: Nicolas Schier Link: https://patch.msgid.link/20260402145116.1010901-1-minipli@grsecurity.net Signed-off-by: Nicolas Schier Signed-off-by: Sasha Levin commit 03a8177556117aa3b0bac5c49a794bbd5863470b Author: Anthony Pighin (Nokia) Date: Tue Nov 25 18:00:10 2025 +0000 rtc: abx80x: Disable alarm feature if no interrupt attached [ Upstream commit 0fedce7244e4b85c049ce579c87e298a1b0b811d ] Commit 795cda8338ea ("rtc: interface: Fix long-standing race when setting alarm") exposed an issue where the rtc-abx80x driver does not clear the alarm feature bit, but instead relies on the set_alarm operation to return invalid. For example, when a RTC_UIE_ON ioctl is handled, it should abort at the feature validation. Instead, it proceeds to the rtc_timer_enqueue(), which used to return an error from the set_alarm call. However, following the race condition handling, which likely should not be discarding predecing errors, a success condition is returned to the ioctl() caller. This results in (for example): hwclock: select() to /dev/rtc0 to wait for clock tick timed out Notwithstanding the validity of the race condition handling, if an interrupt wasn't specified, or could not be attached, the driver should clear the alarm feature bit. Fixes: 718a820a303c ("rtc: abx80x: add alarm support") Signed-off-by: Anthony Pighin Link: https://patch.msgid.link/BN0PR08MB69510928028C933749F4139383D1A@BN0PR08MB6951.namprd08.prod.outlook.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit a3fd5dc1c7b0aae947a67dc2e2c037d57557a4de Author: Bae Yeonju Date: Sat Mar 21 13:45:02 2026 +0900 fs/adfs: validate nzones in adfs_validate_bblk() [ Upstream commit dd9d3e16c2d5fa166e13dce07413be51f42c8f5d ] Reject ADFS disc records with a zero zone count during boot block validation, before the disc record is used. When nzones is 0, adfs_read_map() passes it to kmalloc_array(0, ...) which returns ZERO_SIZE_PTR, and adfs_map_layout() then writes to dm[-1], causing an out-of-bounds write before the allocated buffer. adfs_validate_dr0() already rejects nzones != 1 for old-format images. Add the equivalent check to adfs_validate_bblk() for new-format images so that a crafted image with nzones == 0 is rejected at probe time. Found by syzkaller. Fixes: f6f14a0d71b0 ("fs/adfs: map: move map-specific sb initialisation to map.c") Signed-off-by: Bae Yeonju Signed-off-by: Russell King (Oracle) Signed-off-by: Sasha Levin commit ef4ca02e95363e78977ca04340d44fe3b4b2b81f Author: Christian Brauner Date: Thu Apr 23 11:56:09 2026 +0200 eventpoll: fix ep_remove struct eventpoll / struct file UAF [ Upstream commit a6dc643c69311677c574a0f17a3f4d66a5f3744b ] ep_remove() (via ep_remove_file()) cleared file->f_ep under file->f_lock but then kept using @file inside the critical section (is_file_epoll(), hlist_del_rcu() through the head, spin_unlock). A concurrent __fput() taking the eventpoll_release() fastpath in that window observed the transient NULL, skipped eventpoll_release_file() and ran to f_op->release / file_free(). For the epoll-watches-epoll case, f_op->release is ep_eventpoll_release() -> ep_clear_and_put() -> ep_free(), which kfree()s the watched struct eventpoll. Its embedded ->refs hlist_head is exactly where epi->fllink.pprev points, so the subsequent hlist_del_rcu()'s "*pprev = next" scribbles into freed kmalloc-192 memory. In addition, struct file is SLAB_TYPESAFE_BY_RCU, so the slot backing @file could be recycled by alloc_empty_file() -- reinitializing f_lock and f_ep -- while ep_remove() is still nominally inside that lock. The upshot is an attacker-controllable kmem_cache_free() against the wrong slab cache. Pin @file via epi_fget() at the top of ep_remove() and gate the critical section on the pin succeeding. With the pin held @file cannot reach refcount zero, which holds __fput() off and transitively keeps the watched struct eventpoll alive across the hlist_del_rcu() and the f_lock use, closing both UAFs. If the pin fails @file has already reached refcount zero and its __fput() is in flight. Because we bailed before clearing f_ep, that path takes the eventpoll_release() slow path into eventpoll_release_file() and blocks on ep->mtx until the waiter side's ep_clear_and_put() drops it. The bailed epi's share of ep->refcount stays intact, so the trailing ep_refcount_dec_and_test() in ep_clear_and_put() cannot free the eventpoll out from under eventpoll_release_file(); the orphaned epi is then cleaned up there. A successful pin also proves we are not racing eventpoll_release_file() on this epi, so drop the now-redundant re-check of epi->dying under f_lock. The cheap lockless READ_ONCE(epi->dying) fast-path bailout stays. Fixes: 58c9b016e128 ("epoll: use refcount to reduce ep_mutex contention") Reported-by: Jaeyoung Chung Link: https://patch.msgid.link/20260423-work-epoll-uaf-v1-6-2470f9eec0f5@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit eb206b8f55e14985eb531e76cc741e0de6270df1 Author: Christian Brauner Date: Thu Apr 23 11:56:08 2026 +0200 eventpoll: move epi_fget() up [ Upstream commit 86e87059e6d1fd5115a31949726450ed03c1073b ] We'll need it when removing files so move it up. No functional change. Link: https://patch.msgid.link/20260423-work-epoll-uaf-v1-5-2470f9eec0f5@kernel.org Signed-off-by: Christian Brauner (Amutable) Stable-dep-of: a6dc643c6931 ("eventpoll: fix ep_remove struct eventpoll / struct file UAF") Signed-off-by: Sasha Levin commit e644f892e1f27b7ed21a513a62b42dc1ca62d468 Author: Christian Brauner Date: Fri Apr 24 00:23:18 2026 +0200 eventpoll: drop vestigial __ prefix from ep_remove_{file,epi}() [ Upstream commit 0feaf644f7180c4a91b6b405a881afbfd958f1cf ] With __ep_remove() gone, the double-underscore on __ep_remove_file() and __ep_remove_epi() no longer contrasts with a __-less parent and just reads as noise. Rename both to ep_remove_file() and ep_remove_epi(). No functional change. Signed-off-by: Christian Brauner (Amutable) Stable-dep-of: a6dc643c6931 ("eventpoll: fix ep_remove struct eventpoll / struct file UAF") Signed-off-by: Sasha Levin commit e084713397a415afa4166994d5af5afea20c2ef4 Author: Christian Brauner Date: Thu Apr 23 11:56:06 2026 +0200 eventpoll: kill __ep_remove() [ Upstream commit e9e5cd40d7c403e19f21d0f7b8b8ba3a76b58330 ] Remove the boolean conditional in __ep_remove() and restructure the code so the check for racing with eventpoll_release_file() are only done in the ep_remove_safe() path where they belong. Link: https://patch.msgid.link/20260423-work-epoll-uaf-v1-3-2470f9eec0f5@kernel.org Signed-off-by: Christian Brauner (Amutable) Stable-dep-of: a6dc643c6931 ("eventpoll: fix ep_remove struct eventpoll / struct file UAF") Signed-off-by: Sasha Levin commit 416b491cd2890470624a85d90ca53242f1ea68ef Author: Christian Brauner Date: Thu Apr 23 11:56:05 2026 +0200 eventpoll: split __ep_remove() [ Upstream commit 0f7bdfd413000985de09fc39eb9efa1e091a3ce0 ] Split __ep_remove() to delineate file removal from epoll item removal. Suggested-by: Linus Torvalds Link: https://patch.msgid.link/20260423-work-epoll-uaf-v1-2-2470f9eec0f5@kernel.org Signed-off-by: Christian Brauner (Amutable) Stable-dep-of: a6dc643c6931 ("eventpoll: fix ep_remove struct eventpoll / struct file UAF") Signed-off-by: Sasha Levin commit 9348f4763aa9b9e97fb006edc7aabd2aa209e5eb Author: Christian Brauner Date: Thu Apr 23 11:56:04 2026 +0200 eventpoll: use hlist_is_singular_node() in __ep_remove() [ Upstream commit 3d9fd0abc94d8cd430cc7cd7d37ce5e5aae2cd2b ] Replace the open-coded "epi is the only entry in file->f_ep" check with hlist_is_singular_node(). Same semantics, and the helper avoids the head-cacheline access in the common false case. Link: https://patch.msgid.link/20260423-work-epoll-uaf-v1-1-2470f9eec0f5@kernel.org Signed-off-by: Christian Brauner (Amutable) Stable-dep-of: a6dc643c6931 ("eventpoll: fix ep_remove struct eventpoll / struct file UAF") Signed-off-by: Sasha Levin commit bd501c86407da75bf7242fc89b71cdb9045e5a18 Author: Randy Dunlap Date: Thu Apr 16 14:54:29 2026 -0700 nstree: fix func. parameter kernel-doc warnings [ Upstream commit 43eb354ecb471426e97b0ce6a0c922ec20f82027 ] Use the correct parameter name ("__ns") for function parameter kernel-doc to avoid 3 warnings: Warning: include/linux/nstree.h:68 function parameter '__ns' not described in 'ns_tree_add_raw' Warning: include/linux/nstree.h:77 function parameter '__ns' not described in 'ns_tree_add' Warning: include/linux/nstree.h:88 function parameter '__ns' not described in 'ns_tree_remove' Fixes: 885fc8ac0a4d ("nstree: make iterator generic") Signed-off-by: Randy Dunlap Link: https://patch.msgid.link/20260416215429.948898-1-rdunlap@infradead.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 70f788e22693e98957e61e64e9e9b0cfbe57d374 Author: Kohei Enju Date: Wed Apr 22 02:30:24 2026 +0000 vhost_net: fix sleeping with preempt-disabled in vhost_net_busy_poll() [ Upstream commit e08a9fac5cf8c3fecf4755e7e3ac059f78b8f83d ] syzbot reported "sleeping function called from invalid context" in vhost_net_busy_poll(). Commit 030881372460 ("vhost_net: basic polling support") introduced a busy-poll loop and preempt_{disable,enable}() around it, where each iteration calls a sleepable function inside the loop. The purpose of disabling preemption was to keep local_clock()-based timeout accounting on a single CPU, rather than as a requirement of busy-poll itself: https://lore.kernel.org/1448435489-5949-4-git-send-email-jasowang@redhat.com From this perspective, migrate_disable() is sufficient here, so replace preempt_disable() with migrate_disable(), avoiding sleepable accesses from a preempt-disabled context. Fixes: 030881372460 ("vhost_net: basic polling support") Tested-by: syzbot+6985cb8e543ea90ba8ee@syzkaller.appspotmail.com Reported-by: syzbot+6985cb8e543ea90ba8ee@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/69e6a414.050a0220.24bfd3.002d.GAE@google.com/T/ Signed-off-by: Kohei Enju Acked-by: Michael S. Tsirkin Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1d5e589055880fae229e229e1929e087dbe08cf3 Author: Lee Jones Date: Tue Apr 21 13:45:26 2026 +0100 tipc: fix double-free in tipc_buf_append() [ Upstream commit d293ca716e7d5dffdaecaf6b9b2f857a33dc3d3a ] tipc_msg_validate() can potentially reallocate the skb it is validating, freeing the old one. In tipc_buf_append(), it was being called with a pointer to a local variable which was a copy of the caller's skb pointer. If the skb was reallocated and validation subsequently failed, the error handling path would free the original skb pointer, which had already been freed, leading to double-free. Fix this by checking if head now points to a newly allocated reassembled skb. If it does, reassign *headbuf for later freeing operations. Fixes: d618d09a68e4 ("tipc: enforce valid ratio between skb truesize and contents") Suggested-by: Tung Nguyen Signed-off-by: Lee Jones Reviewed-by: Tung Nguyen Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 671f743d2dd50a36b33f485ac2a745f0ecde3d72 Author: Jiayuan Chen Date: Wed Apr 22 20:35:38 2026 +0800 tcp: send a challenge ACK on SEG.ACK > SND.NXT [ Upstream commit 42726ec644cbdde0035c3e0417fee8ed9547e120 ] RFC 5961 Section 5.2 validates an incoming segment's ACK value against the range [SND.UNA - MAX.SND.WND, SND.NXT] and states: "All incoming segments whose ACK value doesn't satisfy the above condition MUST be discarded and an ACK sent back." Commit 354e4aa391ed ("tcp: RFC 5961 5.2 Blind Data Injection Attack Mitigation") opted Linux into this mitigation and implements the challenge ACK on the lower side (SEG.ACK < SND.UNA - MAX.SND.WND), but the symmetric upper side (SEG.ACK > SND.NXT) still takes the pre-RFC-5961 path and silently returns SKB_DROP_REASON_TCP_ACK_UNSENT_DATA, even though RFC 793 Section 3.9 (now RFC 9293 Section 3.10.7.4) has always required: "If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return." Complete the mitigation by sending a challenge ACK on that branch, reusing the existing tcp_send_challenge_ack() path which already enforces the per-socket RFC 5961 Section 7 rate limit via __tcp_oow_rate_limited(). FLAG_NO_CHALLENGE_ACK is honoured for symmetry with the lower-edge case. Update the existing tcp_ts_recent_invalid_ack.pkt selftest, which drives this exact path, to consume the new challenge ACK. Fixes: 354e4aa391ed ("tcp: RFC 5961 5.2 Blind Data Injection Attack Mitigation") Signed-off-by: Jiayuan Chen Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260422123605.320000-2-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b5992dbb3bc521bd5bc16aa8144471b2f43cc68f Author: Alexey Kodanev Date: Wed Apr 22 16:05:36 2026 +0000 nfp: fix swapped arguments in nfp_encode_basic_qdr() calls [ Upstream commit 4078c5611d7585548b249377ebd60c272e410490 ] There is a mismatch between the passed arguments and the actual nfp_encode_basic_qdr() function parameter names: static int nfp_encode_basic_qdr(u64 addr, int dest_island, int cpp_tgt, int mode, bool addr40, int isld1, int isld0) { ... But "dest_island" and "cpp_tgt" are swapped at every call-site. For example: return nfp_encode_basic_qdr(*addr, cpp_tgt, dest_island, mode, addr40, isld1, isld0); As a result, nfp_encode_basic_qdr() receives "dest_island" as CPP target type, which is always NFP_CPP_TARGET_QDR(2) for these calls, and "cpp_tgt" as the destination island ID, which can accidentally match or be outside the valid NFP_CPP_TARGET_* types (e.g. '-1' for any destination). Since code already worked for years, also add extra pr_warn() to error paths in nfp_encode_basic_qdr() to help identify any potential address verification failures. Detected using the static analysis tool - Svace. Fixes: 4cb584e0ee7d ("nfp: add CPP access core") Signed-off-by: Alexey Kodanev Link: https://patch.msgid.link/20260422160536.61855-1-aleksei.kodanev@bell-sw.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1abf8c202cafc37aecb1db7c5b19b1240f934520 Author: Brett Creeley Date: Thu Apr 16 14:21:21 2026 -0700 virtio_net: sync rss_trailer.max_tx_vq on queue_pairs change via VQ_PAIRS_SET [ Upstream commit 3bc06da858ef17cfe94b49efc0d9713727012835 ] When netif_is_rxfh_configured() is true (i.e., the user has explicitly configured the RSS indirection table), virtnet_set_queues() skips the RSS update path and falls through to the VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command to change the number of queue pairs. However, it does not update vi->rss_trailer.max_tx_vq to reflect the new queue_pairs value. This causes a mismatch between vi->curr_queue_pairs and vi->rss_trailer.max_tx_vq. Any subsequent RSS reconfiguration (e.g., via ethtool -X) calls virtnet_commit_rss_command(), which sends the stale max_tx_vq to the device, silently reverting the queue count. Reproduction: 1. User configured RSS ethtool -X eth0 equal 8 2. VQ_PAIRS_SET path; max_tx_vq stays 16 ethtool -L eth0 combined 12 3. RSS commit uses max_tx_vq=16 instead of 12 ethtool -X eth0 equal 4 Fix this by updating vi->rss_trailer.max_tx_vq after a successful VQ_PAIRS_SET command when RSS is enabled, keeping it in sync with curr_queue_pairs. Fixes: 50bfcaedd78e ("virtio_net: Update rss when set queue") Signed-off-by: Brett Creeley Acked-by: Michael S. Tsirkin Link: https://patch.msgid.link/20260416212121.29073-1-brett.creeley@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6af1736b5810bc8a4a43a8518530113f5a757dc1 Author: Stefano Garzarella Date: Mon Apr 20 15:20:51 2026 +0200 vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting [ Upstream commit 1cb36e252211506f51095fe7ced8286cc77b4c80 ] virtio_transport_init_zcopy_skb() uses iter->count as the size argument for msg_zerocopy_realloc(), which in turn passes it to mm_account_pinned_pages() for RLIMIT_MEMLOCK accounting. However, this function is called after virtio_transport_fill_skb() has already consumed the iterator via __zerocopy_sg_from_iter(), so on the last skb, iter->count will be 0, skipping the RLIMIT_MEMLOCK enforcement. Pass pkt_len (the total bytes being sent) as an explicit parameter to virtio_transport_init_zcopy_skb() instead of reading the already-consumed iter->count. This matches TCP and UDP, which both call msg_zerocopy_realloc() with the original message size. Fixes: 581512a6dc93 ("vsock/virtio: MSG_ZEROCOPY flag support") Reported-by: Yiming Qian Signed-off-by: Stefano Garzarella Reviewed-by: Bobby Eshleman Link: https://patch.msgid.link/20260420132051.217589-1-sgarzare@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c60545ffb9203f3adac5af0b1e75d9c3df468c69 Author: Erni Sri Satya Vennela Date: Mon Apr 20 05:47:39 2026 -0700 net: mana: Fix EQ leak in mana_remove on NULL port [ Upstream commit 65267c9c4f28199985505977bc2c628c82fc50ef ] In mana_remove(), when a NULL port is encountered in the port iteration loop, 'goto out' skips the mana_destroy_eq(ac) call, leaking the event queues allocated earlier by mana_create_eq(). This can happen when mana_probe_port() fails for port 0, leaving ac->ports[0] as NULL. On driver unload or error cleanup, mana_remove() hits the NULL entry and jumps past mana_destroy_eq(). Change 'goto out' to 'break' so the for-loop exits normally and mana_destroy_eq() is always reached. Remove the now-unreferenced out: label. Fixes: 1e2d0824a9c3 ("net: mana: Add support for EQ sharing") Signed-off-by: Erni Sri Satya Vennela Link: https://patch.msgid.link/20260420124741.1056179-6-ernis@linux.microsoft.com Reviewed-by: Simon Horman Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit fb9f98e1041a30dd5766620a2a64cb472b54caa9 Author: Dipayaan Roy Date: Mon Jan 12 05:05:52 2026 -0800 net: mana: Implement ndo_tx_timeout and serialize queue resets per port. [ Upstream commit 3b194343c25084a8d2fa0c0f2c9e80f3080fd732 ] Implement .ndo_tx_timeout for MANA so any stalled TX queue can be detected and a device-controlled port reset for all queues can be scheduled to a ordered workqueue. The reset for all queues on stall detection is recomended by hardware team. Reviewed-by: Pavan Chebbi Reviewed-by: Haiyang Zhang Signed-off-by: Dipayaan Roy Link: https://patch.msgid.link/20260112130552.GA11785@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net Signed-off-by: Jakub Kicinski Stable-dep-of: 65267c9c4f28 ("net: mana: Fix EQ leak in mana_remove on NULL port") Signed-off-by: Sasha Levin commit 2c345eb03d2f9e3d3397d0761ea4f40c6da5f546 Author: Long Li Date: Wed Nov 26 13:45:52 2025 -0800 net: mana: Handle hardware recovery events when probing the device [ Upstream commit 9bf66036d686b9a67000ba22bd94be13a4ea79ac ] When MANA is being probed, it's possible that hardware is in recovery mode and the device may get GDMA_EQE_HWC_RESET_REQUEST over HWC in the middle of the probe. Detect such condition and go through the recovery service procedure. Signed-off-by: Long Li Reviewed-by: Haiyang Zhang Link: https://patch.msgid.link/1764193552-9712-1-git-send-email-longli@linux.microsoft.com Signed-off-by: Jakub Kicinski Stable-dep-of: 65267c9c4f28 ("net: mana: Fix EQ leak in mana_remove on NULL port") Signed-off-by: Sasha Levin commit e0596009873e1137949cd87b84b38f97fb0177d8 Author: Aditya Garg Date: Tue Nov 18 03:11:08 2025 -0800 net: mana: Handle SKB if TX SGEs exceed hardware limit [ Upstream commit 934fa943b53795339486cc0026b3ab7ad39dc600 ] The MANA hardware supports a maximum of 30 scatter-gather entries (SGEs) per TX WQE. Exceeding this limit can cause TX failures. Add ndo_features_check() callback to validate SKB layout before transmission. For GSO SKBs that would exceed the hardware SGE limit, clear NETIF_F_GSO_MASK to enforce software segmentation in the stack. Add a fallback in mana_start_xmit() to linearize non-GSO SKBs that still exceed the SGE limit. Also, Add ethtool counter for SKBs linearized Co-developed-by: Dipayaan Roy Signed-off-by: Dipayaan Roy Signed-off-by: Aditya Garg Reviewed-by: Eric Dumazet Reviewed-by: Haiyang Zhang Link: https://patch.msgid.link/1763464269-10431-2-git-send-email-gargaditya@linux.microsoft.com Signed-off-by: Jakub Kicinski Stable-dep-of: 65267c9c4f28 ("net: mana: Fix EQ leak in mana_remove on NULL port") Signed-off-by: Sasha Levin commit 577441de198339d762b98b28c3c68dc4ade553e4 Author: Erni Sri Satya Vennela Date: Mon Apr 20 05:47:38 2026 -0700 net: mana: Don't overwrite port probe error with add_adev result [ Upstream commit a7fdaf069bd031fcc234581fa6a580be11bf2175 ] In mana_probe(), if mana_probe_port() fails for any port, the error is stored in 'err' and the loop breaks. However, the subsequent unconditional 'err = add_adev(gd, "eth")' overwrites this error. If add_adev() succeeds, mana_probe() returns success despite ports being left in a partially initialized state (ac->ports[i] == NULL). Only call add_adev() when there is no prior error, so the probe correctly fails and triggers mana_remove() cleanup. Fixes: a69839d4327d ("net: mana: Add support for auxiliary device") Signed-off-by: Erni Sri Satya Vennela Link: https://patch.msgid.link/20260420124741.1056179-5-ernis@linux.microsoft.com Reviewed-by: Simon Horman Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 95e4598b68052b9aea7f3ea062b7bafe3299e50a Author: Erni Sri Satya Vennela Date: Fri Nov 14 03:43:19 2025 -0800 net: mana: Add standard counter rx_missed_errors [ Upstream commit be4f1d67ec56f23f37714ac73c01094e63c7ff28 ] Report standard counter stats->rx_missed_errors using hc_rx_discards_no_wqe from the hardware. Add a global workqueue to periodically run mana_query_gf_stats every 2 seconds to get the latest info in eth_stats and define a driver capability flag to notify hardware of the periodic queries. To avoid repeated failures and log flooding, the workqueue is not rescheduled if mana_query_gf_stats fails on HWC timeout error and the stats are reset to 0. Other errors are transient which will not need a VF reset for recovery. Signed-off-by: Erni Sri Satya Vennela Reviewed-by: Haiyang Zhang Link: https://patch.msgid.link/1763120599-6331-3-git-send-email-ernis@linux.microsoft.com Signed-off-by: Jakub Kicinski Stable-dep-of: a7fdaf069bd0 ("net: mana: Don't overwrite port probe error with add_adev result") Signed-off-by: Sasha Levin commit 8804f00ea0283ff5d0a4193385fde27f0a4892c3 Author: Erni Sri Satya Vennela Date: Fri Nov 14 03:43:18 2025 -0800 net: mana: Move hardware counter stats from per-port to per-VF context [ Upstream commit e275d9091c01b3b46f3ec534ce4ac77cffc9e3ae ] Move hardware counter (HC) statistics from mana_port_context to mana_context to enable sharing stats across multiple network ports on the same MANA VF. Previously, each network port queried hardware counters independently using MANA_QUERY_GF_STAT command (GF = Generic Function stats from GDMA hardware), resulting in redundant queries when multiple ports existed on the same device. Isolate hardware counter stats by introducing mana_ethtool_hc_stats in mana_context and update the code to ensure all stats are properly reported via ethtool -S , maintaining consistency with previous behavior. Signed-off-by: Erni Sri Satya Vennela Reviewed-by: Haiyang Zhang Link: https://patch.msgid.link/1763120599-6331-2-git-send-email-ernis@linux.microsoft.com Signed-off-by: Jakub Kicinski Stable-dep-of: a7fdaf069bd0 ("net: mana: Don't overwrite port probe error with add_adev result") Signed-off-by: Sasha Levin commit a1ddfd2c0b7a48e5239fadd2a24cc4bc2cda90e6 Author: Erni Sri Satya Vennela Date: Mon Apr 20 05:47:37 2026 -0700 net: mana: Guard mana_remove against double invocation [ Upstream commit 50271d7ec95144d26808025b508f463780517d3c ] If PM resume fails (e.g., mana_attach() returns an error), mana_probe() calls mana_remove(), which tears down the device and sets gd->gdma_context = NULL and gd->driver_data = NULL. However, a failed resume callback does not automatically unbind the driver. When the device is eventually unbound, mana_remove() is invoked a second time. Without a NULL check, it dereferences gc->dev with gc == NULL, causing a kernel panic. Add an early return if gdma_context or driver_data is NULL so the second invocation is harmless. Move the dev = gc->dev assignment after the guard so it cannot dereference NULL. Fixes: 635096a86edb ("net: mana: Support hibernation and kexec") Signed-off-by: Erni Sri Satya Vennela Link: https://patch.msgid.link/20260420124741.1056179-4-ernis@linux.microsoft.com Reviewed-by: Simon Horman Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 8709d4457faf3691e1b08a70fa157b53bedbc3d9 Author: Erni Sri Satya Vennela Date: Mon Apr 20 05:47:35 2026 -0700 net: mana: Init link_change_work before potential error paths in probe [ Upstream commit cb4a90744bcd1adf12f0d0c7c4f0dd2647444ec5 ] Move INIT_WORK(link_change_work) to right after the mana_context allocation, before any error path that could reach mana_remove(). Previously, if mana_create_eq() or mana_query_device_cfg() failed, mana_probe() would jump to the error path which calls mana_remove(). mana_remove() unconditionally calls disable_work_sync(link_change_work), but the work struct had not been initialized yet. This can trigger CONFIG_DEBUG_OBJECTS_WORK enabled. Fixes: 54133f9b4b53 ("net: mana: Support HW link state events") Signed-off-by: Erni Sri Satya Vennela Link: https://patch.msgid.link/20260420124741.1056179-2-ernis@linux.microsoft.com Reviewed-by: Simon Horman Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 5a90c4cfd8b7ad779ef62a810a391ee88eaf2726 Author: Lorenzo Bianconi Date: Mon Apr 20 10:07:48 2026 +0200 net: airoha: Add size check for TX NAPIs in airoha_qdma_cleanup() [ Upstream commit 4b91cb65789b794bfc8d50554b8994f8e0f16309 ] If airoha_qdma_init routine fails before airoha_qdma_tx_irq_init() runs successfully for all TX NAPIs, airoha_qdma_cleanup() will unconditionally runs netif_napi_del() on TX NAPIs, triggering a NULL pointer dereference. Fix the issue relying on q_tx_irq size value to check if the TX NAPIs is properly initialized in airoha_qdma_cleanup(). Moreover, run netif_napi_add_tx() just if irq_q queue is properly allocated. Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260420-airoha_qdma_init_rx_queue-fix-v2-2-d99347e5c18d@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit d8ad264e9a019808c858aeada39a9bf99467868c Author: Lorenzo Bianconi Date: Sat Mar 21 15:41:44 2026 +0100 net: airoha: Rework the code flow in airoha_remove() and in airoha_probe() error path [ Upstream commit b1c803d5c8167026791abfaed96fd3e6a1fcd750 ] As suggested by Simon in [0], rework the code flow in airoha_remove() and in the airoha_probe() error path in order to rely on a more common approach un-registering configured net-devices first and destroying the hw resources at the end of the code. Introduce airoha_qdma_cleanup routine to release QDMA resources. [0] https://lore.kernel.org/netdev/20251214-airoha-fix-dev-registration-v1-1-860e027ad4c6@kernel.org/ Suggested-by: Simon Horman Signed-off-by: Lorenzo Bianconi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260321-airoha-remove-rework-v2-1-16c7bade5fe5@kernel.org Signed-off-by: Paolo Abeni Stable-dep-of: 4b91cb65789b ("net: airoha: Add size check for TX NAPIs in airoha_qdma_cleanup()") Signed-off-by: Sasha Levin commit 4d4acfa348a1d8c0941004823662ede0fdb5dea5 Author: Lorenzo Bianconi Date: Mon Apr 20 10:07:47 2026 +0200 net: airoha: Move ndesc initialization at end of airoha_qdma_init_rx_queue() [ Upstream commit 379050947a1828826ad7ea50c95245a56929b35a ] If queue entry or DMA descriptor list allocation fails in airoha_qdma_init_rx_queue routine, airoha_qdma_cleanup() will trigger a NULL pointer dereference running netif_napi_del() for RX queue NAPIs since netif_napi_add() has never been executed to this particular RX NAPI. The issue is due to the early ndesc initialization in airoha_qdma_init_rx_queue() since airoha_qdma_cleanup() relies on ndesc value to check if the queue is properly initialized. Fix the issue moving ndesc initialization at end of airoha_qdma_init_tx routine. Move page_pool allocation after descriptor list allocation in order to avoid memory leaks if desc allocation fails. Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260420-airoha_qdma_init_rx_queue-fix-v2-1-d99347e5c18d@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit b707f3109f1a7828b93f1633be39c0ebc9ce4afc Author: Mieczyslaw Nalewaj Date: Sun Apr 19 21:37:07 2026 +0200 net: dsa: realtek: rtl8365mb: fix mode mask calculation [ Upstream commit 0c078021d3861966614d5e594ee03587f0c9e74d ] The RTL8365MB_DIGITAL_INTERFACE_SELECT_MODE_MASK macro was shifting the 4-bit mask (0xF) by only (_extint % 2) bits instead of (_extint % 2) * 4. This caused the mask to overlap with the adjacent nibble when configuring odd-numbered external interfaces, selecting the wrong bits entirely. Align the shift calculation with the existing ...MODE_OFFSET macro. Fixes: 4af2950c50c8 ("net: dsa: realtek-smi: add rtl8365mb subdriver for RTL8365MB-VC") Signed-off-by: Abdulkader Alrezej Signed-off-by: Mieczyslaw Nalewaj Reviewed-by: Luiz Angelo Daros de Luca Link: https://patch.msgid.link/400a6387-a444-4576-af6d-26be5410bce3@yahoo.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c0cfce4d76702dba9601a4020df1a0bc35806efc Author: Lorenzo Bianconi Date: Fri Apr 17 08:36:32 2026 +0200 net: airoha: Add missing bits in airoha_qdma_cleanup_tx_queue() [ Upstream commit 3309965fe44c00fd65af7cef5016e9e782c021a7 ] Similar to airoha_qdma_cleanup_rx_queue(), reset DMA TX descriptors in airoha_qdma_cleanup_tx_queue routine. Moreover, reset TX_DMA_IDX to TX_CPU_IDX to notify the NIC the QDMA TX ring is empty. Fixes: 23020f0493270 ("net: airoha: Introduce ethernet support for EN7581 SoC") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260417-airoha_qdma_cleanup_tx_queue-fix-net-v4-2-e04bcc2c9642@kernel.org Reviewed-by: Simon Horman Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ad02cb61c52cae5afa3e2de6adbb49ad884c26e9 Author: Lorenzo Bianconi Date: Thu Nov 6 13:53:23 2025 +0100 net: airoha: Add the capability to consume out-of-order DMA tx descriptors [ Upstream commit 3f47e67dff1f7266e112c50313d63824f6f17102 ] EN7581 and AN7583 SoCs are capable of DMA mapping non-linear tx skbs on non-consecutive DMA descriptors. This feature is useful when multiple flows are queued on the same hw tx queue since it allows to fully utilize the available tx DMA descriptors and to avoid the starvation of high-priority flow we have in the current codebase due to head-of-line blocking introduced by low-priority flows. Tested-by: Xuegang Lu Reviewed-by: Jacob Keller Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251106-airoha-tx-linked-list-v2-1-0706d4a322bd@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: 3309965fe44c ("net: airoha: Add missing bits in airoha_qdma_cleanup_tx_queue()") Signed-off-by: Sasha Levin commit b7c1bbf78b099723c32abbd6bcc7bc8c20d43129 Author: Lorenzo Bianconi Date: Fri Oct 17 11:06:22 2025 +0200 net: airoha: Add AN7583 SoC support [ Upstream commit e4e5ce823bdd4601bd75ae7c206ae35e7c2fa60b ] Introduce support for AN7583 ethernet controller to airoha-eth dirver. Reviewed-by: Simon Horman Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251017-an7583-eth-support-v3-13-f28319666667@kernel.org Signed-off-by: Paolo Abeni Stable-dep-of: 3309965fe44c ("net: airoha: Add missing bits in airoha_qdma_cleanup_tx_queue()") Signed-off-by: Sasha Levin commit 8d913ab0141974d2d640ba3e8e14821f53800dee Author: Lorenzo Bianconi Date: Fri Oct 17 11:06:20 2025 +0200 net: airoha: Refactor src port configuration in airhoha_set_gdm2_loopback [ Upstream commit 9d5b5219f672c80bed4d4e15f0068e648cdca43b ] AN7583 chipset relies on different definitions for source-port identifier used for hw offloading. In order to support hw offloading in AN7583 controller, refactor src port configuration in airhoha_set_gdm2_loopback routine and introduce get_src_port_id callback. Reviewed-by: Simon Horman Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251017-an7583-eth-support-v3-11-f28319666667@kernel.org Signed-off-by: Paolo Abeni Stable-dep-of: 3309965fe44c ("net: airoha: Add missing bits in airoha_qdma_cleanup_tx_queue()") Signed-off-by: Sasha Levin commit 1a21910e32d788238b7f6d0de71e284df288b4c1 Author: Lorenzo Bianconi Date: Fri Oct 17 11:06:15 2025 +0200 net: airoha: ppe: Move PPE memory info in airoha_eth_soc_data struct [ Upstream commit 5bd1d1fd48ea9f8300b211540d946899c7f96480 ] AN7583 SoC runs a single PPE device while EN7581 runs two of them. Moreover PPE SRAM in AN7583 SoC is reduced to 8K (while SRAM is 16K on EN7581). Take into account PPE memory layout during PPE configuration. Reviewed-by: Simon Horman Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251017-an7583-eth-support-v3-6-f28319666667@kernel.org Signed-off-by: Paolo Abeni Stable-dep-of: 3309965fe44c ("net: airoha: Add missing bits in airoha_qdma_cleanup_tx_queue()") Signed-off-by: Sasha Levin commit 56b99327a451917f1c17f85fc33ea8293c08a9ee Author: Lorenzo Bianconi Date: Fri Oct 17 11:06:11 2025 +0200 net: airoha: ppe: Dynamically allocate foe_check_time array in airoha_ppe struct [ Upstream commit 6d5b601d52a27aafff555b480e538507901c672c ] This is a preliminary patch to properly enable PPE support for AN7583 SoC. Reviewed-by: Simon Horman Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251017-an7583-eth-support-v3-2-f28319666667@kernel.org Signed-off-by: Paolo Abeni Stable-dep-of: 3309965fe44c ("net: airoha: Add missing bits in airoha_qdma_cleanup_tx_queue()") Signed-off-by: Sasha Levin commit ae68eb4f2fddcc631d6e429678931f3b4e649914 Author: Eric Dumazet Date: Tue Apr 21 14:16:55 2026 +0000 net/sched: sch_sfb: annotate data-races in sfb_dump_stats() [ Upstream commit 1ada03fdef82d3d7d2edb9dcd3acc91917675e48 ] sfb_dump_stats() only runs with RTNL held, reading fields that can be changed in qdisc fast path. Add READ_ONCE()/WRITE_ONCE() annotations. Alternative would be to acquire the qdisc spinlock, but our long-term goal is to make qdisc dump operations lockless as much as we can. tc_sfb_xstats fields don't need to be latched atomically, otherwise this bug would have been caught earlier. Fixes: edb09eb17ed8 ("net: sched: do not acquire qdisc spinlock in qdisc/class stats dump") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260421141655.3953721-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 910213de955e40c5b9e2680f6e0eb6614caa3c59 Author: Eric Dumazet Date: Tue Apr 21 14:23:09 2026 +0000 net/sched: sch_red: annotate data-races in red_dump_stats() [ Upstream commit a8f5192809caf636d05ba47c144f282cfd0e3839 ] red_dump_stats() only runs with RTNL held, reading fields that can be changed in qdisc fast path. Add READ_ONCE()/WRITE_ONCE() annotations. Alternative would be to acquire the qdisc spinlock, but our long-term goal is to make qdisc dump operations lockless as much as we can. tc_red_xstats fields don't need to be latched atomically, otherwise this bug would have been caught earlier. Fixes: edb09eb17ed8 ("net: sched: do not acquire qdisc spinlock in qdisc/class stats dump") Signed-off-by: Eric Dumazet Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260421142309.3964322-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1dbe52b6a0aff9555297971cc6ecf169695f7e34 Author: Eric Dumazet Date: Tue Apr 21 14:25:09 2026 +0000 net/sched: sch_fq_codel: remove data-races from fq_codel_dump_stats() [ Upstream commit bbfaa73ea6871db03dc05d7f05f00557a8981f25 ] fq_codel_dump_stats() acquires the qdisc spinlock a bit too late. Move this acquisition before we fill st.qdisc_stats with live data. Fixes: edb09eb17ed8 ("net: sched: do not acquire qdisc spinlock in qdisc/class stats dump") Signed-off-by: Eric Dumazet Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260421142509.3967231-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 796fb2037d854e8fdf4f8d00ad01193762c6c346 Author: Eric Dumazet Date: Tue Apr 21 14:29:44 2026 +0000 net/sched: sch_pie: annotate data-races in pie_dump_stats() [ Upstream commit 5154561d9b119f781249f8e845fecf059b38b483 ] pie_dump_stats() only runs with RTNL held, reading fields that can be changed in qdisc fast path. Add READ_ONCE()/WRITE_ONCE() annotations. Alternative would be to acquire the qdisc spinlock, but our long-term goal is to make qdisc dump operations lockless as much as we can. tc_pie_xstats fields don't need to be latched atomically, otherwise this bug would have been caught earlier. Fixes: edb09eb17ed8 ("net: sched: do not acquire qdisc spinlock in qdisc/class stats dump") Signed-off-by: Eric Dumazet Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260421142944.4009941-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 48de5f5f0f7b92fecb4a03b8223584f4b8174234 Author: Eric Dumazet Date: Tue Apr 21 14:33:49 2026 +0000 net_sched: sch_hhf: annotate data-races in hhf_dump_stats() [ Upstream commit a6edf2cd4156b71e07258876b7626692e158f7e8 ] hhf_dump_stats() only runs with RTNL held, reading fields that can be changed in qdisc fast path. Add READ_ONCE()/WRITE_ONCE() annotations. Fixes: edb09eb17ed8 ("net: sched: do not acquire qdisc spinlock in qdisc/class stats dump") Signed-off-by: Eric Dumazet Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260421143349.4052215-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7846f1e20f9a221911e5a434bd59981baca21db6 Author: Jacob Keller Date: Mon Apr 20 17:51:28 2026 -0700 ice: fix ice_ptp_read_tx_hwtstamp_status_eth56g [ Upstream commit 1f75dbc53f68f0fb2acd99f92315e426a3d0b446 ] The ice_ptp_read_tx_hwtstamp_status_eth56g function calls ice_read_phy_eth56g with a PHY index. However the function actually expects a port index. This causes the function to read the wrong PHY_PTP_INT_STATUS registers, and effectively makes the status wrong for the second set of ports from 4 to 7. The ice_read_phy_eth56g function uses the provided port index to determine which PHY device to read. We could refactor the entire chain to take a PHY index, but this would impact many code sites. Instead, multiply the PHY index by the number of ports, so that we read from the first port of each PHY. Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products") Reviewed-by: Aleksandr Loktionov Reviewed-by: Petr Oros Tested-by: Sunitha Mekala Signed-off-by: Jacob Keller Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260420-jk-iwl-net-2026-04-20-ptp-e825c-phy-interrupt-fixes-v1-4-bc2240f42251@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9fb0d0528177ac7376dd1d4d78aaf3613c934fbf Author: Jacob Keller Date: Mon Apr 20 17:51:27 2026 -0700 ice: fix ready bitmap check for non-E822 devices [ Upstream commit 359dc1d41358c88955eeff1b75aee55da7a415d3 ] The E800 hardware (apart from E810) has a ready bitmap for the PHY indicating which timestamp slots currently have an outstanding timestamp waiting to be read by software. This bitmap is checked in multiple places using the ice_get_phy_tx_tstamp_ready(): * ice_ptp_process_tx_tstamp() calls it to determine which timestamps to attempt reading from the PHY * ice_ptp_tx_tstamps_pending() calls it in a loop at the end of the miscellaneous IRQ to check if new timestamps came in while the interrupt handler was executing. * ice_ptp_maybe_trigger_tx_interrupt() calls it in the auxiliary work task to trigger a software interrupt in the event that the hardware logic gets stuck. For E82X devices, multiple PHYs share the same block, and the parameter passed to the ready bitmap is a block number associated with the given port. For E825-C devices, the PHYs have their own independent blocks and do not share, so the parameter passed needs to be the port number. For E810 devices, the ice_get_phy_tx_tstamp_ready() always returns all 1s regardless of what port, since this hardware does not have a ready bitmap. Finally, for E830 devices, each PF has its own ready bitmap accessible via register, and the block parameter is unused. The first call correctly uses the Tx timestamp tracker block parameter to check the appropriate timestamp block. This works because the tracker is setup correctly for each timestamp device type. The second two callers behave incorrectly for all device types other than the older E822 devices. They both iterate in a loop using ICE_GET_QUAD_NUM() which is a macro only used by E822 devices. This logic is incorrect for devices other than the E822 devices. For E810 the calls would always return true, causing E810 devices to always attempt to trigger a software interrupt even when they have no reason to. For E830, this results in duplicate work as the ready bitmap is checked once per number of quads. Finally, for E825-C, this results in the pending checks failing to detect timestamps on ports other than the first two. Fix this by introducing a new hardware API function to ice_ptp_hw.c, ice_check_phy_tx_tstamp_ready(). This function will check if any timestamps are available and returns a positive value if any timestamps are pending. For E810, the function always returns false, so that the re-trigger checks never happen. For E830, check the ready bitmap just once. For E82x hardware, check each quad. Finally, for E825-C, check every port. The interface function returns an integer to enable reporting of error code if the driver is unable read the ready bitmap. This enables callers to handle this case properly. The previous implementation assumed that timestamps are available if they failed to read the bitmap. This is problematic as it could lead to continuous software IRQ triggering if the PHY timestamp registers somehow become inaccessible. This change is especially important for E825-C devices, as the missing checks could leave a window open where a new timestamp could arrive while the existing timestamps aren't completed. As a result, the hardware threshold logic would not trigger a new interrupt. Without the check, the timestamp is left unhandled, and new timestamps will not cause an interrupt again until the timestamp is handled. Since both the interrupt check and the backup check in the auxiliary task do not function properly, the device may have Tx timestamps permanently stuck failing on a given port. The faulty checks originate from commit d938a8cca88a ("ice: Auxbus devices & driver for E822 TS") and commit 712e876371f8 ("ice: periodically kick Tx timestamp interrupt"), however at the time of the original coding, both functions only operated on E822 hardware. This is no longer the case, and hasn't been since the introduction of the ETH56G PHY model in commit 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products") Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products") Reviewed-by: Aleksandr Loktionov Reviewed-by: Petr Oros Tested-by: Sunitha Mekala Signed-off-by: Jacob Keller Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260420-jk-iwl-net-2026-04-20-ptp-e825c-phy-interrupt-fixes-v1-3-bc2240f42251@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 77803e30cdd02751d8aa1941d76f99d7c8e91214 Author: Grzegorz Nitka Date: Mon Apr 20 17:51:26 2026 -0700 ice: perform PHY soft reset for E825C ports at initialization [ Upstream commit 3ec46e157c7fa420c77dfc23f7030e61f2f3fd55 ] In some cases the PHY timestamp block of the E825C can become stuck. This is known to occur if the software writes 0 to the Tx timestamp threshold, and with older versions of the ice driver the threshold configuration is buggy and can race in such that hardware briefly operates with a zero threshold enabled. There are no other known ways to trigger this behavior, but once it occurs, the hardware is not recovered by normal reset, a driver reload, or even a warm power cycle of the system. A cold power cycle is sufficient to recover hardware, but this is extremely invasive and can result in significant downtime on customer deployments. The PHY for each port has a timestamping block which has its own reset functionality accessible by programming the PHY_REG_GLOBAL register. Writing to the PHY_REG_GLOBAL_SOFT_RESET_BIT triggers the hardware to perform a complete reset of the timestamping block of the PHY. This includes clearing the timestamp status for the port, clearing all outstanding timestamps in the memory bank, and resetting the PHY timer. The new ice_ptp_phy_soft_reset_eth56g() function toggles the PHY_REG_GLOBAL soft reset bit with the required delays, ensuring the PHY is properly reinitialized without requiring a full device reset. The sequence clears the reset bit, asserts it, then clears it again, with short waits between transitions to allow hardware stabilization. Call this function in the new ice_ptp_init_phc_e825c(), implementing the E825C device specific variant of the ice_ptp_init_phc(). Note that if ice_ptp_init_phc() fails, PTP functionality may be disabled, but the driver will still load to allow basic functionality to continue. This causes the clock owning PF driver to perform a PHY soft reset for every port during initialization. This ensures the driver begins life in a known functional state regardless of how it was previously programmed. This ensures that we properly reconfigure the hardware after a device reset or when loading the driver, even if it was previously misconfigured with an out-of-date or modified driver. Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products") Signed-off-by: Timothy Miskell Signed-off-by: Grzegorz Nitka Reviewed-by: Aleksandr Loktionov Reviewed-by: Petr Oros Tested-by: Sunitha Mekala Signed-off-by: Jacob Keller Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260420-jk-iwl-net-2026-04-20-ptp-e825c-phy-interrupt-fixes-v1-2-bc2240f42251@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2496a593c6e35973c6c5ba64f437ef957d10b9b6 Author: Grzegorz Nitka Date: Mon Apr 20 17:51:25 2026 -0700 ice: fix timestamp interrupt configuration for E825C [ Upstream commit c0a575a801a2040eb1e0db54b488f8c548c8458a ] The E825C ice_phy_cfg_intr_eth56g() function is responsible for programming the PHY interrupt for a given port. This function writes to the PHY_REG_TS_INT_CONFIG register of the port. The register is responsible for configuring whether the port interrupt logic is enabled, as well as programming the threshold of waiting timestamps that will trigger an interrupt from this port. This threshold value must not be programmed to zero while the interrupt is enabled. Doing so puts the port in a misconfigured state where the PHY timestamp interrupt for the quad of connected ports will become stuck. This occurs, because a threshold of zero results in the timestamp interrupt status for the port becoming stuck high. The four ports in the connected quad have their timestamp status indicators muxed together. A new interrupt cannot be generated until the timestamp status indicators return low for all four ports. Normally, the timestamp status for a port will clear once there are fewer timestamps in that ports timestamp memory bank than the threshold. A threshold of zero makes this impossible, so the timestamp status for the port does not clear. The ice driver never intentionally programs the threshold to zero, indeed the driver always programs it to a value of 1, intending to get an interrupt immediately as soon as even a single packet is waiting for a timestamp. However, there is a subtle flaw in the programming logic in the ice_phy_cfg_intr_eth56g() function. Due to the way that the hardware handles enabling the PHY interrupt. If the threshold value is modified at the same time as the interrupt is enabled, the HW PHY state machine might enable the interrupt before the new threshold value is actually updated. This leaves a potential race condition caused by the hardware logic where a PHY timestamp interrupt might be triggered before the non-zero threshold is written, resulting in the PHY timestamp logic becoming stuck. Once the PHY timestamp status is stuck high, it will remain stuck even after attempting to reprogram the PHY block by changing its threshold or disabling the interrupt. Even a typical PF or CORE reset will not reset the particular block of the PHY that becomes stuck. Even a warm power cycle is not guaranteed to cause the PHY block to reset, and a cold power cycle is required. Prevent this by always writing the PHY_REG_TS_INT_CONFIG in two stages. First write the threshold value with the interrupt disabled, and only write the enable bit after the threshold has been programmed. When disabling the interrupt, leave the threshold unchanged. Additionally, re-read the register after writing it to guarantee that the write to the PHY has been flushed upon exit of the function. While we're modifying this function implementation, explicitly reject programming a threshold of 0 when enabling the interrupt. No caller does this today, but the consequences of doing so are significant. An explicit rejection in the code makes this clear. Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products") Signed-off-by: Grzegorz Nitka Reviewed-by: Aleksandr Loktionov Reviewed-by: Petr Oros Tested-by: Sunitha Mekala Signed-off-by: Jacob Keller Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260420-jk-iwl-net-2026-04-20-ptp-e825c-phy-interrupt-fixes-v1-1-bc2240f42251@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 91ce1bb6e4194dc2321748f68145359dcf86e350 Author: Michael Bommarito Date: Sat Apr 18 10:10:47 2026 -0400 net/rds: zero per-item info buffer before handing it to visitors [ Upstream commit c88eb7e8d8397a8c1db59c425332c5a30b2a1682 ] rds_for_each_conn_info() and rds_walk_conn_path_info() both hand a caller-allocated on-stack u64 buffer to a per-connection visitor and then copy the full item_len bytes back to user space via rds_info_copy() regardless of how much of the buffer the visitor actually wrote. rds_ib_conn_info_visitor() and rds6_ib_conn_info_visitor() only write a subset of their output struct when the underlying rds_connection is not in state RDS_CONN_UP (src/dst addr, tos, sl and the two GIDs via explicit memsets). Several u32 fields (max_send_wr, max_recv_wr, max_send_sge, rdma_mr_max, rdma_mr_size, cache_allocs) and the 2-byte alignment hole between sl and cache_allocs remain as whatever stack contents preceded the visitor call and are then memcpy_to_user()'d out to user space. struct rds_info_rdma_connection and struct rds6_info_rdma_connection are the only rds_info_* structs in include/uapi/linux/rds.h that are not marked __attribute__((packed)), so they have a real alignment hole. The other info visitors (rds_conn_info_visitor, rds6_conn_info_visitor, rds_tcp_tc_info, ...) write all fields of their packed output struct today and are not known to be vulnerable, but a future visitor that adds a conditional write-path would have the same bug. Reproduction on a kernel built without CONFIG_INIT_STACK_ALL_ZERO=y: a local unprivileged user opens AF_RDS, sets SO_RDS_TRANSPORT=IB, binds to a local address on an RDMA-capable netdev (rxe soft-RoCE on any netdev is sufficient), sendto()'s any peer on the same subnet (fails cleanly but installs an rds_connection in the global hash in RDS_CONN_CONNECTING), then calls getsockopt(SOL_RDS, RDS_INFO_IB_CONNECTIONS). The returned 68-byte item contains 26 bytes of stack garbage including kernel text/data pointers: 0..7 0a 63 00 01 0a 63 00 02 src=10.99.0.1 dst=10.99.0.2 8..39 00 ... gids (memset-zeroed) 40..47 e0 92 a3 81 ff ff ff ff kernel pointer (max_send_wr) 48..55 7f 37 b5 81 ff ff ff ff kernel pointer (rdma_mr_max) 56..59 01 00 08 00 rdma_mr_size (garbage) 60..61 00 00 tos, sl 62..63 00 00 alignment padding 64..67 18 00 00 00 cache_allocs (garbage) Fix by zeroing the per-item buffer in both rds_for_each_conn_info() and rds_walk_conn_path_info() before invoking the visitor. This covers the IPv4/IPv6 IB visitors and hardens all current and future visitors against the same class of bug. No functional change for visitors that fully populate their output. Changes in v2: - retarget at the net tree (subject prefix "[PATCH net v2]", net/rds: prefix in the title) - pick up Reviewed-by tags from Sharath Srinivasan and Allison Henderson Fixes: ec16227e1414 ("RDS/IB: Infiniband transport") Signed-off-by: Michael Bommarito Reviewed-by: Sharath Srinivasan Reviewed-by: Allison Henderson Assisted-by: Claude:claude-opus-4-7 Link: https://patch.msgid.link/20260418141047.3398203-1-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1269a7d38577efedec57f17a4c5b6e2d59548fa0 Author: Vikas Gupta Date: Sat Apr 18 08:04:38 2026 +0530 bnge: remove unsupported backing store type [ Upstream commit c6b34add67a5402f53359580956b5c318965a893 ] The backing store type, BNGE_CTX_MRAV, is not applicable in Thor Ultra devices. Remove it from the backing store configuration, as the firmware will not populate entities in this backing store type, due to which the driver load fails. Fixes: 29c5b358f385 ("bng_en: Add backing store support") Signed-off-by: Vikas Gupta Reviewed-by: Dharmender Garg Link: https://patch.msgid.link/20260418023438.1597876-3-vikas.gupta@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a2b26c4ade3ead6a2c0c3f9f04ac7ef979b5ab1b Author: Vikas Gupta Date: Sat Apr 18 08:04:37 2026 +0530 bnge: fix initial HWRM sequence [ Upstream commit 70d7c905a07ae8415b955569620bf2bf77423553 ] Firmware may not advertize correct resources if backing store is not enabled before resource information is queried. Fix the initial sequence of HWRMs so that driver gets capabilities and resource information correctly. Fixes: 3fa9e977a0cd ("bng_en: Initialize default configuration") Signed-off-by: Vikas Gupta Reviewed-by: Rahul Gupta Link: https://patch.msgid.link/20260418023438.1597876-2-vikas.gupta@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 20e3b61e21c7c29e1ffe9c5b873822b1e55e4333 Author: Kohei Enju Date: Mon Apr 20 10:54:23 2026 +0000 net: validate skb->napi_id in RX tracepoints [ Upstream commit 3bfcf396081ace536733b454ff128d53116581e5 ] Since commit 2bd82484bb4c ("xps: fix xps for stacked devices"), skb->napi_id shares storage with sender_cpu. RX tracepoints using net_dev_rx_verbose_template read skb->napi_id directly and can therefore report sender_cpu values as if they were NAPI IDs. For example, on the loopback path this can report 1 as napi_id, where 1 comes from raw_smp_processor_id() + 1 in the XPS path: # bpftrace -e 'tracepoint:net:netif_rx_entry{ print(args->napi_id); }' # taskset -c 0 ping -c 1 ::1 Report only valid NAPI IDs in these tracepoints and use 0 otherwise. Fixes: 2bd82484bb4c ("xps: fix xps for stacked devices") Signed-off-by: Kohei Enju Reviewed-by: Simon Horman Reviewed-by: Jiayuan Chen Link: https://patch.msgid.link/20260420105427.162816-1-kohei@enjuk.jp Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2cc8a4db633b10715450b291c1343859a4b2c509 Author: Hyunwoo Kim Date: Tue Apr 21 00:31:47 2026 +0900 ksmbd: scope conn->binding slowpath to bound sessions only [ Upstream commit b0da97c034b6107d14e537e212d4ce8b22109a58 ] When the binding SESSION_SETUP sets conn->binding = true, the flag stays set after the call so that the global session lookup in ksmbd_session_lookup_all() can find the session, which was not added to conn->sessions. Because the flag is connection-wide, the global lookup path will also resolve any other session by id if asked. Tighten the global lookup so that the returned session must have this connection registered in its channel xarray (sess->ksmbd_chann_list). The channel entry is installed by the existing binding_session path in ntlm_authenticate()/krb5_authenticate() when a SESSION_SETUP completes successfully, so this condition is a strict equivalent of "this connection has been accepted as a channel of this session". Connections that have not bound to a given session cannot reach it via the global table. The existing conn->binding gate for entering the slowpath is preserved so that non-binding connections keep the fast-path-only behavior, and the session->state check is unchanged. Fixes: f5a544e3bab7 ("ksmbd: add support for SMB3 multichannel") Signed-off-by: Hyunwoo Kim Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 06f709d0e531f3e54d88665dd426be3998a774e6 Author: DaeMyung Kang Date: Tue Apr 21 03:45:11 2026 +0900 ksmbd: fix durable fd leak on ClientGUID mismatch in durable v2 open [ Upstream commit 804054d19886ac6628883d82410f6ee42a818664 ] ksmbd_lookup_fd_cguid() returns a ksmbd_file with its refcount incremented via ksmbd_fp_get(). parse_durable_handle_context() in the DURABLE_REQ_V2 case properly releases this reference on every path inside the ClientGUID-match branch, either by calling ksmbd_put_durable_fd() or by transferring ownership to dh_info->fp for a successful reconnect. However, when an entry exists in the global file table with the same CreateGuid but a different ClientGUID, the code simply falls through to the new-open path without dropping the reference obtained from ksmbd_lookup_fd_cguid(). Per MS-SMB2 section 3.3.5.9.10 ("Handling the SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2 Create Context"), the server MUST locate an Open whose Open.CreateGuid matches the request's CreateGuid AND whose Open.ClientGuid matches the ClientGuid of the connection that received the request. If no such Open is found, the server MUST continue with the normal open execution phase. A CreateGuid hit with a ClientGUID mismatch is therefore the "Open not found" case: proceeding with a new open is correct, but the reference obtained purely as a side effect of the lookup must not be leaked. Repeated requests that hit this mismatch pin global_ft entries, prevent __ksmbd_close_fd() from ever running for the corresponding files, and defeat the durable scavenger, leading to long-lived resource leaks. Release the reference in the mismatch path and clear dh_info->fp so subsequent logic does not mistake a non-matching lookup result for a reconnect target. Fixes: c8efcc786146 ("ksmbd: add support for durable handles v1/v2") Signed-off-by: DaeMyung Kang Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 9c3936515a523406410279e0c9c05a26eeb0cf81 Author: DaeMyung Kang Date: Sun Apr 19 20:02:55 2026 +0900 ksmbd: destroy async_ida in ksmbd_conn_free() [ Upstream commit b32c8db48212a34998c36d0bbc05b29d5c407ef5 ] When per-connection async_ida was converted from a dynamically allocated ksmbd_ida to an embedded struct ida, ksmbd_ida_free() was removed from the connection teardown path but no matching ida_destroy() was added. The connection is therefore freed with the IDA's backing xarray still intact. The kernel IDA API expects ida_init() and ida_destroy() to be paired over an object's lifetime, so add the missing cleanup before the connection is freed. No leak has been observed in testing; this is a pairing fix to match the IDA lifetime rules, not a response to a reproduced regression. Fixes: d40012a83f87 ("cifsd: declare ida statically") Signed-off-by: DaeMyung Kang Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 6237cc0f7a4cf74daf33e1f559298d344cc42a60 Author: DaeMyung Kang Date: Sun Apr 19 20:02:54 2026 +0900 ksmbd: destroy tree_conn_ida in ksmbd_session_destroy() [ Upstream commit c049ee14eb4343b69b6f7755563f961f5e153423 ] When per-session tree_conn_ida was converted from a dynamically allocated ksmbd_ida to an embedded struct ida, ksmbd_ida_free() was removed from ksmbd_session_destroy() but no matching ida_destroy() was added. The session is therefore freed with the IDA's backing xarray still intact. The kernel IDA API expects ida_init() and ida_destroy() to be paired over an object's lifetime, so add the missing cleanup before the enclosing session is freed. Also move ida_init() to right after the session is allocated so that it is always paired with the destroy call even on the early error paths of __session_create() (ksmbd_init_file_table() or __init_smb2_session() failures), both of which jump to the error label and invoke ksmbd_session_destroy() on a partially initialised session. No leak has been observed in testing; this is a pairing fix to match the IDA lifetime rules, not a response to a reproduced regression. Fixes: d40012a83f87 ("cifsd: declare ida statically") Signed-off-by: DaeMyung Kang Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 9c59c79788e89055c07e23a10e0ef431c7996850 Author: Sangyun Kim Date: Sun Apr 19 17:08:38 2026 +0900 pwm: atmel-tcb: Cache clock rates and mark chip as atomic [ Upstream commit 68637b68afcc3cb4d56aca14a3a1d1b47b879369 ] atmel_tcb_pwm_apply() holds tcbpwmc->lock as a spinlock via guard(spinlock)() and then calls atmel_tcb_pwm_config(), which calls clk_get_rate() twice. clk_get_rate() acquires clk_prepare_lock (a mutex), so this is a sleep-in-atomic-context violation. On CONFIG_DEBUG_ATOMIC_SLEEP kernels every pwm_apply_state() that enables or reconfigures the PWM triggers a "BUG: sleeping function called from invalid context" warning. Acquire exclusive control over the clock rates with clk_rate_exclusive_get() at probe time and cache the rates in struct atmel_tcb_pwm_chip, then read the cached rates from atmel_tcb_pwm_config(). This keeps the spinlock-based mutual exclusion introduced in commit 37f7707077f5 ("pwm: atmel-tcb: Fix race condition and convert to guards") and removes the sleeping calls from the atomic section. With no sleeping calls left in .apply() and the regmap-mmio bus already running with fast_io=true, also mark the chip as atomic so consumers can use pwm_apply_atomic() from atomic context. Fixes: 37f7707077f5 ("pwm: atmel-tcb: Fix race condition and convert to guards") Signed-off-by: Sangyun Kim Link: https://patch.msgid.link/20260419080838.3192357-1-sangyun.kim@snu.ac.kr [ukleinek: Ensure .clk is enabled before calling clk_get_rate on it.] Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit 83cc775fc8fd770148dbdba11c0d1d0c62f36892 Author: Jun Yan Date: Mon Mar 30 22:51:11 2026 +0800 arm64: dts: meson-gxl-p230: fix ethernet PHY interrupt number [ Upstream commit 174a0ef3b33434f475c87e66f37980e39b73805a ] Correct the interrupt number assigned to the Realtek PHY in the p230 following the same logic as commit 3106507e1004 ("ARM64: dts: meson-gxm: fix q200 interrupt number"),as reported in [PATCH 0/2] Ethernet PHY interrupt improvements [1]. [1] https://lore.kernel.org/all/20171202214037.17017-1-martin.blumenstingl@googlemail.com/ Fixes: b94d22d94ad2 ("ARM64: dts: meson-gx: add external PHY interrupt on some platforms") Signed-off-by: Jun Yan Reviewed-by: Martin Blumenstingl Link: https://patch.msgid.link/20260330145111.115318-1-jerrysteve1101@gmail.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 3a6dfd9f2cdb9f070ea867e22f05b725117ae987 Author: Anand Moon Date: Thu Feb 19 16:05:46 2026 +0530 arm64: dts: amlogic: meson-axg: Add missing cache information to cpu0 [ Upstream commit 918273be0885362a9a00615b46e03f15f8b55667 ] Add missing L1 data and instruction cache parameters to the CPU node 0 for the Cortex-A53 caches on the Meson AXG SoC. Fixes: 3b6ad2a43367 ("arm64: dts: amlogic: Add cache information to the Amlogic AXG SoCS") Signed-off-by: Anand Moon Link: https://patch.msgid.link/20260219103548.18392-1-linux.amoon@gmail.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 86cf2eba2056bcf9c41fba260e599bd95bf9943b Author: Chia-Yu Chang Date: Fri Apr 17 17:25:51 2026 +0200 net/sched: sch_dualpi2: drain both C-queue and L-queue in dualpi2_change() [ Upstream commit 478ed6b7d2577439c610f91fa8759a4c878a4264 ] Fix dualpi2_change() to correctly enforce updated limit and memlimit values after a configuration change of the dualpi2 qdisc. Before this patch, dualpi2_change() always attempted to dequeue packets via the root qdisc (C-queue) when reducing backlog or memory usage, and unconditionally assumed that a valid skb will be returned. When traffic classification results in packets being queued in the L-queue while the C-queue is empty, this leads to a NULL skb dereference during limit or memlimit enforcement. This is fixed by first dequeuing from the C-queue path if it is non-empty. Once the C-queue is empty, packets are dequeued directly from the L-queue. Return values from qdisc_dequeue_internal() are checked for both queues. When dequeuing from the L-queue, the parent qdisc qlen and backlog counters are updated explicitly to keep overall qdisc statistics consistent. Fixes: 320d031ad6e4 ("sched: Struct definition and parsing of dualpi2 qdisc") Reported-by: "Kito Xu (veritas501)" Closes: https://lore.kernel.org/netdev/20260413075740.2234828-1-hxzene@gmail.com/ Signed-off-by: Chia-Yu Chang Link: https://patch.msgid.link/20260417152551.71648-1-chia-yu.chang@nokia-bell-labs.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 0511ecb00e61bf28e2fec4bb41fcce385c3a3b2d Author: Weiming Shi Date: Thu Apr 16 18:01:51 2026 +0800 slip: bound decode() reads against the compressed packet length [ Upstream commit 4c1367a2d7aad643a6f87c6931b13cc1a25e8ca7 ] slhc_uncompress() parses a VJ-compressed TCP header by advancing a pointer through the packet via decode() and pull16(). Neither helper bounds-checks against isize, and decode() masks its return with & 0xffff so it can never return the -1 that callers test for -- those error paths are dead code. A short compressed frame whose change byte requests optional fields lets decode() read past the end of the packet. The over-read bytes are folded into the cached cstate and reflected into subsequent reconstructed packets. Make decode() and pull16() take the packet end pointer and return -1 when exhausted. Add a bounds check before the TCP-checksum read. The existing == -1 tests now do what they were always meant to. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Simon Horman Closes: https://lore.kernel.org/netdev/20260414134126.758795-2-horms@kernel.org/ Signed-off-by: Weiming Shi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260416100147.531855-5-bestswngs@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 9e1ff0eead073c4f46d874ad2526b7dda5465faf Author: Weiming Shi Date: Thu Apr 16 04:41:31 2026 +0800 slip: reject VJ receive packets on instances with no rstate array [ Upstream commit e76607442d5b73e1ba6768f501ef815bb58c2c0e ] slhc_init() accepts rslots == 0 as a valid configuration, with the documented meaning of 'no receive compression'. In that case the allocation loop in slhc_init() is skipped, so comp->rstate stays NULL and comp->rslot_limit stays 0 (from the kzalloc of struct slcompress). The receive helpers do not defend against that configuration. slhc_uncompress() dereferences comp->rstate[x] when the VJ header carries an explicit connection ID, and slhc_remember() later assigns cs = &comp->rstate[...] after only comparing the packet's slot number to comp->rslot_limit. Because rslot_limit is 0, slot 0 passes the range check, and the code dereferences a NULL rstate. The configuration is reachable in-tree through PPP. PPPIOCSMAXCID stores its argument in a signed int, and (val >> 16) uses arithmetic shift. Passing 0xffff0000 therefore sign-extends to -1, so val2 + 1 is 0 and ppp_generic.c ends up calling slhc_init(0, 1). Because /dev/ppp open is gated by ns_capable(CAP_NET_ADMIN), the whole path is reachable from an unprivileged user namespace. Once the malformed VJ state is installed, any inbound VJ-compressed or VJ-uncompressed frame that selects slot 0 crashes the kernel in softirq context: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:slhc_uncompress (drivers/net/slip/slhc.c:519) Call Trace: ppp_receive_nonmp_frame (drivers/net/ppp/ppp_generic.c:2466) ppp_input (drivers/net/ppp/ppp_generic.c:2359) ppp_async_process (drivers/net/ppp/ppp_async.c:492) tasklet_action_common (kernel/softirq.c:926) handle_softirqs (kernel/softirq.c:623) run_ksoftirqd (kernel/softirq.c:1055) smpboot_thread_fn (kernel/smpboot.c:160) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:164) Reject the receive side on such instances instead of touching rstate. slhc_uncompress() falls through to its existing 'bad' label, which bumps sls_i_error and enters the toss state. slhc_remember() mirrors that with an explicit sls_i_error increment followed by slhc_toss(); the sls_i_runt counter is not used here because a missing rstate is an internal configuration state, not a runt packet. The transmit path is unaffected: the only in-tree caller that picks rslots from userspace (ppp_generic.c) still supplies tslots >= 1, and slip.c always calls slhc_init(16, 16), so comp->tstate remains valid and slhc_compress() continues to work. Fixes: 4ab42d78e37a ("ppp, slip: Validate VJ compression slot parameters completely") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260415204130.258866-2-bestswngs@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 79b90a96688e521771fa6ed3dc7864b76b8df293 Author: Fernando Fernandez Mancera Date: Fri Apr 17 18:20:57 2026 +0200 netfilter: nfnetlink_osf: fix potential NULL dereference in ttl check [ Upstream commit 711987ba281fd806322a7cd244e98e2a81903114 ] The nf_osf_ttl() function accessed skb->dev to perform a local interface address lookup without verifying that the device pointer was valid. Additionally, the implementation utilized an in_dev_for_each_ifa_rcu loop to match the packet source address against local interface addresses. It assumed that packets from the same subnet should not see a decrement on the initial TTL. A packet might appear it is from the same subnet but it actually isn't especially in modern environments with containers and virtual switching. Remove the device dereference and interface loop. Replace the logic with a switch statement that evaluates the TTL according to the ttl_check. Fixes: 11eeef41d5f6 ("netfilter: passive OS fingerprint xtables match") Reported-by: Kito Xu (veritas501) Closes: https://lore.kernel.org/netfilter-devel/20260414074556.2512750-1-hxzene@gmail.com/ Signed-off-by: Fernando Fernandez Mancera Reviewed-by: Pablo Neira Ayuso Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 21883587593d7c8bb519a79460a0b5bc5ffbdabd Author: Fernando Fernandez Mancera Date: Fri Apr 17 18:20:56 2026 +0200 netfilter: nfnetlink_osf: fix out-of-bounds read on option matching [ Upstream commit f5ca450087c3baf3651055e7a6de92600f827af3 ] In nf_osf_match(), the nf_osf_hdr_ctx structure is initialized once and passed by reference to nf_osf_match_one() for each fingerprint checked. During TCP option parsing, nf_osf_match_one() advances the shared ctx->optp pointer. If a fingerprint perfectly matches, the function returns early without restoring ctx->optp to its initial state. If the user has configured NF_OSF_LOGLEVEL_ALL, the loop continues to the next fingerprint. However, because ctx->optp was not restored, the next call to nf_osf_match_one() starts parsing from the end of the options buffer. This causes subsequent matches to read garbage data and fail immediately, making it impossible to log more than one match or logging incorrect matches. Instead of using a shared ctx->optp pointer, pass the context as a constant pointer and use a local pointer (optp) for TCP option traversal. This makes nf_osf_match_one() strictly stateless from the caller's perspective, ensuring every fingerprint check starts at the correct option offset. Fixes: 1a6a0951fc00 ("netfilter: nfnetlink_osf: add missing fmatch check") Suggested-by: Florian Westphal Signed-off-by: Fernando Fernandez Mancera Reviewed-by: Pablo Neira Ayuso Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 5b73746bd85f3a64c391973763aed0b3ff46f109 Author: Yingnan Zhang <342144303@qq.com> Date: Wed Apr 15 22:40:29 2026 +0800 ipvs: fix MTU check for GSO packets in tunnel mode [ Upstream commit 67bf42cae41d847fd6e5749eb68278ca5d748b25 ] Currently, IPVS skips MTU checks for GSO packets by excluding them with the !skb_is_gso(skb) condition. This creates problems when IPVS tunnel mode encapsulates GSO packets with IPIP headers. The issue manifests in two ways: 1. MTU violation after encapsulation: When a GSO packet passes through IPVS tunnel mode, the original MTU check is bypassed. After adding the IPIP tunnel header, the packet size may exceed the outgoing interface MTU, leading to unexpected fragmentation at the IP layer. 2. Fragmentation with problematic IP IDs: When net.ipv4.vs.pmtu_disc=1 and a GSO packet with multiple segments is fragmented after encapsulation, each segment gets a sequentially incremented IP ID (0, 1, 2, ...). This happens because: a) The GSO packet bypasses MTU check and gets encapsulated b) At __ip_finish_output, the oversized GSO packet is split into separate SKBs (one per segment), with IP IDs incrementing c) Each SKB is then fragmented again based on the actual MTU This sequential IP ID allocation differs from the expected behavior and can cause issues with fragment reassembly and packet tracking. Fix this by properly validating GSO packets using skb_gso_validate_network_len(). This function correctly validates whether the GSO segments will fit within the MTU after segmentation. If validation fails, send an ICMP Fragmentation Needed message to enable proper PMTU discovery. Fixes: 4cdd34084d53 ("netfilter: nf_conntrack_ipv6: improve fragmentation handling") Signed-off-by: Yingnan Zhang <342144303@qq.com> Acked-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 32fdd2e38e7435a368d88f5977a7d6585ebc8b0e Author: Pablo Neira Ayuso Date: Wed Apr 15 17:29:45 2026 +0200 netfilter: nat: use kfree_rcu to release ops [ Upstream commit 6eda0d771f94267f73f57c94630aa47e90957915 ] Florian Westphal says: "Historically this is not an issue, even for normal base hooks: the data path doesn't use the original nf_hook_ops that are used to register the callbacks. However, in v5.14 I added the ability to dump the active netfilter hooks from userspace. This code will peek back into the nf_hook_ops that are available at the tail of the pointer-array blob used by the datapath. The nat hooks are special, because they are called indirectly from the central nat dispatcher hook. They are currently invisible to the nfnl hook dump subsystem though. But once that changes the nat ops structures have to be deferred too." Update nf_nat_register_fn() to deal with partial exposition of the hooks from error path which can be also an issue for nfnetlink_hook. Fixes: e2cf17d3774c ("netfilter: add new hook nfnl subsystem") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 76160e04440c9698b989dbd9492a7ec4f520c9ee Author: Pablo Neira Ayuso Date: Wed Apr 15 12:21:00 2026 +0200 netfilter: xtables: restrict several matches to inet family [ Upstream commit b6fe26f86a1649f84e057f3f15605b08eda15497 ] This is a partial revert of: commit ab4f21e6fb1c ("netfilter: xtables: use NFPROTO_UNSPEC in more extensions") to allow ipv4 and ipv6 only. - xt_mac - xt_owner - xt_physdev These extensions are not used by ebtables in userspace. Moreover, xt_realm is only for ipv4, since dst->tclassid is ipv4 specific. Fixes: ab4f21e6fb1c ("netfilter: xtables: use NFPROTO_UNSPEC in more extensions") Reported-by: "Kito Xu (veritas501)" Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 8e3be0d12615a173fe260cd42753ca7a001acbf2 Author: Florian Westphal Date: Tue Apr 14 19:13:46 2026 +0200 netfilter: conntrack: remove sprintf usage [ Upstream commit 6e7066bdb481a87fe88c4fa563e348c03b2d373d ] Replace it with scnprintf, the buffer sizes are expected to be large enough to hold the result, no need for snprintf+overflow check. Increase buffer size in mangle_content_len() while at it. BUG: KASAN: stack-out-of-bounds in vsnprintf+0xea5/0x1270 Write of size 1 at addr [..] vsnprintf+0xea5/0x1270 sprintf+0xb1/0xe0 mangle_content_len+0x1ac/0x280 nf_nat_sdp_session+0x1cc/0x240 process_sdp+0x8f8/0xb80 process_invite_request+0x108/0x2b0 process_sip_msg+0x5da/0xf50 sip_help_tcp+0x45e/0x780 nf_confirm+0x34d/0x990 [..] Fixes: 9fafcd7b2032 ("[NETFILTER]: nf_conntrack/nf_nat: add SIP helper port") Reported-by: Yiming Qian Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit fb965b1cfe92b28d28b5ebe3116b81dbef9f2d2f Author: Xiang Mei Date: Tue Apr 14 15:14:01 2026 -0700 netfilter: nfnetlink_osf: fix divide-by-zero in OSF_WSS_MODULO [ Upstream commit 2195574dc6d9017d32ac346987e12659f931d932 ] nf_osf_match_one() computes ctx->window % f->wss.val in the OSF_WSS_MODULO branch with no guard for f->wss.val == 0. A CAP_NET_ADMIN user can add such a fingerprint via nfnetlink; a subsequent matching TCP SYN divides by zero and panics the kernel. Reject the bogus fingerprint in nfnl_osf_add_callback() above the per-option for-loop. f->wss is per-fingerprint, not per-option, so the check must run regardless of f->opt_num (including 0). Also reject wss.wc >= OSF_WSS_MAX; nf_osf_match_one() already treats that as "should not happen". Crash: Oops: divide error: 0000 [#1] SMP KASAN NOPTI RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98) Call Trace: nf_osf_match (net/netfilter/nfnetlink_osf.c:220) xt_osf_match_packet (net/netfilter/xt_osf.c:32) ipt_do_table (net/ipv4/netfilter/ip_tables.c:348) nf_hook_slow (net/netfilter/core.c:622) ip_local_deliver (net/ipv4/ip_input.c:265) ip_rcv (include/linux/skbuff.h:1162) __netif_receive_skb_one_core (net/core/dev.c:6181) process_backlog (net/core/dev.c:6642) __napi_poll (net/core/dev.c:7710) net_rx_action (net/core/dev.c:7945) handle_softirqs (kernel/softirq.c:622) Fixes: 11eeef41d5f6 ("netfilter: passive OS fingerprint xtables match") Reported-by: Weiming Shi Suggested-by: Florian Westphal Suggested-by: Pablo Neira Ayuso Signed-off-by: Xiang Mei Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 6e9038e7b394569ad7e4faa6dc549563ae862a36 Author: Pablo Neira Ayuso Date: Tue Apr 14 13:06:38 2026 +0200 netfilter: nft_osf: restrict it to ipv4 [ Upstream commit b336fdbb7103fb1484e1dcb6741151d4b5a41e35 ] This expression only supports for ipv4, restrict it. Fixes: b96af92d6eaf ("netfilter: nf_tables: implement Passive OS fingerprint module in nft_osf") Acked-by: Florian Westphal Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 8d298ece6db710005abf8b28a698490e11397a9c Author: Lorenzo Bianconi Date: Thu Apr 16 12:30:12 2026 +0200 net: airoha: Fix possible TX queue stall in airoha_qdma_tx_napi_poll() [ Upstream commit b94769eb2f30e61e86cd8551c084c34134290d89 ] Since multiple net_device TX queues can share the same hw QDMA TX queue, there is no guarantee we have inflight packets queued in hw belonging to a net_device TX queue stopped in the xmit path because hw QDMA TX queue can be full. In this corner case the net_device TX queue will never be re-activated. In order to avoid any potential net_device TX queue stall, we need to wake all the net_device TX queues feeding the same hw QDMA TX queue in airoha_qdma_tx_napi_poll routine. Fixes: 23020f0493270 ("net: airoha: Introduce ethernet support for EN7581 SoC") Signed-off-by: Lorenzo Bianconi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260416-airoha-txq-potential-stall-v2-1-42c732074540@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fa6e90bc443bed8dc0d55bc5ea5b27ffdfe37704 Author: Weiming Shi Date: Wed Apr 15 19:46:54 2026 -0700 openvswitch: cap upcall PID array size and pre-size vport replies [ Upstream commit 2091c6aa0df6aba47deb5c8ab232b1cb60af3519 ] The vport netlink reply helpers allocate a fixed-size skb with nlmsg_new(NLMSG_DEFAULT_SIZE, ...) but serialize the full upcall PID array via ovs_vport_get_upcall_portids(). Since ovs_vport_set_upcall_portids() accepts any non-zero multiple of sizeof(u32) with no upper bound, a CAP_NET_ADMIN user can install a PID array large enough to overflow the reply buffer, causing nla_put() to fail with -EMSGSIZE and hitting BUG_ON(err < 0). On systems with unprivileged user namespaces enabled (e.g., Ubuntu default), this is reachable via unshare -Urn since OVS vport mutation operations use GENL_UNS_ADMIN_PERM. kernel BUG at net/openvswitch/datapath.c:2414! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 65 Comm: poc Not tainted 7.0.0-rc7-00195-geb216e422044 #1 RIP: 0010:ovs_vport_cmd_set+0x34c/0x400 Call Trace: genl_family_rcv_msg_doit (net/netlink/genetlink.c:1116) genl_rcv_msg (net/netlink/genetlink.c:1194) netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Kernel panic - not syncing: Fatal exception Reject attempts to set more PIDs than nr_cpu_ids in ovs_vport_set_upcall_portids(), and pre-compute the worst-case reply size in ovs_vport_cmd_msg_size() based on that bound, similar to the existing ovs_dp_cmd_msg_size(). nr_cpu_ids matches the cap already used by the per-CPU dispatch configuration on the datapath side (ovs_dp_cmd_fill_info() serialises at most nr_cpu_ids PIDs), so the two sides stay consistent. Fixes: 5cd667b0a456 ("openvswitch: Allow each vport to have an array of 'port_id's.") Reported-by: Xiang Mei Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Weiming Shi Reviewed-by: Ilya Maximets Link: https://patch.msgid.link/20260416024653.153456-2-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d17830d050f7f051f8a0167ae28e9e1ad8a6a454 Author: Prathamesh Deshpande Date: Wed Apr 15 01:49:37 2026 +0100 net/mlx5: Fix HCA caps leak on notifier init failure [ Upstream commit d03fc81a57956248383efec99967d0ae627390a8 ] mlx5_mdev_init() allocates HCA caps via mlx5_hca_caps_alloc() before calling mlx5_notifiers_init(). If notifier initialization fails, the error path jumps to err_hca_caps and skips mlx5_hca_caps_free(), leaking allocated caps. Add a dedicated unwind label for notifier-init failure that frees HCA caps before continuing the existing cleanup sequence. Fixes: b6b03097f982 ("net/mlx5: Initialize events outside devlink lock") Signed-off-by: Prathamesh Deshpande Reviewed-by: Cosmin Ratiu Reviewed-by: Tariq Toukan Link: https://patch.msgid.link/20260415005022.34764-1-prathameshdeshpande7@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0cab5d077dd1efd2bd1a47271acc35894f945b4f Author: Qingfang Deng Date: Wed Apr 15 10:24:51 2026 +0800 pppoe: drop PFC frames [ Upstream commit cc1ff87bce1ccd38410ab10960f576dcd17db679 ] RFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOT RECOMMENDED for PPPoE. In practice, pppd does not support negotiating PFC for PPPoE sessions, and the current PPPoE driver assumes an uncompressed (2-byte) protocol field. However, the generic PPP layer function ppp_input() is not aware of the negotiation result, and still accepts PFC frames. If a peer with a broken implementation or an attacker sends a frame with a compressed (1-byte) protocol field, the subsequent PPP payload is shifted by one byte. This causes the network header to be 4-byte misaligned, which may trigger unaligned access exceptions on some architectures. To reduce the attack surface, drop PPPoE PFC frames. Introduce ppp_skb_is_compressed_proto() helper function to be used in both ppp_generic.c and pppoe.c to avoid open-coding. Fixes: 7fb1b8ca8fa1 ("ppp: Move PFC decompression to PPP generic layer") Signed-off-by: Qingfang Deng Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260415022456.141758-2-qingfang.deng@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 70a089cc9590aa347a61e84434116ab74619e3c3 Author: Michael Bommarito Date: Wed Apr 15 23:19:03 2026 -0400 sctp: fix OOB write to userspace in sctp_getsockopt_peer_auth_chunks [ Upstream commit 0cf004ffb61cd32d140531c3a84afe975f9fc7ea ] sctp_getsockopt_peer_auth_chunks() checks that the caller's optval buffer is large enough for the peer AUTH chunk list with if (len < num_chunks) return -EINVAL; but then writes num_chunks bytes to p->gauth_chunks, which lives at offset offsetof(struct sctp_authchunks, gauth_chunks) == 8 inside optval. The check is missing the sizeof(struct sctp_authchunks) = 8-byte header. When the caller supplies len == num_chunks (for any num_chunks > 0) the test passes but copy_to_user() writes sizeof(struct sctp_authchunks) = 8 bytes past the declared buffer. The sibling function sctp_getsockopt_local_auth_chunks() at the next line already has the correct check: if (len < sizeof(struct sctp_authchunks) + num_chunks) return -EINVAL; Align the peer variant with its sibling. Reproducer confirms on v7.0-13-generic: an unprivileged userspace caller that opens a loopback SCTP association with AUTH enabled, queries num_chunks with a short optval, then issues the real getsockopt with len == num_chunks and sentinel bytes painted past the buffer observes those sentinel bytes overwritten with the peer's AUTH chunk type. The bytes written are under the peer's control but land in the caller's own userspace; this is not a kernel memory corruption, but it is a kernel-side contract violation that can silently corrupt adjacent userspace data. Fixes: 65b07e5d0d09 ("[SCTP]: API updates to suport SCTP-AUTH extensions.") Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Michael Bommarito Acked-by: Xin Long Link: https://patch.msgid.link/20260416031903.1447072-1-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7c66b368c6ff453f99cb39d84af93e908e51eef2 Author: Eric Dumazet Date: Thu Apr 16 10:35:05 2026 +0000 ipv6: fix possible UAF in icmpv6_rcv() [ Upstream commit f996edd7615e686ada141b7f3395025729ff8ccb ] Caching saddr and daddr before pskb_pull() is problematic since skb->head can change. Remove these temporary variables: - We only access &ipv6_hdr(skb)->saddr and &ipv6_hdr(skb)->daddr when net_dbg_ratelimited() is called in the slow path. - Avoid potential future misuse after pskb_pull() call. Fixes: 4b3418fba0fe ("ipv6: icmp: include addresses in debug messages") Signed-off-by: Eric Dumazet Reviewed-by: Fernando Fernandez Mancera Reviewed-by: Joe Damato Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260416103505.2380753-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d77baa6214b7ddf70aa6ae6840e466c1e283b82b Author: Matt Vollrath Date: Thu Apr 16 17:53:36 2026 -0700 e1000e: Unroll PTP in probe error handling [ Upstream commit aa3f7fe409350857c25d050482a2eef2cfd69b58 ] If probe fails after registering the PTP clock and its delayed work, these resources must be released. This was not an issue until a 2016 fix moved the e1000e_ptp_init() call before the jump to err_register. Fixes: aa524b66c5ef ("e1000e: don't modify SYSTIM registers during SIOCSHWTSTAMP ioctl") Signed-off-by: Matt Vollrath Tested-by: Avigail Dahan Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260416-iwl-net-submission-2026-04-14-v2-12-686c33c9828d@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 15c666a99626eb13889554d6df8ff90c54dff71c Author: Petr Oros Date: Thu Apr 16 17:53:34 2026 -0700 iavf: fix wrong VLAN mask for legacy Rx descriptors L2TAG2 [ Upstream commit 496d9f91062fa07956702e0f234c5203f03a974d ] The IAVF_RXD_LEGACY_L2TAG2_M mask was incorrectly defined as GENMASK_ULL(63, 32), extracting 32 bits from qw2 instead of the 16-bit VLAN tag. In the legacy Rx descriptor layout, the 2nd L2TAG2 (VLAN tag) occupies bits 63:48 of qw2, not 63:32. The oversized mask causes FIELD_GET to return a 32-bit value where the actual VLAN tag sits in bits 31:16. When this value is passed to iavf_receive_skb() as a u16 parameter, it gets truncated to the lower 16 bits (which contain the 1st L2TAG2, typically zero). As a result, __vlan_hwaccel_put_tag() is never called and software VLAN interfaces on VFs receive no traffic. This affects VFs behind ice PF (VIRTCHNL VLAN v2) when the PF advertises VLAN stripping into L2TAG2_2 and legacy descriptors are used. The flex descriptor path already uses the correct mask (IAVF_RXD_FLEX_L2TAG2_2_M = GENMASK_ULL(63, 48)). Reproducer: 1. Create 2 VFs on ice PF (echo 2 > sriov_numvfs) 2. Disable spoofchk on both VFs 3. Move each VF into a separate network namespace 4. On each VF: create VLAN interface (e.g. vlan 198), assign IP, bring up 5. Set rx-vlan-offload OFF on both VFs 6. Ping between VLAN interfaces -> expect PASS (VLAN tag stays in packet data, kernel matches in-band) 7. Set rx-vlan-offload ON on both VFs 8. Ping between VLAN interfaces -> expect FAIL if bug present (HW strips VLAN tag into descriptor L2TAG2 field, wrong mask extracts bits 47:32 instead of 63:48, truncated to u16 -> zero, __vlan_hwaccel_put_tag() never called, packet delivered to parent interface, not VLAN interface) The reproducer requires legacy Rx descriptors. On modern ice + iavf with full PTP support, flex descriptors are always negotiated and the buggy legacy path is never reached. Flex descriptors require all of: - CONFIG_PTP_1588_CLOCK enabled - VIRTCHNL_VF_OFFLOAD_RX_FLEX_DESC granted by PF - PTP capabilities negotiated (VIRTCHNL_VF_CAP_PTP) - VIRTCHNL_1588_PTP_CAP_RX_TSTAMP supported - VIRTCHNL_RXDID_2_FLEX_SQ_NIC present in DDP profile If any condition is not met, iavf_select_rx_desc_format() falls back to legacy descriptors (RXDID=1) and the wrong L2TAG2 mask is hit. Fixes: 2dc8e7c36d80 ("iavf: refactor iavf_clean_rx_irq to support legacy and flex descriptors") Signed-off-by: Petr Oros Reviewed-by: Aleksandr Loktionov Reviewed-by: Paul Menzel Reviewed-by: Jacob Keller Tested-by: Rafal Romanowski Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260416-iwl-net-submission-2026-04-14-v2-10-686c33c9828d@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3c29ddd46aba05b12801d07bed394f649e3e4cca Author: Kohei Enju Date: Thu Apr 16 17:53:33 2026 -0700 i40e: don't advertise IFF_SUPP_NOFCS [ Upstream commit a24162f18825684ad04e3a5d0531f8a50d679347 ] i40e advertises IFF_SUPP_NOFCS, allowing users to use the SO_NOFCS socket option. However, this option is silently ignored, as the driver does not check skb->no_fcs, and always enables FCS insertion offload. Fix this by removing the advertisement of IFF_SUPP_NOFCS. This behavior can be reproduced with a simple AF_PACKET socket: import socket s = socket.socket(socket.AF_PACKET, socket.SOCK_RAW) s.setsockopt(socket.SOL_SOCKET, 43, 1) # SO_NOFCS s.bind(("eth0", 0)) s.send(b'\xff' * 64) Previously, send() succeeds but the driver ignores SO_NOFCS. With this change, send() fails with -EPROTONOSUPPORT, as expected. Fixes: 41c445ff0f48 ("i40e: main driver core") Signed-off-by: Kohei Enju Reviewed-by: Aleksandr Loktionov Tested-by: Sunitha Mekala Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260416-iwl-net-submission-2026-04-14-v2-9-686c33c9828d@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3c5c3ac308a762bdb57d9267ede849d7c5e5ebde Author: Paul Greenwalt Date: Thu Apr 16 17:53:30 2026 -0700 ice: fix ICE_AQ_LINK_SPEED_M for 200G [ Upstream commit 4a3a940059e98539de293a6e36e464094c2e875b ] When setting PHY configuration during driver initialization, 200G link speed is not being advertised even when the PHY is capable. This is because the get PHY capabilities link speed response is being masked by ICE_AQ_LINK_SPEED_M, which does not include the 200G link speed bit. ICE_AQ_LINK_SPEED_200GB is defined as BIT(11), but the mask 0x7FF only covers bits 0-10. Fix ICE_AQ_LINK_SPEED_M to use GENMASK(11, 0) so that it covers all defined link speed bits including 200G. Fixes: 24407a01e57c ("ice: Add 200G speed/phy type use") Signed-off-by: Paul Greenwalt Signed-off-by: Aleksandr Loktionov Reviewed-by: Simon Horman Tested-by: Sunitha Mekala Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260416-iwl-net-submission-2026-04-14-v2-6-686c33c9828d@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7cb19ec8ac087f33bee60f5d6054b284a5b9bb6f Author: Michal Schmidt Date: Thu Apr 16 17:53:28 2026 -0700 ice: fix double-free of tx_buf skb [ Upstream commit 1a303baa715e6b78d6a406aaf335f87ff35acfcd ] If ice_tso() or ice_tx_csum() fail, the error path in ice_xmit_frame_ring() frees the skb, but the 'first' tx_buf still points to it and is marked as valid (ICE_TX_BUF_SKB). 'next_to_use' remains unchanged, so the potential problem will likely fix itself when the next packet is transmitted and the tx_buf gets overwritten. But if there is no next packet and the interface is brought down instead, ice_clean_tx_ring() -> ice_unmap_and_free_tx_buf() will find the tx_buf and free the skb for the second time. The fix is to reset the tx_buf type to ICE_TX_BUF_EMPTY in the error path, so that ice_unmap_and_free_tx_buf(). Move the initialization of 'first' up, to ensure it's already valid in case we hit the linearization error path. The bug was spotted by AI while I had it looking for something else. It also proposed an initial version of the patch. I reproduced the bug and tested the fix by adding code to inject failures, on a build with KASAN. I looked for similar bugs in related Intel drivers and did not find any. Fixes: d76a60ba7afb ("ice: Add support for VLANs and offloads") Assisted-by: Claude:claude-4.6-opus-high Cursor Signed-off-by: Michal Schmidt Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260416-iwl-net-submission-2026-04-14-v2-4-686c33c9828d@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 55500245ec0420df96b2a89444aabf0cff2c60bc Author: Alice Mikityanska Date: Thu Feb 5 15:39:20 2026 +0200 ice: Remove jumbo_remove step from TX path [ Upstream commit 8b76102c5e00d1f090e0c31d17b060c76d8fa859 ] Now that the kernel doesn't insert HBH for BIG TCP IPv6 packets, remove unnecessary steps from the ice TX path, that used to check and remove HBH. Signed-off-by: Alice Mikityanska Acked-by: Paolo Abeni Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260205133925.526371-8-alice.kernel@fastmail.im Signed-off-by: Jakub Kicinski Stable-dep-of: 1a303baa715e ("ice: fix double-free of tx_buf skb") Signed-off-by: Sasha Levin commit 05fd391f9065561bf8cab4307aac96f7338c6a9e Author: Grzegorz Nitka Date: Thu Apr 16 17:53:26 2026 -0700 ice: update PCS latency settings for E825 10G/25Gb modes [ Upstream commit 05567e4052732d70c7ff9655217b3d14d25f639a ] Update MAC Rx/Tx offset registers settings (PHY_MAC_[RX|TX]_OFFSET registers) with the data obtained with the latest research. It applies to PCS latency settings for the following speeds/modes: * 10Gb NO-FEC - TX latency changed from 71.25 ns to 73 ns - RX latency changed from -25.6 ns to -28 ns * 25Gb NO-FEC - TX latency changed from 28.17 ns to 33 ns - RX latency changed from -12.45 ns to -12 ns * 25Gb RS-FEC - TX latency changed from 64.5 ns to 69 ns - RX latency changed from -3.6 ns to -3 ns The original data came from simulation and pre-production hardware. The new data measures the actual delays and as such is more accurate. Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products") Co-developed-by: Zoltan Fodor Signed-off-by: Zoltan Fodor Reviewed-by: Aleksandr Loktionov Reviewed-by: Jacob Keller Signed-off-by: Grzegorz Nitka Tested-by: Sunitha Mekala Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260416-iwl-net-submission-2026-04-14-v2-2-686c33c9828d@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 722fcf831107ae25f258a4ec79263203dc3c3fd9 Author: Grzegorz Nitka Date: Thu Apr 16 17:53:25 2026 -0700 ice: fix 'adjust' timer programming for E830 devices [ Upstream commit 885c5e57924dc040b23d0ad0d8388f0e35772159 ] Fix incorrect 'adjust the timer' programming sequence for E830 devices series. Only shadow registers GLTSYN_SHADJ were programmed in the current implementation. According to the specification [1], write to command GLTSYN_CMD register is also required with CMD field set to "Adjust the Time" value, for the timer adjustment to take the effect. The flow was broken for the adjustment less than S32_MAX/MIN range (around +/- 2 seconds). For bigger adjustment, non-atomic programming flow is used, involving set timer programming. Non-atomic flow is implemented correctly. Testing hints: Run command: phc_ctl /dev/ptpX get adj 2 get Expected result: Returned timestamps differ at least by 2 seconds [1] Intel® Ethernet Controller E830 Datasheet rev 1.3, chapter 9.7.5.4 https://cdrdv2.intel.com/v1/dl/getContent/787353?explicitVersion=true Fixes: f00307522786 ("ice: Implement PTP support for E830 devices") Reviewed-by: Aleksandr Loktionov Signed-off-by: Grzegorz Nitka Reviewed-by: Simon Horman Tested-by: Rinitha S Reviewed-by: Jacob Keller Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260416-iwl-net-submission-2026-04-14-v2-1-686c33c9828d@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1b579c2001d06c00f4424c240b8f68f6f97950aa Author: Eric Dumazet Date: Thu Apr 16 20:03:19 2026 +0000 tcp: annotate data-races around tp->plb_rehash [ Upstream commit 9e89b9d03a2d2e30dcca166d5af52f9a8eceab25 ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() and WRITE_ONCE() annotations to keep KCSAN happy. Fixes: 29c1c44646ae ("tcp: add u32 counter in tcp_sock and an SNMP counter for PLB") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-15-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4d1ea8a2c6ac30d95948d1a02c77617d4f813418 Author: Eric Dumazet Date: Thu Apr 16 20:03:18 2026 +0000 tcp: annotate data-races around (tp->write_seq - tp->snd_nxt) [ Upstream commit 3a63b3d160560ef51e43fb4c880a5cde8078053c ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() annotations to keep KCSAN happy. WRITE_ONCE() annotations are already present. Fixes: e08ab0b377a1 ("tcp: add bytes not sent to SCM_TIMESTAMPING_OPT_STATS") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-14-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 37f33454b284ebfeccb8390c62a334df94ebdca2 Author: Eric Dumazet Date: Thu Apr 16 20:03:17 2026 +0000 tcp: annotate data-races around tp->timeout_rehash [ Upstream commit 71c675358b711bbfd8528949249419dc2dfa4ce1 ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() and WRITE_ONCE() annotations to keep KCSAN happy. Fixes: 32efcc06d2a1 ("tcp: export count for rehash attempts") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-13-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0edffaf11267c84d9c285886ec591da9f1d83faf Author: Eric Dumazet Date: Thu Apr 16 20:03:16 2026 +0000 tcp: annotate data-races around tp->srtt_us [ Upstream commit 290b693ce7c9d48588d88b15a782a3efc6fa036b ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() and WRITE_ONCE() annotations to keep KCSAN happy. Fixes: e8bd8fca6773 ("tcp: add SRTT to SCM_TIMESTAMPING_OPT_STATS") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-12-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cd6011dc4c339b83a853901d9772e8e07927ddc3 Author: Eric Dumazet Date: Mon Oct 13 14:59:26 2025 +0000 tcp: better handle TCP_TX_DELAY on established flows [ Upstream commit 1c51450f1afff1e7419797720df3fbd9ccbf610c ] Some applications uses TCP_TX_DELAY socket option after TCP flow is established. Some metrics need to be updated, otherwise TCP might take time to adapt to the new (emulated) RTT. This patch adjusts tp->srtt_us, tp->rtt_min, icsk_rto and sk->sk_pacing_rate. This is best effort, and for instance icsk_rto is reset without taking backoff into account. Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20251013145926.833198-1-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 290b693ce7c9 ("tcp: annotate data-races around tp->srtt_us") Signed-off-by: Sasha Levin commit 3955bfec74ab41925252951f2364fb7e4c2b2752 Author: Eric Dumazet Date: Thu Apr 16 20:03:15 2026 +0000 tcp: annotate data-races around tp->reord_seen [ Upstream commit 62585690e6b2a112c408fe25f142b246ac833c42 ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() and WRITE_ONCE() annotations to keep KCSAN happy. Fixes: 7ec65372ca53 ("tcp: add stat of data packet reordering events") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-11-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7fc9ef56acfe9d74f8d73b5a8b130200a37bcccb Author: Eric Dumazet Date: Thu Apr 16 20:03:14 2026 +0000 tcp: annotate data-races around tp->dsack_dups [ Upstream commit a984705ca88b976bf1087978fd98b7f3993da88c ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() and WRITE_ONCE() annotations to keep KCSAN happy. Fixes: 7e10b6554ff2 ("tcp: add dsack blocks received stats") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-10-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b208984309842b8c13d7a4ea8c872b9bfb172e07 Author: Eric Dumazet Date: Thu Apr 16 20:03:13 2026 +0000 tcp: annotate data-races around tp->bytes_retrans [ Upstream commit 5efc7b9f7cbd43401f1af81d3d7f2be00f93390d ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() and WRITE_ONCE() annotations to keep KCSAN happy. Fixes: fb31c9b9f6c8 ("tcp: add data bytes retransmitted stats") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-9-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d0ae38a0ee95441954137b4e4dde3f9493030269 Author: Eric Dumazet Date: Thu Apr 16 20:03:12 2026 +0000 tcp: annotate data-races around tp->bytes_sent [ Upstream commit ee43e957ce2ec77b2ec47fef28f3c0df6ab01a31 ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() and WRITE_ONCE() annotations to keep KCSAN happy. Fixes: ba113c3aa79a ("tcp: add data bytes sent stats") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-8-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5987cec30473c58f29df33625b9270ce2e5d88f6 Author: Eric Dumazet Date: Thu Apr 16 20:03:11 2026 +0000 tcp: add data-race annotations for TCP_NLA_SNDQ_SIZE [ Upstream commit 124199444de467767175a9004e1574dc42523e62 ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() and WRITE_ONCE() annotations to keep KCSAN happy. Fixes: 87ecc95d81d9 ("tcp: add send queue size stat in SCM_TIMESTAMPING_OPT_STATS") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-7-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4215a5c7b07981fcb5c59470797f4d0e8718474e Author: Eric Dumazet Date: Thu Apr 16 20:03:10 2026 +0000 tcp: annotate data-races around tp->delivered and tp->delivered_ce [ Upstream commit faa886ad3ce5fc8f5156493491fe189b2b726bc9 ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() and WRITE_ONCE() annotations to keep KCSAN happy. Fixes: feb5f2ec6464 ("tcp: export packets delivery info") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-6-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d8068252f0435938ccb36e24e9c07475e5dff381 Author: Eric Dumazet Date: Thu Apr 16 20:03:09 2026 +0000 tcp: annotate data-races around tp->snd_ssthresh [ Upstream commit fd571afb05ebaeac5d8f09460a0640d4cf6755f8 ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() and WRITE_ONCE() annotations to keep KCSAN happy. Fixes: 7156d194a077 ("tcp: add snd_ssthresh stat in SCM_TIMESTAMPING_OPT_STATS") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-5-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9bce4d9c6da13991d84e2dc1711f09cd39e4df02 Author: Eric Dumazet Date: Thu Apr 16 20:03:08 2026 +0000 tcp: add data-races annotations around tp->reordering, tp->snd_cwnd [ Upstream commit 829ba1f329cb7cbd56d599a6d225997fba66dc32 ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE(), WRITE_ONCE() data_race() annotations to keep KCSAN happy. Fixes: bb7c19f96012 ("tcp: add related fields into SCM_TIMESTAMPING_OPT_STATS") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-4-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9eb93126c0122c2c7a3b9c105a469934d6dec351 Author: Eric Dumazet Date: Thu Apr 16 20:03:07 2026 +0000 tcp: add data-race annotations around tp->data_segs_out and tp->total_retrans [ Upstream commit 21e92a38cfd891538598ba8f805e0165a820d532 ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() and WRITE_ONCE() annotations to keep KCSAN happy. Fixes: 7e98102f4897 ("tcp: record pkts sent and retransmistted") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2962660dc75af3bf9de4bf3171876c297a486e98 Author: Eric Dumazet Date: Thu Apr 16 20:03:06 2026 +0000 tcp: annotate data-races in tcp_get_info_chrono_stats() [ Upstream commit 267bf3cf9a6f0ffb98b8afd983c1950e835f07c9 ] tcp_get_timestamping_opt_stats() does not own the socket lock, this is intentional. It calls tcp_get_info_chrono_stats() while other threads could change chrono fields in tcp_chrono_set(). I do not think we need coherent TCP socket state snapshot in tcp_get_timestamping_opt_stats(), I chose to only add annotations to keep KCSAN happy. Fixes: 1c885808e456 ("tcp: SOF_TIMESTAMPING_OPT_STATS option for SO_TIMESTAMPING") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c67c9032ce565dabe8b12198a52bc0ea3bb6e2d3 Author: Eric Dumazet Date: Sun Mar 8 12:35:49 2026 +0000 tcp: inline tcp_chrono_start() [ Upstream commit d6d4ff335db2d9242937ca474d292010acd35c38 ] tcp_chrono_start() is small enough, and used in TCP sendmsg() fast path (from tcp_skb_entail()). Note clang is already inlining it from functions in tcp_output.c. Inlining it improves performance and reduces bloat : $ scripts/bloat-o-meter -t vmlinux.old vmlinux.new add/remove: 0/2 grow/shrink: 1/0 up/down: 1/-84 (-83) Function old new delta tcp_skb_entail 280 281 +1 __pfx_tcp_chrono_start 16 - -16 tcp_chrono_start 68 - -68 Total: Before=25192434, After=25192351, chg -0.00% Note that tcp_chrono_stop() is too big. Signed-off-by: Eric Dumazet Reviewed-by: Neal Cardwell Link: https://patch.msgid.link/20260308123549.2924460-1-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 267bf3cf9a6f ("tcp: annotate data-races in tcp_get_info_chrono_stats()") Signed-off-by: Sasha Levin commit 8e8a7c72a24f13a6854ef0f45acb96188eaeff43 Author: Eric Dumazet Date: Sun Mar 8 12:23:02 2026 +0000 tcp: move tp->chrono_type next tp->chrono_stat[] [ Upstream commit 4b78c9cbd8f1fbb9517aee48b372646f4cf05442 ] chrono_type is currently in tcp_sock_read_txrx group, which is supposed to hold read-mostly fields. But chrono_type is mostly written in tx path, it should be moved to tcp_sock_write_tx group, close to other chrono fields (chrono_stat[], chrono_start). Note this adds holes, but data locality is far more important. Use a full u8 for the time being, compiler can generate more efficient code. Signed-off-by: Eric Dumazet Reviewed-by: Neal Cardwell Link: https://patch.msgid.link/20260308122302.2895067-1-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 267bf3cf9a6f ("tcp: annotate data-races in tcp_get_info_chrono_stats()") Signed-off-by: Sasha Levin commit ce2e164c1c51c3f7813b80f8c926836e896bcbb3 Author: Akif Date: Fri Apr 17 23:57:09 2026 +0530 ksmbd: fix use-after-free in smb2_open during durable reconnect [ Upstream commit 1baff47b81f94f9231c91236aa511420d0e266b9 ] In smb2_open, the call to ksmbd_put_durable_fd(fp) drops the reference to the durable file descriptor early during the durable reconnect process. If an error occurs subsequently (eg, ksmbd_iov_pin_rsp fails) or a scavenger accesses the file, it leads to a use-after-free when accessing fp properties (eg fp->create_time). Move the single put to the end of the function below err_out2 so fp stays valid until smb2_open returns. Fixes: c8efcc786146 ("ksmbd: add support for durable handles v1/v2") Signed-off-by: Akif Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit ff3e8515c1d92994db1b777c7ccc2058ae8256e0 Author: ZhangGuoDong Date: Mon Oct 27 15:12:54 2025 +0800 smb: move smb_version_values to common/smbglob.h [ Upstream commit 34cf191bb6a349dc88ec2c4f6355fe006ac669e0 ] Merge the struct members of the server and the client: - req_capabilities: from client - header_preamble_size: from client - cap_unicode: from client - capabilities: from server, rename to req_capabilities - max_read_size: from server - max_write_size: from server - max_trans_size: from server - max_credits: from server - create_durable_size: from server - create_durable_v2_size: from server - create_mxac_size: from server - create_disk_id_size: from server - create_posix_size: from server Then move duplicate definitions to common header file. Co-developed-by: ChenXiaoSong Signed-off-by: ChenXiaoSong Signed-off-by: ZhangGuoDong Acked-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: 1baff47b81f9 ("ksmbd: fix use-after-free in smb2_open during durable reconnect") Signed-off-by: Sasha Levin commit 37c8933064be714ee672b0a0523c2fd045b73b3d Author: Wei Fang Date: Wed Apr 15 14:08:33 2026 +0800 net: enetc: fix NTMP DMA use-after-free issue [ Upstream commit 3cade698881eb238f88cbbfec82acc2110440a3f ] The AI-generated review reported a potential DMA use-after-free issue [1]. If netc_xmit_ntmp_cmd() times out and returns an error, the pending command is not explicitly aborted, while ntmp_free_data_mem() unconditionally frees the DMA buffer. If the buffer has already been reallocated elsewhere, this may lead to silent memory corruption. Because the hardware eventually processes the pending command and perform a DMA write of the response to the physical address of the freed buffer. To resolve this issue, this patch does the following modifications: 1. Convert cbdr->ring_lock from a spinlock to a mutex The lock was originally a spinlock in case NTMP operations might be invoked from atomic context. After downstream support for all NTMP tables, no such usage has materialized. A mutex lock is now required because the driver now needs to reclaim used BDs and release associated DMA memory within the lock's context, while dma_free_coherent() might sleep. 2. Introduce software command BD (struct netc_swcbd) The hardware write-back overwrites the addr and len fields of the BD, so the driver cannot rely on the hardware BD to free the associated DMA memory. The driver now maintains a software shadow BD storing the DMA buffer pointer, DMA address, and size. And netc_xmit_ntmp_cmd() only reclaims older BDs when the number of used BDs reaches NETC_CBDR_CLEAN_WORK (16). The software BD enables correct DMA memory release. With this, struct ntmp_dma_buf and ntmp_free_data_mem() are no longer needed and are removed. 3. Require callers to hold ring_lock across netc_xmit_ntmp_cmd() netc_xmit_ntmp_cmd() releases the ring_lock before the caller finishes consuming the response. At this point, if a concurrent thread submits a new command, it may trigger ntmp_clean_cbdr() and free the DMA buffer while it is still in use. Move ring_lock ownership to the caller to ensure the response buffer cannot be reclaimed prematurely. So the helpers ntmp_select_and_lock_cbdr() and ntmp_unlock_cbdr() are added. These changes eliminate the DMA use-after-free condition and ensure safe and consistent BD reclamation and DMA buffer lifecycle management. Fixes: 4701073c3deb ("net: enetc: add initial netc-lib driver to support NTMP") Link: https://lore.kernel.org/netdev/20260403011729.1795413-1-kuba@kernel.org/ # [1] Signed-off-by: Wei Fang Link: https://patch.msgid.link/20260415060833.2303846-3-wei.fang@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1f379216ccc882bf0a1e8aeb5b7ff5a4c0e3a027 Author: Wei Fang Date: Wed Apr 15 14:08:32 2026 +0800 net: enetc: correct the command BD ring consumer index [ Upstream commit 759a32900b6f3db3d0f34a3b61123742723b50b4 ] The command BD ring cousumer index register has the consumer index as the lower 10 bits, and the bit 31 is SBE, which indicates whether a system bus error occurred during execution of the CBD command. So if a system bus error occurs, reading the register will get the SBE bit set. However, the current implementation directly uses the register value as the consumer index without masking it. Therefore, if a system bus error occurs, an incorrect consumer index will be obtained, causing errors in the processing of the command BD ring. Thus, we need to mask out the other bits to obtain the correct consumer index. In addition, this patch adds a check for the SBE bit after the polling loop and returns an error if the bit is set. Fixes: 4701073c3deb ("net: enetc: add initial netc-lib driver to support NTMP") Signed-off-by: Wei Fang Link: https://patch.msgid.link/20260415060833.2303846-2-wei.fang@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 74d64ae4254e99ef8c8215b057a76edac82c5f99 Author: Stanislav Fomichev Date: Tue Apr 14 16:10:35 2026 -0700 net: dsa: remove redundant netdev_lock_ops() from conduit ethtool ops [ Upstream commit 0f99e0c3e19badaf3fdced0d3feba623e59eed41 ] DSA replaces the conduit (master) device's ethtool_ops with its own wrappers that aggregate stats from both the conduit and DSA switch ports. Taking the lock again inside the DSA wrappers causes a deadlock. Stumbled upon this when booting qemu with fbnic and CONFIG_NET_DSA_LOOP=y (which looks like some kind of testing device that auto-populates the ports of eth0). `ethtool -i` is enough to deadlock. This means we have basically zero coverage for DSA stuff with real ops locked devs. Remove the redundant netdev_lock_ops()/netdev_unlock_ops() calls from the DSA conduit ethtool wrappers. Fixes: 2bcf4772e45a ("net: ethtool: try to protect all callback with netdev instance lock") Signed-off-by: Stanislav Fomichev Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260414231035.1917035-1-sdf@fomichev.me Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4c078a699a8c1e730d3c486381e11690fc2427c5 Author: Vladimir Oltean Date: Sat Nov 22 13:23:11 2025 +0200 net: dsa: append ethtool counters of all hidden ports to conduit [ Upstream commit f647ed2ca78ec4efcc436915b441da9de0974926 ] Currently there is no way to see packet counters on cascade ports, and no clarity on how the API for that would look like. Because it's something that is currently needed, just extend the hack where ethtool -S on the conduit interface dumps CPU port counters, and also use it to dump counters of cascade ports. Note that the "pXX_" naming convention changes to "sXX_pYY", to distinguish between ports having the same index but belonging to different switches. This has a slight chance of causing regressions to existing tooling: - grepping for "p04_counter_name" still works, but might return more than one string now - grepping for " p04_counter_name" no longer works Signed-off-by: Vladimir Oltean Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20251122112311.138784-4-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Stable-dep-of: 0f99e0c3e19b ("net: dsa: remove redundant netdev_lock_ops() from conduit ethtool ops") Signed-off-by: Sasha Levin commit 87bbc2e86439495f89017f4381d82e1d679505a3 Author: Vladimir Oltean Date: Sat Nov 22 13:23:10 2025 +0200 net: dsa: use kernel data types for ethtool ops on conduit [ Upstream commit 8afabd27fe46ebf991b4aea20b74e08196c15c0c ] Suppress some checkpatch 'CHECK' messages about u8 being preferable over uint8_t, etc. No functional change. Signed-off-by: Vladimir Oltean Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20251122112311.138784-3-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Stable-dep-of: 0f99e0c3e19b ("net: dsa: remove redundant netdev_lock_ops() from conduit ethtool ops") Signed-off-by: Sasha Levin commit f128f04a893da87e4616af3a75ebbb3855b06cf2 Author: Vladimir Oltean Date: Sat Nov 22 13:23:09 2025 +0200 net: dsa: cpu_dp->orig_ethtool_ops might be NULL [ Upstream commit eba81b0a6de39e2466d37e410003642282b4e546 ] In theory this would have been seen by now, but it seems that all drivers used as DSA conduit interfaces thus far have had ethtool_ops set, and it's hard to even find modern Ethernet drivers (and not VF ones) which don't use ethtool. Here is the unfiltered list of drivers which register any sort of net_device but don't set its ethtool_ops pointer. I don't think any of them 'risks' being used as a DSA conduit, maybe except for moxart, rnpbge and icssm, I'm not sure. - drivers/net/can/dev/dev.c - drivers/net/wwan/qcom_bam_dmux.c - drivers/net/wwan/t7xx/t7xx_netdev.c - drivers/net/arcnet/arcnet.c - drivers/net/hamradio/ - drivers/net/slip/slip.c - drivers/net/ethernet/ezchip/nps_enet.c - drivers/net/ethernet/moxa/moxart_ether.c - drivers/net/ethernet/wangxun/txgbevf/txgbevf_main.c - drivers/net/ethernet/wangxun/ngbevf/ngbevf_main.c - drivers/net/ethernet/huawei/hinic3/hinic3_main.c - drivers/net/ethernet/i825xx/ - drivers/net/ethernet/ti/icssm/icssm_prueth.c - drivers/net/ethernet/seeq/ - drivers/net/ethernet/litex/litex_liteeth.c - drivers/net/ethernet/sunplus/spl2sw_driver.c - drivers/net/ethernet/mucse/rnpgbe/rnpgbe_main.c - drivers/net/ipa/ - drivers/net/wireless/microchip/wilc1000/ - drivers/net/wireless/mediatek/mt76/dma.c - drivers/net/wireless/ath/ath12k/ - drivers/net/wireless/ath/ath11k/ - drivers/net/wireless/ath/ath6kl/ - drivers/net/wireless/ath/ath10k/ - drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/trans.c - drivers/net/wireless/virtual/mac80211_hwsim.c - drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c - drivers/net/wireless/realtek/rtw89/core.c - drivers/net/wireless/realtek/rtw88/pci.c - drivers/net/caif/ - drivers/net/plip/ - drivers/net/wan/ - drivers/net/mctp/ - drivers/net/ppp/ - drivers/net/thunderbolt/ Nonetheless, it's good for the framework not to make such assumptions, and not panic when coming across such kind of host device in the future. Signed-off-by: Vladimir Oltean Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20251122112311.138784-2-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Stable-dep-of: 0f99e0c3e19b ("net: dsa: remove redundant netdev_lock_ops() from conduit ethtool ops") Signed-off-by: Sasha Levin commit b73235da5dde77ed1264f9767b62c28c9d71fd78 Author: Vinicius Costa Gomes Date: Fri Apr 10 18:57:57 2026 -0700 net/sched: taprio: fix use-after-free in advance_sched() on schedule switch [ Upstream commit 105425b1969c5affe532713cfac1c0b320d7ac2b ] In advance_sched(), when should_change_schedules() returns true, switch_schedules() is called to promote the admin schedule to oper. switch_schedules() queues the old oper schedule for RCU freeing via call_rcu(), but 'next' still points into an entry of the old oper schedule. The subsequent 'next->end_time = end_time' and rcu_assign_pointer(q->current_entry, next) are use-after-free. Fix this by selecting 'next' from the new oper schedule immediately after switch_schedules(), and using its pre-calculated end_time. setup_first_end_time() sets the first entry's end_time to base_time + interval when the schedule is installed, so the value is already correct. The deleted 'end_time = sched_base_time(admin)' assignment was also harmful independently: it would overwrite the new first entry's pre-calculated end_time with just base_time. Fixes: a3d43c0d56f1 ("taprio: Add support adding an admin schedule") Reported-by: Junxi Qian Signed-off-by: Vinicius Costa Gomes Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 75b6c361f41707b4fec21347d914353be9ceb9cc Author: Lorenzo Bianconi Date: Tue Apr 14 16:08:52 2026 +0200 net: airoha: Wait for NPU PPE configuration to complete in airoha_ppe_offload_setup() [ Upstream commit f3206328bb52c2787197d80d7cbd687946047d5f ] In order to properly enable flowtable hw offloading, poll REG_PPE_FLOW_CFG register in airoha_ppe_offload_setup routine and wait for NPU PPE configuration triggered by ppe_init callback to complete before running airoha_ppe_hw_init(). Fixes: 00a7678310fe3 ("net: airoha: Introduce flowtable offload support") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260414-airoha-wait-for-npu-config-offload-setup-v2-1-5a9bf6d43aee@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 613c8f4a501421dd258b07ea614205d4e16ec845 Author: Jiayuan Chen Date: Mon Apr 13 19:45:19 2026 +0800 nexthop: fix IPv6 route referencing IPv4 nexthop [ Upstream commit 29c95185ba32b621fbc3800fb86e7dc3edf5c2be ] syzbot reported a panic [1] [2]. When an IPv6 nexthop is replaced with an IPv4 nexthop, the has_v4 flag of all groups containing this nexthop is not updated. This is because nh_group_v4_update is only called when replacing AF_INET to AF_INET6, but the reverse direction (AF_INET6 to AF_INET) is missed. This allows a stale has_v4=false to bypass fib6_check_nexthop, causing IPv6 routes to be attached to groups that effectively contain only AF_INET members. Subsequent route lookups then call nexthop_fib6_nh() which returns NULL for the AF_INET member, leading to a NULL pointer dereference. Fix by calling nh_group_v4_update whenever the family changes, not just AF_INET to AF_INET6. Reproducer: # AF_INET6 blackhole ip -6 nexthop add id 1 blackhole # group with has_v4=false ip nexthop add id 100 group 1 # replace with AF_INET (no -6), has_v4 stays false ip nexthop replace id 1 blackhole # pass stale has_v4 check ip -6 route add 2001:db8::/64 nhid 100 # panic ping -6 2001:db8::1 [1] https://syzkaller.appspot.com/bug?id=e17283eb2f8dcf3dd9b47fe6f67a95f71faadad0 [2] https://syzkaller.appspot.com/bug?id=8699b6ae54c9f35837d925686208402949e12ef3 Fixes: 7bf4796dd099 ("nexthops: add support for replace") Signed-off-by: Jiayuan Chen Reviewed-by: David Ahern Link: https://patch.msgid.link/20260413114522.147784-1-jiayuan.chen@linux.dev Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 7ad66185052d9de36ad2dd299bb3473aa34edc9c Author: Dudu Lu Date: Mon Apr 13 19:00:41 2026 +0800 net/sched: sch_cake: fix NAT destination port not being updated in cake_update_flowkeys [ Upstream commit f9e40664706927d7ae22a448a3383e23c38a4c0b ] cake_update_flowkeys() is supposed to update the flow dissector keys with the NAT-translated addresses and ports from conntrack, so that CAKE's per-flow fairness correctly identifies post-NAT flows as belonging to the same connection. For the source port, this works correctly: keys->ports.src = port; But for the destination port, the assignment is reversed: port = keys->ports.dst; This means the NAT destination port is never updated in the flow keys. As a result, when multiple connections are NATed to the same destination, CAKE treats them as separate flows because the original (pre-NAT) destination ports differ. This breaks CAKE's NAT-aware flow isolation when using the "nat" mode. The bug was introduced in commit b0c19ed6088a ("sch_cake: Take advantage of skb->hash where appropriate") which refactored the original direct assignment into a compare-and-conditionally-update pattern, but wrote the destination port update backwards. Fix by reversing the assignment direction to match the source port pattern. Fixes: b0c19ed6088a ("sch_cake: Take advantage of skb->hash where appropriate") Signed-off-by: Dudu Lu Acked-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20260413110041.44704-1-phx0fer@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit b6b7154e9f5d75b608ceb2d05b376de8c638c40e Author: Dudu Lu Date: Mon Apr 13 16:53:49 2026 +0800 macvlan: fix macvlan_get_size() not reserving space for IFLA_MACVLAN_BC_CUTOFF [ Upstream commit fa92a77b0ed4d5f11a71665a232ac5a54a4b055d ] macvlan_get_size() does not account for IFLA_MACVLAN_BC_CUTOFF, but macvlan_fill_info() conditionally includes it when port->bc_cutoff != 1. This causes nla_put_s32() to fail with -EMSGSIZE when the netlink skb runs out of space, triggering a WARN_ON in rtnetlink and preventing the interface from being dumped. The bug can be reproduced with: ip link add macvlan0 link eth0 type macvlan mode bridge ip link set macvlan0 type macvlan bc_cutoff 0 ip -d link show macvlan0 # fails with -EMSGSIZE The bc_cutoff feature was added in commit 954d1fa1ac93 ("macvlan: Add netlink attribute for broadcast cutoff"), which added the nla_put_s32() call in macvlan_fill_info() but missed adding the corresponding nla_total_size(4) in macvlan_get_size(). A follow-up commit 55cef78c244d ("macvlan: add forgotten nla_policy for IFLA_MACVLAN_BC_CUTOFF") fixed the missing nla_policy entry but still did not fix the size calculation. Fixes: 954d1fa1ac93 ("macvlan: Add netlink attribute for broadcast cutoff") Signed-off-by: Dudu Lu Reviewed-by: Vadim Fedorenko Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260413085349.73977-1-phx0fer@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 7db3e4e03032261b1b519341123fc30d995478ca Author: Dudu Lu Date: Mon Apr 13 16:49:27 2026 +0800 net/sched: act_mirred: fix wrong device for mac_header_xmit check in tcf_blockcast_redir [ Upstream commit 4510d140524ca7d6e772db962e013f26f09a63b1 ] In tcf_blockcast_redir(), when iterating block ports to redirect packets to multiple devices, the mac_header_xmit flag is queried from the wrong device. The loop sends to dev_prev but queries dev_is_mac_header_xmit(dev) — which is the NEXT device in the iteration, not the one being sent to. This causes tcf_mirred_to_dev() to make incorrect decisions about whether to push or pull the MAC header. When the block contains mixed device types (e.g., an ethernet veth and a tunnel device), intermediate devices get the wrong mac_header_xmit flag, leading to skb header corruption. In the worst case, skb_push_rcsum with an incorrect mac_len can exhaust headroom and panic. The last device in the loop is handled correctly (line 365-366 uses dev_is_mac_header_xmit(dev_prev)), confirming this is a copy-paste oversight for the intermediate devices. Fix by using dev_prev instead of dev for the mac_header_xmit query, consistent with the device actually being sent to. Fixes: 42f39036cda8 ("net/sched: act_mirred: Allow mirred to block") Signed-off-by: Dudu Lu Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260413084927.71353-1-phx0fer@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 7b5501a62214e76ec5fbdb4dce324e1271dc46d2 Author: Uwe Kleine-König Date: Wed Apr 15 16:50:12 2026 +0200 pwm: stm32: Fix rounding issue for requests with inverted polarity [ Upstream commit 5d087c485b6ecf200a9ebb2a032bf8571d330250 ] The calculation of the number of pwm clk ticks from a time length in nanoseconds involves a division and thus some rounding. That might result in duty_ticks + offset_ticks < period_ticks despite duty_length_ns + duty_offset_ns >= period_length_ns . The stm32 PWM cannot configure offset_ticks freely, it can only select 0 or period_length_ns - duty_length_ns---that is the classic normal and inverted polarity. The decision to select the hardware polarity must be done using the ticks values and not the nanoseconds times to adhere to the rounding rules by the pwm core. With the pwm clk running at 208900 kHz on my test machine (stm32mp135f-dk), a test case that was handled wrong is: # pwmround -P 9999962 -O 24970 -D 9974992 period_length = 9999962 duty_length = 9974840 duty_offset = 25123 With this change applied the rounding is done correctly: # pwmround -P 9999962 -O 24970 -D 9974992 period_length = 9999962 duty_length = 9974840 duty_offset = 0 Fixes: deaba9cff809 ("pwm: stm32: Implementation of the waveform callbacks") Signed-off-by: Uwe Kleine-König Link: https://patch.msgid.link/c5e7767cee821b5f6e00f95bd14a5e13015646fb.1776264104.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit ad5dc433b34e7d8c33b35fdc0e4ad60080d4b59b Author: Gabor Juhos Date: Mon Mar 30 17:25:16 2026 +0200 arm64: dts: marvell: armada-37xx: use 'usb2-phy' in USB3 controller's phy-names [ Upstream commit 0fef19844624f8bc07651b4d26088d8940affba3 ] Instead of the generic 'usb2-phy' name, the Armada 37xx device trees are using a custom 'usb2-utmi-otg-phy' name for the USB2 PHY in the USB3 controller node. Since commit 53a2d95df836 ("usb: core: add phy notify connect and disconnect"), this triggers a bug [1] in the USB core which causes double use of the USB3 PHY. Change the PHY name to 'usb2-phy' in the SoC and in the uDPU specific dtsi files in order to avoid triggering the bug and also to keep the names in line with the ones used by other platforms. Link: https://lore.kernel.org/r/20260330-usb-avoid-usb3-phy-double-use-v1-1-d2113aecb535@gmail.com # [1] Fixes: 53a2d95df836 ("usb: core: add phy notify connect and disconnect") Signed-off-by: Gabor Juhos Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit 5b5f8ff0a2e8fd366f24f9c10850732d0b420198 Author: Peng Fan Date: Sun Mar 29 21:00:13 2026 +0800 arm64: dts: imx8mm-tqma8mqml: Correct PAD settings for PMIC_nINT [ Upstream commit 42a9f5a16328ed78a88e0498556965b6c6ec515c ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. Fixes: dfcd1b6f7620e ("arm64: dts: freescale: add initial device tree for TQMa8MQML with i.MX8MM") Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 8002eb9b60a60451568988352df34f4aef3cef95 Author: Peng Fan Date: Sun Mar 29 21:00:12 2026 +0800 arm64: dts: imx8mn-tqma8mqnl: Correct PAD settings for PMIC_nINT [ Upstream commit 0fb37990774113afd943eaa91323679388584b6d ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. Fixes: 3e56e354db6d3 ("arm64: dts: freescale: add initial device tree for TQMa8MQNL with i.MX8MN") Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 33d043815ccc7588b7c07d82bb4a7415a350ddc5 Author: Peng Fan Date: Sun Mar 29 21:00:11 2026 +0800 arm64: dts: imx8mm-emtop-som: Correct PAD settings for PMIC_nINT [ Upstream commit 721dec3ee9ff5231d13a412ff87df63b966d137b ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. While at here, also correct interrupt type as IRQ_TYPE_LEVEL_LOW. Fixes: cbd3ef64eb9d1 ("arm64: dts: Add support for Emtop SoM & Baseboard") Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit cde69482d2e6834dcd4ed675d1ef84e48627ee9f Author: Ronald Claveau Date: Tue Mar 31 16:24:04 2026 +0200 reset: amlogic: t7: Fix null reset ops [ Upstream commit 9797524ef2b69c6b187b55bd844eb72a8c1cbd99 ] Fix missing reset ops causing kernel null pointer dereference. This SOC's reset is currently not used yet. Signed-off-by: Ronald Claveau Fixes: fb4c31587adf ("reset: amlogic: add auxiliary reset driver support") Reviewed-by: Philipp Zabel Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin commit 4790bd29d626b052373f462f166fffb8e4c9cbad Author: René Rebe Date: Wed Nov 26 17:42:56 2025 +0100 PCMCIA: Fix garbled log messages for KERN_CONT [ Upstream commit bfeaa6814bd3f9a1f6d525b3b35a03b9a0368961 ] For years the PCMCIA info messages are messed up by superfluous newlines. While f2e6cf76751d ("pcmcia: Convert dev_printk to dev_") converted the code to pr_cont(), dev_info enforces a \n via vprintk_store setting LOG_NEWLINE, breaking subsequent pr_cont. Fix by logging the device name manually to allow pr_cont to work for more readable and not \n distorted logs. Fixes: f2e6cf76751d ("pcmcia: Convert dev_printk to dev_") Signed-off-by: René Rebe Signed-off-by: Dominik Brodowski Signed-off-by: Sasha Levin commit 9e8087ac4636066578ded9e8aa52c310f9d58147 Author: Peng Fan Date: Thu Mar 26 15:28:16 2026 +0800 arm64: dts: imx8mp-data-modul-edm-sbc: Correct PAD settings for PMIC_nINT [ Upstream commit 8ff145577e93f312ff398cb950ee3bd44835f5be ] PMIC_nINT is low level triggered, but the current PAD settings is PE=0,PUE=0,FSEL_1_FAST_SLEW_RATE=1,SION=1. So PAD needs to be configured as PULL UP with PULL Enable, no need SION. Correct it. Fixes: 562d222f23f0f ("arm64: dts: imx8mp: Add support for Data Modul i.MX8M Plus eDM SBC") Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 2b7db3e83f78f96c87718f8d3a6a76256a9dd6c8 Author: Peng Fan Date: Thu Mar 26 15:28:15 2026 +0800 arm64: dts: imx8mp-dhcom-som: Correct PAD settings for PMIC_nINT [ Upstream commit f9ed5afc988da3e22543725e35be6addbb0497bc ] PMIC_nINT is low level triggered, but the current PAD settings is PE=0,PUE=0,FSEL_1_FAST_SLEW_RATE=1,SION=1. So PAD needs to be configured as PULL UP with PULL Enable, no need SION. Correct it. Fixes: 8d6712695bc8e ("arm64: dts: imx8mp: Add support for DH electronics i.MX8M Plus DHCOM and PDK2") Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit d8d75e1135329908a1a1254d0efba3471b624619 Author: Peng Fan Date: Thu Mar 26 15:28:14 2026 +0800 arm64: dts: imx8mp-ultra-mach-sbc: Correct PAD settings for PMIC_nINT [ Upstream commit daaf41ee72fb5fad936e7051a015cccae9b33937 ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. Fixes: d1c1400bd3b8b ("arm64: dts: imx8mp: Add initial support for Ultratronik imx8mp-ultra-mach-sbc board") Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit e754961b2655e843ba6939a8a5071513b7bd5098 Author: Peng Fan Date: Thu Mar 26 15:28:13 2026 +0800 arm64: dts: imx8mp-sr-som: Correct PAD settings for PMIC_nINT [ Upstream commit 695a476275cfb9c798a696aeaa43967701d5c78a ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. Fixes: a009c0c66ecb4 ("arm64: dts: add description for solidrun imx8mp som and cubox-m") Signed-off-by: Peng Fan Reviewed-by: Josua Mayer Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 4ff0003fabd7cfd557005cefb86196f4373ad432 Author: Peng Fan Date: Thu Mar 26 15:28:12 2026 +0800 arm64: dts: imx8mp-nitrogen-som: Correct PAD settings for PMIC_nINT [ Upstream commit 16611eda2c7584a1a7d6f80511d825e5108f026c ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. Fixes: ab4d874c9f44e ("arm64: dts: imx8mp: Add device tree for Nitrogen8M Plus ENC Carrier Board") Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 9011a6128935b19e2a038694adbb00a97bae5090 Author: Peng Fan Date: Thu Mar 26 15:28:11 2026 +0800 arm64: dts: imx8mp-aristainetos3a-som-v1: Correct PAD settings for PMIC_nINT [ Upstream commit e6d2d8e49ca34bb39126a69128794d08ffd7c83e ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. Fixes: eead8f3536d5c ("arm64: dts: imx8mp: add aristainetos3 board support") Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit dde47488fb191faf054c6dae4634be689374bdd9 Author: Peng Fan Date: Thu Mar 26 15:28:10 2026 +0800 arm64: dts: imx8mp-edm-g: Correct PAD settings for PMIC_nINT [ Upstream commit c46c5a54443440ce0f71de9f4df9dd860f5c2afd ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. Fixes: 95e882c021c8b ("arm64: dts: imx8mp: Add TechNexion EDM-G-IMX8M-PLUS SOM on WB-EDM-G carrier board") Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 91c150b3760df2b815e83fbb74dd3e5a25aa4cab Author: Peng Fan Date: Thu Mar 26 15:28:09 2026 +0800 arm64: dts: imx8mp-icore-mx8mp: Correct PAD settings for PMIC_nINT [ Upstream commit ea8c90f5c7ceeb6657a8fe564aa7b190dce298a6 ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. Fixes: eefe06b295087 ("arm64: dts: imx8mp: Add Engicam i.Core MX8M Plus SoM") Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 3a958f45a6767ce16e16fed33cfddf3df1e834d4 Author: Peng Fan Date: Thu Mar 26 15:28:07 2026 +0800 arm64: dts: imx8mp-navqp: Correct PAD settings for PMIC_nINT [ Upstream commit 741d6ac1a2a2e0f3e2cae5eef3516cdd75119e83 ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there will be interrupt storm for i.MX8MP NAVQP. Per schematic, there is no on board PULL-UP resistors for GPIO1_IO03, so need to set PAD PUE and PU together to make pull up work properly. Fixes: 682729a9d506d ("arm64: dts: freescale: Add device tree for Emcraft Systems NavQ+ Kit") Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit e821e5e0c61b85898c76ebcff51a47ca50a738f4 Author: Peng Fan Date: Thu Mar 26 15:28:06 2026 +0800 arm64: dts: imx8mp-debix-som-a: Correct PAD settings for PMIC_nINT [ Upstream commit 2ea7872048a179b0ea8dadc67771961df3f0fc4a ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there is interrupt storm for i.MX8MP DEBIX SOM A. Need to set PAD PUE and PU together to make pull up work properly. Fixes: 21baf0b47f81b ("arm64: dts: freescale: Add DEBIX SOM A and SOM A I/O Board support") Reported-by: Laurent Pinchart Closes: https://lore.kernel.org/all/20260323105858.GA2185714@killaraus.ideasonboard.com/ Reported-by: Kieran Bingham Closes: https://lore.kernel.org/imx/20260324194353.GB2352505@killaraus.ideasonboard.com/T/#m9a07fdc75496369a7d76d52c5e34ed140dcabfe3 Signed-off-by: Peng Fan Reviewed-by: Kieran Bingham Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 4a259bb367021df7f1520c80101a14190242aed7 Author: Peng Fan Date: Thu Mar 26 15:28:05 2026 +0800 arm64: dts: imx8mp-debix-model-a: Correct PAD settings for PMIC_nINT [ Upstream commit 3b778178997aee24537b521a8cb60970bc1ce01c ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there is interrupt storm for i.MX8MP DEBIX Model A. Per schematic, there is no on board PULL-UP resistors for GPIO1_IO03, so need to set PAD PUE and PU together to make pull up work properly. Fixes: c86d350aae68e ("arm64: dts: Add device tree for the Debix Model A Board") Reported-by: Laurent Pinchart Closes: https://lore.kernel.org/all/20260323105858.GA2185714@killaraus.ideasonboard.com/ Reviewed-by: Laurent Pinchart Tested-by: Laurent Pinchart Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 858e4d98a86adf34584767388deb6c9b217f70c5 Author: Gao Xiang Date: Mon Apr 20 18:11:42 2026 +0800 erofs: unify lcn as u64 for 32-bit platforms [ Upstream commit 2d8c7edcb661812249469f4a5b62e9339118846f ] As sashiko reported [1], `lcn` was typed as `unsigned long` (or `unsigned int` sometimes), which is only 32 bits wide on 32-bit platforms, which causes `(lcn << lclusterbits)` to be truncated at 4 GiB. In order to consolidate the logic, just use `u64` consistently around the codebase. [1] https://sashiko.dev/r/20260420034612.1899973-1-hsiangkao%40linux.alibaba.com Fixes: 152a333a5895 ("staging: erofs: add compacted compression indexes support") Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit df9784bb5b637ac80f4a2768a58ca9a50bef28a9 Author: Paul Moses Date: Wed Apr 1 03:07:49 2026 -0500 crypto: ccp - copy IV using skcipher ivsize [ Upstream commit a7a1f3cdd64d8a165d9b8c9e9ad7fb46ac19dfc4 ] AF_ALG rfc3686-ctr-aes-ccp requests pass an 8-byte IV to the driver. ccp_aes_complete() restores AES_BLOCK_SIZE bytes into the caller's IV buffer while RFC3686 skciphers expose an 8-byte IV, so the restore overruns the provided buffer. Use crypto_skcipher_ivsize() to copy only the algorithm's IV length. Fixes: 2b789435d7f3 ("crypto: ccp - CCP AES crypto API support") Signed-off-by: Paul Moses Reviewed-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit d05ebf0d3f8c078852fbcb3aa5b59c748c47446a Author: T Pratham Date: Wed Apr 15 20:06:58 2026 +0530 crypto: sa2ul - Fix AEAD fallback algorithm names [ Upstream commit 8451ab6ad686ffdcdf9ddadaa446a79ab48e5590 ] For authenc AEAD algorithms, sa2ul is trying to register very specific -ce version as a fallback. This causes registration failure on SoCs which do not have ARMv8-CE enabled/available. Change the fallback algorithm from the specific driver name to generic algorithm name so that the kernel can allocate any available fallback. Fixes: d2c8ac187fc92 ("crypto: sa2ul - Add AEAD algorithm support") Signed-off-by: T Pratham Reviewed-by: Manorit Chawdhry Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit fc9310d79fdb117b369a01eb00f4fd5fb4849d4e Author: Aleksander Jan Bajkowski Date: Sat Apr 11 23:08:17 2026 +0200 crypto: eip93 - fix hmac setkey algo selection [ Upstream commit 3ba3b02f897b14e34977e1886d95ffe64d907204 ] eip93_hmac_setkey() allocates a temporary ahash transform for computing HMAC ipad/opad key material. The allocation uses the driver-specific cra_driver_name (e.g. "sha256-eip93") but passes CRYPTO_ALG_ASYNC as the mask, which excludes async algorithms. Since the EIP93 hash algorithms are the only ones registered under those driver names and they are inherently async, the lookup is self-contradictory and always fails with -ENOENT. When called from the AEAD setkey path, this failure leaves the SA record partially initialized with zeroed digest fields. A subsequent crypto operation then dereferences a NULL pointer in the request context, resulting in a kernel panic: ``` pc : eip93_aead_handle_result+0xc8c/0x1240 [crypto_hw_eip93] lr : eip93_aead_handle_result+0xbec/0x1240 [crypto_hw_eip93] sp : ffffffc082feb820 x29: ffffffc082feb820 x28: ffffff8011043980 x27: 0000000000000000 x26: 0000000000000000 x25: ffffffc078da0bc8 x24: 0000000091043980 x23: ffffff8004d59e50 x22: ffffff8004d59410 x21: ffffff8004d593c0 x20: ffffff8004d593c0 x19: ffffff8004d4f300 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000007fda7aa498 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: fffffffff8127a80 x9 : 0000000000000000 x8 : ffffff8004d4f380 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : 0000000000000008 x3 : 0000000000000009 x2 : 0000000000000008 x1 : 0000000028000003 x0 : ffffff8004d388c0 Code: 910142b6 f94012e0 f9002aa0 f90006d3 (f9400740) ``` The reported symbol eip93_aead_handle_result+0xc8c is a resolution artifact from static functions being merged under the nearest exported symbol. Decoding the faulting sequence: ``` 910142b6 ADD X22, X21, #0x50 f94012e0 LDR X0, [X23, #0x20] f9002aa0 STR X0, [X21, #0x50] f90006d3 STR X19, [X22, #0x8] f9400740 LDR X0, [X26, #0x8] ``` The faulting LDR at [X26, #0x8] is loading ctx->flags (offset 8 in eip93_hash_ctx), where ctx has been resolved to NULL from a partially initialized or unreachable transform context following the failed setkey. Fix this by dropping the CRYPTO_ALG_ASYNC mask from the crypto_alloc_ahash() call. The code already handles async completion correctly via crypto_wait_req(), so there is no requirement to restrict the lookup to synchronous algorithms. Note that hashing a single 64-byte block through the hardware is likely slower than doing it in software due to the DMA round-trip overhead, but offloading it may still spare CPU cycles on the slower embedded cores where this IP is found. Fixes: 9739f5f93b78 ("crypto: eip93 - Add Inside Secure SafeXcel EIP-93 crypto engine support") Signed-off-by: Aleksander Jan Bajkowski [Detailed investigation report of this bug] Signed-off-by: Kenneth Kasilag Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit c6efc77954d8a59447c8560251ddad04d9859574 Author: Sami Mujawar Date: Fri Apr 10 17:36:36 2026 +0100 virt: arm-cca-guest: fix error check for RSI_INCOMPLETE [ Upstream commit e534e9d13d0b7bdbb2cccdace7b96b769a10540e ] The RSI interface can return RSI_INCOMPLETE when a report spans multiple granules. This is an expected condition and should not be treated as a fatal error. Currently, arm_cca_report_new() checks for `info.result != RSI_SUCCESS` and bails out, which incorrectly flags RSI_INCOMPLETE as a failure. Fix the check to only break out on results other than RSI_SUCCESS or RSI_INCOMPLETE. This ensures partial reports are handled correctly and avoids spurious -ENXIO errors when generating attestation reports. Fixes: 7999edc484ca ("virt: arm-cca-guest: TSM_REPORT support for realms") Signed-off-by: Sami Mujawar Reported-by: Jagdish Gediya Reviewed-by: Steven Price Reviewed-by: Gavin Shan Reviewed-by: Suzuki K Poulose Reviewed-by: Yeoreum Yun Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 60a6842061b49f5afdc605b801713fb831f44d0f Author: Ville Syrjälä Date: Tue Mar 24 15:48:38 2026 +0200 drm/i915/wm: Verify the correct plane DDB entry [ Upstream commit a97c88a176b6b8d116f4d3f508f3bd02bc77b462 ] Actually verify the DDB entry for the plane we're looking at instead of always verifying the cursor DDB. Fixes: 7d4561722c3b ("drm/i915: Tweak plane ddb allocation tracking") Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20260324134843.2364-5-ville.syrjala@linux.intel.com Reviewed-by: Vinod Govindapillai (cherry picked from commit f002f7c7439de18117a31ca84dc87a59719c3dd6) Signed-off-by: Tvrtko Ursulin Signed-off-by: Sasha Levin commit d0e877810baf613b018fd9747440b9d4d9db1428 Author: Yongpeng Yang Date: Fri Apr 10 23:05:39 2026 +0800 f2fs: protect extension_list reading with sb_lock in f2fs_sbi_show() [ Upstream commit 5909bedbed38c558bee7cb6758ceedf9bc3a9194 ] In f2fs_sbi_show(), the extension_list, extension_count and hot_ext_count are read without holding sbi->sb_lock. If a concurrent sysfs store modifies the extension list via f2fs_update_extension_list(), the show path may read inconsistent count and array contents, potentially leading to out-of-bounds access or displaying stale data. Fix this by holding sb_lock around the entire extension list read and format operation. Fixes: b6a06cbbb5f7 ("f2fs: support hot file extension") Signed-off-by: Yongpeng Yang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 2b0ae4b59ff5d277989bc5c477d01c0d48e093b1 Author: Jaegeuk Kim Date: Mon Mar 30 23:40:59 2026 +0000 f2fs: allow empty mount string for Opt_usr|grp|projjquota [ Upstream commit 2a3db1e02ce08c14af04da70bb99e8a0a31eb9e8 ] The fsparam_string_empty() gives an error when mounting without string, since its type is set to fsparam_flag in VFS. So, let's allow the flag as well. This addresses xfstests/f2fs/015 and f2fs/021. Fixes: d18535132523 ("f2fs: separate the options parsing and options checking") Reviewed-by: Daeho Jeong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 1c5973c84ab453dd8e752aed0e33450292213943 Author: Brian Masney Date: Mon Mar 30 10:32:37 2026 -0400 clk: visconti: pll: initialize clk_init_data to zero [ Upstream commit 1603cbb64173a0e9fa7500f2a686f4aa011c58b9 ] Sashiko reported the following: > The struct clk_init_data init is declared on the stack without being > fully zero-initialized. While fields like name, flags, parent_names, > num_parents, and ops are explicitly assigned, the parent_data and > parent_hws fields are left containing stack garbage. clk_core_populate_parent_map() currently prefers the parent names over the parent data and hws, so this isn't a problem at the moment. If that ordering ever changed in the future, then this could lead to some unexpected crashes. Let's just go ahead and make sure that the struct clk_init_data is initialized to zero as a good practice. Fixes: b4cbe606dc367 ("clk: visconti: Add support common clock driver and reset driver") Link: https://sashiko.dev/#/patchset/20260326042317.122536-1-rosenp%40gmail.com Signed-off-by: Brian Masney Reviewed-by: Benoît Monin Reviewed-by: Nobuhiro Iwamatsu Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit cccefa34c09ac2a24c5953cd069bfa79af892086 Author: Jagadeesh Kona Date: Fri Mar 27 20:36:46 2026 +0530 clk: qcom: gcc-x1e80100: Keep GCC USB QTB clock always ON [ Upstream commit 05566ebcc0cd170bd4f50c907ee3ed8e106251e3 ] In Hamoa, SMMU invalidation requires the GCC_AGGRE_USB_NOC_AXI_CLK to be on for the USB QTB to be functional. This is currently explicitly enabled by the DWC3 glue driver, so an invalidation happening while the USB controller is suspended will fault. Solve this by voting for the GCC MMU USB QTB clock. Fixes: 161b7c401f4b ("clk: qcom: Add Global Clock controller (GCC) driver for X1E80100") Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Signed-off-by: Jagadeesh Kona Reviewed-by: Taniya Das Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20260327-hamoa-usb-qtb-clk-always-on-v2-1-7d8a406e650f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a841167c1ef7bfeffa62e6f494e4ff9be7fa0812 Author: Zhiguo Niu Date: Thu Mar 5 11:22:46 2026 +0800 f2fs: fix to preserve previous reserve_{blocks,node} value when remount [ Upstream commit 01968164d94762db2f703647c5acfa28613844f1 ] The following steps will change previous value of reserve_{blocks,node}, this dones not match the original intention. 1.mount -t f2fs -o reserve_root=8192 imgfile test_mount/ F2FS-fs (loop56): Mounted with checkpoint version = 1b69f8c7 mount info: /dev/block/loop56 on /data/test_mount type f2fs (xxx,reserve_root=8192,reserve_node=0,resuid=0,resgid=0,xxx) 2.mount -t f2fs -o remount,reserve_root=4096 /data/test_mount F2FS-fs (loop56): Preserve previous reserve_root=8192 check mount info: reserve_root change to 4096 /dev/block/loop56 on /data/test_mount type f2fs (xxx,reserve_root=4096,reserve_node=0,resuid=0,resgid=0,xxx) Prior to commit d18535132523 ("f2fs: separate the options parsing and options checking"), the value of reserve_{blocks,node} was only set during the first mount, along with the corresponding mount option F2FS_MOUNT_RESERVE_{ROOT,NODE} . If the mount option F2FS_MOUNT_RESERVE_{ROOT,NODE} was found to have been set during the mount/remount, the previously value of reserve_{blocks,node} would also be preserved, as shown in the code below. if (test_opt(sbi, RESERVE_ROOT)) { f2fs_info(sbi, "Preserve previous reserve_root=%u", F2FS_OPTION(sbi).root_reserved_blocks); } else { F2FS_OPTION(sbi).root_reserved_blocks = arg; set_opt(sbi, RESERVE_ROOT); } But commit d18535132523 ("f2fs: separate the options parsing and options checking") only preserved the previous mount option; it did not preserve the previous value of reserve_{blocks,node}. Since value of reserve_{blocks,node} value is assigned or not depends on ctx->spec_mask, ctx->spec_mask should be alos handled in f2fs_check_opt_consistency. This patch will clear the corresponding ctx->spec_mask bits in f2fs_check_opt_consistency to preserve the previously values of reserve_{blocks,node} if it already have a value. Fixes: d18535132523 ("f2fs: separate the options parsing and options checking") Signed-off-by: Zhiguo Niu Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit ef72360aa88ad588f17bc248c3e30bd733b5163b Author: Chao Yu Date: Mon Nov 17 20:45:59 2025 +0800 f2fs: expand scalability of f2fs mount option [ Upstream commit 1627a303bca692edc6552630aa2f878c8a726a01 ] opt field in structure f2fs_mount_info and opt_mask field in structure f2fs_fs_context is 32-bits variable, now we're running out of available bits in them, let's expand them to 64-bits for better scalability. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Stable-dep-of: 01968164d947 ("f2fs: fix to preserve previous reserve_{blocks,node} value when remount") Signed-off-by: Sasha Levin commit 480307ffa289dd528211a4c3da9fa4f6c9b41736 Author: Geert Uytterhoeven Date: Tue Mar 31 17:21:43 2026 +0200 lib/hexdump: print_hex_dump_bytes() calls print_hex_dump_debug() [ Upstream commit 36776b7f8a8955b4e75b5d490a75fee0c7a2a7ef ] print_hex_dump_bytes() claims to be a simple wrapper around print_hex_dump(), but it actally calls print_hex_dump_debug(), which means no output is printed if (dynamic) DEBUG is disabled. Update the documentation to match the implementation. Fixes: 091cb0994edd20d6 ("lib/hexdump: make print_hex_dump_bytes() a nop on !DEBUG builds") Signed-off-by: Geert Uytterhoeven Reviewed-by: Petr Mladek Link: https://patch.msgid.link/3d5c3069fd9102ecaf81d044b750cd613eb72a08.1774970392.git.geert+renesas@glider.be Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin commit 3547f6b9a110fc6b72ec49abda6969a0d32f6e81 Author: Vladimir Zapolskiy Date: Sat Mar 28 03:26:19 2026 +0200 clk: qcom: gdsc: Fix error path on registration of multiple pm subdomains [ Upstream commit 16ba98dace9e7cfe25ad8a314e34befacd91f86f ] Some pm subdomains may be left in added to a parent domain state, if gdsc_add_subdomain_list() function fails in the middle and bails from a GDSC power domain controller registration out. Fixes: b489235b4dc0 ("clk: qcom: Support attaching GDSCs to multiple parents") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Dmitry Baryshkov Reviewed-by: Bryan O'Donoghue Link: https://lore.kernel.org/r/20260328012619.832770-1-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 4623c251496b99c530ce225c05334f4eac8b933a Author: Jianan Huang Date: Thu Mar 5 09:18:10 2026 +0800 f2fs: avoid reading already updated pages during GC [ Upstream commit 570e2ccc7cb35fe720106964e65060602d3d2ac4 ] We found the following issue during fuzz testing: page: refcount:3 mapcount:0 mapping:00000000b6e89c65 index:0x18b2dc pfn:0x161ba9 memcg:f8ffff800e269c00 aops:f2fs_meta_aops ino:2 flags: 0x52880000000080a9(locked|waiters|uptodate|lru|private|zone=1|kasantag=0x4a) raw: 52880000000080a9 fffffffec6e17588 fffffffec0ccc088 a7ffff8067063618 raw: 000000000018b2dc 0000000000000009 00000003ffffffff f8ffff800e269c00 page dumped because: VM_BUG_ON_FOLIO(folio_test_uptodate(folio)) page_owner tracks the page as allocated post_alloc_hook+0x58c/0x5ec prep_new_page+0x34/0x284 get_page_from_freelist+0x2dcc/0x2e8c __alloc_pages_noprof+0x280/0x76c __folio_alloc_noprof+0x18/0xac __filemap_get_folio+0x6bc/0xdc4 pagecache_get_page+0x3c/0x104 do_garbage_collect+0x5c78/0x77a4 f2fs_gc+0xd74/0x25f0 gc_thread_func+0xb28/0x2930 kthread+0x464/0x5d8 ret_from_fork+0x10/0x20 ------------[ cut here ]------------ kernel BUG at mm/filemap.c:1563! folio_end_read+0x140/0x168 f2fs_finish_read_bio+0x5c4/0xb80 f2fs_read_end_io+0x64c/0x708 bio_endio+0x85c/0x8c0 blk_update_request+0x690/0x127c scsi_end_request+0x9c/0xb8c scsi_io_completion+0xf0/0x250 scsi_finish_command+0x430/0x45c scsi_complete+0x178/0x6d4 blk_mq_complete_request+0xcc/0x104 scsi_done_internal+0x214/0x454 scsi_done+0x24/0x34 which is similar to the problem reported by syzbot: https://syzkaller.appspot.com/bug?extid=3686758660f980b402dc This case is consistent with the description in commit 9bf1a3f ("f2fs: avoid GC causing encrypted file corrupted"): Page 1 is moved from blkaddr A to blkaddr B by move_data_block, and after being written it is marked as uptodate. Then, Page 1 is moved from blkaddr B to blkaddr C, VM_BUG_ON_FOLIO was triggered in the endio initiated by ra_data_block. There is no need to read Page 1 again from blkaddr B, since it has already been updated. Therefore, avoid initiating I/O in this case. Fixes: 6aa58d8ad20a ("f2fs: readahead encrypted block during GC") Signed-off-by: Jianan Huang Signed-off-by: Sheng Yong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit fa18659f883e0c31d178d0e81c90e421f4aeefed Author: Chao Yu Date: Tue Oct 14 14:27:03 2025 +0800 f2fs: use f2fs_filemap_get_folio() instead of f2fs_pagecache_get_page() [ Upstream commit e0b89d00ea9f846da42fc92f200c96254d0e2fef ] Let's use f2fs_filemap_get_folio() instead of f2fs_pagecache_get_page() in ra_data_block() and move_data_block(), then remove f2fs_pagecache_get_page() since it has no user. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Stable-dep-of: 570e2ccc7cb3 ("f2fs: avoid reading already updated pages during GC") Signed-off-by: Sasha Levin commit da99d0302d3ccccfb13c69e663bf8eae698b9562 Author: Shuwei Wu Date: Thu Mar 5 20:46:08 2026 +0800 clk: spacemit: ccu_mix: fix inverted condition in ccu_mix_trigger_fc() [ Upstream commit 54e97360b44bed6b4399dd3be3d65f392df940fa ] Fix inverted condition that skips frequency change trigger, causing kernel panics during cpufreq scaling. Fixes: 1b72c59db0ad ("clk: spacemit: Add clock support for SpacemiT K1 SoC") Signed-off-by: Shuwei Wu Reviewed-by: Yixun Lan Link: https://lore.kernel.org/r/20260305-k1-clk-fix-v1-1-abca85d6e266@mailbox.org Signed-off-by: Yixun Lan Signed-off-by: Sasha Levin commit 16472129ffd728701716532224d8afc2007ed7fa Author: Konrad Dybcio Date: Tue Jan 20 12:19:26 2026 +0100 clk: qcom: dispcc-sc7180: Add missing MDSS resets [ Upstream commit b0bc6011c5499bdfddd0390262bfa13dce1eff74 ] The MDSS resets have so far been left undescribed. Fix that. Fixes: dd3d06622138 ("clk: qcom: Add display clock controller driver for SC7180") Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Reviewed-by: Taniya Das Tested-by: Val Packett # sc7180-ecs-liva-qc710 Link: https://lore.kernel.org/r/20260120-topic-7180_dispcc_bcr-v1-2-0b1b442156c3@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 28e796ac02793c75a017b0f055940cce112cdf4c Author: Konrad Dybcio Date: Tue Jan 20 12:19:25 2026 +0100 dt-bindings: clock: qcom,dispcc-sc7180: Define MDSS resets [ Upstream commit fc6e29d42872680dca017f2e5169eefe971f8d89 ] The MDSS resets have so far been left undescribed. Fix that. Fixes: 75616da71291 ("dt-bindings: clock: Introduce QCOM sc7180 display clock bindings") Signed-off-by: Konrad Dybcio Reviewed-by: Taniya Das Acked-by: Krzysztof Kozlowski Tested-by: Val Packett # sc7180-ecs-liva-qc710 Link: https://lore.kernel.org/r/20260120-topic-7180_dispcc_bcr-v1-1-0b1b442156c3@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: b0bc6011c549 ("clk: qcom: dispcc-sc7180: Add missing MDSS resets") Signed-off-by: Sasha Levin commit a0195eab4ed5d06a018e1c09302f7887c1a9a726 Author: Geert Uytterhoeven Date: Thu Mar 5 11:11:16 2026 +0100 clk: xgene: Fix mapping leak in xgene_pllclk_init() [ Upstream commit f520a492e07bc6718e26cfb7543ab4cadd8bb0e2 ] If xgene_register_clk_pll() fails, the mapped register block is never unmapped. Fixes: 308964caeebc45eb ("clk: Add APM X-Gene SoC clock driver") Signed-off-by: Geert Uytterhoeven Reviewed-by: Brian Masney Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 558b2eb623f2fb1b128df7dd157e1077b60988e6 Author: Arnd Bergmann Date: Fri Mar 20 16:18:49 2026 +0100 clk: qoriq: avoid format string warning [ Upstream commit 096abbb6682ee031a0f5ce9f4c71ead9fa63d31e ] clang-22 warns about the use of non-variadic format arguments passed into snprintf(): drivers/clk/clk-qoriq.c:925:39: error: diagnostic behavior may be improved by adding the 'format(printf, 7, 8)' attribute to the declaration of 'create_mux_common' [-Werror,-Wmissing-format-attribute] 910 | static struct clk * __init create_mux_common(struct clockgen *cg, | __attribute__((format(printf, 7, 8))) 911 | struct mux_hwclock *hwc, 912 | const struct clk_ops *ops, 913 | unsigned long min_rate, 914 | unsigned long max_rate, 915 | unsigned long pct80_rate, 916 | const char *fmt, int idx) 917 | { 918 | struct clk_init_data init = {}; 919 | struct clk *clk; 920 | const struct clockgen_pll_div *div; 921 | const char *parent_names[NUM_MUX_PARENTS]; 922 | char name[32]; 923 | int i, j; 924 | 925 | snprintf(name, sizeof(name), fmt, idx); | ^ drivers/clk/clk-qoriq.c:910:28: note: 'create_mux_common' declared here 910 | static struct clk * __init create_mux_common(struct clockgen *cg, Rework this to pass the 'int idx' as a varargs argument, allowing the format string to be verified at the caller location. Fixes: 0dfc86b3173f ("clk: qoriq: Move chip-specific knowledge into driver") Signed-off-by: Arnd Bergmann Reviewed-by: Kees Cook Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 07410592862686ad3be4906b1fcabc253d3961d8 Author: Thomas Weißschuh Date: Wed Mar 18 22:03:26 2026 +0100 x86/um: fix vDSO installation [ Upstream commit d1895c15fc7d90a615bc8c455feb02acaf08ef1e ] The generic vDSO installation logic used by 'make vdso_install' requires that $(vdso-install-y) is defined by the top-level architecture Makefile and that it contains a path relative to the root of the tree. For UML neither of these is satisfied. Move the definition of $(vdso-install-y) to a place which is included by the arch/um/Makefile and use the full relative path. Fixes: f1c2bb8b9964 ("um: implement a x86_64 vDSO") Signed-off-by: Thomas Weißschuh Link: https://patch.msgid.link/20260318-um-vdso-install-v1-1-26a4ca5c4210@weissschuh.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 0f548ecd2d7812a27498bcf8b0b0656b9c21567a Author: Thomas Weißschuh Date: Mon Oct 13 12:40:21 2025 +0200 x86/um/vdso: Drop VDSO64-y from Makefile [ Upstream commit 3c9b904f9033fb250db72d258bbdec791dc89405 ] This symbol is unnecessary, remove it. Signed-off-by: Thomas Weißschuh Link: https://patch.msgid.link/20251013-uml-vdso-cleanup-v1-4-a079c7adcc69@weissschuh.net Signed-off-by: Johannes Berg Stable-dep-of: d1895c15fc7d ("x86/um: fix vDSO installation") Signed-off-by: Sasha Levin commit b55d2128faf54d10a9d116025cb788a09f22b0aa Author: Sebastian Krzyszkowiak Date: Wed Jan 28 00:47:21 2026 +0100 clk: imx8mq: Correct the CSI PHY sels [ Upstream commit d16f57caa78776e6e8a88b96cb2597797b376138 ] According to i.MX 8M Quad Reference Manual (Section 5.1.2 Table 5-1) MIPI_CSI1_PHY_REF_CLK_ROOT and MIPI_CSI2_PHY_REF_CLK_ROOT have SYSTEM_PLL2_DIV3 available as their second source, which corresponds to sys2_pll_333m rather than sys2_pll_125m. Fixes: b80522040cd3 ("clk: imx: Add clock driver for i.MX8MQ CCM") Signed-off-by: Sebastian Krzyszkowiak Reviewed-by: Peng Fan Link: https://patch.msgid.link/20260128-imx8mq-csi-clk-v1-1-ac028ed26e8c@puri.sm Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin commit e3d41039263dde6bcc933cebff98e2c94d66e30f Author: Felix Gu Date: Tue Feb 3 22:07:58 2026 +0800 clk: imx: imx6q: Fix device node reference leak in of_assigned_ldb_sels() [ Upstream commit 9faf207208951460f3f7eefbc112246c8d28ff1b ] The function of_assigned_ldb_sels() calls of_parse_phandle_with_args() but never calls of_node_put() to release the reference, causing a memory leak. Fix this by adding proper cleanup calls on all exit paths. Fixes: 5d283b083800 ("clk: imx6: Fix procedure to switch the parent of LDB_DI_CLK") Signed-off-by: Felix Gu Reviewed-by: Frank Li Reviewed-by: Peng Fan Link: https://patch.msgid.link/20260203-clk-imx6q-v3-2-6cd2696bb371@gmail.com Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin commit 3cb3f533424b2f07eddd7c33773782c655bdd1b7 Author: Felix Gu Date: Tue Feb 3 22:07:57 2026 +0800 clk: imx: imx6q: Fix device node reference leak in pll6_bypassed() [ Upstream commit 4b84d496c804b470124cd3a08e928df6801d8eae ] The function pll6_bypassed() calls of_parse_phandle_with_args() but never calls of_node_put() to release the reference, causing a memory leak. Fix this by adding proper cleanup calls on all exit paths. Fixes: 3cc48976e9763 ("clk: imx6q: handle ENET PLL bypass") Signed-off-by: Felix Gu Reviewed-by: Frank Li Reviewed-by: Peng Fan Link: https://patch.msgid.link/20260203-clk-imx6q-v3-1-6cd2696bb371@gmail.com Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin commit 8ae85245632c26da86a2936afd352364d96e7332 Author: Val Packett Date: Thu Mar 12 08:12:13 2026 -0300 clk: qcom: dispcc-sm8250: Enable parents for pixel clocks [ Upstream commit acf7a91d0b0e9e3ef374944021de62062125b7e4 ] Add CLK_OPS_PARENT_ENABLE to MDSS pixel clock sources to ensure parent clocks are enabled during clock operations, preventing potential stability issues during display configuration. Fixes: 80a18f4a8567 ("clk: qcom: Add display clock controller driver for SM8150 and SM8250") Signed-off-by: Val Packett Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260312112321.370983-9-val@packett.cool Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d7f633fc6e4d2d4a96017c64e17f962e469b28c0 Author: Val Packett Date: Thu Mar 12 08:12:12 2026 -0300 clk: qcom: dispcc-sm8250: Use shared ops on the mdss vsync clk [ Upstream commit 8c522da70f0c2e5148c4c13ccb1c64cca57a6fdb ] mdss_gdsc can get stuck on boot due to RCGs being left on from last boot. As a fix, commit 01a0a6cc8cfd ("clk: qcom: Park shared RCGs upon registration") introduced a callback to ensure the RCG is off upon init. However, the fix depends on all shared RCGs being marked as such in code. For SM8150/SC8180X/SM8250 the MDSS vsync clock was using regular ops, unlike the same clock in the SC7180 code. This was causing display to frequently fail to initialize after rebooting on the Surface Pro X. Fix by using shared ops for this clock. Fixes: 80a18f4a8567 ("clk: qcom: Add display clock controller driver for SM8150 and SM8250") Signed-off-by: Val Packett Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260312112321.370983-8-val@packett.cool Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d79e6ca14c559e0e0add8431a57c82e321a8ce9b Author: Val Packett Date: Thu Mar 12 08:12:09 2026 -0300 clk: qcom: gcc-sc8180x: Use retention for PCIe power domains [ Upstream commit ccb92c78b42edd26225b4d5920847dfee3e1b093 ] As the PCIe host controller driver does not yet support dealing with the loss of state during suspend, use retention for relevant GDSCs. This fixes the link not surviving upon resume: nvme 0002:01:00.0: Unable to change power state from D3cold to D0, device inaccessible nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS read failed (134) nvme 0002:01:00.0: Unable to change power state from D3cold to D0, device inaccessible nvme nvme0: Disabling device after reset failure: -19 Fixes: 4433594bbe5d ("clk: qcom: gcc: Add global clock controller driver for SC8180x") Reviewed-by: Dmitry Baryshkov Signed-off-by: Val Packett Reviewed-by: Konrad Dybcio Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260312112321.370983-5-val@packett.cool Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a263813276f9a4bbe49c0ce4e2eb58d50b573336 Author: Val Packett Date: Thu Mar 12 08:12:08 2026 -0300 clk: qcom: gcc-sc8180x: Use retention for USB power domains [ Upstream commit 25bc96f26cd6c19dde13a0b9859183e531d6fbfc ] The USB subsystem does not expect to lose its state on suspend: xhci-hcd xhci-hcd.0.auto: xHC error in resume, USBSTS 0x401, Reinit usb usb1: root hub lost power or was reset (The reinitialization usually succeeds, but it does slow down resume.) To maintain state during suspend, the relevant GDSCs need to stay in retention mode, like they do on other similar SoCs. Change the mode to PWRSTS_RET_ON to fix. Fixes: 4433594bbe5d ("clk: qcom: gcc: Add global clock controller driver for SC8180x") Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Val Packett Link: https://lore.kernel.org/r/20260312112321.370983-4-val@packett.cool Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit ed9ca2c4dc02934de42be1a240dcdc480994fb51 Author: Val Packett Date: Thu Mar 12 08:12:07 2026 -0300 clk: qcom: gcc-sc8180x: Add missing GDSCs [ Upstream commit 3565741eb985a8a7cc6656eb33496195468cb99e ] There are 5 more GDSCs that we were ignoring and not putting to sleep, which are listed in downstream DTS. Add them. Fixes: 4433594bbe5d ("clk: qcom: gcc: Add global clock controller driver for SC8180x") Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Val Packett Link: https://lore.kernel.org/r/20260312112321.370983-3-val@packett.cool Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 841d495177685c779a5b4c943ba95a4e08573427 Author: Val Packett Date: Thu Mar 12 08:12:06 2026 -0300 dt-bindings: clock: qcom,gcc-sc8180x: Add missing GDSCs [ Upstream commit 76404ffbf07f28a5ec04748e18fce3dac2e78ef6 ] There are 5 more GDSCs that we were ignoring and not putting to sleep, which are listed in downstream DTS. Add them. Signed-off-by: Val Packett Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20260312112321.370983-2-val@packett.cool Signed-off-by: Bjorn Andersson Stable-dep-of: 3565741eb985 ("clk: qcom: gcc-sc8180x: Add missing GDSCs") Signed-off-by: Sasha Levin commit a2fb7c42ab9b2fec12f39864b8aa0d81efbaa2d1 Author: Shawn Lin Date: Fri Mar 13 10:21:07 2026 +0800 scsi: ufs: rockchip,rk3576-ufshc: dt-bindings: Add new mphy reset item [ Upstream commit bdce3a69c578090dd5e3c77bcdaaca10c3a41e34 ] Add the mphy reset property to the devicetree bindings for the Rockchip RK3576 UFS host controller. The mphy reset signal is used to reset the physical adapter. Resetting other components while leaving the mphy unreset may occasionally prevent the UFS controller from successfully linking up with the device. This addresses an intermittent hardware bug where the UFS link fails to establish under specific timing conditions with certain chips. While difficult to reproduce initially, this issue was consistently observed in downstream testing and requires explicit mphy reset control for full stability. Although this change increases the maxItems for resets and adds a new entry (which technically alters the binding ABI), it does not break compatibility for existing Linux systems. The driver uses devm_reset_control_array_get_exclusive() to manage resets, allowing it to function correctly with both older Device Trees (without the mphy entry) and newer ones. Fixes: d90e92023771 ("scsi: ufs: dt-bindings: Document Rockchip UFS host controller") Signed-off-by: Shawn Lin Reviewed-by: Krzysztof Kozlowski Link: https://patch.msgid.link/1773368467-109650-1-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 51075df70c46e60a9773f2dcd28299e40dac36fb Author: Junrui Luo Date: Wed Mar 4 23:42:58 2026 +0800 scsi: target: core: Fix integer overflow in UNMAP bounds check [ Upstream commit 2bf2d65f76697820dbc4227d13866293576dd90a ] sbc_execute_unmap() checks LBA + range does not exceed the device capacity, but does not guard against LBA + range wrapping around on 64-bit overflow. Add an overflow check matching the pattern already used for WRITE_SAME in the same file. Fixes: 86d7182985d2 ("target: Add sbc_execute_unmap() helper") Reported-by: Yuhao Jiang Signed-off-by: Junrui Luo Link: https://patch.msgid.link/SYBPR01MB7881593C61AD52C69FBDB0BDAF7CA@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ac0411865e3e7a4d0446595df1d753c5040f0cf6 Author: Fabrizio Castro Date: Tue Feb 3 12:42:47 2026 +0000 clk: renesas: r9a09g057: Remove entries for WDT{0,2,3} [ Upstream commit 1b4f047dc4010d51821694cc4ed73b52b3040a5c ] The HW user manual for the Renesas RZ/V2H(P) SoC specifies that only the WDT1 IP is supposed to be used by Linux, while the WDT{0,2,3} IPs are supposed to be used by the CM33 and CR8 cores. Remove the clock and reset entries for WDT{0,2,3} to prevent interfering with the CM33 and CR8 cores. This change is harmless as only WDT1 is used by Linux, there are no users for the WDT{0,2,3} cores. Fixes: 3aeccbe08171 ("clk: renesas: r9a09g057: Add clock and reset entries for GTM/RIIC/SDHI/WDT") Signed-off-by: Fabrizio Castro Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260203124247.7320-4-fabrizio.castro.jz@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 3c0a96358c1324b23b608efe4b04daecb6ea3e02 Author: Ovidiu Panait Date: Sun Jan 25 19:03:14 2026 +0000 clk: renesas: r9a09g057: Fix ordering of module clocks array [ Upstream commit 79cac2b8dc1d9f63fbf6c6793e423052118cc51a ] The r9a09g057_mod_clks array is sorted by CPG_CLKON register number and bit position. Move the RTC and RSPI module clock entries to their correct position to restore the array sort order. Fixes: 2efea3b35cc9 ("clk: renesas: r9a09g057: Add entries for RSCIs") Signed-off-by: Ovidiu Panait Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260125190314.26729-1-ovidiu.panait.rb@renesas.com Signed-off-by: Geert Uytterhoeven Stable-dep-of: 1b4f047dc401 ("clk: renesas: r9a09g057: Remove entries for WDT{0,2,3}") Signed-off-by: Sasha Levin commit 21aae9f766a3e43263ae3c98639b37c167beccc2 Author: Lad Prabhakar Date: Wed Dec 3 09:41:47 2025 +0000 clk: renesas: r9a09g057: Add entries for RSCIs [ Upstream commit 2efea3b35cc916f04f06b89f2e2557dbd9c48109 ] Add clock and reset entries for the RSCI IPs. Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20251203094147.6429-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Stable-dep-of: 1b4f047dc401 ("clk: renesas: r9a09g057: Remove entries for WDT{0,2,3}") Signed-off-by: Sasha Levin commit 34e869e21080f137678ef978c70efd2fd0ef1197 Author: Ovidiu Panait Date: Tue Oct 21 08:07:00 2025 +0000 clk: renesas: r9a09g057: Add clock and reset entries for RTC [ Upstream commit 7a03ef9f8223434f19e19a37acc32dcb581ab475 ] Add module clock and reset entries for the RTC module on the Renesas RZ/V2H (R9A09G057) SoC. Signed-off-by: Ovidiu Panait Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20251021080705.18116-2-ovidiu.panait.rb@renesas.com Signed-off-by: Geert Uytterhoeven Stable-dep-of: 1b4f047dc401 ("clk: renesas: r9a09g057: Remove entries for WDT{0,2,3}") Signed-off-by: Sasha Levin commit 87534f2a3842749973ea43b21efc5346ce196b86 Author: Konrad Dybcio Date: Wed Mar 4 14:48:31 2026 +0100 clk: qcom: dispcc[01]-sa8775p: Fix DSI byte clock rate setting [ Upstream commit 2851b6c6a42e22c243aa4cd606a49e2b9acfb6d6 ] The clock tree for byte_clk_src is as follows: ┌──────byte0_clk_src─────┐ │ │ byte0_clk byte0_div_clk_src │ byte0_intf_clk If both of its direct children have CLK_SET_RATE_PARENT with different requests, byte0_clk_src (and its parent) will be reconfigured. In this case, byte0_intf should strictly follow the rate of byte0_clk (with some adjustments based on PHY mode). Remove CLK_SET_RATE_PARENT from byte0_div_clk_src to avoid this issue. Fixes: e700bfd2f976 ("clk: qcom: Add support for Display clock Controllers on SA8775P") Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260304-topic-dsi_byte_fixup-v1-5-b79b29f83176@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit b92a29da9f7e114c05fd549cc388c0c26c338492 Author: Konrad Dybcio Date: Wed Mar 4 14:48:30 2026 +0100 clk: qcom: dispcc-sm4450: Fix DSI byte clock rate setting [ Upstream commit 7bc48fcdf9e77bf68ef04af015d50df2a9acac00 ] The clock tree for byte_clk_src is as follows: ┌──────byte0_clk_src─────┐ │ │ byte0_clk byte0_div_clk_src │ byte0_intf_clk If both of its direct children have CLK_SET_RATE_PARENT with different requests, byte0_clk_src (and its parent) will be reconfigured. In this case, byte0_intf should strictly follow the rate of byte0_clk (with some adjustments based on PHY mode). Remove CLK_SET_RATE_PARENT from byte0_div_clk_src to avoid this issue. Fixes: 76f05f1ec766 ("clk: qcom: Add DISPCC driver support for SM4450") Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260304-topic-dsi_byte_fixup-v1-4-b79b29f83176@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit b0015d7752afd9444d9fe06ad7604769ad9e5eb6 Author: Konrad Dybcio Date: Wed Mar 4 14:48:29 2026 +0100 clk: qcom: dispcc-milos: Fix DSI byte clock rate setting [ Upstream commit dd5b76257b4048151006620c9895e2f5f0d997eb ] The clock tree for byte_clk_src is as follows: ┌──────byte0_clk_src─────┐ │ │ byte0_clk byte0_div_clk_src │ byte0_intf_clk If both of its direct children have CLK_SET_RATE_PARENT with different requests, byte0_clk_src (and its parent) will be reconfigured. In this case, byte0_intf should strictly follow the rate of byte0_clk (with some adjustments based on PHY mode). Remove CLK_SET_RATE_PARENT from byte0_div_clk_src to avoid this issue. Fixes: f40b5217dce1 ("clk: qcom: Add Display Clock controller (DISPCC) driver for Milos") Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260304-topic-dsi_byte_fixup-v1-3-b79b29f83176@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 0c7a14a3d5808e0fbaceec6095d6395cf6177c04 Author: Konrad Dybcio Date: Wed Mar 4 14:48:27 2026 +0100 clk: qcom: dispcc-glymur: Fix DSI byte clock rate setting [ Upstream commit 98ea9eda030587601db56425efcd32263d853591 ] The clock tree for byte_clk_src is as follows: ┌──────byte0_clk_src─────┐ │ │ byte0_clk byte0_div_clk_src │ byte0_intf_clk If both of its direct children have CLK_SET_RATE_PARENT with different requests, byte0_clk_src (and its parent) will be reconfigured. In this case, byte0_intf should strictly follow the rate of byte0_clk (with some adjustments based on PHY mode). Remove CLK_SET_RATE_PARENT from byte0_div_clk_src to avoid this issue. Fixes: b4d15211c408 ("clk: qcom: dispcc-glymur: Add support for Display Clock Controller") Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260304-topic-dsi_byte_fixup-v1-1-b79b29f83176@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6c87b3a371fae179cb9788f2c61075c12cdd4265 Author: White Lewis Date: Tue Mar 3 19:55:50 2026 +0800 clk: qcom: dispcc-sc8280xp: remove CLK_SET_RATE_PARENT from byte_div_clk_src dividers [ Upstream commit 0b151a6307205eb867250985a910a88787cbf12e ] The four byte_div_clk_src dividers (disp{0,1}_cc_mdss_byte{0,1}_div_clk_src) had CLK_SET_RATE_PARENT set. When the DSI driver calls clk_set_rate() on byte_intf_clk, the rate-change propagates through the divider up to the parent PLL (byte_clk_src), halving the byte clock rate. A simiar issue had been also encountered on SM8750. b8501febdc51 ("clk: qcom: dispcc-sm8750: Drop incorrect CLK_SET_RATE_PARENT on byte intf parent"). Likewise, remove CLK_SET_RATE_PARENT from all four byte divider clocks so that clk_set_rate() on the divider adjusts only the divider ratio, leaving the parent PLL untouched. Fixes: 4a66e76fdb6d ("clk: qcom: Add SC8280XP display clock controller") Signed-off-by: White Lewis [pengyu: reword] Signed-off-by: Pengyu Luo Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260303115550.9279-1-mitltlatltl@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 1afd963fcd963db0dc5d47df6dfcf010c9c4647e Author: Yang Erkun Date: Tue Jan 27 14:20:43 2026 +0800 scsi: sg: Resolve soft lockup issue when opening /dev/sgX [ Upstream commit d06a310b45e153872033dd0cf19d5a2279121099 ] The parameter def_reserved_size defines the default buffer size reserved for each Sg_fd and should be restricted to a range between 0 and 1,048,576 (see https://tldp.org/HOWTO/SCSI-Generic-HOWTO/proc.html). Although the function sg_proc_write_dressz enforces this limit, it is possible to bypass it by directly modifying the module parameter as shown below, which then causes a soft lockup: echo -1 > /sys/module/sg/parameters/def_reserved_size exec 4<> /dev/sg0 watchdog: BUG: soft lockup - CPU#5 stuck for 26 seconds! [bash:537] Modules loaded: CPU: 5 UID: 0 PID: 537 Command: bash, kernel version 6.19.0-rc3+ #134, PREEMPT disabled Hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS version 1.16.1-2.fc37 dated 04/01/2014 ... Call Trace: sg_build_reserve+0x5c/0xa0 sg_add_sfp+0x168/0x270 sg_open+0x16e/0x340 chrdev_open+0xbe/0x230 do_dentry_open+0x175/0x480 vfs_open+0x34/0xf0 do_open+0x265/0x3d0 path_openat+0x110/0x290 do_filp_open+0xc3/0x170 do_sys_openat2+0x71/0xe0 __x64_sys_openat+0x6d/0xa0 do_syscall_64+0x62/0x310 entry_SYSCALL_64_after_hwframe+0x76/0x7e The fix is to use module_param_cb to validate and reject invalid values assigned to def_reserved_size. Fixes: 6460e75a104d ("[SCSI] sg: fixes for large page_size") Signed-off-by: Yang Erkun Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260127062044.3034148-3-yangerkun@huawei.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 6a4ccbb9b40e9cb3b185890bddc48753a4baeff6 Author: Yang Erkun Date: Tue Jan 27 14:20:42 2026 +0800 scsi: sg: Fix sysctl sg-big-buff register during sg_init() [ Upstream commit 3033c471aaf675254efaa0da431e95d91a104b41 ] Commit 26d1c80fd61e ("scsi/sg: move sg-big-buff sysctl to scsi/sg.c") made a mistake. sysctl sg-big-buff was not created because the call to register_sg_sysctls() was placed on the wrong code path. Fixes: 26d1c80fd61e ("scsi/sg: move sg-big-buff sysctl to scsi/sg.c") Signed-off-by: Yang Erkun Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260127062044.3034148-2-yangerkun@huawei.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b9ab6cf1c2ef598e1d74dc37e171cda92d3884fa Author: Chen-Yu Tsai Date: Tue Feb 17 17:30:03 2026 +0800 clk: sunxi-ng: sun55i-a523-r: Add missing r-spi module clock [ Upstream commit fb20ccf70cf695f178d7c32e2d33b376560df0ff ] When the PRCM clk driver was added, somehow the r-spi module clock was skipped over. Add it so that r-spi can actually work. Fixes: 8cea339cfb81 ("clk: sunxi-ng: add support for the A523/T527 PRCM CCU") Reviewed-by: Andre Przywara Reviewed-by: Jernej Skrabec Link: https://patch.msgid.link/20260217093004.3239051-1-wens@kernel.org Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit e906a312ee06ef301e3401d24db5ff82aa22ab3a Author: Dmitry Baryshkov Date: Mon Jan 12 04:12:23 2026 +0200 clk: qcom: dispcc-sm8450: use RCG2 ops for DPTX1 AUX clock source [ Upstream commit 141af1be817c42c7f1e1605348d4b1983d319bea ] The clk_dp_ops are supposed to be used for DP-related clocks with a proper MND divier. Use standard RCG2 ops for dptx1_aux_clk_src, the same as all other DPTX AUX clocks in this driver. Fixes: 16fb89f92ec4 ("clk: qcom: Add support for Display Clock Controller on SM8450") Signed-off-by: Dmitry Baryshkov Reviewed-by: Abel Vesa Reviewed-by: Konrad Dybcio Reviewed-by: Taniya Das Link: https://lore.kernel.org/r/20260112-dp-aux-clks-v1-2-456b0c11b069@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 89715e519ab7900ea40c7f86a90072ed697b748d Author: Dmitry Baryshkov Date: Mon Jan 12 04:12:22 2026 +0200 clk: qcom: dispcc-glymur: use RCG2 ops for DPTX1 AUX clock source [ Upstream commit e7c8eb1646db5d967d77ee67793dd95a2c5ff451 ] The clk_dp_ops are supposed to be used for DP-related clocks with a proper MND divier. Use shared RCG2 ops for dptx1_aux_clk_src, the same as all other DPTX AUX clocks in this driver. Fixes: b4d15211c408 ("clk: qcom: dispcc-glymur: Add support for Display Clock Controller") Signed-off-by: Dmitry Baryshkov Reviewed-by: Abel Vesa Reviewed-by: Konrad Dybcio Reviewed-by: Taniya Das Link: https://lore.kernel.org/r/20260112-dp-aux-clks-v1-1-456b0c11b069@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 1e56e335bc86044539252ae238d5c3be281b38c7 Author: Taniya Das Date: Mon Feb 2 16:26:52 2026 +0530 clk: qcom: gcc-glymur: Add video axi clock resets for glymur [ Upstream commit 1c8ce43e1e07ecc531fb517f95620ed85e998608 ] The global clock controller video axi reset clocks are required by the video SW driver to assert and deassert the clock resets during their power down sequence. Hence add these clock resets. Fixes: efe504300a17 ("clk: qcom: gcc: Add support for Global Clock Controller") Signed-off-by: Taniya Das Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260202-glymur_videocc-v2-3-8f7d8b4d8edd@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 927c8a511c2aa01d0f380fe36d13ef0c8d65a728 Author: Taniya Das Date: Mon Feb 2 16:26:50 2026 +0530 dt-bindings: clock: qcom: Add GCC video axi reset clock for Glymur [ Upstream commit 7c3260327fc874b7c89d7bb230cd569d2e78aff7 ] The global clock controller video axi reset clocks are required by the video SW driver to assert and deassert the clock resets. Signed-off-by: Taniya Das Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20260202-glymur_videocc-v2-1-8f7d8b4d8edd@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 1c8ce43e1e07 ("clk: qcom: gcc-glymur: Add video axi clock resets for glymur") Signed-off-by: Sasha Levin commit f2c7b39dde2e61df8157066969cc2a408cd3dcd9 Author: Florian Westphal Date: Mon Mar 30 14:27:39 2026 +0200 RDMA/core: Prefer NLA_NUL_STRING [ Upstream commit 6ed3d14fc45d3da6025e7fe4a6a09066856698e2 ] These attributes are evaluated as c-string (passed to strcmp), but NLA_STRING doesn't check for the presence of a \0 terminator. Either this needs to switch to nla_strcmp() and needs to adjust printf fmt specifier to not use plain %s, or this needs to use NLA_NUL_STRING. As the code has been this way for long time, it seems to me that userspace does include the terminating nul, even tough its not enforced so far, and thus NLA_NUL_STRING use is the simpler solution. Fixes: 30dc5e63d6a5 ("RDMA/core: Add support for iWARP Port Mapper user space service") Link: https://patch.msgid.link/r/20260330122742.13315-1-fw@strlen.de Signed-off-by: Florian Westphal Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit c5683ca4949a514fbe656c6d0d08c4c126e21db9 Author: Pengpeng Hou Date: Wed Apr 8 08:38:21 2026 +0800 platform/x86: dell-wmi-sysman: bound enumeration string aggregation [ Upstream commit 3c34471c26abc52a37f5ad90949e2e4b8027eb14 ] populate_enum_data() aggregates firmware-provided value-modifier and possible-value strings into fixed 512-byte struct members. The current code bounds each individual source string but then appends every string and separator with raw strcat() and no remaining-space check. Switch the aggregation loops to a bounded append helper and reject enumeration packages whose combined strings do not fit in the destination buffers. Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260408084501.1-dell-wmi-sysman-v2-pengpeng@iscas.ac.cn [ij: add include] Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 58688eeaa3079ff20e85faa7c5727dee2074cfb1 Author: Fedor Pchelkin Date: Fri Apr 3 16:42:39 2026 +0300 platform/x86: dell_rbu: avoid uninit value usage in packet_size_write() [ Upstream commit f8fd138c2363c0e2d3235c32bfb4fb5c6474e4ae ] Ensure the temp value has been properly parsed from the user-provided buffer and initialized to be used in later operations. While at it, prefer a convenient kstrtoul() helper. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool. Fixes: ad6ce87e5bd4 ("[PATCH] dell_rbu: changes in packet update mechanism") Signed-off-by: Fedor Pchelkin Link: https://patch.msgid.link/20260403134240.604837-1-pchelkin@ispras.ru [ij: add include] Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 6136bbb054f7ab9f51ae99915541633b18bcef90 Author: Pengpeng Hou Date: Fri Mar 27 14:19:55 2026 +0800 fs/ntfs3: terminate the cached volume label after UTF-8 conversion [ Upstream commit a6cd43fe9b083fa23fe1595666d5738856cb261a ] ntfs_fill_super() loads the on-disk volume label with utf16s_to_utf8s() and stores the result in sbi->volume.label. The converted label is later exposed through ntfs3_label_show() using %s, but utf16s_to_utf8s() only returns the number of bytes written and does not add a trailing NUL. If the converted label fills the entire fixed buffer, ntfs3_label_show() can read past the end of sbi->volume.label while looking for a terminator. Terminate the cached label explicitly after a successful conversion and clamp the exact-full case to the last byte of the buffer. Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block") Signed-off-by: Pengpeng Hou Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit c44ad02d591bac06e57a701cff980150bcb2d356 Author: Thomas Bogendoerfer Date: Thu Apr 2 12:21:53 2026 +0200 tty: serial: ip22zilog: Fix section mispatch warning [ Upstream commit a1a81aef99e853dec84241d701fbf587d713eb5b ] ip22zilog_prepare() is now called by driver probe routine, so it shouldn't be in the __init section any longer. Fixes: 3fc36ae6abd2 ("tty: serial: ip22zilog: Use platform device for probing") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202604020945.c9jAvCPs-lkp@intel.com/ Signed-off-by: Thomas Bogendoerfer Link: https://patch.msgid.link/20260402102154.136620-1-tbogendoerfer@suse.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit bfd3e5309503380fca1fe2d73c94a1b33dfc4801 Author: Denis Benato Date: Mon Mar 2 18:44:31 2026 +0100 platform/x86: asus-wmi: fix screenpad brightness range [ Upstream commit 8d95d1f4aa5c76202b0833a70998769384612488 ] Fix screenpad brightness range being too limited without reason: testing this patch on a Zenbook Duo showed the hardware minimum not being too low, therefore allow the user to configure the entire range, and expose to userspace the hardware brightness range and value. Fixes: 2c97d3e55b70 ("platform/x86: asus-wmi: add support for ASUS screenpad") Signed-off-by: Denis Benato Signed-off-by: Luke Jones Link: https://patch.msgid.link/20260302174431.349816-3-denis.benato@linux.dev Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 38a9aa192ef73b6c0d3e96a39e8d81fbcb30b982 Author: Denis Benato Date: Mon Mar 2 18:44:30 2026 +0100 platform/x86: asus-wmi: adjust screenpad power/brightness handling [ Upstream commit 130d29c5627cd50e786e926ad7ef66322c5a0c09 ] Fix illogical screen off control by hardcoding 0 and 1 depending on the requested brightness and also do not rely on the last screenpad power state to issue screen brightness commands. Fixes: 2c97d3e55b70 ("platform/x86: asus-wmi: add support for ASUS screenpad") Signed-off-by: Denis Benato Signed-off-by: Luke Jones Link: https://patch.msgid.link/20260302174431.349816-2-denis.benato@linux.dev Link: https://patch.msgid.link/20260326231154.856729-2-ethantidmore06@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 4584229395d0d65bd517780afe97ffea07cb2c3d Author: Dai Ngo Date: Wed Feb 4 13:07:43 2026 -0800 NFSD: fix nfs4_file access extra count in nfsd4_add_rdaccess_to_wrdeleg [ Upstream commit b48f44f36e6607b2f818560f19deb86b4a9c717b ] In nfsd4_add_rdaccess_to_wrdeleg, if fp->fi_fds[O_RDONLY] is already set by another thread, __nfs4_file_get_access should not be called to increment the nfs4_file access count since that was already done by the thread that added READ access to the file. The extra fi_access count in nfs4_file can prevent the corresponding nfsd_file from being freed. When stopping nfs-server service, these extra access counts trigger a BUG in kmem_cache_destroy() that shows nfsd_file object remaining on __kmem_cache_shutdown. This problem can be reproduced by running the Git project's test suite over NFS. Fixes: 8072e34e1387 ("nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg()") Signed-off-by: Dai Ngo Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 248e4b9cc719ffd92f939d4b85fc21480eb0c829 Author: Andy Shevchenko Date: Wed Feb 4 21:21:49 2026 +0100 nfs/blocklayout: Fix compilation error (`make W=1`) in bl_write_pagelist() [ Upstream commit f83c8dda456ce4863f346aa26d88efa276eda35d ] Clang compiler is not happy about set but unused variable (when dprintk() is no-op): .../blocklayout/blocklayout.c:384:9: error: variable 'count' set but not used [-Werror,-Wunused-but-set-variable] Remove a leftover from the previous cleanup. Fixes: 3a6fd1f004fc ("pnfs/blocklayout: remove read-modify-write handling in bl_write_pagelist") Acked-by: Anna Schumaker Reviewed-by: Jeff Layton Signed-off-by: Andy Shevchenko Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit ac8551a4254d6d8939dd61147d74b449f15da774 Author: Abdun Nihaal Date: Tue Jan 20 15:56:20 2026 +0530 mfd: mc13xxx-core: Fix memory leak in mc13xxx_add_subdevice_pdata() [ Upstream commit a5a65a7fb2f7796bbe492cd6be59c92cb64377d1 ] The memory allocated for cell.name using kmemdup() is not freed when mfd_add_devices() fails. Fix that by using devm_kmemdup(). Fixes: 8e00593557c3 ("mfd: Add mc13892 support to mc13xxx") Signed-off-by: Abdun Nihaal Link: https://patch.msgid.link/20260120102622.66921-1-nihaal@cse.iitm.ac.in Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit cc7716bd050be5bd8d69b9dacbac25780d7d8ca3 Author: Dmitry Torokhov Date: Wed Mar 18 19:56:17 2026 -0700 platform/x86: barco-p50-gpio: normalize return value of gpio_get [ Upstream commit 1c9d30d37aaffe3454d70b89a77f8aaecda257bf ] The GPIO get callback is expected to return 0 or 1 (or a negative error code). Ensure that the value returned by p50_gpio_get() is normalized to the [0, 1] range. Fixes: 86ef402d805d606a ("gpiolib: sanitize the return value of gpio_chip::get()") Reviewed-by: Linus Walleij Signed-off-by: Dmitry Torokhov Reviewed-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260318-barco-p50-gpio-set-v2-1-c0a4a6416163@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit e4a666652daece49053264c0590393a0a183c0e9 Author: Rafael J. Wysocki Date: Fri Mar 20 11:31:54 2026 +0100 platform/x86: panasonic-laptop: Fix OPTD notifier registration and cleanup [ Upstream commit 8baeff2c1d33dad8572216c6ad3a7425852507d4 ] An ACPI notify handler is leaked if device_create_file() returns an error in acpi_pcc_hotkey_add(). Also, it is pointless to call pcc_unregister_optd_notifier() in acpi_pcc_hotkey_remove() if pcc->platform is NULL and it is better to arrange the cleanup code in that function in the same order as the rollback code in acpi_pcc_hotkey_add(). Address the above by placing the pcc_register_optd_notifier() call in acpi_pcc_hotkey_add() after the device_create_file() return value check and placing the pcc_unregister_optd_notifier() call in acpi_pcc_hotkey_remove() right before the device_remove_file() call. Fixes: d5a81d8e864b ("platform/x86: panasonic-laptop: Add support for optical driver power in Y and W series") Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2411055.ElGaqSPkdT@rafael.j.wysocki Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 37a3d1b6827783f26d2f8e6c7683e253ba79ae93 Author: Mostafa Saleh Date: Fri Mar 13 15:55:34 2026 +0000 usb: typec: ps883x: Fix Oops at unbind [ Upstream commit 381133848a033c2086cf9cafb226f425bd0414ff ] When trying to unbind a device in order to bind to it vfio-platform as: echo bc0000.geniqup > /sys/bus/platform/devices/bc0000.geniqup/driver/unbind I get the following Oops: [ 436.478639] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 [ 436.487762] Mem abort info: [ 436.490716] ESR = 0x0000000096000004 [ 436.494595] EC = 0x25: DABT (current EL), IL = 32 bits [ 436.500071] SET = 0, FnV = 0 [ 436.503250] EA = 0, S1PTW = 0 [ 436.506505] FSC = 0x04: level 0 translation fault [ 436.511533] Data abort info: [ 436.514558] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 436.520215] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 436.525436] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 436.530918] user pgtable: 4k pages, 48-bit VAs, pgdp=00000008861a9000 [ 436.537554] [0000000000000020] pgd=0000000000000000, p4d=0000000000000000 [ 436.544548] Internal error: Oops: 0000000096000004 [#1] SMP [ 436.550374] Modules linked in: [ 436.553542] CPU: 2 UID: 0 PID: 671 Comm: bash Tainted: G W 7.0.0-rc3-g56fcdd0911a5-dirty #2 PREEMPT [ 436.564440] Tainted: [W]=WARN [ 436.567515] Hardware name: LENOVO 91B6CTO1WW/3796, BIOS O6NKT3BA 05/02/2025 [ 436.574675] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 436.581841] pc : ps883x_retimer_remove+0x14/0x94 [ 436.586605] lr : i2c_device_remove+0x28/0x84 [ 436.591017] sp : ffff8000847137c0 That's because the ps883x_retimer_remove() retrieves the driver data from i2c_get_clientdata() which was never set at probe. So, add i2c_set_clientdata() at the end of the probe. Signed-off-by: Mostafa Saleh Reviewed-by: Konrad Dybcio Fixes: 257a087c8b52 ("usb: typec: Add support for Parade PS8830 Type-C Retimer") Link: https://patch.msgid.link/20260313155534.1916773-1-smostafa@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3104a3f40feb107f77d7116ad9bf6c210ab7babf Author: Randy Dunlap Date: Thu Jan 29 23:29:37 2026 -0800 tty: hvc_iucv: fix off-by-one in number of supported devices [ Upstream commit f2a880e802ad12d1e38039d1334fb1475d0f5241 ] MAX_HVC_IUCV_LINES == HVC_ALLOC_TTY_ADAPTERS == 8. This is the number of entries in: static struct hvc_iucv_private *hvc_iucv_table[MAX_HVC_IUCV_LINES]; Sometimes hvc_iucv_table[] is limited by: (a) if (num > hvc_iucv_devices) // for error detection or (b) for (i = 0; i < hvc_iucv_devices; i++) // in 2 places (so these 2 don't agree; second one appears to be correct to me.) hvc_iucv_devices can be 0..8. This is a counter. (c) if (hvc_iucv_devices > MAX_HVC_IUCV_LINES) If hvc_iucv_devices == 8, (a) allows the code to access hvc_iucv_table[8]. Oops. Fixes: 44a01d5ba8a4 ("[S390] s390/hvc_console: z/VM IUCV hypervisor console support") Signed-off-by: Randy Dunlap Link: https://patch.msgid.link/20260130072939.1535869-1-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 19951118fb22b5ad512379ee64510fe0e2c40eb3 Author: Ethan Tidmore Date: Wed Feb 18 15:46:21 2026 -0600 usb: typec: Fix error pointer dereference [ Upstream commit f2529d08fcb429ea01bb87c326342f41483f8b2f ] The variable tps->partner is checked for an error pointer and then if it is, it sends an error message but does not return and then immediately dereferenced a few lines below: tps->partner = typec_register_partner(tps->port, &desc); if (IS_ERR(tps->partner)) dev_warn(tps->dev, "%s: failed to register partnet\n", __func__); if (desc.identity) { typec_partner_set_identity(tps->partner); cd321x->cur_partner_identity = st.partner_identity; } Add early return and fix spelling mistake in error message. Detected by Smatch: drivers/usb/typec/tipd/core.c:827 cd321x_update_work() error: 'tps->partner' dereferencing possible ERR_PTR() Fixes: 82432bbfb9e83 ("usb: typec: tipd: Handle mode transitions for CD321x") Signed-off-by: Ethan Tidmore Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260218214621.38154-1-ethantidmore06@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 099494e4499dcbc54c4e44354c65d881aaf3678a Author: Chen Ni Date: Thu Feb 26 11:30:48 2026 +0800 leds: lgm-sso: Remove duplicate assignments for priv->mmap [ Upstream commit 7186d0330c3f3e86de577687a82f4ebd96dcb5ac ] Remove duplicate assignment of priv->mmap in intel_sso_led_probe(). Fixes: fba8a6f2263b ("leds: lgm-sso: Fix clock handling") Signed-off-by: Chen Ni Link: https://patch.msgid.link/20260226033048.3715915-1-nichen@iscas.ac.cn Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 34be68c52af8218d8d21e4b764cf32b0b9b36ce3 Author: Rafael J. Wysocki Date: Wed Mar 4 19:54:08 2026 +0100 platform/surface: surfacepro3_button: Drop wakeup source on remove [ Upstream commit 1410a228ab2d36fe2b383415a632ae12048d4f3a ] The wakeup source added by device_init_wakeup() in surface_button_add() needs to be dropped during driver removal, so update the driver to do that. Fixes: 19351f340765 ("platform/x86: surfacepro3: Support for wakeup from suspend-to-idle") Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/4368848.1IzOArtZ34@rafael.j.wysocki Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 834dece8ced2bdf781b16a62a17b9b5ed5a0c331 Author: Chen Ni Date: Tue Feb 3 10:16:25 2026 +0800 backlight: sky81452-backlight: Check return value of devm_gpiod_get_optional() in sky81452_bl_parse_dt() [ Upstream commit 797cc011ae02bda26f93d25a4442d7a1a77d84df ] The devm_gpiod_get_optional() function may return an ERR_PTR in case of genuine GPIO acquisition errors, not just NULL which indicates the legitimate absence of an optional GPIO. Add an IS_ERR() check after the call in sky81452_bl_parse_dt(). On error, return the error code to ensure proper failure handling rather than proceeding with invalid pointers. Fixes: e1915eec54a6 ("backlight: sky81452: Convert to GPIO descriptors") Signed-off-by: Chen Ni Reviewed-by: Linus Walleij Reviewed-by: Daniel Thompson (RISCstar) Link: https://patch.msgid.link/20260203021625.578678-1-nichen@iscas.ac.cn Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 7d88f2e1a972ef3a41863f25643fb1356e0f1ee3 Author: Billy Tsai Date: Tue Apr 7 16:53:23 2026 +0800 i3c: mipi-i3c-hci: fix IBI payload length calculation for final status [ Upstream commit d35a6db887eeae7c57b719521e39d64f929c6dc3 ] In DMA mode, the IBI status descriptor encodes the payload using CHUNKS (number of chunks) and DATA_LENGTH (valid bytes in the last chunk). All preceding chunks are implicitly full-sized. The current code accumulates full chunk sizes for non-final status descriptors, but for the final status descriptor it only adds DATA_LENGTH. This ignores the contribution of the preceding full chunks described by the same final status entry. As a result, the computed IBI payload length is truncated whenever the final status spans multiple chunks. For example, with a chunk size of 4 bytes, CHUNKS=2 and DATA_LENGTH=1 should result in a total payload size of 5 bytes, but the current code reports only 1 byte. Fix the calculation by adding the size of (CHUNKS - 1) full chunks plus DATA_LENGTH for the last chunk. Fixes: 9ad9a52cce28 ("i3c/master: introduce the mipi-i3c-hci driver") Signed-off-by: Billy Tsai Reviewed-by: Frank Li Link: https://patch.msgid.link/20260407-i3c-hci-dma-v2-1-a583187b9d22@aspeedtech.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 1c70c5b933e21b8bbdc679b8431f6dbafb1d5758 Author: Jorge Marques Date: Mon Mar 23 17:11:33 2026 +0100 i3c: master: adi: Fix error propagation for CCCs [ Upstream commit 0b73da96b6eb6b9354654f96a9d423ab22cb222d ] adi_i3c_master_send_ccc_cmd() always returned 0, ignoring the transfer result populated in the completion path. As a consequence, CCC command errors were silently dropped, including the default -ETIMEDOUT and later overwritten by adi_i3c_master_end_xfer_locked(). Fix this by returning xfer->ret so that callers correctly receive any transfer error codes. Fixes: a79ac2cdc91d ("i3c: master: Add driver for Analog Devices I3C Controller IP") Reviewed-by: Adrian Hunter Reviewed-by: Frank Li Signed-off-by: Jorge Marques Link: https://patch.msgid.link/20260323-ad4062-positive-error-fix-v3-5-30bdc68004be@analog.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit b5a2893ce6fdb88bcfdc3217a19eb191866302be Author: Felix Gu Date: Sat Apr 4 18:32:30 2026 +0800 i3c: dw: Fix memory leak in dw_i3c_master_i3c_xfers() [ Upstream commit 256cc1f1305a8e5dcadf8ca208d04a3acadd26f1 ] The dw_i3c_master_i3c_xfers() function allocates memory for the xfer structure using dw_i3c_master_alloc_xfer(). If pm_runtime_resume_and_get() fails, the function returns without freeing the allocated xfer, resulting in a memory leak. Since dw_i3c_master_free_xfer() is a thin wrapper around kfree(), use the __free(kfree) cleanup attribute to handle the free automatically on all exit paths. Fixes: 62fe9d06f570 ("i3c: dw: Add power management support") Signed-off-by: Felix Gu Reviewed-by: Frank Li Link: https://patch.msgid.link/20260404-dw-i3c-2-v3-1-8f7d146549c1@gmail.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 1b6a7e94be678d34a9ccb9db7e2443ae02ad2bc8 Author: Felix Gu Date: Mon Apr 6 20:43:16 2026 +0800 i3c: master: renesas: Fix memory leak in renesas_i3c_i3c_xfers() [ Upstream commit d7665c3b4f575251e449e2656879392346ca612b ] The xfer structure allocated by renesas_i3c_alloc_xfer() was never freed in the renesas_i3c_i3c_xfers() function. Use the __free(kfree) cleanup attribute to automatically free the memory when the variable goes out of scope. Fixes: d028219a9f14 ("i3c: master: Add basic driver for the Renesas I3C controller") Tested-by: Tommaso Merciai Reviewed-by: Tommaso Merciai Reviewed-by: Frank Li Signed-off-by: Felix Gu Link: https://patch.msgid.link/20260406-renesas-v3-1-4b724d7708f4@gmail.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit c192859f277586732f865db6c59887d48bce3cf0 Author: Felix Gu Date: Fri Mar 20 22:18:02 2026 +0800 i3c: master: dw-i3c: Fix missing reset assertion in remove() callback [ Upstream commit bef1eef667186cedb0bc6d152464acb3c97d5f72 ] The reset line acquired during probe is currently left deasserted when the driver is unbound. Switch to devm_reset_control_get_optional_exclusive_deasserted() to ensure the reset is automatically re-asserted by the devres core when the driver is removed. Fixes: 62fe9d06f570 ("i3c: dw: Add power management support") Reviewed-by: Philipp Zabel Signed-off-by: Felix Gu Reviewed-by: Frank Li Link: https://patch.msgid.link/20260320-dw-i3c-v3-1-477040c2e3f5@gmail.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit b0cdbc690dae7a80d47631d0acd8dc32fde540d6 Author: Arnaldo Carvalho de Melo Date: Wed Apr 8 14:31:57 2026 -0300 perf util: Kill die() prototype, dead for a long time [ Upstream commit e5cce1b9c82fbd48e2f1f7a25a9fad8ee228176f ] In fef2a735167a827a ("perf tools: Kill die()") the die() function was removed, but not the prototype in util.h, now when building with LIBPERL=1, during a 'make -C tools/perf build-test' routine test, it is failing as perl likes die() calls and then this clashes with this remnant, remove it. Fixes: fef2a735167a827a ("perf tools: Kill die()") Reviewed-by: Ian Rogers Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit e97cc0120390cf2e2579af0172f8bb6899a38077 Author: Ian Rogers Date: Tue Apr 7 19:08:38 2026 -0700 perf maps: Fix copy_from that can break sorted by name order [ Upstream commit f552b132e4d5248715828e7e5c2bf7889bf05b2e ] When an parent is copied into a child the name array is populated in address not name order. Make sure the name array isn't flagged as sorted. Fixes: 659ad3492b91 ("perf maps: Switch from rbtree to lazily sorted array for addresses") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit def6cd4271e75abc10f0d90e3d50d62d6b672b1b Author: Ian Rogers Date: Tue Apr 7 19:08:37 2026 -0700 perf maps: Fix fixup_overlap_and_insert that can break sorted by name order [ Upstream commit c4f3ff3289380437d26177e8f2fe4b7507816ee3 ] When an entry in the address array is replaced, the corresponding name entry is replaced. The entries names may sort differently and so it is important that the sorted by name property be cleared on the maps. Fixes: 0d11fab32714 ("perf maps: Fixup maps_by_name when modifying maps_by_address") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 59a58ada259c314c3675bc7fb2a2b8ecb158ce1b Author: Inochi Amaoto Date: Wed Apr 1 08:35:50 2026 +0800 pinctrl: sophgo: pinctrl-sg2044: Fix wrong module description [ Upstream commit 7648112358a4207916d3e38bfee49f85552fe95f ] Fix the SoC model in module description string, it should be sg2044 instead of sg2002. Fixes: 614a54cb5ac3 ("pinctrl: sophgo: add support for SG2044 SoC") Signed-off-by: Inochi Amaoto Reviewed-by: Chen Wang Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit c98c71ed8834b2f4c6014e1f7de7494e0896d163 Author: Inochi Amaoto Date: Wed Apr 1 08:35:49 2026 +0800 pinctrl: sophgo: pinctrl-sg2042: Fix wrong module description [ Upstream commit ca1c2ddff00480c213903a1479b56203536e92de ] Fix the SoC model in module description string, it should be sg2042 instead of sg2002. Fixes: 1e67465d3b74 ("pinctrl: sophgo: add support for SG2042 SoC") Signed-off-by: Inochi Amaoto Reviewed-by: Chen Wang Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 2db35db04c030829ef609c332add0a7a16baf408 Author: Ian Rogers Date: Fri Apr 3 23:05:52 2026 -0700 perf cgroup: Update metric leader in evlist__expand_cgroup [ Upstream commit c9ef786c0970991578397043f1c819229e2b7197 ] When the evlist is expanded the metric leader wasn't being updated. As the original evsel is deleted this creates a use-after-free in stat-shadow's prepare_metric. This was detected running the "perf stat --bpf-counters --for-each-cgroup test" with sanitizers. The change itself puts the copied evsel into the priv field (known unused because of evsel__clone use) and then in a second pass over the list updates the copied values using the priv pointer. Fixes: d1c5a0e86a4e ("perf stat: Add --for-each-cgroup option") Signed-off-by: Ian Rogers Acked-by: Sun Jian Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit e21bac13522020a5e5f05ac966dcf46188ed46b2 Author: Jian Zhang Date: Fri Apr 3 17:06:01 2026 +0800 ipmi: ssif_bmc: change log level to dbg in irq callback [ Upstream commit c9c99b7b7051eb7121b3224bfce181fb023b0269 ] Long-running tests indicate that this logging can occasionally disrupt timing and lead to request/response corruption. Irq handler need to be executed as fast as possible, most I2C slave IRQ implementations are byte-level, logging here can significantly affect transfer behavior and timing. It is recommended to use dev_dbg() for these messages. Fixes: dd2bc5cc9e25 ("ipmi: ssif_bmc: Add SSIF BMC driver") Signed-off-by: Jian Zhang Message-ID: <20260403090603.3988423-4-zhangjian.3032@bytedance.com> Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin commit ca4d0555000f6e8cb4dd69a758f284d609cccd53 Author: Jian Zhang Date: Fri Apr 3 17:06:00 2026 +0800 ipmi: ssif_bmc: fix message desynchronization after truncated response [ Upstream commit 1d38e849adb6851ee280aa1a1d687b2181549a66 ] A truncated response, caused by host power-off, or other conditions, can lead to message desynchronization. Raw trace data (STOP loss scenario, add state transition comment): 1. T-1: Read response phase (SSIF_RES_SENDING) 8271.955342 WR_RCV [03] <- Read polling cmd 8271.955348 RD_REQ [04] <== SSIF_RES_SENDING <- start sending response 8271.955436 RD_PRO [b4] 8271.955527 RD_PRO [00] 8271.955618 RD_PRO [c1] 8271.955707 RD_PRO [00] 8271.955814 RD_PRO [ad] <== SSIF_RES_SENDING <- last byte <- !! STOP lost (truncated response) 2. T: New Write request arrives, BMC still in SSIF_RES_SENDING 8271.967973 WR_REQ [] <== SSIF_RES_SENDING >> SSIF_ABORTING <- log: unexpected WR_REQ in RES_SENDING 8271.968447 WR_RCV [02] <== SSIF_ABORTING <- do nothing 8271.968452 WR_RCV [02] <== SSIF_ABORTING <- do nothing 8271.968454 WR_RCV [18] <== SSIF_ABORTING <- do nothing 8271.968456 WR_RCV [01] <== SSIF_ABORTING <- do nothing 8271.968458 WR_RCV [66] <== SSIF_ABORTING <- do nothing 8271.978714 STOP [] <== SSIF_ABORTING >> SSIF_READY <- log: unexpected SLAVE STOP in state=SSIF_ABORTING 3. T+1: Next Read polling, treated as a fresh transaction 8271.979125 WR_REQ [] <== SSIF_READY >> SSIF_START 8271.979326 WR_RCV [03] <== SSIF_START >> SSIF_SMBUS_CMD <- smbus_cmd=0x03 8271.979331 RD_REQ [04] <== SSIF_RES_SENDING <- sending response 8271.979427 RD_PRO [b4] <- !! this is T's stale response -> desynchronization When in SSIF_ABORTING state, a newly arrived command should still be handled to avoid dropping the request or causing message desynchronization. Fixes: dd2bc5cc9e25 ("ipmi: ssif_bmc: Add SSIF BMC driver") Signed-off-by: Jian Zhang Message-ID: <20260403090603.3988423-3-zhangjian.3032@bytedance.com> Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin commit 3cce2a3f8f60c079fa779e385a4b45d246be918b Author: Jian Zhang Date: Fri Apr 3 17:05:59 2026 +0800 ipmi: ssif_bmc: fix missing check for copy_to_user() partial failure [ Upstream commit ea641be7a4faee4351f9c5ed6b188e1bbf5586a6 ] copy_to_user() returns the number of bytes that could not be copied, with a non-zero value indicating a partial or complete failure. The current code only checks for negative return values and treats all non-negative results as success. Treating any positive return value from copy_to_user() as an error and returning -EFAULT. Fixes: dd2bc5cc9e25 ("ipmi: ssif_bmc: Add SSIF BMC driver") Signed-off-by: Jian Zhang Message-ID: <20260403090603.3988423-2-zhangjian.3032@bytedance.com> Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin commit e62ac39eb2ce1a3d98ac9bea92dcb7d6a697ac3c Author: Leo Yan Date: Thu Apr 2 17:04:47 2026 +0100 perf expr: Return -EINVAL for syntax error in expr__find_ids() [ Upstream commit 3a61fd866ef9aaa1d3158b460f852b74a2df07f4 ] expr__find_ids() propagates the parser return value directly. For syntax errors, the parser can return a positive value, but callers treat it as success, e.g., for below case on Arm64 platform: metric expr 100 * (STALL_SLOT_BACKEND / (CPU_CYCLES * #slots) - BR_MIS_PRED * 3 / CPU_CYCLES) for backend_bound parsing metric: 100 * (STALL_SLOT_BACKEND / (CPU_CYCLES * #slots) - BR_MIS_PRED * 3 / CPU_CYCLES) Failure to read '#slots' literal: #slots = nan syntax error Convert positive parser returns in expr__find_ids() to -EINVAL, as a result, the error value will be respected by callers. Before: perf stat -C 5 Failure to read '#slots'Failure to read '#slots'Failure to read '#slots'Failure to read '#slots'Segmentation fault After: perf stat -C 5 Failure to read '#slots'Cannot find metric or group `Default' Fixes: ded80bda8bc9 ("perf expr: Migrate expr ids table to a hashmap") Signed-off-by: Leo Yan Reviewed-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 131e9cb0b93254db8a61f85edf303b6c3370b654 Author: Chuck Lever Date: Mon Mar 23 11:58:04 2026 -0400 perf tools: Fix module symbol resolution for non-zero .text sh_addr [ Upstream commit 9a82bfde4775b7a87cd1a7e791f46f83ae442848 ] When perf resolves symbols from kernel module ELF files (ET_REL), it converts symbol addresses to file offsets so that sample IPs can be matched to the correct symbol. The conversion adjusts each symbol's st_value: sym->st_value -= shdr->sh_addr - shdr->sh_offset; For vmlinux (ET_EXEC), st_value is a virtual address and sh_addr is the section's virtual base, so subtracting sh_addr and adding sh_offset correctly yields a file offset. For kernel modules (ET_REL), st_value is a section-relative offset. The module loader ignores sh_addr entirely and places symbols at module_base + st_value. Converting to file offset requires only adding sh_offset; subtracting sh_addr introduces an error equal to sh_addr bytes. When .text has sh_addr == 0 -- the historical norm for simple modules -- both formulas produce the same result and the bug is latent. As modules gain more metadata sections before .text (.note, .static_call.text, etc.), the linker assigns .text a non-zero sh_addr, exposing the defect. For example, nfsd.ko on this kernel has sh_addr=0xa80, kvm-intel.ko has sh_addr=0x1e90. The effect is that all .text symbols in affected modules shift by sh_addr bytes relative to sample IPs, causing perf report to attribute samples to incorrect, nearby symbols. This was observed as 13% of LLC-load-miss samples misattributed to nfsd_file_get_dio_attrs when the actual hot function was nfsd_cache_lookup, approximately 0xa80 bytes away in the symbol table. Use the existing dso__rel() flag (already set for ET_REL modules) to select the correct adjustment: add sh_offset for ET_REL, subtract (sh_addr - sh_offset) for ET_EXEC/ET_DYN. Fixes: 0131c4ec794a ("perf tools: Make it possible to read object code from kernel modules") Signed-off-by: Chuck Lever Reviewed-by: Ian Rogers Tested-by: Thomas Richter Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 7377e48f9ca8b45420bde4e74da88af2b708d59e Author: Mike Rapoport (Microsoft) Date: Mon Mar 23 09:48:28 2026 +0200 memblock: reserve_mem: fix end caclulation in reserve_mem_release_by_name() [ Upstream commit c12c3e1507809ad1fc0448f51c933f52e17d13cd ] free_reserved_area() expects end parameter to point to the first address after the area, but reserve_mem_release_by_name() passes it the last address inside the area. Remove subtraction of one in calculation of the area end. Fixes: 74e2498ccf7b ("mm/memblock: Add reserved memory release function") Link: https://patch.msgid.link/20260323074836.3653702-2-rppt@kernel.org Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin commit 3fb038e078ec9cc8f2f175112664ac4353b8e002 Author: Ian Rogers Date: Thu Mar 19 16:33:49 2026 -0700 perf stat: Fix opt->value type for parse_cache_level [ Upstream commit 44311ae84ad9177fb311aee856027861c22f17b2 ] Commit f5803651b4a4 ("perf stat: Choose the most disaggregate command line option") changed aggregation option handling for `perf stat` but not `perf stat report` leading to parse_cache_level being passed a struct in the `perf stat` case but erroneously an aggr_mode enum value for `perf stat report`. Change the `perf stat report` aggregation handling to use the same opt_aggr_mode as `perf stat`. Also, just pass the boolean for consistency with other boolean argument handling. Fixes: f5803651b4a4 ("perf stat: Choose the most disaggregate command line option") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 206ac6c702ca7955771e6617f9fe46c1b0f30e02 Author: Ian Rogers Date: Thu Mar 19 16:33:48 2026 -0700 perf lock: Fix option value type in parse_max_stack [ Upstream commit cfaade34b52aa1ec553044255702c4b31b57c005 ] The value is a void* and the address of an int, max_stack_depth, is set up in the perf lock options. The parse_max_stack function treats the int* as a long*, make this more correct by declaring the value to be an int*. Fixes: 0a277b622670 ("perf lock contention: Check --max-stack option") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 509d342d02fff0c7cc42e778a198317ba7b09dab Author: Biju Das Date: Thu Mar 26 16:24:51 2026 +0000 pinctrl: renesas: rzg2l: Fix save/restore of {IOLH,IEN,PUPD,SMT} registers [ Upstream commit d9a60e367919752a1d398ebeba667f1e200fae1e ] The rzg2l_pinctrl_pm_setup_regs() handles save/restore of {IOLH,IEN,PUPD,SMT} registers during s2ram, but only for ports where all pins share the same pincfg. Extend the code to also support ports with variable pincfg per pin, so that {IOLH,IEN,PUPD,SMT} registers are correctly saved and restored for all pins. Fixes: 254203f9a94c ("pinctrl: renesas: rzg2l: Add suspend/resume support") Signed-off-by: Biju Das Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260326162459.101414-1-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 71e13d4c1d77ce1efad790f8c5ed65cfc71cf815 Author: Yu-Chun Lin Date: Fri Mar 20 23:15:06 2026 +0800 pinctrl: abx500: Fix type of 'argument' variable [ Upstream commit 34006f77890d050e6d80cbee365b5d703c1140b4 ] The argument variable is assigned the return value of pinconf_to_config_argument(), which returns a u32. Change its type from enum pin_config_param to unsigned int to correctly store the configuration argument. Fixes: 03b054e9696c ("pinctrl: Pass all configs to driver on pin_config_set()") Signed-off-by: Yu-Chun Lin Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit bb548a3c26a1f902f483953a3c51102ed14c9883 Author: Yu-Chun Lin Date: Tue Mar 17 19:54:03 2026 +0800 pinctrl: realtek: Fix function signature for config argument [ Upstream commit 1f5451844786ed203605528dca9e5d84ed378160 ] The argument originates from pinconf_to_config_argument(), which returns a u32. Therefore, the arg parameter should be an unsigned int instead of enum pin_config_param. Fixes: e99ce78030db ("pinctrl: realtek: Add common pinctrl driver for Realtek DHC RTD SoCs") Signed-off-by: Yu-Chun Lin Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 6476aac13805721e16439bd71f0e1703a4154517 Author: Andy Shevchenko Date: Tue Mar 17 11:36:11 2026 +0100 pinctrl: pinconf-generic: Fully validate 'pinmux' property [ Upstream commit c98324ea7849b6e5baa1774f71709b375a2c2f9e ] The pinconf_generic_parse_dt_pinmux() assumes that the 'pinmux' property is not empty when present. This might be not true. With that, the allocator will give a special value in return and not NULL which lead to the crash when trying to access that (invalid) memory. Fix that by fully validating 'pinmux' value, including its length. Fixes: 7112c05fff83 ("pinctrl: pinconf-generic: Add API for pinmux propertity in DTS file") Signed-off-by: Andy Shevchenko Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit be787fea6c66d2c24dbab6d5581b0d18a69ca332 Author: Mike Leach Date: Wed Mar 18 10:36:39 2026 +0000 perf: tools: cs-etm: Fix print issue for Coresight debug in ETE/TRBE trace [ Upstream commit 6c478e7b3eba3f387a2d6c749e3e3ee0f8ad1c53 ] Building perf with CORESIGHT=1 and the optional CSTRACE_RAW=1 enables additional debug printing of raw trace data when using command:- perf report --dump. This raw trace prints the CoreSight formatted trace frames, which may be used to investigate suspected issues with trace quality / corruption / decode. These frames are not present in ETE + TRBE trace. This fix removes the unnecessary call to print these frames. This fix also rationalises implementation - original code had helper function that unnecessarily repeated initialisation calls that had already been made. Due to an addtional fault with the OpenCSD library, this call when ETE/TRBE are being decoded will cause a segfault in perf. This fix also prevents that problem for perf using older (<= 1.8.0 version) OpenCSD libraries. Fixes: 68ffe3902898 ("perf tools: Add decoder mechanic to support dumping trace data") Reported-by: Leo Yan Signed-off-by: Mike Leach Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 9878e6ed7ec520c5348a2cf306d657586aaf5246 Author: Ian Rogers Date: Thu Mar 12 15:31:31 2026 -0700 perf branch: Avoid incrementing NULL [ Upstream commit c969a9d7bbf46f983c4a48566b3b2f7340b02296 ] If the entry is NULL the value is meaningless so early return NULL to avoid an increment of NULL. This was happening in calls from has_stitched_lbr when running the "perf record LBR tests". The return value isn't used in that case, so returning NULL as no effect. Fixes: 42bbabed09ce ("perf tools: Add hw_idx in struct branch_stack") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 518ae2a82efebc0cb619538dfaad98d4a0c1eaf8 Author: Andy Shevchenko Date: Fri Feb 27 17:43:35 2026 +0100 pinctrl: cy8c95x0: Avoid returning positive values to user space [ Upstream commit 5ad32c3607cf241a1a2680cabd64cbcd757227aa ] When probe fails due to unclear interrupt status register, it returns a positive number instead of the proper error code. Fix this accordingly. Fixes: e6cbbe42944d ("pinctrl: Add Cypress cy8c95x0 support") Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202602271847.vVWkqLBD-lkp@intel.com/ Signed-off-by: Andy Shevchenko Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit df50e63cdf1512b4d2e496d9f276b5a86951370c Author: Andy Shevchenko Date: Mon Feb 23 19:06:54 2026 +0100 pinctrl: cy8c95x0: Unify messages with help of dev_err_probe() [ Upstream commit 014884732095b982412d13d3220c3fe8483b9b3e ] Unify error messages that might appear during probe phase by switching to use dev_err_probe(). Signed-off-by: Andy Shevchenko Signed-off-by: Linus Walleij Stable-dep-of: 5ad32c3607cf ("pinctrl: cy8c95x0: Avoid returning positive values to user space") Signed-off-by: Sasha Levin commit 815a7b8af68d4c7a3dd9f14664a5c0489136e527 Author: Andy Shevchenko Date: Mon Feb 23 19:06:53 2026 +0100 pinctrl: cy8c95x0: remove duplicate error message [ Upstream commit 970dacb3b9f0fedbbbcfd7dbf1f4f22340b3f359 ] The pin control core is covered to report any error via message. The devm_request_threaded_irq() already prints an error message. Remove the duplicates. While at it, drop the info message as the same information about an IRQ in use can be retrieved differently. Signed-off-by: Andy Shevchenko Signed-off-by: Linus Walleij Stable-dep-of: 5ad32c3607cf ("pinctrl: cy8c95x0: Avoid returning positive values to user space") Signed-off-by: Sasha Levin commit dbfb30248dbe405557a2c99fee9019047808878e Author: Ian Rogers Date: Mon Mar 2 15:45:15 2026 -0800 perf trace: Avoid an ERR_PTR in syscall_stats [ Upstream commit d05073adda0f047e9b2115a2932bcb2797eab238 ] hashmap__new may return an ERR_PTR and previously this would be assigned to syscall_stats meaning all use of syscall_stats needs to test for NULL (uninitialized) or an ERR_PTR. Given the only reason hashmap__new can fail is ENOMEM, just use NULL to indicate the allocation failure and avoid the code having to test for NULL and IS_ERR. Fixes: 96f202eab813 (perf trace: Fix IS_ERR() vs NULL check bug) Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 4d994ff457272524105621d2bcf4c1b45a420088 Author: Ethan Tidmore Date: Fri Feb 27 15:56:23 2026 -0600 pinctrl: pinctrl-pic32: Fix resource leak [ Upstream commit fe5560688f3ba98364c7de7b4f8dc240ffd1ff75 ] Fix three possible resource leaks by using the devres version of clk_prepare_enable(). Also, update error message accordingly. Detected by Smatch: drivers/pinctrl/pinctrl-pic32.c:2211 pic32_pinctrl_probe() warn: 'pctl->clk' from clk_prepare_enable() not released on lines: 2208. drivers/pinctrl/pinctrl-pic32.c:2274 pic32_gpio_probe() warn: 'bank->clk' from clk_prepare_enable() not released on lines: 2264,2272. Fixes: 2ba384e6c3810 ("pinctrl: pinctrl-pic32: Add PIC32 pin control driver") Signed-off-by: Ethan Tidmore Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit dc3ece1d92e62210cba676d88f05a08ec3813530 Author: wangguangju Date: Thu Feb 26 20:22:08 2026 +0800 perf trace: Fix IS_ERR() vs NULL check bug [ Upstream commit 96f202eab8133f94479b14a32902c636e9bdf6af ] The alloc_syscall_stats() function always returns an error pointer (ERR_PTR) on failure. So replace NULL check with IS_ERR() check after calling delete_syscall_stats() function. Fixes: ef2da619b132c6f74 ("perf trace: Convert syscall_stats to hashmap") Signed-off-by: wangguangju Reviewed-by: Howard Chu Acked-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 02c06e764fe5d37f0faab7da66cc50fc3152d924 Author: Puranjay Mohan Date: Fri Apr 17 07:33:52 2026 -0700 bpf, arm32: Reject BPF-to-BPF calls and callbacks in the JIT [ Upstream commit e1d486445af3c392628532229f7ce5f5cf7891b6 ] The ARM32 BPF JIT does not support BPF-to-BPF function calls (BPF_PSEUDO_CALL) or callbacks (BPF_PSEUDO_FUNC), but it does not reject them either. When a program with subprograms is loaded (e.g. libxdp's XDP dispatcher uses __noinline__ subprograms, or any program using callbacks like bpf_loop or bpf_for_each_map_elem), the verifier invokes bpf_jit_subprogs() which calls bpf_int_jit_compile() for each subprogram. For BPF_PSEUDO_CALL, since ARM32 does not reject it, the JIT silently emits code using the wrong address computation: func = __bpf_call_base + imm where imm is a pc-relative subprogram offset, producing a bogus function pointer. For BPF_PSEUDO_FUNC, the ldimm64 handler ignores src_reg and loads the immediate as a normal 64-bit value without error. In both cases, build_body() reports success and a JIT image is allocated. ARM32 lacks the jit_data/extra_pass mechanism needed for the second JIT pass in bpf_jit_subprogs(). On the second pass, bpf_int_jit_compile() performs a full fresh compilation, allocating a new JIT binary and overwriting prog->bpf_func. The first allocation is never freed. bpf_jit_subprogs() then detects the function pointer changed and aborts with -ENOTSUPP, but the original JIT binary has already been leaked. Each program load/unload cycle leaks one JIT binary allocation, as reported by kmemleak: unreferenced object 0xbf0a1000 (size 4096): backtrace: bpf_jit_binary_alloc+0x64/0xfc bpf_int_jit_compile+0x14c/0x348 bpf_jit_subprogs+0x4fc/0xa60 Fix this by rejecting both BPF_PSEUDO_CALL in the BPF_CALL handler and BPF_PSEUDO_FUNC in the BPF_LD_IMM64 handler, falling through to the existing 'notyet' path. This causes build_body() to fail before any JIT binary is allocated, so bpf_int_jit_compile() returns the original program unjitted. bpf_jit_subprogs() then sees !prog->jited and cleanly falls back to the interpreter with no leak. Acked-by: Daniel Borkmann Fixes: 1c2a088a6626 ("bpf: x64: add JIT support for multi-function programs") Reported-by: Jonas Rebmann Closes: https://lore.kernel.org/bpf/b63e9174-7a3d-4e22-8294-16df07a4af89@pengutronix.de Tested-by: Jonas Rebmann Signed-off-by: Puranjay Mohan Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/r/20260417143353.838911-1-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit e15900888c09480a4c632bc598f1c5bd39bed6d6 Author: Puranjay Mohan Date: Fri Apr 17 08:21:33 2026 -0700 bpf: Validate node_id in arena_alloc_pages() [ Upstream commit 2845989f2ebaf7848e4eccf9a779daf3156ea0a5 ] arena_alloc_pages() accepts a plain int node_id and forwards it through the entire allocation chain without any bounds checking. Validate node_id before passing it down the allocation chain in arena_alloc_pages(). Fixes: 317460317a02 ("bpf: Introduce bpf_arena.") Signed-off-by: Puranjay Mohan Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/r/20260417152135.1383754-1-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit e8bd8274ae563ccabb4a778be9bd9c6d4754ab10 Author: Jiri Olsa Date: Thu Apr 16 12:00:34 2026 +0200 libbpf: Prevent double close and leak of btf objects [ Upstream commit 380044c40b1636a72fd8f188b5806be6ae564279 ] Sashiko found possible double close of btf object fd [1], which happens when strdup in load_module_btfs fails at which point the obj->btf_module_cnt is already incremented. The error path close btf fd and so does later cleanup code in bpf_object_post_load_cleanup function. Also libbpf_ensure_mem failure leaves btf object not assigned and it's leaked. Replacing the err_out label with break to make the error path less confusing as suggested by Alan. Incrementing obj->btf_module_cnt only if there's no failure and releasing btf object in error path. Fixes: 91abb4a6d79d ("libbpf: Support attachment of BPF tracing programs to kernel modules") [1] https://sashiko.dev/#/patchset/20260324081846.2334094-1-jolsa%40kernel.org Signed-off-by: Jiri Olsa Link: https://lore.kernel.org/r/20260416100034.1610852-1-jolsa@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 8abad856e2a5bfc15b53a8a6420910fa73021bff Author: Yihan Ding Date: Thu Apr 16 20:01:41 2026 +0800 bpf: allow UTF-8 literals in bpf_bprintf_prepare() [ Upstream commit b960430ea8862ef37ce53c8bf74a8dc79d3f2404 ] bpf_bprintf_prepare() only needs ASCII parsing for conversion specifiers. Plain text can safely carry bytes >= 0x80, so allow UTF-8 literals outside '%' sequences while keeping ASCII control bytes rejected and format specifiers ASCII-only. This keeps existing parsing rules for format directives unchanged, while allowing helpers such as bpf_trace_printk() to emit UTF-8 literal text. Update test_snprintf_negative() in the same commit so selftests keep matching the new plain-text vs format-specifier split during bisection. Fixes: 48cac3f4a96d ("bpf: Implement formatted output helpers with bstr_printf") Signed-off-by: Yihan Ding Acked-by: Paul Chaignon Link: https://lore.kernel.org/r/20260416120142.1420646-2-dingyihan@uniontech.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 6982653ce5f119982aa58f1af58e7bfbebf39252 Author: Mykyta Yatsenko Date: Thu Apr 16 11:08:07 2026 -0700 bpf: Fix NULL deref in map_kptr_match_type for scalar regs [ Upstream commit 4d0a375887ab4d49e4da1ff10f9606cab8f7c3ad ] Commit ab6c637ad027 ("bpf: Fix a bpf_kptr_xchg() issue with local kptr") refactored map_kptr_match_type() to branch on btf_is_kernel() before checking base_type(). A scalar register stored into a kptr slot has no btf, so the btf_is_kernel(reg->btf) call dereferences NULL. Move the base_type() != PTR_TO_BTF_ID guard before any reg->btf access. Fixes: ab6c637ad027 ("bpf: Fix a bpf_kptr_xchg() issue with local kptr") Reported-by: Hiker Cl Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221372 Signed-off-by: Mykyta Yatsenko Acked-by: Paul Chaignon Link: https://lore.kernel.org/r/20260416-kptr_crash-v1-1-5589356584b4@meta.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 5c04f89f9557ec52db4cf0d42bb602c0a15db5af Author: Daniel Borkmann Date: Thu Apr 16 14:27:19 2026 +0200 bpf: Fix precedence bug in convert_bpf_ld_abs alignment check [ Upstream commit e5f635edd393aeaa7cad9e42831d397e6e2e1eed ] Fix an operator precedence issue in convert_bpf_ld_abs() where the expression offset + ip_align % size evaluates as offset + (ip_align % size) due to % having higher precedence than +. That latter evaluation does not make any sense. The intended check is (offset + ip_align) % size == 0 to verify that the packet load offset is properly aligned for direct access. With NET_IP_ALIGN == 2, the bug causes the inline fast-path for direct packet loads to almost never be taken on !CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS platforms. This forces nearly all cBPF BPF_LD_ABS packet loads through the bpf_skb_load_helper slow path on the affected archs. Fixes: e0cea7ce988c ("bpf: implement ld_abs/ld_ind in native bpf") Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260416122719.661033-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 921920c34cb591947dd30c692500795a69f1e3fa Author: Michal Luczaj Date: Tue Apr 14 16:13:19 2026 +0200 bpf, sockmap: Take state lock for af_unix iter [ Upstream commit 64c2f93fc3254d3bf5de4445fb732ee5c451edb6 ] When a BPF iterator program updates a sockmap, there is a race condition in unix_stream_bpf_update_proto() where the `peer` pointer can become stale[1] during a state transition TCP_ESTABLISHED -> TCP_CLOSE. CPU0 bpf CPU1 close -------- ---------- // unix_stream_bpf_update_proto() sk_pair = unix_peer(sk) if (unlikely(!sk_pair)) return -EINVAL; // unix_release_sock() skpair = unix_peer(sk); unix_peer(sk) = NULL; sock_put(skpair) sock_hold(sk_pair) // UaF More practically, this fix guarantees that the iterator program is consistently provided with a unix socket that remains stable during iterator execution. [1]: BUG: KASAN: slab-use-after-free in unix_stream_bpf_update_proto+0x155/0x490 Write of size 4 at addr ffff8881178c9a00 by task test_progs/2231 Call Trace: dump_stack_lvl+0x5d/0x80 print_report+0x170/0x4f3 kasan_report+0xe4/0x1c0 kasan_check_range+0x125/0x200 unix_stream_bpf_update_proto+0x155/0x490 sock_map_link+0x71c/0xec0 sock_map_update_common+0xbc/0x600 sock_map_update_elem+0x19a/0x1f0 bpf_prog_bbbf56096cdd4f01_selective_dump_unix+0x20c/0x217 bpf_iter_run_prog+0x21e/0xae0 bpf_iter_unix_seq_show+0x1e0/0x2a0 bpf_seq_read+0x42c/0x10d0 vfs_read+0x171/0xb20 ksys_read+0xff/0x200 do_syscall_64+0xf7/0x5e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 2236: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x63/0x80 kmem_cache_alloc_noprof+0x1d5/0x680 sk_prot_alloc+0x59/0x210 sk_alloc+0x34/0x470 unix_create1+0x86/0x8a0 unix_stream_connect+0x318/0x15b0 __sys_connect+0xfd/0x130 __x64_sys_connect+0x72/0xd0 do_syscall_64+0xf7/0x5e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 2236: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x70 __kasan_slab_free+0x47/0x70 kmem_cache_free+0x11c/0x590 __sk_destruct+0x432/0x6e0 unix_release_sock+0x9b3/0xf60 unix_release+0x8a/0xf0 __sock_release+0xb0/0x270 sock_close+0x18/0x20 __fput+0x36e/0xac0 fput_close_sync+0xe5/0x1a0 __x64_sys_close+0x7d/0xd0 do_syscall_64+0xf7/0x5e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: 2c860a43dd77 ("bpf: af_unix: Implement BPF iterator for UNIX domain socket.") Suggested-by: Kuniyuki Iwashima Signed-off-by: Michal Luczaj Signed-off-by: Martin KaFai Lau Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260414-unix-proto-update-null-ptr-deref-v4-5-2af6fe97918e@rbox.co Signed-off-by: Sasha Levin commit 041eb6348d73ee5e15fc8161f1eac5a6e8289ca0 Author: Michal Luczaj Date: Tue Apr 14 16:13:18 2026 +0200 bpf, sockmap: Fix af_unix null-ptr-deref in proto update [ Upstream commit dca38b7734d2ea00af4818ff3ae836fab33d5d5a ] unix_stream_connect() sets sk_state (`WRITE_ONCE(sk->sk_state, TCP_ESTABLISHED)`) _before_ it assigns a peer (`unix_peer(sk) = newsk`). sk_state == TCP_ESTABLISHED makes sock_map_sk_state_allowed() believe that socket is properly set up, which would include having a defined peer. IOW, there's a window when unix_stream_bpf_update_proto() can be called on socket which still has unix_peer(sk) == NULL. CPU0 bpf CPU1 connect -------- ------------ WRITE_ONCE(sk->sk_state, TCP_ESTABLISHED) sock_map_sk_state_allowed(sk) ... sk_pair = unix_peer(sk) sock_hold(sk_pair) sock_hold(newsk) smp_mb__after_atomic() unix_peer(sk) = newsk BUG: kernel NULL pointer dereference, address: 0000000000000080 RIP: 0010:unix_stream_bpf_update_proto+0xa0/0x1b0 Call Trace: sock_map_link+0x564/0x8b0 sock_map_update_common+0x6e/0x340 sock_map_update_elem_sys+0x17d/0x240 __sys_bpf+0x26db/0x3250 __x64_sys_bpf+0x21/0x30 do_syscall_64+0x6b/0x3a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Initial idea was to move peer assignment _before_ the sk_state update[1], but that involved an additional memory barrier, and changing the hot path was rejected. Then a NULL check during proto update in unix_stream_bpf_update_proto() was considered[2], but the follow-up discussion[3] focused on the root cause, i.e. sockmap update taking a wrong lock. Or, more specifically, missing unix_state_lock()[4]. In the end it was concluded that teaching sockmap about the af_unix locking would be unnecessarily complex[5]. Complexity aside, since BPF_PROG_TYPE_SCHED_CLS and BPF_PROG_TYPE_SCHED_ACT are allowed to update sockmaps, sock_map_update_elem() taking the unix lock, as it is currently implemented in unix_state_lock(): spin_lock(&unix_sk(s)->lock), would be problematic. unix_state_lock() taken in a process context, followed by a softirq-context TC BPF program attempting to take the same spinlock -- deadlock[6]. This way we circled back to the peer check idea[2]. [1]: https://lore.kernel.org/netdev/ba5c50aa-1df4-40c2-ab33-a72022c5a32e@rbox.co/ [2]: https://lore.kernel.org/netdev/20240610174906.32921-1-kuniyu@amazon.com/ [3]: https://lore.kernel.org/netdev/7603c0e6-cd5b-452b-b710-73b64bd9de26@linux.dev/ [4]: https://lore.kernel.org/netdev/CAAVpQUA+8GL_j63CaKb8hbxoL21izD58yr1NvhOhU=j+35+3og@mail.gmail.com/ [5]: https://lore.kernel.org/bpf/CAAVpQUAHijOMext28Gi10dSLuMzGYh+jK61Ujn+fZ-wvcODR2A@mail.gmail.com/ [6]: https://lore.kernel.org/bpf/dd043c69-4d03-46fe-8325-8f97101435cf@linux.dev/ Summary of scenarios where af_unix/stream connect() may race a sockmap update: 1. connect() vs. bpf(BPF_MAP_UPDATE_ELEM), i.e. sock_map_update_elem_sys() Implemented NULL check is sufficient. Once assigned, socket peer won't be released until socket fd is released. And that's not an issue because sock_map_update_elem_sys() bumps fd refcnf. 2. connect() vs BPF program doing update Update restricted per verifier.c:may_update_sockmap() to BPF_PROG_TYPE_TRACING/BPF_TRACE_ITER BPF_PROG_TYPE_SOCK_OPS (bpf_sock_map_update() only) BPF_PROG_TYPE_SOCKET_FILTER BPF_PROG_TYPE_SCHED_CLS BPF_PROG_TYPE_SCHED_ACT BPF_PROG_TYPE_XDP BPF_PROG_TYPE_SK_REUSEPORT BPF_PROG_TYPE_FLOW_DISSECTOR BPF_PROG_TYPE_SK_LOOKUP Plus one more race to consider: CPU0 bpf CPU1 connect -------- ------------ WRITE_ONCE(sk->sk_state, TCP_ESTABLISHED) sock_map_sk_state_allowed(sk) sock_hold(newsk) smp_mb__after_atomic() unix_peer(sk) = newsk sk_pair = unix_peer(sk) if (unlikely(!sk_pair)) return -EINVAL; CPU1 close ---------- skpair = unix_peer(sk); unix_peer(sk) = NULL; sock_put(skpair) // use after free? sock_hold(sk_pair) 2.1 BPF program invoking helper function bpf_sock_map_update() -> BPF_CALL_4(bpf_sock_map_update(), ...) Helper limited to BPF_PROG_TYPE_SOCK_OPS. Nevertheless, a unix sock might be accessible via bpf_map_lookup_elem(). Which implies sk already having psock, which in turn implies sk already having sk_pair. Since sk_psock_destroy() is queued as RCU work, sk_pair won't go away while BPF executes the update. 2.2 BPF program invoking helper function bpf_map_update_elem() -> sock_map_update_elem() 2.2.1 Unix sock accessible to BPF prog only via sockmap lookup in BPF_PROG_TYPE_SOCKET_FILTER, BPF_PROG_TYPE_SCHED_CLS, BPF_PROG_TYPE_SCHED_ACT, BPF_PROG_TYPE_XDP, BPF_PROG_TYPE_SK_REUSEPORT, BPF_PROG_TYPE_FLOW_DISSECTOR, BPF_PROG_TYPE_SK_LOOKUP. Pretty much the same as case 2.1. 2.2.2 Unix sock accessible to BPF program directly: BPF_PROG_TYPE_TRACING, narrowed down to BPF_TRACE_ITER. Sockmap iterator (sock_map_seq_ops) is safe: unix sock residing in a sockmap means that the sock already went through the proto update step. Unix sock iterator (bpf_iter_unix_seq_ops), on the other hand, gives access to socks that may still be unconnected. Which means iterator prog can race sockmap/proto update against connect(). BUG: KASAN: null-ptr-deref in unix_stream_bpf_update_proto+0x253/0x4d0 Write of size 4 at addr 0000000000000080 by task test_progs/3140 Call Trace: dump_stack_lvl+0x5d/0x80 kasan_report+0xe4/0x1c0 kasan_check_range+0x125/0x200 unix_stream_bpf_update_proto+0x253/0x4d0 sock_map_link+0x71c/0xec0 sock_map_update_common+0xbc/0x600 sock_map_update_elem+0x19a/0x1f0 bpf_prog_bbbf56096cdd4f01_selective_dump_unix+0x20c/0x217 bpf_iter_run_prog+0x21e/0xae0 bpf_iter_unix_seq_show+0x1e0/0x2a0 bpf_seq_read+0x42c/0x10d0 vfs_read+0x171/0xb20 ksys_read+0xff/0x200 do_syscall_64+0xf7/0x5e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e While the introduced NULL check prevents null-ptr-deref in the BPF program path as well, it is insufficient to guard against a poorly timed close() leading to a use-after-free. This will be addressed in a subsequent patch. Fixes: c63829182c37 ("af_unix: Implement ->psock_update_sk_prot()") Closes: https://lore.kernel.org/netdev/ba5c50aa-1df4-40c2-ab33-a72022c5a32e@rbox.co/ Reported-by: Michal Luczaj Reported-by: 钱一铭 Suggested-by: Kuniyuki Iwashima Suggested-by: Martin KaFai Lau Signed-off-by: Michal Luczaj Signed-off-by: Martin KaFai Lau Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260414-unix-proto-update-null-ptr-deref-v4-4-2af6fe97918e@rbox.co Signed-off-by: Sasha Levin commit 527057ebe8076dfbcaef51195ff1b7508646be2c Author: Michal Luczaj Date: Tue Apr 14 16:13:16 2026 +0200 bpf, sockmap: Fix af_unix iter deadlock [ Upstream commit 4d328dd695383224aa750ddee6b4ad40c0f8d205 ] bpf_iter_unix_seq_show() may deadlock when lock_sock_fast() takes the fast path and the iter prog attempts to update a sockmap. Which ends up spinning at sock_map_update_elem()'s bh_lock_sock(): WARNING: possible recursive locking detected test_progs/1393 is trying to acquire lock: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: sock_map_update_elem+0xdb/0x1f0 but task is already holding lock: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: __lock_sock_fast+0x37/0xe0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(slock-AF_UNIX); lock(slock-AF_UNIX); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by test_progs/1393: #0: ffff88814b59c790 (&p->lock){+.+.}-{4:4}, at: bpf_seq_read+0x59/0x10d0 #1: ffff88811ec25fd8 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: bpf_seq_read+0x42c/0x10d0 #2: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: __lock_sock_fast+0x37/0xe0 #3: ffffffff85a6a7c0 (rcu_read_lock){....}-{1:3}, at: bpf_iter_run_prog+0x51d/0xb00 Call Trace: dump_stack_lvl+0x5d/0x80 print_deadlock_bug.cold+0xc0/0xce __lock_acquire+0x130f/0x2590 lock_acquire+0x14e/0x2b0 _raw_spin_lock+0x30/0x40 sock_map_update_elem+0xdb/0x1f0 bpf_prog_2d0075e5d9b721cd_dump_unix+0x55/0x4f4 bpf_iter_run_prog+0x5b9/0xb00 bpf_iter_unix_seq_show+0x1f7/0x2e0 bpf_seq_read+0x42c/0x10d0 vfs_read+0x171/0xb20 ksys_read+0xff/0x200 do_syscall_64+0x6b/0x3a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: 2c860a43dd77 ("bpf: af_unix: Implement BPF iterator for UNIX domain socket.") Suggested-by: Kuniyuki Iwashima Suggested-by: Martin KaFai Lau Signed-off-by: Michal Luczaj Signed-off-by: Martin KaFai Lau Reviewed-by: Jiayuan Chen Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260414-unix-proto-update-null-ptr-deref-v4-2-2af6fe97918e@rbox.co Signed-off-by: Sasha Levin commit 77ad43af264215d33b6a3a1ced1dbdaa3a85fc5c Author: Puranjay Mohan Date: Mon Apr 13 12:11:09 2026 -0700 bpf, riscv: Remove redundant bpf_flush_icache() after pack allocator finalize [ Upstream commit 46ee1342b887c9387a933397d846ff6c9584322c ] bpf_flush_icache() calls flush_icache_range() to clean the data cache and invalidate the instruction cache for the JITed code region. However, since commit 48a8f78c50bd ("bpf, riscv: use prog pack allocator in the BPF JIT"), this flush is redundant. bpf_jit_binary_pack_finalize() copies the JITed instructions to the ROX region via bpf_arch_text_copy() -> patch_text_nosync(), and patch_text_nosync() already calls flush_icache_range() on the written range. The subsequent bpf_flush_icache() repeats the same cache maintenance on an overlapping range. Remove the redundant bpf_flush_icache() call and its now-unused definition. Fixes: 48a8f78c50bd ("bpf, riscv: use prog pack allocator in the BPF JIT") Acked-by: Song Liu Signed-off-by: Puranjay Mohan Reviewed-by: Pu Lehui Tested-by: Paul Chaignon Link: https://lore.kernel.org/r/20260413191111.3426023-3-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit ca51684db023e96faf5d8fe94b5f9322e73dd675 Author: Puranjay Mohan Date: Mon Apr 13 12:11:08 2026 -0700 bpf, arm64: Remove redundant bpf_flush_icache() after pack allocator finalize [ Upstream commit 42f18ae53011826cfd3c84d041817e7f07bc645b ] bpf_flush_icache() calls flush_icache_range() to clean the data cache and invalidate the instruction cache for the JITed code region. However, since commit 1dad391daef1 ("bpf, arm64: use bpf_prog_pack for memory management"), this flush is redundant. bpf_jit_binary_pack_finalize() copies the JITed instructions to the ROX region via bpf_arch_text_copy() -> aarch64_insn_copy() -> __text_poke(), and __text_poke() already calls flush_icache_range() on the written range. The subsequent bpf_flush_icache() repeats the same cache maintenance on an overlapping range, including an unnecessary second synchronous IPI to all CPUs via kick_all_cpus_sync(). Remove the redundant bpf_flush_icache() call and its now-unused definition. Fixes: 1dad391daef1 ("bpf, arm64: use bpf_prog_pack for memory management") Acked-by: Song Liu Signed-off-by: Puranjay Mohan Acked-by: Breno Leitao Link: https://lore.kernel.org/r/20260413191111.3426023-2-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 1a113b5497297871699cd498b1b83542e0db7f15 Author: Daniel Borkmann Date: Wed Apr 15 14:14:03 2026 +0200 bpf, arm64: Fix off-by-one in check_imm signed range check [ Upstream commit 1dd8be4ec722ce54e4cace59f3a4ba658111b3ec ] check_imm(bits, imm) is used in the arm64 BPF JIT to verify that a branch displacement (in arm64 instruction units) fits into the signed N-bit immediate field of a B, B.cond or CBZ/CBNZ encoding before it is handed to the encoder. The macro currently tests for (imm > 0 && imm >> bits) || (imm < 0 && ~imm >> bits) which admits values in [-2^N, 2^N) — effectively a signed (N+1)-bit range. A signed N-bit field only holds [-2^(N-1), 2^(N-1)), so the check admits one extra bit of range on each side. In particular, for check_imm19(), values in [2^18, 2^19) slip past the check but do not fit into the 19-bit signed imm19 field of B.cond. aarch64_insn_encode_immediate() then masks the raw value into the 19-bit field, setting bit 18 (the sign bit) and flipping a forward branch into a backward one. Same class of issue exists for check_imm26() and the B/BL encoding. Shift by (bits - 1) instead of bits so the actual signed N-bit range is enforced. Fixes: e54bcde3d69d ("arm64: eBPF JIT compiler") Signed-off-by: Daniel Borkmann Reviewed-by: Puranjay Mohan Link: https://lore.kernel.org/r/20260415121403.639619-2-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 07793ce19221444556b91a615ffcc9ac8fe258ac Author: Ye Bin Date: Mon Mar 30 21:30:35 2026 +0800 ext4: fix possible null-ptr-deref in mbt_kunit_exit() [ Upstream commit 22f53f08d9eb837ce69b1a07641d414aac8d045f ] There's issue as follows: # test_new_blocks_simple: failed to initialize: -12 KASAN: null-ptr-deref in range [0x0000000000000638-0x000000000000063f] Tainted: [E]=UNSIGNED_MODULE, [N]=TEST RIP: 0010:mbt_kunit_exit+0x5e/0x3e0 [ext4_test] Call Trace: kunit_try_run_case_cleanup+0xbc/0x100 [kunit] kunit_generic_run_threadfn_adapter+0x89/0x100 [kunit] kthread+0x408/0x540 ret_from_fork+0xa76/0xdf0 ret_from_fork_asm+0x1a/0x30 If mbt_kunit_init() init testcase failed will lead to null-ptr-deref. So add test if 'sb' is inited success in mbt_kunit_exit(). Fixes: 7c9fa399a369 ("ext4: add first unit test for ext4_mb_new_blocks_simple in mballoc") Signed-off-by: Ye Bin Reviewed-by: Ritesh Harjani (IBM) Reviewed-by: Ojaswin Mujoo Link: https://patch.msgid.link/20260330133035.287842-6-yebin@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit c7abd0e6c87441e99c759d40eb6fe589634e3041 Author: Oliver Neukum Date: Tue Mar 24 15:24:54 2026 +0100 HID: usbhid: fix deadlock in hid_post_reset() [ Upstream commit 8df2c1b47ee3cd50fd454f75c7a7e2ae8a6adf72 ] You can build a USB device that includes a HID component and a storage or UAS component. The components can be reset only together. That means that hid_pre_reset() and hid_post_reset() are in the block IO error handling. Hence no memory allocation used in them may do block IO because the IO can deadlock on the mutex held while resetting a device and calling the interface drivers. Use GFP_NOIO for all allocations in them. Fixes: dc3c78e434690 ("HID: usbhid: Check HID report descriptor contents after device reset") Signed-off-by: Oliver Neukum Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit c3a6ee43246d4dc5e7d9fd0b7fd9685fb8d5191b Author: Miquel Raynal Date: Wed Mar 18 11:47:50 2026 +0100 mtd: spinand: winbond: Clarify when to enable the HS bit [ Upstream commit 25a915fad503c2678902075565d47ddc2aa45db9 ] Above 104MHz when in fast dual or quad I/O reads, the delay between address and data cycles is too short. It is possible to reach higher frequencies, up to 166MHz, by adding a few more dummy cycles through the setting of the HS bit. Improve the condition for enabling this bit, and also make sure we set it at soon as we go over 104MHz. Fixes: f1a91175faaa ("mtd: spinand: winbond: Enable high-speed modes on w25n0xjw") Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 52aaa647b02d0f9f81a36746e244ded9e82214f2 Author: Miquel Raynal Date: Fri Jan 9 18:18:22 2026 +0100 mtd: spinand: Give the bus interface to the configuration helper [ Upstream commit 0a331a1851aedd670b95a2d16c6a82496137378d ] The chip configuration hook is the one responsible to actually switch the switch between bus interfaces. It is natural to give it the bus interface we expect with a new parameter. For now the only value we can give is SSDR, but this is subject to change in the future, so add a bit of extra logic in the implementations of this callback to make sure both the core and the chip driver are aligned on the request. Signed-off-by: Miquel Raynal Stable-dep-of: 25a915fad503 ("mtd: spinand: winbond: Clarify when to enable the HS bit") Signed-off-by: Sasha Levin commit 6a5f5c25fb1f2c39be4fd4df309de7270f32e4ea Author: Miquel Raynal Date: Fri Jan 9 18:18:20 2026 +0100 mtd: spinand: Add support for setting a bus interface [ Upstream commit 20387f2fe509eba46ecf758da052786d7b1203fb ] Create a bus interface enumeration, currently only containing the one we support: SSDR, for single SDR, so any operation whose command is sent over a single data line in SDR mode, ie. any operation matching 1S-XX-XX. The main spinand_device structure gets a new parameter to store this enumeration, for now unused. Of course it is set to SSDR during the SSDR templates initialization to further clarify the state we are in at the moment. This member is subject to be used to know in which bus configuration we and be updated by the core when we switch to faster mode(s). Signed-off-by: Miquel Raynal Stable-dep-of: 25a915fad503 ("mtd: spinand: winbond: Clarify when to enable the HS bit") Signed-off-by: Sasha Levin commit d4e22374b9b01139a350c30b181caab8e34166e7 Author: Miquel Raynal Date: Fri Jan 9 18:18:19 2026 +0100 mtd: spinand: Gather all the bus interface steps in one single function [ Upstream commit be0b86c648bf811237cc17e274e9f9488fccb772 ] Writing the quad enable bit in one helper and doing the chip configuration in another does not make much sense from a bus interface setup point of view. Instead, let's create a broader helper which is going to be in charge of all the bus configuration steps at once. This will specifically allow to transition to octal DDR mode, and even fallback to quad (if suppoorted) or single mode otherwise. Signed-off-by: Miquel Raynal Stable-dep-of: 25a915fad503 ("mtd: spinand: winbond: Clarify when to enable the HS bit") Signed-off-by: Sasha Levin commit a602b7efb876d1086883d1bc227c9e3776ea341d Author: Miquel Raynal Date: Fri Jan 9 18:18:18 2026 +0100 mtd: spinand: winbond: Configure the IO mode after the dummy cycles [ Upstream commit ef1ed296fb9d9246256e1b5b2cf2e86e85606ac3 ] When we will change the bus interface, the action that actually performs the transition is the IO mode register write. This means after the IO mode register write, we should use the new bus interface. But the ->configure_chip() hook itself is not responsible of making this change official, it is the caller that must act according to the return value. Reorganize this helper to first configure the dummy cycles before possibly switching to another bus interface. Signed-off-by: Miquel Raynal Stable-dep-of: 25a915fad503 ("mtd: spinand: winbond: Clarify when to enable the HS bit") Signed-off-by: Sasha Levin commit a5d27efc8e4f912b083a18423c85c81585a721fc Author: Miquel Raynal Date: Fri Jan 9 18:18:17 2026 +0100 mtd: spinand: winbond: Rename IO_MODE register macro [ Upstream commit 57e1015cc9a96372f330195abe32a904ec8d1eab ] Suffix the macro name with *_REG to align with the rest of the driver. Signed-off-by: Miquel Raynal Stable-dep-of: 25a915fad503 ("mtd: spinand: winbond: Clarify when to enable the HS bit") Signed-off-by: Sasha Levin commit 7298335371044a6d6d3c2ce07311433ad3ed12b7 Author: Miquel Raynal Date: Fri Jan 9 18:18:07 2026 +0100 mtd: spinand: Create an array of operation templates [ Upstream commit 408015023294958407925bc50cdd85718d12a335 ] Currently, the SPI NAND core implementation directly calls macros to get the various operations in shape. These macros are specific to the bus interface, currently only supporting the single SDR interface (any command following the 1S-XX-XX pattern). Introducing support for other bus interfaces (such as octal DTR) would mean that every user of these macros should become aware of the current bus interface and act accordingly, picking up and adapting to the current configuration. This would add quite a bit of boilerplate, be repetitive as well as error prone in case we miss one occurrence. Instead, let's create a table with all SPI NAND memory operations that are currently supported. We initialize them with the same single SDR _OP macros as before. This opens the possibility for users of the individual macros to make use of these templates instead. This way, when we will add another bus interface, we can just switch to another set of templates and all users will magically fill in their spi_mem_op structures with the correct ops. The existing read, write and update cache variants are also moved in this template array, which is barely noticeable by callers as we also add a structure member pointing to it. Reviewed-by: Tudor Ambarus Signed-off-by: Miquel Raynal Stable-dep-of: 25a915fad503 ("mtd: spinand: winbond: Clarify when to enable the HS bit") Signed-off-by: Sasha Levin commit d5de6d39a3bb980639ea64a19b167e1828670e66 Author: Miquel Raynal Date: Fri Jan 9 18:18:06 2026 +0100 mtd: spinand: Decouple write enable and write disable operations [ Upstream commit c0ba929cf7a960c796cc9946b3f79d8405e9b805 ] In order to introduce templates for all operations and not only for page helpers (in order to introduce octal DDR support), decouple the WR_EN and WR_DIS operations into two separate macros. Adapt the callers accordingly. There is no functional change. Reviewed-by: Tudor Ambarus Signed-off-by: Miquel Raynal Stable-dep-of: 25a915fad503 ("mtd: spinand: winbond: Clarify when to enable the HS bit") Signed-off-by: Sasha Levin commit b5804b3ae4b8556ef200c4209e372f90460de20d Author: Miquel Raynal Date: Fri Jan 9 18:18:03 2026 +0100 mtd: spinand: Add missing check [ Upstream commit aab8a4c656379a6a1a4ca716f48118680560eaab ] The update cache variant is mandatory, both read and write versions are being checked, but not this one. All chip drivers seem to implement this variant, so there should be no breakage. Reviewed-by: Tudor Ambarus Signed-off-by: Miquel Raynal Stable-dep-of: 25a915fad503 ("mtd: spinand: winbond: Clarify when to enable the HS bit") Signed-off-by: Sasha Levin commit 34e666a256de327bc1fa79e9cd18105bd363f5c8 Author: Richard Genoud Date: Tue Mar 17 15:24:30 2026 +0100 mtd: rawnand: sunxi: fix sunxi_nfc_hw_ecc_read_extra_oob [ Upstream commit 848c13996c55fe4ea6bf5acc3ce6c8c5c944b5f6 ] When dumping the OOB, the bytes at the end where actually copied from the beginning of the OOB instead of current_offset. That leads to something like: OOB: ff ff ff ff ff ff ff ff ea 19 00 3a 83 db aa 8d OOB: 99 09 c8 9a 90 36 35 7d aa 15 13 07 3d 97 b2 a4 OOB: a8 bb 19 b3 07 e9 f6 25 52 d7 1a 23 e2 7e 0a e4 OOB: 52 8a 09 d2 1a 86 3d cf b4 99 43 13 d3 90 33 0b OOB: ff ff ff ff ff ff ff ff ea 19 00 3a 83 db aa 8d OOB: 99 09 c8 9a 90 36 35 7d aa 15 13 07 3d 97 b2 a4 OOB: a8 bb 19 b3 07 e9 f6 25 52 d7 1a 23 e2 7e 0a e4 OOB: 52 8a 09 d2 1a 86 3d cf b4 99 43 13 d3 90 33 0b instead of: OOB: ff ff ff ff ff ff ff ff ea 19 00 3a 83 db aa 8d OOB: 99 09 c8 9a 90 36 35 7d aa 15 13 07 3d 97 b2 a4 OOB: a8 bb 19 b3 07 e9 f6 25 52 d7 1a 23 e2 7e 0a e4 OOB: 52 8a 09 d2 1a 86 3d cf b4 99 43 13 d3 90 33 0b OOB: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff OOB: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff OOB: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff OOB: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff (example with BCH16, user data [8,0], no scrambling) *cur_off (offset from the beginning of the page) was compared to offset (offset from the beginning of the OOB), and then, the nand_change_read_column_op() sets the current position to the beginning of the OOB instead of OOB+offset Fixes: 15d6f118285f ("mtd: rawnand: sunxi: Stop supporting ECC_HW_SYNDROME mode") Reviewed-by: Jernej Skrabec Signed-off-by: Richard Genoud Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 84688b608f013d7c21317c58dd6fe971a68c2a9d Author: Li Ming Date: Sat Mar 14 15:06:33 2026 +0800 cxl/pci: Check memdev driver binding status in cxl_reset_done() [ Upstream commit e8069c66d09309579e53567be8ddfa6ccb2f452a ] cxl_reset_done() accesses the endpoint of the corresponding CXL memdev without endpoint validity checking. By default, cxlmd->endpoint is initialized to -ENXIO, if cxl_reset_done() is triggered after the corresponding CXL memdev probing failed, this results in access to an invalid endpoint. CXL subsystem can always check CXL memdev driver binding status to confirm its endpoint validity. So adding the CXL memdev driver checking inside cxl_reset_done() to avoid accessing an invalid endpoint. Fixes: 934edcd436dc ("cxl: Add post-reset warning if reset results in loss of previously committed HDM decoders") Reviewed-by: Dan Williams Reviewed-by: Dave Jiang Signed-off-by: Li Ming Link: https://patch.msgid.link/20260314-fix_access_endpoint_without_drv_check-v2-4-4c09edf2e1db@zohomail.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 5a282a6f81299840898d176d739a897df966635f Author: Cosmin Tanislav Date: Wed Mar 11 17:39:57 2026 +0200 mtd: parsers: ofpart: call of_node_get() for dedicated subpartitions [ Upstream commit e882626c1747653f1f01ea9d12e278e613b11d0f ] In order to parse sub-partitions, add_mtd_partitions() calls parse_mtd_partitions() for all previously found partitions. Each partition will end up being passed to parse_fixed_partitions(), and its of_node will be treated as the ofpart_node. Commit 7cce81df7d26 ("mtd: parsers: ofpart: fix OF node refcount leak in parse_fixed_partitions()") added of_node_put() calls for ofpart_node on all exit paths. In the case where the partition passed to parse_fixed_partitions() has a parent, it is treated as a dedicated partitions node, and of_node_put() is wrongly called for it, even if of_node_get() was not called explicitly. On repeated bind / unbinds of the MTD, the extra of_node_put() ends up decrementing the refcount down to 0, which should never happen, resulting in the following error: OF: ERROR: of_node_release() detected bad of_node_put() on /soc/spi@80007000/flash@0/partitions/partition@0 Call of_node_get() to balance the call to of_node_put() done for dedicated partitions nodes. Fixes: 7cce81df7d26 ("mtd: parsers: ofpart: fix OF node refcount leak in parse_fixed_partitions()") Signed-off-by: Cosmin Tanislav Tested-by: Tommaso Merciai Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit c92dc1b31a1db0e8abcd4252c5ad2f691b70ceeb Author: Cosmin Tanislav Date: Wed Mar 11 17:39:56 2026 +0200 mtd: parsers: ofpart: call of_node_put() only in ofpart_fail path [ Upstream commit 0c87dea1aab86116211cb37387c404c9e9231c39 ] ofpart_none can only be reached after the for_each_child_of_node() loop finishes. for_each_child_of_node() correctly calls of_node_put() for all device nodes it iterates over as long as we don't break or jump out of the loop. Calling of_node_put() inside the ofpart_none path will wrongly decrement the ref count of the last node in the for_each_child_of_node() loop. Move the call to of_node_put() under the ofpart_fail label to fix this. Fixes: ebd5a74db74e ("mtd: ofpart: Check availability of reg property instead of name property") Signed-off-by: Cosmin Tanislav Tested-by: Tommaso Merciai Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 5549c3f88dd7bea1792e11baffc7c3c738a7b5f7 Author: Shiji Yang Date: Wed Jan 28 20:42:56 2026 +0800 mtd: spi-nor: swp: check SR_TB flag when getting tb_mask [ Upstream commit 94645aa41bf9ecb87c2ce78b1c3405bfb6074a37 ] When the chip does not support top/bottom block protect, the tb_mask must be set to 0, otherwise SR1 bit5 will be unexpectedly modified. Signed-off-by: Shiji Yang Fixes: 3dd8012a8eeb ("mtd: spi-nor: add TB (Top/Bottom) protect support") Reviewed-by: Michael Walle Reviewed-by: Miquel Raynal Signed-off-by: Pratyush Yadav (Google) Signed-off-by: Sasha Levin commit 53d7a4e1b04175bedbba3ad7d4d61ad303d51082 Author: Jonas Gorski Date: Thu Dec 18 10:54:30 2025 +0100 mtd: spi-nor: update spi_nor_fixups::post_sfdp() documentation [ Upstream commit 3620d67b48493c6252bbc873dc88dde81641d56b ] After commit 5273cc6df984 ("mtd: spi-nor: core: Call spi_nor_post_sfdp_fixups() only when SFDP is defined") spi_nor_post_sfdp_fixups() isn't called anymore if no SFDP is detected. Update the documentation accordingly. Fixes: 5273cc6df984 ("mtd: spi-nor: core: Call spi_nor_post_sfdp_fixups() only when SFDP is defined") Signed-off-by: Jonas Gorski Reviewed-by: Pratyush Yadav Signed-off-by: Pratyush Yadav (Google) Signed-off-by: Sasha Levin commit 0173aca3e4b1ff20d1c8ee5bb06066c59b726536 Author: Takahiro Kuwano Date: Wed Nov 5 16:47:59 2025 +0900 mtd: spi-nor: sfdp: introduce smpt_map_id fixup hook [ Upstream commit f74de390557bf2bcc5dca4a357b41c0701d3f76e ] Certain chips have inconsistent Sector Map Parameter Table (SMPT) data, which leads to the wrong map ID being identified, causing failures to detect the correct sector map. To fix this, introduce smpt_map_id() into the struct spi_nor_fixups. This function will be called after the initial SMPT-based detection, allowing chip-specific logic to correct the map ID. Infineon S25FS512S needs this fixup as it has inconsistency between map ID definition and configuration register value actually obtained. Co-developed-by: Marek Vasut Signed-off-by: Marek Vasut Reviewed-by: Tudor Ambarus Tested-by: Marek Vasut # S25FS512S Signed-off-by: Takahiro Kuwano Reviewed-by: Tudor Ambarus > Signed-off-by: Pratyush Yadav Stable-dep-of: 3620d67b4849 ("mtd: spi-nor: update spi_nor_fixups::post_sfdp() documentation") Signed-off-by: Sasha Levin commit 6278713f55d42b723abe04c71b89db5e787b3fab Author: Takahiro Kuwano Date: Wed Nov 5 16:47:58 2025 +0900 mtd: spi-nor: sfdp: introduce smpt_read_dummy fixup hook [ Upstream commit 653f6def567c81f37302f9591ffd54df3e2a11eb ] SMPT contains config detection info that describes opcode, address, and dummy cycles to read sector map config. The dummy cycles parameter can be SMPT_CMD_READ_DUMMY_IS_VARIABLE and in that case nor->read_dummy (initialized as 0) is used. In Infineon flash chips, Read Any Register command with variable dummy cycle is defined in SMPT. S25Hx/S28Hx flash has 0 dummy cycle by default to read volatile regiters and nor->read_dummy can work. S25FS-S flash has 8 dummy cycles so we need a hook that can fix dummy cycles with actually used value. Inroduce smpt_read_dummy() in struct spi_nor_fixups. It is called when the dummy cycle field in SMPT config detection is 'varialble'. Reviewed-by: Tudor Ambarus Tested-by: Marek Vasut # S25FS512S Signed-off-by: Takahiro Kuwano Signed-off-by: Pratyush Yadav Stable-dep-of: 3620d67b4849 ("mtd: spi-nor: update spi_nor_fixups::post_sfdp() documentation") Signed-off-by: Sasha Levin commit ad41b585f0e4a67480eda8ea4adab34c277bb865 Author: Haibo Chen Date: Mon Dec 8 17:14:14 2025 +0800 mtd: spi-nor: core: correct the op.dummy.nbytes when check read operations [ Upstream commit 756564a536ecd8c9d33edd89f0647a91a0b03587 ] When check read operation, need to setting the op.dummy.nbytes based on current read operation rather than the nor->read_proto. Fixes: 0e30f47232ab ("mtd: spi-nor: add support for DTR protocol") Signed-off-by: Haibo Chen Reviewed-by: Pratyush Yadav Signed-off-by: Pratyush Yadav (Google) Signed-off-by: Sasha Levin commit 756afec88e85c9ea400564c16373ce7b875c05c0 Author: Geert Uytterhoeven Date: Fri Mar 6 11:26:20 2026 +0100 dt-bindings: interrupt-controller: arm,gic-v3: Fix EPPI range [ Upstream commit 15cfc8984defc17e5e4de1f58db7b993240fcbda ] According to the "Arm Generic Interrupt Controller (GIC) Architecture Specification, v3 and v4", revision H.b[1], there can be only 64 Extended PPI interrupts. [1] https://developer.arm.com/documentation/ihi0069/hb/ Fixes: 4b049063e0bcbfd3 ("dt-bindings: interrupt-controller: arm,gic-v3: Describe EPPI range support") Signed-off-by: Geert Uytterhoeven Brain-farted-by: Marc Zyngier Acked-by: Marc Zyngier Link: https://patch.msgid.link/3e49a63c6b2b6ee48e3737adee87781f9c136c5f.1772792753.git.geert+renesas@glider.be Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin commit b6766b171a5c4c33b26ff6fec530cb798db1f75e Author: Dmitry Safonov <0x7f454c46@gmail.com> Date: Tue Mar 10 17:40:39 2026 +0000 ima_fs: Correctly create securityfs files for unsupported hash algos [ Upstream commit d7bd8cf0b348d3edae7bee33e74a32b21668b181 ] ima_tpm_chip->allocated_banks[i].crypto_id is initialized to HASH_ALGO__LAST if the TPM algorithm is not supported. However there are places relying on the algorithm to be valid because it is accessed by hash_algo_name[]. On 6.12.40 I observe the following read out-of-bounds in hash_algo_name: ================================================================== BUG: KASAN: global-out-of-bounds in create_securityfs_measurement_lists+0x396/0x440 Read of size 8 at addr ffffffff83e18138 by task swapper/0/1 CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.40 #3 Call Trace: dump_stack_lvl+0x61/0x90 print_report+0xc4/0x580 ? kasan_addr_to_slab+0x26/0x80 ? create_securityfs_measurement_lists+0x396/0x440 kasan_report+0xc2/0x100 ? create_securityfs_measurement_lists+0x396/0x440 create_securityfs_measurement_lists+0x396/0x440 ima_fs_init+0xa3/0x300 ima_init+0x7d/0xd0 init_ima+0x28/0x100 do_one_initcall+0xa6/0x3e0 kernel_init_freeable+0x455/0x740 kernel_init+0x24/0x1d0 ret_from_fork+0x38/0x80 ret_from_fork_asm+0x11/0x20 The buggy address belongs to the variable: hash_algo_name+0xb8/0x420 Memory state around the buggy address: ffffffff83e18000: 00 01 f9 f9 f9 f9 f9 f9 00 01 f9 f9 f9 f9 f9 f9 ffffffff83e18080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffff83e18100: 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 00 05 f9 f9 ^ ffffffff83e18180: f9 f9 f9 f9 00 00 00 00 00 00 00 04 f9 f9 f9 f9 ffffffff83e18200: 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9 ================================================================== Seems like the TPM chip supports sha3_256, which isn't yet in tpm_algorithms: tpm tpm0: TPM with unsupported bank algorithm 0x0027 That's TPM_ALG_SHA3_256 == 0x0027 from "Trusted Platform Module 2.0 Library Part 2: Structures", page 51 [1]. See also the related U-Boot algorithms update [2]. Thus solve the problem by creating a file name with "_tpm_alg_" postfix if the crypto algorithm isn't initialized. This is how it looks on the test machine (patch ported to v6.12 release): # ls -1 /sys/kernel/security/ima/ ascii_runtime_measurements ascii_runtime_measurements_tpm_alg_27 ascii_runtime_measurements_sha1 ascii_runtime_measurements_sha256 binary_runtime_measurements binary_runtime_measurements_tpm_alg_27 binary_runtime_measurements_sha1 binary_runtime_measurements_sha256 policy runtime_measurements_count violations [1]: https://trustedcomputinggroup.org/wp-content/uploads/Trusted-Platform-Module-2.0-Library-Part-2-Version-184_pub.pdf [2]: https://lists.denx.de/pipermail/u-boot/2024-July/558835.html Fixes: 9fa8e7625008 ("ima: add crypto agility support for template-hash algorithm") Signed-off-by: Dmitry Safonov Cc: Enrico Bravi Cc: Silvia Sisinni Cc: Roberto Sassu Cc: Mimi Zohar Reviewed-by: Roberto Sassu Tested-by: Roberto Sassu Link: https://github.com/linux-integrity/linux/issues/14 Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit e4e0bd721b92ba5ba02569b37880df5cf5a6e60f Author: Chen Ni Date: Fri Feb 27 09:43:36 2026 +0800 mtd: physmap_of_gemini: Fix disabled pinctrl state check [ Upstream commit b7c0982184b0661f5b1b805f3a56f1bd3757b63e ] The condition for checking the disabled pinctrl state incorrectly checks gf->enabled_state instead of gf->disabled_state. This causes misleading error messages and could lead to incorrect behavior when only one of the pinctrl states is defined. Fix the condition to properly check gf->disabled_state. Fixes: 9d3b5086f6d4 ("mtd: physmap_of_gemini: Handle pin control") Signed-off-by: Chen Ni Reviewed-by: Linus Walleij Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit fb9364ba4fa66deb1e554cbed4a130502b7ba866 Author: Denis Benato Date: Sat Feb 28 20:10:09 2026 +0100 HID: asus: do not abort probe when not necessary [ Upstream commit 7253091766ded0fd81fe8d8be9b8b835495b06e8 ] In order to avoid dereferencing a NULL pointer asus_probe is aborted early and control of some asus devices is transferred over hid-generic after erroring out even when such NULL dereference cannot happen: only early abort when the NULL dereference can happen. Also make the code shorter and more adherent to coding standards removing square brackets enclosing single-line if-else statements. Fixes: d3af6ca9a8c3 ("HID: asus: fix UAF via HID_CLAIMED_INPUT validation") Signed-off-by: Denis Benato Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 59601f0e83d422fd19d6720bc4fd934eeac0c76d Author: Denis Benato Date: Sat Feb 28 20:10:07 2026 +0100 HID: asus: make asus_resume adhere to linux kernel coding standards [ Upstream commit 51d33b42b8ae23da92819d28439fdd5636c45186 ] Linux kernel coding standars requires functions opening brackets to be in a newline: move the opening bracket of asus_resume in its own line. Fixes: 546edbd26cff ("HID: hid-asus: reset the backlight brightness level on resume") Signed-off-by: Denis Benato Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 148e4f7ece72022311f70c5638fb15d4f088db61 Author: Daniel Hodges Date: Sat Jan 31 18:40:15 2026 -0800 ima: check return value of crypto_shash_final() in boot aggregate [ Upstream commit 870819434c8dfcc3158033b66e7851b81bb17e21 ] The return value of crypto_shash_final() is not checked in ima_calc_boot_aggregate_tfm(). If the hash finalization fails, the function returns success and a corrupted boot aggregate digest could be used for IMA measurements. Capture the return value and propagate any error to the caller. Fixes: 76bb28f6126f ("ima: use new crypto_shash API instead of old crypto_hash") Signed-off-by: Daniel Hodges Reviewed-by: Roberto Sassu Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 5bfc58588ae02496a7648a1d07660e3b5ebc8bd4 Author: Chen Ni Date: Mon Feb 9 13:14:07 2026 +0800 remoteproc: imx_rproc: Check return value of regmap_attach_dev() in imx_rproc_mmio_detect_mode() [ Upstream commit a48c6676912fb808d2af1b8344d8656815a3e108 ] Add error checking for regmap_attach_dev() call in imx_rproc_mmio_detect_mode() function to ensure proper error propagation. Return the value of regmap_attach_dev() if it fails to prevent proceeding with an incomplete regmap setup. Suggested-by: Peng Fan Signed-off-by: Chen Ni Fixes: e14168bf3493 ("remoteproc: imx_rproc: Simplify IMX_RPROC_MMIO switch case") Link: https://lore.kernel.org/r/20260209051407.1467660-1-nichen@iscas.ac.cn Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit 28122fcd7bccfe762f58125430f5765326ccd77e Author: Thomas Weißschuh Date: Tue Feb 17 14:11:11 2026 +0100 stop_machine: Fix the documentation for a NULL cpus argument [ Upstream commit 48f7a50c027dd2abb9e7b8a6ecc8e531d87f2c21 ] A recent refactoring of the kernel-docs for stop machine changed the description of the cpus parameter from "NULL = any online cpu" to "NULL = run on each online CPU". However the callback is only executed on a single CPU, not all of them. The old wording was a bit ambiguous and could have been read both ways. Reword the documentation to be correct again and hopefully also clearer. Fixes: fc6f89dc7078 ("stop_machine: Improve kernel-doc function-header comments") Signed-off-by: Thomas Weißschuh Signed-off-by: Paul E. McKenney Reviewed-by: Sebastian Andrzej Siewior Signed-off-by: Sasha Levin commit 405c94550c684c959466ccfe9665906b9630de94 Author: Tim Michals Date: Wed Feb 4 12:27:30 2026 -0800 remoteproc: xlnx: Fix sram property parsing [ Upstream commit d116bccf6f1c199b27c9ebdf07cc3cfe868f919c ] As per sram bindings, "sram" property can be list of phandles. When more than one sram phandles are listed, driver can't parse second phandle's address correctly. Because, phandle index is passed to the API instead of offset of address from reg property which is always 0 as per sram.yaml bindings. Fix it by passing 0 to the API instead of sram phandle index. Fixes: 77fcdf51b8ca ("remoteproc: xlnx: Add sram support") Signed-off-by: Tim Michals Signed-off-by: Tanmay Shah Link: https://lore.kernel.org/r/20260204202730.3729984-1-tanmay.shah@amd.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit 514f1eb75ffb3e5068b7084baeb513f0c2d9b2b4 Author: Francesco Lavra Date: Wed Nov 26 11:46:18 2025 +0100 hte: tegra194: remove Kconfig dependency on Tegra194 SoC [ Upstream commit 92dfd92f747698352b256cd9ddd7497bb7ebe9c8 ] This driver runs also on other Tegra SoCs (e.g. Tegra234). Replace Kconfig dependency on Tegra194 with more generic dependency on Tegra, and amend the Kconfig help text to reflect the fact that this driver works on SoCs other than Tegra194. Fixes: b003fb5c9df8 ("hte: Add Tegra234 provider") Signed-off-by: Francesco Lavra Acked-by: Dipen Patel Signed-off-by: Dipen Patel Signed-off-by: Sasha Levin commit 0402c60abe769098d77f3b3bd1e29a97922b614b Author: Pengpeng Hou Date: Wed Apr 1 19:22:23 2026 +0800 tracing: Rebuild full_name on each hist_field_name() call [ Upstream commit 5ec1d1e97de134beed3a5b08235a60fc1c51af96 ] hist_field_name() uses a static MAX_FILTER_STR_VAL buffer for fully qualified variable-reference names, but it currently appends into that buffer with strcat() without rebuilding it first. As a result, repeated calls append a new "system.event.field" name onto the previous one, which can eventually run past the end of full_name. Build the name with snprintf() on each call and return NULL if the fully qualified name does not fit in MAX_FILTER_STR_VAL. Link: https://patch.msgid.link/20260401112224.85582-1-pengpeng@iscas.ac.cn Fixes: 067fe038e70f ("tracing: Add variable reference handling to hist triggers") Reviewed-by: Tom Zanussi Tested-by: Tom Zanussi Signed-off-by: Pengpeng Hou Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit d7338f4dde91eab87be2a20ead8387bb5f20f078 Author: Arnd Bergmann Date: Tue Feb 3 17:45:29 2026 +0100 tracing: move __printf() attribute on __ftrace_vbprintk() [ Upstream commit 473e470f16f98569d59adc11c4a318780fb68fe9 ] The sunrpc change to use trace_printk() for debugging caused a new warning for every instance of dprintk() in some configurations, when -Wformat-security is enabled: fs/nfs/getroot.c: In function 'nfs_get_root': fs/nfs/getroot.c:90:17: error: format not a string literal and no format arguments [-Werror=format-security] 90 | nfs_errorf(fc, "NFS: Couldn't getattr on root"); I've been slowly chipping away at those warnings over time with the intention of enabling them by default in the future. While I could not figure out why this only happens for this one instance, I see that the __trace_bprintk() function is always called with a local variable as the format string, rather than a literal. Move the __printf(2,3) annotation on this function from the declaration to the caller. As this is can only be validated for literals, the attribute on the declaration causes the warnings every time, but removing it entirely introduces a new warning on the __ftrace_vbprintk() definition. The format strings still get checked because the underlying literal keeps getting passed into __trace_printk() in the "else" branch, which is not taken but still evaluated for compile-time warnings. Cc: Masami Hiramatsu Cc: Anna Schumaker Cc: Chuck Lever Cc: Simon Horman Cc: Mathieu Desnoyers Cc: Andrew Morton Cc: Yury Norov Cc: Randy Dunlap Link: https://patch.msgid.link/20260203164545.3174910-1-arnd@kernel.org Fixes: ec7d8e68ef0e ("sunrpc: add a Kconfig option to redirect dfprintk() output to trace buffer") Acked-by: Jeff Layton Acked-by: Steven Rostedt (Google) Signed-off-by: Arnd Bergmann Acked-by: Andy Shevchenko Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 2be24b87a474336db545a5c9fea57fd0f15183f4 Author: Yury Norov Date: Thu Jan 15 23:25:09 2026 -0500 tracing: move tracing declarations from kernel.h to a dedicated header [ Upstream commit bec261fec6d41318e414c4064f2b67c6db628acd ] Tracing is a half of the kernel.h in terms of LOCs, although it's a self-consistent part. It is intended for quick debugging purposes and isn't used by the normal tracing utilities. Move it to a separate header. If someone needs to just throw a trace_printk() in their driver, they will not have to pull all the heavy tracing machinery. This is a pure move. Link: https://lkml.kernel.org/r/20260116042510.241009-7-ynorov@nvidia.com Signed-off-by: Yury Norov Acked-by: Steven Rostedt Reviewed-by: Andy Shevchenko Reviewed-by: Joel Fernandes Cc: Aaron Tomlin Cc: Andi Shyti Cc: Christophe Leroy (CS GROUP) Cc: Greg Kroah-Hartman Cc: Jani Nikula Cc: Petr Pavlu Cc: Randy Dunlap Signed-off-by: Andrew Morton Stable-dep-of: 473e470f16f9 ("tracing: move __printf() attribute on __ftrace_vbprintk()") Signed-off-by: Sasha Levin commit d09b029f639cddf6336ee3e25d544ac2ddff3499 Author: Steven Rostedt Date: Thu Jan 15 23:25:08 2026 -0500 tracing: remove size parameter in __trace_puts() [ Upstream commit 86e685ff364394b477cd1c476029480a2a1960c5 ] The __trace_puts() function takes a string pointer and the size of the string itself. All users currently simply pass in the strlen() of the string it is also passing in. There's no reason to pass in the size. Instead have the __trace_puts() function do the strlen() within the function itself. This fixes a header recursion issue where using strlen() in the macro calling __trace_puts() requires adding #include in order to use strlen(). Removing the use of strlen() from the header fixes the recursion issue. Link: https://lore.kernel.org/all/aUN8Hm377C5A0ILX@yury/ Link: https://lkml.kernel.org/r/20260116042510.241009-6-ynorov@nvidia.com Signed-off-by: Steven Rostedt (Google) Signed-off-by: Yury Norov Reviewed-by: Andy Shevchenko Reviewed-by: Joel Fernandes Cc: Aaron Tomlin Cc: Andi Shyti Cc: Christophe Leroy (CS GROUP) Cc: Greg Kroah-Hartman Cc: Jani Nikula Cc: Petr Pavlu Cc: Randy Dunlap Signed-off-by: Andrew Morton Stable-dep-of: 473e470f16f9 ("tracing: move __printf() attribute on __ftrace_vbprintk()") Signed-off-by: Sasha Levin commit 1e78af7019762329e7e1ac32ddd3b1a78d56ed2f Author: Richard Fitzgerald Date: Tue Mar 10 11:31:33 2026 +0000 soundwire: cadence: Clear message complete before signaling waiting thread [ Upstream commit cbfea84f820962c3c5394ff06e7e9344c96bf761 ] Clear the CDNS_MCP_INT_RX_WL interrupt before signaling completion. This is to prevent the potential race where: - The main thread is scheduled immediately the completion is signaled, and starts a new message - The RX_WL IRQ for this new message happens before sdw_cdns_irq() has been re-scheduled. - When sdw_cdns_irq() is re-scheduled it clears the new RX_WL interrupt. MAIN THREAD | IRQ THREAD | _cdns_xfer_msg() | { | write data to FIFO | wait_for_completion_timeout() | | <---- RX_WL IRQ | sdw_cdns_irq() | { | signal completion <== RESCHEDULE <== Handle message completion | } | | Start new message | _cdns_xfer_msg() | { | write data to FIFO | wait_for_completion_timeout() | | <---- RX_WL IRQ ==> RESCHEDULE ==> | // New RX_WL IRQ is cleared before | // it has been handled. | clear CDNS_MCP_INTSTAT | return IRQ_HANDLED; | } Before this change, this error message was sometimes seen on kernels that have large amounts of debugging enabled: SCP Msg trf timed out This error indicates that the completion has not been signalled after 500ms. Signed-off-by: Richard Fitzgerald Fixes: 956baa1992f9 ("soundwire: cdns: Add sdw_master_ops and IO transfer support") Reported-by: Norman Bintang Closes: https://issuetracker.google.com/issues/477099834 Reviewed-by: Pierre-Louis Bossart Link: https://patch.msgid.link/20260310113133.1707288-1-rf@opensource.cirrus.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 8995ef2dbebc021e076a78032490cfbb36fb8a17 Author: Frank Li Date: Wed Feb 25 16:41:38 2026 -0500 dmaengine: mxs-dma: Fix missing return value from of_dma_controller_register() [ Upstream commit ab2bf6d4c0a0152907b18d25c1b118ea5ea779df ] Propagate the return value of of_dma_controller_register() in probe() instead of ignoring it. Fixes: a580b8c5429a6 ("dmaengine: mxs-dma: add dma support for i.MX23/28") Signed-off-by: Frank Li Link: https://patch.msgid.link/20260225-mxsdma-module-v3-2-8f798b13baa6@nxp.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 4cafee50af44bb87b32c98770ec722afc4793fa2 Author: Bard Liao Date: Mon Jan 26 13:40:45 2026 +0800 soundwire: Intel: test bus.bpt_stream before assigning it [ Upstream commit b2c9f1d5a7eb50bcdda607afef1378e552bbb490 ] We only allow up to 1 bpt stream running on a SoundWire bus. bus.bpt_stream will be assigned when it is opened and will be set to NULL when it is closed. We do check bus->bpt_stream_refcount if the stream type is SDW_STREAM_BPT in sdw_master_rt_alloc(), but at that moment the bpt stream is allocated and set to bus.bpt_stream. It will lead to the original bus.bpt_stream be changed to the new and not used bpt stream. And it will be released and set to NULL when sdw_slave_bpt_stream_add() return error as it supposed to. Then the original stream will try to use the NULL bus.bpt_stream. Fixes: 4c1ce9f37d8a ("soundwire: intel_ace2x: add BPT send_async/wait callbacks") Reported-by: Simon Trimmer Signed-off-by: Bard Liao Reviewed-by: Simon Trimmer Reviewed-by: Ranjani Sridharan Link: https://patch.msgid.link/20260126054045.2504103-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 03d56c4c3861dcfe741bb82e13750604b0f25867 Author: Cole Leavitt Date: Wed Feb 18 11:02:10 2026 -0700 soundwire: bus: demote UNATTACHED state warnings to dev_dbg() [ Upstream commit 2c96956fe764f8224f9ec93b2a9160a578949a7a ] The dev_warn() messages in sdw_handle_slave_status() for UNATTACHED transitions were added in commit d1b328557058 ("soundwire: bus: add dev_warn() messages to track UNATTACHED devices") to debug attachment failures with dynamic debug enabled. These warnings fire during normal operation -- for example when a codec driver triggers a hardware reset after firmware download, causing the device to momentarily go UNATTACHED before re-attaching -- producing misleading noise on every boot. Demote the messages to dev_dbg() so they remain available via dynamic debug for diagnosing real attachment failures without alarming users during expected initialization sequences. Fixes: d1b328557058 ("soundwire: bus: add dev_warn() messages to track UNATTACHED devices") Signed-off-by: Cole Leavitt Reviewed-by: Richard Fitzgerald Link: https://patch.msgid.link/20260218180210.9263-1-cole@unwrap.rs Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 8cedbb75f70eb7aef4d10ec089407f403ff6a655 Author: Khairul Anuar Romli Date: Mon Feb 2 14:02:19 2026 +0800 dmaengine: dw-axi-dmac: Remove unnecessary return statement from void function [ Upstream commit 48278a72fce8a8d30efaedeb206c9c3f05c1eb3f ] checkpatch.pl --strict reports a WARNING in dw-axi-dmac-platform.c: WARNING: void function return statements are not generally useful FILE: drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c According to Linux kernel coding style [Documentation/process/ coding-style.rst], explicit "return;" statements at the end of void functions are redundant and should be omitted. The function will automatically return upon reaching the closing brace, so the extra statement adds unnecessary clutter without functional benefit. This patch removes the superfluous "return;" statement in dw_axi_dma_set_hw_channel() to comply with kernel coding standards and eliminate the checkpatch warning. Fixes: 32286e279385 ("dmaengine: dw-axi-dmac: Remove free slot check algorithm in dw_axi_dma_set_hw_channel") Signed-off-by: Khairul Anuar Romli Link: https://patch.msgid.link/20260202060224.12616-4-karom.9560@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit aed87e866d1a321edb9703563c2faa8fec89835d Author: ZhengYuan Huang Date: Fri Apr 10 10:02:08 2026 +0800 ocfs2: validate group add input before caching [ Upstream commit 70b672833f4025341c11b22c7f83778a5cd611bc ] [BUG] OCFS2_IOC_GROUP_ADD can trigger a BUG_ON in ocfs2_set_new_buffer_uptodate(): kernel BUG at fs/ocfs2/uptodate.c:509! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ocfs2_set_new_buffer_uptodate+0x194/0x1e0 fs/ocfs2/uptodate.c:509 Code: ffffe88f 42b9fe4c 89e64889 dfe8b4df Call Trace: ocfs2_group_add+0x3f1/0x1510 fs/ocfs2/resize.c:507 ocfs2_ioctl+0x309/0x6e0 fs/ocfs2/ioctl.c:887 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583 x64_sys_call+0x1144/0x26a0 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x93/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7bbfb55a966d [CAUSE] ocfs2_group_add() calls ocfs2_set_new_buffer_uptodate() on a user-controlled group block before ocfs2_verify_group_and_input() validates that block number. That helper is only valid for newly allocated metadata and asserts that the block is not already present in the chosen metadata cache. The code also uses INODE_CACHE(inode) even though the group descriptor belongs to main_bm_inode and later journal accesses use that cache context instead. [FIX] Validate the on-disk group descriptor before caching it, then add it to the metadata cache tracked by INODE_CACHE(main_bm_inode). Keep the validation failure path separate from the later cleanup path so we only remove the buffer from that cache after it has actually been inserted. This keeps the group buffer lifetime consistent across validation, journaling, and cleanup. Link: https://lkml.kernel.org/r/20260410020209.3786348-1-gality369@gmail.com Fixes: 7909f2bf8353 ("[PATCH 2/2] ocfs2: Implement group add for online resize") 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 4c2d62ddde8928db12f4608950b67a20e67deab2 Author: ZhengYuan Huang Date: Fri Apr 10 11:42:20 2026 +0800 ocfs2: validate bg_bits during freefrag scan [ Upstream commit 8f687eeed3da3012152b0f9473f578869de0cd7b ] [BUG] A crafted filesystem can trigger an out-of-bounds bitmap walk when OCFS2_IOC_INFO is issued with OCFS2_INFO_FL_NON_COHERENT. BUG: KASAN: use-after-free in instrument_atomic_read include/linux/instrumented.h:68 [inline] BUG: KASAN: use-after-free in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] BUG: KASAN: use-after-free in test_bit_le include/asm-generic/bitops/le.h:21 [inline] BUG: KASAN: use-after-free in ocfs2_info_freefrag_scan_chain fs/ocfs2/ioctl.c:495 [inline] BUG: KASAN: use-after-free in ocfs2_info_freefrag_scan_bitmap fs/ocfs2/ioctl.c:588 [inline] BUG: KASAN: use-after-free in ocfs2_info_handle_freefrag fs/ocfs2/ioctl.c:662 [inline] BUG: KASAN: use-after-free in ocfs2_info_handle_request+0x1c66/0x3370 fs/ocfs2/ioctl.c:754 Read of size 8 at addr ffff888031bce000 by task syz.0.636/1435 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbe/0x130 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xd1/0x650 mm/kasan/report.c:482 kasan_report+0xfb/0x140 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 [inline] kasan_check_range+0x11c/0x200 mm/kasan/generic.c:200 __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31 instrument_atomic_read include/linux/instrumented.h:68 [inline] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] test_bit_le include/asm-generic/bitops/le.h:21 [inline] ocfs2_info_freefrag_scan_chain fs/ocfs2/ioctl.c:495 [inline] ocfs2_info_freefrag_scan_bitmap fs/ocfs2/ioctl.c:588 [inline] ocfs2_info_handle_freefrag fs/ocfs2/ioctl.c:662 [inline] ocfs2_info_handle_request+0x1c66/0x3370 fs/ocfs2/ioctl.c:754 ocfs2_info_handle+0x18d/0x2a0 fs/ocfs2/ioctl.c:828 ocfs2_ioctl+0x632/0x6e0 fs/ocfs2/ioctl.c:913 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583 ... [CAUSE] ocfs2_info_freefrag_scan_chain() uses on-disk bg_bits directly as the bitmap scan limit. The coherent path reads group descriptors through ocfs2_read_group_descriptor(), which validates the descriptor before use. The non-coherent path uses ocfs2_read_blocks_sync() instead and skips that validation, so an impossible bg_bits value can drive the bitmap walk past the end of the block. [FIX] Compute the bitmap capacity from the filesystem format with ocfs2_group_bitmap_size(), report descriptors whose bg_bits exceeds that limit, and clamp the scan to the computed capacity. This keeps the freefrag report going while avoiding reads beyond the buffer. Link: https://lkml.kernel.org/r/20260410034220.3825769-1-gality369@gmail.com Fixes: d24a10b9f8ed ("Ocfs2: Add a new code 'OCFS2_INFO_FREEFRAG' for o2info ioctl.") Signed-off-by: ZhengYuan Huang Reviewed-by: Heming Zhao 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 2685df8577a38d83b367c8cf52eda9dc286959ff Author: ZhengYuan Huang Date: Fri Apr 10 12:03:39 2026 +0800 ocfs2: fix listxattr handling when the buffer is full [ Upstream commit d12f558e6200b3f47dbef9331ed6d115d2410e59 ] [BUG] If an OCFS2 inode has both inline and block-based xattrs, listxattr() can return a size larger than the caller's buffer when the inline names consume that buffer exactly. kernel BUG at mm/usercopy.c:102! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:usercopy_abort+0xb7/0xd0 mm/usercopy.c:102 Call Trace: __check_heap_object+0xe3/0x120 mm/slub.c:8243 check_heap_object mm/usercopy.c:196 [inline] __check_object_size mm/usercopy.c:250 [inline] __check_object_size+0x5c5/0x780 mm/usercopy.c:215 check_object_size include/linux/ucopysize.h:22 [inline] check_copy_size include/linux/ucopysize.h:59 [inline] copy_to_user include/linux/uaccess.h:219 [inline] listxattr+0xb0/0x170 fs/xattr.c:926 filename_listxattr fs/xattr.c:958 [inline] path_listxattrat+0x137/0x320 fs/xattr.c:988 __do_sys_listxattr fs/xattr.c:1001 [inline] __se_sys_listxattr fs/xattr.c:998 [inline] __x64_sys_listxattr+0x7f/0xd0 fs/xattr.c:998 ... [CAUSE] Commit 936b8834366e ("ocfs2: Refactor xattr list and remove ocfs2_xattr_handler().") replaced the old per-handler list accounting with ocfs2_xattr_list_entry(), but it kept using size == 0 to detect probe mode. That assumption stops being true once ocfs2_listxattr() finishes the inline-xattr pass. If the inline names fill the caller buffer exactly, the block-xattr pass runs with a non-NULL buffer and a remaining size of zero. ocfs2_xattr_list_entry() then skips the bounds check, keeps counting block names, and returns a positive size larger than the supplied buffer. [FIX] Detect probe mode by testing whether the destination buffer pointer is NULL instead of whether the remaining size is zero. That restores the pre-refactor behavior and matches the OCFS2 getxattr helpers. Once the remaining buffer reaches zero while more names are left, the block-xattr pass now returns -ERANGE instead of reporting a size larger than the allocated list buffer. Link: https://lkml.kernel.org/r/20260410040339.3837162-1-gality369@gmail.com Fixes: 936b8834366e ("ocfs2: Refactor xattr list and remove ocfs2_xattr_handler().") 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 a28f56988c8e5bb9375806a5cfb0bf54d662ae3f Author: Richard Cheng Date: Thu Apr 9 13:19:02 2026 +0800 fwctl: Fix class init ordering to avoid NULL pointer dereference on device removal [ Upstream commit a55f80233f384dc89ef3425b2e1dd0e6d44bcf29 ] CXL is linked before fwctl in drivers/Makefile. Both use `module_init, so `cxl_pci_driver_init()` runs first. When `cxl_pci_probe()` calls `fwctl_register()` and then `device_add()`, fwctl_class is not yet registered because fwctl_init() hasn't run, causing `class_to_subsys()` to return NULL and skip knode_class initialization. On device removal, `class_to_subsys()` returns non-NULL, and `device_del()` calls `klist_del()` on the uninitialized knode, triggering a NULL pointer dereference. Fixes: 858ce2f56b52 ("cxl: Add FWCTL support to CXL") Link: https://patch.msgid.link/r/20260409051902.40218-1-icheng@nvidia.com Signed-off-by: Richard Cheng Reviewed-by: Kai-Heng Feng Reviewed-by: Dave Jiang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit a3879c708a60a662b0847ddc5fe527a0d7bc40d9 Author: Sebastian Ene Date: Thu Apr 2 11:39:39 2026 +0000 firmware: arm_ffa: Use the correct buffer size during RXTX_MAP [ Upstream commit 83210251fd70d5f96bcdc8911e15f7411a6b2463 ] Don't use the discovered buffer size from an FFA_FEATURES call directly since we can run on a system that has the PAGE_SIZE larger than the returned size which makes the alloc_pages_exact for the buffer to be rounded up. Fixes: 61824feae5c0 ("firmware: arm_ffa: Fetch the Rx/Tx buffer size using ffa_features()") Signed-off-by: Sebastian Ene Link: https://patch.msgid.link/20260402113939.930221-1-sebastianene@google.com Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 28a547af44323c8da7ffb9427664181e03b373c2 Author: Frank Li Date: Wed Feb 11 18:12:55 2026 -0500 ARM: dts: imx27-eukrea: replace interrupts with interrupts-extended [ Upstream commit 0477a6b31e2874e554e3bcfac9883684b8f8ca2d ] The property interrupts use default interrupt controllers. But pass down gpio as phandle. Correct it by use interrupts-extended. Fixes: d8cae888aa2bc ("ARM: dts: Add support for the cpuimx27 board from Eukrea and its baseboard") Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 6eab9741965b21bba4ad4b460e2ff91487e9b5eb Author: Christian A. Ehrhardt Date: Thu Mar 26 22:49:03 2026 +0100 lib: kunit_iov_iter: fix memory leaks [ Upstream commit 0b49c7d0ae697fcecd7377cb7dda220f7cd096ff ] Use vfree() instead of vunmap() to free the buffer allocated by iov_kunit_create_buffer() because vunmap() does not honour VM_MAP_PUT_PAGES. In order for this to work the page array itself must not be managed by kunit. Remove the folio_put() when destroying a folioq. This is handled by vfree(), now. Pointed out by sashiko.dev on a previous iteration of this series. Tested by running the kunit test 10000 times in a loop. Link: https://lkml.kernel.org/r/20260326214905.818170-4-lk@c--e.de Fixes: 2d71340ff1d4 ("iov_iter: Kunit tests for copying to/from an iterator") Signed-off-by: Christian A. Ehrhardt Cc: David Howells Cc: David Gow Cc: Kees Cook Cc: Petr Mladek Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 3bf5e19c804d0b03f2293a12cac9a3f556c68229 Author: Kees Cook Date: Wed Dec 3 15:30:31 2025 -0800 slab: Introduce kmalloc_obj() and family [ Upstream commit 2932ba8d9c99875b98c951d9d3fd6d651d35df3a ] Introduce type-aware kmalloc-family helpers to replace the common idioms for single object and arrays of objects allocation: ptr = kmalloc(sizeof(*ptr), gfp); ptr = kmalloc(sizeof(struct some_obj_name), gfp); ptr = kzalloc(sizeof(*ptr), gfp); ptr = kmalloc_array(count, sizeof(*ptr), gfp); ptr = kcalloc(count, sizeof(*ptr), gfp); These become, respectively: ptr = kmalloc_obj(*ptr, gfp); ptr = kmalloc_obj(*ptr, gfp); ptr = kzalloc_obj(*ptr, gfp); ptr = kmalloc_objs(*ptr, count, gfp); ptr = kzalloc_objs(*ptr, count, gfp); Beyond the other benefits outlined below, the primary ergonomic benefit is the elimination of needing "sizeof" nor the type name, and the enforcement of assignment types (they do not return "void *", but rather a pointer to the type of the first argument). The type name _can_ be used, though, in the case where an assignment is indirect (e.g. via "return"). This additionally allows[1] variables to be declared via __auto_type: __auto_type ptr = kmalloc_obj(struct foo, gfp); Internal introspection of the allocated type now becomes possible, allowing for future alignment-aware choices to be made by the allocator and future hardening work that can be type sensitive. For example, adding __alignof(*ptr) as an argument to the internal allocators so that appropriate/efficient alignment choices can be made, or being able to correctly choose per-allocation offset randomization within a bucket that does not break alignment requirements. Link: https://lore.kernel.org/all/CAHk-=wiCOTW5UftUrAnvJkr6769D29tF7Of79gUjdQHS_TkF5A@mail.gmail.com/ [1] Acked-by: Vlastimil Babka Link: https://patch.msgid.link/20251203233036.3212363-1-kees@kernel.org Signed-off-by: Kees Cook Stable-dep-of: 0b49c7d0ae69 ("lib: kunit_iov_iter: fix memory leaks") Signed-off-by: Sasha Levin commit 9777d7e6fc58795707dba6b9238cdb95b96144e4 Author: Christoph Hellwig Date: Fri Mar 27 07:16:35 2026 +0100 arm64/xor: fix conflicting attributes for xor_block_template [ Upstream commit 675a0dd596e712404557286d0a883b54ee28e4f4 ] Commit 2c54b423cf85 ("arm64/xor: use EOR3 instructions when available") changes the definition to __ro_after_init instead of const, but failed to update the external declaration in xor.h. This was not found because xor-neon.c doesn't include , and can't easily do that due to current architecture of the XOR code. Link: https://lkml.kernel.org/r/20260327061704.3707577-4-hch@lst.de Fixes: 2c54b423cf85 ("arm64/xor: use EOR3 instructions when available") Signed-off-by: Christoph Hellwig Reviewed-by: Eric Biggers Tested-by: Eric Biggers Cc: Albert Ou Cc: Alexander Gordeev Cc: Alexandre Ghiti Cc: Andreas Larsson Cc: Anton Ivanov Cc: Ard Biesheuvel Cc: Arnd Bergmann Cc: "Borislav Petkov (AMD)" Cc: Catalin Marinas Cc: Chris Mason Cc: Christian Borntraeger Cc: Dan Williams Cc: David S. Miller Cc: David Sterba Cc: Heiko Carstens Cc: Herbert Xu Cc: "H. Peter Anvin" Cc: Huacai Chen Cc: Ingo Molnar Cc: Jason A. Donenfeld Cc: Johannes Berg Cc: Li Nan Cc: Madhavan Srinivasan Cc: Magnus Lindholm Cc: Matt Turner Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Palmer Dabbelt Cc: Richard Henderson Cc: Richard Weinberger Cc: Russell King Cc: Song Liu Cc: Sven Schnelle Cc: Ted Ts'o Cc: Vasily Gorbik Cc: WANG Xuerui Cc: Will Deacon Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 8f466be889a2959b159513b84beca2d00b90064b Author: Aaro Koskinen Date: Fri Mar 27 19:15:10 2026 +0200 ARM: OMAP1: Fix DEBUG_LL and earlyprintk on OMAP16XX [ Upstream commit 7e74b606dd39c46d4378d6f6563f560a00ab8694 ] On OMAP16XX, the UART enable bit shifts are written instead of the actual bits. This breaks the boot when DEBUG_LL and earlyprintk is enabled; the UART gets disabled and some random bits get enabled. Fix that. Fixes: 34c86239b184 ("ARM: OMAP1: clock: Fix early UART rate issues") Signed-off-by: Aaro Koskinen Link: https://patch.msgid.link/aca7HnXZ-aCSJPW7@darkstar.musicnaut.iki.fi Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit 42fbb173e855e592e86cf311cbf08570a25167ed Author: Alexander Koskovich Date: Sun Mar 8 04:26:37 2026 +0000 arm64: dts: qcom: sm8250: Add missing CPU7 3.09GHz OPP [ Upstream commit b683730e27ba4f91986c4c92f5cb7297f1e01a6d ] This resolves the following error seen on the ASUS ROG Phone 3: cpu cpu7: Voltage update failed freq=3091200 cpu cpu7: failed to update OPP for freq=3091200 Fixes: 8e0e8016cb79 ("arm64: dts: qcom: sm8250: Add CPU opp tables") Signed-off-by: Alexander Koskovich Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260307-sm8250-cpu7-opp-v1-1-435f5f6628a1@pm.me Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9dd9d748c5a09584ba0470f4e88cf635051659ef Author: Alok Tiwari Date: Sun Mar 29 12:53:23 2026 -0700 soc: qcom: aoss: compare against normalized cooling state [ Upstream commit cd3c4670db3ffe997be9548c7a9db3952563cf14 ] qmp_cdev_set_cur_state() normalizes the requested state to a boolean (cdev_state = !!state). The existing early-return check compares qmp_cdev->state == state, which can be wrong if state is non-boolean (any non-zero value). Compare qmp_cdev->state against cdev_state instead, so the check matches the effective state and avoids redundant updates. Signed-off-by: Alok Tiwari Fixes: 05589b30b21a ("soc: qcom: Extend AOSS QMP driver to support resources that are used to wake up the SoC.") Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260329195333.1478090-1-alok.a.tiwari@oracle.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 611d9e46bdc6c0d6c005a13643ef185873b6a9fb Author: Alok Tiwari Date: Mon Mar 30 02:51:11 2026 -0700 soc: qcom: llcc: fix v1 SB syndrome register offset [ Upstream commit 24e7625df5ce065393249b78930781be593bc381 ] The llcc_v1_edac_reg_offset table uses 0x2304c for trp_ecc_sb_err_syn0, which is inconsistent with the surrounding TRP ECC registers (0x2034x) and with llcc_v2_1_edac_reg_offset, where trp_ecc_sb_err_syn0 is 0x2034c adjacent to trp_ecc_error_status0/1 at 0x20344/0x20348. Use 0x2034c for llcc v1 so the SB syndrome register follows the expected +0x4 progression from trp_ecc_error_status1. This fixes EDAC reading the wrong register for SB syndrome reporting. Fixes: c13d7d261e36 ("soc: qcom: llcc: Pass LLCC version based register offsets to EDAC driver") Signed-off-by: Alok Tiwari Reviewed-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260330095118.2657362-1-alok.a.tiwari@oracle.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 1fb7f356547d9688822315cd2b205ff0bd5429b4 Author: Junrui Luo Date: Sat Mar 7 15:21:09 2026 +0800 ocfs2/dlm: fix off-by-one in dlm_match_regions() region comparison [ Upstream commit 01b61e8dda9b0fdb0d4cda43de25f4e390554d7b ] The local-vs-remote region comparison loop uses '<=' instead of '<', causing it to read one entry past the valid range of qr_regions. The other loops in the same function correctly use '<'. Fix the loop condition to use '<' for consistency and correctness. Link: https://lkml.kernel.org/r/SYBPR01MB78813DA26B50EC5E01F00566AF7BA@SYBPR01MB7881.ausprd01.prod.outlook.com Fixes: ea2034416b54 ("ocfs2/dlm: Add message DLM_QUERY_REGION") Signed-off-by: Junrui Luo Reported-by: Yuhao Jiang 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 3f474c33ebc2e2ca3fcb587d7de4375348f13373 Author: Junrui Luo Date: Sat Mar 7 15:21:08 2026 +0800 ocfs2/dlm: validate qr_numregions in dlm_match_regions() [ Upstream commit 7ab3fbb01bc6d79091bc375e5235d360cd9b78be ] Patch series "ocfs2/dlm: fix two bugs in dlm_match_regions()". In dlm_match_regions(), the qr_numregions field from a DLM_QUERY_REGION network message is used to drive loops over the qr_regions buffer without sufficient validation. This series fixes two issues: - Patch 1 adds a bounds check to reject messages where qr_numregions exceeds O2NM_MAX_REGIONS. The o2net layer only validates message byte length; it does not constrain field values, so a crafted message can set qr_numregions up to 255 and trigger out-of-bounds reads past the 1024-byte qr_regions buffer. - Patch 2 fixes an off-by-one in the local-vs-remote comparison loop, which uses '<=' instead of '<', reading one entry past the valid range even when qr_numregions is within bounds. This patch (of 2): The qr_numregions field from a DLM_QUERY_REGION network message is used directly as loop bounds in dlm_match_regions() without checking against O2NM_MAX_REGIONS. Since qr_regions is sized for at most O2NM_MAX_REGIONS (32) entries, a crafted message with qr_numregions > 32 causes out-of-bounds reads past the qr_regions buffer. Add a bounds check for qr_numregions before entering the loops. Link: https://lkml.kernel.org/r/SYBPR01MB7881A334D02ACEE5E0645801AF7BA@SYBPR01MB7881.ausprd01.prod.outlook.com Link: https://lkml.kernel.org/r/SYBPR01MB788166F524AD04E262E174BEAF7BA@SYBPR01MB7881.ausprd01.prod.outlook.com Fixes: ea2034416b54 ("ocfs2/dlm: Add message DLM_QUERY_REGION") Signed-off-by: Junrui Luo Reported-by: Yuhao Jiang 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 a261fccdb4ac58ec5ba6aa1d92a6cc418fff301f Author: Michal Grzedzicki Date: Fri Feb 13 11:39:59 2026 -0800 unshare: fix nsproxy leak in ksys_unshare() on set_cred_ucounts() failure [ Upstream commit a98621a0f187a934c115dcfe79a49520ae892111 ] When set_cred_ucounts() fails in ksys_unshare() new_nsproxy is leaked. Let's call put_nsproxy() if that happens. Link: https://lkml.kernel.org/r/20260213193959.2556730-1-mge@meta.com Fixes: 905ae01c4ae2 ("Add a reference to ucounts for each cred") Signed-off-by: Michal Grzedzicki Reviewed-by: Andrew Morton Cc: Alexey Gladkov (Intel) Cc: Ben Segall Cc: David Hildenbrand Cc: Dietmar Eggemann Cc: Ingo Molnar Cc: Juri Lelli Cc: Kees Cook Cc: "Liam R. Howlett" Cc: Lorenzo Stoakes (Oracle) Cc: Mel Gorman Cc: Michal Hocko Cc: Mike Rapoport Cc: Peter Zijlstra Cc: Steven Rostedt Cc: Suren Baghdasaryan Cc: Valentin Schneider Cc: Vincent Guittot Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit c892d0d4fe5ec05d3fdfb1616c3c0e3c12ef5abc Author: Sumit Gupta Date: Wed Jan 21 15:42:05 2026 +0530 soc/tegra: cbb: Fix cross-fabric target timeout lookup [ Upstream commit a5f51b04cbb3ae0f9cb2c4488952b775ebb0ccbf ] When a fabric receives an error interrupt, the error may have occurred on a different fabric. The target timeout lookup was using the wrong base address (cbb->regs) with offsets from a different fabric's target map, causing a kernel page fault. Unable to handle kernel paging request at virtual address ffff80000954cc00 pc : tegra234_cbb_get_tmo_slv+0xc/0x28 Call trace: tegra234_cbb_get_tmo_slv+0xc/0x28 print_err_notifier+0x6c0/0x7d0 tegra234_cbb_isr+0xe4/0x1b4 Add tegra234_cbb_get_fabric() to look up the correct fabric device using fab_id, and use its base address for accessing target timeout registers. Fixes: 25de5c8fe0801 ("soc/tegra: cbb: Improve handling for per SoC fabric data") Signed-off-by: Sumit Gupta Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit f46870b451f7583802ed26eec8b93e138840fcd9 Author: Sumit Gupta Date: Wed Jan 21 15:42:04 2026 +0530 soc/tegra: cbb: Fix incorrect ARRAY_SIZE in fabric lookup tables [ Upstream commit 499f7e5ebbdd9ff0c4d532b1c432f8a61ff585b3 ] Fix incorrect ARRAY_SIZE usage in fabric lookup tables which could cause out-of-bounds access during target timeout lookup. Fixes: 25de5c8fe0801 ("soc/tegra: cbb: Improve handling for per SoC fabric data") Signed-off-by: Sumit Gupta Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 9dc2462a7595f32e970b7c0649d6d7cfd636030d Author: Sumit Gupta Date: Wed Jan 21 15:42:03 2026 +0530 soc/tegra: cbb: Set ERD on resume for err interrupt [ Upstream commit b6ff71c5d1d4ad858ddf6f39394d169c96689596 ] Set the Error Response Disable (ERD) bit to mask SError responses and use interrupt-based error reporting. When the ERD bit is set, inband error responses to the initiator via SError are suppressed, and fabric errors are reported via an interrupt instead. The register is set during boot but the info is lost during system suspend and needs to be set again on resume. Fixes: fc2f151d2314 ("soc/tegra: cbb: Add driver for Tegra234 CBB 2.0") Signed-off-by: Sumit Gupta Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit aabc9baae9a73e65e481219eac4381770f2c6679 Author: Xu Yang Date: Tue Mar 24 19:04:59 2026 +0800 arm64: dts: imx8qxp-mek: switch Type-C connector power-role to dual [ Upstream commit 825b8c7e1d2918d89eb378b761530d1e51dba82e ] When attach to PC Type-A port, the USB device controller does not function at all. Because it is configured as source-only and a Type-A port doesn't support PD capability, a data role swap is impossible. Actually, PTN5110THQ is configured for Source role only at POR, but after POR it can operate as a DRP (Dual-Role Power). By switching the power-role to dual, the port can operate as a sink and enter device mode when attach to Type-A port. Since the board design uses EN_SRC to control the 5V VBUS path and EN_SNK to control the 12V VBUS output, to avoid outputting a higher VBUS when in sink role, we set the operation current limit to 0mA so that SW will not control EN_SNK at all. Fixes: 2faf4ebcee2e5 ("arm64: dts: freescale: imx8qxp-mek: enable cadence usb3") Signed-off-by: Xu Yang Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit bf9a33944d7d08597ddb580d910221c44bd76793 Author: Xu Yang Date: Tue Mar 24 19:04:58 2026 +0800 arm64: dts: imx8qm-mek: switch Type-C connector power-role to dual [ Upstream commit e3d3d19d1c0050789a4813ce836a641a3387d916 ] When attach to PC Type-A port, the USB device controller does not function at all. Because it is configured as source-only and a Type-A port doesn't support PD capability, a data role swap is impossible. Actually, PTN5110THQ is configured for Source role only at POR, but after POR it can operate as a DRP (Dual-Role Power). By switching the power-role to dual, the port can operate as a sink and enter device mode when attach to Type-A port. Since the board design uses EN_SRC to control the 5V VBUS path and EN_SNK to control the 12V VBUS output, to avoid outputting a higher VBUS when in sink role, we set the operation current limit to 0mA so that SW will not control EN_SNK at all. Fixes: b237975b2cd58 ("arm64: dts: imx8qm-mek: add usb 3.0 and related type C nodes") Signed-off-by: Xu Yang Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 3341ca45d2808018bc5f1d0d3abfad12ee38de68 Author: Josua Mayer Date: Tue Mar 24 13:41:01 2026 +0100 arm64: dts: lx2160a: complete pinmux for rcwsr12 configuration word [ Upstream commit 284ad7064aaa1badde022785cd925af29c696b21 ] Commit 8a1365c7bbc1 ("arm64: dts: lx2160a: add pinmux and i2c gpio to support bus recovery") introduced pinmux nodes for lx2160 i2c interfaces, allowing runtime change between i2c and gpio functions implementing bus recovery. However, the dynamic configuration area (overwrite MUX) used by the pinctrl-single driver initially reads as zero and does not reflect the actual hardware state set by the Reset Configuration Word (RCW) at power-on. Because multiple groups of pins are configured from a single 32-bit register, the first write from the pinctrl driver unintentionally clears all other bits to zero. Add description for all bits of RCWSR12 register, allowing boards to explicitly define and restore their intended hardware state. This includes i2c, gpio, flextimer, spi, can and sdhc functions. Other configuration words, i.e. RCWSR13 & RCWSR14 may be added in the future for boards setting non-zero values there. Fixes: 8a1365c7bbc1 ("arm64: dts: lx2160a: add pinmux and i2c gpio to support bus recovery") Signed-off-by: Josua Mayer Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 857dbf1f51feffbb819b7f61b696c76e5fb0ed93 Author: Josua Mayer Date: Tue Mar 24 13:41:00 2026 +0100 arm64: dts: lx2160a: change zeros to hexadecimal in pinmux nodes [ Upstream commit 03241620d2b9915c9e3463dbc56e9eb95ad43c08 ] Replace some stray zeros from decimal to hexadecimal format within pinmux nodes. No functional change intended. Fixes: 8a1365c7bbc1 ("arm64: dts: lx2160a: add pinmux and i2c gpio to support bus recovery") Signed-off-by: Josua Mayer Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit e77a86d883b5e4ee784191bcc406991d10a692eb Author: Josua Mayer Date: Tue Mar 24 13:40:59 2026 +0100 arm64: dts: lx2160a: add sda gpio references for i2c bus recovery [ Upstream commit 89ea0dbd701f89805499d26bd90657468c789545 ] LX2160A pinmux is done in groups by various length bitfields within configuration registers. In particular i2c sda/scl pins are always configured together. Therefore bus recovery may control both sda and scl. When pinmux nodes and bus recovery was enabled originally for LX2160, only the scl-gpios were added to the i2c controller nodes. Add references to sda-gpios for each i2c controller. Fixes: 8a1365c7bbc1 ("arm64: dts: lx2160a: add pinmux and i2c gpio to support bus recovery") Signed-off-by: Josua Mayer Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit ce85b22e556aff1f487196f219e9fa0b02b0ac70 Author: Josua Mayer Date: Tue Mar 24 13:40:58 2026 +0100 arm64: dts: lx2160a: rename pinmux nodes for readability [ Upstream commit 456eb494746afd56d3a9dc30271300136e55b96e ] LX2160A pinmux is done in groups by various length bitfields within configuration registers. Each group of pins is named in the reference manual after a primary function using soc-specific naming, e.g. IIC1 (for i2c0). Hardware block numbering starts from zero in device-tree but one in the reference manual. Rename the already defined pinmux nodes originally added for changing i2c pins between i2c and gpio functions reflecting the reference manual name (IIC) in the node name, and the device-tree name (i2c, gpio) in the label. Specifically, drop the "_scl" suffix from the I2C labels because the nodes actually configure both SDA and SCL pins together. Instead add "_pins" suffix to avoid conflicts with I2C controller labels. For GPIO functions, include the specific controller and pin numbers in the label to clarify they are generic GPIOs and help spot mistakes. No functional change intended. Fixes: 8a1365c7bbc1 ("arm64: dts: lx2160a: add pinmux and i2c gpio to support bus recovery") Signed-off-by: Josua Mayer Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit b165c477175b528d1dc472bf02e79bfcf19a503e Author: Josua Mayer Date: Tue Mar 24 13:40:57 2026 +0100 arm64: dts: lx2160a: remove duplicate pinmux nodes [ Upstream commit 325ca511ca3dda936207ce737e0afe837d45a674 ] LX2160A pinmux is done in groups by various length bitfields within configuration registers. The pinmux nodes i2c7-scl-pins and i2c7-scl-gpio-pins are duplicates of i2c6-scl-gpio and i2c6-scl-gpio-pins, writing to the same register and bits. These two i2c buses i2c6/i2c7 (IIC7/IIC8) are configured together in register RCWSR13 bits 3-0. Drop the duplicate node name and change references to the i2c6 node. Fixes: 8a1365c7bbc1 ("arm64: dts: lx2160a: add pinmux and i2c gpio to support bus recovery") Signed-off-by: Josua Mayer Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 69f4d9ce27d89615561d46aab8d7f121f68413b7 Author: Josua Mayer Date: Tue Mar 24 13:40:56 2026 +0100 arm64: dts: lx2160a: change i2c0 (iic1) pinmux mask to one bit [ Upstream commit 7a3cc49ad1fc8d063abb7f5de8f1b981b99d2978 ] LX2160A pinmux is done in groups by various length bitfields within configuration registers. The first i2c bus (called IIC1 in reference manual) is configured through field IIC1_PMUX in register RCWSR14 bit 10 which is described in the reference manual as a single bit, unlike the other i2c buses. Change the bitmask for the pinmux nodes from 0x7 to 0x1 to ensure only single bit is modified. Further change the zero in the same line to hexadecimal format for consistency. Align with documentation by avoiding writes to reserved bits. No functional change, as writing the extra two reserved bits is not known to cause issues. Fixes: 8a1365c7bbc1 ("arm64: dts: lx2160a: add pinmux and i2c gpio to support bus recovery") Signed-off-by: Josua Mayer Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 5f2ca479f0f30930bbec35dc6280a431d5499e68 Author: Shengjiu Wang Date: Tue Mar 17 13:37:38 2026 +0800 arm64: dts: imx8dxl-evk: Use audio-graph-card2 for wm8960-2 and wm8960-3 [ Upstream commit e8341b0245736619f8d6a2cc311c9e8ad8e82390 ] The sound card wm8960-2 and wm8960-3 only support capture mode for the reason of connection on the EVK board. But fsl-asoc-card don't support capture_only setting, the sound card creation will fail. fsl-sai 59060000.sai: Missing dma channel for stream: 0 fsl-sai 59060000.sai: ASoC error (-22): at snd_soc_pcm_component_new() on 59060000.sai fsl-sai 59070000.sai: Missing dma channel for stream: 0 fsl-sai 59070000.sai: ASoC error (-22): at snd_soc_pcm_component_new() on 59070000.sai so switch to use audio-graph-card2 which supports 'capture_only' property for wm8960-2 and wm8960-3 cards. Fixes: b41c45eb990a ("arm64: dts: imx8dxl-evk: add audio nodes") Signed-off-by: Shengjiu Wang Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 7fedcbedec65ee5d9157403c0fceeba508c49f77 Author: Annette Kobou Date: Mon Mar 9 09:57:43 2026 +0100 arm64: dts: imx8mp-kontron: Fix boot order for PMIC and RTC [ Upstream commit 130d90114c5255a7a729158da8fd8298a02017f1 ] The PMIC provides a level-shifter for the I2C lines to the RTC. As the level shifter needs to be enabled before the RTC can be accessed, make sure that the PMIC driver is probed first. As the PMIC also provides the supply voltage for the RTC through the 3.3V regulator, simply express this in the DT to create the required dependency. Avoid sporadic boot hangs that occurred when the RTC was accessed before the level-shifter was enabled. Fixes: 946ab10e3f40f ("arm64: dts: Add support for Kontron OSM-S i.MX8MP SoM and BL carrier board") Signed-off-by: Annette Kobou Signed-off-by: Frieder Schrempf Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 85163323ab36824da95f07b5203c8d2c3a7e757b Author: Nora Schiffer Date: Mon Mar 2 09:45:48 2026 +0100 arm64: dts: freescale: imx8mp-tqma8mpql-mba8mp-ras314: fix UART1 RTS/CTS muxing [ Upstream commit b8d785a9f360abcd6a6f8f10a2adf222f8494d66 ] UART1 operates in DCE mode, but the RTS/CTS pins were incorrectly configured using the DTE pinmux setting. Correct the pinmux to match DCE mode. Switching the RTS and CTS signals is fine for this board, as UART1 is routed to a pin header. Existing functionality is unaffected, as RTS/CTS could never have worked with the incorrect pinmux. Fixes: ddabb3ce3f90 ("arm64: dts: freescale: add TQMa8MPQL on MBa8MP-RAS314") Signed-off-by: Nora Schiffer Reviewed-by: Alexander Stein Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 4675ae61aa6364bd8802bd6ed42220fd4e1e5197 Author: Francesco Dolcini Date: Tue Mar 24 10:36:57 2026 +0100 arm64: dts: ti: k3-am62-verdin: Fix SPI_1 GPIO CS pinctrl label [ Upstream commit 944dffaec1ef0f21c203728de77b5618ed70df6e ] Fix SPI_1_CS GPIO pinmux label, this is spi1_cs, not qspi1_io4. There are no user of this label yet, therefore this change does not create any compatibility issue. Fixes: fcb335934c51 ("arm64: dts: ti: verdin-am62: Improve spi1 chip-select pinctrl") Signed-off-by: Francesco Dolcini Link: https://patch.msgid.link/20260324093705.26730-3-francesco@dolcini.it Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit 45669e3578aca4e59b1f0ab4637b812a5518632a Author: Judith Mendez Date: Mon Feb 23 17:37:31 2026 -0600 arm64: dts: ti: k3-am62-lp-sk: Enable internal pulls for MMC0 data pins [ Upstream commit ee2a9d9c9e6c9643fb7e45febcaedfbc038e483a ] AM62 LP SK board does not have external pullups on MMC0 DAT1-DAT7 pins [0]. Enable internal pullups on DAT1-DAT7 considering: - without a host-side pullup, these lines rely solely on the eMMC device's internal pullup (R_int, 10-150K per JEDEC), which may exceed the recommended 50K max for 1.8V VCCQ - JEDEC JESD84-B51 Table 200 requires host-side pullups (R_DAT, 10K-100K) on all data lines to prevent bus floating [0] https://www.ti.com/lit/zip/SPRR471 Fixes: a0b8da04153e ("arm64: dts: ti: k3-am62*: Move eMMC pinmux to top level board file") Signed-off-by: Judith Mendez Reviewed-by: Moteen Shah Link: https://patch.msgid.link/20260223233731.2690472-4-jm@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit 5f852e9baea0b1f85a312cad84ff4c96fea6d4d6 Author: Judith Mendez Date: Mon Feb 23 17:37:29 2026 -0600 arm64: dts: ti: k3-am62p5-sk: Disable MMC1 internal pulls on data pins [ Upstream commit 6d4441be969bea89bb9702781f5dfb3a8f2a02a4 ] AM62P SK has external 10K pullups on MMC1 DAT1-DAT3 pins [0]. Disable internal pullups on DAT1-DAT3 so that each line has a single pullup source: - with both pullups enabled, the effective parallel resistance on DAT1-3 (~8.33K) drops below the 10K minimum pullup requirement for data lines (per SD Physical Layer Specification) - removing internal pullups makes DAT1-3 match DAT0 10K external pullup so its consistent and within spec - both internal and external pullups enabled equals unnecessary power consumption [0] https://www.ti.com/lit/zip/SPRR487 Fixes: c00504ea42c0 ("arm64: dts: ti: k3-am62p5-sk: Updates for SK EVM") Signed-off-by: Judith Mendez Reviewed-by: Moteen Shah Link: https://patch.msgid.link/20260223233731.2690472-2-jm@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit 8caadf4fef50be0f93a1a4ceb798d2af3961822b Author: Barnabás Czémán Date: Sun Mar 15 17:26:19 2026 +0100 arm64: dts: qcom: msm8917-xiaomi-riva: Fix board-id for all bootloader [ Upstream commit a49cd243503c528ea99e31a7853cf438ccc9032d ] Redmi 5A comes with multiple bootloader versions where the expected board-id is different. Change the board-id to unified form what works on both bootloader version. Fixes: 26633b582056 ("arm64: dts: qcom: Add Xiaomi Redmi 5A") Reviewed-by: Konrad Dybcio Signed-off-by: Barnabás Czémán Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260315-riva-common-v3-1-897f130786ed@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit bf30d3790340248d876dc430c6c94fc30472292b Author: David Heidelberg Date: Fri Mar 20 18:33:11 2026 +0100 arm64: dts: qcom: sdm845-xiaomi-beryllium: Mark l1a regulator as powered during boot [ Upstream commit 3b0dd81eea6b7a239fce456ce4545af76f1a9715 ] The regulator must be on, since it provides the display subsystem and therefore the bootloader had turned it on before Linux booted. Fixes: 77809cf74a8c ("arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)") Signed-off-by: David Heidelberg Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260320-beryllium-booton-v2-1-931d1be21eae@ixit.cz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 7f8365e8ff829bc963846ac09f3f85439d42284f Author: Luca Weiss Date: Thu Mar 19 09:55:00 2026 +0100 arm64: dts: qcom: sm7225-fairphone-fp4: Fix conflicting bias pinctrl [ Upstream commit be7c1badb0b934cfe88427b1d4ec3eb9f52ba587 ] The pinctrl nodes from sm6350.dtsi already contain a bias-* property, so that needs to be deleted, otherwise the dtb will contain two conflicting bias-* properties. Reported-by: Conor Dooley Closes: https://lore.kernel.org/r/20260310-maritime-silly-05e7b7e03aa6@spud/ Fixes: c4ef464b24c5 ("arm64: dts: qcom: sm7225-fairphone-fp4: Add Bluetooth") Signed-off-by: Luca Weiss Reviewed-by: Konrad Dybcio Reviewed-by: Conor Dooley Link: https://lore.kernel.org/r/20260319-fp4-uart1-fix-v1-1-f6b3fedef583@fairphone.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 1327f28e4775375365966d683541f53d7d0226ee Author: Vladimir Zapolskiy Date: Sat Mar 14 04:37:15 2026 +0200 arm64: dts: qcom: sm8650: Enable UHS-I SDR50 and SDR104 SD card modes [ Upstream commit 93f823e7d48232e62fb8fb74481696609c90244a ] The restriction on UHS-I speed modes was added to all SM8650 platforms by copying it from SM8450 and SM8550 dtsi files, and it was an actually reproducible problem due to the overclocking of SD cards. Since the latter issue has been fixed in the SM8650 GCC driver, UHS-I speed modes are working fine on SM8650 boards, below is the test performed on SM8650-HDK: SDR50 speed mode: mmc0: new UHS-I speed SDR50 SDHC card at address 0001 mmcblk0: mmc0:0001 00000 14.6 GiB mmcblk0: p1 % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 24.8086 s, 43.3 MB/s SDR104 speed mode: mmc0: new UHS-I speed SDR104 SDHC card at address 59b4 mmcblk0: mmc0:59b4 USDU1 28.3 GiB mmcblk0: p1 % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 12.9448 s, 82.9 MB/s Unset the UHS-I speed mode restrictions from the SM8550 platform dtsi file, there is no indication that the SDHC controller is broken. Fixes: 10e024671295 ("arm64: dts: qcom: sm8650: add interconnect dependent device nodes") Reviewed-by: Neil Armstrong Reviewed-by: Konrad Dybcio Signed-off-by: Vladimir Zapolskiy Link: https://lore.kernel.org/r/20260314023715.357512-7-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 3578d41b7ef0609f76a7db84bb71b0b1ab6f7836 Author: Vladimir Zapolskiy Date: Sat Mar 14 04:37:14 2026 +0200 arm64: dts: qcom: sm8550: Enable UHS-I SDR50 and SDR104 SD card modes [ Upstream commit 66b0f024fba0728ddce6916dce173bb1bdd4eab0 ] The restriction on UHS-I speed modes was added to all SM8550 platforms by copying it from SM8450 dtsi file, and due to the overclocking of SD cards it was an actually reproducible problem. Since the latter issue has been fixed, UHS-I speed modes are working fine on SM8550 boards, below is the test performed on SM8550-HDK: SDR50 speed mode: mmc0: new UHS-I speed SDR50 SDHC card at address 0001 mmcblk0: mmc0:0001 00000 14.6 GiB mmcblk0: p1 % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 23.5468 s, 45.6 MB/s SDR104 speed mode: mmc0: new UHS-I speed SDR104 SDHC card at address 59b4 mmcblk0: mmc0:59b4 USDU1 28.3 GiB mmcblk0: p1 % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 11.9819 s, 89.6 MB/s Unset the UHS-I speed mode restrictions from the SM8550 platform dtsi file, there is no indication that the SDHC controller is broken. Fixes: ffc50b2d3828 ("arm64: dts: qcom: Add base SM8550 dtsi") Reviewed-by: Neil Armstrong Signed-off-by: Vladimir Zapolskiy Link: https://lore.kernel.org/r/20260314023715.357512-6-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 2ea7bfce00245cb55378031b5fe2a149f83ddfb7 Author: Vladimir Zapolskiy Date: Sat Mar 14 04:37:13 2026 +0200 arm64: dts: qcom: sm8450: Enable UHS-I SDR50 and SDR104 SD card modes [ Upstream commit db0c5ef1abda6effdc5c85d6688fb6af2b351ae5 ] The reported problem of some non-working UHS-I speed modes on SM8450 originates in commit 0a631a36f724 ("arm64: dts: qcom: Add device tree for Sony Xperia 1 IV"), and then it was spread to all SM8450 powered platforms by commit 9d561dc4e5cc ("arm64: dts: qcom: sm8450: disable SDHCI SDR104/SDR50 on all boards"). The tests show that the rootcause of the problem was related to an overclocking of SD cards, and it's fixed later on by commit a27ac3806b0a ("clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs"). Since then both SDR50 and SDR104 speed modes are working fine on SM8450, tested on SM8450-HDK: SDR50 speed mode: mmc0: new UHS-I speed SDR50 SDHC card at address 0001 mmcblk0: mmc0:0001 00000 14.6 GiB mmcblk0: p1 % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 24.6254 s, 43.6 MB/s SDR104 speed mode: mmc0: new UHS-I speed SDR104 SDHC card at address 59b4 mmcblk0: mmc0:59b4 USDU1 28.3 GiB mmcblk0: p1 % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 12.3266 s, 87.1 MB/s Remove the restrictions on SD card speed modes from the SM8450 platform dtsi file and enable UHS-I speed modes. Fixes: 9d561dc4e5cc ("arm64: dts: qcom: sm8450: disable SDHCI SDR104/SDR50 on all boards") Reviewed-by: Neil Armstrong Reviewed-by: Konrad Dybcio Signed-off-by: Vladimir Zapolskiy Link: https://lore.kernel.org/r/20260314023715.357512-5-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6360bcaf572712cf50398b8ca61ad8cacf234390 Author: Vladimir Zapolskiy Date: Sat Mar 14 04:37:12 2026 +0200 arm64: dts: qcom: hamoa: Fix xo clock supply of platform SD host controller [ Upstream commit d094f79960e1da20c1380083c95945371baa3668 ] The expected frequency of SD host controller core supply clock is 19.2MHz, while RPMH_CXO_CLK clock frequency on SM8650 platform is 38.4MHz. Apparently the overclocked supply clock could be good enough on some boards and even with the most of SD cards, however some low-end UHS-I SD cards in SDR104 mode of the host controller produce I/O errors in runtime, fortunately this problem is gone, if the "xo" clock frequency matches the expected 19.2MHz clock rate. Fixes: ffb21c1e19b1 ("arm64: dts: qcom: x1e80100: Describe the SDHC controllers") Reported-by: Neil Armstrong Signed-off-by: Vladimir Zapolskiy Reviewed-by: Konrad Dybcio Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20260314023715.357512-4-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 168ec540bdfd844c8758ebc1c9ba6e53ca99fc12 Author: Vladimir Zapolskiy Date: Sat Mar 14 04:37:11 2026 +0200 arm64: dts: qcom: sm8650: Fix xo clock supply of SD host controller [ Upstream commit 390903efaa057c44fd80e7d9839419c50092018e ] The expected frequency of SD host controller core supply clock is 19.2MHz, while RPMH_CXO_CLK clock frequency on SM8650 platform is 38.4MHz. Apparently the overclocked supply clock could be good enough on some boards and even with the most of SD cards, however some low-end UHS-I SD cards in SDR104 mode of the host controller produce I/O errors in runtime, fortunately this problem is gone, if the "xo" clock frequency matches the expected 19.2MHz clock rate. Fixes: 10e024671295 ("arm64: dts: qcom: sm8650: add interconnect dependent device nodes") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Konrad Dybcio Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20260314023715.357512-3-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit cd2894362390e44b397a8ce7565c3989ea5a1729 Author: Vladimir Zapolskiy Date: Sat Mar 14 04:37:10 2026 +0200 arm64: dts: qcom: sm8550: Fix xo clock supply of platform SD host controller [ Upstream commit 30ac651c69bddbc83cab6d52fc5d2e03bed83282 ] The expected frequency of SD host controller core supply clock is 19.2MHz, while RPMH_CXO_CLK clock frequency on SM8650 platform is 38.4MHz. Apparently the overclocked supply clock could be good enough on some boards and even with the most of SD cards, however some low-end UHS-I SD cards in SDR104 mode of the host controller produce I/O errors in runtime, fortunately this problem is gone, if the "xo" clock frequency matches the expected 19.2MHz clock rate. Fixes: ffc50b2d3828 ("arm64: dts: qcom: Add base SM8550 dtsi") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Konrad Dybcio Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20260314023715.357512-2-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c1b5e85c88fbf8786803a1458719baac0036a1db Author: Konrad Dybcio Date: Tue Mar 17 15:41:19 2026 +0100 arm64: dts: qcom: sm8750: Fix GIC_ITS range length [ Upstream commit c2f1f8874fda674af1efaa9a90efbdea8b6834ff ] Currently, the GITS_SGIR register is cut off. Fix it up. Fixes: 068c3d3c83be ("arm64: dts: qcom: Add base SM8750 dtsi") Signed-off-by: Konrad Dybcio Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20260317-topic-its_range_fixup-v1-6-49be8076adb1@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 000d5533f451238788f8dca100c9971adc07592b Author: Konrad Dybcio Date: Tue Mar 17 15:41:18 2026 +0100 arm64: dts: qcom: sm8650: Fix GIC_ITS range length [ Upstream commit 6c8e2ca1263d0da5976418ed285eaec430e8d87f ] Currently, the GITS_SGIR register is cut off. Fix it up. Fixes: d2350377997f ("arm64: dts: qcom: add initial SM8650 dtsi") Signed-off-by: Konrad Dybcio Reviewed-by: Neil Armstrong Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20260317-topic-its_range_fixup-v1-5-49be8076adb1@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6670dc96864b4b671d0ae8dd3e3f3f70c5bd7947 Author: Konrad Dybcio Date: Tue Mar 17 15:41:17 2026 +0100 arm64: dts: qcom: sm8550: Fix GIC_ITS range length [ Upstream commit 357c559e386705609b6b9dc0544c420e3f91f3a0 ] Currently, the GITS_SGIR register is cut off. Fix it up. Fixes: ffc50b2d3828 ("arm64: dts: qcom: Add base SM8550 dtsi") Signed-off-by: Konrad Dybcio Reviewed-by: Neil Armstrong Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20260317-topic-its_range_fixup-v1-4-49be8076adb1@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 1de0b109aaa7ed3e6e461fc36f26ca1fa82d1f03 Author: Konrad Dybcio Date: Tue Mar 17 15:41:16 2026 +0100 arm64: dts: qcom: sm8450: Fix GIC_ITS range length [ Upstream commit 14044fa192c50265bc1f636108371044bbdcf7b7 ] Currently, the GITS_SGIR register is cut off. Fix it up. Fixes: fc8b0b9b630d ("arm64: dts: qcom: sm8450 add ITS device tree node") Signed-off-by: Konrad Dybcio Reviewed-by: Neil Armstrong Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20260317-topic-its_range_fixup-v1-3-49be8076adb1@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 3bb7be86f4c0b54d1d0d135d7baa61f6f03b7407 Author: Dmitry Baryshkov Date: Fri Mar 13 17:27:12 2026 +0200 arm64: dts: qcom: sm8650: correct Iris corners for the MXC rail [ Upstream commit 7c302a2a6c1a4644e798ecfc4e72ddc4acec653f ] The corners of the MVS0 / MVS0C clocks on the MMCX rail don't always match the PLL corners on the MXC rail. Correct the performance corners for the MXC rail following the PLL documentation. Fixes: 56cf5ad39a55 ("arm64: dts: qcom: sm8650: add iris DT node") Signed-off-by: Dmitry Baryshkov Reviewed-by: Dikshita Agarwal Link: https://lore.kernel.org/r/20260313-iris-fix-corners-v1-5-32a393c25dda@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 16771dd53aa9365349ec1cdb9ff657e58348a082 Author: Dmitry Baryshkov Date: Fri Mar 13 17:27:11 2026 +0200 arm64: dts: qcom: sm8550: correct Iris corners for the MXC rail [ Upstream commit ff8edb5bc8bdf8bdf4573d8dc062b09cc1e6bc76 ] The corners of the MVS0 / MVS0C clocks on the MMCX rail don't always match the PLL corners on the MXC rail. Correct the performance corners for the MXC rail following the PLL documentation. Fixes: 41661853ae8e ("arm64: dts: qcom: sm8550: add iris DT node") Signed-off-by: Dmitry Baryshkov Reviewed-by: Dikshita Agarwal Link: https://lore.kernel.org/r/20260313-iris-fix-corners-v1-4-32a393c25dda@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 14ec98366e303ffb998ff552d6bfb22672becd65 Author: Dmitry Baryshkov Date: Fri Mar 13 17:27:10 2026 +0200 arm64: dts: qcom: monaco: correct Iris corners for the MXC rail [ Upstream commit bba8d9ba7df8f6592552377049fc84958fd0575a ] The corners of the MVS0 / MVS0C clocks on the MMCX rail don't always match the PLL corners on the MXC rail. Correct the performance corners for the MXC rail following the PLL documentation. Fixes: bf6ec39c3f36 ("arm64: dts: qcom: qcs8300: add video node") Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260313-iris-fix-corners-v1-3-32a393c25dda@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e589b6c38265c3bf8edcfc5854bb42ef251dd8a3 Author: Dmitry Baryshkov Date: Fri Mar 13 17:27:09 2026 +0200 arm64: dts: qcom: lemans: correct Iris corners for the MXC rail [ Upstream commit 85a6cf5ef8cf6e6de948fbba56101fa05049417f ] The corners of the MVS0 / MVS0C clocks on the MMCX rail don't always match the PLL corners on the MXC rail. Correct the performance corners for the MXC rail following the PLL documentation. Fixes: 7bc95052c64f ("arm64: dts: qcom: sa8775p: add support for video node") Signed-off-by: Dmitry Baryshkov Reviewed-by: Dikshita Agarwal Link: https://lore.kernel.org/r/20260313-iris-fix-corners-v1-2-32a393c25dda@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c0040375fec7fbb6860c0b050c650fa8bc68e1cf Author: Dmitry Baryshkov Date: Fri Mar 13 17:27:08 2026 +0200 arm64: dts: qcom: hamoa: correct Iris corners for the MXC rail [ Upstream commit baac8b5e43f42b632b912a6a837d94fd5bca48f2 ] The corners of the MVS0 / MVS0C clocks on the MMCX rail don't always match the PLL corners on the MXC rail. Correct the performance corners for the MXC rail following the PLL documentation. Fixes: 9065340ac04d ("arm64: dts: qcom: x1e80100: Add IRIS video codec") Signed-off-by: Dmitry Baryshkov Reviewed-by: Dikshita Agarwal Link: https://lore.kernel.org/r/20260313-iris-fix-corners-v1-1-32a393c25dda@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 8344cd62b825cb656699a89a0c826faff4b7ed39 Author: Gatien Chevallier Date: Thu Jan 29 13:56:17 2026 +0100 bus: rifsc: fix RIF configuration check for peripherals [ Upstream commit d5ce3b4e951bc41a6ce877c8500bb4fe42146669 ] Peripheral holding CID0 cannot be accessed, remove this completely incorrect check. While there, fix and simplify the semaphore checking that should be performed when the CID filtering is enabled. Fixes: a18208457253 ("bus: rifsc: introduce RIFSC firewall controller driver") Signed-off-by: Gatien Chevallier Link: https://lore.kernel.org/r/20260129-fix_cid_check_rifsc-v1-1-ef280ccf764d@foss.st.com Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit 8bfa413a1bd8b05101151b14614abbab94529250 Author: Shawn Lin Date: Thu Mar 12 09:11:53 2026 +0800 arm64: dts: rockchip: Add mphy reset to ufshc node [ Upstream commit 792c42da47fa199f90492784e3c57280acd57f22 ] The mphy reset signal is used to reset the physical adapter. Resetting other components while leaving the mphy unreset may occasionally prevent the UFS controller from successfully linking up with the device. This addresses an intermittent hardware bug where the UFS link fails to establish under specific timing conditions with certain chips. While difficult to reproduce initially, this issue was consistently observed in downstream testing and requires explicit mphy reset control for full stability. Fixes: c75e5e010fef ("scsi: arm64: dts: rockchip: Add UFS support for RK3576 SoC") Signed-off-by: Shawn Lin Link: https://patch.msgid.link/1773277913-29580-1-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 835d16955dd75e5d742f3f4e8e8145ac455cbd5a Author: 谢致邦 (XIE Zhibang) Date: Thu Mar 19 13:55:00 2026 +0000 arm64: dts: rockchip: Fix RK3562 EVB2 model name [ Upstream commit ede6a05606892bab4f6d785ffcfc124150c2eb32 ] The model name should be "Rockchip RK3562 EVB2 V10 Board". Fixes: ceb6ef1ea900 ("arm64: dts: rockchip: Add RK3562 evb2 devicetree") Signed-off-by: 谢致邦 (XIE Zhibang) Link: https://patch.msgid.link/tencent_78E7E3F6991FB4403D5ADC9E6A6BC3BF8307@qq.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 2fea83507b4cea111f620b0f243a9956dad77682 Author: Dmitry Baryshkov Date: Mon Mar 23 03:20:59 2026 +0200 soc: qcom: ocmem: return -EPROBE_DEFER is ocmem is not available [ Upstream commit 91b59009c7d48b58dbc50fecb27f2ad20749a05a ] If OCMEM is declared in DT, it is expected that it is present and handled by the driver. The GPU driver will ignore -ENODEV error, which typically means that OCMEM isn't defined in DT. Let ocmem return -EPROBE_DEFER if it supposed to be used, but it is not probed (yet). Fixes: 88c1e9404f1d ("soc: qcom: add OCMEM driver") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260323-ocmem-v1-3-ad9bcae44763@oss.qualcomm.com [bjorn: s/ERR_PTR(dev_err_probe)/dev_err_ptr_probe/ Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c10e14863b626abafa3dee6ddece297b54e8b84f Author: Dmitry Baryshkov Date: Mon Mar 23 03:20:58 2026 +0200 soc: qcom: ocmem: register reasons for probe deferrals [ Upstream commit 9dfd69cd89cd6afa4723be9098979abeef3bb8c6 ] Instead of printing messages to the dmesg, let the message be recorded as a reason for the OCMEM client deferral. Fixes: 88c1e9404f1d ("soc: qcom: add OCMEM driver") Signed-off-by: Dmitry Baryshkov Reviewed-by: Brian Masney Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260323-ocmem-v1-2-ad9bcae44763@oss.qualcomm.com [bjorn: s/ERR_PTR(dev_err_probe)/dev_err_ptr_probe/ Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 702ee8e9821b45206d9d79ab3913476b75651afd Author: Dmitry Baryshkov Date: Mon Mar 23 03:20:57 2026 +0200 soc: qcom: ocmem: make the core clock optional [ Upstream commit e8a61c51417c679d1a599fb36695e9d3b8d95514 ] OCMEM's core clock (aka RPM bus 2 clock) is being handled internally by the interconnect driver. Corresponding clock has been dropped from the SMD RPM clock driver. The users of the ocmem will vote on the ocmemnoc interconnect paths, making sure that ocmem is on. Make the clock optional, keeping it for compatibility with older DT. Fixes: d6edc31f3a68 ("clk: qcom: smd-rpm: Separate out interconnect bus clocks") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260323-ocmem-v1-1-ad9bcae44763@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 99eb1df4acd43eaa64b53500b6785eb05be08109 Author: Chris Morgan Date: Tue Mar 10 08:49:19 2026 -0500 arm64: dts: rockchip: Correct Joystick Axes on Gameforce Ace [ Upstream commit c337c1b561c1c3016d30776d7dc2032ea4979334 ] The Gameforce Ace's joystick axes were set incorrectly initially, getting the X/Y and RX/RY axes backwards. Additionally, correct the RY axis so that it is inverted. All axes tested with evtest and outputting correct values. Fixes: 4e946c447a04 ("arm64: dts: rockchip: Add GameForce Ace") Reported-by: sydarn Signed-off-by: Chris Morgan Link: https://patch.msgid.link/20260310134919.550023-1-macroalpha82@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit fd16a9e05b48056661c824a9c6963d5d46bd28d9 Author: Chris Morgan Date: Tue Mar 10 08:46:48 2026 -0500 arm64: dts: rockchip: Correct Fan Supply for Gameforce Ace [ Upstream commit c7079215b7dbf88b84a95ff13982bf3dab3cfbe1 ] Correct the regulator providing power to the PWM controlled fan. Without this fix the fan only runs when the audio path is playing audio (because the speaker amplifier and PWM fan share the same regulator). Fixes: 4e946c447a04 ("arm64: dts: rockchip: Add GameForce Ace") Signed-off-by: Chris Morgan Link: https://patch.msgid.link/20260310134648.550006-1-macroalpha82@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 6db6534abfe13d1192e9b507adecbda98f43136b Author: Robin Murphy Date: Mon Jan 26 12:32:04 2026 +0000 Revert "arm64: dts: rockchip: add SPDIF audio to Beelink A1" [ Upstream commit 03978cb18059ecd27e3d955508b18cf2a1196142 ] This reverts commit bdc4d388c6452498ab62ef2564589f40e0c8c262. While Beelink A1 mostly follows the high-end RK3328 reference design, it does not in fact have the S/PDIF connector, only HDMI and a 3.5mm jack for the analog audio/TV codecs - the tiny form factor literally doesn't have room to fit more! Cc: Christian Hewitt Cc: Alex Bee Fixes: bdc4d388c645 ("arm64: dts: rockchip: add SPDIF audio to Beelink A1") Signed-off-by: Robin Murphy Link: https://patch.msgid.link/0af77a02c2b0806d4ca72066392a5453fcc89a8f.1767111968.git.robin.murphy@arm.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 31d145a54f169317fd08b0b60107e73113544d74 Author: Ming Wang Date: Fri Feb 6 17:04:53 2026 +0800 arm64: dts: rockchip: Fix Bluetooth stability on LCKFB TaiShan Pi [ Upstream commit 861a9593e10bb6ab2a492b315c8a2a3aad70ac00 ] The AP6212 WiFi/BT module on the LCKFB TaiShan Pi (RK3566) is prone to communication timeouts and reset failures (error -110) when operating at 3 Mbps. This patch stabilizes the Bluetooth interface by: 1. Updating the compatible string to 'brcm,bcm43430a1-bt' to better reflect the actual chip revision used in the AP6212 module. 2. Lowering the maximum UART baud rate from 3,000,000 to 1,500,000 bps. Tests show that 1.5 Mbps is the reliable upper limit for this board's UART configuration, eliminating the initialization timeouts. Fixes: 251e5ade9ba4 ("arm64: dts: rockchip: add dts for LCKFB Taishan Pi RK3566") Signed-off-by: Ming Wang Link: https://patch.msgid.link/20260206090453.1041919-1-wming126@126.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 2fda9b3776e04903929fa37d918050df5f13e5a3 Author: Barnabás Czémán Date: Fri Jan 16 08:07:39 2026 +0100 arm64: dts: qcom: msm8953-xiaomi-daisy: fix backlight [ Upstream commit 7131f6d909a6546329b71f2bacfdc60cb3e6020e ] The backlight on this device is connected via 3 strings. Currently, the DT claims only two are present, which results in visible stripes on the display (since every third backlight string remains unconfigured). Fix the number of strings to avoid that. Fixes: 38d779c26395 ("arm64: dts: qcom: msm8953: Add device tree for Xiaomi Mi A2 Lite") Signed-off-by: Barnabás Czémán Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260116-pmi8950-wled-v3-7-e6c93de84079@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 151c29b6952ccd7f267b4b181b52168b736aa66e Author: Barnabás Czémán Date: Fri Jan 16 08:07:37 2026 +0100 arm64: dts: qcom: msm8953-xiaomi-vince: correct wled ovp value [ Upstream commit 9e87f0eaadccc3fecdf3c3c0334e05694804b5f5 ] PMI8950 doesn't actually support setting an OVP threshold value of 29.6 V. The closest allowed value is 29.5 V. Set that instead. Fixes: aa17e707e04a ("arm64: dts: qcom: msm8953: Add device tree for Xiaomi Redmi 5 Plus") Reviewed-by: Konrad Dybcio Signed-off-by: Barnabás Czémán Link: https://lore.kernel.org/r/20260116-pmi8950-wled-v3-5-e6c93de84079@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 1ab2769df3deb91a7b0b222bfcae2a1c530bd65b Author: Josua Mayer Date: Thu Feb 26 18:36:32 2026 +0200 arm64: dts: imx8mp-hummingboard-pulse: fix mini-hdmi dsi port reference [ Upstream commit 1d1d14d4253e6f373c247e67f3716768910be81e ] imx8mp.dtsi includes a default port@1 node with an empty placeholder endpoint intended for linking to a dsi bridge or panel. HummingBoard Pulse mini-hdmi dtsi described a new endpoint node with a different label attached. This duplicate label causes confusion and is suspected to also cause errors during dsi_attach. Remove the duplicate node and link to the one defined in soc dtsi. Further remove the unnecessary attach-bridge property. Fixes: 2a222aa2bee9 ("arm64: dts: add description for solidrun imx8mp hummingboard variants") Signed-off-by: Josua Mayer Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 6c5178dd60366274a5ac180a3ffaba5aca2cd307 Author: Frieder Schrempf Date: Fri Feb 20 11:36:17 2026 +0100 arm64: dts: imx8mp-kontron: Drop vmmc-supply to fix SD card on SMARC eval carrier [ Upstream commit d2ce84eecf081056b1d18d7524de52f849281ba7 ] The SMARC evaluation carrier provides an SD card power switch that complies with the OSM standard definition. The OSM base devicetree already describes this correctly. Stop overriding the vmmc-supply in the board devicetree and rely on the definition from the OSM base DTS instead to fix the power supply configuration for the SD card. Fixes: 6fe1ced5ccab7 ("arm64: dts: Add support for Kontron i.MX8MP SMARC module and eval carrier") Signed-off-by: Frieder Schrempf Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 7e6420179e217308780ce6a8b11f161911fb135b Author: Frieder Schrempf Date: Fri Feb 20 11:36:16 2026 +0100 arm64: dts: imx8mp-kontron: Fix touch reset configuration on DL devices [ Upstream commit 058c53476dde9937877e93d964a283bbb5e1e4c7 ] The reset signal needs a pullup, but there is no hardware pullup. As a workaround, enable the internal pullup to fix the touchscreen. As this deviates from the default generic GPIO settings in the OSM devicetree, add a new node for the touch pinctrl and redefine the generic gpio1 pinctrl. Fixes: 946ab10e3f40f ("arm64: dts: Add support for Kontron OSM-S i.MX8MP SoM and BL carrier board") Signed-off-by: Frieder Schrempf Reviewed-by: Frank Li Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit a5f56ff8573ffdc9cdac21822c139533ae3c1e0e Author: Thorsten Blum Date: Thu Mar 12 17:40:42 2026 +0100 iommufd/selftest: Fix page leaks in mock_viommu_{init,destroy} [ Upstream commit 09c091fddb0b93297ea659ab48ee64f54ebeeaa2 ] mock_viommu_init() allocates two pages using __get_free_pages(..., 1), but its error path and mock_viommu_destroy() only release the first page using free_page(), leaking the second page. Use free_pages() with the matching order instead to avoid any page leaks. Fixes: 80478a2b450e ("iommufd/selftest: Add coverage for the new mmap interface") Link: https://patch.msgid.link/r/20260312164040.457293-3-thorsten.blum@linux.dev Signed-off-by: Thorsten Blum Reviewed-by: Nicolin Chen Reviewed-by: Pranjal Shrivastava Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit d02f10e74fe22abaeb823e1b29c8b059d838ba8a Author: Akari Tsuyukusa Date: Thu Mar 12 13:15:30 2026 +0900 arm64: dts: mediatek: mt7986a: Fix gpio-ranges pin count [ Upstream commit 820ed0c1a13c5fafb36232538d793f99a0986ef3 ] The gpio-ranges in the MT7986A pinctrl node were incorrectly defined, therefore, pin 100 cannot be used. Correct the range count to match the driver. Fixes: c3a064a32ed9 ("arm64: dts: mediatek: add pinctrl support for mt7986a") Signed-off-by: Akari Tsuyukusa Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 1cda0e4ef9c47b46a450571f407735e24abf152b Author: Akari Tsuyukusa Date: Thu Mar 12 13:15:29 2026 +0900 arm64: dts: mediatek: mt7981b: Fix gpio-ranges pin count [ Upstream commit b62a927f4a46a7f58d88ba3d5fb6e88e1a4b4603 ] The gpio-ranges in the MT7981B pinctrl node were incorrectly defined, therefore, pin 56 cannot be used. Correct the range count to match the driver. Fixes: 62b24c7fdf0a ("arm64: dts: mediatek: mt7981: add pinctrl") Signed-off-by: Akari Tsuyukusa Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 1a94d799de9e6ed533d3da3ebcbe48b236196a00 Author: Akari Tsuyukusa Date: Thu Mar 12 13:15:28 2026 +0900 arm64: dts: mediatek: mt6795: Fix gpio-ranges pin count [ Upstream commit c4c4823c8a5baa10b8100b01f49d7c3f4a871689 ] The gpio-ranges in the MT6795 pinctrl node were incorrectly defined, therefore, GPIO196 cannot be used. Correct the range count to match the driver. Fixes: b888886a4536 ("arm64: dts: mediatek: mt6795: Add pinctrl controller node") Signed-off-by: Akari Tsuyukusa Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit a2475c0a2bbbea5a554b1a36a73111c42047396a Author: Konrad Dybcio Date: Mon Jan 26 10:45:03 2026 +0100 arm64: dts: qcom: talos: Add missing clock-names to GCC [ Upstream commit c653607929bb4e0d8b80573bdb523adab5b975c2 ] The binding for this clock controller requires that clock-names are present. They're not really used by the kernel driver, but they're marked as required, so someone might have assumed it's done on purpose (where in reality we try to stay away from that since index-based references are faster, take up less space and are already widely used) and referenced it in drivers for another OS. Hence, do the least painful thing and add the missing entries. Fixes: 8e266654a2fe ("arm64: dts: qcom: add QCS615 platform") Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Reviewed-by: Taniya Das Link: https://lore.kernel.org/r/20260126-topic-talos_dt_warn-v1-1-c452afc647ad@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c4620dad9f1b56830b36c24618aedd11e6510fbb Author: Barnabás Czémán Date: Mon Jan 26 17:34:55 2026 +0100 arm64: dts: qcom: sm6125-xiaomi-ginkgo: Fix reserved gpio ranges [ Upstream commit e8669e010991154bedadd1cd67700544e0362e99 ] The device was crashing on boot because the reserved gpio ranges was wrongly defined. Correct the ranges for avoid pinctrl crashing. Fixes: 9b1a6c925c88 ("arm64: dts: qcom: sm6125: Initial support for xiaomi-ginkgo") Tested-by: Biswapriyo Nath Reviewed-by: Konrad Dybcio Signed-off-by: Barnabás Czémán Link: https://lore.kernel.org/r/20260126-xiaomi-willow-v3-5-aad7b106c311@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 449023f22c11b2816a2655a590aae9b0bf144313 Author: Barnabás Czémán Date: Mon Jan 26 17:34:54 2026 +0100 arm64: dts: qcom: sm6125-xiaomi-ginkgo: Remove extcon [ Upstream commit 79664600fd3ed3972ad9321e13d1f80267730447 ] GPIO pin 102 is related to DisplayPort what is not supported by this device and it is also disabled at downstream, remove the unnecessary extcon-usb node. Fixes: 9b1a6c925c88 ("arm64: dts: qcom: sm6125: Initial support for xiaomi-ginkgo") Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Signed-off-by: Barnabás Czémán Link: https://lore.kernel.org/r/20260126-xiaomi-willow-v3-4-aad7b106c311@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e849632c0988e9f162357449256a92f14978acd1 Author: Barnabás Czémán Date: Mon Jan 26 17:34:52 2026 +0100 arm64: dts: qcom: sm6125-xiaomi-ginkgo: Correct reserved memory ranges [ Upstream commit 242801cc24e865cb525ef7d826ce6ebeffcad606 ] The device was crashing on high memory load because the reserved memory ranges was wrongly defined. Correct the ranges for avoid the crashes. Change the ramoops memory range to match with the values from the recovery to be able to get the results from the device. Fixes: 9b1a6c925c88 ("arm64: dts: qcom: sm6125: Initial support for xiaomi-ginkgo") Reviewed-by: Konrad Dybcio Signed-off-by: Barnabás Czémán Link: https://lore.kernel.org/r/20260126-xiaomi-willow-v3-2-aad7b106c311@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6256ef55fe90c2351c281955d4a97df54ac56a08 Author: Barnabás Czémán Date: Mon Jan 26 17:34:51 2026 +0100 arm64: dts: qcom: sm6125-xiaomi-ginkgo: Remove board-id [ Upstream commit 535e5741bc9acef5ea2561aa300f28370599e7e2 ] Remove board-id it is not necessary for the bootloader. Fixes: 9b1a6c925c88 ("arm64: dts: qcom: sm6125: Initial support for xiaomi-ginkgo") Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Signed-off-by: Barnabás Czémán Link: https://lore.kernel.org/r/20260126-xiaomi-willow-v3-1-aad7b106c311@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 4e3f607c3b99a537f65247725d51b5a2c960d221 Author: Krzysztof Kozlowski Date: Mon Dec 29 15:28:07 2025 +0100 arm64: dts: qcom: sm6125-ginkgo: Fix missing msm-id subtype [ Upstream commit 2c3b8260d1a0d9a388f2d30e3bbe50d93edfa2aa ] qcom,msm-id property must consist of two numbers, where the second number is the subtype, as reported by dtbs_check: sm6125-xiaomi-ginkgo.dtb: / (xiaomi,ginkgo): qcom,msm-id:0: [394] is too short Xiaomi vendor DTS for Trinket IDP and QRD boards uses value of 0x10000, so put it here as well. Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20251229142806.241088-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 535e5741bc9a ("arm64: dts: qcom: sm6125-xiaomi-ginkgo: Remove board-id") Signed-off-by: Sasha Levin commit 643af7b854596c9f02799cd8b93927d8f154ec67 Author: Jacob Pan Date: Fri Feb 13 10:36:36 2026 -0800 iommufd: vfio compatibility extension check for noiommu mode [ Upstream commit 7147ec874ea08c322d779d8eba28946e294ed1f3 ] VFIO_CHECK_EXTENSION should return false for TYPE1_IOMMU variants when in NO-IOMMU mode and IOMMUFD compat container is set. This change makes the behavior match VFIO_CONTAINER in noiommu mode. It also prevents userspace from incorrectly attempting to use TYPE1 IOMMU operations in a no-iommu context. Fixes: d624d6652a65 ("iommufd: vfio container FD ioctl compatibility") Link: https://patch.msgid.link/r/20260213183636.3340-1-jacob.pan@linux.microsoft.com Signed-off-by: Jacob Pan Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 982b56bf7c7d2baf6e4875e06102e17b6927ba8f Author: Sherry Sun Date: Thu Feb 5 15:34:53 2026 +0800 arm64: dts: imx8mp-evk: Enable pull select bit for PCIe regulator GPIO (M.2 W_DISABLE1) [ Upstream commit d1e7eab6033f9885a02c4b4e8f09e34d8e9d21ab ] The current pin configuration for MX8MP_IOMUXC_SD1_DATA4__GPIO2_IO06 sets the weak pull-up but does not enable the pull select field. Bit 8 in the IOMUX register must be set in order for the weak pull-up to actually take effect. Update the pinctrl setting from 0x40 to 0x140 to enable both the pull select and the weak pull-up, ensuring the line behaves as expected. Fixes: d50650500064 ("arm64: dts: imx8mp-evk: Add PCIe support") Signed-off-by: Sherry Sun Reviewed-by: Frank Li Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 8e7ff76becce01927774e784b6aa0ed7e14ff4de Author: Heiko Stuebner Date: Tue Feb 10 09:03:02 2026 +0100 arm64: dts: rockchip: Make Jaguar PCIe-refclk pin use pull-up config [ Upstream commit f45d4356feeba1c8dac3414b688f59292ddfc9f9 ] The hardware PU/PD config of the pin after reset is to pull-up and on Jaguar this will also keep the device in reset until the driver actually enables the pin. So restore this boot pull-up config of the pin on Jaguar instead of setting it to pull-none. Suggested-by: Quentin Schulz Fixes: 0ec7e1096332 ("arm64: dts: rockchip: add PCIe3 support on rk3588-jaguar") Signed-off-by: Heiko Stuebner Reviewed-by: Shawn Lin Reviewed-by: Quentin Schulz Link: https://patch.msgid.link/20260210080303.680403-5-heiko@sntech.de Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit e483129ae51315f12222f034ca40fd9b0780bb0f Author: Luke Wang Date: Tue Feb 3 19:23:10 2026 +0800 arm64: dts: imx91-11x11-evk: change usdhc tuning step for eMMC and SD [ Upstream commit 5ab0c76df2403137a6d0fb27a55e03cedf47f44c ] During system resume, the following errors occurred: [ 430.638625] mmc1: error -84 writing Cache Enable bit [ 430.643618] mmc1: error -84 doing runtime resume For eMMC and SD, there are two tuning pass windows and the gap between those two windows may only have one cell. If tuning step > 1, the gap may just be skipped and host assumes those two windows as a continuous windows. This will cause a wrong delay cell near the gap to be selected. Set the tuning step to 1 to avoid selecting the wrong delay cell. For SDIO, the gap is sufficiently large, so the default tuning step does not cause this issue. Fixes: 6772c4cffd87 ("arm64: dts: freescale: add i.MX91 11x11 EVK basic support") Signed-off-by: Luke Wang Reviewed-by: Frank Li Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit a028d9919f46c3a9490062167a82347126a88485 Author: Francesco Dolcini Date: Mon Jan 19 11:34:09 2026 +0100 arm64: dts: imx8-apalis: Fix LEDs name collision [ Upstream commit 92ab53b9bb2a72581c32073755077af916eb9aee ] Ixora boards have multiple instances of status leds, to avoid a name collision add the function-enumerator property. This fixes the following Linux kernel warnings: leds-gpio leds: Led green:status renamed to green:status_1 due to name collision leds-gpio leds: Led red:status renamed to red:status_1 due to name collision Fixes: c083131c9021 ("arm64: dts: freescale: add apalis imx8 aka quadmax carrier board support") Signed-off-by: Francesco Dolcini Reviewed-by: Frank Li Reviewed-by: Daniel Baluta Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 86b77735cb4c47df862bc9ac6bb8b3fd6e69b118 Author: Mikko Perttunen Date: Mon Jan 26 15:50:43 2026 +0900 memory: tegra30-emc: Fix dll_change check [ Upstream commit 0a93f2355cf4922ad2399dbef5ea1049fef116d4 ] The code checking whether the specified memory timing enables DLL in the EMRS register was reversed. DLL is enabled if bit A0 is low. Fix the check. Fixes: e34212c75a68 ("memory: tegra: Introduce Tegra30 EMC driver") Signed-off-by: Mikko Perttunen Link: https://patch.msgid.link/20260126-fix-emc-dllchange-v1-2-47ad3bb63262@nvidia.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 1793249c067a4b28e1aba0ad0e4d73aa9f9e165a Author: Mikko Perttunen Date: Mon Jan 26 15:50:42 2026 +0900 memory: tegra124-emc: Fix dll_change check [ Upstream commit 9597ab9a8296ab337e6820f8a717ff621078b632 ] The code checking whether the specified memory timing enables DLL in the EMRS register was reversed. DLL is enabled if bit A0 is low. Fix the check. Fixes: 73a7f0a90641 ("memory: tegra: Add EMC (external memory controller) driver") Signed-off-by: Mikko Perttunen Link: https://patch.msgid.link/20260126-fix-emc-dllchange-v1-1-47ad3bb63262@nvidia.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 6dd527eb8b70672f44dbba7ef2985e132dda20ed Author: Rafał Miłecki Date: Tue Feb 24 09:25:41 2026 +0100 ARM: dts: mediatek: mt7623: fix efuse fallback compatible [ Upstream commit 5978ff33cc6f0988388a2830dc5cd2ea4e81f36a ] Fix following validation error: arch/arm/boot/dts/mediatek/mt7623a-rfb-emmc.dtb: efuse@10206000: compatible: 'oneOf' conditional failed, one must be fixed: ['mediatek,mt7623-efuse', 'mediatek,mt8173-efuse'] is too long 'mediatek,mt8173-efuse' was expected 'mediatek,efuse' was expected from schema $id: http://devicetree.org/schemas/nvmem/mediatek,efuse.yaml# arch/arm/boot/dts/mediatek/mt7623a-rfb-emmc.dtb: efuse@10206000: Unevaluated properties are not allowed ('compatible' was unexpected) from schema $id: http://devicetree.org/schemas/nvmem/mediatek,efuse.yaml# Fixes: 43c7a91b4b3a ("arm: dts: mt7623: add efuse nodes to the mt7623.dtsi file") Signed-off-by: Rafał Miłecki Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit e2b1e633257e7236a304eaf9d03b785a0586ed78 Author: Nícolas F. R. A. Prado Date: Fri May 2 12:43:22 2025 -0400 arm64: dts: mediatek: mt8365: Describe infracfg-nao as a pure syscon [ Upstream commit 0651c24658360706c30588cec0a12c05edb03e9a ] The infracfg-nao register space at 0x1020e000 has different registers than the infracfg space at 0x10001000, and most importantly, doesn't contain any clock controls. Therefore it shouldn't use the same compatible used for the mt8365 infracfg clocks driver: mediatek,mt8365-infracfg. Since it currently does, probe errors are reported in the kernel logs: [ 0.245959] Failed to register clk ifr_pmic_tmr: -EEXIST [ 0.245998] clk-mt8365 1020e000.infracfg: probe with driver clk-mt8365 failed with error -17 This register space is used only as a syscon for bus control by the power domain controller, so in order to properly describe it and fix the errors, set its compatible to a distinct compatible used exclusively as a syscon, drop the clock-cells, and while at it rename the node to 'syscon' following the naming convention. Fixes: 6ff945376556 ("arm64: dts: mediatek: Initial mt8365-evk support") Signed-off-by: Nícolas F. R. A. Prado Reviewed-by: David Lechner Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 7164b3953cefd540e7ebca828c793bc6869cfbc4 Author: Joshua Klinesmith Date: Mon Apr 6 22:31:12 2026 -0400 ksmbd: fix use-after-free from async crypto on Qualcomm crypto engine [ Upstream commit 3e298897f41c61450c2e7a4f457e8b2485eb35b3 ] ksmbd_crypt_message() sets a NULL completion callback on AEAD requests and does not handle the -EINPROGRESS return code from async hardware crypto engines like the Qualcomm Crypto Engine (QCE). When QCE returns -EINPROGRESS, ksmbd treats it as an error and immediately frees the request while the hardware DMA operation is still in flight. The DMA completion callback then dereferences freed memory, causing a NULL pointer crash: pc : qce_skcipher_done+0x24/0x174 lr : vchan_complete+0x230/0x27c ... el1h_64_irq+0x68/0x6c ksmbd_free_work_struct+0x20/0x118 [ksmbd] ksmbd_exit_file_cache+0x694/0xa4c [ksmbd] Use the standard crypto_wait_req() pattern with crypto_req_done() as the completion callback, matching the approach used by the SMB client in fs/smb/client/smb2ops.c. This properly handles both synchronous engines (immediate return) and async engines (-EINPROGRESS followed by callback notification). Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Link: https://github.com/openwrt/openwrt/issues/21822 Signed-off-by: Joshua Klinesmith Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit e0e6b14995fd6fa2c0df8c712d76ab32f0694c31 Author: Thomas Huth Date: Fri Apr 10 17:46:37 2026 +0200 efi/capsule-loader: fix incorrect sizeof in phys array reallocation [ Upstream commit 48a428215782321b56956974f23593e40ce84b7a ] The krealloc() call for cap_info->phys in __efi_capsule_setup_info() uses sizeof(phys_addr_t *) instead of sizeof(phys_addr_t), which might be causing an undersized allocation. The allocation is also inconsistent with the initial array allocation in efi_capsule_open() that allocates one entry with sizeof(phys_addr_t), and the efi_capsule_write() function that stores phys_addr_t values (not pointers) via page_to_phys(). On 64-bit systems where sizeof(phys_addr_t) == sizeof(phys_addr_t *), this goes unnoticed. On 32-bit systems with PAE where phys_addr_t is 64-bit but pointers are 32-bit, this allocates half the required space, which might lead to a heap buffer overflow when storing physical addresses. This is similar to the bug fixed in commit fccfa646ef36 ("efi/capsule-loader: fix incorrect allocation size") which fixed the same issue at the initial allocation site. Fixes: f24c4d478013 ("efi/capsule-loader: Reinstate virtual capsule mapping") Assisted-by: Claude:claude-sonnet-4-5 Signed-off-by: Thomas Huth Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit d8ffae016c4a78693fe1283335d0b6833a9c1366 Author: Andreas Gruenbacher Date: Tue Apr 7 12:14:30 2026 +0200 gfs2: prevent NULL pointer dereference during unmount [ Upstream commit 74b4dbb946060a3233604d91859a9abd3708141d ] When flushing out outstanding glock work during an unmount, gfs2_log_flush() can be called when sdp->sd_jdesc has already been deallocated and sdp->sd_jdesc is NULL. Commit 35264909e9d1 ("gfs2: Fix NULL pointer dereference in gfs2_log_flush") added a check for that to gfs2_log_flush() itself, but it missed the sdp->sd_jdesc dereference in gfs2_log_release(). Fix that. Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202604071139.HNJiCaAi-lkp@intel.com/ Fixes: 35264909e9d1 ("gfs2: Fix NULL pointer dereference in gfs2_log_flush") Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 49d9be0722da3a4a893ba905720cba1921834ec3 Author: Andreas Gruenbacher Date: Tue Mar 31 06:13:42 2026 +0200 gfs2: add some missing log locking [ Upstream commit fe2c8d051150b90b3ccb85f89e3b1d636cb88ec8 ] Function gfs2_logd() calls the log flushing functions gfs2_ail1_start(), gfs2_ail1_wait(), and gfs2_ail1_empty() without holding sdp->sd_log_flush_lock, but these functions require exclusion against concurrent transactions. To fix that, add a non-locking __gfs2_log_flush() function. Then, in gfs2_logd(), take sdp->sd_log_flush_lock before calling the above mentioned log flushing functions and __gfs2_log_flush(). Fixes: 5e4c7632aae1c ("gfs2: Issue revokes more intelligently") Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 3f90bfd31f163b2ed6088afe087e45c6338a3737 Author: Arnd Bergmann Date: Fri Mar 27 17:55:08 2026 +0100 vfio: unhide vdev->debug_root [ Upstream commit 555aa178f8d22261d71da74df6267e6e6e97f95a ] When debugfs is disabled, the hisilicon driver now fails to build: drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c: In function 'hisi_acc_vfio_debug_init': drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c:1671:62: error: 'struct vfio_device' has no member named 'debug_root' 1671 | vfio_dev_migration = debugfs_lookup("migration", vdev->debug_root); | ^~ The driver otherwise relies on dead-code elimination, but this reference fails. The single struct member is not going to make much of a difference for memory consumption, so just keep this visible unconditionally. Signed-off-by: Arnd Bergmann Fixes: b398f91779b8 ("hisi_acc_vfio_pci: register debugfs for hisilicon migration driver") Link: https://lore.kernel.org/r/20260327165521.3779707-1-arnd@kernel.org Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit fdd424d7c35633ac577fd87d1b043d1b8a6cd350 Author: Jan Kara Date: Fri Feb 27 14:22:16 2026 +0100 quota: Fix race of dquot_scan_active() with quota deactivation [ Upstream commit e93ab401da4b2e2c1b8ef2424de2f238d51c8b2d ] dquot_scan_active() can race with quota deactivation in quota_release_workfn() like: CPU0 (quota_release_workfn) CPU1 (dquot_scan_active) ============================== ============================== spin_lock(&dq_list_lock); list_replace_init( &releasing_dquots, &rls_head); /* dquot X on rls_head, dq_count == 0, DQ_ACTIVE_B still set */ spin_unlock(&dq_list_lock); synchronize_srcu(&dquot_srcu); spin_lock(&dq_list_lock); list_for_each_entry(dquot, &inuse_list, dq_inuse) { /* finds dquot X */ dquot_active(X) -> true atomic_inc(&X->dq_count); } spin_unlock(&dq_list_lock); spin_lock(&dq_list_lock); dquot = list_first_entry(&rls_head); WARN_ON_ONCE(atomic_read(&dquot->dq_count)); The problem is not only a cosmetic one as under memory pressure the caller of dquot_scan_active() can end up working on freed dquot. Fix the problem by making sure the dquot is removed from releasing list when we acquire a reference to it. Fixes: 869b6ea1609f ("quota: Fix slow quotaoff") Reported-by: Sam Sun Link: https://lore.kernel.org/all/CAEkJfYPTt3uP1vAYnQ5V2ZWn5O9PLhhGi5HbOcAzyP9vbXyjeg@mail.gmail.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit d05d4a6ee877bed2600189c63f7f8de597ec9e88 Author: Andreas Gruenbacher Date: Fri Mar 6 18:05:48 2026 +0100 gfs2: less aggressive low-memory log flushing [ Upstream commit 7288185ce87ec70133b7bc3b694b0f74bf46a0ee ] It turns out that for some workloads, the fix in commit b74cd55aa9a9d ("gfs2: low-memory forced flush fixes") causes the number of forced log flushes to increase to a degree that the overall filesystem performance drops significantly. Address that by forcing a log flush only when gfs2_writepages cannot make any progress rather than when it cannot make "enough" progress. Fixes: b74cd55aa9a9d ("gfs2: low-memory forced flush fixes") Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 2c57d6c0afcd5dc08adf4a10858a04e814b8ec67 Author: Wander Lairson Costa Date: Mon Mar 9 16:46:30 2026 -0300 rtla/utils: Fix resource leak in set_comm_sched_attr() [ Upstream commit 5b6dc659ad792c72b3ff1be8039ae2945e030928 ] The set_comm_sched_attr() function opens the /proc directory via opendir() but fails to call closedir() on its successful exit path. If the function iterates through all processes without error, it returns 0 directly, leaking the DIR stream pointer. Fix this by refactoring the function to use a single exit path. A retval variable is introduced to track the success or failure status. All exit points now jump to a unified out label that calls closedir() before the function returns, ensuring the resource is always freed. Fixes: dada03db9bb19 ("rtla: Remove procps-ng dependency") Signed-off-by: Wander Lairson Costa Link: https://lore.kernel.org/r/20260309195040.1019085-18-wander@redhat.com Signed-off-by: Tomas Glozar Signed-off-by: Sasha Levin commit 6a815bb366c9b5d4546c3fa4da0474edd40e7803 Author: Wander Lairson Costa Date: Tue Jan 6 08:49:40 2026 -0300 rtla: Replace atoi() with a robust strtoi() [ Upstream commit 7e9dfccf8f11c26208211457c4597a466135b56a ] The atoi() function does not perform error checking, which can lead to undefined behavior when parsing invalid or out-of-range strings. This can cause issues when parsing user-provided numerical inputs, such as signal numbers, PIDs, or CPU lists. To address this, introduce a new strtoi() helper function that safely converts a string to an integer. This function validates the input and checks for overflows, returning a negative value on failure. Replace all calls to atoi() with the new strtoi() function and add proper error handling to make the parsing more robust and prevent potential issues. Signed-off-by: Wander Lairson Costa Link: https://lore.kernel.org/r/20260106133655.249887-5-wander@redhat.com Signed-off-by: Tomas Glozar Stable-dep-of: 5b6dc659ad79 ("rtla/utils: Fix resource leak in set_comm_sched_attr()") Signed-off-by: Sasha Levin commit dac3f0a68ec25169ed6d6bbe566835697f836268 Author: Ivan Pravdin Date: Mon Nov 3 11:19:06 2025 -0500 rtla: Fix -C/--cgroup interface [ Upstream commit 7b71f3a6986c93defbb72bb6c143e04122720cb1 ] Currently, user can only specify cgroup to the tracer's thread the following ways: `-C[cgroup]` `-C[=cgroup]` `--cgroup[=cgroup]` If user tries to specify cgroup as `-C [cgroup]` or `--cgroup [cgroup]`, the parser silently fails and rtla's cgroup is used for the tracer threads. To make interface more user-friendly, allow user to specify cgroup in the aforementioned way, i.e. `-C [cgroup]` and `--cgroup [cgroup]`. Refactor identical logic between -t/--trace and -C/--cgroup into a common function. Change documentation to reflect this user interface change. Fixes: a957cbc02531 ("rtla: Add -C cgroup support") Signed-off-by: Ivan Pravdin Reviewed-by: Tomas Glozar Link: https://lore.kernel.org/r/16132f1565cf5142b5fbd179975be370b529ced7.1762186418.git.ipravdin.official@gmail.com [ use capital letter in subject, as required by tracing subsystem ] Signed-off-by: Tomas Glozar Stable-dep-of: 5b6dc659ad79 ("rtla/utils: Fix resource leak in set_comm_sched_attr()") Signed-off-by: Sasha Levin commit 0a7a4ab3be8e34200f28861b95ddb74b279681ee Author: Ricardo B. Marlière Date: Sat Mar 7 19:08:03 2026 -0300 ktest: Run POST_KTEST hooks on failure and cancellation [ Upstream commit bc6e165a452da909cef0efbc286e6695624db372 ] PRE_KTEST can be useful for setting up the environment and POST_KTEST to tear it down, however POST_KTEST only runs on the normal end-of-run path. It is skipped when ktest exits through dodie() or cancel_test(). Final cleanup hooks are skipped. Factor the final hook execution into run_post_ktest(), call it from the normal exit path and from the early exit paths, and guard it so the hook runs at most once. Cc: John Hawley Cc: Andrea Righi Cc: Marcos Paulo de Souza Cc: Matthieu Baerts Cc: Fernando Fernandez Mancera Cc: Pedro Falcato Link: https://patch.msgid.link/20260307-ktest-fixes-v1-8-565d412f4925@suse.com Fixes: 921ed4c7208e ("ktest: Add PRE/POST_KTEST and TEST options") Signed-off-by: Ricardo B. Marlière Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 9b798ad996922e28341a0aa87ecbc50f964d7e2c Author: Ricardo B. Marlière Date: Sat Mar 7 19:07:59 2026 -0300 ktest: Honor empty per-test option overrides [ Upstream commit a2de57a3c8192dcd67cccaff6c341b93748d799b ] A per-test override can clear an inherited default option by assigning an empty value, but __set_test_option() still used option_defined() to decide whether a per-test key existed. That turned an empty per-test assignment back into "fall back to the default", so tests still could not clear inherited settings. For example: DEFAULTS (...) LOG_FILE = /tmp/ktest-empty-override.log CLEAR_LOG = 1 ADD_CONFIG = /tmp/.config TEST_START TEST_TYPE = build BUILD_TYPE = nobuild ADD_CONFIG = This would run the test with ADD_CONFIG[1] = /tmp/.config Fix by checking whether the per-test key exists before falling back. If it does exist but is empty, treat it as unset for that test and stop the fallback chain there. Cc: John Hawley Cc: Andrea Righi Cc: Marcos Paulo de Souza Cc: Matthieu Baerts Cc: Fernando Fernandez Mancera Cc: Pedro Falcato Link: https://patch.msgid.link/20260307-ktest-fixes-v1-4-565d412f4925@suse.com Fixes: 22c37a9ac49d ("ktest: Allow tests to undefine default options") Signed-off-by: Ricardo B. Marlière Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit f68e24b9697af129756e25309b3c969a0038ca8b Author: Ricardo B. Marlière Date: Sat Mar 7 19:07:56 2026 -0300 ktest: Avoid undef warning when WARNINGS_FILE is unset [ Upstream commit 057854f8a595160656fe77ed7bf0d2403724b915 ] check_buildlog() probes $warnings_file with -f even when WARNINGS_FILE is not configured. Perl warns about the uninitialized value and adds noise to the test log, which can hide the output we actually care about. Check that WARNINGS_FILE is defined before testing whether the file exists. Cc: John Hawley Cc: Andrea Righi Cc: Marcos Paulo de Souza Cc: Matthieu Baerts Cc: Fernando Fernandez Mancera Cc: Pedro Falcato Link: https://patch.msgid.link/20260307-ktest-fixes-v1-1-565d412f4925@suse.com Fixes: 4283b169abfb ("ktest: Add make_warnings_file and process full warnings") Signed-off-by: Ricardo B. Marlière Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 14dee7a3441fa66b4b37dea99b5b5f261fad3722 Author: Ondrej Mosnacek Date: Mon Feb 16 16:06:25 2026 +0100 fanotify: call fanotify_events_supported() before path_permission() and security_path_notify() [ Upstream commit 66052a768d4726a31e939b5ac902f2b0b452c8d5 ] The latter trigger LSM (e.g. SELinux) checks, which will log a denial when permission is denied, so it's better to do them after validity checks to avoid logging a denial when the operation would fail anyway. Fixes: 0b3b094ac9a7 ("fanotify: Disallow permission events for proc filesystem") Signed-off-by: Ondrej Mosnacek Reviewed-by: Amir Goldstein Reviewed-by: Paul Moore Link: https://patch.msgid.link/20260216150625.793013-3-omosnace@redhat.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 27c95204b51820bcc1ad1dab3e12abd4b42ef2b1 Author: Ondrej Mosnacek Date: Mon Feb 16 16:06:24 2026 +0100 fanotify: avoid/silence premature LSM capability checks [ Upstream commit 0d5ee3373426395478c355f3e93ba4b1118a04e9 ] Make sure calling capable()/ns_capable() actually leads to access denied when false is returned, because these functions emit an audit record when a Linux Security Module denies the capability, which makes it difficult to avoid allowing/silencing unnecessary permissions in security policies (namely with SELinux). Where the return value just used to set a flag, use the non-auditing ns_capable_noaudit() instead. Fixes: 7cea2a3c505e ("fanotify: support limited functionality for unprivileged users") Signed-off-by: Ondrej Mosnacek Reviewed-by: Paul Moore Reviewed-by: Amir Goldstein Link: https://patch.msgid.link/20260216150625.793013-2-omosnace@redhat.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 0d19bce169328388039ea26184b063c2678ec503 Author: Andreas Gruenbacher Date: Mon Feb 23 12:04:05 2026 +0100 gfs2: Call unlock_new_inode before d_instantiate [ Upstream commit 2ff7cf7e0640ff071ebc5c7e3dc2df024a7c91e6 ] As Neil Brown describes in detail in the link referenced below, new inodes must be unlocked before they can be instantiated. An even better fix is to use d_instantiate_new(), which combines d_instantiate() and unlock_new_inode(). Fixes: 3d36e57ff768 ("gfs2: gfs2_create_inode rework") Reported-by: syzbot+0ea5108a1f5fb4fcc2d8@syzkaller.appspotmail.com Link: https://lore.kernel.org/linux-fsdevel/177153754005.8396.8777398743501764194@noble.neil.brown.name/ Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit ac25916e75ca2c68274b642b44e84cf8ae654afe Author: Kailang Yang Date: Tue Apr 14 15:44:04 2026 +0800 ALSA: hda/realtek - fixed speaker no sound update [ Upstream commit 46c862f5419e0a86b60b9f9558d247f6084c99f9 ] Fixed speaker has pop noise on Lenovo Thinkpad X11 Carbon Gen 12. Fixes: 630fbc6e870e ("ALSA: hda/realtek - fixed speaker no sound") Reported-and-tested-by: Jeremy Bethmont Closes: https://lore.kernel.org/CAC88DfsHrhyhy0Pn1O-z9egBvMYu=6NYgcvcC6KCgwh_-Ldkxg@mail.gmail.com Signed-off-by: Kailang Yang Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 4573698801107087b583dc9554161b90209f5626 Author: Geoffrey D. Bennett Date: Tue Apr 14 03:03:00 2026 +0930 ALSA: usb-audio: Exclude Scarlett 18i20 1st Gen from SKIP_IFACE_SETUP [ Upstream commit a47306a74c31557b1e5cab54642950bbb20294cb ] Same issue as the other 1st Gen Scarletts: QUIRK_FLAG_SKIP_IFACE_SETUP causes distorted audio on the Scarlett 18i20 1st Gen (1235:800c). Fixes: 38c322068a26 ("ALSA: usb-audio: Add QUIRK_FLAG_SKIP_IFACE_SETUP") Reported-by: tucktuckg00se [https://github.com/geoffreybennett/linux-fcp/issues/54] Signed-off-by: Geoffrey D. Bennett Link: https://patch.msgid.link/ad0ozNnkcFrcjVQz@m.b4.vu Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ff734dbd9e2432601a6dcd167cfb0bf8a36d1880 Author: Haixin Xu Date: Mon Mar 30 15:23:46 2026 +0800 crypto: jitterentropy - replace long-held spinlock with mutex [ Upstream commit 01d798e9feb30212952d4e992801ba6bd6a82351 ] jent_kcapi_random() serializes the shared jitterentropy state, but it currently holds a spinlock across the jent_read_entropy() call. That path performs expensive jitter collection and SHA3 conditioning, so parallel readers can trigger stalls as contending waiters spin for the same lock. To prevent non-preemptible lock hold, replace rng->jent_lock with a mutex so contended readers sleep instead of spinning on a shared lock held across expensive entropy generation. Fixes: bb5530e40824 ("crypto: jitterentropy - add jitterentropy RNG") Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Yuan Tan Suggested-by: Xin Liu Signed-off-by: Haixin Xu Reviewed-by: Stephan Mueller Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 3ab9ab2dc18829d8c4bb65a677ae4ef7beb5c728 Author: Tejun Heo Date: Fri Apr 10 07:54:06 2026 -1000 sched_ext: Fix ops.cgroup_move() invocation kf_mask and rq tracking [ Upstream commit b470e37c1fad72731be6f437e233cb6b16618f41 ] sched_move_task() invokes ops.cgroup_move() inside task_rq_lock(tsk), so @p's rq lock is held. The SCX_CALL_OP_TASK invocation mislabels this: - kf_mask = SCX_KF_UNLOCKED (== 0), claiming no lock is held. - rq = NULL, so update_locked_rq() doesn't run and scx_locked_rq() returns NULL. Switch to SCX_KF_REST and pass task_rq(p), matching ops.set_cpumask() from set_cpus_allowed_scx(). Three effects: - scx_bpf_task_cgroup() becomes callable (was rejected by scx_kf_allowed(__SCX_KF_RQ_LOCKED)). Safe; rq lock is held. - scx_bpf_dsq_move() is now rejected (was allowed via the unlocked branch). Calling it while holding an unrelated task's rq lock is risky; rejection is correct. - scx_bpf_select_cpu_*() previously took the unlocked branch in select_cpu_from_kfunc() and called task_rq_lock(p, &rf), which would deadlock against the already-held pi_lock. Now it takes the locked-rq branch and is rejected with -EPERM via the existing kf_allowed(SCX_KF_SELECT_CPU | SCX_KF_ENQUEUE) check. Latent deadlock fix. No in-tree scheduler is known to call any of these from ops.cgroup_move(). v2: Add Fixes: tag (Andrea Righi). Fixes: 18853ba782be ("sched_ext: Track currently locked rq") Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi Signed-off-by: Sasha Levin commit b60a90bf7cde00d166ecf54971b7a859ca291504 Author: Tejun Heo Date: Fri Apr 10 07:54:06 2026 -1000 sched_ext: Track @p's rq lock across set_cpus_allowed_scx -> ops.set_cpumask [ Upstream commit 9fb457074f6d118b30458624223abef985725a88 ] The SCX_CALL_OP_TASK call site passes rq=NULL incorrectly, leaving scx_locked_rq() unset. Pass task_rq(p) instead so update_locked_rq() reflects reality. v2: Add Fixes: tag (Andrea Righi). Fixes: 18853ba782be ("sched_ext: Track currently locked rq") Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi Signed-off-by: Sasha Levin commit 9769c143015cba7fbb3225940ff183d121ad234e Author: Ming-Hung Tsai Date: Fri Apr 10 21:08:01 2026 +0800 dm cache: fix missing return in invalidate_committed's error path [ Upstream commit 8c0ee19db81f0fa1ff25fd75b22b17c0cc2acde3 ] In passthrough mode, dm-cache defers write submission until after metadata commit completes via the invalidate_committed() continuation. On commit error, invalidate_committed() calls invalidate_complete() to end the bio and free the migration struct, after which it should return immediately. The patch 4ca8b8bd952d ("dm cache: fix write hang in passthrough mode") omitted this early return, causing execution to fall through into the success path on error. This results in use-after-free on the migration struct in the subsequent calls. Fix by adding the missing return after the invalidate_complete() call. Fixes: 4ca8b8bd952d ("dm cache: fix write hang in passthrough mode") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/dm-devel/adjMq6T5RRjv_uxM@stanley.mountain/ Signed-off-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 9a0f6c0485544311ff7151d6881912f31012afb9 Author: Cássio Gabriel Date: Fri Apr 10 00:54:32 2026 -0300 ALSA: sc6000: Keep the programmed board state in card-private data [ Upstream commit fb79bf127ac2577b4876132da6dba768018aad4c ] The driver may auto-select IRQ and DMA resources at probe time, but sc6000_init_board() still derives the SC-6000 soft configuration from the module parameter arrays. When irq=auto or dma=auto is used, the codec is created with the selected resources while the board is programmed with the unresolved values. Store the mapped ports and generated SC-6000 board configuration in card-private data, build that configuration from the live probe results instead of the raw module parameters, and keep the probe-time board programming in a shared helper. This fixes the resource-programming mismatch and leaves the driver with a stable board-state block that can be reused by suspend/resume. Fixes: c282866101bf ("ALSA: sc6000: add support for SC-6600 and SC-7000") Signed-off-by: Cássio Gabriel Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260410-alsa-sc6000-pm-v1-1-4d9e95493d26@gmail.com Signed-off-by: Sasha Levin commit e0b049bd7b279d7b6ad22a637cddced93198a51b Author: Pei Xiao Date: Tue Apr 7 15:26:59 2026 +0800 spi: mtk-snfi: unregister ECC engine on probe failure and remove() callback [ Upstream commit ab00febad191d7a4400aa1c3468279fb508258d4 ] mtk_snand_probe() registers the on-host NAND ECC engine, but teardown was missing from both probe unwind and remove-time cleanup. Add a devm cleanup action after successful registration so nand_ecc_unregister_on_host_hw_engine() runs automatically on probe failures and during device removal. Fixes: 764f1b748164 ("spi: add driver for MTK SPI NAND Flash Interface") Signed-off-by: Pei Xiao Link: https://patch.msgid.link/20263f885f1a9c9d559f95275298cd6de4b11ed5.1775546401.git.xiaopei01@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b059a41bdd5b202b2b9d7708403fb43c69689e53 Author: Manikanta Maddireddy Date: Wed Mar 25 00:37:55 2026 +0530 PCI: tegra194: Fix CBB timeout caused by DBI access before core power-on [ Upstream commit 34b3eef48d980cd37b876e128bbf314f69fb5d70 ] When PERST# is deasserted twice (assert -> deassert -> assert -> deassert), a CBB (Control Backbone) timeout occurs at DBI register offset 0x8bc (PCIE_MISC_CONTROL_1_OFF). This happens because pci_epc_deinit_notify() and dw_pcie_ep_cleanup() are called before reset_control_deassert() powers on the controller core. The call chain that causes the timeout: pex_ep_event_pex_rst_deassert() pci_epc_deinit_notify() pci_epf_test_epc_deinit() pci_epf_test_clear_bar() pci_epc_clear_bar() dw_pcie_ep_clear_bar() __dw_pcie_ep_reset_bar() dw_pcie_dbi_ro_wr_en() <- Accesses 0x8bc DBI register reset_control_deassert(pcie->core_rst) <- Core powered on HERE The DBI registers, including PCIE_MISC_CONTROL_1_OFF (0x8bc), are only accessible after the controller core is powered on via reset_control_deassert(pcie->core_rst). Accessing them before this point results in a CBB timeout because the hardware is not yet operational. Fix this by moving pci_epc_deinit_notify() and dw_pcie_ep_cleanup() to after reset_control_deassert(pcie->core_rst), ensuring the controller is fully powered on before any DBI register accesses occur. Fixes: 40e2125381dc ("PCI: tegra194: Move controller cleanups to pex_ep_event_pex_rst_deassert()") Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Reviewed-by: Vidya Sagar Link: https://patch.msgid.link/20260324190755.1094879-15-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit 4e7a00aeb09172521ce651d5f0e0dd2a0775c22f Author: Vidya Sagar Date: Wed Mar 25 00:37:54 2026 +0530 PCI: tegra194: Disable L1.2 capability of Tegra234 EP [ Upstream commit f59df1d9e6bdb6bd7ef65fb5d200900ac40c20ba ] When Tegra234 is operating in the Endpoint mode with L1.2 enabled, PCIe link goes down during L1.2 exit. This is because Tegra234 powers up UPHY PLL immediately without making sure that the REFCLK is stable. This causes UPHY PLL to fail to lock to the correct frequency and leads to link going down. There is no hardware fix for this, hence do not advertise the L1.2 capability in the Endpoint mode. Fixes: a54e19073718 ("PCI: tegra194: Add Tegra234 PCIe support") Signed-off-by: Vidya Sagar Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Reviewed-by: Vidya Sagar Link: https://patch.msgid.link/20260324190755.1094879-14-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit 2914977cb75e48e760ab6925154a6ad7a34ca9fa Author: Bjorn Helgaas Date: Tue Nov 18 15:42:16 2025 -0600 PCI: tegra194: Remove unnecessary L1SS disable code [ Upstream commit 07c99eac0bc2c1fe962e56d8b5dc5b1152d421bf ] The DWC core clears the L1 Substates Supported bits unless the driver sets the "dw_pcie.l1ss_support" flag. The tegra194 init_host_aspm() sets "dw_pcie.l1ss_support" if the platform has the "supports-clkreq" DT property. If "supports-clkreq" is absent, "dw_pcie.l1ss_support" is not set, and the DWC core will clear the L1 Substates Supported bits. The tegra194 code to clear the L1 Substates Supported bits is unnecessary, so remove it. Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20251118214312.2598220-3-helgaas@kernel.org Stable-dep-of: f59df1d9e6bd ("PCI: tegra194: Disable L1.2 capability of Tegra234 EP") Signed-off-by: Sasha Levin commit 9daf2a8d9cc140b2ade231428622ad34e6f5f93e Author: Manikanta Maddireddy Date: Wed Mar 25 00:37:53 2026 +0530 PCI: dwc: Apply ECRC workaround to DesignWare 5.00a as well [ Upstream commit 40805f32dceadebb7381d911003100bec7b8cd51 ] The ECRC (TLP digest) workaround was originally added for DesignWare version 4.90a. Tegra234 SoC has 5.00a DWC HW version, which has the same ATU TD override behaviour, so apply the workaround for 5.00a too. Fixes: a54e19073718 ("PCI: tegra194: Add Tegra234 PCIe support") Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Reviewed-by: Vidya Sagar Link: https://patch.msgid.link/20260324190755.1094879-13-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit 5cb649c27024521b7bf1e94702b00d1af5844906 Author: Manikanta Maddireddy Date: Wed Mar 25 00:37:52 2026 +0530 PCI: tegra194: Use DWC IP core version [ Upstream commit ea60ca067f0f098043610c96a915d162113c1aac ] Tegra194 PCIe driver used custom version numbers to detect Tegra194 and Tegra234 IPs. With version detect logic added, version check results in mismatch warnings: tegra194-pcie 14100000.pcie: Versions don't match (0000562a != 3536322a) Use HW version numbers which match to PORT_LOGIC.PCIE_VERSION_OFF in Tegra194 driver to avoid these kernel warnings. Fixes: a54e19073718 ("PCI: tegra194: Add Tegra234 PCIe support") Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Reviewed-by: Vidya Sagar Link: https://patch.msgid.link/20260324190755.1094879-12-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit 1e877168b0e7b43a626a961b55876cec26d5fa2d Author: Vidya Sagar Date: Wed Mar 25 00:37:51 2026 +0530 PCI: tegra194: Free up Endpoint resources during remove() [ Upstream commit 8870f02f7868209eb9bdc5dc53540a6262cf9227 ] Free up the resources during remove() that were acquired by the DesignWare driver for the Endpoint mode during probe(). Fixes: bb617cbd8151 ("PCI: tegra194: Clean up the exit path for Endpoint mode") Signed-off-by: Vidya Sagar Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Reviewed-by: Vidya Sagar Link: https://patch.msgid.link/20260324190755.1094879-11-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit e697ea9ecdebc06cef89dbf6f0f667028528ddb1 Author: Vidya Sagar Date: Wed Mar 25 00:37:50 2026 +0530 PCI: tegra194: Allow system suspend when the Endpoint link is not up [ Upstream commit c76f8eae7d4695b1176c4ea5eb93c17e16a20272 ] Host software initiates the L2 sequence. PCIe link is kept in L2 state during suspend. If Endpoint mode is enabled and the link is up, the software cannot proceed with suspend. However, when the PCIe Endpoint driver is probed, but the PCIe link is not up, Tegra can go into suspend state. So, allow system to suspend in this case. Fixes: de2bbf2b71bb ("PCI: tegra194: Don't allow suspend when Tegra PCIe is in EP mode") Signed-off-by: Vidya Sagar Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Reviewed-by: Vidya Sagar Link: https://patch.msgid.link/20260324190755.1094879-10-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit 849068f0129cc64043f2b3350dc5b77eb1459135 Author: Vidya Sagar Date: Wed Mar 25 00:37:49 2026 +0530 PCI: tegra194: Set LTR message request before PCIe link up in Endpoint mode [ Upstream commit b256493bf8cacf0e524bf4c10b5c4901d0c6cefe ] LTR message should be sent as soon as the Root Port enables LTR in the Endpoint mode. So set snoop and no-snoop LTR timing and LTR message request before the PCIe link comes up, so that the LTR message is sent upstream as soon as LTR is enabled. Without programming these values, the Endpoint would send latencies of 0 to the host, which will be inaccurate. Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") Signed-off-by: Vidya Sagar Signed-off-by: Manikanta Maddireddy [mani: commit log] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Jon Hunter Tested-by: Jon Hunter Link: https://patch.msgid.link/20260324190755.1094879-9-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit e463beb1e13092aa04be36ea3d7314c418a207d2 Author: Vidya Sagar Date: Wed Mar 25 00:37:48 2026 +0530 PCI: tegra194: Disable direct speed change for Endpoint mode [ Upstream commit 976f6763f57970388bcd7118931f33f447916927 ] Pre-silicon simulation showed the controller operating in Endpoint mode initiating link speed change after completing Secondary Bus Reset. Ideally, the Root Port or the Switch Downstream Port should initiate the link speed change post SBR, not the Endpoint. So, as per the hardware team recommendation, disable direct speed change for the Endpoint mode to prevent it from initiating speed change after the physical layer link is up at Gen1, leaving speed change ownership with the host. Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") Signed-off-by: Vidya Sagar Signed-off-by: Manikanta Maddireddy [mani: commit log] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Reviewed-by: Vidya Sagar Link: https://patch.msgid.link/20260324190755.1094879-8-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit f4556f70f00a0f0aa9403d34fae5af81b8ac6b4b Author: Vidya Sagar Date: Wed Mar 25 00:37:47 2026 +0530 PCI: tegra194: Use devm_gpiod_get_optional() to parse "nvidia,refclk-select" [ Upstream commit f62bc7917de1374dce86a852ffba8baf9cb7a56a ] The GPIO DT property "nvidia,refclk-select", to select the PCIe reference clock is optional. Use devm_gpiod_get_optional() to get it. Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") Signed-off-by: Vidya Sagar Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Reviewed-by: Vidya Sagar Link: https://patch.msgid.link/20260324190755.1094879-7-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit 89b7185833db4ea4d82f6e70088497da74a5dc95 Author: Manikanta Maddireddy Date: Wed Mar 25 00:37:46 2026 +0530 PCI: tegra194: Disable PERST# IRQ only in Endpoint mode [ Upstream commit 40658a31b6e134169c648041efc84944c4c71dcd ] The PERST# GPIO interrupt is only registered when the controller is operating in Endpoint mode. In Root Port mode, the PERST# GPIO is configured as an output to control downstream devices, and no interrupt is registered for it. Currently, tegra_pcie_dw_stop_link() unconditionally calls disable_irq() on pex_rst_irq, which causes issues in Root Port mode where this IRQ is not registered. Fix this by only disabling the PERST# IRQ when operating in Endpoint mode, where the interrupt is actually registered and used to detect PERST# assertion/deassertion from the host. Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Reviewed-by: Vidya Sagar Link: https://patch.msgid.link/20260324190755.1094879-6-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit 871d9a6bf21b6e5e3d5a85aaa6216ff8abf8ff08 Author: Vidya Sagar Date: Wed Mar 25 00:37:45 2026 +0530 PCI: tegra194: Don't force the device into the D0 state before L2 [ Upstream commit 71d9f67701e1affc82d18ca88ae798c5361beddf ] As per PCIe CEM r6.0, sec 2.3, the PCIe Endpoint device should be in D3cold to assert WAKE# pin. The previous workaround that forced downstream devices to D0 before taking the link to L2 cited PCIe r4.0, sec 5.2, "Link State Power Management"; however, that spec does not explicitly require putting the device into D0 and only indicates that power removal may be initiated without transitioning to D3hot. Remove the D0 workaround so that Endpoint devices can use wake functionality (WAKE# from D3). With some Endpoints the link may not enter L2 when they remain in D3, but the Root Port continues with the usual flow after PME timeout, so there is no functional issue. Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support") Signed-off-by: Vidya Sagar Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Vidya Sagar Reviewed-by: Jon Hunter Link: https://patch.msgid.link/20260324190755.1094879-5-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit fb08535d374c4bd3c539fc6fb8cb038180424a7f Author: Manikanta Maddireddy Date: Wed Mar 25 00:37:44 2026 +0530 PCI: tegra194: Disable LTSSM after transition to Detect on surprise link down [ Upstream commit 9fa0c242f8d7acf1b124d4462d18f4023573ac1c ] After the link reaches a Detect-related LTSSM state, disable LTSSM so it does not keep toggling between Polling and Detect. Do this by polling for the Detect state first, then clearing APPL_CTRL_LTSSM_EN in both tegra_pcie_dw_pme_turnoff() and pex_ep_event_pex_rst_assert(). Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support") Signed-off-by: Vidya Sagar Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Link: https://patch.msgid.link/20260324190755.1094879-4-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit 8626b64c37c9c1000b378056fab8848c3ced0b96 Author: Manikanta Maddireddy Date: Wed Mar 25 00:37:43 2026 +0530 PCI: tegra194: Increase LTSSM poll time on surprise link down [ Upstream commit 74dd8efe4d6cead433162147333af989a568aac7 ] On surprise link down, LTSSM state transits from L0 -> Recovery.RcvrLock -> Recovery.RcvrSpeed -> Gen1 Recovery.RcvrLock -> Detect. Recovery.RcvrLock and Recovery.RcvrSpeed transit times are 24 ms and 48 ms respectively, so the total time from L0 to Detect is ~96 ms. Increase the poll timeout to 120 ms to account for this. While at it, add LTSSM state defines for Detect-related states and use them in the poll condition. Use readl_poll_timeout() instead of readl_poll_timeout_atomic() in tegra_pcie_dw_pme_turnoff() since that path runs in non-atomic context. Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support") Signed-off-by: Vidya Sagar Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Link: https://patch.msgid.link/20260324190755.1094879-3-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit f38e0c5f377a58bdbfd4818b13e2574765558118 Author: Vidya Sagar Date: Wed Mar 25 00:37:42 2026 +0530 PCI: tegra194: Fix polling delay for L2 state [ Upstream commit adaffed907f14f954096555665ad6af2ae724d83 ] As per PCIe r7.0, sec 5.3.3.2.1, after sending PME_Turn_Off message, Root Port should wait for 1-10 msec for PME_TO_Ack message. Currently, driver is polling for 10 msec with 1 usec delay which is aggressive. Use existing macro PCIE_PME_TO_L2_TIMEOUT_US to poll for 10 msec with 1 msec delay. Since this function is used in non-atomic context only, use non-atomic poll function. Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support") Signed-off-by: Vidya Sagar Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Link: https://patch.msgid.link/20260324190755.1094879-2-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit feac3db37d14adc2565bf4e46dfc98cf292d0624 Author: songxiebing Date: Wed Apr 8 16:33:11 2026 +0800 ALSA: usb-audio: qcom: Fix incorrect type in enable_audio_stream [ Upstream commit 292286b2d229fb732421429b027d38ac3f969383 ] Fix sparse warning: sound/usb/qcom/qc_audio_offload.c:943:27: sparse: incorrect type in argument 2 expected unsigned int val but got snd_pcm_format_t. Explicitly cast pcm_format to unsigned int for snd_mask_leave(). Fixes: 326bbc348298 ("ALSA: usb-audio: qcom: Introduce QC USB SND offloading support") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202604062109.Oxi8JjWW-lkp@intel.com/ Signed-off-by: songxiebing Link: https://patch.msgid.link/20260408083311.774173-1-songxiebing@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 19ad2384ce5e6e2d967cdff4b766be21be5d36c0 Author: Richard Cheng Date: Thu Apr 2 17:38:50 2026 +0800 PCI/NPEM: Set LED_HW_PLUGGABLE for hotplug-capable ports [ Upstream commit 16d021c878dca22532c984668c9e8cf4722d6a49 ] NPEM registers LED classdevs on PCI endpoint that may be behind hotplug-capable ports. During hot-removal, led_classdev_unregister() calls led_set_brightness(LED_OFF) which leads to a PCI config read to a disconnected device, which fails and returns -ENODEV (topology details in msgid.link below): leds 0003:01:00.0:enclosure:ok: Setting an LED's brightness failed (-19) The LED core already suppresses this for devices with LED_HW_PLUGGABLE set, but NPEM never sets it. Add the flag since NPEM LEDs are on hot-pluggable hardware by nature. Fixes: 4e893545ef87 ("PCI/NPEM: Add Native PCIe Enclosure Management support") Signed-off-by: Richard Cheng Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Acked-by: Kai-Heng Feng Link: https://patch.msgid.link/20260402093850.23075-1-icheng@nvidia.com Signed-off-by: Sasha Levin commit 989ccfcc920e71d065a736f54b77ec5501126874 Author: Cássio Gabriel Date: Wed Mar 25 17:05:11 2026 -0300 ASoC: SOF: compress: return the configured codec from get_params [ Upstream commit 2c4fdd055f92a2fc8602dcd88bcea08c374b7e8b ] The SOF compressed offload path accepts codec parameters in sof_compr_set_params() and forwards them to firmware as extended data in the SOF IPC stream params message. However, sof_compr_get_params() still returns success without filling the snd_codec structure. Since the compress core allocates that structure zeroed and copies it back to userspace on success, SNDRV_COMPRESS_GET_PARAMS returns an all-zero codec description even after the stream has been configured successfully. The stale TODO in this callback conflates get_params() with capability discovery. Supported codec enumeration belongs in get_caps() and get_codec_caps(). get_params() should report the current codec settings. Cache the codec accepted by sof_compr_set_params() in the per-stream SOF compress state and return it from sof_compr_get_params(). Fixes: 6324cf901e14 ("ASoC: SOF: compr: Add compress ops implementation") Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260325-sof-compr-get-params-v1-1-0758815f13c7@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 12d76d99e8453dd261c2343111b4fc852c01245c Author: Panagiotis Petrakopoulos Date: Mon Apr 6 01:25:48 2026 +0300 ALSA: scarlett2: Add missing sentinel initializer field [ Upstream commit 2428cd6e8b6fa80c36db4652702ca0acd2ce3f08 ] A "-Wmissing-field-initializers" warning was emitted when compiling the module using the W=2 option. There is a sentinel initializer field missing in the end of scarlett2_devices[]. Tested using a Scarlett Solo 4th gen. Fixes: d98cc489029d ("ALSA: scarlett2: Move USB IDs out from device_info struct") Signed-off-by: Panagiotis Petrakopoulos Link: https://patch.msgid.link/20260405222548.8903-1-npetrakopoulos2003@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 2fdb6c1e743d2d442b19a1bc702a38d5a0c3c7f2 Author: Waiman Long Date: Wed Mar 11 16:05:26 2026 -0400 selftest: memcg: skip memcg_sock test if address family not supported [ Upstream commit 2d028f3e4bbbfd448928a8d3d2814b0b04c214f4 ] The test_memcg_sock test in memcontrol.c sets up an IPv6 socket and send data over it to consume memory and verify that memory.stat.sock and memory.current values are close. On systems where IPv6 isn't enabled or not configured to support SOCK_STREAM, the test_memcg_sock test always fails. When the socket() call fails, there is no way we can test the memory consumption and verify the above claim. I believe it is better to just skip the test in this case instead of reporting a test failure hinting that there may be something wrong with the memcg code. Link: https://lkml.kernel.org/r/20260311200526.885899-1-longman@redhat.com Fixes: 5f8f019380b8 ("selftests: cgroup/memcontrol: add basic test for socket accounting") Signed-off-by: Waiman Long Acked-by: Michal Koutný Acked-by: Shakeel Butt Cc: Johannes Weiner Cc: Michal Hocko Cc: Michal Koutný Cc: Mike Rapoport Cc: Muchun Song Cc: Roman Gushchin Cc: Shuah Khan Cc: Tejun Heo Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 0619073fd08213a63cb92db13b8accc0c633c69d Author: Jane Chu Date: Mon Mar 2 13:10:15 2026 -0700 Documentation: fix a hugetlbfs reservation statement [ Upstream commit 7a197d346a44384a1a858a98ef03766840e561d4 ] Documentation/mm/hugetlbfs_reserv.rst has if (resv_needed <= (resv_huge_pages - free_huge_pages)) resv_huge_pages += resv_needed; which describes this code in gather_surplus_pages() needed = (h->resv_huge_pages + delta) - h->free_huge_pages; if (needed <= 0) { h->resv_huge_pages += delta; return 0; } which means if there are enough free hugepages to account for the new reservation, simply update the global reservation count without further action. But the description is backwards, it should be if (resv_needed <= (free_huge_pages - resv_huge_pages)) instead. Link: https://lkml.kernel.org/r/20260302201015.1824798-1-jane.chu@oracle.com Fixes: 70bc0dc578b3 ("Documentation: vm, add hugetlbfs reservation overview") Signed-off-by: Jane Chu Cc: David Hildenbrand Cc: Hillf Danton Cc: Jonathan Corbet Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Oscar Salvador Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit fc1ca4f0d6be0939bac2db6f7a1fa681c8775eeb Author: Pasha Tatashin Date: Sat Nov 1 10:23:17 2025 -0400 kho: make debugfs interface optional [ Upstream commit 03d3963464a43654703938a66503cd686c5fc54e ] Patch series "liveupdate: Rework KHO for in-kernel users", v9. This series refactors the KHO framework to better support in-kernel users like the upcoming LUO. The current design, which relies on a notifier chain and debugfs for control, is too restrictive for direct programmatic use. The core of this rework is the removal of the notifier chain in favor of a direct registration API. This decouples clients from the shutdown-time finalization sequence, allowing them to manage their preserved state more flexibly and at any time. In support of this new model, this series also: - Makes the debugfs interface optional. - Introduces APIs to unpreserve memory and fixes a bug in the abort path where client state was being incorrectly discarded. Note that this is an interim step, as a more comprehensive fix is planned as part of the stateless KHO work [1]. - Moves all KHO code into a new kernel/liveupdate/ directory to consolidate live update components. This patch (of 9): Currently, KHO is controlled via debugfs interface, but once LUO is introduced, it can control KHO, and the debug interface becomes optional. Add a separate config CONFIG_KEXEC_HANDOVER_DEBUGFS that enables the debugfs interface, and allows to inspect the tree. Move all debugfs related code to a new file to keep the .c files clear of ifdefs. Link: https://lkml.kernel.org/r/20251101142325.1326536-1-pasha.tatashin@soleen.com Link: https://lkml.kernel.org/r/20251101142325.1326536-2-pasha.tatashin@soleen.com Link: https://lore.kernel.org/all/20251020100306.2709352-1-jasonmiu@google.com [1] Co-developed-by: Mike Rapoport (Microsoft) Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Pasha Tatashin Reviewed-by: Pratyush Yadav Cc: Alexander Graf Cc: Christian Brauner Cc: Jason Gunthorpe Cc: Jonathan Corbet Cc: Masahiro Yamada Cc: Miguel Ojeda Cc: Randy Dunlap Cc: Tejun Heo Cc: Changyuan Lyu Cc: Jason Gunthorpe Cc: Simon Horman Cc: Zhu Yanjun Signed-off-by: Andrew Morton Stable-dep-of: 019fc3687237 ("kho: fix KASAN support for restored vmalloc regions") Signed-off-by: Sasha Levin commit 43106160a00b42f10d989e36010db57fd5493eae Author: AnishMulay Date: Wed Feb 18 11:39:41 2026 -0500 selftests/mm: skip migration tests if NUMA is unavailable [ Upstream commit 54218f10dfbe88c8e41c744fd45a756cde60b8c4 ] Currently, the migration test asserts that numa_available() returns 0. On systems where NUMA is not available (returning -1), such as certain ARM64 configurations or single-node systems, this assertion fails and crashes the test. Update the test to check the return value of numa_available(). If it is less than 0, skip the test gracefully instead of failing. This aligns the behavior with other MM selftests (like rmap) that skip when NUMA support is missing. Link: https://lkml.kernel.org/r/20260218163941.13499-1-anishm7030@gmail.com Fixes: 0c2d08728470 ("mm: add selftests for migration entries") Signed-off-by: AnishMulay Reviewed-by: SeongJae Park Reviewed-by: Dev Jain Reviewed-by: Anshuman Khandual Tested-by: Sayali Patil Acked-by: David Hildenbrand (Arm) Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit fa123b901eb6ff7d8992ee49af1526a22ffdc955 Author: Eliot Courtney Date: Wed Apr 1 10:42:28 2026 +0900 gpu: nova-core: bitfield: fix broken Default implementation [ Upstream commit de0aca13509bf47a2d49bc7a26d56079c758c95f ] The current implementation does not actually set the default values for the fields in the bitfield. Fixes: 3fa145bef533 ("gpu: nova-core: register: generate correct `Default` implementation") Signed-off-by: Eliot Courtney Link: https://patch.msgid.link/20260401-fix-bitfield-v2-1-2fa68c98114a@nvidia.com Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit af46044d16714911d0e2c45f4d5697f89221a6f8 Author: Joel Fernandes Date: Thu Oct 16 11:13:21 2025 -0400 gpu: nova-core: bitfield: Move bitfield-specific code from register! into new macro [ Upstream commit 71ea85be25b4f54a53ec03d5deaed52f5ee65da8 ] Move the bitfield-specific code from the register macro into a new macro called bitfield. This will be used to define structs with bitfields, similar to C language. Reviewed-by: Elle Rhumsaa Reviewed-by: Alexandre Courbot Reviewed-by: Edwin Peer Signed-off-by: Joel Fernandes Signed-off-by: Alexandre Courbot Message-ID: <20251016151323.1201196-3-joelagnelf@nvidia.com> Stable-dep-of: de0aca13509b ("gpu: nova-core: bitfield: fix broken Default implementation") Signed-off-by: Sasha Levin commit e6b0e1f74d355a207dee4cc76ad91178bd4457f0 Author: Alexandre Courbot Date: Thu Oct 16 11:13:20 2025 -0400 gpu: nova-core: register: use field type for Into implementation [ Upstream commit 3f674dc4ef1b3783f9d8dae33b46bf50eaac7c79 ] The getter method of a field works with the field type, but its setter expects the type of the register. This leads to an asymmetry in the From/Into implementations required for a field with a dedicated type. For instance, a field declared as pub struct ControlReg(u32) { 3:0 mode as u8 ?=> Mode; ... } currently requires the following implementations: impl TryFrom for Mode { ... } impl From for u32 { ... } Change this so the `From` now needs to be implemented for `u8`, i.e. the primitive type of the field. This is more consistent, and will become a requirement once we start using the TryFrom/Into derive macros to implement these automatically. Reported-by: Edwin Peer Closes: https://lore.kernel.org/rust-for-linux/F3853912-2C1C-4F9B-89B0-3168689F35B3@nvidia.com/ Reviewed-by: Joel Fernandes Signed-off-by: Joel Fernandes Signed-off-by: Alexandre Courbot Message-ID: <20251016151323.1201196-2-joelagnelf@nvidia.com> Stable-dep-of: de0aca13509b ("gpu: nova-core: bitfield: fix broken Default implementation") Signed-off-by: Sasha Levin commit 0a2d60edc3e57c9512e239ebdfd12204d3368560 Author: Chen-Yu Tsai Date: Tue Mar 24 17:35:41 2026 +0800 PCI: mediatek-gen3: Prevent leaking IRQ domains when IRQ not found [ Upstream commit 5573c44cb3fd01a9f62d569ae9ac870ef5f0e0ba ] In mtk_pcie_setup_irq(), the IRQ domains are allocated before the controller's IRQ is fetched. If the latter fails, the function directly returns an error, without cleaning up the allocated domains. Hence, reverse the order so that the IRQ domains are allocated after the controller's IRQ is found. This was flagged by Sashiko during a review of "[PATCH v6 0/7] PCI: mediatek-gen3: add power control support". Fixes: 814cceebba9b ("PCI: mediatek-gen3: Add INTx support") Signed-off-by: Chen-Yu Tsai Signed-off-by: Manivannan Sadhasivam Link: https://sashiko.dev/#/patchset/20260324052002.4072430-1-wenst%40chromium.org Link: https://patch.msgid.link/20260324093542.18523-1-wenst@chromium.org Signed-off-by: Sasha Levin commit db805e9399c8cdfa19f57aababb4f22d01dc64c1 Author: Gerd Bayer Date: Mon Mar 30 15:09:45 2026 +0200 PCI: Enable AtomicOps only if Root Port supports them [ Upstream commit 1ae8c4ce157037e266184064a182af9ef9af278b ] When inspecting the config space of a Connect-X physical function in an s390 system after it was initialized by the mlx5_core device driver, we found the function to be enabled to request AtomicOps despite the Root Port lacking support for completing them: 00:00.1 Ethernet controller: Mellanox Technologies MT2894 Family [ConnectX-6 Lx] Subsystem: Mellanox Technologies Device 0002 DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- AtomicOpsCtl: ReqEn+ On s390 and many virtualized guests, the Endpoint is visible but the Root Port is not. In this case, pci_enable_atomic_ops_to_root() previously enabled AtomicOps in the Endpoint even though it can't tell whether the Root Port supports them as a completer. Change pci_enable_atomic_ops_to_root() to fail if there's no Root Port or the Root Port doesn't support AtomicOps. Fixes: 430a23689dea ("PCI: Add pci_enable_atomic_ops_to_root()") Reported-by: Alexander Schmidt Signed-off-by: Gerd Bayer [bhelgaas: commit log, check RP first to simplify flow] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260330-fix_pciatops-v7-2-f601818417e8@linux.ibm.com Signed-off-by: Sasha Levin commit 134c61925e9e9ee0f4fdbab5c3984d5bb024f5f5 Author: Denis Rastyogin Date: Fri Mar 27 13:33:11 2026 +0300 ASoC: rsnd: Fix potential out-of-bounds access of component_dais[] [ Upstream commit f9e437cddf6cf9e603bdaefe148c1f4792aaf39c ] component_dais[RSND_MAX_COMPONENT] is initially zero-initialized and later populated in rsnd_dai_of_node(). However, the existing boundary check: if (i >= RSND_MAX_COMPONENT) does not guarantee that the last valid element remains zero. As a result, the loop can rely on component_dais[RSND_MAX_COMPONENT] being zero, which may lead to an out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 547b02f74e4a ("ASoC: rsnd: enable multi Component support for Audio Graph Card/Card2") Signed-off-by: Denis Rastyogin Acked-by: Kuninori Morimoto Link: https://patch.msgid.link/20260327103311.459239-1-gerben@altlinux.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 254091c91767ee282fb75bde980134ab6e3626cc Author: Giovanni Cabiddu Date: Sat Mar 28 22:29:46 2026 +0000 crypto: qat - use swab32 macro [ Upstream commit 35ecb77ae0749a2f1b04872c9978d9d7ddbbeb79 ] Replace __builtin_bswap32() with swab32 in icp_qat_hw_20_comp.h to fix the following build errors on architectures without native byte-swap support: alpha-linux-ld: drivers/crypto/intel/qat/qat_common/adf_gen4_hw_data.o: in function `adf_gen4_build_decomp_block': drivers/crypto/intel/qat/qat_common/icp_qat_hw_20_comp.h:141:(.text+0xeec): undefined reference to `__bswapsi2' alpha-linux-ld: drivers/crypto/intel/qat/qat_common/icp_qat_hw_20_comp.h:141:(.text+0xef8): undefined reference to `__bswapsi2' alpha-linux-ld: drivers/crypto/intel/qat/qat_common/adf_gen4_hw_data.o: in function `adf_gen4_build_comp_block': drivers/crypto/intel/qat/qat_common/icp_qat_hw_20_comp.h:57:(.text+0xf64): undefined reference to `__bswapsi2' alpha-linux-ld: drivers/crypto/intel/qat/qat_common/icp_qat_hw_20_comp.h:57:(.text+0xf7c): undefined reference to `__bswapsi2' Fixes: 5b14b2b307e4 ("crypto: qat - enable deflate for QAT GEN4") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202603290259.Ig9kDOmI-lkp@intel.com/ Signed-off-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 8d77cf260535e0b2b7692212a8df2c03629a56ca Author: Giovanni Cabiddu Date: Tue Mar 24 18:29:05 2026 +0000 crypto: iaa - fix per-node CPU counter reset in rebalance_wq_table() [ Upstream commit 590fa5d69c27cfaecd2e8287aec78f902417c877 ] The cpu counter used to compute the IAA device index is reset to zero at the start of each NUMA node iteration. This causes CPUs on every node to map starting from IAA index 0 instead of continuing from the previous node's last index. On multi-node systems, this results in all nodes mapping their CPUs to the same initial set of IAA devices, leaving higher-indexed devices unused. Move the cpu counter initialization before the for_each_node_with_cpus() loop so that the IAA index computation accumulates correctly across all nodes. Fixes: 714ca27e9bf4 ("crypto: iaa - Optimize rebalance_wq_table()") Signed-off-by: Giovanni Cabiddu Acked-by: Vinicius Costa Gomes Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 52906bb0f636c4279a263ea19a76deb824d47e39 Author: Giovanni Cabiddu Date: Tue Mar 24 18:17:23 2026 +0000 crypto: qat - fix type mismatch in RAS sysfs show functions [ Upstream commit ec23d75c4b77ae42af0777ea59599b1d4f611371 ] ADF_RAS_ERR_CTR_READ() expands to atomic_read(), which returns int. The local variable 'counter' was declared as 'unsigned long', causing a type mismatch on the assignment. The format specifier '%ld' was consequently wrong in two ways: wrong length modifier and wrong signedness. Use int to match the return type of atomic_read() and update the format specifier to '%d' accordingly. Fixes: 532d7f6bc458 ("crypto: qat - add error counters") Signed-off-by: Giovanni Cabiddu Reviewed-by: Ahsan Atta Reviewed-by: Andy Shevchenko Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 684bd5404f9c3605b8e10be7c7affe88fd198121 Author: Giovanni Cabiddu Date: Tue Mar 24 17:59:40 2026 +0000 crypto: qat - fix compression instance leak [ Upstream commit 795c24c677c7a1c12f5768daf22a874a2890662f ] qat_comp_alg_init_tfm() acquires a compression instance via qat_compression_get_instance_node() before calling qat_comp_build_ctx() to initialize the compression context. If qat_comp_build_ctx() fails, the function returns an error without releasing the compression instance, causing a resource leak. When qat_comp_build_ctx() fails, release the compression instance with qat_compression_put_instance() and clear the context to avoid leaving a stale reference to the released instance. The issue was introduced when build_deflate_ctx() (which always returned void) was replaced by qat_comp_build_ctx() (which can return an error) without adding error handling for the failure path. Fixes: cd0e7160f80f ("crypto: qat - refactor compression template logic") Signed-off-by: Giovanni Cabiddu Reviewed-by: Laurent M Coquerel Reviewed-by: Ahsan Atta Reviewed-by: Wojciech Drewek Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 06b30beb9104390137e31ec9694b5aad01dd406f Author: Ahsan Atta Date: Tue Mar 24 11:12:34 2026 +0000 crypto: qat - disable 420xx AE cluster when lead engine is fused off [ Upstream commit f216e0f2d1787e662bb6662c9c522185aa3b855a ] The get_ae_mask() function only disables individual engines based on the fuse register, but engines are organized in clusters of 4. If the lead engine of a cluster is fused off, the entire cluster must be disabled. Replace the single bitmask inversion with explicit test_bit() checks on the lead engine of each group, disabling the full ADF_AE_GROUP when the lead bit is set. Signed-off-by: Ahsan Atta Reviewed-by: Giovanni Cabiddu Fixes: fcf60f4bcf54 ("crypto: qat - add support for 420xx devices") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 6aef8e6fdf4d3dae5ea87b3af78a0c88d78f0c2f Author: Ahsan Atta Date: Tue Mar 24 11:11:12 2026 +0000 crypto: qat - disable 4xxx AE cluster when lead engine is fused off [ Upstream commit b260d53561dd69b29505222ec44cf386ac2c2ca6 ] The get_ae_mask() function only disables individual engines based on the fuse register, but engines are organized in clusters of 4. If the lead engine of a cluster is fused off, the entire cluster must be disabled. Replace the single bitmask inversion with explicit test_bit() checks on the lead engine of each group, disabling the full ADF_AE_GROUP when the lead bit is set. Signed-off-by: Ahsan Atta Reviewed-by: Giovanni Cabiddu Fixes: 8c8268166e834 ("crypto: qat - add qat_4xxx driver") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 44faf7ea013c28f9231a64744c155b0126f89a2c Author: Hans Zhang <18255117159@163.com> Date: Wed Apr 1 10:30:48 2026 +0800 PCI: dwc: Fix type mismatch for kstrtou32_from_user() return value [ Upstream commit 445588a3b18bb0702d746cb61f7a443639027651 ] kstrtou32_from_user() returns int, but the return value was stored in a u32 variable 'val', risking sign loss. Use a dedicated int variable to correctly handle the return code. Fixes: 4fbfa17f9a07 ("PCI: dwc: Add debugfs based Silicon Debug support for DWC") Signed-off-by: Hans Zhang <18255117159@163.com> Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260401023048.4182452-1-18255117159@163.com Signed-off-by: Sasha Levin commit a1a24d4b8c9682f9b7a9138f636ff004c721aef1 Author: Srinivas Kandagatla Date: Thu Apr 2 08:11:08 2026 +0000 ASoC: qcom: qdsp6: topology: check widget type before accessing data [ Upstream commit d5bfdd28e0cdd45043ae6e0ac168a451d59283dc ] Check widget type before accessing the private data, as this could a virtual widget which is no associated with a dsp graph, container and module. Accessing witout check could lead to incorrect memory access. Fixes: 36ad9bf1d93d ("ASoC: qdsp6: audioreach: add topology support") Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260402081118.348071-4-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9f0632b0d4246675fa221aa1a3bffadf9c6bd9ac Author: Jason Gunthorpe Date: Fri Mar 27 12:22:10 2026 -0300 iommu/riscv: Remove overflows on the invalidation path [ Upstream commit 40a13b49957937427bc23e78eb50679df4396a47 ] Since RISC-V supports a sign extended page table it should support a gather->end of ULONG_MAX, but if this happens it will infinite loop because of the overflow. Also avoid overflow computing the length by moving the +1 to the other side of the < Fixes: 488ffbf18171 ("iommu/riscv: Paging domain support") Signed-off-by: Jason Gunthorpe Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 20b3c566e2702e5d4d0545be8a97029a2eebcc0e Author: Vasant Hegde Date: Wed Apr 1 08:00:17 2026 +0000 iommu/amd: Fix clone_alias() to use the original device's devid [ Upstream commit faad224fe0f0857a04ff2eb3c90f0de57f47d0f3 ] Currently clone_alias() assumes first argument (pdev) is always the original device pointer. This function is called by pci_for_each_dma_alias() which based on topology decides to send original or alias device details in first argument. This meant that the source devid used to look up and copy the DTE may be incorrect, leading to wrong or stale DTE entries being propagated to alias device. Fix this by passing the original pdev as the opaque data argument to both the direct clone_alias() call and pci_for_each_dma_alias(). Inside clone_alias(), retrieve the original device from data and compute devid from it. Fixes: 3332364e4ebc ("iommu/amd: Support multiple PCI DMA aliases in device table") Signed-off-by: Vasant Hegde Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 715d7b1e1af8096fa4eae5eb046b684b7ae4350e Author: Shengjiu Wang Date: Wed Apr 1 17:42:26 2026 +0800 ASoC: fsl_easrc: Change the type for iec958 channel status controls [ Upstream commit 47f28a5bd154a95d5aa563dde02a801bd32ddb81 ] Use the type SNDRV_CTL_ELEM_TYPE_IEC958 for iec958 channel status controls, the original type will cause mixer-test to iterate all 32bit values, which costs a lot of time. And using IEC958 type can reduce the control numbers. Also enable pm runtime before updating registers to make the regmap cache data align with the value in hardware. Fixes: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260401094226.2900532-12-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9f8304abcd7e7c56e98bba47f618e92d436ac2e6 Author: Shengjiu Wang Date: Wed Apr 1 17:42:25 2026 +0800 ASoC: fsl_easrc: Fix value type in fsl_easrc_iec958_get_bits() [ Upstream commit aa21fe4a81458cf469c2615b08cbde5997dde25a ] The value type of controls "Context 0 IEC958 Bits Per Sample" should be integer, not enumerated, the issue is found by the mixer-test. Fixes: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260401094226.2900532-11-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cbf3693ddf5aa87e53963518108e404715f13baa Author: Shengjiu Wang Date: Wed Apr 1 17:42:24 2026 +0800 ASoC: fsl_easrc: Check the variable range in fsl_easrc_iec958_put_bits() [ Upstream commit 00541b86fb578d4949cfdd6aff1f82d43fcf07af ] Add check of input value's range in fsl_easrc_iec958_put_bits(), otherwise the wrong value may be written from user space. Fixes: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260401094226.2900532-10-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 15ff6da3e9bd21acf9538d8a5dbd81f97c9c7329 Author: Shengjiu Wang Date: Wed Apr 1 17:42:23 2026 +0800 ASoC: fsl_xcvr: Fix event generation in fsl_xcvr_mode_put() [ Upstream commit 64a496ba976324615b845d60739dfcdae3d57434 ] ALSA controls should return 1 if the value in the control changed but the control put operation fsl_xcvr_mode_put() only returns 0 or a negative error code, causing ALSA to not generate any change events. Add a suitable check in the function before updating the mode variable. Fixes: 28564486866f ("ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260401094226.2900532-9-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4ab351b4b785afccef524ea6a518f2c59459417a Author: Shengjiu Wang Date: Wed Apr 1 17:42:22 2026 +0800 ASoC: fsl_xcvr: Fix event generation in fsl_xcvr_arc_mode_put() [ Upstream commit 1b61c8103c9317a9c37fe544c2d83cee1c281149 ] ALSA controls should return 1 if the value in the control changed but the control put operation fsl_xcvr_arc_mode_put() only returns 0 or a negative error code, causing ALSA to not generate any change events. Add a suitable check in the function before updating the arc_mode variable. Fixes: 28564486866f ("ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260401094226.2900532-8-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4095fa1c8ed98463a33184effcb44df149ef0e66 Author: Shengjiu Wang Date: Wed Apr 1 17:42:21 2026 +0800 ASoC: fsl_micfil: Fix event generation in micfil_quality_set() [ Upstream commit e5785093b1b45af7ee57d18619b2854a8aed073a ] ALSA controls should return 1 if the value in the control changed but the control put operation micfil_quality_set() only returns 0 or a negative error code, causing ALSA to not generate any change events. Add a suitable check in the function before updating the quality variable. Also enable pm runtime before calling the function micfil_set_quality() to make the regmap cache data align with the value in hardware. Fixes: bea1d61d5892 ("ASoC: fsl_micfil: rework quality setting") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260401094226.2900532-7-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fe6e720bf2a065694e50775ca4e9c831433528ea Author: Shengjiu Wang Date: Wed Apr 1 17:42:20 2026 +0800 ASoC: fsl_micfil: Fix event generation in micfil_put_dc_remover_state() [ Upstream commit 7d2bd35100de370dc326b250e8f6b66bee06a2f3 ] ALSA controls should return 1 if the value in the control changed but the control put operation micfil_put_dc_remover_state() only returns 0 or a negative error code, causing ALSA to not generate any change events. return the value of snd_soc_component_update_bits() directly, as it has the capability of return check status of changed or not. Also enable pm runtime before calling the function snd_soc_component_update_bits() to make the regmap cache data align with the value in hardware. Fixes: 29dbfeecab85 ("ASoC: fsl_micfil: Add Hardware Voice Activity Detector support") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260401094226.2900532-6-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 79acc3ea6fb690b219c55f6dcf700a8dce4e7583 Author: Shengjiu Wang Date: Wed Apr 1 17:42:18 2026 +0800 ASoC: fsl_micfil: Fix event generation in hwvad_put_init_mode() [ Upstream commit 7e226209906906421f0d952d7304e48fdb0adabc ] ALSA controls should return 1 if the value in the control changed but the control put operation hwvad_put_init_mode() only returns 0 or a negative error code, causing ALSA to not generate any change events. Add a suitable check in the function before updating the vad_init_mode variable. Fixes: 29dbfeecab85 ("ASoC: fsl_micfil: Add Hardware Voice Activity Detector support") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260401094226.2900532-4-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 891c51e19d3a0ca4241cec598ac7efda6dacfafd Author: Shengjiu Wang Date: Wed Apr 1 17:42:17 2026 +0800 ASoC: fsl_micfil: Fix event generation in hwvad_put_enable() [ Upstream commit 59b9061824f2179fe133e2636203548eaba3e528 ] ALSA controls should return 1 if the value in the control changed but the control put operation hwvad_put_enable() only returns 0 or a negative error code, causing ALSA to not generate any change events. Add a suitable check in the function before updating the vad_enabled variable. Fixes: 29dbfeecab85 ("ASoC: fsl_micfil: Add Hardware Voice Activity Detector support") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260401094226.2900532-3-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2a6a72a0beab24594e9b1483b8ca116ab1ecf197 Author: Shengjiu Wang Date: Wed Apr 1 17:42:16 2026 +0800 ASoC: fsl_micfil: Add access property for "VAD Detected" [ Upstream commit c7661bfc7422443df394c01e069ae4e5c3a7f04c ] Add access property SNDRV_CTL_ELEM_ACCESS_READ for control "VAD Detected", which doesn't support put operation, otherwise there will be issue with mixer-test. Fixes: 29dbfeecab85 ("ASoC: fsl_micfil: Add Hardware Voice Activity Detector support") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260401094226.2900532-2-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1140626eb6f57cd79ba08834da27754f2c50934b Author: Dmitry Baryshkov Date: Wed Mar 25 07:35:44 2026 +0200 drm/msm/dpu: drop INTF_0 on MSM8953 [ Upstream commit 7090420420d5a7d7c88b21d16962f2a230be3ef3 ] There is no INTF_0 on MSM8953. Currently catalog lists dummy INTF_NONE entry for it. Drop it from the catalog. Fixes: 7a6109ce1c2c ("drm/msm/dpu: Add support for MSM8953") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/713990/ Link: https://lore.kernel.org/r/20260325-drop-8953-intf-v1-1-d80e214a1a75@oss.qualcomm.com Signed-off-by: Sasha Levin commit 507cc9ab1e8ca1268db95002a3faf0d40900345a Author: Dmitry Baryshkov Date: Sun Feb 1 12:48:59 2026 +0200 PM: domains: De-constify fields in struct dev_pm_domain_attach_data [ Upstream commit 1877d3f258cbb57d64e275754fb9b18b089ce72d ] It doesn't really make sense to keep u32 fields to be marked as const. Having the const fields prevents their modification in the driver. Instead the whole struct can be defined as const, if it is constant. Fixes: 161e16a5e50a ("PM: domains: Add helper functions to attach/detach multiple PM domains") Signed-off-by: Dmitry Baryshkov Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 2ba2e8ce483cfb524a650cf8aa684d271c315fb9 Author: Felix Gu Date: Wed Jan 21 22:17:17 2026 +0800 pmdomain: imx: scu-pd: Fix device_node reference leak during ->probe() [ Upstream commit c8e9b6a55702be6c6d034e973d519c52c3848415 ] When calling of_parse_phandle_with_args(), the caller is responsible to call of_node_put() to release the reference of device node. In imx_sc_pd_get_console_rsrc(), it does not release the reference. Fixes: 893cfb99734f ("firmware: imx: scu-pd: do not power off console domain") Signed-off-by: Felix Gu Reviewed-by: Peng Fan Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 2d9cb1f588ceeda5960cca983267ab743e69abe3 Author: Felix Gu Date: Fri Jan 16 20:27:47 2026 +0800 pmdomain: ti: omap_prm: Fix a reference leak on device node [ Upstream commit 44c28e1c52764fef6dd1c1ada3a248728812e67f ] When calling of_parse_phandle_with_args(), the caller is responsible to call of_node_put() to release the reference of device node. In omap_prm_domain_attach_dev, it does not release the reference. Fixes: 58cbff023bfa ("soc: ti: omap-prm: Add basic power domain support") Signed-off-by: Felix Gu Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 9232d70f98cdf1a5d96dd2f1fbed465da6b9a0b9 Author: wangdicheng Date: Wed Apr 1 16:26:25 2026 +0800 ALSA: hda/cmedia: Remove duplicate pin configuration parsing [ Upstream commit 579e7b820de5dd5124585413bb5e9c278d255436 ] The cmedia_probe() function calls snd_hda_parse_pin_defcfg() and snd_hda_gen_parse_auto_config() twice unnecessarily. Remove The duplicate code. Fixes: 0f1e8306dcbe ("ALSA: hda/cmedia: Rewrite to new probe method") Signed-off-by: wangdicheng Link: https://patch.msgid.link/20260401082625.157868-1-wangdich9700@163.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 70f694e0bb878bf526ed9ab85660f398cf39a278 Author: Akhil P Oommen Date: Fri Mar 27 05:43:50 2026 +0530 drm/msm/a6xx: Use barriers while updating HFI Q headers [ Upstream commit dc78b35d5ec09d1b0b8a937e6e640d2c5a030915 ] To avoid harmful compiler optimizations and IO reordering in the HW, use barriers and READ/WRITE_ONCE helpers as necessary while accessing the HFI queue index variables. Fixes: 4b565ca5a2cb ("drm/msm: Add A6XX device support") Signed-off-by: Akhil P Oommen Patchwork: https://patchwork.freedesktop.org/patch/714653/ Message-ID: <20260327-a8xx-gpu-batch2-v2-1-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 4180d90a40545b0d5992acab6a2ef564af32c27c Author: Connor Abbott Date: Wed Mar 25 16:58:37 2026 -0400 drm/msm/a6xx: Fix dumping A650+ debugbus blocks [ Upstream commit cc83f71c9be0715fe93b963ffa9767d5d84354ed ] These should be appended after the existing debugbus blocks, instead of replacing them. Fixes: 1e05bba5e2b8 ("drm/msm/a6xx: Update a6xx gpu coredump") Signed-off-by: Connor Abbott Patchwork: https://patchwork.freedesktop.org/patch/714270/ Message-ID: <20260325-drm-msm-a650-debugbus-v1-1-dfbf358890a7@gmail.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 279fde87aa70bdce2409a7586b66dfc87e693183 Author: Rob Clark Date: Wed Mar 25 11:41:05 2026 -0700 drm/msm/shrinker: Fix can_block() logic [ Upstream commit df0f439e3926817cf577ca6272aad68468ff7624 ] The intention here was to allow blocking if DIRECT_RECLAIM or if called from kswapd and KSWAPD_RECLAIM is set. Reported by Claude code review: https://lore.gitlab.freedesktop.org/drm-ai-reviews/review-patch9-20260309151119.290217-10-boris.brezillon@collabora.com/ on a panthor patch which had copied similar logic. Reported-by: Boris Brezillon Fixes: 7860d720a84c ("drm/msm: Fix build break with recent mm tree") Signed-off-by: Rob Clark Reviewed-by: Boris Brezillon Patchwork: https://patchwork.freedesktop.org/patch/714238/ Message-ID: <20260325184106.1259528-1-robin.clark@oss.qualcomm.com> Signed-off-by: Sasha Levin commit 6a83ea4da004f0a6ed448261c31277486773bd62 Author: Rob Clark Date: Wed Mar 25 11:40:42 2026 -0700 drm/msm/a6xx: Fix HLSQ register dumping [ Upstream commit c289a6db9ba6cb974f0317da142e4f665d589566 ] Fix the bitfield offset of HLSQ_READ_SEL state-type bitfield. Otherwise we are always reading TP state when we wanted SP or HLSQ state. Reported-by: Connor Abbott Suggested-by: Connor Abbott Fixes: 1707add81551 ("drm/msm/a6xx: Add a6xx gpu state") Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/714236/ Message-ID: <20260325184043.1259312-1-robin.clark@oss.qualcomm.com> Signed-off-by: Sasha Levin commit 206f812ef140727b75697111391ae320fd8aa652 Author: Rob Clark Date: Tue Mar 24 15:05:18 2026 -0700 drm/msm: Fix VM_BIND UNMAP locking [ Upstream commit 85042c2cd970a6b0e686329387096fe19989ae62 ] Wrong argument meant that the objs involved in UNMAP ops were not always getting locked. Since _NO_SHARE objs share a common resv with the VM (which is always locked) this would only show up with non-_NO_SHARE BOs. Reported-by: Victoria Brekenfeld Fixes: 2e6a8a1fe2b2 ("drm/msm: Add VM_BIND ioctl") Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/94 Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/713898/ Message-ID: <20260324220519.1221471-2-robin.clark@oss.qualcomm.com> Signed-off-by: Sasha Levin commit 8cf18974284fbfd43fe32fdacec59fabbcca9003 Author: Rob Clark Date: Wed Mar 25 11:59:26 2026 -0700 drm/msm: Reject fb creation from _NO_SHARE objs [ Upstream commit cf50ccdb765b3a6f1cd8e75642b0439fea0263a5 ] It would be an error to map these into kms->vm. So reject this as early as possible, when creating an fb. Fixes: b58e12a66e47 ("drm/msm: Add _NO_SHARE flag") Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/714264/ Message-ID: <20260325185926.1265661-1-robin.clark@oss.qualcomm.com> Signed-off-by: Sasha Levin commit 30b8a3f88c5935f37fa4f1a0d8cdf86e584217c8 Author: Rob Clark Date: Mon Mar 16 11:44:42 2026 -0700 drm/msm/vma: Avoid lock in VM_BIND fence signaling path [ Upstream commit 8a7023b035355ef5bfa096bd323256fa8abbbc6a ] Use msm_gem_unpin_active(), similar to what is used in the GEM_SUBMIT path. This avoids needing to hold the obj lock, and the end result is the same. (As with GEM_SUBMIT, we know the fence isn't signaled yet.) Reported-by: Akhil P Oommen Fixes: 2e6a8a1fe2b2 ("drm/msm: Add VM_BIND ioctl") Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/712230/ Message-ID: <20260316184442.673558-1-robin.clark@oss.qualcomm.com> Signed-off-by: Sasha Levin commit d0b28251ca4488a7c87a38b59983bc604a392339 Author: Ethan Tidmore Date: Tue Mar 24 12:38:30 2026 -0500 ASoC: SOF: Intel: hda: Place check before dereference [ Upstream commit 6cbc8360f51a3df2ea16a786b262b9fe44d4c68c ] The struct hext_stream is dereferenced before it is checked for NULL. Although it can never be NULL due to a check prior to hda_dsp_iccmax_stream_hw_params() being called, this change clears any confusion regarding hext_stream possibly being NULL. Check hext_stream for NULL and then assign its members. Detected by Smatch: sound/soc/sof/intel/hda-stream.c:488 hda_dsp_iccmax_stream_hw_params() warn: variable dereferenced before check 'hext_stream' (see line 486) Fixes: aca961f196e5d ("ASoC: SOF: Intel: hda: Add helper function to program ICCMAX stream") Signed-off-by: Ethan Tidmore Link: https://patch.msgid.link/20260324173830.17563-1-ethantidmore06@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c87f914822c26ae00484fdba11e7ef68df5c82d7 Author: Lei Huang Date: Tue Mar 31 15:54:05 2026 +0800 ALSA: hda/realtek: fix code style (ERROR: else should follow close brace '}') [ Upstream commit d1888bf848ade6a9e71c7ba516fd215aa1bd8d65 ] Fix checkpatch code style errors: ERROR: else should follow close brace '}' #2300: FILE: sound/hda/codecs/realtek/alc269.c:2300: + } + else Fixes: 31278997add6 ("ALSA: hda/realtek - Add headset quirk for Dell DT") Signed-off-by: Lei Huang Link: https://patch.msgid.link/20260331075405.78148-1-huanglei814@163.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit f329dccceb764e063e6c60c1f7877e27e2b0cf2b Author: Billy Tsai Date: Mon Mar 9 10:33:24 2026 +0800 hwmon: (aspeed-g6-pwm-tach): remove redundant driver remove callback [ Upstream commit 46fef8583daa1bf78fda7eaa523c64d4440322ac ] Drops the remove callback as it only asserts reset and the probe already registers a devres action (devm_add_action_or_reset()) to call aspeed_pwm_tach_reset_assert(). Fixes: 7e1449cd15d1 ("hwmon: (aspeed-g6-pwm-tacho): Support for ASPEED g6 PWM/Fan tach") Signed-off-by: Billy Tsai Link: https://lore.kernel.org/r/20260309-pwm_fixes-v2-1-ca9768e70470@aspeedtech.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 06fed91296f8c451fbac3067687c8c450d8ceb99 Author: Kuppuswamy Sathyanarayanan Date: Wed Mar 18 10:04:49 2026 -0700 PCI/DPC: Log AER error info for DPC/EDR uncorrectable errors [ Upstream commit 97970e7c694356e3386a10e3b936d61eafd06bce ] aer_print_error() skips printing if ratelimit_print[i] is not set. In the native AER path, ratelimit_print is initialized by add_error_device() during source device discovery, and is set to 1 for fatal errors to bypass rate limiting since fatal errors should always be logged. The DPC/EDR path uses the DPC-capable port as the error source and reads its AER uncorrectable error status registers directly in dpc_get_aer_uncorrect_severity(). Since it does not go through add_error_device(), ratelimit_print[0] is left uninitialized and zero. As a result, aer_print_error() silently drops all AER error messages for DPC/EDR triggered events. Set ratelimit_print[0] to 1 to bypass rate limiting and always print AER logs for uncorrectable errors detected by the DPC port. Fixes: a57f2bfb4a58 ("PCI/AER: Ratelimit correctable and non-fatal error logging") Co-developed-by: Goudar Manjunath Ramanagouda Signed-off-by: Goudar Manjunath Ramanagouda Signed-off-by: Kuppuswamy Sathyanarayanan [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260318170449.2733581-1-sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Sasha Levin commit 0a84e210daec23132035a944d430d562ffcc8097 Author: Timur Kristóf Date: Sun Mar 29 18:03:06 2026 +0200 drm/amdgpu/uvd4.2: Don't initialize UVD 4.2 when DPM is disabled [ Upstream commit 8b3e8fa6d7bdab292447a43f70532db437d5d4f5 ] UVD 4.2 doesn't work at all when DPM is disabled because the SMU is responsible for ungating it. So, Linux fails to boot with CIK GPUs when using the amdgpu.dpm=0 parameter. Fix this by returning -ENOENT from uvd_v4_2_early_init() when amdgpu_dpm isn't enabled. Note: amdgpu.dpm=0 is often suggested as a workaround for issues and is useful for debugging. Fixes: a2e73f56fa62 ("drm/amdgpu: Add support for CIK parts") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2381d4c5cc1efa2dc9db3d7b7789c15d59d0ce00 Author: Timur Kristóf Date: Sun Mar 29 18:03:05 2026 +0200 drm/amd/pm/smu7: Add SCLK cap for quirky Hawaii board [ Upstream commit 4724bc5b8d78c34b993594f9406135408ccb312a ] On a specific Radeon R9 390X board, the GPU can "randomly" hang while gaming. Initially I thought this was a RADV bug and tried to work around this in Mesa: commit 8ea08747b86b ("radv: Mitigate GPU hang on Hawaii in Dota 2 and RotTR") However, I got some feedback from other users who are reporting that the above mitigation causes a significant performance regression for them, and they didn't experience the hang on their GPU in the first place. After some further investigation, it turns out that the problem is that the highest SCLK DPM level on this board isn't stable. Lowering SCLK to 1040 MHz (from 1070 MHz) works around the issue, and has a negligible impact on performance compared to the Mesa patch. (Note that increasing the voltage can also work around it, but we felt that lowering the SCLK is the safer option.) To solve the above issue, add an "sclk_cap" field to smu7_hwmgr and set this field for the affected board. The capped SCLK value correctly appears on the sysfs interface and shows up in GUI tools such as LACT. Fixes: 9f4b35411cfe ("drm/amd/powerplay: add CI asics support to smumgr (v3)") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c140492d0bbe014c5b3962e0c1b68d314a37122f Author: Timur Kristóf Date: Sun Mar 29 18:03:04 2026 +0200 drm/amd/pm/ci: Fill DW8 fields from SMC [ Upstream commit baf28ec5795c077406d6f52b8ad39e614153bce6 ] In ci_populate_dw8() we currently just read a value from the SMU and then throw it away. Instead of throwing away the value, we should use it to fill other fields in DW8 (like radeon). Otherwise the value of the other fiels is just cleared when we copy this data to the SMU later. Fixes: 9f4b35411cfe ("drm/amd/powerplay: add CI asics support to smumgr (v3)") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 1de9639b50dbc574815924651bd9eee6c04eeccf Author: Timur Kristóf Date: Sun Mar 29 18:03:03 2026 +0200 drm/amd/pm/ci: Clear EnabledForActivity field for memory levels [ Upstream commit 5facfd4c4c67e8500116ffec0d9da35d92b9c787 ] Follow what radeon did and what amdgpu does for other GPUs with SMU7. Fixes: 9f4b35411cfe ("drm/amd/powerplay: add CI asics support to smumgr (v3)") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9d92707b43f74648bb163ed4536bf34de65cc86c Author: Timur Kristóf Date: Sun Mar 29 18:03:02 2026 +0200 drm/amd/pm/ci: Fix powertune defaults for Hawaii 0x67B0 [ Upstream commit d784759c07924280f3c313f205fc48eb62d7cb71 ] There is no AMD GPU with the ID 0x66B0, this looks like a typo. It should be 0x67B0 which is actually part of the PCI ID list, and should use the Hawaii XT powertune defaults according to the old radeon driver. Fixes: 9f4b35411cfe ("drm/amd/powerplay: add CI asics support to smumgr (v3)") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 432fdc0141b53793702e862884cd04bff9b409c7 Author: Timur Kristóf Date: Sun Mar 29 18:03:00 2026 +0200 drm/amd/pm/smu7: Fix SMU7 voltage dependency on display clock [ Upstream commit 0138610c14130425be53423b35336561829965e0 ] The DCE (display controller engine) requires a minimum voltage in order to function correctly, depending on which clock level it currently uses. Add a new table that contains display clock frequency levels and the corresponding required voltages. The clock frequency levels are taken from DC (and the old radeon driver's voltage dependency table for CI in cases where its values were lower). The voltage levels are taken from the following function: phm_initializa_dynamic_state_adjustment_rule_settings(). Furthermore, in case of CI, call smu7_patch_vddc() on the new table to account for leakage voltage (like in radeon). Use the display clock value from amd_pp_display_configuration to look up the voltage level needed by the DCE. Send the voltage to the SMU via the PPSMC_MSG_VddC_Request command. The previous implementation of this feature was non-functional because it relied on a "dal_power_level" field which was never assigned; and it was not at all implemented for CI ASICs. I verified this on a Radeon R9 M380 which previously booted to a black screen with DC enabled (default since Linux 6.19), but now works correctly. Fixes: 599a7e9fe1b6 ("drm/amd/powerplay: implement smu7 hwmgr to manager asics with smu ip version 7.") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c829b4633041f3eb59b197a6e38baf6f94541dd8 Author: Timur Kristóf Date: Sun Mar 29 18:02:59 2026 +0200 drm/amd/pm/ci: Disable MCLK DPM on problematic CI ASICs [ Upstream commit 9851f29cb06c09f7dad3867d8b0feec3fc71b6c8 ] There are two known cases where MCLK DPM can causes issues: Radeon R9 M380 found in iMac computers from 2015. The SMU in this GPU just hangs as soon as we send it the PPSMC_MSG_MCLKDPM_Enable command, even when MCLK switching is disabled, and even when we only populate one MCLK DPM level. Apply workaround to all devices with the same subsystem ID. Radeon R7 260X due to old memory controller microcode. We only flash the MC ucode when it isn't set up by the VBIOS, therefore there is no way to make sure that it has the correct ucode version. I verified that this patch fixes the SMU hang on the R9 M380 which would previously fail to boot. This also fixes the UVD initialization error on that GPU which happened because the SMU couldn't ungate the UVD after it hung. Fixes: 86457c3b21cb ("drm/amd/powerplay: Add support for CI asics to hwmgr") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 21e8dd9906bff50b97ca7c3c782496678635ddce Author: Timur Kristóf Date: Sun Mar 29 18:02:58 2026 +0200 drm/amd/pm/ci: Use highest MCLK on CI when MCLK DPM is disabled [ Upstream commit 894f0d34d66cb47fe718fe2ae5c18729d22c5218 ] When MCLK DPM is disabled for any reason, populate the MCLK table with the highest MCLK DPM level, so that the ASIC can use the highest possible memory clock to get good performance even when MCLK DPM is disabled. Fixes: 9f4b35411cfe ("drm/amd/powerplay: add CI asics support to smumgr (v3)") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 67e582c86ab17b40f97e17fd5c06ac0cb6e693a8 Author: Vijendar Mukunda Date: Mon Mar 30 12:50:27 2026 +0530 ASoC: amd: acp: update dmic_num logic for acp pdm dmic [ Upstream commit 5902e1f3c501375797dcd7ca21b58e2c9abbe317 ] Currently there is no mechanism to read dmic_num in mach_params structure. In this scenario mach_params->dmic_num check always returns 0 which fails to add component string for dmic. Update the condition check with acp pdm dmic quirk check and pass the dmic_num as 1. Fixes: 2981d9b0789c ("ASoC: amd: acp: add soundwire machine driver for legacy stack") Signed-off-by: Vijendar Mukunda Link: https://patch.msgid.link/20260330072431.3512358-2-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit edfa91bb652e2d03ccc8caa3b17af01ddce23538 Author: Cássio Gabriel Date: Wed Mar 25 02:24:04 2026 -0300 ALSA: core: Validate compress device numbers without dynamic minors [ Upstream commit 796e119e9b14763be905ad0d023c71a14bc2e931 ] Without CONFIG_SND_DYNAMIC_MINORS, ALSA reserves only two fixed minors for compress devices on each card: comprD0 and comprD1. snd_find_free_minor() currently computes the compress minor as type + dev without validating dev first, so device numbers greater than 1 spill into the HWDEP minor range instead of failing registration. ASoC passes rtd->id to snd_compress_new(), so this can happen on real non-dynamic-minor builds. Add a dedicated fixed-minor check for SNDRV_DEVICE_TYPE_COMPRESS in snd_find_free_minor() and reject out-of-range device numbers with -EINVAL before constructing the minor. Also remove the stale TODO in compress_offload.c that still claims multiple compress nodes are missing. Fixes: 3eafc959b32f ("ALSA: core: add support for compressed devices") Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260325-alsa-compress-static-minors-v1-1-0628573bee1c@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 3c349995e51edfa3d1d12cf341b5ae3bb98119d7 Author: Ethan Tidmore Date: Thu Mar 19 13:26:44 2026 -0500 iommu/riscv: Fix signedness bug [ Upstream commit 553a127cb66523089bc10eb54640205495f4bb5b ] The function platform_irq_count() returns negative error codes and iommu->irqs_count is an unsigned integer, so the check (iommu->irqs_count <= 0) is always impossible. Make the return value of platform_irq_count() be assigned to ret, check for error, and then assign iommu->irqs_count to ret. Detected by Smatch: drivers/iommu/riscv/iommu-platform.c:119 riscv_iommu_platform_probe() warn: 'iommu->irqs_count' unsigned <= 0 Signed-off-by: Ethan Tidmore Fixes: 5c0ebbd3c6c6 ("iommu/riscv: Add RISC-V IOMMU platform device driver") Reviewed-by: Andrew Jones Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit e3fae61f4799d7cc84a815c5d60a67431ec273cd Author: Yaxing Guo Date: Fri Jan 30 14:54:20 2026 +0800 iommu/riscv: Skip IRQ count check when using MSI interrupts [ Upstream commit 7217cee35aadbb07e12673bcf1dcf729e1b2f6c9 ] In RISC-V IOMMU platform devices that use MSI interrupts (indicated by the presence of 'msi-parent' in the device tree), there are no wired interrupt lines, so calling platform_get_irq_count() returns 0 or -ENXIO, causing the driver to fail during probe. However, MSI interrupts are allocated dynamically via the MSI subsystem and do not appear in the device tree 'interrupts' property. Therefore, the driver should not require a non-zero IRQ count when 'msi-parent' is present. This patch fixes the bug where probe fails when using MSI interrupts (which do not have an 'interrupts' property in the device tree).. Fixes: ("iommu/riscv: Add support for platform msi") Signed-off-by: Yaxing Guo Reviewed-by: Andrew Jones Signed-off-by: Joerg Roedel Stable-dep-of: 553a127cb665 ("iommu/riscv: Fix signedness bug") Signed-off-by: Sasha Levin commit ccd4c3e5c9078249d9448519fe8cf042821005a8 Author: Ilpo Järvinen Date: Tue Mar 24 18:56:33 2026 +0200 PCI: Fix alignment calculation for resource size larger than align [ Upstream commit 8cb081667377709f4924ab6b3a88a0d7a761fe91 ] The commit bc75c8e50711 ("PCI: Rewrite bridge window head alignment function") did not use if (r_size <= align) check from pbus_size_mem() for the new head alignment bookkeeping structure (aligns2[]). In some configurations, this can result in producing a gap into the bridge window which the resource larger than its alignment cannot fill. The old alignment calculation algorithm was removed by the subsequent commit 3958bf16e2fe ("PCI: Stop over-estimating bridge window size") which renamed the aligns2[] array leaving only aligns[] array. Add the if (r_size <= align) check back to avoid this problem. Fixes: bc75c8e50711 ("PCI: Rewrite bridge window head alignment function") Reported-by: Guenter Roeck Closes: https://lore.kernel.org/all/b05a6f14-979d-42c9-924c-d8408cb12ae7@roeck-us.net/ Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Xifer Link: https://patch.msgid.link/20260324165633.4583-11-ilpo.jarvinen@linux.intel.com Signed-off-by: Sasha Levin commit b375c3c7209cc59e40e97998aa9bc768369cca0e Author: Wenkai Lin Date: Sat Mar 21 15:00:38 2026 +0800 crypto: hisilicon/sec2 - prevent req used-after-free for sec [ Upstream commit 67b53a660e6bf0da2fa8d8872e897a14d8059eaf ] During packet transmission, if the system is under heavy load, the hardware might complete processing the packet and free the request memory (req) before the transmission function finishes. If the software subsequently accesses this req, a use-after-free error will occur. The qp_ctx memory exists throughout the packet sending process, so replace the req with the qp_ctx. Fixes: f0ae287c5045 ("crypto: hisilicon/sec2 - implement full backlog mode for sec") Signed-off-by: Wenkai Lin Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 2d18cf09f2b07e116b53532fe20dc7020b01525b Author: Ilpo Järvinen Date: Fri Mar 13 10:45:50 2026 +0200 PCI: Fix premature removal from realloc_head list during resource assignment [ Upstream commit 1ee4716a5a28eaef81ae1f280d983258bee49623 ] reassign_resources_sorted() checks for two things: a) Resource assignment failures for mandatory resources by checking if the resource remains unassigned, which are known to always repeat, and does not attempt to assign them again. b) That resource is not among the ones being processed/assigned at this stage, leading to skip processing such resources in reassign_resources_sorted() as well (resource assignment progresses one PCI hierarchy level at a time). The problem here is that a) is checked before b), but b) also implies the resource is not being assigned yet, making also a) true. As a) only skips resource assignment but still removes the resource from realloc_head, the later stages that would need to process the information in realloc_head cannot obtain the optional size information anymore. This leads to considering only non-optional part for bridge windows deeper in the PCI hierarchy. This problem has been observed during rescan (add_size is not considered while attempting assignment for 0000:e2:00.0 indicating the corresponding entry was removed from realloc_head while processing resource assignments for 0000:e1): pci_bus 0000:e1: scanning bus ... pci 0000:e3:01.0: bridge window [mem 0x800000000-0x1000ffffff 64bit pref] to [bus e4] add_size 60c000000 add_align 800000000 pci 0000:e3:01.0: bridge window [mem 0x00100000-0x000fffff] to [bus e4] add_size 200000 add_align 200000 pci 0000:e3:02.0: disabling bridge window [mem 0x00000000-0x000fffff 64bit pref] to [bus e5] (unused) pci 0000:e2:00.0: bridge window [mem 0x800000000-0x1000ffffff 64bit pref] to [bus e3-e5] add_size 60c000000 add_align 800000000 pci 0000:e2:00.0: bridge window [mem 0x00100000-0x001fffff] to [bus e3-e5] add_size 200000 add_align 200000 pcieport 0000:e1:02.0: bridge window [io size 0x2000]: can't assign; no space pcieport 0000:e1:02.0: bridge window [io size 0x2000]: failed to assign pcieport 0000:e1:02.0: bridge window [io 0x1000-0x2fff]: resource restored pcieport 0000:e1:02.0: bridge window [io 0x1000-0x2fff]: resource restored pcieport 0000:e1:02.0: bridge window [io size 0x2000]: can't assign; no space pcieport 0000:e1:02.0: bridge window [io size 0x2000]: failed to assign pci 0000:e2:00.0: bridge window [mem 0x28f000000000-0x28f800ffffff 64bit pref]: assigned Fixes: 96336ec70264 ("PCI: Perform reset_resource() and build fail list in sync") Reported-by: Peter Nisbet Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Peter Nisbet Link: https://patch.msgid.link/20260313084551.1934-1-ilpo.jarvinen@linux.intel.com Signed-off-by: Sasha Levin commit 34678c9788887b65d48ca10530581ca7440402e5 Author: Ilpo Järvinen Date: Fri Dec 19 19:40:21 2025 +0200 PCI: Use res_to_dev_res() in reassign_resources_sorted() [ Upstream commit 4bee4fc0f4ee1086e498f9d197352237a0232598 ] reassign_resources_sorted() contains a search loop for a particular resource in the head list. res_to_dev_res() already implements the same search so use it instead. Drop unused found_match and dev_res variables. Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20251219174036.16738-9-ilpo.jarvinen@linux.intel.com Stable-dep-of: 1ee4716a5a28 ("PCI: Fix premature removal from realloc_head list during resource assignment") Signed-off-by: Sasha Levin commit f176c47683bf6365e2f6d580d557fae49169a703 Author: Krishna Chaitanya Chundru Date: Sat Mar 14 07:26:34 2026 +0530 PCI: qcom: Advertise Hotplug Slot Capability with no Command Completion support [ Upstream commit 33a76fc3c3e61386524479b99f35423bd3d9a895 ] Qcom PCIe Root Ports advertise hotplug capability in hardware, but do not support hotplug command completion. As a result, the hotplug commands issued by the pciehp driver never gets completion notification, leading to repeated timeout warnings and multi-second delays during boot and suspend/resume. Commit a54db86ddc153 ("PCI: qcom: Do not advertise hotplug capability for IPs v2.7.0 and v1.9.0") mistakenly assumed that the Root Ports doesn't support Hotplug due to timeouts and disabled the Hotplug functionality altogether. But the Root Ports does support reporting Hotplug events like DL_Up/Down events. So to fix the command completion timeout issues, just set the No Command Completed Support (NCCS) bit and enable Hotplug in Slot Capability field back. Fixes: a54db86ddc153 ("PCI: qcom: Do not advertise hotplug capability for IPs v2.7.0 and v1.9.0") Signed-off-by: Krishna Chaitanya Chundru [mani: renamed function, commit log and added comment] Signed-off-by: Manivannan Sadhasivam Tested-by: Konrad Dybcio # Hamoa CRD, tunneled link Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260314-hotplug-v1-1-96ac87d93867@oss.qualcomm.com Signed-off-by: Sasha Levin commit cd3938c12bdac9f23a9d1fcdb1176504c47e39bc Author: Sebastian Reichel Date: Tue Feb 17 16:25:26 2026 +0200 drm/panel: simple: Correct G190EAN01 prepare timing [ Upstream commit f1080f82570b797598c1ba7e9c800ae9e94aafc6 ] The prepare timing specified by the G190EAN01 datasheet should be between 30 and 50 ms. Considering it might take some time for the LVDS encoder to enable the signal, we should only wait the min. required time in the panel driver and not the max. allowed time. Fixes: 2f7b832fc992 ("drm/panel: simple: Add support for AUO G190EAN01 panel") Signed-off-by: Sebastian Reichel Signed-off-by: Ian Ray Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://patch.msgid.link/20260217142528.68613-1-ian.ray@gehealthcare.com Signed-off-by: Sasha Levin commit 31b2d7be7540cec5c5fc7dbb1dbeaa61d5c6b739 Author: Dmitry Baryshkov Date: Mon Mar 23 03:21:49 2026 +0200 drm/panel: sharp-ls043t1le01: make use of prepare_prev_first [ Upstream commit c222177d7c7e1b2e0433d9e47ec2da7015345d50 ] The DSI link must be powered up to let panel driver to talk to the panel during prepare() callback execution. Set the prepare_prev_first flag to guarantee this. Fixes: 9e15123eca79 ("drm/msm/dsi: Stop unconditionally powering up DSI hosts at modeset") Signed-off-by: Dmitry Baryshkov Reviewed-by: Douglas Anderson Signed-off-by: Neil Armstrong Link: https://patch.msgid.link/20260323-panel-fix-v1-1-9f12b09161e8@oss.qualcomm.com Signed-off-by: Sasha Levin commit 131e01ba249f28f90e8ec1db1c7187f33868381d Author: Alexey Charkov Date: Wed Mar 18 18:50:25 2026 +0400 ASoC: rockchip: rockchip_sai: Set slot width for non-TDM mode [ Upstream commit 8a6391ec669366cbe7bde92b468c561e8b309fd6 ] Currently the slot width in non-TDM mode is always kept at the POR value of 32 bits, regardless of the sample width, which doesn't work well for some codecs such as NAU8822. Set the slot width according to the sample width in non-TDM mode, which is what other CPU DAI drivers do. Tested on the following RK3576 configurations: - SAI2 + NAU8822 (codec as the clock master), custom board - SAI1 + ES8388 (codec as the clock master), RK3576 EVB1 - SAI2 + RT5616 (SAI as the clock master), FriendlyElec NanoPi M5 NAU8822 didn't work prior to this patch but works after the patch. Other two configurations work both before and after the patch. Fixes: cc78d1eaabad ("ASoC: rockchip: add Serial Audio Interface (SAI) driver") Signed-off-by: Alexey Charkov Tested-by: Nicolas Frattaroli Link: https://patch.msgid.link/20260318-sai-slot-width-v1-1-1f68186f71e3@flipper.net Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9c47a36ceaf043e07c872597069826916e20e3ef Author: Alexander Koskovich Date: Tue Mar 24 11:48:27 2026 +0000 drm/msm/dsi: rename MSM8998 DSI version from V2_2_0 to V2_0_0 [ Upstream commit 913a709dea0eff9c7b2e9470f8c8594b9a0114ab ] The MSM8998 DSI controller is v2.0.0 as stated in commit 7b8c9e203039 ("drm/msm/dsi: Add support for MSM8998 DSI controller"). The value was always correct just the name was wrong. Rename and reorder to maintain version sorting. Fixes: 7b8c9e203039 ("drm/msm/dsi: Add support for MSM8998 DSI controller") Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Signed-off-by: Alexander Koskovich Patchwork: https://patchwork.freedesktop.org/patch/713717/ Link: https://lore.kernel.org/r/20260324-dsi-rgb101010-support-v5-3-ff6afc904115@pm.me Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit a303f8863c9766d0f3fadd5874286fee6992644d Author: Pengyu Luo Date: Sat Mar 7 19:12:49 2026 +0800 drm/msm/dsi: fix hdisplay calculation for CMD mode panel [ Upstream commit 82159db4371f5cef56444ebd0b8f96e2a6d709ff ] Commit ac47870fd795 ("drm/msm/dsi: fix hdisplay calculation when programming dsi registers") incorrecly broke hdisplay calculation for CMD mode by specifying incorrect number of bytes per transfer, fix it. Fixes: ac47870fd795 ("drm/msm/dsi: fix hdisplay calculation when programming dsi registers") Signed-off-by: Pengyu Luo Patchwork: https://patchwork.freedesktop.org/patch/709917/ Link: https://lore.kernel.org/r/20260307111250.105772-2-mitltlatltl@gmail.com [DB: fixed commit message] Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit e82ef4ef320c56d2a12443eb796253427a5b67cb Author: Pengyu Luo Date: Sat Mar 7 19:12:48 2026 +0800 drm/msm/dsi: fix bits_per_pclk [ Upstream commit 2d51cfb77daa30b10bc68c403f8ace35783d2922 ] mipi_dsi_pixel_format_to_bpp return dst bpp not src bpp, dst bpp may not be the uncompressed data size. use src bpc * 3 to get src bpp, this aligns with pclk rate calculation. Fixes: ac47870fd795 ("drm/msm/dsi: fix hdisplay calculation when programming dsi registers") Signed-off-by: Pengyu Luo Patchwork: https://patchwork.freedesktop.org/patch/709916/ Link: https://lore.kernel.org/r/20260307111250.105772-1-mitltlatltl@gmail.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 94e021272c455c9c710743256b5fe8fe9457f176 Author: Dmitry Baryshkov Date: Tue Mar 17 17:30:05 2026 +0200 drm/msm/dpu: don't try using 2 LMs if only one DSC is available [ Upstream commit b9699dd862760e642807a2bc226e4d127e35dcb7 ] Current topology code will try using 2 LMs with just one DSC, which breaks cases like SC7280 / Fairphone5. Forbid using 2 LMs split in such a case. Fixes: 1ce69c265a53 ("drm/msm/dpu: move resource allocation to CRTC") Reported-by: Luca Weiss Closes: https://lore.kernel.org/r/DH1IKLU0YZYU.2SW4WYO7H3H4R@fairphone.com/ Tested-by: Luca Weiss # qcm6490-fairphone-fp5 Patchwork: https://patchwork.freedesktop.org/patch/712386/ Link: https://lore.kernel.org/r/20260317-fix-3d-dsc-v1-1-88b54f62f659@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit acde37cb798d257db5debf1f2fe4ef524e962dda Author: Pengyu Luo Date: Mon Mar 9 18:02:53 2026 +0800 drm/msm/dsi: add the missing parameter description [ Upstream commit 958adefc4c0fddee3b12269da5dd7cb49bac953f ] Add a description for is_bonded_dsi in dsi_adjust_pclk_for_compression to match the existing kernel-doc comment. Fixes: e4eb11b34d6c ("drm/msm/dsi: fix pclk rate calculation for bonded dsi") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202603080314.XeqyRZ7A-lkp@intel.com/ Signed-off-by: Pengyu Luo Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/710112/ Link: https://lore.kernel.org/r/20260309100254.877801-1-mitltlatltl@gmail.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 0f7dd5839cfabaf9c007fb718ec66e907a473c93 Author: Yuanjie Yang Date: Mon Mar 9 14:37:20 2026 +0800 drm/msm/dpu: fix mismatch between power and frequency [ Upstream commit bc1dccc518cc5ab5140fba06c27e7188e0ed342b ] During DPU runtime suspend, calling dev_pm_opp_set_rate(dev, 0) drops the MMCX rail to MIN_SVS while the core clock frequency remains at its original (highest) rate. When runtime resume re-enables the clock, this may result in a mismatch between the rail voltage and the clock rate. For example, in the DPU bind path, the sequence could be: cpu0: dev_sync_state -> rpmhpd_sync_state cpu1: dpu_kms_hw_init timeline 0 ------------------------------------------------> t After rpmhpd_sync_state, the voltage performance is no longer guaranteed to stay at the highest level. During dpu_kms_hw_init, calling dev_pm_opp_set_rate(dev, 0) drops the voltage, causing the MMCX rail to fall to MIN_SVS while the core clock is still at its maximum frequency. When the power is re-enabled, only the clock is enabled, leading to a situation where the MMCX rail is at MIN_SVS but the core clock is at its highest rate. In this state, the rail cannot sustain the clock rate, which may cause instability or system crash. Remove the call to dev_pm_opp_set_rate(dev, 0) from dpu_runtime_suspend to ensure the correct vote is restored when DPU resumes. Fixes: b0530eb11913 ("drm/msm/dpu: Use OPP API to set clk/perf state") Signed-off-by: Yuanjie Yang Reviewed-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/710077/ Link: https://lore.kernel.org/r/20260309063720.13572-1-yuanjie.yang@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit c7d586c6348dfc14d0254528cc63efd5951393d8 Author: Dmitry Baryshkov Date: Sat Feb 28 19:20:37 2026 +0200 drm/msm: add missing MODULE_DEVICE_ID definitions [ Upstream commit b21e85400ce763f2c6ad913e03fea5cadc323c13 ] The drm/msm module bundles several drivers, each of them having a separate OF match table, however only MDSS (subsystem), KMS devices and GPU have corresponding MODULE_DEVICE_ID tables. Add MODULE_DEVICE_ID to the display-related driver and to all other drivers in this module, simplifying userspace job. Fixes: 060530f1ea67 ("drm/msm: use componentised device support") Reported-by: Loïc Minier Patchwork: https://patchwork.freedesktop.org/patch/707960/ Link: https://lore.kernel.org/r/20260228-msm-device-id-v2-1-24b085919444@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 3441e4b70cf9b43bde900e349f64ab175f4cad91 Author: Nicolin Chen Date: Thu Mar 12 17:36:35 2026 -0700 iommu/tegra241-cmdqv: Update uAPI to clarify HYP_OWN requirement [ Upstream commit 9dcef98dbee35b8ae784df04c041efffdd42a69c ] >From hardware implementation perspective, a guest tegra241-cmdqv hardware is different than the host hardware: - Host HW is backed by a VINTF (HYP_OWN=1) - Guest HW is backed by a VINTF (HYP_OWN=0) The kernel driver has an implementation requirement of the HYP_OWN bit in the VM. So, VMM must follow that to allow the same copy of Linux to work. Add this requirement to the uAPI, which is currently missing. Fixes: 4dc0d12474f9 ("iommu/tegra241-cmdqv: Add user-space use support") Signed-off-by: Nicolin Chen Reviewed-by: Eric Auger Reviewed-by: Jason Gunthorpe Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 86c8d5cdadd9d56d336a8bd38d44d95f752cc084 Author: Nicolin Chen Date: Thu Mar 12 17:36:34 2026 -0700 iommu/tegra241-cmdqv: Set supports_cmd op in tegra241_vcmdq_hw_init() [ Upstream commit 803e41f36d227022ab9bbe780c82283fd4713b2e ] vintf->hyp_own is finalized in tegra241_vintf_hw_init(). On the other hand, tegra241_vcmdq_alloc_smmu_cmdq() is called via an init_structures callback, which is earlier than tegra241_vintf_hw_init(). This results in the supports_cmd op always being set to the guest function, although this doesn't break any functionality nor have some noticeable perf impact since non-invalidation commands are not issued in the perf sensitive context. Fix this by moving supports_cmd to tegra241_vcmdq_hw_init(). After this change, - For a guest kernel, this will be a status quo - For a host kernel, non-invalidation commands will be issued to VCMDQ(s) Fixes: a9d40285bdef ("iommu/tegra241-cmdqv: Limit CMDs for VCMDQs of a guest owned VINTF") Reported-by: Eric Auger Reported-by: Shameer Kolothum Closes: https://lore.kernel.org/qemu-devel/CH3PR12MB754836BEE54E39B30C7210C0AB44A@CH3PR12MB7548.namprd12.prod.outlook.com/ Signed-off-by: Nicolin Chen Reviewed-by: Eric Auger Tested-by: Shameer Kolothum Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 3a8d94405fd5d53b51ad48ee6078aec123cd83cd Author: Alexandru Dadu Date: Mon Mar 23 20:31:29 2026 +0200 drm/imagination: Switch reset_reason fields from enum to u32 [ Upstream commit d2f83a6cd598bf413f1acf34153bd1d71023fbab ] Update the reset_reason fwif structure fields from enum to u32 to remove any ambiguity from the interface (enum is not a fixed size thus is unfit for the purpose of the data type). Fixes: a26f067feac1f ("drm/imagination: Add FWIF headers") Signed-off-by: Alexandru Dadu Reviewed-by: Matt Coster Link: https://patch.msgid.link/20260323-b4-firmware-context-reset-notification-handling-v3-2-1a66049a9a65@imgtec.com Signed-off-by: Matt Coster Signed-off-by: Sasha Levin commit 3d0ef0567d21c635b9496b138e55343d95e72e10 Author: Pei Xiao Date: Thu Mar 19 11:06:41 2026 +0800 spi: hisi-kunpeng: prevent infinite while() loop in hisi_spi_flush_fifo [ Upstream commit 9f61daf2c2debe9f5cf4e1a4471e56a89a6fe45a ] The hisi_spi_flush_fifo()'s inner while loop that lacks any timeout mechanism. Maybe the hardware never becomes empty, the loop will spin forever, causing the CPU to hang. Fix this by adding a inner_limit based on loops_per_jiffy. The inner loop now exits after approximately one jiffy if the FIFO remains non-empty, logs a ratelimited warning, and breaks out of the outer loop. Additionally, add a cpu_relax() inside the busy loop to improve power efficiency. Fixes: c770d8631e18 ("spi: Add HiSilicon SPI Controller Driver for Kunpeng SoCs") Signed-off-by: Pei Xiao Link: https://patch.msgid.link/d834ce28172886bfaeb9c8ca00cfd9bf1c65d5a1.1773889292.git.xiaopei01@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit eae672a7ec8a9ba4e06b8d94e88cb2361bc5e21c Author: Alex Deucher Date: Thu Feb 19 18:20:27 2026 -0500 drm/amdgpu/gfx11: look at the right prop for gfx queue priority [ Upstream commit f9a4e81bcbd04e6f967d851f9fe69d8bb3cc08b3 ] Look at hqd_queue_priority rather than hqd_pipe_priority. In practice, it didn't matter as both were always set for kernel queues, but that will change in the future. Fixes: 2e216b1e6ba2 ("drm/amdgpu/gfx11: handle priority setup for gfx pipe1") Reviewed-by：Jesse Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0cd9d5878b3cc810869aaa92b74337c3edd36eaf Author: Alex Deucher Date: Thu Feb 19 18:18:28 2026 -0500 drm/amdgpu/gfx10: look at the right prop for gfx queue priority [ Upstream commit 355d96cdec5c61fd83f7eb54f1a28e38809645d6 ] Look at hqd_queue_priority rather than hqd_pipe_priority. In practice, it didn't matter as both were always set for kernel queues, but that will change in the future. Fixes: b07d1d73b09e ("drm/amd/amdgpu: Enable high priority gfx queue") Reviewed-by：Jesse Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit db201e6fab1e8d2552b65ed78442bc5844650e38 Author: Koichiro Den Date: Fri Mar 6 00:10:50 2026 +0900 PCI: dwc: rcar-gen4: Change EPC BAR alignment to 4K as per the documentation [ Upstream commit 13f55a7ca773c731a1e645934c1ae48577f48785 ] R-Car S4 Series (R8A779F[4-7]*) EP controller uses a 4K minimum iATU region size (CX_ATU_MIN_REGION_SIZE = 4K) as per R19UH0161EJ0130 Rev.1.30. Also, the controller itself can only be configured in the range 4 KB to 64 KB, so the current 1 MB alignment requirement is incorrect. Hence, change the alignment to the min size 4K as per the documentation. This also fixes needless unusability of BAR4 on this platform when the target address is fixed, such as for doorbell targets. Fixes: e311b3834dfa ("PCI: rcar-gen4: Add endpoint mode support") Signed-off-by: Koichiro Den [mani: commit log] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Niklas Cassel Link: https://patch.msgid.link/20260305151050.1834007-1-den@valinux.co.jp Signed-off-by: Sasha Levin commit 5a9f29a3e076b637d2234093e57989cf755ded5b Author: Daniel Jordan Date: Fri Mar 13 11:24:33 2026 -0400 padata: Put CPU offline callback in ONLINE section to allow failure [ Upstream commit c8c4a2972f83c8b68ff03b43cecdb898939ff851 ] syzbot reported the following warning: DEAD callback error for CPU1 WARNING: kernel/cpu.c:1463 at _cpu_down+0x759/0x1020 kernel/cpu.c:1463, CPU#0: syz.0.1960/14614 at commit 4ae12d8bd9a8 ("Merge tag 'kbuild-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux") which tglx traced to padata_cpu_dead() given it's the only sub-CPUHP_TEARDOWN_CPU callback that returns an error. Failure isn't allowed in hotplug states before CPUHP_TEARDOWN_CPU so move the CPU offline callback to the ONLINE section where failure is possible. Fixes: 894c9ef9780c ("padata: validate cpumask without removed CPU during offline") Reported-by: syzbot+123e1b70473ce213f3af@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/69af0a05.050a0220.310d8.002f.GAE@google.com/ Debugged-by: Thomas Gleixner Signed-off-by: Daniel Jordan Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 8e26246dc1049fc0a49b34829f2a83c69ebefa8d Author: Chuyi Zhou Date: Thu Feb 26 16:07:03 2026 +0800 padata: Remove cpu online check from cpu add and removal [ Upstream commit 73117ea6470dca787f70f33c001f9faf437a1c0b ] During the CPU offline process, the dying CPU is cleared from the cpu_online_mask in takedown_cpu(). After this step, various CPUHP_*_DEAD callbacks are executed to perform cleanup jobs for the dead CPU, so this cpu online check in padata_cpu_dead() is unnecessary. Similarly, when executing padata_cpu_online() during the CPUHP_AP_ONLINE_DYN phase, the CPU has already been set in the cpu_online_mask, the action even occurs earlier than the CPUHP_AP_ONLINE_IDLE stage. Remove this unnecessary cpu online check in __padata_add_cpu() and __padata_remove_cpu(). Signed-off-by: Chuyi Zhou Acked-by: Daniel Jordan Signed-off-by: Herbert Xu Stable-dep-of: c8c4a2972f83 ("padata: Put CPU offline callback in ONLINE section to allow failure") Signed-off-by: Sasha Levin commit 3ffcd6c5dca983572d3ee0f9f371b5a431817672 Author: Thorsten Blum Date: Wed Mar 11 12:39:28 2026 +0100 crypto: atmel-aes - guard unregister on error in atmel_aes_register_algs [ Upstream commit 57a13941c0bb06ae24e3b34672d7b6f2172b253f ] Ensure the device supports XTS and GCM with 'has_xts' and 'has_gcm' before unregistering algorithms when XTS or authenc registration fails, which would trigger a WARN in crypto_unregister_alg(). Currently, with the capabilities defined in atmel_aes_get_cap(), this bug cannot happen because all devices that support XTS and authenc also support GCM, but the error handling should still be correct regardless of hardware capabilities. Fixes: d52db5188a87 ("crypto: atmel-aes - add support to the XTS mode") Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit f4b747f0755eed7215c1be8bf7b891d519a73e83 Author: Thorsten Blum Date: Mon Jan 26 18:47:03 2026 +0100 crypto: atmel - Use unregister_{aeads,ahashes,skciphers} [ Upstream commit 2ffc1ef4e826f0c3274f9ff5eb42bc70a5571afd ] Replace multiple for loops with calls to crypto_unregister_aeads(), crypto_unregister_ahashes(), and crypto_unregister_skciphers(). Remove the definition of atmel_tdes_unregister_algs() because it is equivalent to calling crypto_unregister_skciphers() directly, and the function parameter 'struct atmel_tdes_dev *' is unused anyway. Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Stable-dep-of: 57a13941c0bb ("crypto: atmel-aes - guard unregister on error in atmel_aes_register_algs") Signed-off-by: Sasha Levin commit 9458a6513fe7b78a98075257e9a5c29936cbf82f Author: Herbert Xu Date: Tue Mar 10 18:28:29 2026 +0900 crypto: tegra - Disable softirqs before finalizing request [ Upstream commit 2aeec9af775fb53aa086419b953302c6f4ad4984 ] Softirqs must be disabled when calling the finalization fucntion on a request. Reported-by: Guangwu Zhang Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 4a894ba48fa5123032a766a45fb075086720dc2b Author: Andy Shevchenko Date: Fri Mar 20 15:36:46 2026 +0100 fbdev: matroxfb: Mark variable with __maybe_unused to avoid W=1 build break [ Upstream commit caf6144053b4e1c815aa56afb54745a176f999df ] Clang is not happy about set but unused variable: drivers/video/fbdev/matrox/g450_pll.c:412:18: error: variable 'mnp' set but not used 412 | unsigned int mnp; | ^ 1 error generated. Since the commit 7b987887f97b ("video: fbdev: matroxfb: remove dead code and set but not used variable") the 'mnp' became unused, but eliminating that code might have side-effects. The question here is what should we do with 'mnp'? The easiest way out is just mark it with __maybe_unused which will shut the compiler up and won't change any possible IO flow. So does this change. A dive into the history of the driver: The problem was revealed when the #if 0 guarded code along with unused pixel_vco variable was removed. That code was introduced in the original commit 213d22146d1f ("[PATCH] (1/3) matroxfb for 2.5.3"). And then guarded in the commit 705e41f82988 ("matroxfb DVI updates: Handle DVI output on G450/G550. Powerdown unused portions of G450/G550 DAC. Split G450/G550 DAC from older DAC1064 handling. Modify PLL setting when both CRTCs use same pixel clocks."). NOTE: The two commits mentioned above pre-date Git era and available in history.git repository for archaeological purposes. Even without that guard the modern compilers may see that the pixel_vco wasn't ever used and seems a leftover after some debug or review made 25 years ago. The g450_mnp2vco() doesn't have any IO and as Jason said doesn't seem to have any side effects either than some unneeded CPU processing during runtime. I agree that's unlikely that timeout (or heating up the CPU) has any effect on the HW (GPU/display) functionality. Fixes: 7b987887f97b ("video: fbdev: matroxfb: remove dead code and set but not used variable") Signed-off-by: Andy Shevchenko Reviewed-by: Jason Yan Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 57a1079af3ee3dd91fd1c04ac9a9ee198de58f56 Author: Guillaume Gonnet Date: Tue Mar 17 22:32:28 2026 +0100 dm init: ensure device probing has finished in dm-mod.waitfor= [ Upstream commit 99a2312f69805f4ba92d98a757625e0300a747ab ] The early_lookup_bdev() function returns successfully when the disk device is present but not necessarily its partitions. In this situation, dm_early_create() fails as the partition block device does not exist yet. In my case, this phenomenon occurs quite often because the device is an SD card with slow reading times, on which kernel takes time to enumerate available partitions. Fortunately, the underlying device is back to "probing" state while enumerating partitions. Waiting for all probing to end is enough to fix this issue. That's also the reason why this problem never occurs with rootwait= parameter: the while loop inside wait_for_root() explicitly waits for probing to be done and then the function calls async_synchronize_full(). These lines were omitted in 035641b, even though the commit says it's based on the rootwait logic... Anyway, calling wait_for_device_probe() after our while loop does the job (it both waits for probing and calls async_synchronize_full). Fixes: 035641b01e72 ("dm init: add dm-mod.waitfor to wait for asynchronously probed block devices") Signed-off-by: Guillaume Gonnet Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit c695257f6b8d5bf8f303430bf8de3efaf37055dd Author: Srinivasan Shanmugam Date: Thu Mar 12 19:29:54 2026 +0530 drm/amdgpu: Add default case in DVI mode validation [ Upstream commit e6020a55b8e364d15eac27f9c788e13114eec6b7 ] amdgpu_connector_dvi_mode_valid() assigns max_digital_pixel_clock_khz based on connector_object_id using a switch statement that lacks a default case. In practice this code path should never be hit because the existing cases already cover all digital connector types that this function is used for. This is also legacy display code which is not used for new hardware. Add a default case returning MODE_BAD to make the switch exhaustive and silence the static analyzer smatch error. The new branch is effectively defensive and should never be reached during normal operation. Fixes: 585b2f685c56 ("drm/amdgpu: Respect max pixel clock for HDMI and DVI-D (v2)") Cc: Dan Carpenter Cc: Timur Kristóf Cc: Alex Deucher Cc: Christian König Signed-off-by: Srinivasan Shanmugam Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0d3b392b0f2cffa408cc8cf7798a53c114326a7f Author: Fangyu Yu Date: Fri Feb 27 19:26:40 2026 +0800 iommu/riscv: Stop polling when CQCSR reports an error [ Upstream commit b2e5684558edf3e9bbe18d0e0043854994eab1be ] The cmdq wait loop busy-polls the consumer index until it advances or the software timeout expires. If the IOMMU has already signaled a command queue failure in CQCSR, continuing to poll for progress is pointless. Make riscv_iommu_queue_wait() also terminate the poll when any of these CQCSR error bits are observed. This helps the caller return earlier in failure cases and avoids spinning until the full timeout interval when the hardware has already reported an error. On single-core systems in particular, the current busy-wait can delay servicing the command-timeout interrupt until the software timeout expires (90s by default). Fixes: 856c0cfe5c5f ("iommu/riscv: Command and fault queue support") Signed-off-by: Fangyu Yu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 380698b43f072c424d5d8151e5636fd925557c4d Author: Jason Gunthorpe Date: Fri Feb 27 11:25:40 2026 -0400 iommu/riscv: Add missing GENERIC_MSI_IRQ [ Upstream commit c70d20b25ca30d68b377b9363a2adca6eb2538e3 ] The commit below added MSI related calls to the driver that depends on GENERIC_MSI_IRQ. It is possible to build RISC-V without this selected. This is also necessary to make the driver COMPILE_TEST. Fixes: d5f88acdd6ff ("iommu/riscv: Add support for platform msi") Tested-by: Vincent Chen Tested-by: Tomasz Jeznach Signed-off-by: Jason Gunthorpe Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 3f917d9bff68600f77561900f3145bd4706dc840 Author: Fangyu Yu Date: Thu Jan 22 22:32:24 2026 +0800 iommu/riscv: Add IOTINVAL after updating DDT/PDT entries [ Upstream commit f5c262b544975e067ea265fc7403aefbbea8563e ] Add riscv_iommu_iodir_iotinval() to perform required TLB and context cache invalidations after updating DDT or PDT entries, as mandated by the RISC-V IOMMU specification (Section 6.3.1 and 6.3.2). Fixes: 488ffbf18171 ("iommu/riscv: Paging domain support") Signed-off-by: Fangyu Yu Reviewed-by: Andrew Jones Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit b6263eb2b188255735d1ef6b96a95abe7d8ce324 Author: Aleksander Jan Bajkowski Date: Fri Mar 6 23:17:40 2026 +0100 crypto: inside-secure/eip93 - register hash before authenc algorithms [ Upstream commit 5377032914b29b4643adece0ff1dfc67e36700f4 ] Register hash before hmac and authenc algorithms. This will ensure selftests pass at startup. Previously, selftests failed on the crypto_alloc_ahash() function since the associated algorithm was not yet registered. Fixes following error: ... [ 18.375811] alg: self-tests for authenc(hmac(sha1),cbc(aes)) using authenc(hmac(sha1-eip93),cbc(aes-eip93)) failed (rc=-2) [ 18.382140] alg: self-tests for authenc(hmac(sha224),rfc3686(ctr(aes))) using authenc(hmac(sha224-eip93),rfc3686(ctr(aes-eip93))) failed (rc=-2) [ 18.395029] alg: aead: authenc(hmac(sha256-eip93),cbc(des-eip93)) setkey failed on test vector 0; expected_error=0, actual_error=-2, flags=0x1 [ 18.409734] alg: aead: authenc(hmac(md5-eip93),cbc(des3_ede-eip93)) setkey failed on test vector 0; expected_error=0, actual_error=-2, flags=0x1 ... 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 4ad705f5e88969e34db9d5baa4811c175a42011d Author: Ethan Tidmore Date: Thu Feb 26 10:38:36 2026 -0600 drm/sun4i: Fix resource leaks [ Upstream commit 127367ad2e0f4870de60c6d719ae82ecf68d674c ] Three clocks are not being released in devm_regmap_init_mmio() error path. Add proper goto and set ret to the error code. Fixes: 8270249fbeaf0 ("drm/sun4i: backend: Create regmap after access is possible") Signed-off-by: Ethan Tidmore Reviewed-by: Jernej Skrabec Link: https://patch.msgid.link/20260226163836.10335-1-ethantidmore06@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 555eb897a4558a725ab70f8657e8e3679ca55413 Author: Maíra Canal Date: Fri Mar 6 08:30:33 2026 -0300 drm/v3d: Handle error from drm_sched_entity_init() [ Upstream commit 8cf1bec37b27846ad3169744c9f1a89a06dcb3fa ] drm_sched_entity_init() can fail but its return value is currently being ignored in v3d_open(). Check the return value and properly unwind on failure by destroying any already-initialized scheduler entities. Fixes: 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+") Reviewed-by: Iago Toral Quiroga Link: https://patch.msgid.link/20260306-v3d-reset-locking-improv-v3-1-49864fe00692@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Sasha Levin commit cb54064705ad60c3eb043693189a167344108643 Author: David Carlier Date: Fri Mar 13 05:17:55 2026 +0000 selftests/sched_ext: Add missing error check for exit__load() [ Upstream commit 1d02346fec8d13b05e54296ddc6ae29b7e1067df ] exit__load(skel) was called without checking its return value. Every other test in the suite wraps the load call with SCX_FAIL_IF(). Add the missing check to be consistent with the rest of the test suite. Fixes: a5db7817af78 ("sched_ext: Add selftests") Signed-off-by: David Carlier Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 75849e13e428ec5680cef65a2dcef21099f96acd Author: Lijo Lazar Date: Mon Mar 9 15:17:00 2026 +0530 drm/amd/pm: Fix xgmi max speed reporting [ Upstream commit da16822ce5c32b5aca848eaea521936d4410d48c ] Fix XGMI max bitrate/width reporting on SMUv13.0.12 SOCs. The data format got changed when moved to static table from dynamic metrics table. Fixes: 1bec2f270766 ("drm/amd/pm: Fetch SMUv13.0.12 xgmi max speed/width") Signed-off-by: Lijo Lazar Reviewed-by: Asad Kamal Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9b614ddf3185976df3791782c793b4fad3cf0de2 Author: Vladimir Zapolskiy Date: Thu Feb 26 15:37:34 2026 +0200 media: i2c: og01a1b: Fix V4L2 subdevice data initialization on probe [ Upstream commit 535b7f106991c7d8f0e5b8e1769bfb8b1ce9d3d6 ] It's necessary to finalize the camera sensor subdevice initialization on driver probe and clean V4L2 subdevice data up on error paths and driver removal. The change fixes a previously reported by v4l2-compliance issue of the failed VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT test: fail: v4l2-test-controls.cpp(1104): subscribe event for control 'User Controls' failed Fixes: 472377febf84 ("media: Add a driver for the og01a1b camera sensor") Signed-off-by: Vladimir Zapolskiy Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 1de12fc4b943e19f849cb929b5d540d4fea05732 Author: Felix Gu Date: Wed Mar 4 20:47:21 2026 +0800 spi: fsl-qspi: Use reinit_completion() for repeated operations [ Upstream commit 981b080a79724738882b0af1c5bb7ade30d94f24 ] The driver currently calls init_completion() during every spi_mem_op. Tchnically it may work, but it's not the recommended pattern. According to the kernel documentation: Calling init_completion() on the same completion object twice is most likely a bug as it re-initializes the queue to an empty queue and enqueued tasks could get "lost" - use reinit_completion() in that case, but be aware of other races. So moves the initial initialization to probe function and uses reinit_completion() for subsequent operations. Fixes: 84d043185dbe ("spi: Add a driver for the Freescale/NXP QuadSPI controller") Signed-off-by: Felix Gu Reviewed-by: Haibo Chen Link: https://patch.msgid.link/20260304-spi-nxp-v2-3-cd7d7726a27e@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c1c2871f33360830b7086634bdb3c136274d1e7d Author: Felix Gu Date: Wed Mar 4 20:47:20 2026 +0800 spi: nxp-fspi: Use reinit_completion() for repeated operations [ Upstream commit 68c8c93fdb0de7e528dc3dfb1d17eb0f652259b8 ] The driver currently calls init_completion() during every spi_mem_op. Tchnically it may work, but it's not the recommended pattern. According to the kernel documentation: Calling init_completion() on the same completion object twice is most likely a bug as it re-initializes the queue to an empty queue and enqueued tasks could get "lost" - use reinit_completion() in that case, but be aware of other races. So moves the initial initialization to probe function and uses reinit_completion() for subsequent operations. Fixes: a5356aef6a90 ("spi: spi-mem: Add driver for NXP FlexSPI controller") Signed-off-by: Felix Gu Reviewed-by: Haibo Chen Link: https://patch.msgid.link/20260304-spi-nxp-v2-2-cd7d7726a27e@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d7b0489d995596d7a51854bbbfa1af5561b2ef21 Author: Harikrishna Shenoy Date: Tue Dec 9 17:33:29 2025 +0530 drm/bridge: cadence: cdns-mhdp8546-core: Handle HDCP state in bridge atomic check [ Upstream commit 4a8edd658489ec2a3d7e20482fa9e8d366153d8d ] Now that we have DRM_BRIDGE_ATTACH_NO_CONNECTOR framework, handle the HDCP state change in bridge atomic check as well to enable correct functioning for HDCP in both DRM_BRIDGE_ATTACH_NO_CONNECTOR and !DRM_BRIDGE_ATTACH_NO_CONNECTOR case. Without this patch, when using DRM_BRIDGE_ATTACH_NO_CONNECTOR flag, HDCP state changes would not be properly handled during atomic commits, potentially leading to HDCP authentication failures or incorrect protection status for content requiring HDCP encryption. Fixes: 6a3608eae6d33 ("drm: bridge: cdns-mhdp8546: Enable HDCP") Signed-off-by: Harikrishna Shenoy Reviewed-by: Luca Ceresoli Reviewed-by: Tomi Valkeinen Link: https://patch.msgid.link/20251209120332.3559893-4-h-shenoy@ti.com Signed-off-by: Luca Ceresoli Signed-off-by: Sasha Levin commit 1a9bef10f894b088cb488517bdfcd539ffa00098 Author: Jayesh Choudhary Date: Tue Dec 9 17:33:28 2025 +0530 drm/bridge: cadence: cdns-mhdp8546-core: Add mode_valid hook to drm_bridge_funcs [ Upstream commit 6dbff34016052b099558b76632e4983e2df13fed ] Add cdns_mhdp_bridge_mode_valid() to check if specific mode is valid for this bridge or not. In the legacy usecase with !DRM_BRIDGE_ATTACH_NO_CONNECTOR we were using the hook from drm_connector_helper_funcs but with DRM_BRIDGE_ATTACH_NO_CONNECTOR we need to have mode_valid() in drm_bridge_funcs. Without this patch, when using DRM_BRIDGE_ATTACH_NO_CONNECTOR flag, the cdns_mhdp_bandwidth_ok() function would not be called during mode validation, potentially allowing modes that exceed the bridge's bandwidth capabilities to be incorrectly marked as valid. Fixes: c932ced6b585 ("drm/tidss: Update encoder/bridge chain connect model") Reviewed-by: Tomi Valkeinen Signed-off-by: Jayesh Choudhary Signed-off-by: Harikrishna Shenoy Reviewed-by: Luca Ceresoli Link: https://patch.msgid.link/20251209120332.3559893-3-h-shenoy@ti.com Signed-off-by: Luca Ceresoli Signed-off-by: Sasha Levin commit cf2ac2cac8b319f89b3a3851ca0c5ffb6a549575 Author: Jayesh Choudhary Date: Tue Dec 9 17:33:27 2025 +0530 drm/bridge: cadence: cdns-mhdp8546-core: Set the mhdp connector earlier in atomic_enable() [ Upstream commit 43d6508ddbf9fb974fbc359a033154f78c9d4c8b ] In case if we get errors in cdns_mhdp_link_up() or cdns_mhdp_reg_read() in atomic_enable, we will go to cdns_mhdp_modeset_retry_fn() and will hit NULL pointer while trying to access the mutex. We need the connector to be set before that. Unlike in legacy cases with flag !DRM_BRIDGE_ATTACH_NO_CONNECTOR, we do not have connector initialised in bridge_attach(), so add the mhdp->connector_ptr in device structure to handle both cases with DRM_BRIDGE_ATTACH_NO_CONNECTOR and !DRM_BRIDGE_ATTACH_NO_CONNECTOR, set it in atomic_enable() earlier to avoid possible NULL pointer dereference in recovery paths like modeset_retry_fn() with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag set. Fixes: c932ced6b585 ("drm/tidss: Update encoder/bridge chain connect model") Signed-off-by: Jayesh Choudhary Signed-off-by: Harikrishna Shenoy Reviewed-by: Luca Ceresoli Reviewed-by: Tomi Valkeinen Link: https://patch.msgid.link/20251209120332.3559893-2-h-shenoy@ti.com Signed-off-by: Luca Ceresoli Signed-off-by: Sasha Levin commit 3149c4f7f26fe2b1373e630758844111969730d5 Author: Randy Dunlap Date: Fri Mar 6 14:10:32 2026 -0800 iopoll: fix function parameter names in read_poll_timeout_atomic() [ Upstream commit 878004e2852bc22ce0687c5597d6fe3909fb59f3 ] Correct the function parameter names to avoid kernel-doc warnings and to emphasize this function is atomic (non-sleeping). Warning: include/linux/iopoll.h:169 function parameter 'sleep_us' not described in 'read_poll_timeout_atomic' Warning: ../include/linux/iopoll.h:169 function parameter 'sleep_before_read' not described in 'read_poll_timeout_atomic' Fixes: 9df8043a546d ("iopoll: Generalize read_poll_timeout() into poll_timeout_us()") Signed-off-by: Randy Dunlap Reviewed-by: Jani Nikula Link: https://patch.msgid.link/20260306221033.2357305-1-rdunlap@infradead.org Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit b455903eed4558982be0811f5b7f44f6bbc4ff57 Author: Junrui Luo Date: Thu Mar 5 20:05:48 2026 +0800 dm log: fix out-of-bounds write due to region_count overflow [ Upstream commit c20e36b7631d83e7535877f08af8b0af72c44b1a ] The local variable region_count in create_log_context() is declared as unsigned int (32-bit), but dm_sector_div_up() returns sector_t (64-bit). When a device-mapper target has a sufficiently large ti->len with a small region_size, the division result can exceed UINT_MAX. The truncated value is then used to calculate bitset_size, causing clean_bits, sync_bits, and recovering_bits to be allocated far smaller than needed for the actual number of regions. Subsequent log operations (log_set_bit, log_clear_bit, log_test_bit) use region indices derived from the full untruncated region space, causing out-of-bounds writes to kernel heap memory allocated by vmalloc. This can be reproduced by creating a mirror target whose region_count overflows 32 bits: dmsetup create bigzero --table '0 8589934594 zero' dmsetup create mymirror --table '0 8589934594 mirror \ core 2 2 nosync 2 /dev/mapper/bigzero 0 \ /dev/mapper/bigzero 0' The status output confirms the truncation (sync_count=1 instead of 4294967297, because 0x100000001 was truncated to 1): $ dmsetup status mymirror 0 8589934594 mirror 2 254:1 254:1 1/4294967297 ... This leads to a kernel crash in core_in_sync: BUG: scheduling while atomic: (udev-worker)/9150/0x00000000 RIP: 0010:core_in_sync+0x14/0x30 [dm_log] CR2: 0000000000000008 Fixing recursive fault but reboot is needed! Fix by widening the local region_count to sector_t and adding an explicit overflow check before the value is assigned to lc->region_count. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Yuhao Jiang Signed-off-by: Junrui Luo Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 322a3b70368d49e39591fe9fc6c07d262128b05f Author: Ming-Hung Tsai Date: Wed Mar 4 19:56:28 2026 +0800 dm cache metadata: fix memory leak on metadata abort retry [ Upstream commit 044ca491d4086dc5bf233e9fcb71db52df32f633 ] When failing to acquire the root_lock in dm_cache_metadata_abort because the block_manager is read-only, the temporary block_manager created outside the root_lock is not properly released, causing a memory leak. Reproduce steps: This can be reproduced by reloading a new table while the metadata is read-only. While the second call to dm_cache_metadata_abort is caused by lack of support for table preload in dm-cache, mentioned in commit 9b1cc9f251af ("dm cache: share cache-metadata object across inactive and active DM tables"), it exposes the memory leak in dm_cache_metadata_abort when the function is called multiple times. Specifically, dm-cache fails to sync the new cache object's mode during preresume, creating the reproducer condition. This issue could also occur through concurrent metadata_operation_failed calls due to races in cache mode updates, but the table preload scenario below provides a reliable reproducer. 1. Create a cache device with some faulty trailing metadata blocks dmsetup create cmeta < unreferenced object 0xffff8880080c2010 (size 16): comm "dmsetup", pid 132, jiffies 4294982580 hex dump (first 16 bytes): 00 38 b9 07 80 88 ff ff 6a 6b 6b 6b 6b 6b 6b a5 ... backtrace (crc 3118f31c): kmemleak_alloc+0x28/0x40 __kmalloc_cache_noprof+0x3d9/0x510 dm_block_manager_create+0x51/0x140 dm_cache_metadata_abort+0x85/0x320 metadata_operation_failed+0x103/0x1e0 cache_preresume+0xacd/0xe70 dm_table_resume_targets+0xd3/0x320 __dm_resume+0x1b/0xf0 dm_resume+0x127/0x170 Fixes: 352b837a5541 ("dm cache: Fix ABBA deadlock between shrink_slab and dm_cache_metadata_abort") Signed-off-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit a3c61bd4e9438a7928bf111c33c2a41cb7d3bce3 Author: Manivannan Sadhasivam Date: Thu Feb 26 19:09:51 2026 +0530 PCI: dwc: Perform cleanup in the error path of dw_pcie_resume_noirq() [ Upstream commit edb5ca3262e2255cf938a5948709d3472d4871ad ] If the dw_pcie_resume_noirq() API fails, it just returns the errno without doing cleanup in the error path, leading to resource leak. So perform cleanup in the error path. Fixes: 4774faf854f5 ("PCI: dwc: Implement generic suspend/resume functionality") Reported-by: Senchuan Zhang Closes: https://lore.kernel.org/linux-pci/78296255.3869.19c8eb694d6.Coremail.zhangsenchuan@eswincomputing.com Signed-off-by: Manivannan Sadhasivam Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260226133951.296743-1-mani@kernel.org Signed-off-by: Sasha Levin commit 104a6e53484e565f06b29e32aa32415f1facc80a Author: Richard Zhu Date: Wed Oct 15 11:04:25 2025 +0800 PCI: dwc: Invoke post_init in dw_pcie_resume_noirq() [ Upstream commit c577ce2881f9c76892de5ffc1a122e3ef427ecee ] In some SoCs like i.MX95, CLKREQ# is pulled low by the controller driver before link up. After link up, if the 'supports-clkreq' property is specified in DT, the driver will release CLKREQ# so that it can go high and the endpoint can pull it low whenever required i.e., during exit from L1 Substates. Hence, at the end of dw_pcie_resume_noirq(), invoke the '.post_init()' callback if exists to perform the above mentioned action. Signed-off-by: Richard Zhu [mani: reworded description] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Frank Li Link: https://patch.msgid.link/20251015030428.2980427-9-hongxing.zhu@nxp.com Stable-dep-of: edb5ca3262e2 ("PCI: dwc: Perform cleanup in the error path of dw_pcie_resume_noirq()") Signed-off-by: Sasha Levin commit a763a53d648def463e08b418f3d3609403b4f6ce Author: Aksh Garg Date: Tue Feb 24 14:08:16 2026 +0530 PCI: dwc: ep: Fix MSI-X Table Size configuration in dw_pcie_ep_set_msix() [ Upstream commit 271d0b1f058ae9815e75233d04b23e3558c3e4f4 ] In dw_pcie_ep_set_msix(), while updating the MSI-X Table Size value for individual functions, Message Control register is read from the passed function number register space using dw_pcie_ep_readw_dbi(), but always written back to the Function 0's register space using dw_pcie_writew_dbi(). This causes incorrect MSI-X configuration for the rest of the functions, other than Function 0. Fix this by using dw_pcie_ep_writew_dbi() to write to the correct function's register space, matching the read operation. Fixes: 70fa02ca1446 ("PCI: dwc: Add dw_pcie_ep_{read,write}_dbi[2] helpers") Signed-off-by: Aksh Garg [mani: commit log] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Niklas Cassel Link: https://patch.msgid.link/20260224083817.916782-2-a-garg7@ti.com Signed-off-by: Sasha Levin commit b7ed10f2d8b538e0a81ca840f826fd4b8774f126 Author: Rafael J. Wysocki Date: Thu Mar 5 20:47:03 2026 +0100 platform/chrome: chromeos_tbmc: Drop wakeup source on remove [ Upstream commit 5d441a4bc93642ed6f41da87327a39946b4e1455 ] The wakeup source added by device_init_wakeup() in chromeos_tbmc_add() needs to be dropped during driver removal, so add a .remove() callback to the driver for this purpose. Fixes: 0144c00ed86b ("platform/chrome: chromeos_tbmc: Report wake events") Signed-off-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/6151957.MhkbZ0Pkbq@rafael.j.wysocki Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin commit 7f3e53990ad3bf3a09107d368bfbf956c70fe058 Author: Benjamin Marzinski Date: Thu Feb 12 13:05:41 2026 -0500 dm-mpath: don't stop probing paths at presuspend [ Upstream commit 51d81e14fe6788dc6463064c7517480f2acd2724 ] Commit 5c977f102315 ("dm-mpath: Don't grab work_mutex while probing paths"), added code to make multipath quit probing paths early, if it was trying to suspend. This isn't necessary. It was just an optimization to try to keep path probing from delaying a suspend. However it causes problems with the intended user of this code, qemu. The path probing code was added because failed ioctls to multipath devices don't cause paths to fail in cases where a regular IO failure would. If an ioctl to a path failed because the path was down, and the multipath device had passed presuspend, the M_MPATH_PROBE_PATHS ioctl would exit early, without probing the path. The caller would then retry the original ioctl, hoping to use a different path. But if there was only one path in the pathgroup, it would pick the same non-working path again, even if there were working paths in other pathgroups. ioctls to a suspended dm device will return -EAGAIN, notifying the caller that the device is suspended, but ioctls to a device that is just preparing to suspend won't (and in general, shouldn't). This means that the caller (qemu in this case) would get into a tight loop where it would issue an ioctl that failed, skip probing the paths because the device had already passed presuspend, and start over issuing the ioctl again. This would continue until the multipath device finally fully suspended, or the caller gave up and failed the ioctl. multipath's path probing code could return -EAGAIN in this case, and the caller could delay a bit before retrying, but the whole purpose of skipping the probe after presuspend was to speed things up, and that would just slow them down. Instead, remove the is_suspending flag, and check dm_suspended() instead to decide whether to exit the probing code early. This means that when the probing code exits early, future ioctls will also be delayed, because the device is fully suspended. Fixes: 5c977f102315 ("dm-mpath: Don't grab work_mutex while probing paths") Signed-off-by: Benjamin Marzinski Reviewed-by: Martin Wilck Reviewed-by: Hanna Czenczek Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 21c503d60a257e54ca3ac58e2721bd24501d5bde Author: Ming-Hung Tsai Date: Mon Feb 9 15:54:10 2026 +0800 dm cache: fix dirty mapping checking in passthrough mode switching [ Upstream commit 322586745bd1a0e5f3559fd1635fdeb4dbd1d6b8 ] As mentioned in commit 9b1cc9f251af ("dm cache: share cache-metadata object across inactive and active DM tables"), dm-cache assumed table reload occurs after suspension, while LVM's table preload breaks this assumption. The dirty mapping check for passthrough mode was designed around this assumption and is performed during table creation, causing the check to fail with preload while metadata updates are ongoing. This risks loading dirty mappings into passthrough mode, resulting in data loss. Reproduce steps: 1. Create a writeback cache with zero migration_threshold to produce dirty mappings dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writeback smq \ 2 migration_threshold 0" 2. Preload a table in passthrough mode dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" 3. Write to the first cache block to make it dirty fio --filename=/dev/mapper/cache --name=populate --rw=write --bs=4k \ --direct=1 --size=64k 4. Resume the inactive table. Now it's possible to load the dirty block into passthrough mode. dmsetup resume cache Fix by moving the checks to the preresume phase to support table preloading. Also remove the unused function dm_cache_metadata_all_clean. Fixes: 2ee57d587357 ("dm cache: add passthrough mode") Signed-off-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit cb8b250b427782b1ec16dd5b2201dcf139ee9512 Author: Ming-Hung Tsai Date: Mon Feb 9 15:54:09 2026 +0800 dm cache: fix concurrent write failure in passthrough mode [ Upstream commit e4f66341779d0cf4c83c74793753a84094286d9e ] When bio prison cell lock acquisition fails due to concurrent writes to the same block in passthrough mode, dm-cache incorrectly returns an I/O error instead of properly handling the concurrency. This can occur in both process and workqueue contexts when invalidate_lock() is called for exclusive access to a data block. Fix this by deferring the write bios to ensure proper block device behavior. Reproduce steps: 1. Create a cache device dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. Promote the first data block into cache fio --filename=/dev/mapper/cache --name=populate --rw=write --bs=4k \ --direct=1 --size=64k 3. Reload the cache into passthrough mode dmsetup suspend cache dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" dmsetup resume cache 4. Write to the first cached block concurrently. Sometimes one of the processes will receive I/O errors. fio --filename=/dev/mapper/cache --name test --rw=randwrite --bs=4k \ --randrepeat=0 --direct=1 --numjobs=2 --size 64k fio-3.41 fio: io_u error on file /dev/mapper/cache: Input/output error: write offset=4096, buflen=4096 fio: pid=106, err=5/file:io_u.c:2008, func=io_u error, error=Input/output error test: (groupid=0, jobs=1): err= 0: pid=105 test: (groupid=0, jobs=1): err= 5 (file:io_u.c:2008, func=io_u error, error=Input/output error): pid=106 Fixes: b29d4986d0da ("dm cache: significant rework to leverage dm-bio-prison-v2") Signed-off-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit c348ae47d8e65f06429fa41adce9ad986b696766 Author: Ming-Hung Tsai Date: Mon Feb 9 15:54:08 2026 +0800 dm cache policy smq: fix missing locks in invalidating cache blocks [ Upstream commit 2d1f7b65f5deedd2e6b09fdc6ea27f8375f24b45 ] In passthrough mode, the policy invalidate_mapping operation is called simultaneously from multiple workers, thus it should be protected by a lock. Otherwise, we might end up with data races on the allocated blocks counter, or even use-after-free issues with internal data structures when doing concurrent writes. Note that the existing FIXME in smq_invalidate_mapping() doesn't affect passthrough mode since migration tasks don't exist there, but would need attention if supporting fast device shrinking via suspend/resume without target reloading. Reproduce steps: 1. Create a cache device consisting of 1024 cache entries dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. Populate the cache, and record the number of cached blocks fio --name=populate --filename=/dev/mapper/cache --rw=randwrite --bs=4k \ --size=64m --direct=1 nr_cached=$(dmsetup status cache | awk '{split($7, a, "/"); print a[1]}') 3. Reload the cache into passthrough mode dmsetup suspend cache dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" dmsetup resume cache 4. Write to the passthrough cache. By setting multiple jobs with I/O size equal to the cache block size, cache blocks are invalidated concurrently from different workers. fio --filename=/dev/mapper/cache --name=test --rw=randwrite --bs=64k \ --direct=1 --numjobs=2 --randrepeat=0 --size=64m 5. Check if demoted matches cached block count. These numbers should match but may differ due to the data race. nr_demoted=$(dmsetup status cache | awk '{print $12}') echo "$nr_cached, $nr_demoted" Fixes: b29d4986d0da ("dm cache: significant rework to leverage dm-bio-prison-v2") Signed-off-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit b8ace9e96983abb20ccf39edce8a60f1bb0b83d8 Author: Ming-Hung Tsai Date: Mon Feb 9 15:54:07 2026 +0800 dm cache: fix write hang in passthrough mode [ Upstream commit 4ca8b8bd952df7c3ccdc68af9bd3419d0839a04b ] The invalidate_remove() function has incomplete logic for handling write hit bios after cache invalidation. It sets up the remapping for the overwrite_bio but then drops it immediately without submission, causing write operations to hang. Fix by adding a new invalidate_committed() continuation that submits the remapped writes to the cache origin after metadata commit completes, while using the overwrite_endio hook to ensure proper completion sequencing. This maintains existing coherency. Also improve error handling in invalidate_complete() to preserve the original error status instead of using bio_io_error() unconditionally. Fixes: b29d4986d0da ("dm cache: significant rework to leverage dm-bio-prison-v2") Signed-off-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 788ac6c94d04d966f903a91c64767013514945ff Author: Ming-Hung Tsai Date: Mon Feb 9 15:54:06 2026 +0800 dm cache: fix write path cache coherency in passthrough mode [ Upstream commit 0c5eef0aad508231d8e43ff8392692925e131b68 ] In passthrough mode, dm-cache defers write bio submission until cache invalidation completes to maintain existing coherency, requiring the target map function to return DM_MAPIO_SUBMITTED. The current map_bio() returns DM_MAPIO_REMAPPED, violating the required ordering constraint. Reproduce steps: 1. Create a cache device dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. Promote the first data block into the cache fio --filename=/dev/mapper/cache --name=populate --rw=write --bs=4k \ --direct=1 --size=64k 3. Reload the cache into passthrough mode dmsetup suspend cache dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" dmsetup resume cache 4. Write to the first data block, and check io ordering using ftrace echo 1 > /sys/kernel/debug/tracing/events/block/block_bio_queue/enable echo 1 > /sys/kernel/debug/tracing/events/block/block_bio_complete/enable echo 1 > /sys/kernel/debug/tracing/events/block/block_rq_complete/enable fio --filename=/dev/mapper/cache --name=test --rw=write --bs=64k \ --direct=1 --size 64k 5. ftrace logs show that write operations to the cache origin (252:2) and metadata operations (252:0) are unsynchronized: the origin write occurs before metadata commit. fio-146 [000] ..... 420.139562: block_bio_queue: 252,3 WS 0 + 128 [fio] fio-146 [000] ..... 420.149395: block_bio_queue: 252,2 WS 0 + 128 [fio] fio-146 [000] ..... 420.149763: block_bio_queue: 8,32 WS 262144 + 128 [fio] fio-146 [000] dNh1. 420.151446: block_rq_complete: 8,32 WS () 262144 + 128 be,0,4 [0] fio-146 [000] dNh1. 420.152731: block_bio_complete: 252,2 WS 0 + 128 [0] fio-146 [000] dNh1. 420.154229: block_bio_complete: 252,3 WS 0 + 128 [0] kworker/0:0-9 [000] ..... 420.160530: block_bio_queue: 252,0 W 408 + 8 [kworker/0:0] kworker/0:0-9 [000] ..... 420.161641: block_bio_queue: 8,32 W 408 + 8 [kworker/0:0] kworker/0:0-9 [000] ..... 420.162533: block_bio_queue: 252,0 W 416 + 8 [kworker/0:0] kworker/0:0-9 [000] ..... 420.162821: block_bio_queue: 8,32 W 416 + 8 [kworker/0:0] Fixes: b29d4986d0da ("dm cache: significant rework to leverage dm-bio-prison-v2") Signed-off-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 25dcc1989c194ba2b5fb6d03cbb9b83814ac0d15 Author: Ming-Hung Tsai Date: Mon Feb 9 15:54:05 2026 +0800 dm cache: fix null-deref with concurrent writes in passthrough mode [ Upstream commit 7d1f98d668ee34c1d15bdc0420fdd062f24a27c0 ] In passthrough mode, when dm-cache starts to invalidate a cache entry and bio prison cell lock fails due to concurrent write to the same cached block, mg->cell remains NULL. The error path in invalidate_complete() attempts to unlock and free the cell unconditionally, causing a NULL pointer dereference: KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 UID: 0 PID: 134 Comm: fio Not tainted 6.19.0-rc7 #3 PREEMPT RIP: 0010:dm_cell_unlock_v2+0x3f/0x210 Call Trace: invalidate_complete+0xef/0x430 map_bio+0x130f/0x1a10 cache_map+0x320/0x6b0 __map_bio+0x458/0x510 dm_submit_bio+0x40e/0x16d0 __submit_bio+0x419/0x870 Reproduce steps: 1. Create a cache device dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. Promote the first data block into cache fio --filename=/dev/mapper/cache --name=populate --rw=write --bs=4k \ --direct=1 --size=64k 3. Reload the cache into passthrough mode dmsetup suspend cache dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" dmsetup resume cache 4. Write to the first cached block concurrently fio --filename=/dev/mapper/cache --name test --rw=randwrite --bs=4k \ --randrepeat=0 --direct=1 --numjobs=2 --size 64k Fix by checking if mg->cell is valid before attempting to unlock it. Fixes: b29d4986d0da ("dm cache: significant rework to leverage dm-bio-prison-v2") Signed-off-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit a3f3c332882c98ae7553af372191116d1384ca52 Author: Sander Vanheule Date: Fri Feb 20 16:26:34 2026 +0100 ASoC: sti: use managed regmap_field allocations [ Upstream commit 1696fad8b259a2d46e51cd6e17e4bcdbe02279fa ] The regmap_field objects allocated at player init are never freed and may leak resources if the driver is removed. Switch to devm_regmap_field_alloc() to automatically limit the lifetime of the allocations the lifetime of the device. Fixes: 76c2145ded6b ("ASoC: sti: Add CPU DAI driver for playback") Signed-off-by: Sander Vanheule Link: https://patch.msgid.link/20260220152634.480766-3-sander@svanheule.net Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 17584bdc724780f4ddc8689f776c420ebd0dc480 Author: Sander Vanheule Date: Fri Feb 20 16:26:33 2026 +0100 ASoC: sti: Return errors from regmap_field_alloc() [ Upstream commit 272aabef50bc3fe58edd26de000f4cdd41bdbe60 ] When regmap_field_alloc() fails, it can return an error. Specifically, it will return PTR_ERR(-ENOMEM) when the allocation returns a NULL pointer. The code then uses these allocations with a simple NULL check: if (player->clk_sel) { // May dereference invalid pointer (-ENOMEM) err = regmap_field_write(player->clk_sel, ...); } Ensure initialization fails by forwarding the errors from regmap_field_alloc(), thus avoiding the use of the invalid pointers. Fixes: 76c2145ded6b ("ASoC: sti: Add CPU DAI driver for playback") Signed-off-by: Sander Vanheule Link: https://patch.msgid.link/20260220152634.480766-2-sander@svanheule.net Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7ed07c9ce5252f841bc38077389b428b16ab0f56 Author: Aleksander Jan Bajkowski Date: Sun Feb 8 11:35:53 2026 +0100 crypto: inside-secure/eip93 - fix register definition [ Upstream commit b7abbc8c7acaeb60c114b038f1fa91bbedb3d16a ] Checked the register definitions with the documentation[1]. Turns out that the PKTE_INBUF_CNT register has a bad offset. It's used in Direct Host Mode (DHM). The driver uses Autonomous Ring Mode (ARM), so it causes no harm. 1. ADSP-SC58x/ADSP-2158x SHARC+ Processor Hardware Reference 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 1f2e41bd668f8f55871555d28763802aaf22143e Author: Charles Keepax Date: Wed Feb 25 14:01:16 2026 +0000 ASoC: SDCA: Update counting of SU/GE DAPM routes [ Upstream commit 1fb720d33eecdb9a90ee340b3000ba378d49f5ca ] Device Layer Selector Unit's are controlled by a Group Entity control rather than by the host directly. For the purposes of the ASoC class driver the number of input routes to the SU is controlled by the number of options within the Group Entity Selected Mode Control. ie. One valid DAPM route for each valid route defined in the Group Entity. Currently the code assumes that a Device Layer SU will have a number of routes equal to the number of potential sources for the SU. ie. it counts the routes using the SU, but then creates the routes using the GE. However, this isn't actually true, it is perfectly allowed for the GE to only define options for some of the potential sources of the SU.o In such a case the number of routes return will not match those created, leading to either an overflow of the routes array or undefined routes to be past to the ASoC core, both of which generally lead to the sound card failing to probe. Update the handling for the counting of routes to count the connected routes on the GE itself and then ignore the source routes on the SU. This makes it match the logic generating the routes and ensuring that both remain in sync. Fixes: 2c8b3a8e6aa8 ("ASoC: SDCA: Create DAPM widgets and routes from DisCo") Reviewed-by: Pierre-Louis Bossart Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20260225140118.402695-3-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 36a0dcd0077b879e14c0a473d24a4d393000281d Author: Felix Gu Date: Sat Jan 24 23:42:45 2026 +0800 PCI: imx6: Fix device node reference leak in imx_pcie_probe() [ Upstream commit 3b55079d6387805ede687e234d84669aeb0f7e98 ] In imx_pcie_probe(), of_parse_phandle() returns the device node pointer with increased refcount. The pointer reference must be dropped by the caller when it's no longer needed. However, imx_pcie_probe() doesn't drop the reference, causing reference leak. Fix this by using the __free(device_node) cleanup handler to drop the reference when the function goes out of scope. Fixes: 1df82ec46600 ("PCI: imx: Add workaround for e10728, IMX7d PCIe PLL failure") Signed-off-by: Felix Gu [mani: commit log] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Frank Li Acked-by: Richard Zhu Link: https://patch.msgid.link/20260124-pci_imx6-v2-1-acb8d5187683@gmail.com Signed-off-by: Sasha Levin commit 47038159c559824f4dbfb5b0d87b9b3416663372 Author: Ethan Tidmore Date: Mon Feb 16 19:48:01 2026 -0600 drm/sun4i: backend: fix error pointer dereference [ Upstream commit 06277983eca4a31d3c2114fa33d99a6e82484b11 ] The function drm_atomic_get_plane_state() can return an error pointer and is not checked for it. Add error pointer check. Detected by Smatch: drivers/gpu/drm/sun4i/sun4i_backend.c:496 sun4i_backend_atomic_check() error: 'plane_state' dereferencing possible ERR_PTR() Fixes: 96180dde23b79 ("drm/sun4i: backend: Add a custom atomic_check for the frontend") Signed-off-by: Ethan Tidmore Reviewed-by: Chen-Yu Tsai Link: https://patch.msgid.link/20260217014801.60760-1-ethantidmore06@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 175717cfc06cab79f84cd037d66dda1b8564cd9e Author: Koichiro Den Date: Tue Feb 17 15:38:56 2026 +0900 PCI: endpoint: pci-ep-msi: Fix error unwind and prevent double alloc [ Upstream commit 1cba96c0a795124c3229293ed7b5b5765e66f259 ] pci_epf_alloc_doorbell() stores the allocated doorbell message array in epf->db_msg/epf->num_db before requesting MSI vectors. If MSI allocation fails, the array is freed but the EPF state may still point to freed memory. Clear epf->db_msg and epf->num_db on the MSI allocation failure path so that later cleanup cannot double-free the array and callers can retry allocation. Also return -EBUSY when doorbells have already been allocated to prevent leaking or overwriting an existing allocation. Fixes: 1c3b002c6bf6 ("PCI: endpoint: Add RC-to-EP doorbell support using platform MSI controller") Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Reviewed-by: Frank Li Reviewed-by: Niklas Cassel Link: https://patch.msgid.link/20260217063856.3759713-4-den@valinux.co.jp Signed-off-by: Sasha Levin commit b13984f0212f2ead9963de18de7f15516df7590a Author: Koichiro Den Date: Tue Feb 17 15:38:55 2026 +0900 PCI: endpoint: pci-epf-test: Don't free doorbell IRQ unless requested [ Upstream commit e81fa70179aac6ac3a6636565d5d35968dca3900 ] pci_epf_test_doorbell_cleanup() unconditionally calls free_irq() for the doorbell virq, which can trigger "Trying to free already-free IRQ" warnings when the IRQ was never requested or when request_threaded_irq() failed. Move free_irq() out of pci_epf_test_doorbell_cleanup() and invoke it only after a successful request, so that free_irq() is not called for an unrequested IRQ. Fixes: eff0c286aa91 ("PCI: endpoint: pci-epf-test: Add doorbell test support") Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Reviewed-by: Frank Li Reviewed-by: Niklas Cassel Link: https://patch.msgid.link/20260217063856.3759713-3-den@valinux.co.jp Signed-off-by: Sasha Levin commit 511c093d9ef4b7002ed1be6d1f0a5732b4335bd6 Author: George Abraham P Date: Fri Jan 9 10:59:23 2026 +0530 PCI/TPH: Allow TPH enable for RCiEPs [ Upstream commit d3e996a596967a62c8a13a279221513461f6ab97 ] Previously, pcie_enable_tph() only enabled TLP Processing Hints (TPH) if both the Endpoint and its Root Port advertised TPH support. Root Complex Integrated Endpoints (RCiEPs) are directly integrated into a Root Complex and do not have an associated Root Port, so pcie_enable_tph() never enabled TPH for RCiEPs. PCIe r7.0 doesn't seem to include a way to learn whether a Root Complex supports TPH, but sec 2.2.7.1.1 says Functions that lack TPH support should ignore TPH, and maybe the same is true for Root Complexes: A Function that does not support the TPH Completer or Routing capability and receives a transaction with the TH bit [which indicates the presence of TPH in the TLP header] Set is required to ignore the TH bit and handle the Request in the same way as Requests of the same transaction type without the TH bit Set. Allow drivers to enable TPH for any RCiEP with a TPH Requester Capability. Fixes: f69767a1ada3 ("PCI: Add TLP Processing Hints (TPH) support") Signed-off-by: George Abraham P [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260109052923.1170070-1-george.abraham.p@intel.com Signed-off-by: Sasha Levin commit e14de2cb819ffd210bb78943e3e0082e93f29dc7 Author: Kuninori Morimoto Date: Thu Feb 19 04:53:52 2026 +0000 ASoC: soc-compress: use function to clear symmetric params [ Upstream commit 07c774dd64ba0c605dbf844132122e3edbdbea93 ] Current soc-compress.c clears symmetric_rate, but it clears rate only, not clear other symmetric_channels/sample_bits. static int soc_compr_clean(...) { ... if (!snd_soc_dai_active(cpu_dai)) => cpu_dai->symmetric_rate = 0; if (!snd_soc_dai_active(codec_dai)) => codec_dai->symmetric_rate = 0; ... }; This feature was added when v3.7 kernel [1], and there was only symmetric_rate, no symmetric_channels/sample_bits in that timing. symmetric_channels/sample_bits were added in v3.14 [2], but I guess it didn't notice that soc-compress.c is updating symmetric_xxx. We are clearing symmetry_xxx by soc_pcm_set_dai_params(), but is soc-pcm.c local function. Makes it global function and clear symmetry_xxx by it. [1] commit 1245b7005de02 ("ASoC: add compress stream support") [2] commit 3635bf09a89cf ("ASoC: soc-pcm: add symmetry for channels and sample bits") Fixes: 3635bf09a89c ("ASoC: soc-pcm: add symmetry for channels and sample bits") Cc: Nicolin Chen Signed-off-by: Kuninori Morimoto Link: https://patch.msgid.link/87ms15e3kv.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1f7687123d38f9494f7c2e41c80b957d618e9ed3 Author: Val Packett Date: Wed Dec 10 12:39:23 2025 -0300 drm/virtio: Allow importing prime buffers when 3D is enabled [ Upstream commit df4dc947c46bb9f80038f52c6e38cb2d40c10e50 ] This functionality was added for using a KMS-only virtgpu with a physical (or SR-IOV) headless GPU in passthrough, but it should not be restricted to KMS-only mode. It can be used with cross-domain to pass guest memfds to the host compositor with zero copies (using udmabuf on both sides). Drop the check for the absence of virgl_3d to allow for more use cases. Fixes: ca77f27a2665 ("drm/virtio: Import prime buffers from other devices as guest blobs") Signed-off-by: Val Packett Reviewed-by: Dmitry Osipenko Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/20251210154755.1119861-2-val@invisiblethingslab.com Signed-off-by: Sasha Levin commit fe1f80f8f6e8611ac6349b9d464e8750443390cf Author: Alexander Konyukhov Date: Tue Feb 3 16:48:46 2026 +0300 drm/komeda: fix integer overflow in AFBC framebuffer size check [ Upstream commit 779ec12c85c9e4547519e3903a371a3b26a289de ] The AFBC framebuffer size validation calculates the minimum required buffer size by adding the AFBC payload size to the framebuffer offset. This addition is performed without checking for integer overflow. If the addition oveflows, the size check may incorrectly succed and allow userspace to provide an undersized drm_gem_object, potentially leading to out-of-bounds memory access. Add usage of check_add_overflow() to safely compute the minimum required size and reject the framebuffer if an overflow is detected. This makes the AFBC size validation more robust against malformed. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 65ad2392dd6d ("drm/komeda: Added AFBC support for komeda driver") Signed-off-by: Alexander Konyukhov Acked-by: Liviu Dudau Signed-off-by: Liviu Dudau Link: https://lore.kernel.org/r/20260203134907.1587067-1-Alexander.Konyukhov@kaspersky.com Signed-off-by: Sasha Levin commit 60a90d853fcae19c111ac95d84081e1a3b19c91a Author: Yuwen Chen Date: Wed Jan 28 10:03:10 2026 +0800 selftests/futex: Fix incorrect result reporting of futex_requeue test item [ Upstream commit d317e2ef9dcf673c9f37cda784284af7c6812757 ] When using the TEST_HARNESS_MAIN macro definition to declare the main function, it is required to use the EXPECT*() and ASSERT*() macros in conjunction and not ksft_test_result_*(). Otherwise, even if a test item fails, the test will still return a success result because ksft_test_result_*() does not affect the test harness state. Convert the code to use EXPECT/ASSERT() variants, which ensures that the overall test result is fail if one of the EXPECT()s fails. [ tglx: Massaged change log to explain _why_ ksft_test_result*() is the wrong choice ] Fixes: f341a20f6d7e ("selftests/futex: Refactor futex_requeue with kselftest_harness.h") Signed-off-by: Yuwen Chen Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/tencent_51851B741CC4B5EC9C22AFF70BA82BB60805@qq.com Signed-off-by: Sasha Levin commit f98084d9786441eb358f702d5aa773db99f383d5 Author: Lorenzo Bianconi Date: Sun Apr 12 10:43:26 2026 +0200 net: airoha: Add missing PPE configurations in airoha_ppe_hw_init() [ Upstream commit b9d8b856689d2b968495d79fe653d87fcb8ad98c ] Add the following PPE configuration in airoha_ppe_hw_init routine: - 6RD hw offloading is currently not supported by Netfilter flowtable. Disable explicitly PPE 6RD offloading in order to prevent PPE to learn 6RD flows and eventually interrupt the traffic. - Add missing PPE bind rate configuration for L3 and L2 traffic. PPE bind rate configuration specifies the pps threshold to move a PPE entry state from UNBIND to BIND. Without this configuration this value is random. - Set ageing thresholds to the values used in the vendor SDK in order to improve connection stability under load and avoid packet loss caused by fast aging. Fixes: 00a7678310fe3 ("net: airoha: Introduce flowtable offload support") Signed-off-by: Lorenzo Bianconi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260412-airoha_ppe_hw_init-missing-bits-v1-1-06ac670819e3@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 7bad93e99737e4a5c0c14ac50c05152cf4e28022 Author: Jiayuan Chen Date: Sat Apr 11 08:55:19 2026 +0800 net, bpf: fix null-ptr-deref in xdp_master_redirect() for down master [ Upstream commit 1921f91298d1388a0bb9db8f83800c998b649cb3 ] syzkaller reported a kernel panic in bond_rr_gen_slave_id() reached via xdp_master_redirect(). Full decoded trace: https://syzkaller.appspot.com/bug?extid=80e046b8da2820b6ba73 bond_rr_gen_slave_id() dereferences bond->rr_tx_counter, a per-CPU counter that bonding only allocates in bond_open() when the mode is round-robin. If the bond device was never brought up, rr_tx_counter stays NULL. The XDP redirect path can still reach that code on a bond that was never opened: bpf_master_redirect_enabled_key is a global static key, so as soon as any bond device has native XDP attached, the XDP_TX -> xdp_master_redirect() interception is enabled for every slave system-wide. The path xdp_master_redirect() -> bond_xdp_get_xmit_slave() -> bond_xdp_xmit_roundrobin_slave_get() -> bond_rr_gen_slave_id() then runs against a bond that has no rr_tx_counter and crashes. Fix this in the generic xdp_master_redirect() by refusing to call into the master's ->ndo_xdp_get_xmit_slave() when the master device is not up. IFF_UP is only set after ->ndo_open() has successfully returned, so this reliably excludes masters whose XDP state has not been fully initialized. Drop the frame with XDP_ABORTED so the exception is visible via trace_xdp_exception() rather than silently falling through. This is not specific to bonding: any current or future master that defers XDP state allocation to ->ndo_open() is protected. Fixes: 879af96ffd72 ("net, core: Add support for XDP redirection to slave device") Reported-by: syzbot+80e046b8da2820b6ba73@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/698f84c6.a70a0220.2c38d7.00cc.GAE@google.com/T/ Suggested-by: Daniel Borkmann Acked-by: Daniel Borkmann Signed-off-by: Jiayuan Chen Link: https://patch.msgid.link/20260411005524.201200-2-jiayuan.chen@linux.dev Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 6a7139084973b4854d589fc30a355c4a8428fcfd Author: Xin Long Date: Sun Apr 12 14:13:51 2026 -0400 sctp: fix missing encap_port propagation for GSO fragments [ Upstream commit bf6f95ae3b8b2638c0e1d6d802d50983ce5d0f45 ] encap_port in SCTP_INPUT_CB(skb) is used by sctp_vtag_verify() for SCTP-over-UDP processing. In the GSO case, it is only set on the head skb, while fragment skbs leave it 0. This results in fragment skbs seeing encap_port == 0, breaking SCTP-over-UDP connections. Fix it by propagating encap_port from the head skb cb when initializing fragment skbs in sctp_inq_pop(). Fixes: 046c052b475e ("sctp: enable udp tunneling socks") Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner Link: https://patch.msgid.link/ea65ed61b3598d8b4940f0170b9aa1762307e6c3.1776017631.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c5a1cb8ff82b06458b458f813c5190bdf4b4634c Author: Kuniyuki Iwashima Date: Fri Apr 10 23:53:27 2026 +0000 tcp: Don't set treq->req_usec_ts in cookie_tcp_reqsk_init(). [ Upstream commit c058bbf05b1197c33df7204842665bd8bc70b3a8 ] Commit de5626b95e13 ("tcp: Factorise cookie-independent fields initialisation in cookie_v[46]_check().") miscategorised tcp_rsk(req)->req_usec_ts init to cookie_tcp_reqsk_init(), which is used by both BPF/non-BPF SYN cookie reqsk. Rather, it should have been moved to cookie_tcp_reqsk_alloc() by commit 8e7bab6b9652 ("tcp: Factorise cookie-dependent fields initialisation in cookie_v[46]_check()") so that only non-BPF SYN cookie sets tcp_rsk(req)->req_usec_ts to false. Let's move the initialisation to cookie_tcp_reqsk_alloc() to respect bpf_tcp_req_attrs.usec_ts_ok. Fixes: e472f88891ab ("bpf: tcp: Support arbitrary SYN Cookie.") Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260410235328.1773449-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 81cfd603c0bde31e91de98b0a5fd766c94554382 Author: Gabriel Krisman Bertazi Date: Fri Apr 10 11:59:36 2026 -0400 udp: Force compute_score to always inline [ Upstream commit b80a95ccf1604a882bb153c45ccb4056e44c8edb ] Back in 2024 I reported a 7-12% regression on an iperf3 UDP loopback thoughput test that we traced to the extra overhead of calling compute_score on two places, introduced by commit f0ea27e7bfe1 ("udp: re-score reuseport groups when connected sockets are present"). At the time, I pointed out the overhead was caused by the multiple calls, associated with cpu-specific mitigations, and merged commit 50aee97d1511 ("udp: Avoid call to compute_score on multiple sites") to jump back explicitly, to force the rescore call in a single place. Recently though, we got another regression report against a newer distro version, which a team colleague traced back to the same root-cause. Turns out that once we updated to gcc-13, the compiler got smart enough to unroll the loop, undoing my previous mitigation. Let's bite the bullet and __always_inline compute_score on both ipv4 and ipv6 to prevent gcc from de-optimizing it again in the future. These functions are only called in two places each, udpX_lib_lookup1 and udpX_lib_lookup2, so the extra size shouldn't be a problem and it is hot enough to be very visible in profilings. In fact, with gcc13, forcing the inline will prevent gcc from unrolling the fix from commit 50aee97d1511, so we don't end up increasing udpX_lib_lookup2 at all. I haven't recollected the results myself, as I don't have access to the machine at the moment. But the same colleague reported 4.67% inprovement with this patch in the loopback benchmark, solving the regression report within noise margins. Eric Dumazet reported no size change to vmlinux when built with clang. I report the same also with gcc-13: scripts/bloat-o-meter vmlinux vmlinux-inline add/remove: 0/2 grow/shrink: 4/0 up/down: 616/-416 (200) Function old new delta udp6_lib_lookup2 762 949 +187 __udp6_lib_lookup 810 975 +165 udp4_lib_lookup2 757 906 +149 __udp4_lib_lookup 871 986 +115 __pfx_compute_score 32 - -32 compute_score 384 - -384 Total: Before=35011784, After=35011984, chg +0.00% Fixes: 50aee97d1511 ("udp: Avoid call to compute_score on multiple sites") Reviewed-by: Eric Dumazet Acked-by: Willem de Bruijn Signed-off-by: Gabriel Krisman Bertazi Link: https://patch.msgid.link/20260410155936.654915-1-krisman@suse.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1218bfe2ad6fb2803733766ae1d0cbdf7ff38a29 Author: Maxime Chevallier Date: Fri Apr 10 19:10:20 2026 +0200 net: phy: qcom: at803x: Use the correct bit to disable extended next page [ Upstream commit e7a62edd34b1b4bc5f979988efc2f81c075733fd ] As noted in the blamed commit, the AR8035 and other PHYs from this family advertise the Extended Next Page support by default, which may be understood by some partners as this PHY being multi-gig capable. The fix is to disable XNP advertising, which is done by setting bit 12 of the Auto-Negotiation Advertisement Register (MII_ADVERTISE). The blamed commit incorrectly uses MDIO_AN_CTRL1_XNP, which is bit 13 as per 802.3 : 45.2.7.1 AN control register (Register 7.0) BIT 12 in MII_ADVERTISE is wrapped by ADVERTISE_RESV, used by some drivers such as the aquantia one. 802.3 Clause 28 defines bit 12 as Extended Next Page ability, at least in recent versions of the standard. Let's add a define for it and use it in the at803x driver. Fixes: 3c51fa5d2afe ("net: phy: ar803x: disable extended next page bit") Signed-off-by: Maxime Chevallier Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260410171021.1277138-1-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b28b3bd9c42fd49169bda697d5e33570f4dbe9a9 Author: Stefan Metzmacher Date: Tue Apr 7 17:13:45 2026 +0200 Bluetooth: SCO: check for codecs->num_codecs == 1 before assigning to sco_pi(sk)->codec [ Upstream commit 4e10a9ebbf081c16517cdd9366ac618bf38d7d0c ] copy_struct_from_sockptr() fill 'buffer' in sco_sock_setsockopt() with zeros, so there's no real problem. But it actually looks strange to do this, without checking all of codecs->codecs[0] really comes from userspace: sco_pi(sk)->codec = codecs->codecs[0]; As only optlen < sizeof(struct bt_codecs) is checked and codecs->num_codecs is not checked against != 1, but only <= 1, and the space for the additional struct bt_codec is not checked. Note I don't understand bluetooth and I didn't do any runtime tests with this! I just found it when debugging a problem in copy_struct_from_sockptr(). I just added this to check the size is as expected: BUILD_BUG_ON(struct_size(codecs, codecs, 0) != 1); BUILD_BUG_ON(struct_size(codecs, codecs, 1) != 8); And made sure it still compiles using this: make CF=-D__CHECK_ENDIAN__ W=1ce C=1 net/bluetooth/sco.o Fixes: 3e643e4efa1e ("Bluetooth: Improve setsockopt() handling of malformed user input") Cc: Michal Luczaj Cc: Luiz Augusto von Dentz Cc: Luiz Augusto von Dentz Cc: Marcel Holtmann Cc: David Wei Cc: linux-bluetooth@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Stefan Metzmacher Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit dc89961b76f12aff47124c1df4bdb32a080f4d0c Author: Dudu Lu Date: Sun Apr 5 23:47:41 2026 +0800 Bluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp [ Upstream commit 42776497cdbc9a665b384a6dcb85f0d4bd927eab ] l2cap_ecred_reconf_rsp() calls l2cap_chan_del() without holding l2cap_chan_lock(). Every other l2cap_chan_del() caller in the file acquires the lock first. A remote BLE device can send a crafted L2CAP ECRED reconfiguration response to corrupt the channel list while another thread is iterating it. Add l2cap_chan_hold() and l2cap_chan_lock() before l2cap_chan_del(), and l2cap_chan_unlock() and l2cap_chan_put() after, matching the pattern used in l2cap_ecred_conn_rsp() and l2cap_conn_del(). Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode") Signed-off-by: Dudu Lu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 385b2d0468a0871fc716c549fa3b0c257c7dbcb3 Author: Pauli Virtanen Date: Sun Mar 29 16:42:59 2026 +0300 Bluetooth: fix locking in hci_conn_request_evt() with HCI_PROTO_DEFER [ Upstream commit 5c7209a341ff2ac338b2b0375c34a307b37c9ac2 ] When protocol sets HCI_PROTO_DEFER, hci_conn_request_evt() calls hci_connect_cfm(conn) without hdev->lock. Generally hci_connect_cfm() assumes it is held, and if conn is deleted concurrently -> UAF. Only SCO and ISO set HCI_PROTO_DEFER and only for defer setup listen, and HCI_EV_CONN_REQUEST is not generated for ISO. In the non-deferred listening socket code paths, hci_connect_cfm(conn) is called with hdev->lock held. Fix by holding the lock. Fixes: 70c464256310 ("Bluetooth: Refactor connection request handling") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 3daa5818e473ed60eb69d8b5c71b651909d28c5a Author: Jonathan Rissanen Date: Fri Mar 27 11:47:20 2026 +0100 Bluetooth: hci_ldisc: Clear HCI_UART_PROTO_INIT on error [ Upstream commit 68d39ea5e0adc9ecaea1ce8abd842ec972eb8718 ] When hci_register_dev() fails in hci_uart_register_dev() HCI_UART_PROTO_INIT is not cleared before calling hu->proto->close(hu) and setting hu->hdev to NULL. This means incoming UART data will reach the protocol-specific recv handler in hci_uart_tty_receive() after resources are freed. Clear HCI_UART_PROTO_INIT with a write lock before calling hu->proto->close() and setting hu->hdev to NULL. The write lock ensures all active readers have completed and no new reader can enter the protocol recv path before resources are freed. This allows the protocol-specific recv functions to remove the "HCI_UART_REGISTERED" guard without risking a null pointer dereference if hci_register_dev() fails. Fixes: 5df5dafc171b ("Bluetooth: hci_uart: Fix another race during initialization") Signed-off-by: Jonathan Rissanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 4ae187c7915d8b7de2cc56ba7732c046c82d198a Author: Luiz Augusto von Dentz Date: Mon Mar 16 14:34:13 2026 -0400 Bluetooth: L2CAP: Fix printing wrong information if SDU length exceeds MTU [ Upstream commit 15bf35a660eb82a49f8397fc3d3acada8dae13db ] The code was printing skb->len and sdu_len in the places where it should be sdu_len and chan->imtu respectively to match the if conditions. Link: https://lore.kernel.org/linux-bluetooth/20260315132013.75ab40c5@kernel.org/T/#m1418f9c82eeff8510c1beaa21cf53af20db96c06 Fixes: e1d9a6688986 ("Bluetooth: LE L2CAP: Disconnect if received packet's SDU exceeds IMTU") Signed-off-by: Luiz Augusto von Dentz Reviewed-by: Paul Menzel Signed-off-by: Sasha Levin commit 8042240412de3222d27b31e89d29336961cad9e4 Author: Sun Jian Date: Wed Apr 8 11:46:22 2026 +0800 bpf: reject short IPv4/IPv6 inputs in bpf_prog_test_run_skb [ Upstream commit 12bec2bd4b76d81c5d3996bd14ec1b7f4d983747 ] bpf_prog_test_run_skb() calls eth_type_trans() first and then uses skb->protocol to initialize sk family and address fields for the test run. For IPv4 and IPv6 packets, it may access ip_hdr(skb) or ipv6_hdr(skb) even when the provided test input only contains an Ethernet header. Reject the input earlier if the Ethernet frame carries IPv4/IPv6 EtherType but the L3 header is too short. Fold the IPv4/IPv6 header length checks into the existing protocol switch and return -EINVAL before accessing the network headers. Fixes: fa5cb548ced6 ("bpf: Setup socket family and addresses in bpf_prog_test_run_skb") Reported-by: syzbot+619b9ef527f510a57cfc@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=619b9ef527f510a57cfc Signed-off-by: Sun Jian Link: https://lore.kernel.org/r/20260408034623.180320-2-sun.jian.kdev@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit afdc8516213ee047f5162bdcd7f80ddc9ebae7ac Author: Gal Pressman Date: Thu Apr 9 23:28:52 2026 +0300 net/mlx5e: IPsec, fix ASO poll timeout with read_poll_timeout_atomic() [ Upstream commit edccdd1eb94712da97a6ce71123ec27890add754 ] The do-while poll loop uses jiffies for its timeout: expires = jiffies + msecs_to_jiffies(10); jiffies is sampled at an arbitrary point within the current tick, so the first partial tick contributes anywhere from a full tick down to nearly zero real time. For small msecs_to_jiffies() results this is significant, the effective poll window can be much shorter than the requested 10ms, and in the worst case the loop exits after a single iteration (e.g., when HZ=100), well before the device has delivered the CQE. Replace the loop with read_poll_timeout_atomic(), which counts elapsed time via udelay() accounting rather than jiffies, guaranteeing the full poll window regardless of HZ. Additionally, read_poll_timeout_atomic() executes the poll operation one more time after the timeout has expired, giving the CQE a final chance to be detected. The old do-while loop could exit without a final poll if the timeout expired during the udelay() between iterations. Fixes: 76e463f6508b ("net/mlx5e: Overcome slow response for first IPsec ASO WQE") Signed-off-by: Gal Pressman Reviewed-by: Jianbo Liu Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260409202852.158059-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ef6d5a0688113b21135c8f271318bb2ecc929ab5 Author: Gal Pressman Date: Thu Apr 9 23:28:51 2026 +0300 net/mlx5e: Fix features not applied during netdev registration [ Upstream commit 9994ad4df82d64e57135c0f0906897685f5a9e87 ] mlx5e_fix_features() returns early when the netdevice is not present. This is correct during profile transitions where priv is cleared, but it also incorrectly blocks feature fixups during register_netdev(), when the device is also not yet present. It is not trivial to distinguish between both cases as we cannot use priv to carry state, and in both cases reg_state == NETREG_REGISTERED. Force a netdev features update after register_netdev() completes, where the device is present and fix_features() can actually work. This is not a pretty solution, as it results in an additional features update call (register_netdevice() already calls __netdev_update_features() internally), but it is the simplest, cleanest, and most robust way I found to fix this issue after multiple attempts. This fixes an issue on systems where CQE compression is enabled by default, RXHASH remains enabled after registration despite the two features being mutually exclusive. Fixes: ab4b01bfdaa6 ("net/mlx5e: Verify dev is present for fix features ndo") Signed-off-by: Gal Pressman Reviewed-by: Dragos Tatulea Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260409202852.158059-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 15a9928f8a93bb9df38900b3f21b665679fb8eb8 Author: Charles Perry Date: Thu Apr 9 06:36:54 2026 -0700 net: phy: fix a return path in get_phy_c45_ids() [ Upstream commit 6f533abe7bbad2eef1e42c639b6bb9dad2b02362 ] The return value of phy_c45_probe_present() is stored in "ret", not "phy_reg", fix this. "phy_reg" always has a positive value if we reach this return path (since it would have returned earlier otherwise), which means that the original goal of the patch of not considering -ENODEV fatal wasn't achieved. Fixes: 17b447539408 ("net: phy: c45 scanning: Don't consider -ENODEV fatal") Signed-off-by: Charles Perry Reviewed-by: Andrew Lunn Reviewed-by: Russell King (Oracle) Link: https://patch.msgid.link/20260409133654.3203336-1-charles.perry@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d7637c455a92d3527ca56902d2632f349fdc98c4 Author: Josua Mayer Date: Thu Apr 9 14:34:33 2026 +0200 dt-bindings: net: dsa: nxp,sja1105: make spi-cpol optional for sja1110 [ Upstream commit 600f01dc4bd0c736b3ffea9f7976136d8bf1b136 ] Currently, the binding requires 'spi-cpha' for SJA1105 and 'spi-cpol' for SJA1110. However, the SJA1110 supports both SPI modes 0 and 2. Mode 2 (cpha=0, cpol=1) is used by the NXP LX2160 Bluebox 3. On the SolidRun i.MX8DXL HummingBoard Telematics, mode 0 is stable, while forcing mode 2 introduces CRC errors especially during bursts. Drop the requirement on spi-cpol for SJA1110. Fixes: af2eab1a8243 ("dt-bindings: net: nxp,sja1105: document spi-cpol/cpha") Signed-off-by: Josua Mayer Acked-by: Conor Dooley Link: https://patch.msgid.link/20260409-imx8dxl-sr-som-v2-1-83ff20629ba0@solid-run.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a3be96c7b1e532e6f4498ec30dab148c95392000 Author: Luca Weiss Date: Thu Apr 9 10:13:32 2026 +0200 net: ipa: Fix decoding EV_PER_EE for IPA v5.0+ [ Upstream commit 1335b903cf2e8aeaca87fd665683384c731ec941 ] Initially 'reg' and 'val' are assigned from HW_PARAM_2. But since IPA v5.0+ takes EV_PER_EE from HW_PARAM_4 (instead of NUM_EV_PER_EE from HW_PARAM_2), we not only need to re-assign 'reg' but also read the register value of that register into 'val' so that reg_decode() works on the correct value. Fixes: f651334e1ef5 ("net: ipa: add HW_PARAM_4 GSI register") Link: https://sashiko.dev/#/patchset/20260403-milos-ipa-v1-0-01e9e4e03d3e%40fairphone.com?part=2 Signed-off-by: Luca Weiss Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260409-ipa-fixes-v1-2-a817c30678ac@fairphone.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 65c7f0bf8ca32c40d0fdc1465a249e3fb579e8f3 Author: Luca Weiss Date: Thu Apr 9 10:13:31 2026 +0200 net: ipa: Fix programming of QTIME_TIMESTAMP_CFG [ Upstream commit de08f9585692813bd41ee654fca0487664c4de30 ] The 'val' variable gets overwritten multiple times, discarding previous values. Looking at the git log shows these should be combined with |= instead. Fixes: 9265a4f0f0b4 ("net: ipa: define even more IPA register fields") Link: https://sashiko.dev/#/patchset/20260403-milos-ipa-v1-0-01e9e4e03d3e%40fairphone.com?part=4 Signed-off-by: Luca Weiss Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260409-ipa-fixes-v1-1-a817c30678ac@fairphone.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5013be175c7ffd8b39efbc3c9c4db5b10b85fea8 Author: Taegu Ha Date: Thu Apr 9 16:11:15 2026 +0900 ppp: require CAP_NET_ADMIN in target netns for unattached ioctls [ Upstream commit 2bb6379416fd19f44c3423a00bfd8626259f6067 ] /dev/ppp open is currently authorized against file->f_cred->user_ns, while unattached administrative ioctls operate on current->nsproxy->net_ns. As a result, a local unprivileged user can create a new user namespace with CLONE_NEWUSER, gain CAP_NET_ADMIN only in that new user namespace, and still issue PPPIOCNEWUNIT, PPPIOCATTACH, or PPPIOCATTCHAN against an inherited network namespace. Require CAP_NET_ADMIN in the user namespace that owns the target network namespace before handling unattached PPP administrative ioctls. This preserves normal pppd operation in the network namespace it is actually privileged in, while rejecting the userns-only inherited-netns case. Fixes: 273ec51dd7ce ("net: ppp_generic - introduce net-namespace functionality v2") Signed-off-by: Taegu Ha Link: https://patch.msgid.link/20260409071117.4354-1-hataegu0826@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6086079e6d1c32ba4c4b422612b8aebb1129a96c Author: Lang Xu Date: Thu Apr 2 15:42:35 2026 +0800 bpf: Fix OOB in pcpu_init_value [ Upstream commit 576afddfee8d1108ee299bf10f581593540d1a36 ] An out-of-bounds read occurs when copying element from a BPF_MAP_TYPE_CGROUP_STORAGE map to another pcpu map with the same value_size that is not rounded up to 8 bytes. The issue happens when: 1. A CGROUP_STORAGE map is created with value_size not aligned to 8 bytes (e.g., 4 bytes) 2. A pcpu map is created with the same value_size (e.g., 4 bytes) 3. Update element in 2 with data in 1 pcpu_init_value assumes that all sources are rounded up to 8 bytes, and invokes copy_map_value_long to make a data copy, However, the assumption doesn't stand since there are some cases where the source may not be rounded up to 8 bytes, e.g., CGROUP_STORAGE, skb->data. the verifier verifies exactly the size that the source claims, not the size rounded up to 8 bytes by kernel, an OOB happens when the source has only 4 bytes while the copy size(4) is rounded up to 8. Fixes: d3bec0138bfb ("bpf: Zero-fill re-used per-cpu map element") Reported-by: Kaiyan Mei Closes: https://lore.kernel.org/all/14e6c70c.6c121.19c0399d948.Coremail.kaiyanm@hust.edu.cn/ Link: https://lore.kernel.org/r/420FEEDDC768A4BE+20260402074236.2187154-1-xulang@uniontech.com Signed-off-by: Lang Xu Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit a7494479757d60d2413bfaa087f8431a26eea032 Author: Greg Jumper Date: Wed Apr 8 01:04:20 2026 -0700 net/rds: Restrict use of RDS/IB to the initial network namespace [ Upstream commit ebf71dd4aff46e8e421d455db3e231ba43d2fa8a ] Prevent using RDS/IB in network namespaces other than the initial one. The existing RDS/IB code will not work properly in non-initial network namespaces. Fixes: d5a8ac28a7ff ("RDS-TCP: Make RDS-TCP work correctly when it is set up in a netns other than init_net") Reported-by: syzbot+da8e060735ae02c8f3d1@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=da8e060735ae02c8f3d1 Signed-off-by: Greg Jumper Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260408080420.540032-3-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d3f880a6eb440a7d446e67bea128b1c6246d3f23 Author: Håkon Bugge Date: Wed Apr 8 01:04:19 2026 -0700 net/rds: Optimize rds_ib_laddr_check [ Upstream commit 236f718ac885965fa886440b9898dfae185c9733 ] rds_ib_laddr_check() creates a CM_ID and attempts to bind the address in question to it. This in order to qualify the allegedly local address as a usable IB/RoCE address. In the field, ExaWatcher runs rds-ping to all ports in the fabric from all local ports. This using all active ToS'es. In a full rack system, we have 14 cell servers and eight db servers. Typically, 6 ToS'es are used. This implies 528 rds-ping invocations per ExaWatcher's "RDSinfo" interval. Adding to this, each rds-ping invocation creates eight sockets and binds the local address to them: socket(AF_RDS, SOCK_SEQPACKET, 0) = 3 bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.36.2")}, 16) = 0 socket(AF_RDS, SOCK_SEQPACKET, 0) = 4 bind(4, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.36.2")}, 16) = 0 socket(AF_RDS, SOCK_SEQPACKET, 0) = 5 bind(5, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.36.2")}, 16) = 0 socket(AF_RDS, SOCK_SEQPACKET, 0) = 6 bind(6, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.36.2")}, 16) = 0 socket(AF_RDS, SOCK_SEQPACKET, 0) = 7 bind(7, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.36.2")}, 16) = 0 socket(AF_RDS, SOCK_SEQPACKET, 0) = 8 bind(8, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.36.2")}, 16) = 0 socket(AF_RDS, SOCK_SEQPACKET, 0) = 9 bind(9, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.36.2")}, 16) = 0 socket(AF_RDS, SOCK_SEQPACKET, 0) = 10 bind(10, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.36.2")}, 16) = 0 So, at every interval ExaWatcher executes rds-ping's, 4224 CM_IDs are allocated, considering this full-rack system. After the a CM_ID has been allocated, rdma_bind_addr() is called, with the port number being zero. This implies that the CMA will attempt to search for an un-used ephemeral port. Simplified, the algorithm is to start at a random position in the available port space, and then if needed, iterate until an un-used port is found. The book-keeping of used ports uses the idr system, which again uses slab to allocate new struct idr_layer's. The size is 2092 bytes and slab tries to reduce the wasted space. Hence, it chooses an order:3 allocation, for which 15 idr_layer structs will fit and only 1388 bytes are wasted per the 32KiB order:3 chunk. Although this order:3 allocation seems like a good space/speed trade-off, it does not resonate well with how it used by the CMA. The combination of the randomized starting point in the port space (which has close to zero spatial locality) and the close proximity in time of the 4224 invocations of the rds-ping's, creates a memory hog for order:3 allocations. These costly allocations may need reclaims and/or compaction. At worst, they may fail and produce a stack trace such as (from uek4): [] __inc_zone_page_state+0x35/0x40 [] page_add_file_rmap+0x57/0x60 [] remove_migration_pte+0x3f/0x3c0 [ksplice_6cn872bt_vmlinux_new] [] rmap_walk+0xd8/0x340 [] remove_migration_ptes+0x40/0x50 [] migrate_pages+0x3ec/0x890 [] compact_zone+0x32d/0x9a0 [] compact_zone_order+0x6d/0x90 [] try_to_compact_pages+0x102/0x270 [] __alloc_pages_direct_compact+0x46/0x100 [] __alloc_pages_nodemask+0x74b/0xaa0 [] alloc_pages_current+0x91/0x110 [] new_slab+0x38b/0x480 [] __slab_alloc+0x3b7/0x4a0 [ksplice_s0dk66a8_vmlinux_new] [] kmem_cache_alloc+0x1fb/0x250 [] idr_layer_alloc+0x36/0x90 [] idr_get_empty_slot+0x28c/0x3d0 [] idr_alloc+0x4d/0xf0 [] cma_alloc_port+0x4d/0xa0 [rdma_cm] [] rdma_bind_addr+0x2ae/0x5b0 [rdma_cm] [] rds_ib_laddr_check+0x83/0x2c0 [ksplice_6l2xst5i_rds_rdma_new] [] rds_trans_get_preferred+0x5b/0xa0 [rds] [] rds_bind+0x212/0x280 [rds] [] SYSC_bind+0xe6/0x120 [] SyS_bind+0xe/0x10 [] system_call_fastpath+0x18/0xd4 To avoid these excessive calls to rdma_bind_addr(), we optimize rds_ib_laddr_check() by simply checking if the address in question has been used before. The rds_rdma module keeps track of addresses associated with IB devices, and the function rds_ib_get_device() is used to determine if the address already has been qualified as a valid local address. If not found, we call the legacy rds_ib_laddr_check(), now renamed to rds_ib_laddr_check_cm(). Signed-off-by: Håkon Bugge Signed-off-by: Somasundaram Krishnasamy Signed-off-by: Gerd Rausch Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260408080420.540032-2-achender@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: ebf71dd4aff4 ("net/rds: Restrict use of RDS/IB to the initial network namespace") Signed-off-by: Sasha Levin commit bc678fa87552b06da8f9f27c843c352202406a98 Author: Paul Chaignon Date: Wed Apr 8 22:40:50 2026 +0200 selftests/bpf: Fix reg_bounds to match new tnum-based refinement [ Upstream commit 2fefa9c81a25534464911447d51ddb44b04a8e5b ] Commit efc11a667878 ("bpf: Improve bounds when tnum has a single possible value") improved the bounds refinement to detect when the tnum and u64 range overlap in a single value (and the bounds can thus be set to that value). Eduard then noticed that it broke the slow-mode reg_bounds selftests because they don't have an equivalent logic and are therefore unable to refine the bounds as much as the verifier. The following test case illustrates this. ACTUAL TRUE1: scalar(u64=0xffffffff00000000,u32=0,s64=0xffffffff00000000,s32=0) EXPECTED TRUE1: scalar(u64=[0xfffffffe00000001; 0xffffffff00000000],u32=0,s64=[0xfffffffe00000001; 0xffffffff00000000],s32=0) [...] #323/1007 reg_bounds_gen_consts_s64_s32/(s64)[0xfffffffe00000001; 0xffffffff00000000] (s32) S64_MIN:FAIL with the verifier logs: [...] 19: w0 = w6 ; R0=scalar(smin=0,smax=umax=0xffffffff, var_off=(0x0; 0xffffffff)) R6=scalar(smin=0xfffffffe00000001,smax=0xffffffff00000000, umin=0xfffffffe00000001,umax=0xffffffff00000000, var_off=(0xfffffffe00000000; 0x1ffffffff)) 20: w0 = w7 ; R0=0 R7=0x8000000000000000 21: if w6 == w7 goto pc+3 [...] from 21 to 25: [...] 25: w0 = w6 ; R0=0 R6=0xffffffff00000000 ; ^ ; unexpected refined value 26: w0 = w7 ; R0=0 R7=0x8000000000000000 27: exit When w6 == w7 is true, the verifier can deduce that the R6's tnum is equal to (0xfffffffe00000000; 0x100000000) and then use that information to refine the bounds: the tnum only overlap with the u64 range in 0xffffffff00000000. The reg_bounds selftest doesn't know about tnums and therefore fails to perform the same refinement. This issue happens when the tnum carries information that cannot be represented in the ranges, as otherwise the selftest could reach the same refined value using just the ranges. The tnum thus needs to represent non-contiguous values (ex., R6's tnum above, after the condition). The only way this can happen in the reg_bounds selftest is at the boundary between the 32 and 64bit ranges. We therefore only need to handle that case. This patch fixes the selftest refinement logic by checking if the u32 and u64 ranges overlap in a single value. If so, the ranges can be set to that value. We need to handle two cases: either they overlap in umin64... u64 values matching u32 range: xxx xxx xxx xxx |--------------------------------------| u64 range: 0 xxxxx UMAX64 or in umax64: u64 values matching u32 range: xxx xxx xxx xxx |--------------------------------------| u64 range: 0 xxxxx UMAX64 To detect the first case, we decrease umax64 to the maximum value that matches the u32 range. If that happens to be umin64, then umin64 is the only overlap. We proceed similarly for the second case, increasing umin64 to the minimum value that matches the u32 range. Note this is similar to how the verifier handles the general case using tnum, but we don't need to care about a single-value overlap in the middle of the range. That case is not possible when comparing two ranges. This patch also adds two test cases reproducing this bug as part of the normal test runs (without SLOW_TESTS=1). Fixes: efc11a667878 ("bpf: Improve bounds when tnum has a single possible value") Reported-by: Eduard Zingerman Closes: https://lore.kernel.org/bpf/4e6dd64a162b3cab3635706ae6abfdd0be4db5db.camel@gmail.com/ Signed-off-by: Paul Chaignon Link: https://lore.kernel.org/r/ada9UuSQi2SE2IfB@mail.gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit cddf2bde8420ed6d3398ad58d292b5c1a2ed2bee Author: Emil Tsalapatis Date: Sun Apr 12 13:45:38 2026 -0400 bpf: Allow instructions with arena source and non-arena dest registers [ Upstream commit ac61bffe91d4bda08806e12957c6d64756d042db ] The compiler sometimes stores the result of a PTR_TO_ARENA and SCALAR operation into the scalar register rather than the pointer register. Relax the verifier to allow operations between a source arena register and a destination non-arena register, marking the destination's value as a PTR_TO_ARENA. Signed-off-by: Emil Tsalapatis Acked-by: Song Liu Fixes: 6082b6c328b5 ("bpf: Recognize addr_space_cast instruction in the verifier.") Link: https://lore.kernel.org/r/20260412174546.18684-2-emil@etsalapatis.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 9d51c86355d9da7e11e8ff794eb5dc9675a77f8d Author: Lorenzo Bianconi Date: Wed Apr 8 20:26:56 2026 +0200 net: airoha: Add missing RX_CPU_IDX() configuration in airoha_qdma_cleanup_rx_queue() [ Upstream commit 656121b155030086b01cfce9bd31b0c925ee6860 ] When the descriptor index written in REG_RX_CPU_IDX() is equal to the one stored in REG_RX_DMA_IDX(), the hw will stop since the QDMA RX ring is empty. Add missing REG_RX_CPU_IDX() configuration in airoha_qdma_cleanup_rx_queue routine during QDMA RX ring cleanup. Fixes: 514aac359987 ("net: airoha: Add missing cleanup bits in airoha_qdma_cleanup_rx_queue()") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260408-airoha-cpu-idx-airoha_qdma_cleanup_rx_queue-v1-1-8efa64844308@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3ddf6523957a9f6991449b0101fa22dac6be0bcd Author: Erni Sri Satya Vennela Date: Wed Apr 8 01:12:20 2026 -0700 net: mana: Move current_speed debugfs file to mana_init_port() [ Upstream commit 3b7c7fc97aea7b4048001d12f45777201c74a17f ] Move the current_speed debugfs file creation from mana_probe_port() to mana_init_port(). The file was previously created only during initial probe, but mana_cleanup_port_context() removes the entire vPort debugfs directory during detach/attach cycles. Since mana_init_port() recreates the directory on re-attach, moving current_speed here ensures it survives these cycles. Fixes: 75cabb46935b ("net: mana: Add support for net_shaper_ops") Signed-off-by: Erni Sri Satya Vennela Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260408081224.302308-3-ernis@linux.microsoft.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 90ebf3e9c12f7a6c0adaf997efac095ccf04cfc3 Author: Haiyang Zhang Date: Wed Oct 29 13:43:10 2025 -0700 net: mana: Support HW link state events [ Upstream commit 54133f9b4b53ffa2204eb27cfc9d50072c9a52d2 ] Handle the NIC hardware link state events received from the HW channel, then set the proper link state accordingly. And, add a feature bit, GDMA_DRV_CAP_FLAG_1_HW_VPORT_LINK_AWARE, to inform the NIC hardware this handler exists. Our MANA NIC only sends out the link state down/up messages when we need to let the VM rerun DHCP client and change IP address. So, add netif_carrier_on() in the probe(), let the NIC show the right initial state in /sys/class/net/ethX/operstate. Signed-off-by: Haiyang Zhang Link: https://patch.msgid.link/1761770601-16920-1-git-send-email-haiyangz@linux.microsoft.com Signed-off-by: Jakub Kicinski Stable-dep-of: 3b7c7fc97aea ("net: mana: Move current_speed debugfs file to mana_init_port()") Signed-off-by: Sasha Levin commit 34dbd7b819544c99c9d96b400fe4db613f40ac4b Author: Erni Sri Satya Vennela Date: Wed Apr 8 01:12:19 2026 -0700 net: mana: Use pci_name() for debugfs directory naming [ Upstream commit c116f07ab9d22bb6f355f3cf9e44c1e6a47fe559 ] Use pci_name(pdev) for the per-device debugfs directory instead of hardcoded "0" for PFs and pci_slot_name(pdev->slot) for VFs. The previous approach had two issues: 1. pci_slot_name() dereferences pdev->slot, which can be NULL for VFs in environments like generic VFIO passthrough or nested KVM, causing a NULL pointer dereference. 2. Multiple PFs would all use "0", and VFs across different PCI domains or buses could share the same slot name, leading to -EEXIST errors from debugfs_create_dir(). pci_name(pdev) returns the unique BDF address, is always valid, and is unique across the system. Fixes: 6607c17c6c5e ("net: mana: Enable debugfs files for MANA device") Signed-off-by: Erni Sri Satya Vennela Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260408081224.302308-2-ernis@linux.microsoft.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 64daf391198cc09d6cafc4c5ba45ffb0899ae57a Author: Florian Westphal Date: Fri Apr 10 00:45:02 2026 +0200 selftests: netfilter: nft_tproxy.sh: adjust to socat changes [ Upstream commit 61119542663cac70898aef532eb57ee41ea9b477 ] Like e65d8b6f3092 ("selftests: drv-net: adjust to socat changes") we need to add shut-none for this test too. The extra 0-packet can trigger a second (unexpected) reply from the server. Fixes: 7e37e0eacd22 ("selftests: netfilter: nft_tproxy.sh: add tcp tests") Reported-by: Jakub Kicinski Closes: https://lore.kernel.org/netdev/20260408152432.24b8ad0d@kernel.org/ Suggested-by: Jakub Kicinski Signed-off-by: Florian Westphal Link: https://patch.msgid.link/20260409224506.27072-1-fw@strlen.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4c727c6967a41b37efe0f26332ca9ec5b74785a3 Author: Jamal Hadi Salim Date: Fri Apr 10 07:16:27 2026 -0400 net/sched: act_ct: Only release RCU read lock after ct_ft [ Upstream commit f462dca0c8415bf0058d0ffa476354c4476d0f09 ] When looking up a flow table in act_ct in tcf_ct_flow_table_get(), rhashtable_lookup_fast() internally opens and closes an RCU read critical section before returning ct_ft. The tcf_ct_flow_table_cleanup_work() can complete before refcount_inc_not_zero() is invoked on the returned ct_ft resulting in a UAF on the already freed ct_ft object. This vulnerability can lead to privilege escalation. Analysis from zdi-disclosures@trendmicro.com: When initializing act_ct, tcf_ct_init() is called, which internally triggers tcf_ct_flow_table_get(). static int tcf_ct_flow_table_get(struct net *net, struct tcf_ct_params *params) { struct zones_ht_key key = { .net = net, .zone = params->zone }; struct tcf_ct_flow_table *ct_ft; int err = -ENOMEM; mutex_lock(&zones_mutex); ct_ft = rhashtable_lookup_fast(&zones_ht, &key, zones_params); // [1] if (ct_ft && refcount_inc_not_zero(&ct_ft->ref)) // [2] goto out_unlock; ... } static __always_inline void *rhashtable_lookup_fast( struct rhashtable *ht, const void *key, const struct rhashtable_params params) { void *obj; rcu_read_lock(); obj = rhashtable_lookup(ht, key, params); rcu_read_unlock(); return obj; } At [1], rhashtable_lookup_fast() looks up and returns the corresponding ct_ft from zones_ht . The lookup is performed within an RCU read critical section through rcu_read_lock() / rcu_read_unlock(), which prevents the object from being freed. However, at the point of function return, rcu_read_unlock() has already been called, and there is nothing preventing ct_ft from being freed before reaching refcount_inc_not_zero(&ct_ft->ref) at [2]. This interval becomes the race window, during which ct_ft can be freed. Free Process: tcf_ct_flow_table_put() is executed through the path tcf_ct_cleanup() call_rcu() tcf_ct_params_free_rcu() tcf_ct_params_free() tcf_ct_flow_table_put(). static void tcf_ct_flow_table_put(struct tcf_ct_flow_table *ct_ft) { if (refcount_dec_and_test(&ct_ft->ref)) { rhashtable_remove_fast(&zones_ht, &ct_ft->node, zones_params); INIT_RCU_WORK(&ct_ft->rwork, tcf_ct_flow_table_cleanup_work); // [3] queue_rcu_work(act_ct_wq, &ct_ft->rwork); } } At [3], tcf_ct_flow_table_cleanup_work() is scheduled as RCU work static void tcf_ct_flow_table_cleanup_work(struct work_struct *work) { struct tcf_ct_flow_table *ct_ft; struct flow_block *block; ct_ft = container_of(to_rcu_work(work), struct tcf_ct_flow_table, rwork); nf_flow_table_free(&ct_ft->nf_ft); block = &ct_ft->nf_ft.flow_block; down_write(&ct_ft->nf_ft.flow_block_lock); WARN_ON(!list_empty(&block->cb_list)); up_write(&ct_ft->nf_ft.flow_block_lock); kfree(ct_ft); // [4] module_put(THIS_MODULE); } tcf_ct_flow_table_cleanup_work() frees ct_ft at [4]. When this function executes between [1] and [2], UAF occurs. This race condition has a very short race window, making it generally difficult to trigger. Therefore, to trigger the vulnerability an msleep(100) was inserted after[1] Fixes: 138470a9b2cc2 ("net/sched: act_ct: fix lockdep splat in tcf_ct_flow_table_get") Reported-by: zdi-disclosures@trendmicro.com Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260410111627.46611-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8e1387216d6673f24aeca04133ef96766dd89748 Author: Eduard Zingerman Date: Sat Apr 11 00:33:44 2026 -0700 selftests/bpf: fix __jited_unpriv tag name [ Upstream commit cdd54fe98c00549264a92613af6bb0e9a5fd0d1c ] __jited_unpriv was using "test_jited=" as its tag name, same as the priv variant __jited. Fix by using "test_jited_unpriv=". Fixes: 7d743e4c759c ("selftests/bpf: __jited test tag to check disassembly after jit") Acked-by: Ihor Solodrai Reviewed-by: Puranjay Mohan Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260410-selftests-global-tags-ordering-v2-1-c566ec9781bf@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 691adf738817275368ed56311b7d798d617823a3 Author: Daniel Borkmann Date: Sat Apr 11 01:26:50 2026 +0200 bpf: Enforce regsafe base id consistency for BPF_ADD_CONST scalars [ Upstream commit 2f2ec8e7730e21fc9bd49e0de9cdd58213ea24d0 ] When regsafe() compares two scalar registers that both carry BPF_ADD_CONST, check_scalar_ids() maps their full compound id (aka base | BPF_ADD_CONST flag) as one idmap entry. However, it never verifies that the underlying base ids, that is, with the flag stripped are consistent with existing idmap mappings. This allows construction of two verifier states where the old state has R3 = R2 + 10 (both sharing base id A) while the current state has R3 = R4 + 10 (base id C, unrelated to R2). The idmap creates two independent entries: A->B (for R2) and A|flag->C|flag (for R3), without catching that A->C conflicts with A->B. State pruning then incorrectly succeeds. Fix this by additionally verifying base ID mapping consistency whenever BPF_ADD_CONST is set: after mapping the compound ids, also invoke check_ids() on the base IDs (flag bits stripped). This ensures that if A was already mapped to B from comparing the source register, any ADD_CONST derivative must also derive from B, not an unrelated C. Fixes: 98d7ca374ba4 ("bpf: Track delta between "linked" registers.") Reported-by: STAR Labs SG Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260410232651.559778-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit adaee08e711b11a4001e9f4c9100ec02262e42df Author: Puranjay Mohan Date: Tue Feb 3 08:51:00 2026 -0800 bpf: Relax scalar id equivalence for state pruning [ Upstream commit b0388bafa4949bd30af7b3be5ee415f2a25ac014 ] Scalar register IDs are used by the verifier to track relationships between registers and enable bounds propagation across those relationships. Once an ID becomes singular (i.e. only a single register/stack slot carries it), it can no longer contribute to bounds propagation and effectively becomes stale. The previous commit makes the verifier clear such ids before caching the state. When comparing the current and cached states for pruning, these stale IDs can cause technically equivalent states to be considered different and thus prevent pruning. For example, in the selftest added in the next commit, two registers - r6 and r7 are not linked to any other registers and get cached with id=0, in the current state, they are both linked to each other with id=A. Before this commit, check_scalar_ids would give temporary ids to r6 and r7 (say tid1 and tid2) and then check_ids() would map tid1->A, and when it would see tid2->A, it would not consider these state equivalent. Relax scalar ID equivalence by treating rold->id == 0 as "independent": if the old state did not rely on any ID relationships for a register, then any ID/linking present in the current state only adds constraints and is always safe to accept for pruning. Implement this by returning true immediately in check_scalar_ids() when old_id == 0. Maintain correctness for the opposite direction (old_id != 0 && cur_id == 0) by still allocating a temporary ID for cur_id == 0. This avoids incorrectly allowing multiple independent current registers (id==0) to satisfy a single linked old ID during mapping. Signed-off-by: Puranjay Mohan Link: https://lore.kernel.org/r/20260203165102.2302462-5-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Stable-dep-of: 2f2ec8e7730e ("bpf: Enforce regsafe base id consistency for BPF_ADD_CONST scalars") Signed-off-by: Sasha Levin commit 0df9abbb138f4bf2cd1caf17b6285f86590b6d9a Author: Lorenzo Bianconi Date: Wed Apr 8 12:20:09 2026 +0200 net: airoha: Fix FE_PSE_BUF_SET configuration if PPE2 is available [ Upstream commit 02f72964395911e7a09bb2ea2fe6f79eda4ea2c2 ] airoha_fe_set routine is used to set specified bits to 1 in the selected register. In the FE_PSE_BUF_SET case this can due to a overestimation of the required buffers for I/O queues since we can miss to set some bits of PSE_ALLRSV_MASK subfield to 0. Fix the issue relying on airoha_fe_rmw routine instead. Fixes: 8e38e08f2c560 ("net: airoha: fix PSE memory configuration in airoha_fe_pse_ports_init()") Tested-by: Xuegang Lu Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260408-airoha-reg_fe_pse_buf_set-v1-1-0c4fa8f4d1d9@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 83d6371570ba9d97107ed4e76cfbfe4866e6ced1 Author: Lorenzo Bianconi Date: Fri Oct 17 11:06:14 2025 +0200 net: airoha: Generalize airoha_ppe2_is_enabled routine [ Upstream commit ef9449f080b61920cdc3d3106f8ffc2d9ba8b861 ] Rename airoha_ppe2_is_enabled() in airoha_ppe_is_enabled() and generalize it in order to check if each PPE module is enabled. Rely on airoha_ppe_is_enabled routine to properly initialize PPE for AN7583 SoC since AN7583 does not support PPE2. Reviewed-by: Simon Horman Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251017-an7583-eth-support-v3-5-f28319666667@kernel.org Signed-off-by: Paolo Abeni Stable-dep-of: 02f729643959 ("net: airoha: Fix FE_PSE_BUF_SET configuration if PPE2 is available") Signed-off-by: Sasha Levin commit 4ea17f5e51266b978a6f5b48cafe9118c0a980ab Author: Lorenzo Bianconi Date: Fri Oct 17 11:06:13 2025 +0200 net: airoha: Add airoha_eth_soc_data struct [ Upstream commit 5863b4e065e2253ef05684f728a04e4972046bcb ] Introduce airoha_eth_soc_data struct to contain differences between various SoC. Move XSI reset names in airoha_eth_soc_data. This is a preliminary patch to enable AN7583 ethernet controller support in airoha-eth driver. Co-developed-by: Christian Marangi Signed-off-by: Christian Marangi Reviewed-by: Simon Horman Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251017-an7583-eth-support-v3-4-f28319666667@kernel.org Signed-off-by: Paolo Abeni Stable-dep-of: 02f729643959 ("net: airoha: Fix FE_PSE_BUF_SET configuration if PPE2 is available") Signed-off-by: Sasha Levin commit ae1b40d3abc1d1309537f95e3b0f620c22b842b9 Author: Lorenzo Bianconi Date: Fri Oct 17 11:06:12 2025 +0200 net: airoha: Add airoha_ppe_get_num_stats_entries() and airoha_ppe_get_num_total_stats_entries() [ Upstream commit 15f357cd4581ce6e02e5e97719320600783140ec ] Introduce airoha_ppe_get_num_stats_entries and airoha_ppe_get_num_total_stats_entries routines in order to make the code more readable controlling if CONFIG_NET_AIROHA_FLOW_STATS is enabled or disabled. Modify airoha_ppe_foe_get_flow_stats_index routine signature relying on airoha_ppe_get_num_total_stats_entries(). Reviewed-by: Simon Horman Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251017-an7583-eth-support-v3-3-f28319666667@kernel.org Signed-off-by: Paolo Abeni Stable-dep-of: 02f729643959 ("net: airoha: Fix FE_PSE_BUF_SET configuration if PPE2 is available") Signed-off-by: Sasha Levin commit 987af7625ceb1ee59d70eb0abd7af11c75e45d79 Author: Mashiro Chen Date: Wed Apr 8 01:31:01 2026 +0800 net: hamradio: 6pack: fix uninit-value in sixpack_receive_buf [ Upstream commit bf9a38803b2626b01cc769aaf13485d8650f576f ] sixpack_receive_buf() does not properly skip bytes with TTY error flags. The while loop iterates through the flags buffer but never advances the data pointer (cp), and passes the original count (including error bytes) to sixpack_decode(). This causes sixpack_decode() to process bytes that should have been skipped due to TTY errors. The TTY layer does not guarantee that cp[i] holds a meaningful value when fp[i] is set, so passing those positions to sixpack_decode() results in KMSAN reporting an uninit-value read. Fix this by processing bytes one at a time, advancing cp on each iteration, and only passing valid (non-error) bytes to sixpack_decode(). This matches the pattern used by slip_receive_buf() and mkiss_receive_buf() for the same purpose. Reported-by: syzbot+ecdb8c9878a81eb21e54@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ecdb8c9878a81eb21e54 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Mashiro Chen Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260407173101.107352-1-mashiro.chen@mailbox.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e1ed678855e315f90c70c1723e94157a9a82e660 Author: Sechang Lim Date: Tue Apr 7 10:38:23 2026 +0000 bpf: Fix RCU stall in bpf_fd_array_map_clear() [ Upstream commit 4406942e65ca128c56c67443832988873c21d2e9 ] Add a missing cond_resched() in bpf_fd_array_map_clear() loop. For PROG_ARRAY maps with many entries this loop calls prog_array_map_poke_run() per entry which can be expensive, and without yielding this can cause RCU stalls under load: rcu: Stack dump where RCU GP kthread last ran: CPU: 0 UID: 0 PID: 30932 Comm: kworker/0:2 Not tainted 6.14.0-13195-g967e8def1100 #2 PREEMPT(undef) Workqueue: events prog_array_map_clear_deferred RIP: 0010:write_comp_data+0x38/0x90 kernel/kcov.c:246 Call Trace: prog_array_map_poke_run+0x77/0x380 kernel/bpf/arraymap.c:1096 __fd_array_map_delete_elem+0x197/0x310 kernel/bpf/arraymap.c:925 bpf_fd_array_map_clear kernel/bpf/arraymap.c:1000 [inline] prog_array_map_clear_deferred+0x119/0x1b0 kernel/bpf/arraymap.c:1141 process_one_work+0x898/0x19d0 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x770/0x10b0 kernel/workqueue.c:3400 kthread+0x465/0x880 kernel/kthread.c:464 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:153 ret_from_fork_asm+0x19/0x30 arch/x86/entry/entry_64.S:245 Reviewed-by: Sun Jian Fixes: da765a2f5993 ("bpf: Add poke dependency tracking for prog array maps") Signed-off-by: Sechang Lim Link: https://lore.kernel.org/r/20260407103823.3942156-1-rhkrqnwk98@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 592226d138378601ae28eb890e2bbc23ec3600f7 Author: Puranjay Mohan Date: Wed Apr 8 08:45:37 2026 -0700 bpf: return VMA snapshot from task_vma iterator [ Upstream commit 4cbee026db54cad39c39db4d356100cb133412b3 ] Holding the per-VMA lock across the BPF program body creates a lock ordering problem when helpers acquire locks that depend on mmap_lock: vm_lock -> i_rwsem -> mmap_lock -> vm_lock Snapshot the VMA under the per-VMA lock in _next() via memcpy(), then drop the lock before returning. The BPF program accesses only the snapshot. The verifier only trusts vm_mm and vm_file pointers (see BTF_TYPE_SAFE_TRUSTED_OR_NULL in verifier.c). vm_file is reference- counted with get_file() under the lock and released via fput() on the next iteration or in _destroy(). vm_mm is already correct because lock_vma_under_rcu() verifies vma->vm_mm == mm. All other pointers are left as-is by memcpy() since the verifier treats them as untrusted. Fixes: 4ac454682158 ("bpf: Introduce task_vma open-coded iterator kfuncs") Signed-off-by: Puranjay Mohan Acked-by: Andrii Nakryiko Acked-by: Mykyta Yatsenko Link: https://lore.kernel.org/r/20260408154539.3832150-4-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 3745834cf761f88ac3a8f5e65dbaebe11b04a846 Author: Puranjay Mohan Date: Wed Apr 8 08:45:36 2026 -0700 bpf: switch task_vma iterator from mmap_lock to per-VMA locks [ Upstream commit bee9ef4a40a277bf401be43d39ba7f7f063cf39c ] The open-coded task_vma iterator holds mmap_lock for the entire duration of iteration, increasing contention on this highly contended lock. Switch to per-VMA locking. Find the next VMA via an RCU-protected maple tree walk and lock it with lock_vma_under_rcu(). lock_next_vma() is not used because its fallback takes mmap_read_lock(), and the iterator must work in non-sleepable contexts. lock_vma_under_rcu() is a point lookup (mas_walk) that finds the VMA containing a given address but cannot iterate across gaps. An RCU-protected vma_next() walk (mas_find) first locates the next VMA's vm_start to pass to lock_vma_under_rcu(). Between the RCU walk and the lock, the VMA may be removed, shrunk, or write-locked. On failure, advance past it using vm_end from the RCU walk. Because the VMA slab is SLAB_TYPESAFE_BY_RCU, vm_end may be stale; fall back to PAGE_SIZE advancement when it does not make forward progress. Concurrent VMA insertions at addresses already passed by the iterator are not detected. CONFIG_PER_VMA_LOCK is required; return -EOPNOTSUPP without it. Signed-off-by: Puranjay Mohan Link: https://lore.kernel.org/r/20260408154539.3832150-3-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Stable-dep-of: 4cbee026db54 ("bpf: return VMA snapshot from task_vma iterator") Signed-off-by: Sasha Levin commit d0862de7c866c5bd7c32531f66738c21197af888 Author: Puranjay Mohan Date: Wed Apr 8 08:45:35 2026 -0700 bpf: fix mm lifecycle in open-coded task_vma iterator [ Upstream commit d8e27d2d22b6e2df3a0125b8c08e9aace38c954c ] The open-coded task_vma iterator reads task->mm locklessly and acquires mmap_read_trylock() but never calls mmget(). If the task exits concurrently, the mm_struct can be freed as it is not SLAB_TYPESAFE_BY_RCU, resulting in a use-after-free. Safely read task->mm with a trylock on alloc_lock and acquire an mm reference. Drop the reference via bpf_iter_mmput_async() in _destroy() and error paths. bpf_iter_mmput_async() is a local wrapper around mmput_async() with a fallback to mmput() on !CONFIG_MMU. Reject irqs-disabled contexts (including NMI) up front. Operations used by _next() and _destroy() (mmap_read_unlock, bpf_iter_mmput_async) take spinlocks with IRQs disabled (pool->lock, pi_lock). Running from NMI or from a tracepoint that fires with those locks held could deadlock. A trylock on alloc_lock is used instead of the blocking task_lock() (get_task_mm) to avoid a deadlock when a softirq BPF program iterates a task that already holds its alloc_lock on the same CPU. Fixes: 4ac454682158 ("bpf: Introduce task_vma open-coded iterator kfuncs") Signed-off-by: Puranjay Mohan Link: https://lore.kernel.org/r/20260408154539.3832150-2-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit b79d567fbc530efc2c3f1ed77e48b66fc8218571 Author: Florian Westphal Date: Thu Apr 9 13:30:41 2026 +0200 netfilter: nft_fwd_netdev: check ttl/hl before forwarding [ Upstream commit 1dfd95bdf4d18d263aa8fad06bfb9f4d9c992b18 ] Drop packets if their ttl/hl is too small for forwarding. Fixes: d32de98ea70f ("netfilter: nft_fwd_netdev: allow to forward packets via neighbour layer") Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 35a38df4085b3abe6c2d2bbcb6742a6d859cd3f1 Author: Florian Westphal Date: Sat Apr 4 12:12:59 2026 +0200 netfilter: xt_socket: enable defrag after all other checks [ Upstream commit 542be3fa5aff54210a02954c38f07e53ea9bdafd ] Originally this did not matter because defrag was enabled once per netns and only disabled again on netns dismantle. When this got changed I should have adjusted checkentry to not leave defrag enabled on error. Fixes: de8c12110a13 ("netfilter: disable defrag once its no longer needed") Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit b9ee2c6c076151eea8531ca5f6802b99f94de438 Author: Mohsin Bashir Date: Tue Apr 7 17:24:15 2026 -0700 eth: fbnic: Use wake instead of start [ Upstream commit 12ff2a4aee6c86746623d5aed24389dbf6dffded ] fbnic_up() calls netif_tx_start_all_queues(), which only clears __QUEUE_STATE_DRV_XOFF. If qdisc backlog has accumulated on any TX queue before the reconfiguration (e.g. ring resize via ethtool -G), start does not call __netif_schedule() to kick the qdisc, so the pending backlog is never drained and the queue stalls. Switch to netif_tx_wake_all_queues(), which clears DRV_XOFF and also calls __netif_schedule() on every queue, ensuring any backlog that built up before the down/up cycle is promptly dequeued. Fixes: bc6107771bb4 ("eth: fbnic: Allocate a netdevice and napi vectors with queues") Signed-off-by: Mohsin Bashir Link: https://patch.msgid.link/20260408002415.2963915-1-mohsin.bashr@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6d28910c51944ffe3bf79f91b6d3b3026e159d16 Author: Lorenzo Bianconi Date: Tue Apr 7 08:48:04 2026 +0200 net: airoha: Add dma_rmb() and READ_ONCE() in airoha_qdma_rx_process() [ Upstream commit 4ae0604a0673e11e2075b178387151fcad5111b5 ] Add missing dma_rmb() in airoha_qdma_rx_process routine to make sure the DMA read operations are completed when the NIC reports the processing on the current descriptor is done. Moreover, add missing READ_ONCE() in airoha_qdma_rx_process() for DMA descriptor control fields in order to avoid any compiler reordering. Fixes: 23020f0493270 ("net: airoha: Introduce ethernet support for EN7581 SoC") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260407-airoha_qdma_rx_process-fix-reordering-v3-1-91c36e9da31f@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c270e2bec3e55a716d25c35341091339457ac883 Author: Justin Chen Date: Mon Apr 6 10:57:56 2026 -0700 net: bcmgenet: fix racing timeout handler [ Upstream commit 5393b2b5bee2ac51a0043dc7f4ac3475f053d08d ] The bcmgenet_timeout handler tries to take down all tx queues when a single queue times out. This is over zealous and causes many race conditions with queues that are still chugging along. Instead lets only restart the timed out queue. Fixes: 13ea657806cf ("net: bcmgenet: improve TX timeout") Signed-off-by: Justin Chen Reviewed-by: Florian Fainelli Reviewed-by: Nicolai Buchwitz Tested-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260406175756.134567-4-justin.chen@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 25ff3a3e47ea635ec08dc93e84dd2bfe15abfebb Author: Justin Chen Date: Mon Apr 6 10:57:55 2026 -0700 net: bcmgenet: fix leaking free_bds [ Upstream commit 3f3168300efb839028328d720ab3962f91d6a0d0 ] While reclaiming the tx queue we fast forward the write pointer to drop any data in flight. These dropped frames are not added back to the pool of free bds. We also need to tell the netdev that we are dropping said data. Fixes: f1bacae8b655 ("net: bcmgenet: support reclaiming unsent Tx packets") Signed-off-by: Justin Chen Reviewed-by: Florian Fainelli Reviewed-by: Nicolai Buchwitz Tested-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260406175756.134567-3-justin.chen@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4cab761fc51c65aef741fcece4a18f3554edbc09 Author: Justin Chen Date: Mon Apr 6 10:57:54 2026 -0700 net: bcmgenet: fix off-by-one in bcmgenet_put_txcb [ Upstream commit 57f3f53d2c9c5a9e133596e2f7bc1c50688a6d38 ] The write_ptr points to the next open tx_cb. We want to return the tx_cb that gets rewinded, so we must rewind the pointer first then return the tx_cb that it points to. That way the txcb can be correctly cleaned up. Fixes: 876dbadd53a7 ("net: bcmgenet: Fix unmapping of fragments in bcmgenet_xmit()") Signed-off-by: Justin Chen Reviewed-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260406175756.134567-2-justin.chen@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0d8726af877e0d6256990e33ac0cdc38b51f989e Author: Cosmin Ratiu Date: Wed Apr 8 14:52:40 2026 +0300 macsec: Support VLAN-filtering lower devices [ Upstream commit a363b1c8be879c79a688eaf93ba01b63f8b0e63c ] VLAN-filtering is done through two netdev features (NETIF_F_HW_VLAN_CTAG_FILTER and NETIF_F_HW_VLAN_STAG_FILTER) and two netdev ops (ndo_vlan_rx_add_vid and ndo_vlan_rx_kill_vid). Implement these and advertise the features if the lower device supports them. This allows proper VLAN filtering to work on top of MACsec devices, when the lower device is capable of VLAN filtering. As a concrete example, having this chain of interfaces now works: vlan_filtering_capable_dev(1) -> macsec_dev(2) -> macsec_vlan_dev(3) Before the mentioned commit this used to accidentally work because the MACsec device (and thus the lower device) was put in promiscuous mode and the VLAN filter was not used. But after commit [1] correctly made the macsec driver expose the IFF_UNICAST_FLT flag, promiscuous mode was no longer used and VLAN filters on dev 1 kicked in. Without support in dev 2 for propagating VLAN filters down, the register_vlan_dev -> vlan_vid_add -> __vlan_vid_add -> vlan_add_rx_filter_info call from dev 3 is silently eaten (because vlan_hw_filter_capable returns false and vlan_add_rx_filter_info silently succeeds). For MACsec, VLAN filters are only relevant for offload, otherwise the VLANs are encrypted and the lower devices don't care about them. So VLAN filters are only passed on to lower devices in offload mode. Flipping between offload modes now needs to offload/unoffload the filters with vlan_{get,drop}_rx_*_filter_info(). To avoid the back-and-forth filter updating during rollback, the setting of macsec->offload is moved after the add/del secy ops. This is safe since none of the code called from those requires macsec->offload. In case adding the filters fails, the added ones are rolled back and an error is returned to the operation toggling the offload state. Fixes: 0349659fd72f ("macsec: set IFF_UNICAST_FLT priv flag") Signed-off-by: Cosmin Ratiu Reviewed-by: Sabrina Dubroca Link: https://patch.msgid.link/20260408115240.1636047-5-cratiu@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f33fb701ab7e709ba965d6a7da6e4141b725fdbf Author: Wang Wensheng Date: Sun Apr 5 19:42:31 2026 +0800 arm64: kexec: Remove duplicate allocation for trans_pgd [ Upstream commit ee020bf6f14094c9ae434bb37e6957a1fdad513c ] trans_pgd would be allocated in trans_pgd_create_copy(), so remove the duplicate allocation before calling trans_pgd_create_copy(). Fixes: 3744b5280e67 ("arm64: kexec: install a copy of the linear-map") Signed-off-by: Wang Wensheng Reviewed-by: Pasha Tatashin Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit bcfdf159d128debbe31630141cb08bb5d5a02cfc Author: Haoyu Lu Date: Tue Apr 7 11:31:15 2026 +0800 ACPI: AGDI: fix missing newline in error message [ Upstream commit b178330b67abb7293b6de28b2a49d49c83962db5 ] Add the missing trailing newline to the dev_err() message printed when SDEI event registration fails. This keeps the error output as a properly terminated log line. Fixes: a2a591fb76e6 ("ACPI: AGDI: Add driver for Arm Generic Diagnostic Dump and Reset device") Reviewed-by: Ilkka Koskinen Signed-off-by: Haoyu Lu Reviewed-by: Hanjun Guo Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 73ae96e2be4e28891519c0ebc23a21990fc20a80 Author: Mark Rutland Date: Tue Apr 7 14:16:46 2026 +0100 arm64: entry: Don't preempt with SError or Debug masked [ Upstream commit 2371bd83b3df9d833191fe58dadb0e69a794a1cd ] On arm64, involuntary kernel preemption has been subtly broken since the move to the generic irqentry code. When preemption occurs, the new task may run with SError and Debug exceptions masked unexpectedly, leading to a loss of RAS events, breakpoints, watchpoints, and single-step exceptions. Prior to moving to the generic irqentry code, involuntary preemption of kernel mode would only occur when returning from regular interrupts, in a state where interrupts were masked and all other arm64-specific exceptions (SError, Debug, and pseudo-NMI) were unmasked. This is the only state in which it is valid to switch tasks. As part of moving to the generic irqentry code, the involuntary preemption logic was moved such that involuntary preemption could occur when returning from any (non-NMI) exception. As most exception handlers mask all arm64-specific exceptions before this point, preemption could occur in a state where arm64-specific exceptions were masked. This is not a valid state to switch tasks, and resulted in the loss of exceptions described above. As a temporary bodge, avoid the loss of exceptions by avoiding involuntary preemption when SError and/or Debug exceptions are masked. Practically speaking this means that involuntary preemption will only occur when returning from regular interrupts, as was the case before moving to the generic irqentry code. Fixes: 99eb057ccd67 ("arm64: entry: Move arm64_preempt_schedule_irq() into __exit_to_kernel_mode()") Reported-by: Ada Couprie Diaz Reported-by: Vladimir Murzin Signed-off-by: Mark Rutland Cc: Andy Lutomirski Cc: Jinjie Ruan Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Reviewed-by: Jinjie Ruan Acked-by: Peter Zijlstra (Intel) Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit d88e8e4a3b52bd5b2ff3eceba4b29d1b5506d066 Author: Daniel Borkmann Date: Tue Apr 7 21:24:18 2026 +0200 bpf: Fix linked reg delta tracking when src_reg == dst_reg [ Upstream commit d7f14173c0d5866c3cae759dee560ad1bed10d2e ] Consider the case of rX += rX where src_reg and dst_reg are pointers to the same bpf_reg_state in adjust_reg_min_max_vals(). The latter first modifies the dst_reg in-place, and later in the delta tracking, the subsequent is_reg_const(src_reg)/reg_const_value(src_reg) reads the post-{add,sub} value instead of the original source. This is problematic since it sets an incorrect delta, which sync_linked_regs() then propagates to linked registers, thus creating a verifier-vs-runtime mismatch. Fix it by just skipping this corner case. Fixes: 98d7ca374ba4 ("bpf: Track delta between "linked" registers.") Reported-by: STAR Labs SG Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260407192421.508817-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 9f88b29b79a06dfd362d6f8dec51aece25683135 Author: Puranjay Mohan Date: Wed Feb 4 07:17:37 2026 -0800 bpf: Support negative offsets, BPF_SUB, and alu32 for linked register tracking [ Upstream commit 7a433e519364c3c19643e5c857f4fbfaebec441c ] Previously, the verifier only tracked positive constant deltas between linked registers using BPF_ADD. This limitation meant patterns like: r1 = r0; r1 += -4; if r1 s>= 0 goto l0_%=; // r1 >= 0 implies r0 >= 4 // verifier couldn't propagate bounds back to r0 if r0 != 0 goto l0_%=; r0 /= 0; // Verifier thinks this is reachable l0_%=: Similar limitation exists for 32-bit registers. With this change, the verifier can now track negative deltas in reg->off enabling bound propagation for the above pattern. For alu32, we make sure the destination register has the upper 32 bits as 0s before creating the link. BPF_ADD_CONST is split into BPF_ADD_CONST64 and BPF_ADD_CONST32, the latter is used in case of alu32 and sync_linked_regs uses this to zext the result if known_reg has this flag. Signed-off-by: Puranjay Mohan Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260204151741.2678118-2-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Stable-dep-of: d7f14173c0d5 ("bpf: Fix linked reg delta tracking when src_reg == dst_reg") Signed-off-by: Sasha Levin commit 25463350662650504636f08eb82ba2bc2fd6cd5c Author: Baochen Qiang Date: Wed Mar 25 11:05:01 2026 +0800 wifi: ath10k: fix station lookup failure during disconnect [ Upstream commit 9a34a59c6086ae731a06b3e61b0951feef758648 ] Recent commit [1] moved station statistics collection to an earlier stage of the disconnect flow. With this change in place, ath10k fails to resolve the station entry when handling a peer stats event triggered during disconnect, resulting in log messages such as: wlp58s0: deauthenticating from 74:1a:e0:e7:b4:c8 by local choice (Reason: 3=DEAUTH_LEAVING) ath10k_pci 0000:3a:00.0: not found station for peer stats ath10k_pci 0000:3a:00.0: failed to parse stats info tlv: -22 The failure occurs because ath10k relies on ieee80211_find_sta_by_ifaddr() for station lookup. That function uses local->sta_hash, but by the time the peer stats request is triggered during disconnect, mac80211 has already removed the station from that hash table, leading to lookup failure. Before commit [1], this issue was not visible because the transition from IEEE80211_STA_NONE to IEEE80211_STA_NOTEXIST prevented ath10k from sending a peer stats request at all: ath10k_mac_sta_get_peer_stats_info() would fail early to find the peer and skip requesting statistics. Fix this by switching the lookup path to ath10k_peer_find(), which queries ath10k's internal peer table. At the point where the firmware emits the peer stats event, the peer entry is still present in the driver's list, ensuring lookup succeeds. Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00309-QCARMSWPZ-1 Fixes: a203dbeeca15 ("wifi: mac80211: collect station statistics earlier when disconnect") # [1] Reported-by: Paul Menzel Closes: https://lore.kernel.org/ath10k/57671b89-ec9f-4e6c-992c-45eb8e75929c@molgen.mpg.de Signed-off-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Reviewed-by: Paul Menzel Tested-by: Paul Menzel Link: https://patch.msgid.link/20260325-ath10k-station-lookup-failure-v1-1-2e0c970f25d5@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 76f2ebaf79a9ae6d0737b87f045fe769e425d78f Author: Weiming Shi Date: Sun Apr 5 00:12:20 2026 +0800 bpf: reject negative CO-RE accessor indices in bpf_core_parse_spec() [ Upstream commit 1c22483a2c4bbf747787f328392ca3e68619c4dc ] CO-RE accessor strings are colon-separated indices that describe a path from a root BTF type to a target field, e.g. "0:1:2" walks through nested struct members. bpf_core_parse_spec() parses each component with sscanf("%d"), so negative values like -1 are silently accepted. The subsequent bounds checks (access_idx >= btf_vlen(t)) only guard the upper bound and always pass for negative values because C integer promotion converts the __u16 btf_vlen result to int, making the comparison (int)(-1) >= (int)(N) false for any positive N. When -1 reaches btf_member_bit_offset() it gets cast to u32 0xffffffff, producing an out-of-bounds read far past the members array. A crafted BPF program with a negative CO-RE accessor on any struct that exists in vmlinux BTF (e.g. task_struct) crashes the kernel deterministically during BPF_PROG_LOAD on any system with CONFIG_DEBUG_INFO_BTF=y (default on major distributions). The bug is reachable with CAP_BPF: BUG: unable to handle page fault for address: ffffed11818b6626 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 85 Comm: poc Not tainted 7.0.0-rc6 #18 PREEMPT(full) RIP: 0010:bpf_core_parse_spec (tools/lib/bpf/relo_core.c:354) RAX: 00000000ffffffff Call Trace: bpf_core_calc_relo_insn (tools/lib/bpf/relo_core.c:1321) bpf_core_apply (kernel/bpf/btf.c:9507) check_core_relo (kernel/bpf/verifier.c:19475) bpf_check (kernel/bpf/verifier.c:26031) bpf_prog_load (kernel/bpf/syscall.c:3089) __sys_bpf (kernel/bpf/syscall.c:6228) CO-RE accessor indices are inherently non-negative (struct member index, array element index, or enumerator index), so reject them immediately after parsing. Fixes: ddc7c3042614 ("libbpf: implement BPF CO-RE offset relocation algorithm") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Reviewed-by: Emil Tsalapatis Acked-by: Paul Chaignon Link: https://lore.kernel.org/r/20260404161221.961828-2-bestswngs@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 281f2a214565a5cbf8b7355a65738d80bd19b8c5 Author: Jiayuan Chen Date: Tue Apr 7 20:23:33 2026 +0800 bpf: Drop task_to_inode and inet_conn_established from lsm sleepable hooks [ Upstream commit beaf0e96b1da74549a6cabd040f9667d83b2e97e ] bpf_lsm_task_to_inode() is called under rcu_read_lock() and bpf_lsm_inet_conn_established() is called from softirq context, so neither hook can be used by sleepable LSM programs. Fixes: 423f16108c9d8 ("bpf: Augment the set of sleepable LSM hooks") Reported-by: Quan Sun <2022090917019@std.uestc.edu.cn> Reported-by: Yinhao Hu Reported-by: Kaiyan Mei Reported-by: Dongliang Mu Closes: https://lore.kernel.org/bpf/3ab69731-24d1-431a-a351-452aafaaf2a5@std.uestc.edu.cn/T/#u Signed-off-by: Jiayuan Chen Link: https://lore.kernel.org/r/20260407122334.344072-1-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit a9937a3ac5857f6308bf42fe43ed37870030319e Author: Nicolas Escande Date: Fri Mar 27 11:02:56 2026 +0100 wifi: mac80211: handle VHT EXT NSS in ieee80211_determine_our_sta_mode() [ Upstream commit b5b8e295973083abf823fb66647a7c702a8db8a7 ] A station which has a NSS ratio on the number of streams it is capable of in 160MHz VHT operation is supposed to use the 'Extended NSS BW Support' as defined by section '9.4.2.156.2 VHT Capabilities Information field'. This was missing in ieee80211_determine_our_sta_mode() and so we would wrongfully downgrade our bandwidth when connecting to an AP that supported 160MHz with messages such as: [ 37.638346] wlan1: AP XX:XX:XX:XX:XX:XX changed bandwidth in assoc response, new used config is 5280.000 MHz, width 3 (5290.000/0 MHz) Fixes: 310c8387c638 ("wifi: mac80211: clean up connection process") Signed-off-by: Nicolas Escande Link: https://patch.msgid.link/20260327100256.3101348-1-nico.escande@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit cbea71b4480394708f9a6e007a0385acfe5e1ec8 Author: Ethan Tidmore Date: Mon Feb 16 20:30:43 2026 -0600 wifi: brcmfmac: Fix error pointer dereference [ Upstream commit dd8592fc6007a451c3e4b9025de365e39de8178a ] The function brcmf_chip_add_core() can return an error pointer and is not checked. Add checks for error pointer. Detected by Smatch: drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1010 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1013 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1016 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1019 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1022 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() Fixes: cb7cf7be9eba7 ("brcmfmac: make chip related functions host interface independent") Signed-off-by: Ethan Tidmore Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260217023043.73631-1-ethantidmore06@gmail.com [add missing wifi: prefix] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit a710df104abbb5435db4d2618aad6b09b0e81ca0 Author: Arnd Bergmann Date: Thu Apr 2 20:46:54 2026 +0200 net: ethernet: ti-cpsw: fix linking built-in code to modules [ Upstream commit df75bd552a8790e83d4aeb5f112050cf3dc687bf ] There are six variants of the cpsw driver, sharing various parts of the code: davinci-emac, cpsw, cpsw-switchdev, netcp, netcp_ethss and am65-cpsw-nuss. I noticed that this means some files can be linked into more than one loadable module, or even part of vmlinux but also linked into a loadable module, both of which mess up assumptions of the build system, and causes warnings: scripts/Makefile.build:279: cpsw_ale.o is added to multiple modules: ti-am65-cpsw-nuss ti_cpsw ti_cpsw_new scripts/Makefile.build:279: cpsw_priv.o is added to multiple modules: ti_cpsw ti_cpsw_new scripts/Makefile.build:279: cpsw_sl.o is added to multiple modules: ti-am65-cpsw-nuss ti_cpsw ti_cpsw_new scripts/Makefile.build:279: cpsw_ethtool.o is added to multiple modules: ti_cpsw ti_cpsw_new scripts/Makefile.build:279: davinci_cpdma.o is added to multiple modules: ti_cpsw ti_cpsw_new ti_davinci_emac Change this back to having separate modules for each portion that can be linked standalone, exporting symbols as needed: - ti-cpsw-common.ko now contains both cpsw-common.o and davinci_cpdma.o as they are always used together - ti-cpsw-priv.ko contains cpsw_priv.o, cpsw_sl.o and cpsw_ethtool.o, which are the core of the cpsw and cpsw-new drivers. - ti-cpsw-sl.ko contains the cpsw-sl.o object and is used on ti-am65-cpsw-nuss.ko in addition to the two other cpsw variants. - ti-cpsw-ale.o is the one standalone module that is used by all except davinci_emac. Each of these will be built-in if any of its users are built-in, otherwise it's a loadable module if there is at least one module using it. I did not bring back the separate Kconfig symbols for this, but just handle it using Makefile logic. Note: ideally this is something that Kbuild complains about, but usually we just notice when something using THIS_MODULE misbehaves in a way that a user notices. Fixes: 99f6297182729 ("net: ethernet: ti: cpsw: drop TI_DAVINCI_CPDMA config option") Link: https://lore.kernel.org/lkml/20240417084400.3034104-1-arnd@kernel.org/ Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20260402184726.3746487-2-arnd@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2bbe3d5c93534927b47dc26abe23704b0f2b38b0 Author: Arnd Bergmann Date: Thu Apr 2 20:46:53 2026 +0200 net: ethernet: ti-cpsw:: rename soft_reset() function [ Upstream commit 961f3c535608df64553f61d64ca086aa9f371bdd ] While looking at the glob symbols shared between the cpsw drivers, I noticed that soft_reset() is the only one that is missing a proper namespace prefix, and will pollute the kernel namespace, so rename it to be consistent with the other symbols. Reviewed-by: Alexander Sverdlin Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20260402184726.3746487-1-arnd@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: df75bd552a87 ("net: ethernet: ti-cpsw: fix linking built-in code to modules") Signed-off-by: Sasha Levin commit 059525cf18e69a9313baf947d8898c6ee7ca6b65 Author: MingTao Huang Date: Thu Apr 2 20:18:50 2026 +0800 bpf: Fix stale offload->prog pointer after constant blinding [ Upstream commit a1aa9ef47c299c5bbc30594d3c2f0589edf908e6 ] When a dev-bound-only BPF program (BPF_F_XDP_DEV_BOUND_ONLY) undergoes JIT compilation with constant blinding enabled (bpf_jit_harden >= 2), bpf_jit_blind_constants() clones the program. The original prog is then freed in bpf_jit_prog_release_other(), which updates aux->prog to point to the surviving clone, but fails to update offload->prog. This leaves offload->prog pointing to the freed original program. When the network namespace is subsequently destroyed, cleanup_net() triggers bpf_dev_bound_netdev_unregister(), which iterates ondev->progs and calls __bpf_prog_offload_destroy(offload->prog). Accessing the freed prog causes a page fault: BUG: unable to handle page fault for address: ffffc900085f1038 Workqueue: netns cleanup_net RIP: 0010:__bpf_prog_offload_destroy+0xc/0x80 Call Trace: __bpf_offload_dev_netdev_unregister+0x257/0x350 bpf_dev_bound_netdev_unregister+0x4a/0x90 unregister_netdevice_many_notify+0x2a2/0x660 ... cleanup_net+0x21a/0x320 The test sequence that triggers this reliably is: 1. Set net.core.bpf_jit_harden=2 (echo 2 > /proc/sys/net/core/bpf_jit_harden) 2. Run xdp_metadata selftest, which creates a dev-bound-only XDP program on a veth inside a netns (./test_progs -t xdp_metadata) 3. cleanup_net -> page fault in __bpf_prog_offload_destroy Dev-bound-only programs are unique in that they have an offload structure but go through the normal JIT path instead of bpf_prog_offload_compile(). This means they are subject to constant blinding's prog clone-and-replace, while also having offload->prog that must stay in sync. Fix this by updating offload->prog in bpf_jit_prog_release_other(), alongside the existing aux->prog update. Both are back-pointers to the prog that must be kept in sync when the prog is replaced. Fixes: 2b3486bc2d23 ("bpf: Introduce device-bound XDP programs") Signed-off-by: MingTao Huang Link: https://lore.kernel.org/r/tencent_BCF692F45859CCE6C22B7B0B64827947D406@qq.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 32ce55d424395904986f5066f8755f6cb9993377 Author: Weiming Shi Date: Fri Apr 3 21:29:50 2026 +0800 bpf: fix end-of-list detection in cgroup_storage_get_next_key() [ Upstream commit 5828b9e5b272ecff7cf5d345128d3de7324117f7 ] list_next_entry() never returns NULL -- when the current element is the last entry it wraps to the list head via container_of(). The subsequent NULL check is therefore dead code and get_next_key() never returns -ENOENT for the last element, instead reading storage->key from a bogus pointer that aliases internal map fields and copying the result to userspace. Replace it with list_entry_is_head() so the function correctly returns -ENOENT when there are no more entries. Fixes: de9cbbaadba5 ("bpf: introduce cgroup storage maps") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Reviewed-by: Sun Jian Acked-by: Paul Chaignon Link: https://lore.kernel.org/r/20260403132951.43533-2-bestswngs@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit d3d3d2791c59d42d5c9f5759c944647edff5f8a8 Author: Eric Dumazet Date: Wed Apr 1 10:38:08 2026 +0000 macvlan: annotate data-races around port->bc_queue_len_used [ Upstream commit 1ef5789d9906df3771c99b7f413caaf2bf473ca5 ] port->bc_queue_len_used is read and written locklessly, add READ_ONCE()/WRITE_ONCE() annotations. While WRITE_ONCE() in macvlan_fill_info() is not yet needed, it is a prereq for future RTNL avoidance. Fixes: d4bff72c8401 ("macvlan: Support for high multicast packet rate") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260401103809.3038139-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b312cf41b9e43f442613053f6cad39898e1baf96 Author: Leon Hwang Date: Tue Mar 31 22:53:52 2026 +0800 bpf: Fix abuse of kprobe_write_ctx via freplace [ Upstream commit 611fe4b79af72d00d80f2223354284447daafae9 ] uprobe programs are allowed to modify struct pt_regs. Since the actual program type of uprobe is KPROBE, it can be abused to modify struct pt_regs via kprobe+freplace when the kprobe attaches to kernel functions. For example, SEC("?kprobe") int kprobe(struct pt_regs *regs) { return 0; } SEC("?freplace") int freplace_kprobe(struct pt_regs *regs) { regs->di = 0; return 0; } freplace_kprobe prog will attach to kprobe prog. kprobe prog will attach to a kernel function. Without this patch, when the kernel function runs, its first arg will always be set as 0 via the freplace_kprobe prog. To fix the abuse of kprobe_write_ctx=true via kprobe+freplace, disallow attaching freplace programs on kprobe programs with different kprobe_write_ctx values. Fixes: 7384893d970e ("bpf: Allow uprobe program to change context registers") Acked-by: Jiri Olsa Acked-by: Song Liu Signed-off-by: Leon Hwang Link: https://lore.kernel.org/r/20260331145353.87606-2-leon.hwang@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit d41508adff0125f75df03290000cb1d615983650 Author: Amit Machhiwal Date: Fri Mar 13 22:24:26 2026 +0530 selftests/powerpc: Suppress -Wmaybe-uninitialized with GCC 15 [ Upstream commit 6e65886fceb23605eff952d6b1975737b4c4b154 ] GCC 15 reports the below false positive '-Wmaybe-uninitialized' warning in vphn_unpack_associativity() when building the powerpc selftests. # make -C tools/testing/selftests TARGETS="powerpc" [...] CC test-vphn In file included from test-vphn.c:3: In function ‘vphn_unpack_associativity’, inlined from ‘test_one’ at test-vphn.c:371:2, inlined from ‘test_vphn’ at test-vphn.c:399:9: test-vphn.c:10:33: error: ‘be_packed’ may be used uninitialized [-Werror=maybe-uninitialized] 10 | #define be16_to_cpup(x) bswap_16(*x) | ^~~~~~~~ vphn.c:42:27: note: in expansion of macro ‘be16_to_cpup’ 42 | u16 new = be16_to_cpup(field++); | ^~~~~~~~~~~~ In file included from test-vphn.c:19: vphn.c: In function ‘test_vphn’: vphn.c:27:16: note: ‘be_packed’ declared here 27 | __be64 be_packed[VPHN_REGISTER_COUNT]; | ^~~~~~~~~ cc1: all warnings being treated as errors When vphn_unpack_associativity() is called from hcall_vphn() in kernel the error is not seen while building vphn.c during kernel compilation. This is because the top level Makefile includes '-fno-strict-aliasing' flag always. The issue here is that GCC 15 emits '-Wmaybe-uninitialized' due to type punning between __be64[] and __b16* when accessing the buffer via be16_to_cpup(). The underlying object is fully initialized but GCC 15 fails to track the aliasing due to the strict aliasing violation here. Please refer [1] and [2]. This results in a false positive warning which is promoted to an error under '-Werror'. This problem is not seen when the compilation is performed with GCC 13 and 14. An issue [1] has also been created on GCC bugzilla. The selftest compiles fine with '-fno-strict-aliasing'. Since this GCC flag is used to compile vphn.c in kernel too, the same flag should be used to build vphn tests when compiling vphn.c in the selftest as well. Fix this by including '-fno-strict-aliasing' during vphn.c compilation in the selftest. This keeps the build working while limiting the scope of the suppression to building vphn tests. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124427 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99768 Fixes: 58dae82843f5 ("selftests/powerpc: Add test for VPHN") Reviewed-by: Vaibhav Jain Signed-off-by: Amit Machhiwal Tested-by: Venkat Rao Bagalkote Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260313165426.43259-1-amachhiw@linux.ibm.com Signed-off-by: Sasha Levin commit 9103787054c685b6bbe242d4e3911714092b4c2b Author: Sourabh Jain Date: Thu Mar 12 14:00:50 2026 +0530 powerpc/crash: Update backup region offset in elfcorehdr on memory hotplug [ Upstream commit f53b24d1fa263f56155213eabab734c18d884aff ] When elfcorehdr is prepared for kdump, the program header representing the first 64 KB of memory is expected to have its offset point to the backup region. This is required because purgatory copies the first 64 KB of the crashed kernel memory to this backup region following a kernel crash. This allows the capture kernel to use the first 64 KB of memory to place the exception vectors and other required data. When elfcorehdr is recreated due to memory hotplug, the offset of the program header representing the first 64 KB is not updated. As a result, the capture kernel exports the first 64 KB at offset 0, even though the data actually resides in the backup region. Fix this by calling sync_backup_region_phdr() to update the program header offset in the elfcorehdr created during memory hotplug. sync_backup_region_phdr() works for images loaded via the kexec_file_load syscall. However, it does not work for kexec_load, because image->arch.backup_start is not initialized in that case. So introduce machine_kexec_post_load() to process the elfcorehdr prepared by kexec-tools and initialize image->arch.backup_start for kdump images loaded via kexec_load syscall. Rename update_backup_region_phdr() to sync_backup_region_phdr() and extend it to synchronize the backup region offset between the kdump image and the ELF core header. The helper now supports updating either the kdump image from the ELF program header or updating the ELF program header from the kdump image, avoiding code duplication. Define ARCH_HAS_KIMAGE_ARCH and struct kimage_arch when CONFIG_KEXEC_FILE or CONFIG_CRASH_DUMP is enabled so that kimage->arch.backup_start is available with the kexec_load system call. This patch depends on the patch titled "powerpc/crash: fix backup region offset update to elfcorehdr". Fixes: 849599b702ef ("powerpc/crash: add crash memory hotplug support") Reviewed-by: Aditya Gupta Signed-off-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260312083051.1935737-3-sourabhjain@linux.ibm.com Signed-off-by: Sasha Levin commit eef879190a1f2365d403219cc94f101c3d04144c Author: Sourabh Jain Date: Thu Mar 12 14:00:49 2026 +0530 powerpc/crash: fix backup region offset update to elfcorehdr [ Upstream commit 789335cacdf37da93bb7c70322dff8c7e82881df ] update_backup_region_phdr() in file_load_64.c iterates over all the program headers in the kdump kernel’s elfcorehdr and updates the p_offset of the program header whose physical address starts at 0. However, the loop logic is incorrect because the program header pointer is not updated during iteration. Since elfcorehdr typically contains PT_NOTE entries first, the PT_LOAD program header with physical address 0 is never reached. As a result, its p_offset is not updated to point to the backup region. Because of this behavior, the capture kernel exports the first 64 KB of the crashed kernel’s memory at offset 0, even though that memory actually lives in the backup region. When a crash happens, purgatory copies the first 64 KB of the crashed kernel’s memory into the backup region so the capture kernel can safely use it. This has not caused problems so far because the first 64 KB is usually identical in both the crashed and capture kernels. However, this is just an assumption and is not guaranteed to always hold true. Fix update_backup_region_phdr() to correctly update the p_offset of the program header with a starting physical address of 0 by correcting the logic used to iterate over the program headers. Fixes: cb350c1f1f86 ("powerpc/kexec_file: Prepare elfcore header for crashing kernel") Reviewed-by: Aditya Gupta Signed-off-by: Sourabh Jain Reviewed-by: Hari Bathini Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260312083051.1935737-2-sourabhjain@linux.ibm.com Signed-off-by: Sasha Levin commit 50c601805fe3b0547fb963e6f47969ab4c5da40b Author: Chih Kai Hsu Date: Thu Mar 26 15:39:23 2026 +0800 r8152: fix incorrect register write to USB_UPHY_XTAL [ Upstream commit 48afd5124fd6129c46fd12cb06155384b1c4a0c4 ] The old code used ocp_write_byte() to clear the OOBS_POLLING bit (BIT(8)) in the USB_UPHY_XTAL register, but this doesn't correctly clear a bit in the upper byte of the 16-bit register. Fix this by using ocp_write_word() instead. Fixes: 195aae321c82 ("r8152: support new chips") Signed-off-by: Chih Kai Hsu Reviewed-by: Hayes Wang Link: https://patch.msgid.link/20260326073925.32976-454-nic_swsd@realtek.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ae5f83c0809f3442bb69f2284e44557e3b9d074d Author: Ritesh Harjani (IBM) Date: Mon Mar 9 18:08:37 2026 +0530 drivers/vfio_pci_core: Change PXD_ORDER check from switch case to if/else block [ Upstream commit 948b71aa81cd89b222942db6055e8d9c51c54e78 ] Architectures like PowerPC uses runtime defined values for PMD_ORDER/PUD_ORDER. This is because it can use either RADIX or HASH MMU at runtime using kernel cmdline. So the pXd_index_size is not known at compile time. Without this fix, when we add huge pfn support on powerpc in the next patch, vfio_pci_core driver compilation can fail with the following errors. CC [M] drivers/vfio/vfio_main.o CC [M] drivers/vfio/group.o CC [M] drivers/vfio/container.o CC [M] drivers/vfio/virqfd.o CC [M] drivers/vfio/vfio_iommu_spapr_tce.o CC [M] drivers/vfio/pci/vfio_pci_core.o CC [M] drivers/vfio/pci/vfio_pci_intrs.o CC [M] drivers/vfio/pci/vfio_pci_rdwr.o CC [M] drivers/vfio/pci/vfio_pci_config.o CC [M] drivers/vfio/pci/vfio_pci.o AR kernel/built-in.a ../drivers/vfio/pci/vfio_pci_core.c: In function ‘vfio_pci_vmf_insert_pfn’: ../drivers/vfio/pci/vfio_pci_core.c:1678:9: error: case label does not reduce to an integer constant 1678 | case PMD_ORDER: | ^~~~ ../drivers/vfio/pci/vfio_pci_core.c:1682:9: error: case label does not reduce to an integer constant 1682 | case PUD_ORDER: | ^~~~ make[6]: *** [../scripts/Makefile.build:289: drivers/vfio/pci/vfio_pci_core.o] Error 1 make[6]: *** Waiting for unfinished jobs.... make[5]: *** [../scripts/Makefile.build:546: drivers/vfio/pci] Error 2 make[5]: *** Waiting for unfinished jobs.... make[4]: *** [../scripts/Makefile.build:546: drivers/vfio] Error 2 make[3]: *** [../scripts/Makefile.build:546: drivers] Error 2 Fixes: f9e54c3a2f5b7 ("vfio/pci: implement huge_fault support") Signed-off-by: Ritesh Harjani (IBM) Tested-by: Venkat Rao Bagalkote Reviewed-by: Alex Williamson Reviewed-by: Christophe Leroy (CS GROUP) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/b155e19993ee1f5584c72050192eb468b31c5029.1773058761.git.ritesh.list@gmail.com Signed-off-by: Sasha Levin commit fa3b3e43e8834617ab4980eeeab9352ab9dd46c0 Author: Ankit Agrawal Date: Thu Nov 27 17:06:27 2025 +0000 vfio: refactor vfio_pci_mmap_huge_fault function [ Upstream commit 9b92bc7554b543dc00a0a0b62904a9ef2ad5c4b0 ] Refactor vfio_pci_mmap_huge_fault to take out the implementation to map the VMA to the PTE/PMD/PUD as a separate function. Export the new function to be used by nvgrace-gpu module. Move the alignment check code to verify that pfn and VMA VA is aligned to the page order to the header file and make it inline. No functional change is intended. Cc: Shameer Kolothum Cc: Alex Williamson Cc: Jason Gunthorpe Reviewed-by: Shameer Kolothum Signed-off-by: Ankit Agrawal Link: https://lore.kernel.org/r/20251127170632.3477-2-ankita@nvidia.com Signed-off-by: Alex Williamson Stable-dep-of: 948b71aa81cd ("drivers/vfio_pci_core: Change PXD_ORDER check from switch case to if/else block") Signed-off-by: Sasha Levin commit 6b9694702c379ef71c89114bc39baee547557393 Author: Alexey Velichayshiy Date: Mon Mar 23 17:05:53 2026 +0300 wifi: rtw89: phy: fix uninitialized variable access in rtw89_phy_cfo_set_crystal_cap() [ Upstream commit 047cddf88c611e616d49a00311d4722e46286234 ] In the rtw89_phy_cfo_set_crystal_cap() function, for chips other than RTL8852A/RTL8851B, the values read by rtw89_mac_read_xtal_si() are stored into the local variables sc_xi_val and sc_xo_val. If either read fails, these variables remain uninitialized, they are later used to update cfo->crystal_cap and in debug print statements. This can lead to undefined behavior. Fix the issue by initializing sc_xi_val and sc_xo_val to zero, like is implemented in vendor driver. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 8379fa611536 ("rtw89: 8852c: add write/read crystal function in CFO tracking") Signed-off-by: Alexey Velichayshiy Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260323140613.1615574-1-a.velichayshiy@ispras.ru Signed-off-by: Sasha Levin commit 97757d231bc64fba69525b01b562187e4c619854 Author: haoyu.lu Date: Tue Mar 24 20:27:02 2026 +0800 bpf,arc_jit: Fix missing newline in pr_err messages [ Upstream commit b6b5e0ebd429d66ce37ae5af649a74ea1f041d92 ] Add missing newline to pr_err messages in ARC JIT. Fixes: f122668ddcce ("ARC: Add eBPF JIT support") Signed-off-by: haoyu.lu Link: https://lore.kernel.org/r/20260324122703.641-1-hechushiguitu666@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 1391ecf3a99a087e49a974717b4c589ce49f8872 Author: Alexei Starovoitov Date: Tue Mar 24 14:59:36 2026 -0700 bpf: Fix variable length stack write over spilled pointers [ Upstream commit 4639eb9e30ab10c7935c7c19e872facf9a94713f ] Scrub slots if variable-offset stack write goes over spilled pointers. Otherwise is_spilled_reg() may == true && spilled_ptr.type == NOT_INIT and valid program is rejected by check_stack_read_fixed_off() with obscure "invalid size of register fill" message. Fixes: 01f810ace9ed ("bpf: Allow variable-offset stack access") Acked-by: Eduard Zingerman Acked-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260324215938.81733-1-alexei.starovoitov@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit d4c4bd231ebad70e6f30db429e9640bf378b2f52 Author: David Carlier Date: Fri Mar 20 07:26:45 2026 +0000 bpf: Use RCU-safe iteration in dev_map_redirect_multi() SKB path [ Upstream commit 8ed82f807bb09d2c8455aaa665f2c6cb17bc6a19 ] The DEVMAP_HASH branch in dev_map_redirect_multi() uses hlist_for_each_entry_safe() to iterate hash buckets, but this function runs under RCU protection (called from xdp_do_generic_redirect_map() in softirq context). Concurrent writers (__dev_map_hash_update_elem, dev_map_hash_delete_elem) modify the list using RCU primitives (hlist_add_head_rcu, hlist_del_rcu). hlist_for_each_entry_safe() performs plain pointer dereferences without rcu_dereference(), missing the acquire barrier needed to pair with writers' rcu_assign_pointer(). On weakly-ordered architectures (ARM64, POWER), a reader can observe a partially-constructed node. It also defeats CONFIG_PROVE_RCU lockdep validation and KCSAN data-race detection. Replace with hlist_for_each_entry_rcu() using rcu_read_lock_bh_held() as the lockdep condition, consistent with the rcu_dereference_check() used in the DEVMAP (non-hash) branch of the same functions. Also fix the same incorrect lockdep_is_held(&dtab->index_lock) condition in dev_map_enqueue_multi(), where the lock is not held either. Fixes: e624d4ed4aa8 ("xdp: Extend xdp_redirect_map with broadcast support") Signed-off-by: David Carlier Signed-off-by: Martin KaFai Lau Link: https://patch.msgid.link/20260320072645.16731-1-devnexen@gmail.com Signed-off-by: Sasha Levin commit 0b69217310ee43ec44d7efb4a6e31ea0393fcb79 Author: Keisuke Nishimura Date: Fri Mar 20 14:02:20 2026 +0100 bpf: Fix refcount check in check_struct_ops_btf_id() [ Upstream commit 25e3e1f1096089a64901ae1faa7b7b13446653db ] The current implementation only checks whether the first argument is refcounted. Fix this by iterating over all arguments. Signed-off-by: Keisuke Nishimura Fixes: 38f1e66abd184 ("bpf: Do not allow tail call in strcut_ops program with __ref argument") Reviewed-by: Emil Tsalapatis Acked-by: Amery Hung Link: https://lore.kernel.org/r/20260320130219.63711-1-keisuke.nishimura@inria.fr Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit a1a8a8bdfa2171a7e2fe79ea8c481db1cd3fadf0 Author: Peter Chiu Date: Thu Mar 12 17:57:19 2026 +0800 wifi: mt76: mt7996: fix RRO EMU configuration [ Upstream commit 73b46379e5231138025b271ce8e158d2a8aa0768 ] Use the correct helper to update specific bitfields instead of overwriting the entire register. Fixes: eedb427eb260 ("wifi: mt76: mt7996: Enable HW RRO for MT7992 chipset") Signed-off-by: Peter Chiu Signed-off-by: Shayne Chen Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260312095724.2117448-1-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit dc34c01521bf025615a588fe296038d69a67e459 Author: Chad Monroe Date: Mon Mar 9 06:07:21 2026 +0000 wifi: mt76: support upgrading passive scans to active [ Upstream commit 360552c8592dab3c69e0bbff786b55137f1a81bb ] On channels with NO_IR or RADAR flags, wait for beacon before sending probe requests. Allows active scanning and WPS on restricted channels if another AP is already present. Fixes: c56d6edebc1f ("wifi: mt76: mt7996: use emulated hardware scan support") Tested-by: Piotr Kubik Signed-off-by: Chad Monroe Link: https://patch.msgid.link/20251118102723.47997-2-nbd@nbd.name Link: https://patch.msgid.link/20260309060730.87840-2-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit a2cde15af3782d407a69bdd43ba455fc1dc5bff3 Author: Chad Monroe Date: Mon Mar 9 06:07:20 2026 +0000 wifi: mt76: fix multi-radio on-channel scanning [ Upstream commit 0420180df092419a96351fb2afec1e2a74d385c3 ] avoid unnecessary channel switch when performing an on-channel scan using a multi-radio device. Fixes: c56d6edebc1f ("wifi: mt76: mt7996: use emulated hardware scan support") Signed-off-by: Chad Monroe Link: https://patch.msgid.link/20251118102723.47997-1-nbd@nbd.name Link: https://patch.msgid.link/20260309060730.87840-1-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 98e0118ab51c6b30f069f185c6651381a12c6eb6 Author: Lorenzo Bianconi Date: Sun Mar 8 14:25:20 2026 +0100 wifi: mt76: mt7996: Decrement sta counter removing the link in mt7996_mac_reset_sta_iter() [ Upstream commit e648051d52afbdb360bd586218961f5fffff63e8 ] Fixes tracking per-phy stations for offchannel switching. Fixes: ace5d3b6b49e8 ("wifi: mt76: mt7996: improve hardware restart reliability") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260308-mt7996_mac_reset_vif_iter-fix-v1-1-57f640aa2dcf@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit e54c6440114d9aa7b14ee140388560aa493c5ed2 Author: Lorenzo Bianconi Date: Fri Dec 5 11:24:38 2025 +0100 wifi: mt76: mt7996: Switch to the secondary link if the default one is removed [ Upstream commit 5ef44c200618430b004233cbfc1b0929a13d5ac8 ] Switch to the secondary link if available in mt7996_mac_sta_remove_links routine if the primary one is removed. Moreover reset secondary link index for single link scenario. Fixes: 85cd5534a3f2e ("wifi: mt76: mt7996: use correct link_id when filling TXD and TXP") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251205-mt76-txq-wicd-fix-v2-3-f19ba48af7c1@kernel.org Signed-off-by: Felix Fietkau Stable-dep-of: e648051d52af ("wifi: mt76: mt7996: Decrement sta counter removing the link in mt7996_mac_reset_sta_iter()") Signed-off-by: Sasha Levin commit d6f6b3a65660d183ef33f5a6582fd3b47174fe5a Author: Shayne Chen Date: Thu Nov 6 14:41:59 2025 +0800 wifi: mt76: mt7996: use correct link_id when filling TXD and TXP [ Upstream commit 85cd5534a3f2ec93e7d88713a77df5b4255520df ] Obtain the correct link ID and, if needed, switch to the corresponding wcid before populating the TX descriptor and TX payload. Rules for link id: - For QoS data of MLD peers (excluding EAPOL), select the primary or secondary wcid based on whether the TID is odd or even to meet FW/HW requirements - For other packets, use IEEE80211_TX_CTRL_MLO_LINK if specified (such as multicast and broadcast packets) Signed-off-by: Shayne Chen Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251106064203.1000505-8-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Stable-dep-of: e648051d52af ("wifi: mt76: mt7996: Decrement sta counter removing the link in mt7996_mac_reset_sta_iter()") Signed-off-by: Sasha Levin commit 5a3353b06387c3ccf398aefe9c19a4a0275bf8d1 Author: Lorenzo Bianconi Date: Fri Mar 6 11:27:52 2026 +0100 wifi: mt76: mt7996: Remove link pointer dependency in mt7996_mac_sta_remove_links() [ Upstream commit 569ce4340268915911fc356ec9ad27e92fb82289 ] Remove link pointer dependency in mt7996_mac_sta_remove_links routine to get the mt7996_phy pointer since the link can be already offchannel running mt7996_mac_sta_remove_links(). Rely on __mt7996_phy routine instead. Fixes: 344dd6a4c919 ("wifi: mt76: mt7996: Move num_sta accounting in mt7996_mac_sta_{add,remove}_links") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260306-mt7996-deflink-lookup-link-remove-v1-1-7162b332873c@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 7da35e2d2fb749fc06a6d11210ae3729a689834a Author: Lorenzo Bianconi Date: Sun Sep 28 18:27:01 2025 +0200 wifi: mt76: mt7996: Add missing CHANCTX_STA_CSA property [ Upstream commit c0a47ffc4caaf5161955add553322112c3a211b0 ] Enable missing CHANCTX_STA_CSA property required for MLO. Fixes: f5160304d57c ("wifi: mt76: mt7996: Enable MLO support for client interfaces") Signed-off-by: Lorenzo Bianconi Reviewed-by: AngeloGioacchino Del Regno Link: https://patch.msgid.link/20250928-mt7996_chanctx_sta_csa-v1-1-82e455185990@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 1e0f3e5e28356da28439561b8b6139f731328903 Author: Michael Lo Date: Wed Feb 11 17:50:25 2026 +0800 wifi: mt76: mt7921: fix 6GHz regulatory update on connection [ Upstream commit 3dc0c40d7806c72cfe88cf4e1e2650c1673f9db4 ] Call mt7921_regd_update() instead of mt7921_mcu_set_clc() when setting the 6GHz power type after connection, so that regulatory limits and SAR power are also applied. Fixes: 51ba0e3a15eb ("wifi: mt76: mt7921: add 6GHz power type support for clc") Signed-off-by: Michael Lo Link: https://patch.msgid.link/20260211095025.2415624-1-leon.yen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit aa4a31cd89f4fde5043ac613fe0e27014a60a60b Author: Duoming Zhou Date: Sat Jan 31 10:47:31 2026 +0800 wifi: mt76: mt7996: fix use-after-free bugs in mt7996_mac_dump_work() [ Upstream commit c8f62f73bbced3a79894655bdb0b625462d956fc ] When the mt7996 pci chip is detaching, the mt7996_crash_data is released in mt7996_coredump_unregister(). However, the work item dump_work may still be running or pending, leading to UAF bugs when the already freed crash_data is dereferenced again in mt7996_mac_dump_work(). The race condition can occur as follows: CPU 0 (removal path) | CPU 1 (workqueue) mt7996_pci_remove() | mt7996_sys_recovery_set() mt7996_unregister_device() | mt7996_reset() mt7996_coredump_unregister() | queue_work() vfree(dev->coredump.crash_data) | mt7996_mac_dump_work() | crash_data-> // UAF Fix this by ensuring dump_work is properly canceled before the crash_data is deallocated. Add cancel_work_sync() in mt7996_unregister_device() to synchronize with any pending or executing dump work. Fixes: 878161d5d4a4 ("wifi: mt76: mt7996: enable coredump support") Signed-off-by: Duoming Zhou Link: https://patch.msgid.link/20260131024731.18741-1-duoming@zju.edu.cn Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 6b7cbb13c838cf2a5f2e7be0e96fe15250087939 Author: Duoming Zhou Date: Fri Jan 30 22:57:59 2026 +0800 wifi: mt76: mt7915: fix use-after-free bugs in mt7915_mac_dump_work() [ Upstream commit 1146d0946b5358fad24812bd39d68f31cd40cc34 ] When the mt7915 pci chip is detaching, the mt7915_crash_data is released in mt7915_coredump_unregister(). However, the work item dump_work may still be running or pending, leading to UAF bugs when the already freed crash_data is dereferenced again in mt7915_mac_dump_work(). The race condition can occur as follows: CPU 0 (removal path) | CPU 1 (workqueue) mt7915_pci_remove() | mt7915_sys_recovery_set() mt7915_unregister_device() | mt7915_reset() mt7915_coredump_unregister() | queue_work() vfree(dev->coredump.crash_data) | mt7915_mac_dump_work() | crash_data-> // UAF Fix this by ensuring dump_work is properly canceled before the crash_data is deallocated. Add cancel_work_sync() in mt7915_unregister_device() to synchronize with any pending or executing dump work. Fixes: 4dbcb9125cc3 ("wifi: mt76: mt7915: enable coredump support") Signed-off-by: Duoming Zhou Link: https://patch.msgid.link/20260130145759.84272-1-duoming@zju.edu.cn Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 419babee9b5c87bc4bd351c7a2ff4062bd16f5fa Author: StanleyYP Wang Date: Tue Feb 3 23:55:30 2026 +0800 wifi: mt76: mt7996: fix struct mt7996_mcu_uni_event [ Upstream commit efbd5bf395f4e6b45a87f3835d4c2e28170c77c5 ] The cid field is defined as a two-byte value in the firmware. Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Signed-off-by: StanleyYP Wang Signed-off-by: Shayne Chen Link: https://patch.msgid.link/20260203155532.1098290-2-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit ae94ef093a15b1a36fff1e70d75fadeb08f5be23 Author: Shayne Chen Date: Tue Feb 3 23:55:29 2026 +0800 wifi: mt76: mt7996: fix wrong DMAD length when using MAC TXP [ Upstream commit 97b9f9831bf297f3ffa62018721601ed2736f2c3 ] The struct mt76_connac_fw_txp is used for HIF TXP. Change to use the struct mt76_connac_hw_txp to fix the wrong DMAD length for MAC TXP. Fixes: cb6ebbdffef2 ("wifi: mt76: mt7996: support writing MAC TXD for AddBA Request") Signed-off-by: Shayne Chen Link: https://patch.msgid.link/20260203155532.1098290-1-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 612bfcfdb993606e4d359277354c8868852841ff Author: James Clark Date: Thu Mar 5 16:28:18 2026 +0000 arm64: cpufeature: Make PMUVer and PerfMon unsigned [ Upstream commit d1dcc20bcc40efe1f1c71639376c91dafa489222 ] On the host, this change doesn't make a difference because the fields are defined as FTR_EXACT. However, KVM allows userspace to set these fields for a guest and overrides the type to be FTR_LOWER_SAFE. And while KVM used to do an unsigned comparison to validate that the new value is lower than what the hardware provides, since the linked commit it uses the generic sanitization framework which does a signed comparison. Fix it by defining these fields as unsigned. In theory, without this fix, userspace could set a higher PMU version than the hardware supports by providing any value with the top bit set. Fixes: c118cead07a7 ("KVM: arm64: Use generic sanitisation for ID_(AA64)DFR0_EL1") Signed-off-by: James Clark Reviewed-by: Marc Zyngier Reviewed-by: Colton Lewis Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 5fc8c5d45e44575dda9fcabdc2aac4ad97baf0cd Author: Chad Monroe Date: Mon Dec 8 14:31:32 2025 +0000 wifi: mt76: fix deadlock in remain-on-channel [ Upstream commit 6939b97ddad3cf3dfbb3b5a0a12ef79cb886747e ] mt76_remain_on_channel() and mt76_roc_complete() call mt76_set_channel() while already holding dev->mutex. Since mt76_set_channel() also acquires dev->mutex, this results in a deadlock. Use __mt76_set_channel() instead of mt76_set_channel(). Add cancel_delayed_work_sync() for mac_work before acquiring the mutex in mt76_remain_on_channel() to prevent a secondary deadlock with the mac_work workqueue. Fixes: a8f424c1287c ("wifi: mt76: add multi-radio remain_on_channel functions") Signed-off-by: Chad Monroe Link: https://patch.msgid.link/ace737e7b621af7c2adb33b0188011a5c1de2166.1765204256.git.chad@monroe.io Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 35180c772f5e11e2fa4d80d3dfd50906cb6d9646 Author: Sean Wang Date: Mon Jan 26 12:00:13 2026 -0600 wifi: mt76: mt7921: fix potential deadlock in mt7921_roc_abort_sync [ Upstream commit d5059e52fd8bc624ec4255c9fa01a266513d126b ] roc_abort_sync() can deadlock with roc_work(). roc_work() holds dev->mt76.mutex, while cancel_work_sync() waits for roc_work() to finish. If the caller already owns the same mutex, both sides block and no progress is possible. This deadlock can occur during station removal when mt76_sta_state() -> mt76_sta_remove() -> mt7921_mac_sta_remove() -> mt7921_roc_abort_sync() invokes cancel_work_sync() while roc_work() is still running and holding dev->mt76.mutex. This avoids the mutex deadlock and preserves exactly-once work ownership. Fixes: 352d966126e6 ("wifi: mt76: mt7921: fix a potential association failure upon resuming") Co-developed-by: Quan Zhou Signed-off-by: Quan Zhou Signed-off-by: Sean Wang Link: https://patch.msgid.link/20260126180013.8167-1-sean.wang@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 153bcba36c87a1ba555b57b6c49028d5812f895b Author: Sean Wang Date: Mon Dec 15 19:38:49 2025 -0600 wifi: mt76: mt7925: fix potential deadlock in mt7925_roc_abort_sync [ Upstream commit dd08ca3f092f4185ece69ce2a835c23198b1628a ] roc_abort_sync() can deadlock with roc_work(). roc_work() holds dev->mt76.mutex, while cancel_work_sync() waits for roc_work() to finish. If the caller already owns the same mutex, both sides block and no progress is possible. This deadlock can occur during station removal when mt76_sta_state() -> mt76_sta_remove() -> mt7925_mac_sta_remove_link() -> mt7925_mac_link_sta_remove() -> mt7925_roc_abort_sync() invokes cancel_work_sync() while roc_work() is still running and holding dev->mt76.mutex. This avoids the mutex deadlock and preserves exactly-once work ownership. Fixes: 45064d19fd3a ("wifi: mt76: mt7925: fix a potential association failure upon resuming") Co-developed-by: Quan Zhou Signed-off-by: Quan Zhou Signed-off-by: Sean Wang Link: https://patch.msgid.link/20251216013849.17976-1-sean.wang@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit e125def8b380e43952fee720920f5fcf9e6880b0 Author: Sean Wang Date: Mon Dec 15 20:20:17 2025 -0600 wifi: mt76: mt7925: drop puncturing handling from BSS change path [ Upstream commit 59a1864509d084a4b34117e693951c06b846b00a ] IEEE80211_CHANCTX_CHANGE_PUNCTURING is a channel context change flag and should not be checked in the BSS change handler, where the changed mask represents enum ieee80211_bss_change. Remove the puncturing handling from the BSS path and rely on mt7925_change_chanctx() to update puncturing configuration. Fixes: cadebdad959b ("wifi: mt76: mt7925: add EHT preamble puncturing") Signed-off-by: Sean Wang Link: https://patch.msgid.link/20251216022017.23870-1-sean.wang@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit a1a59bd3cd1e0a21ef3bea10742922066d3c7677 Author: Jack Kao Date: Wed Oct 1 09:25:06 2025 +0800 wifi: mt76: mt7925: cqm rssi low/high event notify [ Upstream commit 2a035ae2062f38dc5183002d1c5a64ca682170c1 ] The implementation amounts to setting the driver flag IEEE80211_VIF_SUPPORTS_CQM_RSSI, and then providing mechanisms for continuously updating enough information to be able to provide notifications to userspace when RSSI drops below a certain threshold Signed-off-by: Jack Kao Signed-off-by: Ming Yen Hsieh Link: https://patch.msgid.link/20251001012506.2168037-1-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau Stable-dep-of: 59a1864509d0 ("wifi: mt76: mt7925: drop puncturing handling from BSS change path") Signed-off-by: Sasha Levin commit dcbc13d19bef3326c72f324b10f5a3e5fc4d71de Author: Lorenzo Bianconi Date: Mon Dec 8 19:54:08 2025 +0100 wifi: mt76: Fix memory leak destroying device [ Upstream commit 6b470f36616e3448d44b0ef4b1de2a3e3a31b5be ] All MT76 rx queues have an associated page_pool even if the queue is not associated to a NAPI (e.g. WED RRO queues with WED enabled). Destroy the page_pool running mt76_dma_cleanup routine during module unload. Moreover returns pages to the page pool if WED is not enabled for WED RRO queues. Fixes: 950d0abb5cd94 ("wifi: mt76: mt7996: add wed rx support") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251208-mt76-fix-memory-leak-v1-1-cba813fc62b8@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 35835ff71e6e618155578b8e3905597edd5f601c Author: Rory Little Date: Wed Sep 3 17:07:11 2025 -0700 wifi: mt76: mt7921: Place upper limit on station AID [ Upstream commit 4d0bf21e3e20619d51d06c0c36207aabab8b712c ] Any station configured with an AID over 20 causes a firmware crash. This situation occurred in our testing using an AP interface on 7922 hardware, with a modified hostapd, sourced from Mediatek's OpenWRT feeds. In stock hostapd, station AIDs begin counting at 1, and this configuration is prevented with an upper limit on associated stations. However, the modified hostapd began allocation at 65, which caused the firmware to crash. This fix does not allow these AIDs to work, but will prevent the firmware crash. This crash was only seen on IFTYPE_AP interfaces, and the fix does not appear to have an effect on IFTYPE_STATION behavior. Fixes: 5c14a5f944b9 ("mt76: mt7921: introduce mt7921e support") Signed-off-by: Rory Little Link: https://patch.msgid.link/20250904000711.3033860-1-rory@candelatech.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit e00c27608536845d418de8f8991cefd578e35462 Author: Alok Tiwari Date: Mon Oct 13 02:08:24 2025 -0700 wifi: mt76: mt7996: fix FCS error flag check in RX descriptor [ Upstream commit d8db56142e531f060c938fa0b5175ed6c8cabb11 ] The mt7996 driver currently checks the MT_RXD3_NORMAL_FCS_ERR bit in rxd1 whereas other Connac3-based drivers(mt7925) correctly check this bit in rxd3. Since the MT_RXD3_NORMAL_FCS_ERR bit is defined in the fourth RX descriptor word (rxd3), update mt7996 to use the proper descriptor field. This change aligns mt7996 with mt7925 and the rest of the Connac3 family. Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Signed-off-by: Alok Tiwari Reviewed-by: AngeloGioacchino Del Regno Link: https://patch.msgid.link/20251013090826.753992-1-alok.a.tiwari@oracle.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 815db7fd57aa81c93fc8a66c2fac5f8bd0a8d153 Author: Ming Yen Hsieh Date: Thu Sep 4 11:06:47 2025 +0800 wifi: mt76: mt7925: prevent NULL vif dereference in mt7925_mac_write_txwi [ Upstream commit 962eb04e67552be406c906c83099c1d736aae3b6 ] Check for a NULL `vif` before accessing `ieee80211_vif_is_mld(vif)` to avoid a potential kernel panic in scenarios where `vif` might not be initialized. Fixes: ebb1406813c6 ("wifi: mt76: mt7925: add link handling to txwi") Signed-off-by: Ming Yen Hsieh Link: https://patch.msgid.link/20250904030649.655436-3-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 93d0694fb56de4628a921244d7f100c28acd2def Author: Ming Yen Hsieh Date: Thu Sep 4 11:06:48 2025 +0800 wifi: mt76: mt7925: prevent NULL pointer dereference in mt7925_tx_check_aggr() [ Upstream commit 83ae3a18ba957257b4c406273d2da2caeea2b439 ] Move the NULL check for 'sta' before dereferencing it to prevent a possible crash. Fixes: 44eb173bdd4f ("wifi: mt76: mt7925: add link handling in mt7925_txwi_free") Signed-off-by: Ming Yen Hsieh Link: https://patch.msgid.link/20250904030649.655436-4-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit b81a93dc0aedbaf63aacde8cfeb4a8967c6ad99c Author: Ryder Lee Date: Wed Jan 21 09:41:57 2026 -0800 wifi: mt76: mt7915: fix use_cts_prot support [ Upstream commit 8b2c26562b95c6397e132d21f2bd3d73aaee0c0a ] With this fix, when driver needs to adjust its behavior for compatibility, especially concerning older 11g/n devices, by enabling or disabling CTS protection frames, often for hidden SSIDs or to manage legacy clients. Fixes: 150b91419d3d ("wifi: mt76: mt7915: enable use_cts_prot support") Signed-off-by: Ryder Lee Link: https://patch.msgid.link/eb8db4d0bf1c89b7486e89facb788ae3e510dd8b.1768879119.git.ryder.lee@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 729b4adad19187c7699622217ebaa174ab7278fa Author: Ryder Lee Date: Wed Jan 21 09:41:56 2026 -0800 wifi: mt76: mt7615: fix use_cts_prot support [ Upstream commit 1974a67d9b65c29a0a9426e32e8cd8c056de48b7 ] Driver should not directly write WTBL to prevent overwritten issues. With this fix, when driver needs to adjust its behavior for compatibility, especially concerning older 11g/n devices, by enabling or disabling CTS protection frames, often for hidden SSIDs or to manage legacy clients. Fixes: e34235ccc5e3 ("wifi: mt76: mt7615: enable use_cts_prot support") Signed-off-by: Ryder Lee Link: https://patch.msgid.link/edb87088b0111b32fafc6c4179f54a5286dd37d8.1768879119.git.ryder.lee@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 9aa3b49e1c5bf2d7aad941a931afe0b26f9a5e6a Author: Leon Yen Date: Thu Dec 11 20:38:36 2025 +0800 wifi: mt76: mt7925: Fix incorrect MLO mode in firmware control [ Upstream commit 1695f662329faa07c860c73453c097823852df28 ] The selection of MLO mode should depend on the capabilities of the STA rather than those of the peer AP to avoid compatibility issues with certain APs, such as Xiaomi BE5000 WiFi7 router. Fixes: 69acd6d910b0c ("wifi: mt76: mt7925: add mt7925_change_vif_links") Signed-off-by: Leon Yen Link: https://patch.msgid.link/20251211123836.4169436-1-leon.yen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 3880639cec09a8a59b4c19d47670b07c29069930 Author: Sean Wang Date: Mon Dec 15 18:59:30 2025 -0600 wifi: mt76: mt7921: Reset ampdu_state state in case of failure in mt76_connac2_tx_check_aggr() [ Upstream commit 53ffffeb9624ffab6d9a3b1da8635a23f1172b5e ] Reset ampdu_state if ieee80211_start_tx_ba_session() fails in mt76_connac2_tx_check_aggr(), otherwise the driver may incorrectly assume aggregation is active and skip future BA setup attempts. Fixes: 163f4d22c118 ("mt76: mt7921: add MAC support") Signed-off-by: Sean Wang Link: https://patch.msgid.link/20251216005930.9412-1-sean.wang@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 1e16b0a9b988b7961669f00c1e5254710aae67a2 Author: Lorenzo Bianconi Date: Sun Dec 14 10:55:30 2025 +0100 wifi: mt76: mt7996: Reset ampdu_state state in case of failure in mt7996_tx_check_aggr() [ Upstream commit c0747db7c10c2dfbdcff0e8e97021e3df1f1e362 ] Reset the ampdu_state configured state if ieee80211_start_tx_ba_session routine fails in mt7996_tx_check_aggr() Fixes: 98686cd21624c ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251214-mt7996-aggr-check-fix-v1-1-33a8b62ec0fc@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 455a48685feebf2d9c1656caad77f9ba1da7b06e Author: Lorenzo Bianconi Date: Fri Dec 5 11:24:39 2025 +0100 wifi: mt76: mt7996: Clear wcid pointer in mt7996_mac_sta_deinit_link() [ Upstream commit 88973240dc7c976dd320b36a9e6d925c9be083ae ] Clear WCID pointer removing the sta link in mt7996_mac_sta_deinit_link routine. Fixes: dd82a9e02c054 ("wifi: mt76: mt7996: Rely on mt7996_sta_link in sta_add/sta_remove callbacks") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251205-mt76-txq-wicd-fix-v2-4-f19ba48af7c1@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 6d7f231d5fffcea326d74a7471709c95f9d21061 Author: Lorenzo Bianconi Date: Fri Dec 5 11:24:37 2025 +0100 wifi: mt76: mt7996: Reset mtxq->idx if primary link is removed in mt7996_vif_link_remove() [ Upstream commit 751a2679b15e3a0fa8fc9175862f0ec40643db68 ] Reset WCID index in mt76_txq struct if primary link is removed in mt7996_vif_link_remove routine. Fixes: a3316d2fc669f ("wifi: mt76: mt7996: set vif default link_id adding/removing vif links") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251205-mt76-txq-wicd-fix-v2-2-f19ba48af7c1@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 15205c72f1eceee1f31af3f1c7edda8151f097a0 Author: Lorenzo Bianconi Date: Fri Dec 5 11:24:36 2025 +0100 wifi: mt76: mt7996: Set mtxq->wcid just for primary link [ Upstream commit 654abcbe4528f74428b69292fad5c4224414fa1b ] Set WCID index in mt76_txq struct just for the primary link in mt7996_vif_link_add routine. Fixes: 69d54ce7491d0 ("wifi: mt76: mt7996: switch to single multi-radio wiphy") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251205-mt76-txq-wicd-fix-v2-1-f19ba48af7c1@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 900579479395f9e8da4bf3fd569e4b259f045214 Author: Shayne Chen Date: Mon Dec 15 14:37:28 2025 +0800 wifi: mt76: mt7996: fix iface combination for different chipsets [ Upstream commit 5ef0e8e2653b1ba325eb883ffb94073f19cb669a ] MT7992 and MT7990 support up to 19 interfaces per band and 32 in total. Fixes: 8df63a4bbe3d ("wifi: mt76: mt7996: adjust interface num and wtbl size for mt7992") Signed-off-by: Shayne Chen Link: https://patch.msgid.link/20251215063728.3013365-7-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 096b74331df26c603ef1dbb60880e392b0bad796 Author: StanleyYP Wang Date: Mon Dec 15 14:37:23 2025 +0800 wifi: mt76: mt7996: fix the behavior of radar detection [ Upstream commit 45a09251d610f3b8a1fb02039146e42f1f4efe90 ] RDD_DET_MODE is a firmware command intended for testing and does not pause TX after radar detection, so remove it from the normal flow; instead, use the MAC_ENABLE_CTRL firmware command to resume TX after the radar-triggered channel switch completes. Fixes: 1529e335f93d ("wifi: mt76: mt7996: rework radar HWRDD idx") Co-developed-by: Shayne Chen Signed-off-by: Shayne Chen Signed-off-by: StanleyYP Wang Link: https://patch.msgid.link/20251215063728.3013365-2-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit d902905cb7080d39a5f922df7c2daa3a877b3aa9 Author: David Laight Date: Mon Mar 2 10:17:54 2026 +0000 tools/nolibc/printf: Move snprintf length check to callback [ Upstream commit 4045e7b19bbf7338452cda11e64cfe7ae3361964 ] Move output truncation to the snprintf() callback. This simplifies the main code and fixes truncation of padded fields. Add a zero length callback to 'finalise' the buffer rather than doing it in snprintf() itself. Fixes: e90ce42e81381 ("tools/nolibc: implement width padding in printf()") Signed-off-by: David Laight Acked-by: Willy Tarreau Link: https://patch.msgid.link/20260302101815.3043-3-david.laight.linux@gmail.com [Thomas: clean up Fixes trailer] Signed-off-by: Thomas Weißschuh Signed-off-by: Sasha Levin commit ea23d00b98f572a76b2f8243c6d4696d25cbd8ad Author: David Laight Date: Mon Feb 23 10:17:24 2026 +0000 tools/nolibc/printf: Change variables 'c' to 'ch' and 'tmpbuf[]' to 'outbuf[]' [ Upstream commit f675ae28fcdf7db93a8c1a6964f062725b1e06a0 ] Changing 'c' makes the code slightly easier to read because the variable stands out from the single character literals (especially 'c'). Change tmpbuf[] to outbuf[] because 'out' points into it. The following patches pretty much rewrite the function so the churn is limited. Signed-off-by: David Laight Acked-by: Willy Tarreau Link: https://patch.msgid.link/20260223101735.2922-7-david.laight.linux@gmail.com Signed-off-by: Thomas Weißschuh Stable-dep-of: 4045e7b19bbf ("tools/nolibc/printf: Move snprintf length check to callback") Signed-off-by: Sasha Levin commit ca5b2452d6f10b92f5e4ac2c222c77a503c44c11 Author: Benjamin Berg Date: Wed Sep 24 16:20:52 2025 +0200 tools/nolibc: implement %m if errno is not defined [ Upstream commit fbd1b7f6b322a63b21ebbf00c732a17bb8bdb5d4 ] For improved compatibility, print %m as "unknown error" when nolibc is compiled using NOLIBC_IGNORE_ERRNO. Signed-off-by: Benjamin Berg Signed-off-by: Thomas Weißschuh Stable-dep-of: 4045e7b19bbf ("tools/nolibc/printf: Move snprintf length check to callback") Signed-off-by: Sasha Levin commit 00c0317cebf44151df18fb647781f315268cdd98 Author: Heitor Alves de Siqueira Date: Fri Mar 13 18:27:58 2026 -0300 wifi: libertas: don't kill URBs in interrupt context [ Upstream commit 7c5c2b661bdb78c1472b8833265c9ed1ee880039 ] Serialization for the TX path was enforced by calling usb_kill_urb()/usb_kill_anchored_urbs(), to prevent transmission before a previous URB was completed. usb_tx_block() can be called from interrupt context (e.g. in the HCD giveback path), so we can't always use it to kill in-flight URBs. Prevent sleeping during interrupt context by checking the tx_submitted anchor for existing URBs. We now return -EBUSY, to indicate there's a pending request. Reported-by: syzbot+74afbb6355826ffc2239@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=74afbb6355826ffc2239 Fixes: d66676e6ca96 ("wifi: libertas: fix WARNING in usb_tx_block") Signed-off-by: Heitor Alves de Siqueira Link: https://patch.msgid.link/20260313-libertas-usb-anchors-v1-2-915afbe988d7@igalia.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit a761a1539a55efe6519ce624e43d8c7779bfa811 Author: Heitor Alves de Siqueira Date: Fri Mar 13 18:27:57 2026 -0300 wifi: libertas: use USB anchors for tracking in-flight URBs [ Upstream commit a57f35fc19add4dfe33703af575a2c19c2cef9c7 ] The libertas driver currently handles URB lifecycles manually, which makes it non-trivial to check if specific URBs are pending or not. Add anchors for TX/RX URBs, and use those to track in-flight requests. Signed-off-by: Heitor Alves de Siqueira Link: https://patch.msgid.link/20260313-libertas-usb-anchors-v1-1-915afbe988d7@igalia.com Signed-off-by: Johannes Berg Stable-dep-of: 7c5c2b661bdb ("wifi: libertas: don't kill URBs in interrupt context") Signed-off-by: Sasha Levin commit d538795ea2ef593010b34ee12476a5ff71c02960 Author: Petr Pavlu Date: Fri Mar 13 14:48:02 2026 +0100 module: Fix freeing of charp module parameters when CONFIG_SYSFS=n [ Upstream commit deffe1edba626d474fef38007c03646ca5876a0e ] When setting a charp module parameter, the param_set_charp() function allocates memory to store a copy of the input value. Later, when the module is potentially unloaded, the destroy_params() function is called to free this allocated memory. However, destroy_params() is available only when CONFIG_SYSFS=y, otherwise only a dummy variant is present. In the unlikely case that the kernel is configured with CONFIG_MODULES=y and CONFIG_SYSFS=n, this results in a memory leak of charp values when a module is unloaded. Fix this issue by making destroy_params() always available when CONFIG_MODULES=y. Rename the function to module_destroy_params() to clarify that it is intended for use by the module loader. Fixes: e180a6b7759a ("param: fix charp parameters set via sysfs") Signed-off-by: Petr Pavlu Signed-off-by: Sami Tolvanen Signed-off-by: Sasha Levin commit 8f32c95a567871ba10ac5564bc737799edb900f3 Author: Petr Pavlu Date: Tue Aug 19 14:12:09 2025 +0200 params: Replace __modinit with __init_or_module [ Upstream commit 3cb0c3bdea5388519bc1bf575dca6421b133302b ] Remove the custom __modinit macro from kernel/params.c and instead use the common __init_or_module macro from include/linux/module.h. Both provide the same functionality. Signed-off-by: Petr Pavlu Reviewed-by: Aaron Tomlin Reviewed-by: Daniel Gomez Reviewed-by: Sami Tolvanen Signed-off-by: Sami Tolvanen Stable-dep-of: deffe1edba62 ("module: Fix freeing of charp module parameters when CONFIG_SYSFS=n") Signed-off-by: Sasha Levin commit c8b710655012a2993a9567873fb71a8a51f8459c Author: Ritesh Harjani (IBM) Date: Mon Mar 9 23:44:24 2026 +0530 powerpc/pgtable-frag: Fix bad page state in pte_frag_destroy [ Upstream commit fda4d71651f71c44b35829d13f3c8bf920032f77 ] powerpc uses pt_frag_refcount as a reference counter for tracking it's pte and pmd page table fragments. For PTE table, in case of Hash with 64K pagesize, we have 16 fragments of 4K size in one 64K page. Patch series [1] "mm: free retracted page table by RCU" added pte_free_defer() to defer the freeing of PTE tables when retract_page_tables() is called for madvise MADV_COLLAPSE on shmem range. [1]: https://lore.kernel.org/all/7cd843a9-aa80-14f-5eb2-33427363c20@google.com/ pte_free_defer() sets the active flag on the corresponding fragment's folio & calls pte_fragment_free(), which reduces the pt_frag_refcount. When pt_frag_refcount reaches 0 (no active fragment using the folio), it checks if the folio active flag is set, if set, it calls call_rcu to free the folio, it the active flag is unset then it calls pte_free_now(). Now, this can lead to following problem in a corner case... [ 265.351553][ T183] BUG: Bad page state in process a.out pfn:20d62 [ 265.353555][ T183] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x20d62 [ 265.355457][ T183] flags: 0x3ffff800000100(active|node=0|zone=0|lastcpupid=0x7ffff) [ 265.358719][ T183] raw: 003ffff800000100 0000000000000000 5deadbeef0000122 0000000000000000 [ 265.360177][ T183] raw: 0000000000000000 c0000000119caf58 00000000ffffffff 0000000000000000 [ 265.361438][ T183] page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set [ 265.362572][ T183] Modules linked in: [ 265.364622][ T183] CPU: 0 UID: 0 PID: 183 Comm: a.out Not tainted 6.18.0-rc3-00141-g1ddeaaace7ff-dirty #53 VOLUNTARY [ 265.364785][ T183] Hardware name: IBM pSeries (emulated by qemu) POWER10 (architected) 0x801200 0xf000006 of:SLOF,git-ee03ae pSeries [ 265.364908][ T183] Call Trace: [ 265.364955][ T183] [c000000011e6f7c0] [c000000001cfaa18] dump_stack_lvl+0x130/0x148 (unreliable) [ 265.365202][ T183] [c000000011e6f7f0] [c000000000794758] bad_page+0xb4/0x1c8 [ 265.365384][ T183] [c000000011e6f890] [c00000000079c020] __free_frozen_pages+0x838/0xd08 [ 265.365554][ T183] [c000000011e6f980] [c0000000000a70ac] pte_frag_destroy+0x298/0x310 [ 265.365729][ T183] [c000000011e6fa30] [c0000000000aa764] arch_exit_mmap+0x34/0x218 [ 265.365912][ T183] [c000000011e6fa80] [c000000000751698] exit_mmap+0xb8/0x820 [ 265.366080][ T183] [c000000011e6fc30] [c0000000001b1258] __mmput+0x98/0x300 [ 265.366244][ T183] [c000000011e6fc80] [c0000000001c81f8] do_exit+0x470/0x1508 [ 265.366421][ T183] [c000000011e6fd70] [c0000000001c95e4] do_group_exit+0x88/0x148 [ 265.366602][ T183] [c000000011e6fdc0] [c0000000001c96ec] pid_child_should_wake+0x0/0x178 [ 265.366780][ T183] [c000000011e6fdf0] [c00000000003a270] system_call_exception+0x1b0/0x4e0 [ 265.366958][ T183] [c000000011e6fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec The bad page state error occurs when such a folio gets freed (with active flag set), from do_exit() path in parallel. ... this can happen when the pte fragment was allocated from this folio, but when all the fragments get freed, the pte_frag_refcount still had some unused fragments. Now, if this process exits, with such folio as it's cached pte_frag in mm->context, then during pte_frag_destroy(), we simply call pagetable_dtor() and pagetable_free(), meaning it doesn't clear the active flag. This, can lead to the above bug. Since we are anyway in do_exit() path, then if the refcount is 0, then I guess it should be ok to simply clear the folio active flag before calling pagetable_dtor() & pagetable_free(). Fixes: 32cc0b7c9d50 ("powerpc: add pte_free_defer() for pgtables sharing page") Reviewed-by: Christophe Leroy (CS GROUP) Signed-off-by: Ritesh Harjani (IBM) Tested-by: Venkat Rao Bagalkote Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/ee13e7f99b8f258019da2b37655b998e73e5ef8b.1773078178.git.ritesh.list@gmail.com Signed-off-by: Sasha Levin commit 366b0e05ee24f5ba62bdc7ec1346038258b9a797 Author: Ilya Leoshkevich Date: Fri Mar 13 18:46:25 2026 +0100 s390/bpf: Zero-extend bpf prog return values and kfunc arguments [ Upstream commit 202e42e4aa890172366354b233c42c73107a3f59 ] s390x ABI requires callers to zero-extend unsigned arguments and sign-extend signed arguments, and callees to zero-extend unsigned return values and sign-extend signed return values. s390 BPF JIT currently implements only sign extension. Fix this omission and implement zero extension too. Fixes: 528eb2cb87bc ("s390/bpf: Implement arch_prepare_bpf_trampoline()") Reported-by: Hari Bathini Closes: https://lore.kernel.org/bpf/20260312080113.843408-1-hbathini@linux.ibm.com/ Signed-off-by: Ilya Leoshkevich Tested-by: Ihor Solodrai Link: https://lore.kernel.org/r/20260313174807.581826-1-iii@linux.ibm.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 3849f0ee39ea96f0ae07e354aa8b70cd00bf359e Author: Cai Xinchen Date: Thu Mar 12 06:59:07 2026 +0000 dpaa2: compile dpaa2 even CONFIG_FSL_DPAA2_ETH=n [ Upstream commit 97daf00745f7f9f261b0e91418de6e79d7826c36 ] CONFIG_FSL_DPAA2_ETH and CONFIG_FSL_DPAA2_SWITCH are not associated, but the compilation of FSL_DPAA2_SWITCH depends on the compilation of the dpaa2 folder. The files controlled by CONFIG_FSL_DPAA2_SWITCH in the dpaa2 folder are not controlled by CONFIG_FSL_DPAA2_ETH, except for the files controlled by CONFIG_FSL_DPAA2_SWITCH. Therefore, removing the restriction will not affect the compilation of the files in the directory. Fixes: f48298d3fbfaa ("staging: dpaa2-switch: move the driver out of staging") Suggested-by: Ioana Ciornei Signed-off-by: Cai Xinchen Link: https://patch.msgid.link/20260312065907.476663-3-caixinchen1@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit eebe930e785d5655dec24327778f744758100003 Author: Cai Xinchen Date: Thu Mar 12 06:59:06 2026 +0000 dpaa2: add independent dependencies for FSL_DPAA2_SWITCH [ Upstream commit 12589892f41c4c645c80ef9f036f7451a6045624 ] Since the commit 84cba72956fd ("dpaa2-switch: integrate the MAC endpoint support") included dpaa2-mac.o in the driver, but it didn't select PCS_LYNX, PHYLINK and FSL_XGMAC_MDIO. it will lead to link error, such as undefined reference to `phylink_ethtool_ksettings_set' undefined reference to `lynx_pcs_create_fwnode' And the same reason as the commit d2624e70a2f53 ("dpaa2-eth: select XGMAC_MDIO for MDIO bus support"), enable the FSL_XGMAC_MDIO Kconfig option in order to have MDIO access to internal and external PHYs. Because dpaa2-switch uses fsl_mc_driver APIs, add depends on FSL_MC_BUS && FSL_MC_DPIO as FSL_DPAA2_SWITCH do. FSL_XGMAC_MDIO and FSL_MC_BUS depend on OF, thus the dependence of FSL_MC_BUS can satisfy FSL_XGMAC_MDIO's OF requirement. Fixes: 84cba72956fd ("dpaa2-switch: integrate the MAC endpoint support") Suggested-by: Ioana Ciornei Signed-off-by: Cai Xinchen Link: https://patch.msgid.link/20260312065907.476663-2-caixinchen1@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0ee803fc4787a71c64aad0e1b4bc11d5b2acf963 Author: Shayne Chen Date: Fri Mar 13 14:21:49 2026 +0800 wifi: ieee80211: fix definition of EHT-MCS 15 in MRU [ Upstream commit cb0caadb64ca0894c4a24e1a34841f260d462f90 ] According to the definition in IEEE Std 802.11be-2024, Table 9-417r, each bit indicates support for the transmission and reception of EHT-MCS 15 in: - B0: 52+26-tone and 106+26-tone MRUs. - B1: a 484+242-tone MRU if 80 MHz is supported. - B2: a 996+484-tone MRU and a 996+484+242-tone MRU if 160 MHz is supported. - B3: a 3×996-tone MRU if 320 MHz is supported. Fixes: 6239da18d2f9 ("wifi: mac80211: adjust EHT capa when lowering bandwidth") Signed-off-by: Shayne Chen Link: https://patch.msgid.link/20260313062150.3165433-1-shayne.chen@mediatek.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit dd827cff429d5d20cf6a6310b6438d0d13d33028 Author: Johannes Berg Date: Wed Nov 5 15:36:53 2025 +0100 wifi: ieee80211: split EHT definitions out [ Upstream commit 86bc0c662322b4749cd666678d2fdce7015bcae3 ] The ieee80211.h file has gotten very long, continue splitting it by putting EHT definitions into a separate file. Link: https://patch.msgid.link/20251105153843.bf77fe169140.I691267e0edd914c604a5bfd447d33be00044c9b4@changeid Signed-off-by: Johannes Berg Stable-dep-of: cb0caadb64ca ("wifi: ieee80211: fix definition of EHT-MCS 15 in MRU") Signed-off-by: Sasha Levin commit df5720d35848be92944767a6d5ae20ec9ed347ce Author: Johannes Berg Date: Wed Nov 5 15:36:52 2025 +0100 wifi: ieee80211: split HE definitions out [ Upstream commit 02a2cf302557eb59794bba0b05d6755f44928d78 ] The ieee80211.h file has gotten very long, continue splitting it by putting HE definitions into a separate file. Link: https://patch.msgid.link/20251105153843.6998c0802104.I3dd7cfea6abbd118b999ecdedd48437d39cb0533@changeid Signed-off-by: Johannes Berg Stable-dep-of: cb0caadb64ca ("wifi: ieee80211: fix definition of EHT-MCS 15 in MRU") Signed-off-by: Sasha Levin commit f8d1e8038bc76ad5ff6f30aed55da0d8120444f9 Author: Johannes Berg Date: Wed Nov 5 15:36:51 2025 +0100 wifi: ieee80211: split VHT definitions out [ Upstream commit 7cb14da1d7bbfa4a6417ed7f1bc07dd77bcd9c83 ] The ieee80211.h file has gotten very long, continue splitting it by putting VHT definitions into a separate file. Link: https://patch.msgid.link/20251105153843.c31cb771a250.I787a13064db7d80440101de3445be17881daf1b6@changeid Signed-off-by: Johannes Berg Stable-dep-of: cb0caadb64ca ("wifi: ieee80211: fix definition of EHT-MCS 15 in MRU") Signed-off-by: Sasha Levin commit 4d5caab09dabaf293b2fd8f9202ff4a2f3111b65 Author: Johannes Berg Date: Wed Nov 5 15:36:50 2025 +0100 wifi: ieee80211: split HT definitions out [ Upstream commit fdc1c141f3ef4dc94e3880e973061681843f62c0 ] The ieee80211.h file has gotten very long, continue splitting it by putting HT definitions into a separate file. Link: https://patch.msgid.link/20251105153843.7532471178d0.Id956a5433ad8658e4e5c0272dbcbb59587206142@changeid Signed-off-by: Johannes Berg Stable-dep-of: cb0caadb64ca ("wifi: ieee80211: fix definition of EHT-MCS 15 in MRU") Signed-off-by: Sasha Levin commit 3f459076b2d823cd8e52b701f7259236bde4d4bc Author: Johannes Berg Date: Wed Nov 5 15:36:49 2025 +0100 wifi: ieee80211: split mesh definitions out [ Upstream commit 69674282fc97fffd98a85ab5b4837edbc5898145 ] The ieee80211.h file has gotten very long, start splitting it by putting mesh definitions into a separate file. Link: https://patch.msgid.link/20251105153843.489713ca8b34.I3befb4bf6ace0315758a1794224ddd18c4652e32@changeid Signed-off-by: Johannes Berg Stable-dep-of: cb0caadb64ca ("wifi: ieee80211: fix definition of EHT-MCS 15 in MRU") Signed-off-by: Sasha Levin commit 5500913516e071dbe23e5a404c861dd2d82c9589 Author: Feng Yang Date: Wed Mar 4 17:44:28 2026 +0800 bpf: test_run: Fix the null pointer dereference issue in bpf_lwt_xmit_push_encap [ Upstream commit 972787479ee73006fddb5e59ab5c8e733810ff42 ] The bpf_lwt_xmit_push_encap helper needs to access skb_dst(skb)->dev to calculate the needed headroom: err = skb_cow_head(skb, len + LL_RESERVED_SPACE(skb_dst(skb)->dev)); But skb->_skb_refdst may not be initialized when the skb is set up by bpf_prog_test_run_skb function. Executing bpf_lwt_push_ip_encap function in this scenario will trigger null pointer dereference, causing a kernel crash as Yinhao reported: [ 105.186365] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 105.186382] #PF: supervisor read access in kernel mode [ 105.186388] #PF: error_code(0x0000) - not-present page [ 105.186393] PGD 121d3d067 P4D 121d3d067 PUD 106c83067 PMD 0 [ 105.186404] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 105.186412] CPU: 3 PID: 3250 Comm: poc Kdump: loaded Not tainted 6.19.0-rc5 #1 [ 105.186423] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 105.186427] RIP: 0010:bpf_lwt_push_ip_encap+0x1eb/0x520 [ 105.186443] Code: 0f 84 de 01 00 00 0f b7 4a 04 66 85 c9 0f 85 47 01 00 00 31 c0 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8b 73 58 48 83 e6 fe <48> 8b 36 0f b7 be ec 00 00 00 0f b7 b6 e6 00 00 00 01 fe 83 e6 f0 [ 105.186449] RSP: 0018:ffffbb0e0387bc50 EFLAGS: 00010246 [ 105.186455] RAX: 000000000000004e RBX: ffff94c74e036500 RCX: ffff94c74874da00 [ 105.186460] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff94c74e036500 [ 105.186463] RBP: 0000000000000001 R08: 0000000000000002 R09: 0000000000000000 [ 105.186467] R10: ffffbb0e0387bd50 R11: 0000000000000000 R12: ffffbb0e0387bc98 [ 105.186471] R13: 0000000000000014 R14: 0000000000000000 R15: 0000000000000002 [ 105.186484] FS: 00007f166aa4d680(0000) GS:ffff94c8b7780000(0000) knlGS:0000000000000000 [ 105.186490] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 105.186494] CR2: 0000000000000000 CR3: 000000015eade001 CR4: 0000000000770ee0 [ 105.186499] PKRU: 55555554 [ 105.186502] Call Trace: [ 105.186507] [ 105.186513] bpf_lwt_xmit_push_encap+0x2b/0x40 [ 105.186522] bpf_prog_a75eaad51e517912+0x41/0x49 [ 105.186536] ? kvm_clock_get_cycles+0x18/0x30 [ 105.186547] ? ktime_get+0x3c/0xa0 [ 105.186554] bpf_test_run+0x195/0x320 [ 105.186563] ? bpf_test_run+0x10f/0x320 [ 105.186579] bpf_prog_test_run_skb+0x2f5/0x4f0 [ 105.186590] __sys_bpf+0x69c/0xa40 [ 105.186603] __x64_sys_bpf+0x1e/0x30 [ 105.186611] do_syscall_64+0x59/0x110 [ 105.186620] entry_SYSCALL_64_after_hwframe+0x76/0xe0 [ 105.186649] RIP: 0033:0x7f166a97455d Temporarily add the setting of skb->_skb_refdst before bpf_test_run to resolve the issue. Fixes: 52f278774e79 ("bpf: implement BPF_LWT_ENCAP_IP mode in bpf_lwt_push_encap") Reported-by: Yinhao Hu Reported-by: Kaiyan Mei Closes: https://groups.google.com/g/hust-os-kernel-patches/c/8-a0kPpBW2s Signed-off-by: Yun Lu Signed-off-by: Feng Yang Signed-off-by: Martin KaFai Lau Tested-by: syzbot@syzkaller.appspotmail.com Link: https://patch.msgid.link/20260304094429.168521-2-yangfeng59949@163.com Signed-off-by: Sasha Levin commit aa10a452e34810987fb9f4a047995b30003fb53f Author: Duoming Zhou Date: Mon Feb 23 12:55:22 2026 +0800 wifi: rtlwifi: pci: fix possible use-after-free caused by unfinished irq_prepare_bcn_tasklet [ Upstream commit 039cd522dc70151da13329a5e3ae19b1736f468a ] The irq_prepare_bcn_tasklet is initialized in rtl_pci_init() and scheduled when RTL_IMR_BCNINT interrupt is triggered by hardware. But it is never killed in rtl_pci_deinit(). When the rtlwifi card probe fails or is being detached, the ieee80211_hw is deallocated. However, irq_prepare_bcn_tasklet may still be running or pending, leading to use-after-free when the freed ieee80211_hw is accessed in _rtl_pci_prepare_bcn_tasklet(). Similar to irq_tasklet, add tasklet_kill() in rtl_pci_deinit() to ensure that irq_prepare_bcn_tasklet is properly terminated before the ieee80211_hw is released. The issue was identified through static analysis. Fixes: 0c8173385e54 ("rtl8192ce: Add new driver") Signed-off-by: Duoming Zhou Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260223045522.48377-1-duoming@zju.edu.cn Signed-off-by: Sasha Levin commit 9fe48cacab63aa1b2e81b133aab048912c09f29e Author: Zilin Guan Date: Mon Jan 19 09:26:25 2026 +0000 wifi: mwifiex: Fix memory leak in mwifiex_11n_aggregate_pkt() [ Upstream commit 990a73dec3fdc145fef6c827c29205437d533ece ] In mwifiex_11n_aggregate_pkt(), skb_aggr is allocated via mwifiex_alloc_dma_align_buf(). If mwifiex_is_ralist_valid() returns false, the function currently returns -1 immediately without freeing the previously allocated skb_aggr, causing a memory leak. Since skb_aggr has not yet been queued via skb_queue_tail(), no other references to this memory exist. Therefore, it has to be freed locally before returning the error. Fix this by calling mwifiex_write_data_complete() to free skb_aggr before returning the error status. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Signed-off-by: Zilin Guan Reviewed-by: Jeff Chen Link: https://patch.msgid.link/20260119092625.1349934-1-zilin@seu.edu.cn Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit b4f0a37724de1d44be4737e6d8b570d382d17118 Author: Michal Koutný Date: Mon Mar 23 13:39:37 2026 +0100 sched/rt: Skip group schedulable check with rt_group_sched=0 [ Upstream commit 8b016dcec9365675be81d26be88f2c09cf983bd4 ] The warning from the commit 87f1fb77d87a6 ("sched: Add RT_GROUP WARN checks for non-root task_groups") is wrong -- it assumes that only task_groups with rt_rq are traversed, however, the schedulability check would iterate all task_groups even when rt_group_sched=0 is disabled at boot time but some non-root task_groups exist. The schedulability check is supposed to validate: a) that children don't overcommit its parent, b) no RT task group overcommits global RT limit. but with rt_group_sched=0 there is no (non-trivial) hierarchy of RT groups, therefore skip the validation altogether. Otherwise, writes to the global sched_rt_runtime_us knob will be rejected with incorrect validation error. This fix is immaterial with CONFIG_RT_GROUP_SCHED=n. Fixes: 87f1fb77d87a6 ("sched: Add RT_GROUP WARN checks for non-root task_groups") Signed-off-by: Michal Koutný Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260323-sched-rert_groups-v3-1-1e7d5ed6b249@suse.com Signed-off-by: Sasha Levin commit 4bd99f4f86b19f76c25008a57945ea086d6b581b Author: Mario Limonciello (AMD) Date: Sat Mar 7 08:10:20 2026 -0600 firmware: dmi: Correct an indexing error in dmi.h [ Upstream commit c064abc68e009d2cc18416e7132d9c25e03125b6 ] The entries later in enum dmi_entry_type don't match the SMBIOS specification¹. The entry for type 33: `64-Bit Memory Error Information` is not present and thus the index for all later entries is incorrect. Add it. Also, add missing entry types 43-46, while at it. ¹ Search for "System Management BIOS (SMBIOS) Reference Specification" [ bp: Drop the flaky SMBIOS spec URL. ] Fixes: 93c890dbe5287 ("firmware: Add DMI entry types to the headers") Signed-off-by: Mario Limonciello (AMD) Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Jean Delvare Reviewed-by: Yazen Ghannam Link: https://patch.msgid.link/20260307141024.819807-2-superm1@kernel.org Signed-off-by: Sasha Levin commit e5bdb8404df4a9dca83d4535496d4b1cb99fee6e Author: Thomas Weißschuh Date: Mon Mar 30 14:07:55 2026 +0200 x86/vdso: Clean up remnants of VDSO32_NOTE_MASK [ Upstream commit 6517f293b2c6774d21b6e7e26a55fae60c6ec4cf ] VDSO32_NOTE_MASK is not used or provided anymore, remove it. Fixes: a13f2ef168cb ("x86/xen: remove 32-bit Xen PV guest support") Signed-off-by: Thomas Weißschuh Signed-off-by: Ingo Molnar Cc: H. Peter Anvin Cc: Boris Ostrovsky Cc: Juergen Gross Link: https://patch.msgid.link/20260330-vdso-x86-vdso32_note_mask-v1-1-2f5c473327bf@linutronix.de Signed-off-by: Sasha Levin commit d739426c2fd10fee313b6cdae6748722bb873202 Author: Ahmed S. Darwish Date: Fri Mar 27 03:15:16 2026 +0100 ASoC: Intel: avs: Include CPUID header at file scope [ Upstream commit 7f78e0b46e9984e955cb73ffada8dace8b4dd059 ] Commit cbe37a4d2b3c ("ASoC: Intel: avs: Configure basefw on TGL-based platforms") includes the main CPUID header from within a C function. This works by luck and forbids valid refactoring inside that header. Include the CPUID header at file scope instead. Remove the COMPILE_TEST build flag so that the CONFIG_X86 conditionals can be removed. The driver gets enough compilation testing already on x86. For clarity, refactor the CPUID(0x15) code into its own function without changing any of the driver's logic. Fixes: cbe37a4d2b3c ("ASoC: Intel: avs: Configure basefw on TGL-based platforms") Suggested-by: Borislav Petkov # CONFIG_X86 removal Signed-off-by: Ahmed S. Darwish Signed-off-by: Borislav Petkov (AMD) Acked-by: Cezary Rojewski Link: https://lore.kernel.org/all/20250612234010.572636-3-darwi@linutronix.de Signed-off-by: Sasha Levin commit 7e16c122695c291826634ace50f8ff909edc9541 Author: Ahmed S. Darwish Date: Fri Mar 27 03:15:15 2026 +0100 ASoC: Intel: avs: Check maximum valid CPUID leaf [ Upstream commit 93a1f0e61329f538cfc7122d7fa0e7a1803e326d ] The Intel AVS driver queries CPUID(0x15) before checking if the CPUID leaf is available. Check the maximum-valid CPU standard leaf beforehand. Use the CPUID_LEAF_TSC macro instead of the custom local one for the CPUID(0x15) leaf number. Fixes: cbe37a4d2b3c ("ASoC: Intel: avs: Configure basefw on TGL-based platforms") Signed-off-by: Ahmed S. Darwish Signed-off-by: Borislav Petkov (AMD) Acked-by: Cezary Rojewski Link: https://patch.msgid.link/20260327021645.555257-2-darwi@linutronix.de Signed-off-by: Sasha Levin commit e2a2781d1ae6af658e5524f6b44e97edd3a4f392 Author: Biju Das Date: Wed Mar 25 19:24:18 2026 +0000 irqchip/renesas-rzg2l: Fix error path in rzg2l_irqc_common_probe() [ Upstream commit fb74e35f78105efd8635c89b39f4389f567edbdc ] Replace pm_runtime_put() with pm_runtime_put_sync() when irq_domain_create_hierarchy() fails to ensure the device suspends synchronously before devres cleanup disables runtime PM via pm_runtime_disable(). [ tglx: Fix up subject and change log to be precise ] Fixes: 7de11369ef30 ("irqchip/renesas-rzg2l: Use devm_pm_runtime_enable()") Signed-off-by: Biju Das Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260325192451.172562-4-biju.das.jz@bp.renesas.com Signed-off-by: Sasha Levin commit b5232c2f04e13c3cfcea63d250941de7553164de Author: Peter Zijlstra Date: Mon Mar 23 10:36:27 2026 +0100 sched/topology: Fix sched_domain_span() [ Upstream commit e379dce8af11d8d6040b4348316a499bfd174bfb ] Commit 8e8e23dea43e ("sched/topology: Compute sd_weight considering cpuset partitions") ends up relying on the fact that structure initialization should not touch the flexible array. However, the official GCC specification for "Arrays of Length Zero" [*] says: Although the size of a zero-length array is zero, an array member of this kind may increase the size of the enclosing type as a result of tail padding. Additionally, structure initialization will zero tail padding. With the end result that since offsetof(*type, member) < sizeof(*type), array initialization will clobber the flex array. Luckily, the way flexible array sizes are calculated is: sizeof(*type) + count * sizeof(*type->member) This means we have the complete size of the flex array *outside* of sizeof(*type), so use that instead of relying on the broken flex array definition. [*] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html Fixes: 8e8e23dea43e ("sched/topology: Compute sd_weight considering cpuset partitions") Reported-by: Nathan Chancellor Debugged-by: K Prateek Nayak Signed-off-by: Peter Zijlstra (Intel) Tested-by: Jon Hunter Tested-by: Chen Yu Tested-by: K Prateek Nayak Tested-by: Nathan Chancellor Link: https://patch.msgid.link/20260323093627.GY3738010@noisy.programming.kicks-ass.net Signed-off-by: Sasha Levin commit 87800a0bd2fec27605dc9b733b4f922120d45803 Author: K Prateek Nayak Date: Thu Mar 12 04:44:26 2026 +0000 sched/topology: Compute sd_weight considering cpuset partitions [ Upstream commit 8e8e23dea43e64ddafbd1246644c3219209be113 ] The "sd_weight" used for calculating the load balancing interval, and its limits, considers the span weight of the entire topology level without accounting for cpuset partitions. For example, consider a large system of 128CPUs divided into 8 * 16CPUs partition which is typical when deploying virtual machines: [ PKG Domain: 128CPUs ] [Partition0: 16CPUs][Partition1: 16CPUs] ... [Partition7: 16CPUs] Although each partition only contains 16CPUs, the load balancing interval is set to a minimum of 128 jiffies considering the span of the entire domain with 128CPUs which can lead to longer imbalances within the partition although balancing within is cheaper with 16CPUs. Compute the "sd_weight" after computing the "sd_span" considering the cpu_map covered by the partition, and set the load balancing interval, and its limits accordingly. For the above example, the balancing intervals for the partitions PKG domain changes as follows: before after balance_interval 128 16 min_interval 128 16 max_interval 256 32 Intervals are now proportional to the CPUs in the partitioned domain as was intended by the original formula. Fixes: cb83b629bae03 ("sched/numa: Rewrite the CONFIG_NUMA sched domain support") Signed-off-by: K Prateek Nayak Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Shrikanth Hegde Reviewed-by: Chen Yu Reviewed-by: Valentin Schneider Reviewed-by: Dietmar Eggemann Tested-by: Dietmar Eggemann Link: https://patch.msgid.link/20260312044434.1974-2-kprateek.nayak@amd.com Signed-off-by: Sasha Levin commit 5fbefcd7c38edd0c187f5f39ef5960964e8d47a8 Author: Bart Van Assche Date: Fri Mar 13 10:15:07 2026 -0700 locking: Fix rwlock support in [ Upstream commit 756a0e011cfca0b45a48464aa25b05d9a9c2fb0b ] Architecture support for rwlocks must be available whether or not CONFIG_DEBUG_SPINLOCK has been defined. Move the definitions of the arch_{read,write}_{lock,trylock,unlock}() macros such that these become visbile if CONFIG_DEBUG_SPINLOCK=n. This patch prepares for converting do_raw_{read,write}_trylock() into inline functions. Without this patch that conversion triggers a build failure for UP architectures, e.g. arm-ep93xx. I used the following kernel configuration to build the kernel for that architecture: CONFIG_ARCH_MULTIPLATFORM=y CONFIG_ARCH_MULTI_V7=n CONFIG_ATAGS=y CONFIG_MMU=y CONFIG_ARCH_MULTI_V4T=y CONFIG_CPU_LITTLE_ENDIAN=y CONFIG_ARCH_EP93XX=y Fixes: fb1c8f93d869 ("[PATCH] spinlock consolidation") Signed-off-by: Bart Van Assche Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260313171510.230998-2-bvanassche@acm.org Signed-off-by: Sasha Levin commit 8e1be8f79fcaed63f649a3c9f8cdfb51e2c5c565 Author: Thomas Weißschuh (Schneider Electric) Date: Wed Mar 11 11:15:10 2026 +0100 scripts/gdb: timerlist: Adapt to move of tk_core [ Upstream commit 5aa9383813aca45b914d4a7481ca417ef13114df ] tk_core is a macro today which cannot be resolved by gdb. Use the correct symbol expression to reference tk_core. Fixes: 22c62b9a84b8 ("timekeeping: Introduce auxiliary timekeepers") Signed-off-by: Thomas Weißschuh (Schneider Electric) Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260311-hrtimer-cleanups-v1-1-095357392669@linutronix.de Signed-off-by: Sasha Levin commit 6adc01405605e03d5ddaa219d59ad2c8ea088e22 Author: Thomas Weißschuh Date: Wed Mar 4 08:49:01 2026 +0100 sparc64: vdso: Link with -z noexecstack [ Upstream commit acc4f131d5d57c2aa89db914aeb6f7bb0ab4eb4a ] The vDSO stack does not need to be executable. Prevent the linker from creating executable. For more background see commit ffcf9c5700e4 ("x86: link vdso and boot with -z noexecstack --no-warn-rwx-segments"). Also prevent the following warning from the linker: sparc64-linux-ld: warning: arch/sparc/vdso/vdso-note.o: missing .note.GNU-stack section implies executable stack sparc64-linux-ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker Fixes: 9a08862a5d2e ("vDSO for sparc") Suggested-by: Arnd Bergmann Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Tested-by: Andreas Larsson Reviewed-by: Andreas Larsson Acked-by: Andreas Larsson Link: https://lore.kernel.org/lkml/20250707144726.4008707-1-arnd@kernel.org/ Link: https://patch.msgid.link/20260304-vdso-sparc64-generic-2-v6-4-d8eb3b0e1410@linutronix.de Signed-off-by: Sasha Levin commit bec2fa23eaf2a211ab1417afd7e4022fddc441ea Author: Boqun Feng Date: Tue Mar 3 12:16:49 2026 -0800 rust: sync: atomic: Remove bound `T: Sync` for `Atomic::from_ptr()` [ Upstream commit 4a5dc632e0b603ec1cbbf87b78de86b4b6359cff ] Originally, `Atomic::from_ptr()` requires `T` being a `Sync` because I thought having the ability to do `from_ptr()` meant multiplle `&Atomic`s shared by different threads, which was identical (or similar) to multiple `&T`s shared by different threads. Hence `T` was required to be `Sync`. However this is not true, since `&Atomic` is not the same at `&T`. Moreover, having this bound makes `Atomic::<*mut T>::from_ptr()` impossible, which is definitely not intended. Therefore remove the `T: Sync` bound. [boqun: Fix title typo spotted by Alice & Gary] Fixes: 29c32c405e53 ("rust: sync: atomic: Add generic atomics") Signed-off-by: Boqun Feng Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Alice Ryhl Reviewed-by: Gary Guo Link: https://patch.msgid.link/20260120115207.55318-2-boqun.feng@gmail.com Link: https://patch.msgid.link/20260303201701.12204-2-boqun@kernel.org Signed-off-by: Sasha Levin commit 90e8cfcd217cb07a5c22e681be8eaa87d7c8bd92 Author: Xiaoyao Li Date: Tue Mar 3 11:03:32 2026 +0800 x86/tdx: Fix the typo in TDX_ATTR_MIGRTABLE [ Upstream commit 3aecb2e7b948400354399b26f3f1653bd2c1bae0 ] The TD scoped TDCS attributes are defined by bit positions. In the guest side of the TDX code, the 'tdx_attributes' string array holds pretty print names for these attributes, which are generated via macros and defines. Today these pretty print names are only used to print the attribute names to dmesg. Unfortunately there is a typo in the define for the migratable bit. Change the defines TDX_ATTR_MIGRTABLE* to TDX_ATTR_MIGRATABLE*. Update the sole user, the tdx_attributes array, to use the fixed name. Since these defines control the string printed to dmesg, the change is user visible. But the risk of breakage is almost zero since it is not exposed in any interface expected to be consumed programmatically. Fixes: 564ea84c8c14 ("x86/tdx: Dump attributes and TD_CTLS on boot") Signed-off-by: Xiaoyao Li Signed-off-by: Dave Hansen Reviewed-by: Kirill A. Shutemov Reviewed-by: Kai Huang Acked-by: Sean Christopherson Link: https://patch.msgid.link/20260303030335.766779-2-xiaoyao.li@intel.com Signed-off-by: Sasha Levin commit 2783ed2442ce69ae240b787aee6dae801cef7aec Author: Ravi Bangoria Date: Mon Feb 16 04:22:15 2026 +0000 perf/amd/ibs: Avoid calling perf_allow_kernel() from the IBS NMI handler [ Upstream commit b0a09142622a994c4f4088c3f61db5da87cfc711 ] Calling perf_allow_kernel() from the NMI context is unsafe and could be fatal. Capture the permission at event-initialization time by storing it in event->hw.flags, and have the NMI handler rely on that cached flag instead of making the call directly. Fixes: 50a53b60e141d ("perf/amd/ibs: Prevent leaking sensitive data to userspace") Reported-by: Sadasivan Shaiju Signed-off-by: Ravi Bangoria Signed-off-by: Peter Zijlstra (Intel) Acked-by: Namhyung Kim Link: https://patch.msgid.link/20260216042216.1440-5-ravi.bangoria@amd.com Signed-off-by: Sasha Levin commit aaf2712f76747830043ef5dfd5ef2c46f01bd830 Author: Ravi Bangoria Date: Mon Feb 16 04:22:14 2026 +0000 perf/amd/ibs: Preserve PhyAddrVal bit when clearing PhyAddr MSR [ Upstream commit 723a290326e015b07931eabc603d3735999377be ] Commit 50a53b60e141 ("perf/amd/ibs: Prevent leaking sensitive data to userspace") zeroed the physical address and also cleared the PhyAddrVal flag before copying the value into a perf sample to avoid exposing physical addresses to unprivileged users. Clearing PhyAddrVal, however, has an unintended side-effect: several other IBS fields are considered valid only when this bit is set. As a result, those otherwise correct fields are discarded, reducing IBS functionality. Continue to zero the physical address, but keep the PhyAddrVal bit intact so the related fields remain usable while still preventing any address leak. Fixes: 50a53b60e141 ("perf/amd/ibs: Prevent leaking sensitive data to userspace") Signed-off-by: Ravi Bangoria Signed-off-by: Peter Zijlstra (Intel) Acked-by: Namhyung Kim Link: https://patch.msgid.link/20260216042216.1440-4-ravi.bangoria@amd.com Signed-off-by: Sasha Levin commit e017f5b69b7623b36b396f37ec2d13d378e33ed6 Author: Thomas Gleixner Date: Tue Feb 24 17:36:59 2026 +0100 hrtimer: Reduce trace noise in hrtimer_start() [ Upstream commit f2e388a019e4cf83a15883a3d1f1384298e9a6aa ] hrtimer_start() when invoked with an already armed timer traces like: -.. [032] d.h2. 5.002263: hrtimer_cancel: hrtimer= .... -.. [032] d.h1. 5.002263: hrtimer_start: hrtimer= .... Which is incorrect as the timer doesn't get canceled. Just the expiry time changes. The internal dequeue operation which is required for that is not really interesting for trace analysis. But it makes it tedious to keep real cancellations and the above case apart. Remove the cancel tracing in hrtimer_start() and add a 'was_armed' indicator to the hrtimer start tracepoint, which clearly indicates what the state of the hrtimer is when hrtimer_start() is invoked: -.. [032] d.h1. 6.200103: hrtimer_start: hrtimer= .... was_armed=0 -.. [032] d.h1. 6.200558: hrtimer_start: hrtimer= .... was_armed=1 Fixes: c6a2a1770245 ("hrtimer: Add tracepoint for hrtimers") Signed-off-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260224163430.208491877@kernel.org Signed-off-by: Sasha Levin commit a8759eef4951c023bbf95a31a3bd9dd40e83d772 Author: Peter Zijlstra Date: Tue Feb 24 17:35:37 2026 +0100 hrtimer: Avoid pointless reprogramming in __hrtimer_start_range_ns() [ Upstream commit d19ff16c11db38f3ee179d72751fb9b340174330 ] Much like hrtimer_reprogram(), skip programming if the cpu_base is running the hrtimer interrupt. Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Juri Lelli Reviewed-by: Thomas Gleixner Link: https://patch.msgid.link/20260224163429.069535561@kernel.org Stable-dep-of: f2e388a019e4 ("hrtimer: Reduce trace noise in hrtimer_start()") Signed-off-by: Sasha Levin commit 6b05c427a638288310c906faa8897db7340ef298 Author: Brian Masney Date: Sun Feb 22 18:43:44 2026 -0500 irqchip/irq-pic32-evic: Address warning related to wrong printf() formatter [ Upstream commit 86be659415b0ddefebc3120e309091aa215a9064 ] This driver is currently only build on 32 bit MIPS systems. When building it on x86_64, the following warning occurs: drivers/irqchip/irq-pic32-evic.c: In function ‘pic32_ext_irq_of_init’: ./include/linux/kern_levels.h:5:25: error: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Werror=format=] Update the printf() formatter in preparation for allowing this driver to be compiled on all architectures. Fixes: aaa8666ada780 ("IRQCHIP: irq-pic32-evic: Add support for PIC32 interrupt controller") Signed-off-by: Brian Masney Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260222-irqchip-pic32-v1-1-37f50d1f14af@redhat.com Signed-off-by: Sasha Levin commit 8139ce66b52a4a5638bfb445b037c07d4abeb08e Author: Danilo Krummrich Date: Tue Mar 24 01:59:06 2026 +0100 bus: fsl-mc: use generic driver_override infrastructure [ Upstream commit 6c8dfb0362732bf1e4829867a2a5239fedc592d0 ] 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: Ioana Ciornei Acked-by: Ioana Ciornei Acked-by: Christophe Leroy (CS GROUP) 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: 1f86a00c1159 ("bus/fsl-mc: add support for 'driver_override' in the mc-bus") Link: https://patch.msgid.link/20260324005919.2408620-3-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 2081957d8c323ffb58a10bc64837717ac5a042a1 Author: Danilo Krummrich Date: Tue Mar 24 01:59:13 2026 +0100 s390/cio: use generic driver_override infrastructure [ Upstream commit ac4d8bb6e2e13e8684a76ea48d13ebaaaf5c24c4 ] 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: ebc3d1791503 ("s390/cio: introduce driver_override on the css bus") Reviewed-by: Vineeth Vijayan Link: https://patch.msgid.link/20260324005919.2408620-10-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 654ef9c33e138ede6734ac286282df9faf83cd11 Author: Danilo Krummrich Date: Tue Mar 24 01:59:12 2026 +0100 vdpa: use generic driver_override infrastructure [ Upstream commit 85bb534ff12aab6916058897b39c748940a7a4c6 ] 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: 539fec78edb4 ("vdpa: add driver_override support") Acked-by: Eugenio Pérez Acked-by: Michael S. Tsirkin Link: https://patch.msgid.link/20260324005919.2408620-9-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 2c5507010fc3b8e2bd596c63c88f6ad39a69b1c4 Author: Danilo Krummrich Date: Tue Mar 24 01:59:10 2026 +0100 platform/wmi: use generic driver_override infrastructure [ Upstream commit 8a700b1fc94df4d847a04f14ebc7f8532592b367 ] 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: 12046f8c77e0 ("platform/x86: wmi: Add driver_override support") Reviewed-by: Armin Wolf Acked-by: Ilpo Järvinen Link: https://patch.msgid.link/20260324005919.2408620-7-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 58a42be0d70307d765594fc581f5f5e5ef059712 Author: Danilo Krummrich Date: Tue Mar 24 01:59:09 2026 +0100 PCI: use generic driver_override infrastructure [ Upstream commit 10a4206a24013be4d558d476010cbf2eb4c9fa64 ] 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: 782a985d7af2 ("PCI: Introduce new device binding path using pci_dev.driver_override") Acked-by: Bjorn Helgaas Acked-by: Alex Williamson Tested-by: Gui-Dong Han Reviewed-by: Gui-Dong Han Link: https://patch.msgid.link/20260324005919.2408620-6-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit e52830bf37a2f2d972f33ffd1feaa243e40956b8 Author: K Prateek Nayak Date: Mon Mar 16 08:18:49 2026 +0000 cpufreq: Pass the policy to cpufreq_driver->adjust_perf() [ Upstream commit c03791085adcd61fa9b766ab303c7d0941d7378d ] cpufreq_cpu_get() can sleep on PREEMPT_RT in presence of concurrent writer(s), however amd-pstate depends on fetching the cpudata via the policy's driver data which necessitates grabbing the reference. Since schedutil governor can call "cpufreq_driver->update_perf()" during sched_tick/enqueue/dequeue with rq_lock held and IRQs disabled, fetching the policy object using the cpufreq_cpu_get() helper in the scheduler fast-path leads to "BUG: scheduling while atomic" on PREEMPT_RT [1]. Pass the cached cpufreq policy object in sg_policy to the update_perf() instead of just the CPU. The CPU can be inferred using "policy->cpu". The lifetime of cpufreq_policy object outlasts that of the governor and the cpufreq driver (allocated when the CPU is onlined and only reclaimed when the CPU is offlined / the CPU device is removed) which makes it safe to be referenced throughout the governor's lifetime. Closes:https://lore.kernel.org/all/20250731092316.3191-1-spasswolf@web.de/ [1] Fixes: 1d215f0319c2 ("cpufreq: amd-pstate: Add fast switch function for AMD P-State") Reported-by: Bert Karwatzki Acked-by: Viresh Kumar Signed-off-by: K Prateek Nayak Acked-by: Gary Guo # Rust Reviewed-by: Gautham R. Shenoy Reviewed-by: Zhongqiu Han Link: https://lore.kernel.org/r/20260316081849.19368-3-kprateek.nayak@amd.com Signed-off-by: Mario Limonciello (AMD) Signed-off-by: Sasha Levin commit e6210630b24e1255de213333404d5cc1d87aaada Author: Gautham R. Shenoy Date: Thu Mar 26 17:17:46 2026 +0530 amd-pstate: Update cppc_req_cached in fast_switch case [ Upstream commit fcc25a291fbdca2c06c2c6602532050873f0c9de ] The function msr_update_perf() does not cache the new value that is written to MSR_AMD_CPPC_REQ into the variable cpudata->cppc_req_cached when the update is happening from the fast path. Fix that by caching the value everytime the MSR_AMD_CPPC_REQ gets updated. This issue was discovered by Claude Opus 4.6 with the aid of Chris Mason's AI review-prompts (https://github.com/masoncl/review-prompts/tree/main/kernel). Assisted-by: Claude:claude-opus-4.6 review-prompts/linux Reviewed-by: Mario Limonciello (AMD) Fixes: fff395796917 ("cpufreq/amd-pstate: Always write EPP value when updating perf") Signed-off-by: Gautham R. Shenoy Signed-off-by: Mario Limonciello (AMD) Signed-off-by: Sasha Levin commit 539aabbab190825c77eb455ec35652cb3720625f Author: Gautham R. Shenoy Date: Thu Mar 26 17:17:45 2026 +0530 amd-pstate: Fix memory leak in amd_pstate_epp_cpu_init() [ Upstream commit beda3b363546a423e4e29a7395e04c0ac4ff677e ] On failure to set the epp, the function amd_pstate_epp_cpu_init() returns with an error code without freeing the cpudata object that was allocated at the beginning of the function. Ensure that the cpudata object is freed before returning from the function. This memory leak was discovered by Claude Opus 4.6 with the aid of Chris Mason's AI review-prompts (https://github.com/masoncl/review-prompts/tree/main/kernel). Assisted-by: Claude:claude-opus-4.6 review-prompts/linux Fixes: f9a378ff6443 ("cpufreq/amd-pstate: Set different default EPP policy for Epyc and Ryzen") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Gautham R. Shenoy Signed-off-by: Mario Limonciello (AMD) Signed-off-by: Sasha Levin commit 187c8be0c48fb803ac1579d3b7962afc2e7e81f6 Author: Gui-Dong Han Date: Mon Mar 23 16:58:46 2026 +0800 soundwire: debugfs: initialize firmware_file to empty string [ Upstream commit 7215e4552f31e53595eae56a834f7e286beecccc ] Passing NULL to debugfs_create_str() causes a NULL pointer dereference, and creating debugfs nodes with NULL string pointers is no longer permitted. Additionally, firmware_file is a global pointer. Previously, adding every new slave blindly overwrote it with NULL. Fix these issues by initializing firmware_file to an allocated empty string once in the subsystem init path (sdw_debugfs_init), and freeing it in the exit path. Existing driver code handles empty strings correctly. Fixes: fe46d2a4301d ("soundwire: debugfs: add interface to read/write commands") Reported-by: yangshiguang Closes: https://lore.kernel.org/lkml/17647e4c.d461.19b46144a4e.Coremail.yangshiguang1011@163.com/ Signed-off-by: Gui-Dong Han Link: https://patch.msgid.link/20260323085930.88894-4-hanguidong02@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit bfe63c16fefb39bab8f67bfeecb14ceb75a8621a Author: Gui-Dong Han Date: Mon Mar 23 16:58:45 2026 +0800 debugfs: fix placement of EXPORT_SYMBOL_GPL for debugfs_create_str() [ Upstream commit 4afc929c0f74c4f22b055a82b371d50586da58ca ] The EXPORT_SYMBOL_GPL() for debugfs_create_str was placed incorrectly away from the function definition. Move it immediately below the debugfs_create_str() function where it belongs. Fixes: d60b59b96795 ("debugfs: Export debugfs_create_str symbol") Signed-off-by: Gui-Dong Han Link: https://patch.msgid.link/20260323085930.88894-3-hanguidong02@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 172b40b1468eccc9e45aa4c4acf8603f9fc6c709 Author: Gui-Dong Han Date: Mon Mar 23 16:58:44 2026 +0800 debugfs: check for NULL pointer in debugfs_create_str() [ Upstream commit 31de83980d3764d784f79ff1bc93c42b324f4013 ] Passing a NULL pointer to debugfs_create_str() leads to a NULL pointer dereference when the debugfs file is read. Following upstream discussions, forbid the creation of debugfs string files with NULL pointers. Add a WARN_ON() to expose offending callers and return early. Fixes: 9af0440ec86e ("debugfs: Implement debugfs_create_str()") Reported-by: yangshiguang Closes: https://lore.kernel.org/lkml/2025122221-gag-malt-75ba@gregkh/ Suggested-by: Greg Kroah-Hartman Signed-off-by: Gui-Dong Han Link: https://patch.msgid.link/20260323085930.88894-2-hanguidong02@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5b4604cd5a9dc65a64904417c16b9933f7dfee84 Author: Gopi Krishna Menon Date: Fri Mar 27 14:35:24 2026 +0530 thermal/drivers/spear: Fix error condition for reading st,thermal-flags [ Upstream commit da2c4f332a0504d9c284e7626a561d343c8d6f57 ] of_property_read_u32 returns 0 on success. The current check returns -EINVAL if the property is read successfully. Fix the check by removing ! from of_property_read_u32 Fixes: b9c7aff481f1 ("drivers/thermal/spear_thermal.c: add Device Tree probing capability") Signed-off-by: Gopi Krishna Menon Signed-off-by: Daniel Lezcano Suggested-by: Daniel Baluta Reviewed-by: Lukasz Luba Link: https://patch.msgid.link/20260327090526.59330-1-krishnagopi487@gmail.com Signed-off-by: Sasha Levin commit 01cdbf3dcf89a56362260141d39ce2d93af0939b Author: Danilo Krummrich Date: Tue Feb 3 00:48:14 2026 +0100 devres: fix missing node debug info in devm_krealloc() [ Upstream commit f813ec9e84b4d0ca81ec1da94ab07bfb4a29266c ] Fix missing call to set_node_dbginfo() for new devres nodes created by devm_krealloc(). Fixes: f82485722e5d ("devres: provide devm_krealloc()") Reviewed-by: Greg Kroah-Hartman Link: https://patch.msgid.link/20260202235210.55176-2-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit ae04d2e67f9ac2106f2f97a4f4b922ce7f9bcb46 Author: Rafael J. Wysocki Date: Mon Feb 23 16:28:57 2026 +0100 ACPI: x86: cmos_rtc: Improve coordination with ACPI TAD driver [ Upstream commit 6cee29ad9d7e400d39ae0b1a54447fedcb62eecd ] If a CMOS RTC (PNP0B00/PNP0B01/PNP0B02) device coexists with an ACPI TAD (timer and event alarm device, ACPI000E), the ACPI TAD driver will attempt to install the CMOS RTC address space hanlder that has been installed already and the TAD probing will fail. Avoid that by changing acpi_install_cmos_rtc_space_handler() to return zero and acpi_remove_cmos_rtc_space_handler() to do nothing if the CMOS RTC address space handler has been installed already. Fixes: 596ca52a56da ("ACPI: TAD: Install SystemCMOS address space handler for ACPI000E") Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2415111.ElGaqSPkdT@rafael.j.wysocki Signed-off-by: Sasha Levin commit 9f8a61db50a8739126ca247ef06436225651ee6d Author: Rafael J. Wysocki Date: Mon Feb 23 16:28:15 2026 +0100 ACPI: x86: cmos_rtc: Clean up address space handler driver [ Upstream commit ba0b236736dde4059bdcb8e99beaa50d6e5b6e7e ] Make multiple changes that do not alter functionality to the CMOS RTC ACPI address space handler driver, including the following: - Drop the unused .detach() callback from cmos_rtc_handler. - Rename acpi_cmos_rtc_attach_handler() to acpi_cmos_rtc_attach(). - Rearrange acpi_cmos_rtc_space_handler() to reduce the number of redundant checks and make white space follow the coding style. - Adjust an error message in acpi_install_cmos_rtc_space_handler() and make the white space follow the coding style. - Rearrange acpi_remove_cmos_rtc_space_handler() and adjust an error message in it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/5094429.31r3eYUQgx@rafael.j.wysocki Stable-dep-of: 6cee29ad9d7e ("ACPI: x86: cmos_rtc: Improve coordination with ACPI TAD driver") Signed-off-by: Sasha Levin commit 265ab7e7d40d750b40725bea05281f77699cff0d Author: Viresh Kumar Date: Mon Feb 23 11:05:59 2026 +0530 OPP: Move break out of scoped_guard in dev_pm_opp_xlate_required_opp() [ Upstream commit 3d2398f44a2d48fb1c575a6e0bc6b38f3e689e22 ] The commit ff9c512041f2 ("OPP: Use mutex locking guards") unintentionally made the for loop run longer than required. scoped_guard() is implemented as a for loop. The break statement now breaks out out the scoped_guard() and not out of the outer for loop. The outer loop always iterates to completion. Fix it. Fixes: ff9c512041f2 ("OPP: Use mutex locking guards") Reported-by: David Lechner Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 7cbabc3411a75fc07faa3755896ee663d7208ed1 Author: Manivannan Sadhasivam Date: Fri Jan 30 12:49:40 2026 +0530 OPP: debugfs: Use performance level if available to distinguish between rates [ Upstream commit e560083c0467f86b72aecac377b27bd1e7d16c49 ] Some OPP tables have entries with same rate and different performance level. For these entries, using only the rate as the debugfs directory name causes below error: debugfs: 'opp:5000000' already exists in 'soc@0-1c00000.pci' Fix it by appending the performance level to the dir name if available. Reported-by: Bjorn Andersson Closes: https://lore.kernel.org/linux-arm-msm/75lzykd37zdvrks5i2bb4zb2yzjtm25kv3hegmikndkbr772mz@w2ykff3ny45u/ Fixes: 05db35963eef ("OPP: Add support to find OPP for a set of keys") Signed-off-by: Manivannan Sadhasivam Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 9a24f0000876b8755cf21972b41632f4d6f3dafb Author: Filipe Manana Date: Mon Mar 23 15:50:13 2026 +0000 btrfs: fix deadlock between reflink and transaction commit when using flushoncommit [ Upstream commit b48c980b6a7e409050bb3067165db31cc6205e3e ] When using the flushoncommit mount option, we can have a deadlock between a transaction commit and a reflink operation that copied an inline extent to an offset beyond the current i_size of the destination node. The deadlock happens like this: 1) Task A clones an inline extent from inode X to an offset of inode Y that is beyond Y's current i_size. This means we copied the inline extent's data to a folio of inode Y that is beyond its EOF, using a call to copy_inline_to_page(); 2) Task B starts a transaction commit and calls btrfs_start_delalloc_flush() to flush delalloc; 3) The delalloc flushing sees the new dirty folio of inode Y and when it attempts to flush it, it ends up at extent_writepage() and sees that the offset of the folio is beyond the i_size of inode Y, so it attempts to invalidate the folio by calling folio_invalidate(), which ends up at btrfs' folio invalidate callback - btrfs_invalidate_folio(). There it tries to lock the folio's range in inode Y's extent io tree, but it blocks since it's currently locked by task A - during a reflink we lock the inodes and the source and destination ranges after flushing all delalloc and waiting for ordered extent completion - after that we don't expect to have dirty folios in the ranges, the exception is if we have to copy an inline extent's data (because the destination offset is not zero); 4) Task A then attempts to start a transaction to update the inode item, and then it's blocked since the current transaction is in the TRANS_STATE_COMMIT_START state. Therefore task A has to wait for the current transaction to become unblocked (its state >= TRANS_STATE_UNBLOCKED). So task A is waiting for the transaction commit done by task B, and the later waiting on the extent lock of inode Y that is currently held by task A. Syzbot recently reported this with the following stack traces: INFO: task kworker/u8:7:1053 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:7 state:D stack:23520 pid:1053 tgid:1053 ppid:2 task_flags:0x4208060 flags:0x00080000 Workqueue: writeback wb_workfn (flush-btrfs-46) Call Trace: context_switch kernel/sched/core.c:5298 [inline] __schedule+0x1553/0x5240 kernel/sched/core.c:6911 __schedule_loop kernel/sched/core.c:6993 [inline] schedule+0x164/0x360 kernel/sched/core.c:7008 wait_extent_bit fs/btrfs/extent-io-tree.c:811 [inline] btrfs_lock_extent_bits+0x59c/0x700 fs/btrfs/extent-io-tree.c:1914 btrfs_lock_extent fs/btrfs/extent-io-tree.h:152 [inline] btrfs_invalidate_folio+0x43d/0xc40 fs/btrfs/inode.c:7704 extent_writepage fs/btrfs/extent_io.c:1852 [inline] extent_write_cache_pages fs/btrfs/extent_io.c:2580 [inline] btrfs_writepages+0x12ff/0x2440 fs/btrfs/extent_io.c:2713 do_writepages+0x32e/0x550 mm/page-writeback.c:2554 __writeback_single_inode+0x133/0x11a0 fs/fs-writeback.c:1750 writeback_sb_inodes+0x995/0x19d0 fs/fs-writeback.c:2042 wb_writeback+0x456/0xb70 fs/fs-writeback.c:2227 wb_do_writeback fs/fs-writeback.c:2374 [inline] wb_workfn+0x41a/0xf60 fs/fs-writeback.c:2414 process_one_work kernel/workqueue.c:3276 [inline] process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c:3359 worker_thread+0xa53/0xfc0 kernel/workqueue.c:3440 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 INFO: task syz.4.64:6910 blocked for more than 143 seconds. Not tainted syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz.4.64 state:D stack:22752 pid:6910 tgid:6905 ppid:5944 task_flags:0x400140 flags:0x00080002 Call Trace: context_switch kernel/sched/core.c:5298 [inline] __schedule+0x1553/0x5240 kernel/sched/core.c:6911 __schedule_loop kernel/sched/core.c:6993 [inline] schedule+0x164/0x360 kernel/sched/core.c:7008 wait_current_trans+0x39f/0x590 fs/btrfs/transaction.c:535 start_transaction+0x6a7/0x1650 fs/btrfs/transaction.c:705 clone_copy_inline_extent fs/btrfs/reflink.c:299 [inline] btrfs_clone+0x128a/0x24d0 fs/btrfs/reflink.c:529 btrfs_clone_files+0x271/0x3f0 fs/btrfs/reflink.c:750 btrfs_remap_file_range+0x76b/0x1320 fs/btrfs/reflink.c:903 vfs_copy_file_range+0xda7/0x1390 fs/read_write.c:1600 __do_sys_copy_file_range fs/read_write.c:1683 [inline] __se_sys_copy_file_range+0x2fb/0x480 fs/read_write.c:1650 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f5f73afc799 RSP: 002b:00007f5f7315e028 EFLAGS: 00000246 ORIG_RAX: 0000000000000146 RAX: ffffffffffffffda RBX: 00007f5f73d75fa0 RCX: 00007f5f73afc799 RDX: 0000000000000005 RSI: 0000000000000000 RDI: 0000000000000005 RBP: 00007f5f73b92c99 R08: 0000000000000863 R09: 0000000000000000 R10: 00002000000000c0 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f5f73d76038 R14: 00007f5f73d75fa0 R15: 00007fff138a5068 INFO: task syz.4.64:6975 blocked for more than 143 seconds. Not tainted syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz.4.64 state:D stack:24736 pid:6975 tgid:6905 ppid:5944 task_flags:0x400040 flags:0x00080002 Call Trace: context_switch kernel/sched/core.c:5298 [inline] __schedule+0x1553/0x5240 kernel/sched/core.c:6911 __schedule_loop kernel/sched/core.c:6993 [inline] schedule+0x164/0x360 kernel/sched/core.c:7008 wb_wait_for_completion+0x3e8/0x790 fs/fs-writeback.c:227 __writeback_inodes_sb_nr+0x24c/0x2d0 fs/fs-writeback.c:2838 try_to_writeback_inodes_sb+0x9a/0xc0 fs/fs-writeback.c:2886 btrfs_start_delalloc_flush fs/btrfs/transaction.c:2175 [inline] btrfs_commit_transaction+0x82e/0x31a0 fs/btrfs/transaction.c:2364 btrfs_ioctl+0xca7/0xd00 fs/btrfs/ioctl.c:5206 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xff/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f5f73afc799 RSP: 002b:00007f5f7313d028 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f5f73d76090 RCX: 00007f5f73afc799 RDX: 0000000000000000 RSI: 0000000000009408 RDI: 0000000000000004 RBP: 00007f5f73b92c99 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f5f73d76128 R14: 00007f5f73d76090 R15: 00007fff138a5068 Fix this by updating the i_size of the destination inode of a reflink operation after we copy an inline extent's data to an offset beyond the i_size and before attempting to start a transaction to update the inode's item. Reported-by: syzbot+63056bf627663701bbbf@syzkaller.appspotmail.com Link: https://lore.kernel.org/linux-btrfs/69bba3fe.050a0220.227207.002f.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 ff6b93410192b812d73cc54062529715b2dc849f Author: Yu Kuai Date: Fri Mar 27 22:07:29 2026 +0800 md: wake raid456 reshape waiters before suspend [ Upstream commit cf86bb53b9c92354904a328e947a05ffbfdd1840 ] During raid456 reshape, direct IO across the reshape position can sleep in raid5_make_request() waiting for reshape progress while still holding an active_io reference. If userspace then freezes reshape and writes md/suspend_lo or md/suspend_hi, mddev_suspend() kills active_io and waits for all in-flight IO to drain. This can deadlock: the IO needs reshape progress to continue, but the reshape thread is already frozen, so the active_io reference is never dropped and suspend never completes. raid5_prepare_suspend() already wakes wait_for_reshape for dm-raid. Do the same for normal md suspend when reshape is already interrupted, so waiting raid456 IO can abort, drop its reference, and let suspend finish. The mdadm test tests/25raid456-reshape-deadlock reproduces the hang. Fixes: 714d20150ed8 ("md: add new helpers to suspend/resume array") Link: https://lore.kernel.org/linux-raid/20260327140729.2030564-1-yukuai@fnnas.com/ Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit f8b799e4fd97841ab23cf448fdef30cfd09b2f9d Author: Abd-Alrhman Masalkhi Date: Sat Mar 28 22:35:22 2026 +0300 md: remove unused static md_wq workqueue [ Upstream commit e4979f4fac4d6bbe757be50441b45e28e6bf7360 ] The md_wq workqueue is defined as static and initialized in md_init(), but it is not used anywhere within md.c. All asynchronous and deferred work in this file is handled via md_misc_wq or dedicated md threads. Fixes: b75197e86e6d3 ("md: Remove flush handling") Signed-off-by: Abd-Alrhman Masalkhi Link: https://lore.kernel.org/linux-raid/20260328193522.3624-1-abd.masalkhi@gmail.com/ Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 3f1e2902b5ecb821f99fe4c0c6781d93ee1a23cc Author: Marco Crivellari Date: Tue Jan 13 12:03:02 2026 +0100 dm: add WQ_PERCPU to alloc_workqueue users [ Upstream commit d4880868670198df321627a949e7b7f2d76cf54e ] 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. Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/ Suggested-by: Tejun Heo Signed-off-by: Marco Crivellari Signed-off-by: Mikulas Patocka Stable-dep-of: e4979f4fac4d ("md: remove unused static md_wq workqueue") Signed-off-by: Sasha Levin commit d5559ac21f4a0e112a0a18292da51ba5fc402a6f Author: Zhan Xusheng Date: Fri Apr 3 14:36:58 2026 +0800 erofs: handle 48-bit blocks/uniaddr for extra devices [ Upstream commit 63c2f06198ca7513433f1c92f2c654869d72417e ] erofs_init_device() only reads blocks_lo and uniaddr_lo from the on-disk device slot, ignoring blocks_hi and uniaddr_hi that were introduced alongside the 48-bit block addressing feature. For the primary device (dif0), erofs_read_superblock() already handles this correctly by combining blocks_lo with blocks_hi when 48-bit layout is enabled. But the same logic was not applied to extra devices. With a 48-bit EROFS image using extra devices whose uniaddr or blocks exceed 32-bit range, the truncated values cause erofs_map_dev() to compute wrong physical addresses, leading to silent data corruption. Fix this by reading blocks_hi and uniaddr_hi in erofs_init_device() when 48-bit layout is enabled, consistent with the primary device handling. Also fix the erofs_deviceslot on-disk definition where blocks_hi was incorrectly declared as __le32 instead of __le16. Fixes: 61ba89b57905 ("erofs: add 48-bit block addressing on-disk support") Suggested-by: Gao Xiang Signed-off-by: Zhan Xusheng Reviewed-by: Gao Xiang Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 62c44566da7493ee48ef17e8507bb798338a07cb Author: Yu Kuai Date: Mon Mar 30 13:52:13 2026 +0800 md: fix array_state=clear sysfs deadlock [ Upstream commit 2aa72276fab9851dbd59c2daeb4b590c5a113908 ] When "clear" is written to array_state, md_attr_store() breaks sysfs active protection so the array can delete itself from its own sysfs store method. However, md_attr_store() currently drops the mddev reference before calling sysfs_unbreak_active_protection(). Once do_md_stop(..., 0) has made the mddev eligible for delayed deletion, the temporary kobject reference taken by sysfs_break_active_protection() can become the last kobject reference protecting the md kobject. That allows sysfs_unbreak_active_protection() to drop the last kobject reference from the current sysfs writer context. kobject teardown then recurses into kernfs removal while the current sysfs node is still being unwound, and lockdep reports recursive locking on kn->active with kernfs_drain() in the call chain. Reproducer on an existing level: 1. Create an md0 linear array and activate it: mknod /dev/md0 b 9 0 echo none > /sys/block/md0/md/metadata_version echo linear > /sys/block/md0/md/level echo 1 > /sys/block/md0/md/raid_disks echo "$(cat /sys/class/block/sdb/dev)" > /sys/block/md0/md/new_dev echo "$(($(cat /sys/class/block/sdb/size) / 2))" > \ /sys/block/md0/md/dev-sdb/size echo 0 > /sys/block/md0/md/dev-sdb/slot echo active > /sys/block/md0/md/array_state 2. Wait briefly for the array to settle, then clear it: sleep 2 echo clear > /sys/block/md0/md/array_state The warning looks like: WARNING: possible recursive locking detected bash/588 is trying to acquire lock: (kn->active#65) at __kernfs_remove+0x157/0x1d0 but task is already holding lock: (kn->active#65) at sysfs_unbreak_active_protection+0x1f/0x40 ... Call Trace: kernfs_drain __kernfs_remove kernfs_remove_by_name_ns sysfs_remove_group sysfs_remove_groups __kobject_del kobject_put md_attr_store kernfs_fop_write_iter vfs_write ksys_write Restore active protection before mddev_put() so the extra sysfs kobject reference is dropped while the mddev is still held alive. The actual md kobject deletion is then deferred until after the sysfs write path has fully returned. Fixes: 9e59d609763f ("md: call del_gendisk in control path") Reviewed-by: Xiao Ni Link: https://lore.kernel.org/linux-raid/20260330055213.3976052-1-yukuai@fnnas.com/ Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 46194b5ba93b7cf9d1409baa202239ff044ec852 Author: Zhan Xusheng Date: Wed Apr 1 14:13:42 2026 +0800 erofs: include the trailing NUL in FS_IOC_GETFSLABEL [ Upstream commit d6250d49da4d8f11afc0d8991c84e0307949f92e ] erofs_ioctl_get_volume_label() passes strlen(sbi->volume_name) as the length to copy_to_user(), which copies the label string without the trailing NUL byte. Since FS_IOC_GETFSLABEL callers expect a NUL-terminated string in the FSLABEL_MAX-sized buffer and may not pre-zero the buffer, this can cause userspace to read past the label into uninitialised stack memory. Fix this by using strlen() + 1 to include the NUL terminator, consistent with how ext4 and xfs implement FS_IOC_GETFSLABEL. Signed-off-by: Zhan Xusheng Fixes: 1cf12c717741 ("erofs: Add support for FS_IOC_GETFSLABEL") Reviewed-by: Gao Xiang Reviewed-by: Chunhai Guo Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 5263ed3dd13b32179cb94247959f3207583520ac Author: Cole Leavitt Date: Wed Feb 25 16:54:06 2026 -0700 pstore/ram: fix resource leak when ioremap() fails [ Upstream commit 2ddb69f686ef7a621645e97fc7329c50edf5d0e5 ] In persistent_ram_iomap(), ioremap() or ioremap_wc() may return NULL on failure. Currently, if this happens, the function returns NULL without releasing the memory region acquired by request_mem_region(). This leads to a resource leak where the memory region remains reserved but unusable. Additionally, the caller persistent_ram_buffer_map() handles NULL correctly by returning -ENOMEM, but without this check, a NULL return combined with request_mem_region() succeeding leaves resources in an inconsistent state. This is the ioremap() counterpart to commit 05363abc7625 ("pstore: ram_core: fix incorrect success return when vmap() fails") which fixed a similar issue in the vmap() path. Fixes: 404a6043385d ("staging: android: persistent_ram: handle reserving and mapping memory") Signed-off-by: Cole Leavitt Link: https://patch.msgid.link/20260225235406.11790-1-cole@unwrap.rs Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit b3e005f16cd98f815429a87aef4c61e9c140779f Author: Jackie Liu Date: Tue Mar 31 16:50:54 2026 +0800 blk-cgroup: fix disk reference leak in blkcg_maybe_throttle_current() [ Upstream commit 23308af722fefed00af5f238024c11710938fba3 ] Add the missing put_disk() on the error path in blkcg_maybe_throttle_current(). When blkcg lookup, blkg lookup, or blkg_tryget() fails, the function jumps to the out label which only calls rcu_read_unlock() but does not release the disk reference acquired by blkcg_schedule_throttle() via get_device(). Since current->throttle_disk is already set to NULL before the lookup, blkcg_exit() cannot release this reference either, causing the disk to never be freed. Restore the reference release that was present as blk_put_queue() in the original code but was inadvertently dropped during the conversion from request_queue to gendisk. Fixes: f05837ed73d0 ("blk-cgroup: store a gendisk to throttle in struct task_struct") Signed-off-by: Jackie Liu Acked-by: Tejun Heo Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260331085054.46857-1-liu.yun@linux.dev Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e5ff0ba4b6983cdbcc826efc201e7179ece5d46f Author: Deepanshu Kartikey Date: Wed Apr 1 02:52:09 2026 +0900 nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty() [ Upstream commit be3e5d10643d3be1cbac9d9939f220a99253f980 ] nilfs_ioctl_mark_blocks_dirty() uses bd_oblocknr to detect dead blocks by comparing it with the current block number bd_blocknr. If they differ, the block is considered dead and skipped. However, bd_oblocknr should never be 0 since block 0 typically stores the primary superblock and is never a valid GC target block. A corrupted ioctl request with bd_oblocknr set to 0 causes the comparison to incorrectly match when the lookup returns -ENOENT and sets bd_blocknr to 0, bypassing the dead block check and calling nilfs_bmap_mark() on a non-existent block. This causes nilfs_btree_do_lookup() to return -ENOENT, triggering the WARN_ON(ret == -ENOENT). Fix this by rejecting ioctl requests with bd_oblocknr set to 0 at the beginning of each iteration. [ryusuke: slightly modified the commit message and comments for accuracy] Fixes: 7942b919f732 ("nilfs2: ioctl operations") Reported-by: syzbot+98a040252119df0506f8@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=98a040252119df0506f8 Suggested-by: Ryusuke Konishi Signed-off-by: Deepanshu Kartikey Reported-by: syzbot+466a45fcfb0562f5b9a0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=466a45fcfb0562f5b9a0 Cc: Junjie Cao Signed-off-by: Ryusuke Konishi Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 37466ec483eadd27dd3000c0900a8aa0e4cf5ebb Author: Daan De Meyer Date: Tue Mar 31 10:51:28 2026 +0000 loop: fix partition scan race between udev and loop_reread_partitions() [ Upstream commit 267ec4d7223a783f029a980f41b93c39b17996da ] When LOOP_CONFIGURE is called with LO_FLAGS_PARTSCAN, the following sequence occurs: 1. disk_force_media_change() sets GD_NEED_PART_SCAN 2. Uevent suppression is lifted and a KOBJ_CHANGE uevent is sent 3. loop_global_unlock() releases the lock 4. loop_reread_partitions() calls bdev_disk_changed() to scan There is a race between steps 2 and 4: when udev receives the uevent and opens the device before loop_reread_partitions() runs, blkdev_get_whole() in bdev.c sees GD_NEED_PART_SCAN set and calls bdev_disk_changed() for a first scan. Then loop_reread_partitions() does a second scan. The open_mutex serializes these two scans, but does not prevent both from running. The second scan in bdev_disk_changed() drops all partition devices from the first scan (via blk_drop_partitions()) before re-adding them, causing partition block devices to briefly disappear. This breaks any systemd unit with BindsTo= on the partition device: systemd observes the device going dead, fails the dependent units, and does not retry them when the device reappears. Fix this by removing the GD_NEED_PART_SCAN set from disk_force_media_change() entirely. None of the current callers need the lazy on-open partition scan triggered by this flag: - floppy: sets GENHD_FL_NO_PART, so disk_has_partscan() is always false and GD_NEED_PART_SCAN has no effect. - loop (loop_configure, loop_change_fd): when LO_FLAGS_PARTSCAN is set, loop_reread_partitions() performs an explicit scan. When not set, GD_SUPPRESS_PART_SCAN prevents the lazy scan path. - loop (__loop_clr_fd): calls bdev_disk_changed() explicitly if LO_FLAGS_PARTSCAN is set. - nbd (nbd_clear_sock_ioctl): capacity is set to zero immediately after; nbd manages GD_NEED_PART_SCAN explicitly elsewhere. With GD_NEED_PART_SCAN no longer set by disk_force_media_change(), udev opening the loop device after the uevent no longer triggers a redundant scan in blkdev_get_whole(), and only the single explicit scan from loop_reread_partitions() runs. A regression test for this bug has been submitted to blktests: https://github.com/linux-blktests/blktests/pull/240. Fixes: 9f65c489b68d ("loop: raise media_change event") Signed-off-by: Daan De Meyer Acked-by: Christian Brauner Link: https://patch.msgid.link/20260331105130.1077599-1-daan@amutable.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 996d279f2c985d771d6cfdd923e447d825726e06 Author: Bart Van Assche Date: Thu Mar 26 14:40:54 2026 -0700 drbd: Balance RCU calls in drbd_adm_dump_devices() [ Upstream commit 2b31e86387e60b3689339f0f0fbb4d3623d9d494 ] Make drbd_adm_dump_devices() call rcu_read_lock() before rcu_read_unlock() is called. This has been detected by the Clang thread-safety analyzer. Tested-by: Christoph Böhmwalder Reviewed-by: Christoph Hellwig Cc: Andreas Gruenbacher Fixes: a55bbd375d18 ("drbd: Backport the "status" command") Signed-off-by: Bart Van Assche Link: https://patch.msgid.link/20260326214054.284593-1-bvanassche@acm.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c3ec2db64bfe690f29fb0019e193803ff0334852 Author: Xiao Ni Date: Thu Mar 5 09:18:33 2026 +0800 md/raid1: fix the comparing region of interval tree [ Upstream commit de3544d2e5ea99064498de3c21ba490155864657 ] Interval tree uses [start, end] as a region which stores in the tree. In raid1, it uses the wrong end value. For example: bio(A,B) is too big and needs to be split to bio1(A,C-1), bio2(C,B). The region of bio1 is [A,C] and the region of bio2 is [C,B]. So bio1 and bio2 overlap which is not right. Fix this problem by using right end value of the region. Fixes: d0d2d8ba0494 ("md/raid1: introduce wait_for_serialization") Signed-off-by: Xiao Ni Link: https://lore.kernel.org/linux-raid/20260305011839.5118-2-xni@redhat.com/ Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 0e4eff315d799f5842b95872199b0f0fb8ef5f51 Author: HyungJung Joo Date: Tue Mar 17 14:45:56 2026 +0900 fs/mbcache: cancel shrink work before destroying the cache [ Upstream commit d227786ab1119669df4dc333a61510c52047cce4 ] mb_cache_destroy() calls shrinker_free() and then frees all cache entries and the cache itself, but it does not cancel the pending c_shrink_work work item first. If mb_cache_entry_create() schedules c_shrink_work via schedule_work() and the work item is still pending or running when mb_cache_destroy() runs, mb_cache_shrink_worker() will access the cache after its memory has been freed, causing a use-after-free. This is only reachable by a privileged user (root or CAP_SYS_ADMIN) who can trigger the last put of a mounted ext2/ext4/ocfs2 filesystem. Cancel the work item with cancel_work_sync() before calling shrinker_free(), ensuring the worker has finished and will not be rescheduled before the cache is torn down. Fixes: c2f3140fe2ec ("mbcache2: limit cache size") Signed-off-by: Hyungjung Joo Link: https://patch.msgid.link/20260317054556.1821600-1-jhj140711@gmail.com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 6561afc38398e3518a29c5eebb975c30468f98a6 Author: HyungJung Joo Date: Tue Mar 17 14:48:27 2026 +0900 fs/omfs: reject s_sys_blocksize smaller than OMFS_DIR_START [ Upstream commit 0621c385fda1376e967f37ccd534c26c3e511d14 ] omfs_fill_super() rejects oversized s_sys_blocksize values (> PAGE_SIZE), but it does not reject values smaller than OMFS_DIR_START (0x1b8 = 440). Later, omfs_make_empty() uses sbi->s_sys_blocksize - OMFS_DIR_START as the length argument to memset(). Since s_sys_blocksize is u32, a crafted filesystem image with s_sys_blocksize < OMFS_DIR_START causes an unsigned underflow there, wrapping to a value near 2^32. That drives a ~4 GiB memset() from bh->b_data + OMFS_DIR_START and overwrites kernel memory far beyond the backing block buffer. Add the corresponding lower-bound check alongside the existing upper-bound check in omfs_fill_super(), so that malformed images are rejected during superblock validation before any filesystem data is processed. Fixes: a3ab7155ea21 ("omfs: add directory routines") Signed-off-by: Hyungjung Joo Link: https://patch.msgid.link/20260317054827.1822061-1-jhj140711@gmail.com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 93383b66810740eb27fab1b31728beb0cb75c1dd Author: Ming Lei Date: Wed Mar 11 11:28:37 2026 +0800 blk-cgroup: wait for blkcg cleanup before initializing new disk [ Upstream commit 3dbaacf6ab68f81e3375fe769a2ecdbd3ce386fd ] When a queue is shared across disk rebind (e.g., SCSI unbind/bind), the previous disk's blkcg state is cleaned up asynchronously via disk_release() -> blkcg_exit_disk(). If the new disk's blkcg_init_disk() runs before that cleanup finishes, we may overwrite q->root_blkg while the old one is still alive, and radix_tree_insert() in blkg_create() fails with -EEXIST because the old blkg entries still occupy the same queue id slot in blkcg->blkg_tree. This causes the sd probe to fail with -ENOMEM. Fix it by waiting in blkcg_init_disk() for root_blkg to become NULL, which indicates the previous disk's blkcg cleanup has completed. Fixes: 1059699f87eb ("block: move blkcg initialization/destroy into disk allocation/release handler") Cc: Yi Zhang Signed-off-by: Ming Lei Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260311032837.2368714-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit dbbf2fd18057da9f1865f7a204a20a16ef6a3f84 Author: Alexandre Frade Date: Sun May 17 19:11:21 2026 +0000 Linux 6.18.32-rt-xanmod1 Signed-off-by: Alexandre Frade commit 7b252613368b5b5a3853758e9996edb7028f4cfa Merge: 291696c6d6db 9ed50b728578 Author: Alexandre Frade Date: Sun May 17 19:09:27 2026 +0000 Merge branch '6.18' into 6.18-rt commit 9ed50b728578e330e19c208ae099c680c6b219d4 Author: Alexandre Frade Date: Sun May 17 19:05:16 2026 +0000 Linux 6.18.32-xanmod1 Signed-off-by: Alexandre Frade commit 28b6603dc6ccdcdeb8f1ac9f737335f47e9a39d0 Merge: 54defdf30fa9 52386a7b1beb Author: Alexandre Frade Date: Sun May 17 19:03:50 2026 +0000 Merge tag 'v6.18.32' into 6.18 This is the 6.18.32 stable release commit 52386a7b1beb0a7cb5a304935f73c157109c09ad Author: Greg Kroah-Hartman Date: Sun May 17 17:15:37 2026 +0200 Linux 6.18.32 Link: https://lore.kernel.org/r/20260515154657.309489048@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Miguel Ojeda Tested-by: Mark Brown Tested-by: Brett A C Sheffield Link: https://lore.kernel.org/r/20260516102236.209957148@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Ron Economos Tested-by: Peter Schneider Tested-by: Miguel Ojeda Tested-by: Wentao Guan Signed-off-by: Greg Kroah-Hartman commit 271cd5429513ff9b364a9bf8903e5b65b687eb25 Author: Benjamin Cheng Date: Mon Apr 13 09:22:15 2026 -0400 drm/amdgpu/vcn4: Avoid overflow on msg bound check commit 65bce27ea6192320448c30267ffc17ffa094e713 upstream. As pointed out by SDL, the previous condition may be vulnerable to overflow. Fixes: 0a78f2bac142 ("drm/amdgpu/vcn4: Prevent OOB reads when parsing dec msg") Cc: SDL Signed-off-by: Benjamin Cheng Reviewed-by: Ruijing Dong Signed-off-by: Alex Deucher (cherry picked from commit 3c5367d950140d4ec7af830b2268a5a6fdaa3885) Signed-off-by: Greg Kroah-Hartman commit 016b64a0313ea5346cf526e30c8d3e66aca10175 Author: Benjamin Cheng Date: Mon Apr 13 09:22:15 2026 -0400 drm/amdgpu/vcn3: Avoid overflow on msg bound check commit e6e9faba8100628990cccd13f0f044a648c303cf upstream. As pointed out by SDL, the previous condition may be vulnerable to overflow. Fixes: b193019860d6 ("drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg") Cc: SDL Signed-off-by: Benjamin Cheng Reviewed-by: Ruijing Dong Signed-off-by: Alex Deucher (cherry picked from commit db00257ac9e4a51eb2515aaea161a019f7125e10) Signed-off-by: Greg Kroah-Hartman commit e9edf9893cf26d060705c910a9b62d8cc96ed56a Author: Dudu Lu Date: Mon Apr 13 21:14:09 2026 +0800 vsock/virtio: fix accept queue count leak on transport mismatch commit 52bcb57a4e8a0865a76c587c2451906342ae1b2d upstream. virtio_transport_recv_listen() calls sk_acceptq_added() before vsock_assign_transport(). If vsock_assign_transport() fails or selects a different transport, the error path returns without calling sk_acceptq_removed(), permanently incrementing sk_ack_backlog. After approximately backlog+1 such failures, sk_acceptq_is_full() returns true, causing the listener to reject all new connections. Fix by moving sk_acceptq_added() to after the transport validation, matching the pattern used by vmci_transport and hyperv_transport. Fixes: c0cfa2d8a788 ("vsock: add multi-transports support") Signed-off-by: Dudu Lu Reviewed-by: Bobby Eshleman Reviewed-by: Luigi Leonardi Reviewed-by: Stefano Garzarella Acked-by: Michael S. Tsirkin Link: https://patch.msgid.link/20260413131409.19022-1-phx0fer@gmail.com Signed-off-by: Paolo Abeni Cc: Luigi Leonardi Signed-off-by: Greg Kroah-Hartman commit 52da6a74ca3de0fcda60301096b71534b3b18641 Author: Stefano Garzarella Date: Fri May 8 18:44:11 2026 +0200 vsock/virtio: fix empty payload in tap skb for non-linear buffers commit 3a3e3d90cbc79600544536723911657730759af3 upstream. For non-linear skbs, virtio_transport_build_skb() goes through virtio_transport_copy_nonlinear_skb() to copy the original payload in the new skb to be delivered to the vsockmon tap device. This manually initializes an iov_iter but does not set iov_iter.count. Since the iov_iter is zero-initialized, the copy length is zero and no payload is actually copied to the monitor interface, leaving data un-initialized. Fix this by removing the linear vs non-linear split and using skb_copy_datagram_iter() with iov_iter_kvec() for all cases, as vhost-vsock already does. This handles both linear and non-linear skbs, properly initializes the iov_iter, and removes the now unused virtio_transport_copy_nonlinear_skb(). While touching this code, let's also check the return value of skb_copy_datagram_iter(), even though it's unlikely to fail. Fixes: 4b0bf10eb077 ("vsock/virtio: non-linear skb handling for tap") Reported-by: Yiqi Sun Signed-off-by: Stefano Garzarella Reviewed-by: Bobby Eshleman Reviewed-by: Arseniy Krasnov Link: https://patch.msgid.link/20260508164411.261440-3-sgarzare@redhat.com Acked-by: Michael S. Tsirkin Signed-off-by: Paolo Abeni Cc: Luigi Leonardi Signed-off-by: Greg Kroah-Hartman commit a534e1f985b6472abef80437a0dc75e7a259f4fa Author: Stefano Garzarella Date: Fri May 8 18:44:10 2026 +0200 vsock/virtio: fix length and offset in tap skb for split packets commit 5f344d809e015fba3709e5219428c00b8ac5d7df upstream. virtio_transport_build_skb() builds a new skb to be delivered to the vsockmon tap device. To build the new skb, it uses the original skb data length as payload length, but as the comment notes, the original packet stored in the skb may have been split in multiple packets, so we need to use the length in the header, which is correctly updated before the packet is delivered to the tap, and the offset for the data. This was also similar to what we did before commit 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff") where we probably missed something during the skb conversion. Also update the comment above, which was left stale by the skb conversion and still mentioned a buffer pointer that no longer exists. Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff") Signed-off-by: Stefano Garzarella Reviewed-by: Bobby Eshleman Reviewed-by: Arseniy Krasnov Link: https://patch.msgid.link/20260508164411.261440-2-sgarzare@redhat.com Acked-by: Michael S. Tsirkin Signed-off-by: Paolo Abeni Cc: Luigi Leonardi Signed-off-by: Greg Kroah-Hartman commit 2602f7bb5818e92315feeaeb71d8ce4d5c9ab160 Author: Norbert Szetei Date: Thu Apr 9 18:34:12 2026 +0200 vsock: fix buffer size clamping order commit d114bfdc9b76bf93b881e195b7ec957c14227bab upstream. In vsock_update_buffer_size(), the buffer size was being clamped to the maximum first, and then to the minimum. If a user sets a minimum buffer size larger than the maximum, the minimum check overrides the maximum check, inverting the constraint. This breaks the intended socket memory boundaries by allowing the vsk->buffer_size to grow beyond the configured vsk->buffer_max_size. Fix this by checking the minimum first, and then the maximum. This ensures the buffer size never exceeds the buffer_max_size. Fixes: b9f2b0ffde0c ("vsock: handle buffer_size sockopts in the core") Suggested-by: Stefano Garzarella Signed-off-by: Norbert Szetei Reviewed-by: Stefano Garzarella Link: https://patch.msgid.link/180118C5-8BCF-4A63-A305-4EE53A34AB9C@doyensec.com Signed-off-by: Jakub Kicinski Cc: Luigi Leonardi Signed-off-by: Greg Kroah-Hartman commit 8be7860537978c62e0274b463cdca1882cee20fb Author: Sven Eckelmann Date: Fri May 15 13:44:28 2026 +0200 batman-adv: tp_meter: fix tp_num leak on kmalloc failure commit ce425dd05d0fe7594930a0fb103634f35ac47bb6 upstream. When batadv_tp_start() or batadv_tp_init_recv() fail to allocate a new tp_vars object, the previously incremented bat_priv->tp_num counter is never decremented. This causes tp_num to drift upward on each allocation failure. Since only BATADV_TP_MAX_NUM sessions can be started and the count is never reduced for these failed allocations, it causes to an exhaustion of throughput meter sessions. In worst case, no new throughput meter session can be started until the mesh interface is removed. The error handling must decrement tp_num releasing the lock and aborting the creation of an throughput meter session Cc: stable@kernel.org Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation") [ Context ] Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 5e9dfc07d061ee1fc232a692e385bca59300bedb Author: Masami Hiramatsu (Google) Date: Fri May 15 07:32:26 2026 -0400 tracing/fprobe: Remove fprobe from hash in failure path [ Upstream commit 845947aca6814f5723ed65e556eb5ee09493f05b ] When register_fprobe_ips() fails, it tries to remove a list of fprobe_hash_node from fprobe_ip_table, but it missed to remove fprobe itself from fprobe_table. Moreover, when removing the fprobe_hash_node which is added to rhltable once, it must use kfree_rcu() after removing from rhltable. To fix these issues, this reuses unregister_fprobe() internal code to rollback the half-way registered fprobe. Link: https://lore.kernel.org/all/177669366417.132053.17874946321744910456.stgit@mhiramat.tok.corp.google.com/ Fixes: 4346ba160409 ("fprobe: Rewrite fprobe on function-graph tracer") Cc: stable@vger.kernel.org Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a2181464a4a729fee1a9de4404991ef9bd811d72 Author: Masami Hiramatsu (Google) Date: Fri May 15 07:32:25 2026 -0400 tracing/fprobe: Unregister fprobe even if memory allocation fails [ Upstream commit 1aec9e5c3e31ce1e28f914427fb7f90b91d310df ] unregister_fprobe() can fail under memory pressure because of memory allocation failure, but this maybe called from module unloading, and usually there is no way to retry it. Moreover. trace_fprobe does not check the return value. To fix this problem, unregister fprobe and fprobe_hash_node even if working memory allocation fails. Anyway, if the last fprobe is removed, the filter will be freed. Link: https://lore.kernel.org/all/177669365629.132053.8433032896213721288.stgit@mhiramat.tok.corp.google.com/ Fixes: 4346ba160409 ("fprobe: Rewrite fprobe on function-graph tracer") Cc: stable@vger.kernel.org Signed-off-by: Masami Hiramatsu (Google) Stable-dep-of: 845947aca681 ("tracing/fprobe: Remove fprobe from hash in failure path") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d83e51202fec013e5ad7ff7898dc526f33e73507 Author: Menglong Dong Date: Fri May 15 07:32:24 2026 -0400 tracing: fprobe: optimization for entry only case [ Upstream commit 2c67dc457bc67367dc8fcd8f471ce2d5bb5f7b2b ] For now, fgraph is used for the fprobe, even if we need trace the entry only. However, the performance of ftrace is better than fgraph, and we can use ftrace_ops for this case. Then performance of kprobe-multi increases from 54M to 69M. Before this commit: $ ./benchs/run_bench_trigger.sh kprobe-multi kprobe-multi : 54.663 ± 0.493M/s After this commit: $ ./benchs/run_bench_trigger.sh kprobe-multi kprobe-multi : 69.447 ± 0.143M/s Mitigation is disable during the bench testing above. Link: https://lore.kernel.org/all/20251015083238.2374294-2-dongml2@chinatelecom.cn/ Signed-off-by: Menglong Dong Signed-off-by: Masami Hiramatsu (Google) Stable-dep-of: 845947aca681 ("tracing/fprobe: Remove fprobe from hash in failure path") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 52277410cbede5d439c167a84e9f301a2811b605 Author: Menglong Dong Date: Fri May 15 07:32:23 2026 -0400 tracing: fprobe: use rhltable for fprobe_ip_table [ Upstream commit 0de4c70d04a46a3c266547dd4275ce25f623796a ] For now, all the kernel functions who are hooked by the fprobe will be added to the hash table "fprobe_ip_table". The key of it is the function address, and the value of it is "struct fprobe_hlist_node". The budget of the hash table is FPROBE_IP_TABLE_SIZE, which is 256. And this means the overhead of the hash table lookup will grow linearly if the count of the functions in the fprobe more than 256. When we try to hook all the kernel functions, the overhead will be huge. Therefore, replace the hash table with rhltable to reduce the overhead. Link: https://lore.kernel.org/all/20250819031825.55653-1-dongml2@chinatelecom.cn/ Signed-off-by: Menglong Dong Signed-off-by: Masami Hiramatsu (Google) Stable-dep-of: 845947aca681 ("tracing/fprobe: Remove fprobe from hash in failure path") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5d12e0ab009ade48c1bff9324fd9bea2c773d088 Author: Yochai Eisenrich Date: Fri May 15 07:45:37 2026 -0400 btrfs: fix btrfs_ioctl_space_info() slot_count TOCTOU which can lead to info-leak [ Upstream commit 973e57c726c1f8e77259d1c8e519519f1e9aea77 ] btrfs_ioctl_space_info() has a TOCTOU race between two passes over the block group RAID type lists. The first pass counts entries to determine the allocation size, then the second pass fills the buffer. The groups_sem rwlock is released between passes, allowing concurrent block group removal to reduce the entry count. When the second pass fills fewer entries than the first pass counted, copy_to_user() copies the full alloc_size bytes including trailing uninitialized kmalloc bytes to userspace. Fix by copying only total_spaces entries (the actually-filled count from the second pass) instead of alloc_size bytes, and switch to kzalloc so any future copy size mismatch cannot leak heap data. Fixes: 7fde62bffb57 ("Btrfs: buffer results in the space_info ioctl") CC: stable@vger.kernel.org # 3.0 Signed-off-by: Yochai Eisenrich Reviewed-by: David Sterba Signed-off-by: David Sterba [ adapted upstream's `return -EFAULT;` to stable's `ret = -EFAULT;` fall-through to existing `out:` cleanup label ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dfd05a16b5c9d1d98b47905f37f2fccda52173d1 Author: Guangshuo Li Date: Fri May 15 08:06:15 2026 -0400 btrfs: fix double free in create_space_info_sub_group() error path [ Upstream commit a7449edf96143f192606ec8647e3167e1ecbd728 ] When kobject_init_and_add() fails, the call chain is: create_space_info_sub_group() -> btrfs_sysfs_add_space_info_type() -> kobject_init_and_add() -> failure -> kobject_put(&sub_group->kobj) -> space_info_release() -> kfree(sub_group) Then control returns to create_space_info_sub_group(), where: btrfs_sysfs_add_space_info_type() returns error -> kfree(sub_group) Thus, sub_group is freed twice. Keep parent->sub_group[index] = NULL for the failure path, but after btrfs_sysfs_add_space_info_type() has called kobject_put(), let the kobject release callback handle the cleanup. Fixes: f92ee31e031c ("btrfs: introduce btrfs_space_info sub-group") CC: stable@vger.kernel.org # 6.18+ Reviewed-by: Qu Wenruo Signed-off-by: Guangshuo Li Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a4b5c5d2f8c53135c1baaa52d75be83e07823c64 Author: Filipe Manana Date: Fri May 15 08:06:14 2026 -0400 btrfs: remove fs_info argument from btrfs_sysfs_add_space_info_type() [ Upstream commit 771af6ff72e0ed0eb8bf97e5ae4fa5094e0c5d1d ] We don't need it since we can grab fs_info from the given space_info. So remove the fs_info argument. Reviewed-by: Johannes Thumshirn Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Stable-dep-of: a7449edf9614 ("btrfs: fix double free in create_space_info_sub_group() error path") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d784865ce48f3ccb7b9d933b7dabae1396050cbd Author: Selvarasu Ganesan Date: Wed May 13 07:27:44 2026 -0400 usb: dwc3: Move GUID programming after PHY initialization [ Upstream commit aad35f9c926ec220b0742af1ada45666ae667956 ] The Linux Version Code is currently written to the GUID register before PHY initialization. Certain PHY implementations (such as Synopsys eUSB PHY performing link_sw_reset) clear the GUID register to its default value during initialization, causing the kernel version information to be lost. Move the GUID register programming to occur after PHY initialization completes to ensure the Linux version information persists. Fixes: fa0ea13e9f1c ("usb: dwc3: core: write LINUX_VERSION_CODE to our GUID register") Cc: stable Reported-by: Pritam Manohar Sutar Signed-off-by: Selvarasu Ganesan Acked-by: Thinh Nguyen Link: https://patch.msgid.link/20260417063314.2359-1-selvarasu.g@samsung.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 476ee6389120e1900290b46081b3a12b54e05672 Author: Prashanth K Date: Wed May 13 07:27:43 2026 -0400 usb: dwc3: Add dwc pointer to dwc3_readl/writel [ Upstream commit 9accc68b1cf0a2b220f51d53641128bb32598070 ] Use dwc pointer in dwc3_readl() dwc3_writel() instead of passing the dwc->regs. This would help us access the dwc structure and log the base address in traces. There's no functional changes in this patch, just refactoring existing APIs. Signed-off-by: Prashanth K Acked-by: Thinh Nguyen Link: https://patch.msgid.link/20260114100748.2950103-3-prashanth.k@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: aad35f9c926e ("usb: dwc3: Move GUID programming after PHY initialization") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e63942da5e962968404419deec6564a397d19e68 Author: Prashanth K Date: Wed May 13 07:27:42 2026 -0400 usb: dwc3: Remove of dep->regs [ Upstream commit abdd1eef04f0cb3b1707cd1fa243d574d5e07024 ] Remove dep->regs from struct dwc3_ep and reuse dwc->regs instead. Thus eliminating redundant iomem addresses and making register access more consistent across the driver. Signed-off-by: Prashanth K Acked-by: Thinh Nguyen Link: https://patch.msgid.link/20260114100748.2950103-2-prashanth.k@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: aad35f9c926e ("usb: dwc3: Move GUID programming after PHY initialization") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ce9aaa3af445c391735c9d000c4db60dfd5640d4 Author: Tejun Heo Date: Wed May 13 12:33:22 2026 -0400 sched_ext: Read scx_root under scx_cgroup_ops_rwsem in cgroup setters [ Upstream commit 80afd4c84bc8f5e80145ce35279f5ce53f6043db ] scx_group_set_{weight,idle,bandwidth}() cache scx_root before acquiring scx_cgroup_ops_rwsem, so the pointer can be stale by the time the op runs. If the loaded scheduler is disabled and freed (via RCU work) and another is enabled between the naked load and the rwsem acquire, the reader sees scx_cgroup_enabled=true (the new scheduler's) but dereferences the freed one - UAF on SCX_HAS_OP(sch, ...) / SCX_CALL_OP(sch, ...). scx_cgroup_enabled is toggled only under scx_cgroup_ops_rwsem write (scx_cgroup_{init,exit}), so reading scx_root inside the rwsem read section correlates @sch with the enabled snapshot. Fixes: a5bd6ba30b33 ("sched_ext: Use cgroup_lock/unlock() to synchronize against cgroup operations") Cc: stable@vger.kernel.org # v6.18+ Reported-by: Chris Mason Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 30cf8e05d635680eec2eed696b9118cada1c2aa9 Author: zhidao su Date: Wed May 13 12:33:21 2026 -0400 sched/ext: Implement cgroup_set_idle() callback [ Upstream commit 347ed2d566dabb06c7970fff01129c4f59995ed6 ] Implement the missing cgroup_set_idle() callback that was marked as a TODO. This allows BPF schedulers to be notified when a cgroup's idle state changes, enabling them to adjust their scheduling behavior accordingly. The implementation follows the same pattern as other cgroup callbacks like cgroup_set_weight() and cgroup_set_bandwidth(). It checks if the BPF scheduler has implemented the callback and invokes it with the appropriate parameters. Fixes a spelling error in the cgroup_set_bandwidth() documentation. tj: s/scx_cgroup_rwsem/scx_cgroup_ops_rwsem/ to fix build breakage. Signed-off-by: zhidao su Signed-off-by: Tejun Heo Stable-dep-of: 80afd4c84bc8 ("sched_ext: Read scx_root under scx_cgroup_ops_rwsem in cgroup setters") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dc34f8d8240f25dd137dc2758ebbcc75e3779142 Author: David Carlier Date: Wed May 13 13:10:03 2026 -0400 Bluetooth: hci_conn: fix potential UAF in create_big_sync [ Upstream commit 0beddb0c380bed5f5b8e61ddbe14635bb73d0b41 ] Add hci_conn_valid() check in create_big_sync() to detect stale connections before proceeding with BIG creation. Handle the resulting -ECANCELED in create_big_complete() and re-validate the connection under hci_dev_lock() before dereferencing, matching the pattern used by create_le_conn_complete() and create_pa_complete(). Keep the hci_conn object alive across the async boundary by taking a reference via hci_conn_get() when queueing create_big_sync(), and dropping it in the completion callback. The refcount and the lock are complementary: the refcount keeps the object allocated, while hci_dev_lock() serializes hci_conn_hash_del()'s list_del_rcu() on hdev->conn_hash, as required by hci_conn_del(). hci_conn_put() is called outside hci_dev_unlock() so the final put (which resolves to kfree() via bt_link_release) does not run under hdev->lock, though the release path would be safe either way. Without this, create_big_complete() would unconditionally dereference the conn pointer on error, causing a use-after-free via hci_connect_cfm() and hci_conn_del(). Fixes: eca0ae4aea66 ("Bluetooth: Add initial implementation of BIS connections") Cc: stable@vger.kernel.org Co-developed-by: Luiz Augusto von Dentz Signed-off-by: Luiz Augusto von Dentz Signed-off-by: David Carlier Signed-off-by: Luiz Augusto von Dentz [ kept stable's `qos->bcast.out.phy == 0x02` context line instead of upstream's renamed `qos->bcast.out.phys == BIT(1)` ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c0a8dca8d556b55303d6cc2716f60cdebe503567 Author: Johan Hovold Date: Wed May 13 14:08:36 2026 -0400 spi: zynq-qspi: fix controller deregistration [ Upstream commit c9c012706c9fa8ca6d129a9161caf92ab625a3fd ] Make sure to deregister the controller before disabling it during driver unbind. Note that clocks were also disabled before the recent commit 1f8fd9490e31 ("spi: zynq-qspi: Simplify clock handling with devm_clk_get_enabled()"). Fixes: 67dca5e580f1 ("spi: spi-mem: Add support for Zynq QSPI controller") Cc: stable@vger.kernel.org # 5.2: 8eb2fd00f65a Cc: stable@vger.kernel.org # 5.2 Cc: Naga Sureshkumar Relli Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-27-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ed822a5696455312f7c760f1d2c333ce892e0af0 Author: Pei Xiao Date: Wed May 13 14:08:35 2026 -0400 spi: zynq-qspi: Simplify clock handling with devm_clk_get_enabled() [ Upstream commit 1f8fd9490e3184e9a2394df2e682901a1d57ce71 ] Replace devm_clk_get() followed by clk_prepare_enable() with devm_clk_get_enabled() for both "pclk" and "ref_clk". This removes the need for explicit clock enable and disable calls, as the managed API automatically disables the clocks on device removal or probe failure. Remove the now-unnecessary clk_disable_unprepare() calls from the probe error paths and the remove callback. Simplify error handling by jumping directly to the remove_ctlr label. Signed-off-by: Pei Xiao Acked-by: Michal Simek Link: https://patch.msgid.link/24043625f89376da36feca2408f990a85be7ab36.1775555500.git.xiaopei01@kylinos.cn Signed-off-by: Mark Brown Stable-dep-of: c9c012706c9f ("spi: zynq-qspi: fix controller deregistration") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 33e5ce64b8170c6b8a64d6eb5853aa655357c417 Author: Johan Hovold Date: Wed May 13 23:10:37 2026 -0400 spi: tegra114: fix controller deregistration [ Upstream commit 9c9c27ff2058142d8f800de3186d6864184958de ] Make sure to deregister the controller before disabling underlying resources like clocks during driver unbind. Fixes: 5c8096439600 ("spi: tegra114: use devm_spi_register_master()") Cc: stable@vger.kernel.org # 3.13 Cc: Jingoo Han Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-22-johan@kernel.org Signed-off-by: Mark Brown [ kept `host->dev.of_node = pdev->dev.of_node;` context line above the `spi_register_controller()` conversion ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 65eafad7a6005bc221fc24610e5810f7cceea53b Author: Johan Hovold Date: Thu May 14 00:14:46 2026 -0400 spi: tegra20-sflash: fix controller deregistration [ Upstream commit ad7310e983327f939dd6c4e801eab13238992572 ] Make sure to deregister the controller before disabling underlying resources like clocks during driver unbind. Fixes: f12f7318c44a ("spi: tegra20-sflash: use devm_spi_register_master()") Cc: stable@vger.kernel.org # 3.13 Cc: Jingoo Han Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-23-johan@kernel.org Signed-off-by: Mark Brown [ kept the redundant `host->dev.of_node = pdev->dev.of_node;` line above the registration call ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fafa9a4e831b74f533b402409ff3c2b15f11c122 Author: Johan Hovold Date: Thu May 14 00:58:33 2026 -0400 spi: uniphier: fix controller deregistration [ Upstream commit 0245435f777264ac45945ed2f325dd095a41d1af ] Make sure to deregister the controller before releasing underlying resources like DMA during driver unbind. Note that clocks were also disabled before the recent commit fdca270f8f87 ("spi: uniphier: Simplify clock handling with devm_clk_get_enabled()"). Fixes: 5ba155a4d4cc ("spi: add SPI controller driver for UniPhier SoC") Cc: stable@vger.kernel.org # 4.19 Cc: Keiji Hayashibara Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-25-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b0a97cb0b9ba51415d44062977f8e44eef56c161 Author: Pei Xiao Date: Thu May 14 00:58:32 2026 -0400 spi: uniphier: Simplify clock handling with devm_clk_get_enabled() [ Upstream commit fdca270f8f87cae2eb5b619234b9dd11a863ce6b ] Replace devm_clk_get() followed by clk_prepare_enable() with devm_clk_get_enabled() for the clock. This removes the need for explicit clock enable and disable calls, as the managed API automatically handles clock disabling on device removal or probe failure. Remove the now-unnecessary clk_disable_unprepare() calls from the probe error path and the remove callback. Adjust error labels accordingly. Signed-off-by: Pei Xiao Reviewed-by: Kunihiko Hayashi Link: https://patch.msgid.link/b2deeefd4ef1a4bce71116aabfcb7e81400f6d37.1775546948.git.xiaopei01@kylinos.cn Signed-off-by: Mark Brown Stable-dep-of: 0245435f7772 ("spi: uniphier: fix controller deregistration") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6542e180fa6e1c701aba446a555c65556e6fd1a5 Author: Ritesh Harjani (IBM) Date: Thu May 14 11:08:20 2026 -0400 pseries/papr-hvpipe: Fix race with interrupt handler [ Upstream commit 7a4f0846ee6cc8cf44ae0046ed42e3259d1dd45b ] While executing ->ioctl handler or ->release handler, if an interrupt fires on the same cpu, then we can enter into a deadlock. This patch fixes both these handlers to take spin_lock_irq{save|restore} versions of the lock to prevent this deadlock. Cc: stable@vger.kernel.org Fixes: 814ef095f12c9 ("powerpc/pseries: Add papr-hvpipe char driver for HVPIPE interfaces") Signed-off-by: Ritesh Harjani (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/e4ed435c44fc191f2eb23c7907ba6f72f193e6aa.1777606826.git.ritesh.list@gmail.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 09c15bbbed533903e600660ea09098b3b0524f48 Author: Christian Brauner Date: Thu May 14 11:08:19 2026 -0400 papr-hvpipe: convert papr_hvpipe_dev_create_handle() to FD_PREPARE() [ Upstream commit 6d3789d347a7af5c4b0b2da3af47b8d9da607ab2 ] Fixes a UAF for src_info as well. Link: https://patch.msgid.link/20251123-work-fd-prepare-v4-33-b6efa1706cfd@kernel.org Signed-off-by: Christian Brauner Stable-dep-of: 7a4f0846ee6c ("pseries/papr-hvpipe: Fix race with interrupt handler") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 24d2912962d087ebff7c4984f8ac34a5f23c8dbf Author: Prasanna Kumar T S M Date: Thu May 14 11:52:31 2026 -0400 EDAC/versalnet: Fix device name memory leak [ Upstream commit 8cf5dd235eff6008cb04c3d8064d2acfa90616f1 ] The device name allocated via kzalloc() in init_one_mc() is assigned to dev->init_name but never freed on the normal removal path. device_register() copies init_name and then sets dev->init_name to NULL, so the name pointer becomes unreachable from the device. Thus leaking memory. Use a stack-local char array instead of using kzalloc() for name. Fixes: d5fe2fec6c40 ("EDAC: Add a driver for the AMD Versal NET DDR controller") Signed-off-by: Prasanna Kumar T S M Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260401111856.2342975-1-ptsm@linux.microsoft.com [ adapted fix from `init_one_mc()` helper to the equivalent loop in `init_versalnet()` using literal `32` instead of `MC_NAME_LEN` ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d281f3ac0d00d7ae9d409537b1a28f6957701e72 Author: Damien Le Moal Date: Thu May 14 11:52:20 2026 -0400 block: fix zone write plug removal [ Upstream commit b7d4ffb510373cc6ecf16022dd0e510a023034fb ] Commit 7b295187287e ("block: Do not remove zone write plugs still in use") modified disk_should_remove_zone_wplug() to add a check on the reference count of a zone write plug to prevent removing zone write plugs from a disk hash table when the plugs are still being referenced by BIOs or requests in-flight. However, this check does not take into account that a BIO completion may happen right after its submission by a zone write plug BIO work, and before the zone write plug BIO work releases the zone write plug reference count. This situation leads to disk_should_remove_zone_wplug() returning false as in this case the zone write plug reference count is at least equal to 3. If the BIO that completes in such manner transitioned the zone to the FULL condition, the zone write plug for the FULL zone will remain in the disk hash table. Furthermore, relying on a particular value of a zone write plug reference count to set the BLK_ZONE_WPLUG_UNHASHED flag is fragile as reading the atomic reference count and doing a comparison with some value is not overall atomic at all. Address these issues by reworking the reference counting of zone write plugs so that removing plugs from a disk hash table can be done directly from disk_put_zone_wplug() when the last reference on a plug is dropped. To do so, replace the function disk_remove_zone_wplug() with disk_mark_zone_wplug_dead(). This new function sets the zone write plug flag BLK_ZONE_WPLUG_DEAD (which replaces BLK_ZONE_WPLUG_UNHASHED) and drops the initial reference on the zone write plug taken when the plug was added to the disk hash table. This function is called either for zones that are empty or full, or directly in the case of a forced plug removal (e.g. when the disk hash table is being destroyed on disk removal). With this change, disk_should_remove_zone_wplug() is also removed. disk_put_zone_wplug() is modified to call the function disk_free_zone_wplug() to remove a zone write plug from a disk hash table and free the plug structure (with a call_rcu()), when the last reference on a zone write plug is dropped. disk_free_zone_wplug() always checks that the BLK_ZONE_WPLUG_DEAD flag is set. In order to avoid having multiple zone write plugs for the same zone in the disk hash table, disk_get_and_lock_zone_wplug() checked for the BLK_ZONE_WPLUG_UNHASHED flag. This check is removed and a check for the new BLK_ZONE_WPLUG_DEAD flag is added to blk_zone_wplug_handle_write(). With this change, we continue preventing adding multiple zone write plugs for the same zone and at the same time re-inforce checks on the user behavior by failing new incoming write BIOs targeting a zone that is marked as dead. This case can happen only if the user erroneously issues write BIOs to zones that are full, or to zones that are currently being reset or finished. Fixes: 7b295187287e ("block: Do not remove zone write plugs still in use") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Reviewed-by: Christoph Hellwig Reviewed-by: Johannes Thumshirn Signed-off-by: Jens Axboe [ dropped upstream blk_zone_set_cond() call and disk_zone_wplug_update_cond() context line ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7105d9f1387d63b15c9a860674fc92c959181f2f Author: Thomas Zimmermann Date: Thu May 14 13:58:45 2026 -0400 fbcon: Avoid OOB font access if console rotation fails [ Upstream commit e4ef723d8975a2694cc90733a6b888a5e2841842 ] Clear the font buffer if the reallocation during console rotation fails in fbcon_rotate_font(). The putcs implementations for the rotated buffer will return early in this case. See [1] for an example. Currently, fbcon_rotate_font() keeps the old buffer, which is too small for the rotated font. Printing to the rotated console with a high-enough character code will overflow the font buffer. v2: - fix typos in commit message Signed-off-by: Thomas Zimmermann Fixes: 6cc50e1c5b57 ("[PATCH] fbcon: Console Rotation - Add support to rotate font bitmap") Cc: stable@vger.kernel.org # v2.6.15+ Link: https://elixir.bootlin.com/linux/v6.19/source/drivers/video/fbdev/core/fbcon_ccw.c#L144 # [1] Signed-off-by: Helge Deller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1817dd0c350f5918e4c66a0eb5bf6426e619b065 Author: Thomas Zimmermann Date: Thu May 14 13:58:44 2026 -0400 fbcon: Rename struct fbcon_ops to struct fbcon_par [ Upstream commit a6adbbc4c32a016146e117b1e9e5242724a75e10 ] The type struct fbcon_ops contains fbcon state and callbacks. As the callbacks will be removed from struct fbcon_ops, rename the data type to struct fbcon_par. Also rename the variables from ops to par. The _par postfix ("private access registers") is used throughout the fbdev subsystem for per-driver state. The fbcon pointer within struct fb_info is also named fbcon_par. Hence, the new naming fits existing practice. v2: - rename struct fbcon_ops to struct fbcon_par - fix build for CONFIG_FB_TILEBITTING=n (kernel test robot) - fix indention Signed-off-by: Thomas Zimmermann Reviewed-by: Sam Ravnborg Link: https://lore.kernel.org/r/20250909124616.143365-3-tzimmermann@suse.de Stable-dep-of: e4ef723d8975 ("fbcon: Avoid OOB font access if console rotation fails") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f0d3bb6f5125c69ce872a7574afd6d9e1f7ea349 Author: Alex Deucher Date: Mon Mar 16 11:04:46 2026 -0400 drm/amdgpu: rework how we handle TLB fences commit 69c5fbd2b93b5ced77c6e79afe83371bca84c788 upstream. Add a new VM flag to indicate whether or not we need a TLB fence. Userqs (KFD or KGD) require a TLB fence. A TLB fence is not strictly required for kernel queues, but it shouldn't hurt. That said, enabling this unconditionally should be fine, but it seems to tickle some issues in KIQ/MES. Only enable them for KFD, or when KGD userq queues are enabled (currently via module parameter). Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4798 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4749 Fixes: f3854e04b708 ("drm/amdgpu: attach tlb fence to the PTs update") Cc: Christian König Cc: Prike Liang Reviewed-by: Prike Liang Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 13e9ea445191390269a6f092d009b68e086e601b Author: Prike Liang Date: Fri Jan 9 16:15:11 2026 +0800 Revert "drm/amdgpu: don't attach the tlb fence for SI" commit 9163fe4d790fb4e16d6b0e23f55b43cddd3d4a65 upstream. This reverts commit 820b3d376e8a102c6aeab737ec6edebbbb710e04. It’s better to validate VM TLB flushes in the flush‑TLB backend rather than in the generic VM layer. Reverting this patch depends on commit fa7c231fc2b0 ("drm/amdgpu: validate the flush_gpu_tlb_pasid()") being present in the tree. Signed-off-by: Prike Liang Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 576b73b246564c8fa75572d45c1ed9b053b4be5b Author: Timur Kristóf Date: Sun Jan 18 13:57:46 2026 +0100 drm/amdgpu: Fix validating flush_gpu_tlb_pasid() commit e3a6eff92bbd960b471966d9afccb4d584546d17 upstream. When a function holds a lock and we return without unlocking it, it deadlocks the kernel. We should always unlock before returning. This commit fixes suspend/resume on SI. Tested on two Tahiti GPUs: FirePro W9000 and R9 280X. Fixes: f4db9913e4d3 ("drm/amdgpu: validate the flush_gpu_tlb_pasid()") Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202601190121.z9C0uml5-lkp@intel.com/ Signed-off-by: Timur Kristóf Signed-off-by: Prike Liang Reviewed-by: Prike Liang Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit fd78e63459ab6fe99b9fd026c420808d09eaa8be Author: Prike Liang Date: Tue Jan 6 17:00:57 2026 +0800 drm/amdgpu: validate the flush_gpu_tlb_pasid() commit f4db9913e4d3dabe9ff3ea6178f2c1bc286012b8 upstream. Validate flush_gpu_tlb_pasid() availability before flushing tlb. Signed-off-by: Prike Liang Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit a9591e4083cc703fb3fe272b0cdcbe0a213538df Author: SeongJae Park Date: Mon Apr 6 17:31:52 2026 -0700 mm/damon/core: disallow time-quota setting zero esz commit 8bbde987c2b84f80da0853f739f0a920386f8b99 upstream. When the throughput of a DAMOS scheme is very slow, DAMOS time quota can make the effective size quota smaller than damon_ctx->min_region_sz. In the case, damos_apply_scheme() will skip applying the action, because the action is tried at region level, which requires >=min_region_sz size. That is, the quota is effectively exceeded for the quota charge window. Because no action will be applied, the total_charged_sz and total_charged_ns are also not updated. damos_set_effective_quota() will try to update the effective size quota before starting the next charge window. However, because the total_charged_sz and total_charged_ns have not updated, the throughput and effective size quota are also not changed. Since effective size quota can only be decreased, other effective size quota update factors including DAMOS quota goals and size quota cannot make any change, either. As a result, the scheme is unexpectedly deactivated until the user notices and mitigates the situation. The users can mitigate this situation by changing the time quota online or re-install the scheme. While the mitigation is somewhat straightforward, finding the situation would be challenging, because DAMON is not providing good observabilities for that. Even if such observability is provided, doing the additional monitoring and the mitigation is somewhat cumbersome and not aligned to the intention of the time quota. The time quota was intended to help reduce the user's administration overhead. Fix the problem by setting time quota-modified effective size quota be at least min_region_sz always. The issue was discovered [1] by sashiko. Link: https://lore.kernel.org/20260407003153.79589-1-sj@kernel.org Link: https://lore.kernel.org/20260405192504.110014-1-sj@kernel.org [1] Fixes: 1cd243030059 ("mm/damon/schemes: implement time quota") Signed-off-by: SeongJae Park Cc: # 5.16.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 377c3d5dc952d24084721298f849801119cd60ef Author: Amit Sunil Dhamne Date: Tue Apr 14 00:58:32 2026 +0000 usb: typec: tcpm: reset internal port states on soft reset AMS commit 2909f0d4994fb4306bf116df5ccee797791fce2c upstream. Reset internal port states (such as vdm_sm_running and explicit_contract) on soft reset AMS as the port needs to negotiate a new contract. The consequence of leaving the states in as-is cond are as follows: * port is in SRC power role and an explicit contract is negotiated with the port partner (in sink role) * port partner sends a Soft Reset AMS while VDM State Machine is running * port accepts the Soft Reset request and the port advertises src caps * port partner sends a Request message but since the explicit_contract and vdm_sm_running are true from previous negotiation, the port ends up sending Soft Reset instead of Accept msg. Stub Log: [ 203.653942] AMS DISCOVER_IDENTITY start [ 203.653947] PD TX, header: 0x176f [ 203.655901] PD TX complete, status: 0 [ 203.657470] PD RX, header: 0x124f [1] [ 203.657477] Rx VDM cmd 0xff008081 type 2 cmd 1 len 1 [ 203.657482] AMS DISCOVER_IDENTITY finished [ 203.657484] cc:=4 [ 204.155698] PD RX, header: 0x144f [1] [ 204.155718] Rx VDM cmd 0xeeee8001 type 0 cmd 1 len 1 [ 204.155741] PD TX, header: 0x196f [ 204.157622] PD TX complete, status: 0 [ 204.160060] PD RX, header: 0x4d [1] [ 204.160066] state change SRC_READY -> SOFT_RESET [rev2 SOFT_RESET_AMS] [ 204.160076] PD TX, header: 0x163 [ 204.162486] PD TX complete, status: 0 [ 204.162832] AMS SOFT_RESET_AMS finished [ 204.162840] cc:=4 [ 204.162891] AMS POWER_NEGOTIATION start [ 204.162896] state change SOFT_RESET -> AMS_START [rev2 POWER_NEGOTIATION] [ 204.162908] state change AMS_START -> SRC_SEND_CAPABILITIES [rev2 POWER_NEGOTIATION] [ 204.162913] PD TX, header: 0x1361 [ 204.165529] PD TX complete, status: 0 [ 204.165571] pending state change SRC_SEND_CAPABILITIES -> SRC_SEND_CAPABILITIES_TIMEOUT @ 60 ms [rev2 POWER_NEGOTIATION] [ 204.166996] PD RX, header: 0x1242 [1] [ 204.167009] state change SRC_SEND_CAPABILITIES -> SRC_SOFT_RESET_WAIT_SNK_TX [rev2 POWER_NEGOTIATION] [ 204.167019] AMS POWER_NEGOTIATION finished [ 204.167020] cc:=4 [ 204.167083] AMS SOFT_RESET_AMS start [ 204.167086] state change SRC_SOFT_RESET_WAIT_SNK_TX -> SOFT_RESET_SEND [rev2 SOFT_RESET_AMS] [ 204.167092] PD TX, header: 0x16d [ 204.168824] PD TX complete, status: 0 [ 204.168854] pending state change SOFT_RESET_SEND -> HARD_RESET_SEND @ 60 ms [rev2 SOFT_RESET_AMS] [ 204.171876] PD RX, header: 0x43 [1] [ 204.171879] AMS SOFT_RESET_AMS finished This causes COMMON.PROC.PD.11.2 check failure for TEST.PD.VDM.SRC.2_Rev2Src test on the PD compliance tester. Signed-off-by: Amit Sunil Dhamne Fixes: 8d3a0578ad1a ("usb: typec: tcpm: Respond Wait if VDM state machine is running") Fixes: f0690a25a140 ("staging: typec: USB Type-C Port Manager (tcpm)") Cc: stable Reviewed-by: Badhri Jagan Sridharan Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260414-fix-soft-reset-v1-1-01d7cb9764e2@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit d893804e9e3bd29e14d52813a8648a552417f826 Author: SeongJae Park Date: Sun Apr 19 09:10:00 2026 -0700 mm/damon/reclaim: detect and use fresh enabled and kdamond_pid values commit 64a140afa5ed1c6f5ba6d451512cbdbbab1ba339 upstream. Patch series "mm/damon/modules: detect and use fresh status", v3. DAMON modules including DAMON_RECLAIM, DAMON_LRU_SORT and DAMON_STAT commonly expose the kdamond running status via their parameters. Under certain scenarios including wrong user inputs and memory allocation failures, those parameter values can be stale. It can confuse users. For DAMON_RECLAIM and DAMON_LRU_SORT, it even makes the kdamond unable to be restarted before the system reboot. The problem comes from the fact that there are multiple events for the status changes and it is difficult to follow up all the scenarios. Fix the issue by detecting and using the status on demand, instead of using a cached status that is difficult to be updated. Patches 1-3 fix the bugs in DAMON_RECLAIM, DAMON_LRU_SORT and DAMON_STAT in the order. This patch (of 3): DAMON_RECLAIM updates 'enabled' and 'kdamond_pid' parameter values, which represents the running status of its kdamond, when the user explicitly requests start/stop of the kdamond. The kdamond can, however, be stopped in events other than the explicit user request in the following three events. 1. ctx->regions_score_histogram allocation failure at beginning of the execution, 2. damon_commit_ctx() failure due to invalid user input, and 3. damon_commit_ctx() failure due to its internal allocation failures. Hence, if the kdamond is stopped by the above three events, the values of the status parameters can be stale. Users could show the stale values and be confused. This is already bad, but the real consequence is worse. DAMON_RECLAIM avoids unnecessary damon_start() and damon_stop() calls based on the 'enabled' parameter value. And the update of 'enabled' parameter value depends on the damon_start() and damon_stop() call results. Hence, once the kdamond has stopped by the unintentional events, the user cannot restart the kdamond before the system reboot. For example, the issue can be reproduced via below steps. # cd /sys/module/damon_reclaim/parameters # # # start DAMON_RECLAIM # echo Y > enabled # ps -ef | grep kdamond root 806 2 0 17:53 ? 00:00:00 [kdamond.0] root 808 803 0 17:53 pts/4 00:00:00 grep kdamond # # # commit wrong input to stop kdamond withou explicit stop request # echo 3 > addr_unit # echo Y > commit_inputs bash: echo: write error: Invalid argument # # # confirm kdamond is stopped # ps -ef | grep kdamond root 811 803 0 17:53 pts/4 00:00:00 grep kdamond # # # users casn now show stable status # cat enabled Y # cat kdamond_pid 806 # # # even after fixing the wrong parameter, # # kdamond cannot be restarted. # echo 1 > addr_unit # echo Y > enabled # ps -ef | grep kdamond root 815 803 0 17:54 pts/4 00:00:00 grep kdamond The problem will only rarely happen in real and common setups for the following reasons. The allocation failures are unlikely in such setups since those allocations are arguably too small to fail. Also sane users on real production environments may not commit wrong input parameters. But once it happens, the consequence is quite bad. And the bug is a bug. The issue stems from the fact that there are multiple events that can change the status, and following all the events is challenging. Dynamically detect and use the fresh status for the parameters when those are requested. Link: https://lore.kernel.org/20260419161003.79176-1-sj@kernel.org Link: https://lore.kernel.org/20260419161003.79176-2-sj@kernel.org Fixes: e035c280f6df ("mm/damon/reclaim: support online inputs update") Co-developed-by: Liew Rui Yan Signed-off-by: Liew Rui Yan Signed-off-by: SeongJae Park Cc: # 5.19.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 4697ed7be9b991c9790fa322b3e7302491704668 Author: SeongJae Park Date: Sun Apr 19 09:10:01 2026 -0700 mm/damon/lru_sort: detect and use fresh enabled and kdamond_pid values commit b98b7ff6025ae82570d4915e083f0cbd8d48b3cf upstream. DAMON_LRU_SORT updates 'enabled' and 'kdamond_pid' parameter values, which represents the running status of its kdamond, when the user explicitly requests start/stop of the kdamond. The kdamond can, however, be stopped in events other than the explicit user request in the following three events. 1. ctx->regions_score_histogram allocation failure at beginning of the execution, 2. damon_commit_ctx() failure due to invalid user input, and 3. damon_commit_ctx() failure due to its internal allocation failures. Hence, if the kdamond is stopped by the above three events, the values of the status parameters can be stale. Users could show the stale values and be confused. This is already bad, but the real consequence is worse. DAMON_LRU_SORT avoids unnecessary damon_start() and damon_stop() calls based on the 'enabled' parameter value. And the update of 'enabled' parameter value depends on the damon_start() and damon_stop() call results. Hence, once the kdamond has stopped by the unintentional events, the user cannot restart the kdamond before the system reboot. For example, the issue can be reproduced via below steps. # cd /sys/module/damon_lru_sort/parameters # # # start DAMON_LRU_SORT # echo Y > enabled # ps -ef | grep kdamond root 806 2 0 17:53 ? 00:00:00 [kdamond.0] root 808 803 0 17:53 pts/4 00:00:00 grep kdamond # # # commit wrong input to stop kdamond withou explicit stop request # echo 3 > addr_unit # echo Y > commit_inputs bash: echo: write error: Invalid argument # # # confirm kdamond is stopped # ps -ef | grep kdamond root 811 803 0 17:53 pts/4 00:00:00 grep kdamond # # # users casn now show stable status # cat enabled Y # cat kdamond_pid 806 # # # even after fixing the wrong parameter, # # kdamond cannot be restarted. # echo 1 > addr_unit # echo Y > enabled # ps -ef | grep kdamond root 815 803 0 17:54 pts/4 00:00:00 grep kdamond The problem will only rarely happen in real and common setups for the following reasons. The allocation failures are unlikely in such setups since those allocations are arguably too small to fail. Also sane users on real production environments may not commit wrong input parameters. But once it happens, the consequence is quite bad. And the bug is a bug. The issue stems from the fact that there are multiple events that can change the status, and following all the events is challenging. Dynamically detect and use the fresh status for the parameters when those are requested. Link: https://lore.kernel.org/20260419161003.79176-3-sj@kernel.org Fixes: 40e983cca927 ("mm/damon: introduce DAMON-based LRU-lists Sorting") Co-developed-by: Liew Rui Yan Signed-off-by: Liew Rui Yan Signed-off-by: SeongJae Park Cc: # 6.0.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 679e65ae721c9d2e2c3a52d4a3bad239f75adbe4 Author: SeongJae Park Date: Thu Jan 15 07:20:41 2026 -0800 mm/damon/core: implement damon_kdamond_pid() commit 4262c53236977de3ceaa3bf2aefdf772c9b874dd upstream. Patch series "mm/damon: hide kdamond and kdamond_lock from API callers". 'kdamond' and 'kdamond_lock' fields initially exposed to DAMON API callers for flexible synchronization and use cases. As DAMON API became somewhat complicated compared to the early days, Keeping those exposed could only encourage the API callers to invent more creative but complicated and difficult-to-debug use cases. Fortunately DAMON API callers didn't invent that many creative use cases. There exist only two use cases of 'kdamond' and 'kdamond_lock'. Finding whether the kdamond is actively running, and getting the pid of the kdamond. For the first use case, a dedicated API function, namely 'damon_is_running()' is provided, and all DAMON API callers are using the function for the use case. Hence only the second use case is where the fields are directly being used by DAMON API callers. To prevent future invention of complicated and erroneous use cases of the fields, hide the fields from the API callers. For that, provide new dedicated DAMON API functions for the remaining use case, namely damon_kdamond_pid(), migrate DAMON API callers to use the new function, and mark the fields as private fields. This patch (of 5): 'kdamond' and 'kdamond_lock' are directly being used by DAMON API callers for getting the pid of the corresponding kdamond. To discourage invention of creative but complicated and erroneous new usages of the fields that require careful synchronization, implement a new API function that can simply be used without the manual synchronizations. Link: https://lkml.kernel.org/r/20260115152047.68415-1-sj@kernel.org Link: https://lkml.kernel.org/r/20260115152047.68415-2-sj@kernel.org Signed-off-by: SeongJae Park Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 20048f0b38cd74a265588c6c4e93466279f88101 Author: Xianglai Li Date: Mon May 4 09:00:37 2026 +0800 LoongArch: KVM: Compile switch.S directly into the kernel commit 5203012fa6045aac4b69d4e7c212e16dcf38ef10 upstream. If we directly compile the switch.S file into the kernel, the address of the kvm_exc_entry function will definitely be within the DMW memory area. Therefore, we will no longer need to perform a copy relocation of the kvm_exc_entry. So this patch compiles switch.S directly into the kernel, and then remove the copy relocation execution logic for the kvm_exc_entry function. Cc: stable@vger.kernel.org Signed-off-by: Xianglai Li Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit f49a00180dfc05032e2786606095ba9215db1344 Author: Pavel Begunkov Date: Tue Apr 21 09:45:29 2026 +0100 io_uring/zcrx: warn on freelist violations commit 770594e78c3964cf23cf5287f849437cdde9b7d0 upstream. The freelist is appropriately sized to always be able to take a free niov, but let's be more defensive and check the invariant with a warning. That should help to catch any double-free issues. Suggested-by: Kai Aizen Signed-off-by: Pavel Begunkov Link: https://patch.msgid.link/2f3cea363b04649755e3b6bb9ab66485a95936d5.1776760901.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Harshit Mogalapalli Signed-off-by: Greg Kroah-Hartman commit 1a516d19100e2e987d75cd694161f40d3d60b911 Author: Pavel Begunkov Date: Mon Mar 23 12:43:57 2026 +0000 io_uring/zcrx: use guards for locking commit 898ad80d1207cbdb22b21bafb6de4adfd7627bd0 upstream. Convert last several places using manual locking to guards to simplify the code. Signed-off-by: Pavel Begunkov Link: https://patch.msgid.link/eb4667cfaf88c559700f6399da9e434889f5b04a.1774261953.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Harshit Mogalapalli Signed-off-by: Greg Kroah-Hartman commit 0baf4b659cdc7305cf685b5a5d60f9e3816ab5d0 Author: Sven Eckelmann Date: Wed May 6 22:20:52 2026 +0200 batman-adv: bla: put backbone reference on failed claim hash insert commit ba9d20ee9076dac32c371116bacbe72480eb356c upstream. When batadv_bla_add_claim() fails to insert a new claim into the hash, it leaked a reference to the backbone_gw for which the claim was intended. Call batadv_backbone_gw_put() on the error path to release the reference and avoid leaking the backbone_gw object. Cc: stable@kernel.org Fixes: 3db0decf1185 ("batman-adv: Fix non-atomic bla_claim::backbone_gw access") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit b65365d2b1e6095c538d49baeb140dd1c166c1b3 Author: Sven Eckelmann Date: Wed May 6 22:20:51 2026 +0200 batman-adv: bla: only purge non-released claims commit cf6b604011591865ae39ac82de8978c1120d17af upstream. When batadv_bla_purge_claims() goes through the list of claims, it is only traversing the hash list with an rcu_read_lock(). Due to a potential parallel batadv_claim_put(), it can happen that it encounters a claim which was actually in the process of being released+freed by batadv_claim_release(). In this case, backbone_gw is set to NULL before the delayed RCU kfree is started. Calling batadv_bla_claim_get_backbone_gw() is then no longer allowed because it would cause a NULL-ptr derefence. To avoid this, only claims with a valid reference counter must be purged. All others are already taken care of. Cc: stable@kernel.org Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 00155f336a5e8b1006d2ca9ae7ad8fc4a44bb401 Author: Sven Eckelmann Date: Wed May 6 22:20:50 2026 +0200 batman-adv: bla: prevent use-after-free when deleting claims commit 4ae1709a314060a196981b344610d023ea841e57 upstream. When batadv_bla_del_backbone_claims() removes all claims for a backbone, it does this by dropping the link entry in the hash list. This list entry itself was one of the references which need to be dropped at the same time via batadv_claim_put(). But the batadv_claim_put() must not be done before the last access to the claim object in this function. Otherwise the claim might be freed already by the batadv_claim_release() function before the list entry was dropped. Cc: stable@kernel.org Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code") Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 09dc0d1a12222ffca6481916eab3cfea477b9620 Author: Jiexun Wang Date: Sun May 3 12:28:58 2026 +0800 batman-adv: stop caching unowned originator pointers in BAT IV commit f03e8583532941b07761c5429de7d50766fa3110 upstream. BAT IV keeps the last-hop neighbor address in each neigh_node, but some paths also cache an originator pointer derived from a temporary lookup. That pointer is not owned by the neigh_node and may no longer refer to a live originator entry after purge handling runs. Stop storing the auxiliary originator pointer in the BAT IV neighbor state. When BAT IV needs the neighbor originator data, resolve it from the stored neighbor address and drop the reference again after use. Fixes: c6c8fea29769 ("net: Add batman-adv meshing protocol") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Jiexun Wang Signed-off-by: Ren Wei [sven: avoid bonding logic for outgoing OGM] Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit 03660dab86f93319178a24667f6998526dc4355d Author: Jiexun Wang Date: Mon Apr 27 14:43:34 2026 +0800 batman-adv: stop tp_meter sessions during mesh teardown commit 3d3cf6a7314aca4df0a6dde28ce784a2a30d0166 upstream. TP meter sessions remain linked on bat_priv->tp_list after the netlink request has already finished. When the mesh interface is removed, batadv_mesh_free() currently tears down the mesh without first draining these sessions. A running sender thread or a late incoming tp_meter packet can then keep processing against a mesh instance which is already shutting down. Synchronize tp_meter with the mesh lifetime by stopping all active sessions from batadv_mesh_free() and waiting for sender threads to exit before teardown continues. Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Signed-off-by: Jiexun Wang Signed-off-by: Ren Wei Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit e1e2194cc725ec1d41f9412496212f0fa0519c36 Author: Jiexun Wang Date: Mon Apr 27 14:43:33 2026 +0800 batman-adv: reject new tp_meter sessions during teardown commit 3243543592425beec83d453793e9d27caa0d8e66 upstream. Prevent tp_meter from starting new sender or receiver sessions after mesh_state has left BATADV_MESH_ACTIVE. Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Signed-off-by: Jiexun Wang Signed-off-by: Ren Wei Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit bf872db54f91ffe70104b98c20068b2d5910e018 Author: Lyes Bourennani Date: Wed Apr 22 00:20:22 2026 +0200 batman-adv: fix integer overflow on buff_pos commit 0799e5943611006b346b8813c7daf7dd5aa26bfd upstream. Fixing an integer overflow present in batadv_iv_ogm_send_to_if. The size check is done using the int type in batadv_iv_ogm_aggr_packet whereas the buff_pos variable uses the s16 type. This could lead to an out-of-bound read. Cc: stable@vger.kernel.org Fixes: c6c8fea29769 ("net: Add batman-adv meshing protocol") Signed-off-by: Lyes Bourennani Signed-off-by: Alexis Pinson Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman commit c9dadb31f36045a8cb65df4bd75e7237ef21a4b5 Author: Ben Morris Date: Thu May 7 17:14:55 2026 -0700 sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL commit abb5f36771cc4c05899b34000829a787572a8817 upstream. The SCTP_SENDALL path in sctp_sendmsg() iterates ep->asocs with list_for_each_entry_safe(), which caches the next entry in @tmp before the loop body runs. The body calls sctp_sendmsg_to_asoc(), which may drop the socket lock inside sctp_wait_for_sndbuf(). While the lock is dropped, another thread can SCTP_SOCKOPT_PEELOFF the association cached in @tmp, migrating it to a new endpoint via sctp_sock_migrate() (list_del_init() + list_add_tail() to newep->asocs), and optionally close the new socket which frees the association via kfree_rcu(). The cached @tmp can also be freed by a network ABORT for that association, processed in softirq while the lock is dropped. sctp_wait_for_sndbuf() revalidates @asoc (the current entry) on re-lock via the "sk != asoc->base.sk" and "asoc->base.dead" checks, but nothing revalidates @tmp. After a successful return, the iterator advances to the stale @tmp, yielding either a use-after-free (if the peeled socket was closed) or a list-walk onto the new endpoint's list head (type confusion of &newep->asocs as a struct sctp_association *). Both are reachable from CapEff=0; the type-confusion path gives controlled indirect call via the outqueue.sched->init_sid pointer. Fix by re-deriving @tmp from @asoc after sctp_sendmsg_to_asoc() returns. @asoc is known to still be on ep->asocs at that point: the only callers that list_del an association from ep->asocs are sctp_association_free() (which sets asoc->base.dead) and sctp_assoc_migrate() (which changes asoc->base.sk), and sctp_wait_for_sndbuf() checks both under the lock before any successful return; a tripped check propagates as err < 0 and the loop bails before the re-derive. The SCTP_ABORT path in sctp_sendmsg_check_sflags() returns 0 and the loop hits 'continue' before sctp_sendmsg_to_asoc() is ever called, so the @tmp cached by list_for_each_entry_safe() still covers the lock-held free that ba59fb027307 ("sctp: walk the list of asoc safely") was added for. Fixes: 4910280503f3 ("sctp: add support for snd flag SCTP_SENDALL process in sendmsg") Cc: stable@vger.kernel.org Signed-off-by: Ben Morris Acked-by: Xin Long Link: https://patch.msgid.link/20260508001455.3137-1-joycathacker@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit cd39452498e2714340d1f94e3c29081529aec266 Author: Siddharth Vadapalli Date: Mon Mar 9 10:25:32 2026 +0530 arm64: dts: ti: k3-am62a7-sk: Fix pin name in comment from M19 to N22 commit 6ee0792d83d5c690205c350825a4c30746c0e0a2 upstream. The pin for GPMC0_CLK.GPIO0_31 at address 0x000F407C is N22 and not M19. Hence, fix the pin name in the comment to avoid confusion. Fixes: 8f023012eb4a ("arm64: dts: ti: k3-am62a: Enable UHS mode support for SD cards") Cc: stable@vger.kernel.org Signed-off-by: Siddharth Vadapalli Reviewed-by: Andrew Davis Reviewed-by: Bryan Brattlof Link: https://patch.msgid.link/20260309045539.2070793-1-s-vadapalli@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Greg Kroah-Hartman commit 3eb7d0e2d4a08d8e721aa6a75eb07692a549ce89 Author: Viken Dadhaniya Date: Wed Mar 25 18:30:37 2026 +0530 arm64: dts: qcom: lemans: Correct QUP interrupt numbers commit c5b22c88cc09b180e3a23010b29f4d02ec117a44 upstream. Fix GIC_SPI interrupt numbers for QUPv3 SE6 nodes on Lemans SoC. Using incorrect interrupt lines can prevent IRQs from triggering and break I2C, SPI, and UART operation. Fixes: 34a407316b7d3 ("arm64: dts: qcom: sa8775p: Populate additional UART DT nodes") Fixes: 1b2d7ad5ac14d ("arm64: dts: qcom: sa8775p: add missing spi nodes") Fixes: ee2f5f906d69d ("arm64: dts: qcom: sa8775p: add missing i2c nodes") Cc: stable@vger.kernel.org Signed-off-by: Viken Dadhaniya Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260325-lemans-irq-num-v1-1-a470d544966a@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit f8f546883e8777493157ccc4fac5794c502fcbd2 Author: Alex Deucher Date: Tue Apr 28 10:42:49 2026 -0400 drm/amdgpu/pm: align Hawaii mclk workaround with radeon commit 1987c79b4fe5789dfa14423e78b5c25f6acf3e9d upstream. Align the hawaii mclk workaround with radeon and windows. Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/1816 Fixes: 9f4b35411cfe ("drm/amd/powerplay: add CI asics support to smumgr (v3)") Reviewed-by: Timur Kristóf Reviewed-by: Kent Russell Signed-off-by: Alex Deucher (cherry picked from commit 9649528b637f668c5af9f2b83ca4ad8576ae2121) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 6fed6e9f10622db34a18ee6ce155cbe0fa211b23 Author: Alex Deucher Date: Mon Apr 27 11:38:58 2026 -0400 drm/amdgpu/pm: add missing revision check for CI commit 2a561b361b7681509710f3cfc3d95d54c87ac69f upstream. The ci_populate_all_memory_levels() workaround only applies to revision 0 SKUs. Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/1816 Fixes: 9f4b35411cfe ("drm/amd/powerplay: add CI asics support to smumgr (v3)") Reviewed-by: Timur Kristóf Reviewed-by: Kent Russell Signed-off-by: Alex Deucher (cherry picked from commit 1db15ba8f72f400bbad8ae0ce24fafc43429d4bd) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 0b91ea46bb68abf98a082bf239092253bbd6aaa2 Author: John B. Moore Date: Mon Apr 27 16:06:28 2026 -0500 drm/amdgpu/sdma4: replace BUG_ON with WARN_ON in fence emission commit 78d2e624fa073c14970aa097adcf3ea31c157a66 upstream. sdma_v4_0_ring_emit_fence() contains two BUG_ON(addr & 0x3) assertions that verify fence writeback addresses are dword-aligned. These assertions can be reached from unprivileged userspace via crafted DRM_IOCTL_AMDGPU_CS submissions, causing a fatal kernel panic in a scheduler worker thread. Replace both BUG_ON() calls with WARN_ON() to log the condition without crashing the kernel. A misaligned fence address at this point indicates a driver bug, but crashing the kernel is never the correct response when the assertion is reachable from userspace. The CS IOCTL path is the correct place to filter invalid submissions; the ring emission callback is too late to do anything about it. Fixes: 2130f89ced2c ("drm/amdgpu: add SDMA v4.0 implementation (v2)") Reviewed-by: Christian König Signed-off-by: John B. Moore Signed-off-by: Alex Deucher (cherry picked from commit b90250bd933afd1ba94d86d6b13821997b22b18e) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 6fbd52d210c15f3987e04d8fa2cf6ca3ace2d0d8 Author: Felix Kuehling Date: Mon Apr 20 11:55:57 2026 -0400 drm/amdkfd: Make all TLB-flushes heavy-weight commit 9b4e3495d1bd2469bf94b74930c153c2d534ddb7 upstream. With only one sequence number we cannot track the need for legacy vs heavy-weight flushes reliably. Always use heavy-weight. Signed-off-by: Felix Kuehling Reviewed-by: Philip Yang Signed-off-by: Alex Deucher (cherry picked from commit c1a3ff1d327820cd9a52bc1056b98681fc088949) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 46bc180e6ede1cc9bfbd72cd208ad0e742d56ec8 Author: Icenowy Zheng Date: Sun May 3 17:17:08 2026 +0800 drm/panel: boe-tv101wum-nl6: restore MODE_LPM after sending disable cmds commit 570cf799e87ae805eacfab3b4ba66676b5fccdb6 upstream. When preparing the panel, it seems that it always expects commands to be transferred in LP mode. However, the disable function removes the MIPI_DSI_MODE_LPM flag, and no other function re-adds it. As the unprepare function contains no DSI commands, re-adding the flag just after disabling the panel should be safe. Add the code re-adding the flag after the two commands for disabling the panel are sent. This fixes error messages shown in kernel log when unblanking on mt8183-kukui-kodama-sku32 device. Cc: stable@vger.kernel.org Fixes: a869b9db7adf ("drm/panel: support for boe tv101wum-nl6 wuxga dsi video mode panel") Signed-off-by: Icenowy Zheng Reviewed-by: Neil Armstrong Reviewed-by: Douglas Anderson Signed-off-by: Neil Armstrong Link: https://patch.msgid.link/20260503091708.1079962-1-zhengxingda@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit 73af14be7645f3d9d190fe3bec9e8b6bf6e8f1b9 Author: Kory Maincent (TI) Date: Tue Apr 28 11:04:56 2026 +0200 drm/bridge: tda998x: Use __be32 for audio port OF property pointer commit 2a46a9356ba7b1bdd741c8b41e5374edcd960557 upstream. of_get_property() returns a pointer to big-endian (__be32) data, but port_data in tda998x_get_audio_ports() was declared as const u32 *, causing a sparse endianness type mismatch warning. Fix the declaration to use const __be32 *. Fixes: 7e567624dc5a4 ("drm/i2c: tda998x: Register ASoC hdmi-codec and add audio DT binding") Cc: stable@vger.kernel.org Signed-off-by: Kory Maincent (TI) Reviewed-by: Russell King (Oracle) Link: https://patch.msgid.link/20260428090457.121894-1-kory.maincent@bootlin.com Signed-off-by: Luca Ceresoli Signed-off-by: Greg Kroah-Hartman commit 71614ab2a683490bf7f43bf25afcf0d2a57a8403 Author: John B. Moore Date: Tue Apr 28 11:35:12 2026 -0500 drm/amdgpu/gfx9: drop unnecessary 64-bit fence flag check in KIQ commit 7bbfb2559bcec39d1a4e1182d931a2046112c352 upstream. Remove the BUG_ON(flags & AMDGPU_FENCE_FLAG_64BIT) assertion from gfx_v9_0_ring_emit_fence_kiq(). The KIQ hardware supports 64-bit fence writes; the 32-bit writeback address constraint is an upper-layer convention, not a hardware limitation. The check serves no purpose and should not be present. Found by code inspection while investigating related BUG_ON assertions in the GFX and compute ring emission paths. Reviewed-by: Christian König Signed-off-by: John B. Moore Signed-off-by: Alex Deucher (cherry picked from commit 1b1101a46a426bb4328116bb5273c326a2780389) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit f6dbec5bee72e210a670fc05f128790bbd2b1822 Author: Icenowy Zheng Date: Sun Apr 26 00:57:51 2026 +0800 drm/panel: himax-hx83102: restore MODE_LPM after sending disable cmds commit 2d4e80271f784aa0c7b17676e9762c7e8156be1c upstream. When preparing the panel, it seems that it always expects commands to be transferred in LP mode. However, the disable function removes the MIPI_DSI_MODE_LPM flag, and no other function re-adds it. As the unprepare function contains no DSI commands, re-adding the flag just after disabling the panel should be safe. Add the code re-adding the flag after the two commands for disabling the panel are sent. This fixes screen unblanking (after blanking once) on mt8188-geralt-ciri-sku1 device. Cc: stable@vger.kernel.org # 6.11+ Fixes: 0ef94554dc40 ("drm/panel: himax-hx83102: Break out as separate driver") Signed-off-by: Icenowy Zheng Reviewed-by: Neil Armstrong Reviewed-by: Douglas Anderson Signed-off-by: Neil Armstrong Link: https://patch.msgid.link/20260425165751.1716569-1-zhengxingda@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit ed21d6e4ce03b078c84fc4684b13b6a79ec43abe Author: Osama Abdelkader Date: Thu Apr 23 22:06:20 2026 +0200 drm/exynos: remove bridge when component_add fails commit 26f6654a9a60eb4d241f42a0ec85412e8821480b upstream. Use devm_drm_bridge_add() so the bridge is released if probe fails after registration, and drop the manual drm_bridge_remove() in remove(). Check the return value of devm_drm_bridge_add(). Signed-off-by: Osama Abdelkader Fixes: 576d72fbfb45 ("drm/exynos: mic: add a bridge at probe") Cc: stable@vger.kernel.org Reviewed-by: Raphaël Gallais-Pou Reviewed-by: Luca Ceresoli Link: https://patch.msgid.link/20260423200622.325076-2-osama.abdelkader@gmail.com Signed-off-by: Luca Ceresoli Signed-off-by: Greg Kroah-Hartman commit b17175d0a375b3ed5e81597dac4983fdb46e478d Author: Philip Yang Date: Mon Apr 27 09:30:23 2026 -0400 drm/amdgpu: zero-initialize GART table on allocation commit e6c2e6c2e1fa066968a16aca1cb66cd1bdde7741 upstream. GART TLB is flushed after unmapping but not after mapping. Since amdgpu_bo_create_kernel() does not zero-initialize the buffer, when a single PTE is written the TLB may speculatively load other uninitialized entries from the same cacheline. Those garbage entries can appear valid, and a subsequent write to another PTE in the same cacheline may cause the GPU to use a stale garbage PTE from the TLB. Fix this by calling memset_io() to zero-initialize the GART table with gart_pte_flags immediately after allocation. Using AMDGPU_GEM_CREATE_VRAM_CLEARED, SDMA-based clear will not work since SDMA needs GART to be initialized to work. Suggested-by: Felix Kuehling Signed-off-by: Philip Yang Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit d9af8263b82b6eaa60c5718e0c6631c5037e4b24) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 264ee64cf86794353e4fcb363282e3f9cf5249b3 Author: Alex Deucher Date: Mon Apr 27 11:40:25 2026 -0400 drm/radeon: add missing revision check for CI commit 17223816498f7b117d138d18eb0eba63604dc74e upstream. The memory level workarounds only apply to revision 0 SKUs. Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/1816 Fixes: 127e056e2a82 ("drm/radeon: fix mclk vddc configuration for cards for hawaii") Fixes: 21b8a369046f ("drm/radeon: fix dram timing for certain hawaii boards") Fixes: 90b2fee35cb9 ("drm/radeon: fix dpm mc init for certain hawaii boards") Reviewed-by: Timur Kristóf Reviewed-by: Kent Russell Signed-off-by: Alex Deucher (cherry picked from commit 4d8dcc14311515077062b5740f39f427075de5c9) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 672464dd53231509c9c771110798c56d4660e19e Author: Francis, David Date: Tue Apr 28 19:25:50 2026 +0000 drm: Set old handle to NULL before prime swap in change_handle commit 5e28b7b94408897e41c63477aabc9e1db439bc8c upstream. There was a potential race condition in change_handle. The ioctl briefly had a single object with two idr entries; a concurrent gem_close could delete the object and remove one of the handles while leaving the other one dangling, which could subsequently be dereferenced for a use-after-free. To fix this, do the same dance that gem_close itself does. (f6cd7daecff5 drm: Release driver references to handle before making it available again) First idr_replace the old handle to NULL. Later, if the prime operations are successful, actually close it. create_tail required a similar dance to avoid a similar problem. (bd46cece51a3 drm/gem: Fix race in drm_gem_handle_create_tail()) It idr_allocs the new handle with NULL, then swaps in the correct object later to avoid races. We don't need to do that here, since the only operations that could race are drm_prime, and change_handle holds the prime lock for the entire duration. v2: cleanups of error paths Signed-off-by: David Francis Co-authored-by: Dave Airlie Reported-by: Puttimet Thammasaeng Tested-by: Vitaly Prosyak Cc: Simona Vetter Cc: stable@vger.kernel.org Cc: Christian Koenig Fixes: 53096728b8910 ("drm: Add DRM prime interface to reassign GEM handle") Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 87f9b1528e1ffc1da3615d552c9a06aba5e20b00 Author: Jia Yao Date: Fri Apr 17 05:59:16 2026 +0000 drm/xe/uapi: Reject coh_none PAT index for CPU cached memory in madvise commit 4e5591c2fc1b30f4ea5e2eab4c3a695acc404e39 upstream. Add validation in xe_vm_madvise_ioctl() to reject PAT indices with XE_COH_NONE coherency mode when applied to CPU cached memory. Using coh_none with CPU cached buffers is a security issue. When the kernel clears pages before reallocation, the clear operation stays in CPU cache (dirty). GPU with coh_none can bypass CPU caches and read stale sensitive data directly from DRAM, potentially leaking data from previously freed pages of other processes. This aligns with the existing validation in vm_bind path (xe_vm_bind_ioctl_validate_bo). v2(Matthew brost) - Add fixes - Move one debug print to better place v3(Matthew Auld) - Should be drm/xe/uapi - More Cc v4(Shuicheng Lin) - Fix kmem leak issues by the way v5 - Remove kmem leak because it has been merged by another patch v6 - Remove the fix which is not related to current fix v7 - No change v8 - Rebase v9 - Limit the restrictions to iGPU v10 - No change Fixes: ada7486c5668 ("drm/xe: Implement madvise ioctl for xe") Cc: # v6.18+ Cc: Shuicheng Lin Cc: Mathew Alwin Cc: Michal Mrozek Cc: Matthew Brost Cc: Matthew Auld Signed-off-by: Jia Yao Reviewed-by: Matthew Auld Acked-by: Michal Mrozek Acked-by: José Roberto de Souza Signed-off-by: Matthew Auld Link: https://patch.msgid.link/20260417055917.2027459-2-jia.yao@intel.com (cherry picked from commit 016ccdb674b8c899940b3944952c96a6a490d10a) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit fa449b88706e05d3e3a689cedee9d95223a628ec Author: Shuicheng Lin Date: Wed Apr 8 17:52:52 2026 +0000 drm/xe/bo: Fix bo leak on unaligned size validation in xe_bo_init_locked() commit 09a8f3c1c11977a6e10c167f26dd298790b31c32 upstream. When type is ttm_bo_type_device and aligned_size != size, the function returns an error without freeing a caller-provided bo, violating the documented contract that bo is freed on failure. Add xe_bo_free(bo) before returning the error. Fixes: 4e03b584143e ("drm/xe/uapi: Reject bo creation of unaligned size") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.6 Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20260408175255.3402838-2-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin (cherry picked from commit 601c2aa087b6f21014300a3f107a08ee4dde7bdf) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 0afa8b1ef582ecf6fb04097fd356f8741e5005ed Author: Shuicheng Lin Date: Wed Apr 8 17:52:55 2026 +0000 drm/xe: Fix dma-buf attachment leak in xe_gem_prime_import() commit 111ab678471bf1f90d078d5513bb086b70596c3c upstream. When xe_dma_buf_init_obj() fails, the attachment from dma_buf_dynamic_attach() is not detached. Add dma_buf_detach() before returning the error. Note: we cannot use goto out_err here because xe_dma_buf_init_obj() already frees bo on failure, and out_err would double-free it. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.6 Reviewed-by: Mattheq Brost Link: https://patch.msgid.link/20260408175255.3402838-5-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin (cherry picked from commit a828eb185aac41800df8eae4b60501ccc0dbbe51) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit cd38e1503e671576b25f859e5277a56779eb9d06 Author: Shuicheng Lin Date: Wed Apr 8 17:52:53 2026 +0000 drm/xe/bo: Fix bo leak on GGTT flag validation in xe_bo_init_locked() commit 1d0adf2fd94fb0c0037c643fadd8f2cf3cffc009 upstream. When XE_BO_FLAG_GGTT_ALL is set without XE_BO_FLAG_GGTT, the function returns an error without freeing a caller-provided bo, violating the documented contract that bo is freed on failure. Add xe_bo_free(bo) before returning the error. Fixes: 5a3b0df25d6a ("drm/xe: Allow bo mapping on multiple ggtts") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.6 Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20260408175255.3402838-3-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin (cherry picked from commit 3fbd6cf43cac7b60757f3ce3d95195d3843a902c) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit f9ad21b90162baf1d78f8036ff3813c3ec1ac88e Author: Shuicheng Lin Date: Wed Apr 8 17:52:54 2026 +0000 drm/xe: Fix bo leak in xe_dma_buf_init_obj() on allocation failure commit 93a528f67ce5095bcab46a69839eca97f43dd352 upstream. When drm_gpuvm_resv_object_alloc() fails, the pre-allocated storage bo is not freed. Add xe_bo_free(storage) before returning the error. xe_dma_buf_init_obj() calls xe_bo_init_locked(), which frees the bo on error. Therefore, xe_dma_buf_init_obj() must also free the bo on its own error paths. Otherwise, since xe_gem_prime_import() cannot distinguish whether the failure originated from xe_dma_buf_init_obj() or from xe_bo_init_locked(), it cannot safely decide whether the bo should be freed. Add comments documenting the ownership semantics: on success, ownership of storage is transferred to the returned drm_gem_object; on failure, storage is freed before returning. v2: Add comments to explain the free logic. Fixes: eb289a5f6cc6 ("drm/xe: Convert xe_dma_buf.c for exhaustive eviction") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.6 Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20260408175255.3402838-4-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin (cherry picked from commit 78a6c5f899f22338bbf48b44fb8950409c5a69b9) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 2b5ba326f9d0ea2555b717d45548a298529fabf9 Author: Shixiong Ou Date: Fri Apr 24 20:44:27 2026 +0800 drm/udl: Increase GET_URB_TIMEOUT commit ac2c996675755c725a0065dbe3e2ebffded9080b upstream. [WHY] A situation has occurred where udl_handle_damage() executed successfully and the kernel log appears normal, but the display fails to show any output. This is because the call to udl_get_urb() in udl_crtc_helper_atomic_enable() failed without generating any error message. [HOW] 1. Increase timeout of getting urb. 2. Add error messages when calling udl_get_urb() failed in udl_crtc_helper_atomic_enable(). Signed-off-by: Shixiong Ou Reviewed-by: Thomas Zimmermann Fixes: 5320918b9a87 ("drm/udl: initial UDL driver (v4)") Signed-off-by: Thomas Zimmermann Cc: # v3.4+ Link: https://patch.msgid.link/20260424124427.657-1-oushixiong1025@163.com Signed-off-by: Greg Kroah-Hartman commit db9530a9873a7c85d2266a922589ebcf427fa631 Author: Alysa Liu Date: Tue Apr 21 10:18:28 2026 -0400 drm/amdkfd: validate SVM ioctl nattr against buffer size commit 045e0ff208f0838a246c10204105126611b267a1 upstream. Validate nattr field against the buffer size, preventing out-of-bounds buffer access via user-controlled attribute count. Reviewed-by: Amir Shetaia Signed-off-by: Alysa Liu Signed-off-by: Alex Deucher (cherry picked from commit 5eca8bfdfa456c3304ca77523718fe24254c172f) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit a7735b491a2d18f859e14356cb71ad096f3fdf3c Author: Sasha Finkelstein Date: Mon Apr 20 14:17:43 2026 +0200 drm/appletbdrm: Use kvzalloc for big allocations commit aaaa684bab1f6d9ecfc49db328facb1771fd0eb2 upstream. This driver is attached to a ~2000x80 screen, which is a lot more than a single page. This causes out of memory errors in some rare cases. Reported-by: soopyc Closes: https://github.com/t2linux/fedora/issues/51 Signed-off-by: Sasha Finkelstein Signed-off-by: Thomas Zimmermann Reviewed-by: Aditya Garg Reviewed-by: Thomas Zimmermann Fixes: 0670c2f56e45 ("drm/tiny: add driver for Apple Touch Bars in x86 Macs") Cc: # v6.15+ Link: https://patch.msgid.link/20260420-x86-tb-vmalloc-v1-1-7757ff657223@chaosmail.tech Signed-off-by: Greg Kroah-Hartman commit 1a17ea9861e89585361caa8bc231bd22dc6dbe7d Author: Ashutosh Desai Date: Mon Apr 20 01:36:37 2026 +0000 drm/gem: Fix inconsistent plane dimension calculation in drm_gem_fb_init_with_funcs() commit 3d4c2268bd7243c3780fe32bf24ff876da272acf upstream. drm_gem_fb_init_with_funcs() computes sub-sampled plane dimensions using plain integer division: unsigned int width = mode_cmd->width / (i ? info->hsub : 1); unsigned int height = mode_cmd->height / (i ? info->vsub : 1); However, the ioctl-level framebuffer_check() in drm_framebuffer.c uses drm_format_info_plane_width/height() which round up dimensions via DIV_ROUND_UP(). This inconsistency corrupts the subsequent GEM object size check for certain pixel format and dimension combinations. For example, with NV12 (vsub=2) and a 1-pixel-tall framebuffer the GEM size validation path sees height=0 instead of height=1. The expression (height - 1) then wraps to UINT_MAX as an unsigned int, causing min_size to overflow and wrap back to a small value. A tiny GEM object therefore passes the size guard, yet when the GPU accesses the chroma plane it will read or write memory beyond the object's bounds. Fix by replacing the open-coded divisions with drm_format_info_plane_width() and drm_format_info_plane_height(), which use DIV_ROUND_UP() and match the calculation already used in framebuffer_check(). Fixes: 4c3dbb2c312c ("drm: Add GEM backed framebuffer library") Cc: stable@vger.kernel.org # v4.14+ Reviewed-by: Thomas Zimmermann Signed-off-by: Ashutosh Desai Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260420013637.457751-1-ashutoshdesai993@gmail.com Signed-off-by: Greg Kroah-Hartman commit 158def957199b6c0b4d578f369ad05cbd7789fe9 Author: Mario Kleiner Date: Sat Mar 21 06:20:33 2026 +0100 drm/amd/display: Change dither policy for 10 bpc output back to dithering commit d65bfb1782304b03862c8c725fac608015dffd36 upstream. Commit d5df648ec830 ("drm/amd/display: Change dither policy for 10bpc to round") degraded display of 12 bpc color precision output to 10 bpc sinks by switching 10 bpc output from dithering to "truncate to 10 bpc". I don't find the argumentation in that commit convincing, but the consequences highly unfortunate, especially for applications that require effective > 10 bpc precision output of > 10 bpc framebuffers. The argument wasn't something strong like "there are hardware design defects or limitations which require us to work around broken dithering to 10 bpc", or "there are some special use cases which do require truncation to 10 bpc", but essentially "at some point in the past we used truncation in Polaris/Vega times and it looks like it got inadvertently changed for Navi, so let's do that again". I couldn't find evidence for that in the git commit logs for this. The commit message also acknowledges that using dithering "...makes some sense for FP16... ...but not for ARGB2101010 surfaces..." The problem with this is that it makes fp16 surfaces, and especially rgba16 fixed point surfaces, less useful. These are now well supported by Mesa 25.3 and later via OpenGL + EGL, Vulkan/WSI, and by OSS AMDVLK Vulkan/WSI/display, and also by GNOME 50 mutter under Wayland, and they used to provide more than 10 bpc effective precision at the output. Even for 8 or 10 bpc surfaces, the color pipeline behind the framebuffer, e.g., gamma tables, CTM, can be used for color correction and will benefit from an effective > 10 bpc output precision via dithering, retaining some precision that would get lost on the way through the pipeline, e.g., due to non-linear gamma functions. Scientific apps rely on this for > 10 bpc display precision. Truncating to 10 bpc, instead of dithering the pipeline internal 12 bpc precision down to 10 bpc, causes a serious loss of precision. This also creates the undesirable and slightly absurd situation that using a cheap monitor with only 8 bpc input and display panel will yield roughly 12 bpc precision via dithering from 12 -> 8 bpc, whereas investment into a more expensive monitor with 10 bpc input and native 10 bpc display will only yield 10 bpc, even if a fp16 or rgb16 framebuffer and/or a properly set up color pipeline (gamma tables, CTM's etc. with more than 10 bpc out precision) would allow effective 12 bpc precision output. Therefore this patch proposes reverting that commit and going back to dithering down to 10 bpc, consistent with the behaviour for 6 bpc or 8 bpc output. Successfully tested on AMD Polaris DCE 11.2 and Raven Ridge DCN 1.0 with a native 10 bpc capable monitor, outputting a RGBA16 unorm framebuffer and measuring resulting color precision with a photometer. No apparent visual artifacts or problems were observed, and effective precision was measured to be 12 bpc again, as expected. Fixes: d5df648ec830 ("drm/amd/display: Change dither policy for 10bpc to round") Signed-off-by: Mario Kleiner Tested-by: Mario Kleiner Cc: stable@vger.kernel.org Cc: Aric Cyr Cc: Anthony Koo Cc: Rodrigo Siqueira Cc: Krunoslav Kovac Cc: Alex Deucher Reported-by: Mario Kleiner Signed-off-by: Harry Wentland Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 638e48ee39d0f2af9336f917a6f5d6692dd64d93 Author: Benjamin Cheng Date: Tue Mar 24 16:25:56 2026 -0400 drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg commit b193019860d61e92da395eae2011f2f6716b182f upstream. Check bounds against the end of the BO whenever we access the msg. Signed-off-by: Benjamin Cheng Reviewed-by: Christian König Reviewed-by: Ruijing Dong Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 63b51e8a9d54317d31cc3856c1e12407070d5fc2 Author: Benjamin Cheng Date: Wed Mar 25 09:09:27 2026 -0400 drm/amdgpu/vcn4: Prevent OOB reads when parsing dec msg commit 0a78f2bac1424deb7c9d5e09c6b8e849d8e8b648 upstream. Check bounds against the end of the BO whenever we access the msg. Signed-off-by: Benjamin Cheng Reviewed-by: Christian König Reviewed-by: Ruijing Dong Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b3d1a0a45c4aec484fa2a5b060b611e3d3064470 Author: Benjamin Cheng Date: Mon Mar 30 15:01:27 2026 -0400 drm/amdgpu/vce: Prevent partial address patches commit de2a02cc28d6d5d37db07d00a9a684c754a5fd74 upstream. In the case that only one of lo/hi is valid, the patching could result in a bad address written to in FW. Signed-off-by: Benjamin Cheng Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit a6d5563ba1f03a049561cd347574613167294e8d Author: Benjamin Cheng Date: Tue Mar 24 16:42:05 2026 -0400 drm/amdgpu/vcn4: Prevent OOB reads when parsing IB commit 2444eb0ec8283f4a3845eb7febad378476e1ba3c upstream. Rewrite the IB parsing to use amdgpu_ib_get_value() which handles the bounds checks. Signed-off-by: Benjamin Cheng Acked-by: Christian König Reviewed-by: Ruijing Dong Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit fec8b11b55e53ff51a741e56894fe331a516f5c6 Author: Benjamin Cheng Date: Wed Mar 25 08:39:19 2026 -0400 drm/amdgpu: Add bounds checking to ib_{get,set}_value commit 66085e206431ef88ce36f53c1f53d570790ccc9e upstream. The uvd/vce/vcn code accesses the IB at predefined offsets without checking that the IB is large enough. Check the bounds here. The caller is responsible for making sure it can handle arbitrary return values. Also make the idx a uint32_t to prevent overflows causing the condition to fail. Signed-off-by: Benjamin Cheng Reviewed-by: Christian König Reviewed-by: Ruijing Dong Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 44d5a450c04d3d734c13a03561c3131020d66edf Author: Alysa Liu Date: Mon Mar 30 10:50:07 2026 -0400 drm/amdkfd: Add upper bound check for num_of_nodes commit 74b73fa56a395d46745e4f245225963e9f8be7f1 upstream. drm/amdkfd: Add upper bound check for num_of_nodes in kfd_ioctl_get_process_apertures_new. Reviewed-by: Harish Kasiviswanathan Signed-off-by: Alysa Liu Signed-off-by: Alex Deucher (cherry picked from commit 98ff46a5ea090c14d2cdb4f5b993b05d74f3949f) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit de137adccf7ade2d06e46bf9f0960ecc6be6ef13 Author: Yang Wang Date: Thu Apr 2 22:44:29 2026 -0400 drm/amd/pm: fix incorrect FeatureCtrlMask setting on smu v14.0.x commit 504f0098ebd074ac8c0ce3471795d79f68e3d265 upstream. OverDriveTable.FanMinimumPwm and FeatureCtrlMask.PP_OD_FEATURE_FAN_LEGACY_BIT have a hard dependency. Invalid handling of this dependency leads to disabled thermal monitoring and temperature boundary validation. v2: squash in typo fix (Yang) Fixes: 9710b84e2a6a ("drm/amd/pm: add overdrive support on smu v14.0.2/3") Cc: stable@vger.kernel.org Signed-off-by: Yang Wang Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit f34eda3ff33d351a9d9c078420cbe1bd258b413e Author: Chenglei Xie Date: Tue Apr 7 10:51:24 2026 -0400 drm/amdgpu: gate VM CPU HDP flush on reset lock commit ddda81c4d7e71e41b1be91d921fd85747eddbd12 upstream. During GPU reset, the application could still run CPU page table updates. Each commit called amdgpu_device_flush_hdp(), which on SR-IOV sends work through the KIQ ring. That can advance sync_seq while the GPU is being reset, leaving fence writeback out of sync and causing amdgpu_fence_emit_polling() to time out on later KIQ use. Fix: amdgpu_vm_cpu_commit(): Reset will flush HDP anyway, the HDP flush in amdgpu_vm_cpu_commit() can be skipped when a reset is ongoging. Take reset_domain->sem with down_read_trylock() before amdgpu_device_flush_hdp(). If the reset path holds the write lock, skip the HDP flush so no HDP-related HW access (including KIQ) runs during reset; state is re-established after reset. Signed-off-by: Chenglei Xie Reviewed-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2795d325bb5c133ff7f32d9272eea4877f42f358 Author: Ramalingeswara Reddy, Kanala Date: Tue Mar 31 17:23:22 2026 +0530 drm/amdgpu: Use SMUIO 15.0.0 offsets for TSC upper and lower count. commit 574b3b14f7d1b329fc6e67b79328f0e6f4d4b3d4 upstream. Define and use regGOLDEN_TSC_COUNT_UPPER_smu_15_0_0 and regGOLDEN_TSC_COUNT_LOWER_smu_15_0_0 for TSC upper and lower count. Acked-by: Alex Deucher Reviewed-by: Pratik Vishwakarma Signed-off-by: Ramalingeswara Reddy, Kanala Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 77d0b5d11387071770246fd0185a69fa28e8e109 Author: Amir Shetaia Date: Fri Apr 10 10:38:13 2026 -0400 drm/amdkfd: Clear VRAM on allocation to prevent stale data exposure commit ad52d61d82181dbdb7f05826de38352d5e550cc2 upstream. KFD VRAM allocations set AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE but not AMDGPU_GEM_CREATE_VRAM_CLEARED, leaving freshly allocated VRAM with stale data from prior use observable by compute kernels. The GEM ioctl path already sets VRAM_CLEARED for all userspace allocations via amdgpu_gem_create_ioctl() and amdgpu_mode_dumb_create(). The KFD path was missing this flag, allowing stale page table remnants to leak into user buffers. This causes crashes in RCCL P2P transport where non-zero data in ptrExchange/head/tail fields corrupts the protocol handshake. Signed-off-by: Amir Shetaia Reviewed-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 48fb2213e2c27f94dccf657a2ffd3c8256ad7729 Author: Jouni Högander Date: Mon Apr 13 14:23:45 2026 +0300 drm/i915/psr: Init variable to avoid early exit from et alignment loop commit 314f6179e370988ac00dadf373a4f6166eb3db15 upstream. Uninitialized boolean variable may cause unwanted exit from et alignment loop. Fix this by initializing it as false. Fixes: 1be2fca84f52 ("drm/i915/psr: Repeat Selective Update area alignment") Cc: # v6.9+ Signed-off-by: Jouni Högander Reviewed-by: Nemesa Garg Reported-by: Dan Carpenter Reviewed-by: Andi Shyti Link: https://patch.msgid.link/20260413112345.88853-1-jouni.hogander@intel.com (cherry picked from commit 289678a90b8cf81e3514c9d6c667235cd39c7acf) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit 132b8d51f0ffbee6e4e1ebbe1a50330aaf2dbd5d Author: Anna Maniscalco Date: Tue Feb 10 17:29:42 2026 +0100 drm/msm: always recover the gpu commit 01a0d6cd7032e9993feea19fadb03ef9d5b488f2 upstream. Previously, in case there was no more work to do, recover worker wouldn't trigger recovery and would instead rely on the gpu going to sleep and then resuming when more work is submitted. Recover_worker will first increment the fence of the hung ring so, if there's only one job submitted to a ring and that causes an hang, it will early out. There's no guarantee that the gpu will suspend and resume before more work is submitted and if the gpu is in a hung state it will stay in that state and probably trigger a timeout again. Just stop checking and always recover the gpu. Signed-off-by: Anna Maniscalco Cc: stable@vger.kernel.org Patchwork: https://patchwork.freedesktop.org/patch/704066/ Message-ID: <20260210-recovery_suspend_fix-v1-1-00ed9013da04@gmail.com> Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit c5b5a0e418b1dc33b48dc3658f7ee5db6d5187f6 Author: Marek Vasut Date: Sat Jan 10 18:14:10 2026 +0100 drm/imx: parallel-display: Prefer bus format set via legacy "interface-pix-fmt" DT property commit cdf26e1462c220629bb79d487263b66f8b679eab upstream. Prefer bus format set via legacy "interface-pix-fmt" DT property over panel bus format. This is necessary to retain support for DTs which configure the IPUv3 parallel output as 24bit DPI, but connect 18bit DPI panels to it with hardware swizzling. This used to work up to Linux 6.12, but stopped working in 6.13, reinstate the behavior to support old DTs. Cc: stable@vger.kernel.org Fixes: 5f6e56d3319d ("drm/imx: parallel-display: switch to drm_panel_bridge") Signed-off-by: Marek Vasut Reviewed-by: Philipp Zabel Signed-off-by: Philipp Zabel Link: https://patch.msgid.link/20260110171510.692666-1-marex@nabladev.com Signed-off-by: Greg Kroah-Hartman commit c57c861956b89f2e2528e6384d51e2dedd915809 Author: Yasuaki Torimaru Date: Wed Mar 25 20:46:34 2026 +0900 drm/msm/gem: fix error handling in msm_ioctl_gem_info_get_metadata() commit 47cbfe2608314b833ad61a65827d8fb363bc2d2d upstream. msm_ioctl_gem_info_get_metadata() always returns 0 regardless of errors. When copy_to_user() fails or the user buffer is too small, the error code stored in ret is ignored because the function unconditionally returns 0. This causes userspace to believe the ioctl succeeded when it did not. Additionally, kmemdup() can return NULL on allocation failure, but the return value is not checked. This leads to a NULL pointer dereference in the subsequent copy_to_user() call. Add the missing NULL check for kmemdup() and return ret instead of 0. Note that the SET counterpart (msm_ioctl_gem_info_set_metadata) correctly returns ret. Fixes: 9902cb999e4e ("drm/msm/gem: Add metadata") Cc: stable@vger.kernel.org Signed-off-by: Yasuaki Torimaru Patchwork: https://patchwork.freedesktop.org/patch/714478/ Message-ID: <20260325114635.383241-1-yasuakitorimaru@gmail.com> Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit e9ae6590405d46a75c2f9698ba2c1d28231b683f Author: Johan Hovold Date: Tue Apr 21 14:36:13 2026 +0200 spi: cadence: fix clock imbalance on probe failure commit ecea4f0e9db2fb6ab4a68a59c5aba0d8f59a9566 upstream. Make sure that the controller is active before disabling clocks on probe failure to avoid unbalanced clock disable. Also drop the usage count before returning (so that the controller can be suspended after a probe deferral) and restore the autosuspend setting. Fixes: d36ccd9f7ea4 ("spi: cadence: Runtime pm adaptation") Cc: stable@vger.kernel.org # 4.7 Cc: Shubhrajyoti Datta Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260421123615.1533617-3-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6ac380a0071de8c17116bd31511bc33b2dafedf0 Author: Johan Hovold Date: Tue Apr 21 14:36:12 2026 +0200 spi: cadence: fix unclocked access on unbind commit 5b1689a41f02955c5361944f748a4812a6ff9307 upstream. Make sure that the controller is runtime resumed before disabling it during driver unbind to avoid unclocked register access and unbalanced clock disable. Also restore the autosuspend setting. This issue was flagged by Sashiko when reviewing a controller deregistration fix. Fixes: d36ccd9f7ea4 ("spi: cadence: Runtime pm adaptation") Cc: stable@vger.kernel.org # 4.7 Cc: Shubhrajyoti Datta Link: https://sashiko.dev/#/patchset/20260414134319.978196-1-johan%40kernel.org?part=1 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260421123615.1533617-2-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 59701f07b19e462d2e684c7b5b7a2ff720eadaee Author: Johan Hovold Date: Tue Apr 14 15:43:12 2026 +0200 spi: cadence: fix controller deregistration commit 666fa7e9ca98e71c880086ca24147ae843f1ed6e upstream. Make sure to deregister the controller before disabling underlying resources like clocks during driver unbind. Fixes: c474b3866546 ("spi: Add driver for Cadence SPI controller") Cc: stable@vger.kernel.org # 3.16 Cc: Harini Katakam Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260414134319.978196-2-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6c3e413919a12627d04a31a4a5fccb9fc129bb02 Author: Johan Hovold Date: Tue Apr 14 15:43:15 2026 +0200 spi: mpc52xx: fix use-after-free on unbind commit 706b3dc2ac7a998c55e14b3fd2e8f934c367e6e0 upstream. The state machine work is scheduled by the interrupt handler and therefore needs to be cancelled after disabling interrupts to avoid a potential use-after-free. Fixes: 984836621aad ("spi: mpc52xx: Add cancel_work_sync before module remove") Cc: stable@vger.kernel.org Cc: Pei Xiao Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260414134319.978196-5-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 28f28a0f4e327f792c230493a0ea00389ff68ff5 Author: Johan Hovold Date: Tue Apr 14 15:43:14 2026 +0200 spi: mpc52xx: fix controller deregistration commit 0f997fdae819a8c2cc83bd4ff7d935ad76c727c9 upstream. Make sure to deregister the controller before disabling and releasing underlying resources like interrupts and gpios during driver unbind. Fixes: 42bbb70980f3 ("powerpc/5200: Add mpc5200-spi (non-PSC) device driver") Fixes: b8d4e2ce60b6 ("mpc52xx_spi: add gpio chipselect") Cc: stable@vger.kernel.org # 2.6.33 Cc: Grant Likely Cc: Luotao Fu Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260414134319.978196-4-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 336d9ad7560b3baba17af06727a888040ee93390 Author: Johan Hovold Date: Tue Apr 21 14:58:00 2026 +0200 spi: mpc52xx: fix use-after-free on registration failure commit f62c060272b9d7423b1650b844e8e4e7b8f9f925 upstream. Make sure to disable and free the interrupts in case controller registration fails to avoid a potential use-after-free and resource leak. This issue was flagged by Sashiko when reviewing a controller deregistration fix. Fixes: 42bbb70980f3 ("powerpc/5200: Add mpc5200-spi (non-PSC) device driver") Cc: stable@vger.kernel.org # 2.6.33 Cc: Grant Likely Link: https://sashiko.dev/#/patchset/20260414134319.978196-1-johan%40kernel.org?part=3 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260421125800.1537361-1-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 07dc76d31be43e8992c72523edd4e7af70897a52 Author: Johan Hovold Date: Tue Apr 21 15:02:10 2026 +0200 spi: orion: fix clock imbalance on registration failure commit 443cde0dc59c5d154156ac9f27a7dadef8ebc0c2 upstream. Make sure that the controller is not runtime suspended before disabling clocks on probe failure. Also restore the autosuspend setting. Fixes: 5c6786945b4e ("spi: spi-orion: add runtime PM support") Cc: stable@vger.kernel.org # 3.17 Cc: Russell King Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260421130211.1537628-3-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b809b8d2a114384a6228f584b68d0c7767d59f4b Author: Johan Hovold Date: Tue Apr 21 15:02:09 2026 +0200 spi: orion: fix runtime pm leak on unbind commit 97b17dd8266d2e26d9ee3c75a0fa34ecde6944f0 upstream. Make sure to balance the runtime PM usage count on driver unbind so that the controller can be suspended when a driver is rebound. Also restore the autosuspend setting. This issue was flagged by Sashiko when reviewing a controller deregistration fix. Fixes: 5c6786945b4e ("spi: spi-orion: add runtime PM support") Cc: stable@vger.kernel.org # 3.17 Cc: Russell King Link: https://sashiko.dev/#/patchset/20260414134319.978196-1-johan%40kernel.org?part=6 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260421130211.1537628-2-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit ec7a4cff8355c5bb0edc8e225885a92b0c9c1d93 Author: Johan Hovold Date: Tue Apr 14 15:43:17 2026 +0200 spi: orion: fix controller deregistration commit 220f4f11104a7f83b71543ef0e48dde1da2bc5d3 upstream. Make sure to deregister the controller before disabling underlying resources like clocks during driver unbind. Fixes: 60cadec9da7b ("spi: new orion_spi driver") Cc: stable@vger.kernel.org # 2.6.27 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260414134319.978196-7-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5c03d52ee6ceb4be73389f5868586b0084f08f2c Author: Johan Hovold Date: Tue Apr 14 15:43:16 2026 +0200 spi: mxic: fix controller deregistration commit adbc595e272052181d40ec307a4c5ba98571b0fe upstream. Make sure to deregister the controller before disabling underlying resources like clocks (via runtime pm) during driver unbind. Fixes: b942d80b0a39 ("spi: Add MXIC controller driver") Cc: stable@vger.kernel.org # 5.0: cc53711b2191 Cc: stable@vger.kernel.org # 5.0 Cc: Mason Yang Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260414134319.978196-6-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 2a2973cb368220305d8169a3ae8d0e06f668bfcd Author: Johan Hovold Date: Tue Apr 21 14:56:32 2026 +0200 spi: imx: fix runtime pm leak on probe deferral commit a1d50a37d3b1df84f536a982f692371039df4a48 upstream. Make sure to balance the runtime PM usage count before returning on probe failure (e.g. probe deferral) so that the controller can be suspended when a driver is later bound. Fixes: 43b6bf406cd0 ("spi: imx: fix runtime pm support for !CONFIG_PM") Cc: stable@vger.kernel.org # 5.10 Cc: Sascha Hauer Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260421125632.1537235-1-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6a405d594207fa1442d8b26009e4e4e8dc415805 Author: Johan Hovold Date: Thu Apr 9 14:04:19 2026 +0200 spi: mpfs: fix controller deregistration commit 573c7db8fce91a1b07dd64a260bb44b9e6d05943 upstream. Make sure to deregister the controller before disabling underlying resources like interrupts during driver unbind. Fixes: 9ac8d17694b6 ("spi: add support for microchip fpga spi controllers") Cc: stable@vger.kernel.org # 6.0 Cc: Conor Dooley Signed-off-by: Johan Hovold Acked-by: Conor Dooley Link: https://patch.msgid.link/20260409120419.388546-21-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b2bdbe293012fd640fa1406d1b36ecd9c061db8a Author: Johan Hovold Date: Thu Apr 9 14:04:14 2026 +0200 spi: img-spfi: fix controller deregistration commit fc3a83b0d9c16b941c9028f5a8db9541dce4ddf2 upstream. Make sure to deregister the controller before disabling and releasing underlying resources like clocks and DMA during driver unbind. Fixes: deba25800a12 ("spi: Add driver for IMG SPFI controller") Cc: stable@vger.kernel.org # 3.19 Cc: Andrew Bresticker Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260409120419.388546-16-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 4b0fe572a8ea3e1b2de301eff41c8ddb3267d4ae Author: Johan Hovold Date: Fri Apr 10 10:17:45 2026 +0200 spi: slave-mt27xx: fix controller deregistration commit ab840cbda4fe6c40e52f6415c47056797c663bb2 upstream. Make sure to deregister the controller before disabling underlying resources like clocks (by disabling runtime PM) during driver unbind. Fixes: 805be7ddf367 ("spi: mediatek: add spi slave for Mediatek MT2712") Cc: stable@vger.kernel.org # 4.20 Cc: Leilk Liu Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-16-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 0df72db5a13c0f45cc8b54b29abbe288d9e1b843 Author: Johan Hovold Date: Fri Apr 10 10:17:43 2026 +0200 spi: sh-msiof: fix controller deregistration commit 45170f67a08b912ead6ccc387ba06954d1d4e53a upstream. Make sure to deregister the controller before releasing underlying resources like DMA during driver unbind. Fixes: 1bd6363bc0c6 ("spi: sh-msiof: Use core message handling instead of spi-bitbang") Cc: stable@vger.kernel.org # 3.15 Cc: Geert Uytterhoeven Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-14-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit aee76c1dd189562c6678313caec12761f78a9ef3 Author: Johan Hovold Date: Fri Apr 10 10:17:40 2026 +0200 spi: rspi: fix controller deregistration commit 9944fa6726afb1e6eb7e2212764e7da0c97f2dcc upstream. Make sure to deregister the controller before releasing underlying resources like DMA during driver unbind. Fixes: 9e03d05eee4c ("spi: rcar: Use devm_spi_register_master()") Cc: stable@vger.kernel.org # 3.14 Cc: Jingoo Han Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-11-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 229cc70e4e902f904bf774527fd77d4d3777be0b Author: Johan Hovold Date: Fri Apr 10 10:17:46 2026 +0200 spi: sprd: fix controller deregistration commit 123d17dbc5f07059752fa5e616385ca29a8f935a upstream. Make sure to deregister the controller before disabling underlying resources like clocks during driver unbind. Note that the controller is suspended before disabling and releasing resources since commit de082d866cce ("spi: sprd: Add the SPI irq function for the SPI DMA mode") which avoids issues like unclocked accesses but prevents SPI device drivers from doing I/O during deregistration. Fixes: e7d973a31c24 ("spi: sprd: Add SPI driver for Spreadtrum SC9860") Cc: stable@vger.kernel.org # 4.20 Cc: Lanqing Liu Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-17-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit cdbf6baefff09ab042315d4ed19e1029d0de7afb Author: Johan Hovold Date: Fri Apr 10 10:17:37 2026 +0200 spi: pic32-sqi: fix controller deregistration commit 420df79d1a618951eb0eb4331df95c9f4f763b8b upstream. Make sure to deregister the controller before releasing underlying resources like DMA during driver unbind. Fixes: 3270ac230f66 ("spi: pic32-sqi: add SPI driver for PIC32 SQI controller.") Cc: stable@vger.kernel.org # 4.7 Cc: Purna Chandra Mandal Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-8-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 82a95eca235b2fa65c808dfbbbe2716dc6f21379 Author: Johan Hovold Date: Thu Apr 9 14:04:08 2026 +0200 spi: cavium-thunderx: fix controller deregistration commit dbb6b01267c0c866eaac4019cec19f414beec61d upstream. Make sure to deregister the controller before disabling it to avoid hanging or leaking resources associated with the queue when the queue non-empty. Fixes: 7347a6c7af8d ("spi: octeon: Add ThunderX driver") Cc: stable@vger.kernel.org # 4.9 Cc: Jan Glauber Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260409120419.388546-10-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit e84a84209b3f3f20e2c8568d0ddf9f7342c75482 Author: Johan Hovold Date: Fri Apr 10 10:17:34 2026 +0200 spi: npcm-pspi: fix controller deregistration commit ebd81199e00e107980bf8c4d2c747ae50158f797 upstream. Make sure to deregister the controller before disabling underlying resources like clocks during driver unbind. Fixes: 2a22f1b30cee ("spi: npcm: add NPCM PSPI controller driver") Cc: stable@vger.kernel.org # 5.0 Cc: Tomer Maimon Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-5-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit ee2100d08094bf6e50ecc3d58e274d915e506285 Author: Johan Hovold Date: Thu Apr 9 14:04:09 2026 +0200 spi: coldfire-qspi: fix controller deregistration commit e7c510e192ff2a1264d999575eea39a506424264 upstream. Make sure to deregister the controller before disabling underlying resources like clocks (via runtime pm) during driver unbind. Fixes: 34b8c6617366 ("spi: Add Freescale/Motorola Coldfire QSPI driver") Cc: stable@vger.kernel.org # 2.6.34 Cc: Steven King Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260409120419.388546-11-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 047f939c602cfea4e44969412ad4c54e938cb8a8 Author: Johan Hovold Date: Thu Apr 9 14:04:06 2026 +0200 spi: bcmbca-hsspi: fix controller deregistration commit c3d97c3320b9a1ebbd6119857341be034f7b3efc upstream. Make sure to deregister the controller before disabling underlying resources like interrupts during driver unbind to allow SPI drivers to do I/O during deregistration. Note that clocks were also disabled before the recent commit e532e21a246d ("spi: bcm63xx-hsspi: Simplify clock handling with devm_clk_get_enabled()"). Fixes: a38a2233f23b ("spi: bcmbca-hsspi: Add driver for newer HSSPI controller") Cc: stable@vger.kernel.org # 6.3: deb269e0394f Cc: stable@vger.kernel.org # 6.3 Cc: William Zhang Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260409120419.388546-8-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit ca3195c7b88362d7c81efe685948663a9f9db0e6 Author: Johan Hovold Date: Fri Apr 10 08:47:49 2026 +0200 spi: fsl: fix controller deregistration commit 9b7abfed4c3754062d1f3ffd452e65a38667f586 upstream. Make sure to deregister the controller before releasing underlying resources like DMA during driver unbind. Fixes: 4178b6b1b595 ("spi: fsl-(e)spi: migrate to using devm_ functions to simplify cleanup") Cc: stable@vger.kernel.org # 4.3 Cc: Heiner Kallweit Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410064749.496888-1-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit d78c5ca1563c0531e01fcc127820bd0255a7a753 Author: Johan Hovold Date: Fri Apr 10 10:17:42 2026 +0200 spi: sh-hspi: fix controller deregistration commit e63982e6392e45a6ecd68d6c317a081cc8e70143 upstream. Make sure to deregister the controller before releasing underlying resources like clocks during driver unbind. Fixes: 49e599b8595f ("spi: sh-hspi: control spi clock more correctly") Cc: stable@vger.kernel.org # 3.4 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-13-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 4422fc2411cbbdf5104a914e0596bb483faea254 Author: Johan Hovold Date: Fri Mar 27 11:43:05 2026 +0100 spi: ch341: fix devres lifetime commit abe572f630bc1f0e77041012ab075869036ede4f upstream. USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the controller and driver data lifetime so that they are released on driver unbind. Note that this also makes sure that the SPI controller is placed correctly under the USB interface in the device tree. Fixes: 8846739f52af ("spi: add ch341a usb2spi driver") Cc: stable@vger.kernel.org # 6.11 Cc: Johannes Thumshirn Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260327104305.1309915-3-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit af4f58c18c4cdb050fd716b7af7a6545ef8c5ba2 Author: Johan Hovold Date: Fri Apr 10 10:17:38 2026 +0200 spi: pl022: fix controller deregistration commit 994b33366be9148240690e3e94bffe17c4d89458 upstream. Make sure to deregister the controller before releasing underlying resources like DMA during driver unbind. Fixes: b43d65f7e818 ("[ARM] 5546/1: ARM PL022 SSP/SPI driver v3") Cc: stable@vger.kernel.org # 2.6.31 Cc: Linus Walleij Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-9-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit cc8a904cbe6de6cb8b77aea336502cfe8c4974de Author: Johan Hovold Date: Fri Apr 10 10:17:32 2026 +0200 spi: mtk-nor: fix controller deregistration commit 76336f24934621db286cabb20b483773ee01dcaa upstream. Make sure to deregister the controller before disabling underlying resources like clocks during driver unbind. Fixes: 881d1ee9fe81 ("spi: add support for mediatek spi-nor controller") Cc: stable@vger.kernel.org # 5.7 Cc: Chuanhong Guo Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-3-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 894d761a3a852c13688cd2719ebdbc6a43403d64 Author: Johan Hovold Date: Fri Apr 10 10:17:36 2026 +0200 spi: pic32: fix controller deregistration commit 6b627bfe0c44e064aba464839e430dc1ca2b0bb8 upstream. Make sure to deregister the controller before releasing underlying resources like DMA during driver unbind. Fixes: 1bcb9f8ceb67 ("spi: spi-pic32: Add PIC32 SPI master driver") Cc: stable@vger.kernel.org # 4.7 Cc: Purna Chandra Mandal Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-7-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 4ed7de898bbb25421865aa5e95a467239fbd7869 Author: Johan Hovold Date: Fri Apr 10 10:17:35 2026 +0200 spi: omap2-mcspi: fix controller deregistration commit fb45f95c377e4a4bdece2c5e17643b459c9c13e7 upstream. Make sure to deregister the controller before releasing underlying resources like DMA during driver unbind. Fixes: ccdc7bf92573 ("SPI: omap2_mcspi driver") Cc: stable@vger.kernel.org # 2.6.23 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-6-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 09ceedcebc7785f564d6afb4f1db48787431426f Author: Johan Hovold Date: Thu Apr 9 14:04:12 2026 +0200 spi: fsl-espi: fix controller deregistration commit e506a700a7ad229f5c8f01f4b8350119cccb4158 upstream. Make sure to deregister the controller before disabling runtime PM (which can leave the controller disabled) to allow SPI device drivers to do I/O during deregistration. Fixes: e9abb4db8d10 ("spi: fsl-espi: add runtime PM") Cc: stable@vger.kernel.org # 4.3 Cc: Heiner Kallweit Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260409120419.388546-14-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b99939bccae94d0eac8c86532444c11933447102 Author: Johan Hovold Date: Fri Apr 10 10:17:41 2026 +0200 spi: s3c64xx: fix controller deregistration commit c1446b61e472da24d1547525193467b4bea4a7cb upstream. Make sure to deregister the controller before releasing underlying resources like DMA during driver unbind. Fixes: 91800f0e9005 ("spi/s3c64xx: Use managed registration") Cc: stable@vger.kernel.org # 3.13: 76fbad410c0f Cc: stable@vger.kernel.org # 3.13 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-12-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c74ba734001069bab836fa1494d340efcd80b67d Author: Johan Hovold Date: Thu Apr 9 14:04:10 2026 +0200 spi: dln2: fix controller deregistration commit c353020fbfa8514ee91a6de2d88de4e5edca5803 upstream. Make sure to deregister the controller before disabling it to allow SPI device drivers to do I/O during deregistration. Fixes: 3d8c0d749da3 ("spi: add support for DLN-2 USB-SPI adapter") Cc: stable@vger.kernel.org # 4.0 Cc: Laurentiu Palcu Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260409120419.388546-12-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 724520793a2ed39ece0a6f984447e78e614b51fe Author: Johan Hovold Date: Fri Apr 10 10:17:31 2026 +0200 spi: mt65xx: fix controller deregistration commit 2ad30599cccc572ba2fc11010670eb6e01ea6bfc upstream. Make sure to deregister the controller before disabling underlying resources like clocks during driver unbind. Fixes: a568231f4632 ("spi: mediatek: Add spi bus for Mediatek MT8173") Cc: stable@vger.kernel.org # 4.3: ace145802350 Cc: stable@vger.kernel.org # 4.3 Cc: Leilk Liu Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-2-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit cc525debdfc8030959825f42beaabaaeef51d3c4 Author: Johan Hovold Date: Fri Apr 10 10:17:33 2026 +0200 spi: mxs: fix controller deregistration commit 8b0d0011af20fb547aa67a1cefbf320992fd5e92 upstream. Make sure to deregister the controller before releasing underlying resources like DMA during driver unbind. Fixes: 33e195acf268 ("spi: mxs: use devm_spi_register_master()") Cc: stable@vger.kernel.org # 3.13 Cc: Jingoo Han Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-4-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 22ee38cbf536125d4e8a0b6222ded1942f526a3b Author: Wenmeng Liu Date: Fri Mar 13 18:13:04 2026 +0800 media: qcom: camss: Add missing clocks for VFE lite on sa8775p commit d31fac47b39f5e1ed85a587688ca70b793e421b4 upstream. Add missing required clocks (cpas_ahb and camnoc_axi) for VFE lite instances on sa8775p platform. These clocks are necessary for proper VFE lite operation: Reviewed-by: Bryan O'Donoghue Signed-off-by: Wenmeng Liu Fixes: e7b59e1d06fb ("media: qcom: camss: Add support for VFE 690") Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 696ac7c49c27169637e79fd9e6237bf5b42b368c Author: Thomas Fourier Date: Fri Feb 13 10:13:27 2026 +0100 media: iris: Fix dma_free_attrs() size in iris_hfi_queues_init() commit 4a49ae56b0e4268d48fd96babe0cc68596bc301a upstream. The core->iface_q_table_vaddr buffer is alloc'd with size queue_size but freed with sizeof(*q_tbl_hdr) which is different. Change the dma_free_attrs() size. Signed-off-by: Thomas Fourier Reviewed-by: Dikshita Agarwal Fixes: d7378f84e94e ("media: iris: introduce iris core state management with shared queues") Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 095c51bc86d30161e98bf775222bfdf829d501d8 Author: Arnd Bergmann Date: Mon Mar 30 12:08:21 2026 +0100 media: venus: fix QCOM_MDT_LOADER dependency commit aa23c94cc433b145d1ce93820ecdfe16d8940e28 upstream. When build-testined with CONFIG_QCOM_MDT_LOADER=m and VIDEO_QCOM_VENUS=y, the kernel fails to link: x86_64-linux-ld: drivers/media/platform/qcom/venus/firmware.o: in function `venus_boot': firmware.c:(.text+0x1e3): undefined reference to `qcom_mdt_get_size' firmware.c:(.text+0x25a): undefined reference to `qcom_mdt_load' firmware.c:(.text+0x272): undefined reference to `qcom_mdt_load_no_init' The problem is the conditional 'select' statement. Change this to make the driver built-in here regardless of CONFIG_ARCH_QCOM, same as for the similar IRIS driver. Signed-off-by: Arnd Bergmann Reviewed-by: Konrad Dybcio Reviewed-by: Dikshita Agarwal Fixes: 0399b696f7f4 ("media: venus: fix compile-test build on non-qcom ARM platform") Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit e56a252478603938e4fe145ec8f42b740d6241cf Author: Dmitry Baryshkov Date: Fri Mar 27 22:19:55 2026 +0200 media: qcom: iris: increase H265D_MAX_SLICE to fix H.265 decoding on SC7280 commit 3e0b2053751657ed2924adfe3ff25b1450231e33 upstream. Follow the commit bfe1326573ff ("venus: Fix for H265 decoding failure.") and increase H265D_MAX_SLICE following firmware requirements on that platform. Otherwise decoding of the H.265 streams fails with the "insufficient scratch_1 buffer size" from the firmware. Signed-off-by: Dmitry Baryshkov Reviewed-by: Dikshita Agarwal Reviewed-by: Vikash Garodia Reviewed-by: Konrad Dybcio [bod: Fixed commit log withthe => with the] Fixes: e1f5d32608ec ("media: iris: Add internal buffer calculation for HEVC and VP9 decoders") Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 9d6217429cd4dd51fd7178988be8581f72689bcb Author: Wenmeng Liu Date: Fri Mar 13 18:13:02 2026 +0800 media: qcom: camss: Fix csid IRQ offset for sa8775p commit dd1b373941079cc102cc18bc68884e18245f5912 upstream. Fix BUF_DONE_IRQ_STATUS_RDI_OFFSET calculation for csid lite on sa8775p platform. The offset should be 0 for csid lite on sa8775p, Signed-off-by: Wenmeng Liu Reviewed-by: Bryan O'Donoghue Fixes: ed03e99de0fa ("media: qcom: camss: Add support for CSID 690") Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 8744fd0835ddf4e100e97f2a7ce84d07afdd1d32 Author: Wenmeng Liu Date: Fri Mar 13 18:13:03 2026 +0800 media: qcom: camss: Fix csid clock configuration for sa8775p commit fe56c674118aa46da1a3e65aa22ca709ebd7d812 upstream. Fix the mismatch between clock list and clock rate table for CSID lite instances. The current implementation has 5 clocks defined but only 2 are actually needed (vfe_lite_csid and vfe_lite_cphy_rx), while the clock rate table doesn't match this configuration. Update both clock list and rate table to maintain consistency: - Remove unused clocks: cpas_vfe_lite, vfe_lite_ahb, vfe_lite - Update clock rate table to match the remaining two clocks Signed-off-by: Wenmeng Liu Reviewed-by: Bryan O'Donoghue Fixes: ed03e99de0fa ("media: qcom: camss: Add support for CSID 690") Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit dd24998a4a4016fb9921916024399bd80f0d45c6 Author: Dikshita Agarwal Date: Mon Feb 16 12:37:42 2026 +0530 media: iris: Fix use-after-free in iris_release_internal_buffers() commit f27cfdcfc916bb59297825805f4c3499f89f9e76 upstream. The recent change in commit 1dabf00ee206 ("media: iris: gen1: Destroy internal buffers after FW releases") introduced a regression where session_release_buf() may free the buffer. The caller, iris_release_internal_buffers(), continued to access `buffer` after the call, leading to a potential use-after-free. Fix this by setting BUF_ATTR_PENDING_RELEASE before calling session_release_buf(), and reverting the flag if the call fails. This ensures no dereference occurs after potential freeing. Reported-by: Dan Carpenter Closes: https://lore.kernel.org/lkml/aYXvKAX3Pg3sL37P@stanley.mountain/#r Signed-off-by: Dikshita Agarwal Reviewed-by: Vikash Garodia Fixes: 1dabf00ee206 ("media: iris: gen1: Destroy internal buffers after FW releases") Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 1920b4602ec912ac3160b799ef9ae5b936529321 Author: Arnd Bergmann Date: Thu Feb 5 15:56:19 2026 +0100 media: iris: fix QCOM_MDT_LOADER dependency commit a297c5165f91366cbc3490e630aabd1c0f70efb8 upstream. When build-testined with CONFIG_QCOM_MDT_LOADER=m and VIDEO_QCOM_IRIS=y, the kernel fails to link: x86_64-linux-ld: drivers/media/platform/qcom/iris/iris_firmware.o: in function `iris_fw_load': iris_firmware.c:(.text+0xb0): undefined reference to `qcom_mdt_get_size' iris_firmware.c:(.text+0xfd): undefined reference to `qcom_mdt_load' The problem is the conditional 'select' statement. Change this to make the driver built-in here regardless of CONFIG_ARCH_QCOM. Signed-off-by: Arnd Bergmann Reviewed-by: Konrad Dybcio Reviewed-by: Dikshita Agarwal Reviewed-by: Bryan O'Donoghue Fixes: d19b163356b8 ("media: iris: implement video firmware load/unload") Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit d172bb82f70c370912a9184cac083050657612f8 Author: Haoxiang Li Date: Mon Jan 26 09:44:12 2026 +0800 media: omap3isp: drop the use count of v4l2 pipeline commit 9da49bd9d4224035cff39b40d7395310abb10201 upstream. In isp_video_open(), drop the use count of v4l2 pipeline if vb2_queue_init() fails. Fixes: 8fd390b89cc8 ("media: Split v4l2_pipeline_pm_use into v4l2_pipeline_pm_{get, put}") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit cedfde9f45b16ea14541f2390b195ba31bc56403 Author: Matthias Fend Date: Tue Mar 24 11:41:35 2026 +0100 media: i2c: ov08d10: fix runtime PM handling in probe commit 35c7046be2be5e60be8128facb359a47f39e99cd upstream. Set the device's runtime PM status and enable runtime PM before registering the async sub-device. This is needed to avoid the case where the device is runtime PM resumed while runtime PM has not been enabled yet. Remove the related, non-driver-specific comment while at it. Fixes: 7be91e02ed57 ("media: i2c: Add ov08d10 camera sensor driver") Cc: stable@vger.kernel.org Reviewed-by: Philipp Zabel Signed-off-by: Matthias Fend Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit d9e678e8c63366f8f3eb61f035ccca2aebfe5d93 Author: Matthias Fend Date: Tue Mar 24 11:41:36 2026 +0100 media: i2c: ov08d10: fix image vertical start setting commit 5d150fa0f16096d736bd24d13e04495da5116fab upstream. The current settings for the "image vertical start" register appear to be incorrect. While this only results in an incorrect start line for native modes, this faulty setting causes actual problems in binning mode. At least on an i.MX8MP test system, only corrupted frames could be received. To correct this, the recommended settings from the reference register sets are used for all modes. Since this shifts the start by one line, the Bayer pattern also changes, which has also been corrected. Fixes: 7be91e02ed57 ("media: i2c: Add ov08d10 camera sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Matthias Fend Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit ea91dee38b4e96c22361cbfdd4302332992ec615 Author: Michael Tretter Date: Fri Nov 7 11:34:33 2025 +0100 media: staging: imx: request mbus_config in csi_start commit 9df2aaa64890c0b6226057eb6fcb6352bd2df432 upstream. Request the upstream mbus_config in csi_start, which starts the stream, instead of caching it in link_validate. This allows to get rid of the mbus_cfg field in the struct csi_priv and avoids state in the driver. Fixes: 4a34ec8e470c ("[media] media: imx: Add CSI subdev driver") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Signed-off-by: Michael Tretter Reviewed-by: Philipp Zabel Signed-off-by: Frank Li Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 731d7ab8dfa2cdd197e4f77c121fd910fcdc9884 Author: Wenmeng Liu Date: Fri Jan 23 17:19:55 2026 +0800 media: i2c: imx412: Assert reset GPIO during probe commit 8467c5ff5acae28513bc1e0af535e06b41b04344 upstream. Assert the reset GPIO before first power up. This avoids a mismatch where the first power up (when the reset GPIO defaults deasserted) differs from subsequent cycles. Signed-off-by: Wenmeng Liu Fixes: 9214e86c0cc1 ("media: i2c: Add imx412 camera sensor driver") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 34fe9c3c594e515f4668ea4b2233bb5b1ef8d6fd Author: Sergey Shtylyov Date: Fri Feb 6 17:22:26 2026 +0300 media: dib8000: avoid division by 0 in dib8000_set_dds() commit dde3c37af95cd6fa301c4906f33d627bc9dd874c upstream. In dib8000_set_dds(), 1 << 26 (67108864) divided by e.g. 1 apparently can't fit into 16-bit variable unit_khz_dds_val, being truncated to 0; this will cause division by 0 while calling dprintk() with debugging enabled (via the module parameter). Use s32 instead of s16 to declare the variable, getting rid of the cast to u16 in the *else* branch as well... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. Fixes: 173a64cb3fcf ("[media] dib8000: enhancement") Cc: stable@vger.kernel.org Signed-off-by: Sergey Shtylyov Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit def939175ab8e4b13713481c4182217026e8c7e2 Author: Abdun Nihaal Date: Thu Mar 12 18:02:56 2026 +0530 media: pci: zoran: fix potential memory leak in zoran_probe() commit 8ea21435fe36fb853706f4935d78bc11beb63fb4 upstream. The memory allocated for codec in videocodec_attach() is not freed in one of the error paths, due to an incorrect goto label. Fix the label to free it on error. Fixes: 8f7cc5c0b0eb ("media: staging: media: zoran: introduce zoran_i2c_init") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 84d7810692941169a671b587ce021fac9c4da294 Author: Gregor Herburger Date: Thu Feb 26 09:55:59 2026 +0100 arm64: dts: broadcom: bcm2712-d-rpi-5-b: update uart10 interrupt commit 18d4a06e10051681de074a9250e54afc1f3ee312 upstream. On the -d revision of bcm2712 the uart interrupt is on 120. Update it accordingly. Signed-off-by: Gregor Herburger Link: https://lore.kernel.org/r/20260226-raspi-dts-updates-v1-6-60832d20ff04@linutronix.de Signed-off-by: Florian Fainelli Cc: Rasmus Villemoes Signed-off-by: Greg Kroah-Hartman commit 65d7b2aecdfee65a0c85232c4d0bc130b7e5b965 Author: Gregor Herburger Date: Thu Feb 26 09:55:58 2026 +0100 arm64: dts: broadcom: bcm2712-d-rpi-5-b: add fixes for pinctrl/pinctrl_aon commit aeb078cebc40d421f61a8f07b0e7919aeb44d751 upstream. On the -d revision of the bcm2712 the pinctrl differs from the c0 revision. The driver already supports both and distinguishes the two with the compatible string. Update the compatible string and reg length to reflect the different pinctrl. Signed-off-by: Gregor Herburger Link: https://lore.kernel.org/r/20260226-raspi-dts-updates-v1-5-60832d20ff04@linutronix.de Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit 5167575b79e25187242a77ea5d90f8bfc2e563bc Author: Luigi Leonardi Date: Wed Apr 15 17:09:28 2026 +0200 vsock/virtio: fix MSG_PEEK ignoring skb offset when calculating bytes to copy commit 080f22f5d30233faf3d83be3098f35b8be9b7a00 upstream. `virtio_transport_stream_do_peek()` does not account for the skb offset when computing the number of bytes to copy. This means that, after a partial recv() that advances the offset, a peek requesting more bytes than are available in the sk_buff causes `skb_copy_datagram_iter()` to go past the valid payload, resulting in a -EFAULT. The dequeue path already handles this correctly. Apply the same logic to the peek path. Fixes: 0df7cd3c13e4 ("vsock/virtio/vhost: read data from non-linear skb") Reviewed-by: Stefano Garzarella Acked-by: Arseniy Krasnov Signed-off-by: Luigi Leonardi Link: https://patch.msgid.link/20260415-fix_peek-v4-1-8207e872759e@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 75c38af4d919ffbf1ea7931683d6ab2e0b648c7b Author: Krishna Chomal Date: Fri Apr 3 13:31:55 2026 +0530 platform/x86: hp-wmi: Ignore backlight and FnLock events commit e8c597368b8500a824c639bfb5ed0044068c6870 upstream. On HP OmniBook 7 the keyboard backlight and FnLock keys are handled directly by the firmware. However, they still trigger WMI events which results in "Unknown key code" warnings in dmesg. Add these key codes to the keymap with KE_IGNORE to silence the warnings since no software action is needed. Tested-by: Artem S. Tashkinov Reported-by: Artem S. Tashkinov Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221181 Signed-off-by: Krishna Chomal Link: https://patch.msgid.link/20260403080155.169653-1-krishna.chomal108@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 45890a035e2b789b88ea2dfe8180a02a68850bca Author: Johan Hovold Date: Thu Apr 9 14:04:01 2026 +0200 spi: aspeed-smc: fix controller deregistration commit 1044e5a4ccd57bf5a64f90100a321b498e0267a2 upstream. Make sure to deregister the controller before disabling it to allow SPI device drivers to do I/O during deregistration. Fixes: e3228ed92893 ("spi: spi-mem: Convert Aspeed SMC driver to spi-mem") Cc: stable@vger.kernel.org # 5.19 Cc: Cédric Le Goater Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260409120419.388546-3-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 07938829cc11e6979e710db88f20a1a42c42918f Author: Johan Hovold Date: Thu Apr 9 14:04:00 2026 +0200 spi: amlogic-spisg: fix controller deregistration commit 84d31bb1f6256eea0db6cf64a3c7a53145f92bb9 upstream. Make sure to deregister the controller before disabling underlying resources like clocks during driver unbind. Fixes: cef9991e04ae ("spi: Add Amlogic SPISG driver") Cc: stable@vger.kernel.org # 6.17: b8db95529979 Cc: stable@vger.kernel.org # 6.17 Cc: Sunny Luo Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260409120419.388546-2-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6047dc542fa404b5c187cc2c7906aaaaec6d11ed Author: Wang Jun <1742789905@qq.com> Date: Mon Mar 16 20:24:01 2026 +0800 media: saa7164: add ioremap return checks and cleanups commit d51c60a498e83c9a79884c8e420f97e3885c9583 upstream. Add checks for ioremap return values in saa7164_dev_setup(). If ioremap for BAR0 or BAR2 fails, release the already allocated PCI memory regions, remove the device from the global list, decrement the device count, and return -ENODEV. This prevents potential null pointer dereferences and ensures proper cleanup on memory mapping failures. Fixes: 443c1228d505 ("V4L/DVB (12923): SAA7164: Add support for the NXP SAA7164 silicon") Cc: stable@vger.kernel.org Signed-off-by: Wang Jun <1742789905@qq.com> Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit d6f56e66e8f4be148e2ca483704cce52932d20e6 Author: Johan Hovold Date: Thu Apr 9 14:04:02 2026 +0200 spi: at91-usart: fix controller deregistration commit 9acecc9bcff058eaef40fd7a4c3650e88b06b220 upstream. Make sure to deregister the controller before disabling and releasing underlying resources like clocks and DMA during driver unbind. Fixes: e1892546ff66 ("spi: at91-usart: Add driver for at91-usart as SPI") Cc: stable@vger.kernel.org # 4.20 Cc: Radu Pirea Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260409120419.388546-4-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5d707cf9c1386cdbecc6a3a42bdae413b7bf71ac Author: Johan Hovold Date: Fri Apr 10 10:17:39 2026 +0200 spi: qup: fix controller deregistration commit 443e3a0005a4342b218b6dbd4c6387d3c7fed85a upstream. Make sure to deregister the controller before disabling underlying resources like clocks during driver unbind. Fixes: 64ff247a978f ("spi: Add Qualcomm QUP SPI controller support") Cc: stable@vger.kernel.org # 3.15 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-10-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 4eccd83f228f1a59bdc2a135c824f9d23fd00275 Author: Johan Hovold Date: Thu Apr 9 14:04:16 2026 +0200 spi: meson-spicc: fix controller deregistration commit 77953c76bec9af4191f8692a10225dd816208718 upstream. Make sure to deregister the controller before disabling it to allow SPI device drivers to do I/O during deregistration. Fixes: 454fa271bc4e ("spi: Add Meson SPICC driver") Cc: stable@vger.kernel.org # 4.13 Cc: Neil Armstrong Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260409120419.388546-18-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6ca3eaa82812f7f8df89241e8232a450a6cc01c1 Author: Johan Hovold Date: Thu Apr 9 14:04:15 2026 +0200 spi: lantiq-ssc: fix controller deregistration commit b99206710d032c16b7f8b75e4bc18414d8e4b9f4 upstream. Make sure to deregister the controller before releasing underlying resources like clocks during driver unbind. Fixes: 17f84b793c01 ("spi: lantiq-ssc: add support for Lantiq SSC SPI controller") Cc: stable@vger.kernel.org # 4.11 Cc: Hauke Mehrtens Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260409120419.388546-17-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 184dcecc952124ee8ee280d890f7c658e9305e33 Author: Johan Hovold Date: Wed Apr 8 09:30:55 2026 +0200 regulator: bd9571mwv: fix OF node reference imbalance commit 8498100ee1d00422b8c5b161b3e332278b92a59a 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: e85c5a153fe2 ("regulator: Add ROHM BD9571MWV-M PMIC regulator driver") Cc: stable@vger.kernel.org # 4.12 Cc: Marek Vasut Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260408073055.5183-8-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 037bcca27835a2e28aea866b44777d57d7961414 Author: Johan Hovold Date: Wed Apr 8 09:30:53 2026 +0200 regulator: s2dos05: fix OF node reference imbalance commit ebe694d67f159899b063eee61bacda4cb825ed7b 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: bb2441402392 ("regulator: add s2dos05 regulator support") Cc: stable@vger.kernel.org # 6.18 Cc: Dzmitry Sankouski Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260408073055.5183-6-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 890a8bcef3090f715c64b4c10f09e26aae9a60ab Author: Johan Hovold Date: Wed Apr 8 09:30:54 2026 +0200 regulator: act8945a: fix OF node reference imbalance commit 0d15ce31375ccef4162f960b34547a821b7619d2 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: 38c09961048b ("regulator: act8945a: add regulator driver for ACT8945A") Cc: stable@vger.kernel.org # 4.6 Cc: Wenyou Yang Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260408073055.5183-7-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 41ef27dcaa12302ad536043f6791e0fd08bc8e29 Author: Jai Luthra Date: Sat Feb 14 18:35:22 2026 +0530 media: i2c: imx283: Fix hang when going from large to small resolution commit 9206359b2c396ff594adf39bc7daaadab0fcb367 upstream. When switching between modes (e.g. full resolution to binned), standby_cancel() previously cleared XMSTA (starting master mode data output) before the new mode's MDSEL, crop, and timing registers were programmed in start_streaming(). This caused the sensor to briefly output MIPI data using the previous mode's configuration. On receivers like imx-mipi-csis, this leads to FIFO overflow errors when switching from a higher to a lower resolution, as the receiver is configured for the new smaller frame size but receives stale full-resolution data. Fix this by moving the XMSTA and SYNCDRV register writes from standby_cancel() to the end of start_streaming(), after all mode, crop, and timing registers have been configured. Also explicitly stop master mode (XMSTA=1) when stopping the stream, matching the pattern used by other Sony sensor drivers (imx290, imx415). Use named macros IMX283_XMSTA_START/STOP instead of raw 0/BIT(0) for readability. Cc: stable@vger.kernel.org Fixes: ccb4eb4496fa ("media: i2c: Add imx283 camera sensor driver") Signed-off-by: Jai Luthra Tested-by: Kieran Bingham Reviewed-by: Kieran Bingham Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit f43e30646fc93799f3f48530d0ccbd52902c0541 Author: Ethan Tidmore Date: Fri Mar 6 21:03:55 2026 -0600 media: intel/ipu6: fix error pointer dereference commit 8dd088b8b106f7b119664f965b691785998edcfb upstream. In a error path isp->psys is confirmed to be an error pointer not NULL so this condition is true and the error pointer is dereferenced. So isp-psys should be set to NULL before going to out_ipu6_bus_del_devices. Detected by Smatch: drivers/media/pci/intel/ipu6/ipu6.c:690 ipu6_pci_probe() error: 'isp->psys' dereferencing possible ERR_PTR() Fixes: 25fedc021985a ("media: intel/ipu6: add Intel IPU6 PCI device driver") Cc: stable@vger.kernel.org Signed-off-by: Ethan Tidmore [Sakari Ailus: Fix commit message.] Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 21fade52ab9fb13368a5709e60b0d9909197aeae Author: Janne Grunau Date: Sun Feb 15 18:42:59 2026 +0100 media: videobuf2: Set vma_flags in vb2_dma_sg_mmap commit 7254b31a13aaa0c2c0f9ffbc335b718656117ff4 upstream. vb2_dma_contig sets VMA flags VM_DONTEXPAND and VM_DONTDUMP and I do not see a reason why vb2_dma_sg should behave differently. This avoids hitting `WARN_ON(!(vma->vm_flags & VM_DONTEXPAND));` in drm_gem_mmap_obj() during mmap() of an imported dma-buf from the out of tree Apple ISP camera capture driver which uses vb2_dma_sg_memops. gst-launch-1.0 v4l2src ! gtk4paintablesink [ 38.201528] ------------[ cut here ]------------ [ 38.202135] WARNING: CPU: 7 PID: 2362 at drivers/gpu/drm/drm_gem.c:1144 drm_gem_mmap_obj+0x1f8/0x210 [ 38.203278] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device uinput nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables qrtr bnep nls_ascii i2c_dev loop fuse dm_multipath nfnetlink brcmfmac_wcc hid_magicmouse hci_bcm4377 brcmfmac brcmutil bluetooth ecdh_generic cfg80211 ecc btrfs xor xor_neon rfkill hid_apple raid6_pq joydev aop_als apple_nvmem_spmi industrialio snd_soc_aop apple_z2 snd_soc_cs42l84 tps6598x snd_soc_tas2764 macsmc_reboot spi_nor macsmc_hwmon rtc_macsmc gpio_macsmc macsmc_power regmap_spmi macsmc_input dockchannel_hid panel_summit appledrm nvme_apple dwc3 snd_soc_macaudio drm_client_lib nvme_core phy_apple_atc hwmon apple_sart apple_dockchannel macsmc apple_rtkit_helper spmi_apple_controller aop apple_wdt mfd_core nvmem_apple_efuses pinctrl_apple_gpio apple_isp apple_dcp videobuf2_dma_sg mux_core spi_apple [ 38.203300] videobuf2_memops i2c_pasemi_platform snd_soc_apple_mca videobuf2_v4l2 videodev clk_apple_nco videobuf2_common snd_pcm_dmaengine adpdrm asahi apple_admac adpdrm_mipi drm_dma_helper pwm_apple i2c_pasemi_core drm_display_helper mc cec apple_dart ofpart apple_soc_cpufreq leds_pwm phram [ 38.217677] CPU: 7 UID: 1000 PID: 2362 Comm: gst-launch-1.0 Tainted: G W 6.17.6+ #asahi-dev PREEMPT(full) [ 38.219040] Tainted: [W]=WARN [ 38.219398] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT) [ 38.220213] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 38.221088] pc : drm_gem_mmap_obj+0x1f8/0x210 [ 38.221643] lr : drm_gem_mmap_obj+0x78/0x210 [ 38.222178] sp : ffffc0008dc678e0 [ 38.222579] x29: ffffc0008dc678e0 x28: 0000000000042a97 x27: ffff8000b701b480 [ 38.223465] x26: 00000000000000fb x25: ffffc0008dc67d20 x24: ffffc0008dc67968 [ 38.224402] x23: ffff8000e3ca5600 x22: ffff8000265b7800 x21: ffff80003000c0c0 [ 38.225279] x20: 0000000000000000 x19: ffff8000b68c5200 x18: ffffc0008dc67968 [ 38.226151] x17: 0000000000000000 x16: 0000000000000000 x15: ffffc000810a30a8 [ 38.227042] x14: 00007fff637effff x13: 00005555de91ffff x12: 00007fff63293fff [ 38.227942] x11: 0000000000000000 x10: ffff8000184ecf08 x9 : ffffc0007a1900c8 [ 38.228824] x8 : ffffc0008dc67968 x7 : 0000000000000012 x6 : ffffc0015cf1c000 [ 38.229703] x5 : ffffc0008dc676a0 x4 : ffffc00081a27dc0 x3 : 0000000000000038 [ 38.230607] x2 : 0000000000000003 x1 : 0000000000000003 x0 : 00000000100000fb [ 38.231488] Call trace: [ 38.231806] drm_gem_mmap_obj+0x1f8/0x210 (P) [ 38.232342] drm_gem_mmap+0x140/0x260 [ 38.232813] __mmap_region+0x488/0x9a0 [ 38.233277] mmap_region+0xd0/0x148 [ 38.233703] do_mmap+0x350/0x5c0 [ 38.234148] vm_mmap_pgoff+0x14c/0x200 [ 38.234612] ksys_mmap_pgoff+0x150/0x208 [ 38.235107] __arm64_sys_mmap+0x34/0x50 [ 38.235611] invoke_syscall+0x50/0x120 [ 38.236075] el0_svc_common.constprop.0+0x48/0xf0 [ 38.236680] do_el0_svc+0x24/0x38 [ 38.237113] el0_svc+0x38/0x168 [ 38.237507] el0t_64_sync_handler+0xa0/0xe8 [ 38.238034] el0t_64_sync+0x198/0x1a0 [ 38.238491] ---[ end trace 0000000000000000 ]--- There were discussions in [1] at the end of 2023 that mmap() on imported dma-bufs should not be supported but as of v6.17 drm_gem_shmem_mmap() in drm_gem_shmem_helper.c still supports it. This might affect all gpu or accel drivers using drm_gem_shmem_mmap() or the wrapper drm_gem_shmem_object_mmap(). [1] https://lore.kernel.org/dri-devel/bc7f7844-0aa3-4802-b203-69d58e8be2fa@linux.intel.com/ Cc: stable@vger.kernel.org Fixes: 5ba3f757f059 ("[media] v4l: videobuf2: add DMA scatter/gather allocator") Signed-off-by: Janne Grunau Acked-by: Marek Szyprowski Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit dd681c102b4bfea67e3f65ff48641a42cdc8c11f Author: Johan Hovold Date: Wed Apr 8 09:30:50 2026 +0200 regulator: rk808: fix OF node reference imbalance commit 65290b24d8a5f0b8cd065201e653db824c4a4da6 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: 647e57351f8e ("regulator: rk808: reduce 'struct rk808' usage") Cc: stable@vger.kernel.org # 6.2 Reviewed-by: Sebastian Reichel Reviewed-by: Douglas Anderson Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260408073055.5183-3-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit e7374c14216988505e50fea6769c81cca748b211 Author: Johan Hovold Date: Wed Apr 8 09:30:49 2026 +0200 regulator: bq257xx: fix OF node reference imbalance commit 7ea07bc030d8d6395524dec22ff3267441a28c0d 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: 981dd162b635 ("regulator: bq257xx: Add bq257xx boost regulator driver") Cc: stable@vger.kernel.org # 6.18 Cc: Chris Morgan Reviewed-by: Douglas Anderson Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260408073055.5183-2-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6c5d4c819d920b8af9e12bc7db7bfa96d8d1650b Author: Jai Luthra Date: Sat Feb 14 18:35:21 2026 +0530 media: i2c: imx283: Enter full standby when stopping streaming commit bce1349dbf6348ddee47308e2ed08878356de317 upstream. Use IMX283_STANDBY (bit 0) instead of IMX283_STBLOGIC (bit 1) when stopping streaming. STBLOGIC only puts the sensor logic into standby but leaves the MIPI interface (along with other components) in an indeterminate state. This (presumably) causes the CSI receiver (e.g. Raspberry Pi's CFE) to miss the LP-11 to HS transition when streaming restarts, resulting in a hang of 10+ seconds. The issue is most visible when immediately restarting a full-resolution stream after stopping a 3x3 binned one, so that runtime suspend hasn't yet been triggered. Writing IMX283_STANDBY puts the entire sensor into standby. The imx283_standby_cancel() sequence already handles the full wakeup from this suspended state. Cc: stable@vger.kernel.org Link: https://github.com/raspberrypi/linux/issues/7153 Link: https://github.com/will127534/OneInchEye/issues/12 Fixes: ccb4eb4496fa ("media: i2c: Add imx283 camera sensor driver") Signed-off-by: Jai Luthra Tested-by: Kieran Bingham Reviewed-by: Kieran Bingham Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit ecd0c501bd630696244af69eb6a51f6b012a549c Author: Oliver Neukum Date: Wed Feb 11 19:06:21 2026 +0100 media: rc: streamzap: Error handling in probe commit 42844992664f03ef9f930e64f7370fa481e9c267 upstream. If submitting the URB fails, the device will be unusable. Probe() must fail. Fixes: 7a569f524dd36 ("V4L/DVB: IR/streamzap: functional in-kernel decoding") Cc: stable@vger.kernel.org Signed-off-by: Oliver Neukum Signed-off-by: Sean Young Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 63a960b39de9c51f29ca19aa5067934f865c0bc7 Author: Oliver Neukum Date: Wed Feb 11 19:09:44 2026 +0100 media: rc: xbox_remote: heed DMA restrictions commit e280d1e5e3f2595bbb43fe6e1bce00c59a43c0ff upstream. The buffer for IO must not be part of the device structure because that violates the DMA coherency rules. Fixes: 02d32bdad3123 ("media: rc: add driver for Xbox DVD Movie Playback Kit") Cc: stable@vger.kernel.org Signed-off-by: Oliver Neukum Signed-off-by: Sean Young Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit a8ada5b761159698c11785e547427783596dfd5b Author: Johan Hovold Date: Wed Apr 8 09:30:51 2026 +0200 regulator: max77650: fix OF node reference imbalance commit 2edaf5f7ada0ab5c9ec1f0836bd19779a8d85262 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: bcc61f1c44fd ("regulator: max77650: add regulator support") Cc: stable@vger.kernel.org # 5.1 Reviewed-by: Bartosz Golaszewski Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260408073055.5183-4-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 8993d307cf2c055877ccbe5428c202149a48f4ab Author: Johan Hovold Date: Fri Apr 10 10:17:47 2026 +0200 spi: st-ssc4: fix controller deregistration commit 19857374010d06ca6a2f7c2c53464122eb804df0 upstream. Make sure to deregister the controller before disabling underlying resources like clocks during driver unbind. Fixes: 9e862375c542 ("spi: Add new driver for STMicroelectronics' SPI Controller") Cc: stable@vger.kernel.org # 4.0 Cc: Lee Jones Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-18-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 2d51cfca84829ed26881b822c3cc55608c5ec487 Author: Johan Hovold Date: Wed Apr 8 09:30:52 2026 +0200 regulator: mt6357: fix OF node reference imbalance commit 2f38e96c273e15f5e9f5d1fc2c0cbba703751602 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: dafc7cde23dc ("regulator: add mt6357 regulator") Cc: stable@vger.kernel.org # 6.2 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260408073055.5183-5-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c7848b67ef10f581114b6a2f52b160fc20eb52c9 Author: Sakari Ailus Date: Thu Feb 26 15:10:54 2026 +0200 staging: media: atomisp: Disallow all private IOCTLs commit 2b7eb2c5dc72f0fc954ac4aa155f9e285e937f7c upstream. Disallow all private IOCTLs. These aren't quite as safe as one could assume of IOCTL handlers; disable them for now. Instead of removing the code, return in the beginning of the function if cmd is non-zero in order to keep static checkers happy. Reported-by: Soufiane Dani Closes: https://lore.kernel.org/linux-staging/20260210-atomisp-fix-v1-1-024429cbff31@tutanota.com/ Cc: stable@vger.kernel.org Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2") Fixes: ad85094b293e ("Revert "media: staging: atomisp: Remove driver"") Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit af2dc8b8460c0ecee0b20d608be6f1d0540b690c Author: Josua Mayer Date: Tue Mar 24 13:40:55 2026 +0100 arm64: dts: lx2160a-cex7/lx2162a-sr-som: fix usd-cd & gpio pinmux commit 70008aee892bbb5c2969bbe9e5778fc081b14bd2 upstream. Commit 8a1365c7bbc1 ("arm64: dts: lx2160a: add pinmux and i2c gpio to support bus recovery") introduced pinmux nodes for lx2160 i2c interfaces, allowing runtime change between i2c and gpio functions implementing bus recovery. However, the dynamic configuration area (overwrite MUX) used by the pinctrl-single driver initially reads as zero and does not reflect the actual hardware state set by the Reset Configuration Word (RCW) at power-on. Because multiple groups of pins are configured from a single 32-bit register, the first write from the pinctrl driver unintentionally clears all other bits to zero. For example, on the LX2162A Clearfog, RCWSR12 is initialized to 0x08000006. When any i2c pinmux is applied, it clears all other fields. This inadvertently disables SD card-detect (IIC2_PMUX) and some GPIOs (SDHC1_DIR_PMUX): LX2162-CF RCWSR12: 0b0000100000000000 0000000000000110 IIC2_PMUX ||| ||| || | ||| |||XXX : I2C/GPIO/CD-WP SDHC1_DIR_PMUX XXX ||| || | ||| ||| : SDHC/GPIO/SPI Reverting the commit in question was considered but bus recovery is an important feature. Instead add pinmux nodes for those pins that were unintentionally reconfigured on SolidRun LX2160A Clearfog-CX and LX2162A Clearfog boards. Fixes: 8a1365c7bbc1 ("arm64: dts: lx2160a: add pinmux and i2c gpio to support bus recovery") Cc: stable@vger.kernel.org Signed-off-by: Josua Mayer Signed-off-by: Frank Li Signed-off-by: Greg Kroah-Hartman commit 72972aba49dfc48cc4672247d0168402d5bd605b Author: Johan Hovold Date: Thu Apr 9 14:04:03 2026 +0200 spi: atmel: fix controller deregistration commit 8d4de97e83520be89d0ff40610ca633b3963a7de upstream. Make sure to deregister the controller before disabling underlying resources like clocks during driver unbind. Fixes: 754ce4f29937 ("[PATCH] SPI: atmel_spi driver") Cc: stable@vger.kernel.org # 2.6.21 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260409120419.388546-5-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c66a6f226a5f33c2fbd6ef9c29ddbd5088fbb86d Author: Johan Hovold Date: Thu Apr 9 14:04:04 2026 +0200 spi: bcm63xx: fix controller deregistration commit c39e65a4e3b8e764efed0b2f5152a1a8547b80fd upstream. Make sure to deregister the controller before disabling underlying resources like clocks during driver unbind. Fixes: b42dfed83d95 ("spi: add Broadcom BCM63xx SPI controller driver") Cc: stable@vger.kernel.org # 3.4 Cc: Florian Fainelli Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260409120419.388546-6-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 7fbb3b4bef023903e66138c25b205b47be19612b Author: Matthew Brost Date: Fri Jan 30 11:49:27 2026 -0800 drm/gpusvm: Force unmapping on error in drm_gpusvm_get_pages commit 556dba95473900073a6c03121361c11f646dc551 upstream. drm_gpusvm_get_pages() only sets the local flags prior to committing the pages. If an error occurs mid-mapping, has_dma_mapping will be clear, causing the unmap function to skip unmapping pages that were successfully mapped before the error. Fix this by forcibly setting has_dma_mapping in the error path to ensure all previously mapped pages are properly unmapped. Fixes: 99624bdff867 ("drm/gpusvm: Add support for GPU Shared Virtual Memory") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost Reviewed-by: Francois Dugast Link: https://patch.msgid.link/20260130194928.3255613-2-matthew.brost@intel.com Signed-off-by: Greg Kroah-Hartman commit ea28b33e1b15bae5d0a81b947d7039e4c3e7cdfc Author: Ziyi Guo Date: Sat Jan 31 22:19:07 2026 +0000 media: chips-media: wave5: add missing spinlock protection for handle_dynamic_resolution_change() commit cb8bdd3ffca280d014311ab395651d33f58a8708 upstream. Add spin_lock_irqsave()/spin_unlock_irqrestore() around the handle_dynamic_resolution_change() call in initialize_sequence() to fix the missing lock protection. initialize_sequence() calls handle_dynamic_resolution_change() without holding inst->state_spinlock. However, handle_dynamic_resolution_change() has lockdep_assert_held(&inst->state_spinlock) indicating that callers must hold this lock. Other callers of handle_dynamic_resolution_change() properly acquire the spinlock: - wave5_vpu_dec_finish_decode() - wave5_vpu_dec_device_run() Signed-off-by: Ziyi Guo Reviewed-by: Nicolas Dufresne Fixes: 9707a6254a8a6b ("media: chips-media: wave5: Add the v4l2 layer") Cc: stable@vger.kernel.org Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit d71fc6874fce3b859f583968cfc42bf2c425ee4b Author: Ziyi Guo Date: Sat Jan 31 22:03:23 2026 +0000 media: chips-media: wave5: add missing spinlock protection for send_eos_event() commit f48050436746be75227fbc90066a8658cbe94d17 upstream. Add spin_lock_irqsave()/spin_unlock_irqrestore() around send_eos_event() calls in the VB2 buffer queue and streamoff callbacks to fix the missing lock protection. wave5_vpu_dec_buf_queue_dst() and streamoff_output() call send_eos_event() without holding inst->state_spinlock. However, send_eos_event() has lockdep_assert_held(&inst->state_spinlock) indicating that callers must hold this lock. Other callers of send_eos_event() properly acquire the spinlock: - wave5_vpu_dec_finish_decode() acquires lock at line 431 - wave5_vpu_dec_encoder_cmd() acquires lock at line 821 - wave5_vpu_dec_device_run() acquires lock at line 1592 Signed-off-by: Ziyi Guo Reviewed-by: Nicolas Dufresne Fixes: 9707a6254a8a6b ("media: chips-media: wave5: Add the v4l2 layer") Cc: stable@vger.kernel.org Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit b40ec65e092647203b1d240496a15a030d083670 Author: Haoxiang Li Date: Sun Jan 25 22:19:15 2026 +0800 media: chips-media: wave5: fix a potential memory leak in wave5_vdi_init() commit 95bd174a453f77b09ea66e1e22834680754ba501 upstream. Add wave5_vdi_free_dma_memory() in the error path of wave5_vdi_init() to prevent a potential memory leak. Fixes: 45d1a2b93277 ("media: chips-media: wave5: Add vpuapi layer") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 6261d5fd172b86ff331f9cd79d8113165bffc1dd Author: Cristian Ciocaltea Date: Wed Mar 4 23:00:40 2026 +0200 media: dt-bindings: rockchip,vdec: Mark reg-names required for RK35{76,88} commit a11db8d8b403eba1f82728f440727128e9997edd upstream. The Rockchip Video Decoder driver expects reg-names to be mandatory for RK3576 and RK3588 SoCs, however the binding does not currently require the use of them. As a consequence, driver would fail to probe with a hypothetical devicetree that doesn't provide the reg-names for these SoCs, but which is otherwise a perfectly valid DT from the binding perspective. Update the binding and make reg-names required for the aforementioned SoCs. While this change introduces an ABI break, the expected impact on potential users would be minimal, if any, since the old SoCs are unaffected, while the video decoder support for these newer variants in mainline driver and devicetrees hasn't been released yet. Moreover, this is also a prerequisite for a subsequent binding update introducing an alternative reg-names order, according to the address-based listing in the vendor's datasheet. Reported-by: Conor Dooley Closes: https://lore.kernel.org/all/20260227-urologist-gratitude-7984733f2d41@spud/ Fixes: c6ffb7e1fb90 ("media: dt-bindings: rockchip: Document RK3588 Video Decoder bindings") Fixes: a5c4a6526476 ("media: dt-bindings: rockchip: Add RK3576 Video Decoder bindings") Cc: stable@vger.kernel.org Signed-off-by: Cristian Ciocaltea Acked-by: Conor Dooley Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 361e66fb431d905f9ec754f40ccff982fb5e90ed Author: Cristian Ciocaltea Date: Wed Mar 4 23:00:41 2026 +0200 media: dt-bindings: rockchip,vdec: Add alternative reg-names order for RK35{76,88} commit 35c8178ed2bd9821a75a406d762b2f2e161f9c70 upstream. With the introduction of the RK3588 SoC, and RK3576 afterwards, three register blocks have been provided for the video decoder unit instead of just one, which are further referenced in 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. However, while documenting RK3588, the binding broke the convention expecting the unit address to indicate the start of the primary register range, i.e. the 'function' block got listed before the 'link' one. Since the binding changes have been already released and a fix would bring up an ABI break, mark the current 'reg-names' ordering as deprecated and introduce an alternative 'link,function,cache' listing which follows the address-based ordering according to the TRM. Additionally, drop the 'reg' description items as the order is not fixed anymore, while the information they offer is not very relevant anyway. It's worth noting there are currently no (known) users impacted by these binding changes, since the video decoder support for the aforementioned SoCs in mainline driver and devicetrees hasn't been released yet - it landed in v7.0-rc1 while all DTS updates resulting from this will be handled before v7.0 is out. Fixes: c6ffb7e1fb90 ("media: dt-bindings: rockchip: Document RK3588 Video Decoder bindings") Fixes: a5c4a6526476 ("media: dt-bindings: rockchip: Add RK3576 Video Decoder bindings") Cc: stable@vger.kernel.org Reviewed-by: Nicolas Dufresne Reviewed-by: Krzysztof Kozlowski Signed-off-by: Cristian Ciocaltea Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 791598484fd558bb426ef5e051effa5c227d5390 Author: Alexander Koskovich Date: Thu Mar 12 17:16:20 2026 +0000 media: i2c: ov8856: free control handler on error in ov8856_init_controls() commit f75e160745663ce9b13362ae6e90bd439c58df69 upstream. The control handler wasn't freed if adding controls failed, add an error exit label and convert the existing error return to use it. Fixes: 879347f0c258 ("media: ov8856: Add support for OV8856 sensor") Cc: stable@vger.kernel.org Signed-off-by: Alexander Koskovich Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit b6e5c80cc2b216e78924316bfe1191970309730c Author: Tomi Valkeinen Date: Tue Jan 27 10:56:12 2026 +0200 media: renesas: vin: Fix RAW8 (again) commit 40c6da8a9c0f897f99a439330584d93ca7d41226 upstream. Commit e7376745ad5c ("media: rcar-vin: Fix stride setting for RAW8 formats") removed dividing the stride by two for RAW8 formats. It is unclear how this was tested, but in any of the recent tests this does not seem to work and produces quite distorted images. However, reverting the patch fixes the issues only partially. VNIS_REG requires alignment to 16 bytes, and when dividing the stride by 2, in some cases we end up with a non-aligned stride, producing a tilted image. This issue has to be fixed in rvin_format_bytesperline() where we do the alignment for bytesperline. Adding back the stride division and increasing the alignment for RAW8 formats to 0x20 fixes the problems related to RAW8. Fixes: e7376745ad5c ("media: rcar-vin: Fix stride setting for RAW8 formats") Cc: stable@vger.kernel.org Signed-off-by: Tomi Valkeinen Reviewed-by: Niklas Söderlund Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit bfb2081ba00afbbd15a5ed1ed1acdc3edeea5a98 Author: Tomi Valkeinen Date: Thu Jan 15 11:22:35 2026 +0200 media: renesas: vsp1: Fix NULL pointer deref on module unload commit 58b1e9664d8f74d55d8411cc7a7b275a76a6f24f upstream. When unloading the module on gen 4, we hit a NULL pointer dereference. This is caused by the cleanup code calling vsp1_drm_cleanup() where it should be calling vsp1_vspx_cleanup(). Fix this by checking the IP version and calling the drm or vspx function accordingly, the same way as the init code does. Fixes: d06c1a9f348d ("media: vsp1: Add VSPX support") Cc: stable@vger.kernel.org Signed-off-by: Tomi Valkeinen Reviewed-by: Kieran Bingham Reviewed-by: Jacopo Mondi Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 4d6e8496486d7da3d047c8061b24864a6ed6c7b0 Author: Guoniu Zhou Date: Thu Mar 12 11:12:34 2026 +0800 media: nxp: imx8-isi: Reduce minimum queued buffers from 2 to 0 commit 2f38622d0f85f317be9e6b131da6cd511db94fd2 upstream. Fix a hang issue when capturing a single frame with applications like cam in libcamera. It would hang waiting for the driver to complete the buffer, but streaming never starts because min_queued_buffers was set to 2. The ISI module uses a ping-pong buffer mechanism that requires two buffers to be programmed at all times. However, when fewer than 2 user buffers are available, the driver use internal discard buffers to fill the remaining slot(s). Reduce minimum queued buffers from 2 to 0 allows streaming to start without any queued buffers. Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver") Cc: stable@vger.kernel.org Signed-off-by: Guoniu Zhou Reviewed-by: Laurent Pinchart Link: https://patch.msgid.link/20260312-isi_min_buffers-v2-1-d5ea1c79ad81@nxp.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 0ac9ec121d89254bf1812025316439ed62aae71f Author: Krzysztof Kozlowski Date: Wed Mar 11 20:16:21 2026 +0100 drm/msm/hdmi: Fix wrong CTRL1 register used in writing info frames commit 8c6c93b7db42d15c6e8c2540a648d32986a04b1a upstream. Commit 384d2b03d0a1 ("drm/msm/hdmi: make use of the drm_connector_hdmi framework") changed the unconditional register writes in few places to updates: read, apply mask, write. The new code reads REG_HDMI_INFOFRAME_CTRL1 register, applies fields/mask for HDMI_INFOFRAME_CTRL0 register and finally writes to HDMI_INFOFRAME_CTRL0. This difference between CTRL1 and CTRL0 looks unintended and may result in wrong data being written to HDMI bridge registers. Cc: Fixes: 384d2b03d0a1 ("drm/msm/hdmi: make use of the drm_connector_hdmi framework") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/711156/ Link: https://lore.kernel.org/r/20260311191620.245394-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Greg Kroah-Hartman commit 06d99af8db1127fec0a587b654bda1fc2d41f746 Author: Ricardo Ribalda Date: Mon Mar 9 15:01:54 2026 +0000 media: uvcvideo: Enable VB2_DMABUF for metadata stream commit fbac03467e53d8d72e5099c03df26d9adae11416 upstream. The UVC driver has two video streams, one for the frames and another one for the metadata. Both streams share most of the codebase, but only the data stream declares support for DMABUF transfer mode. I have tried the DMABUF transfer mode with CONFIG_DMABUF_HEAPS_SYSTEM and the frames looked correct. This patch announces the support for DMABUF for the metadata stream. This is useful for apps/HALs that only want to support DMABUF. Cc: stable@vger.kernel.org Fixes: 088ead2552458 ("media: uvcvideo: Add a metadata device node") Signed-off-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Reviewed-by: Hans de Goede Link: https://patch.msgid.link/20260309-uvc-metadata-dmabuf-v1-1-fc8b87bd29c5@chromium.org Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 80d8cc29d3b68d65a991c44aedc2f5e5a4e014fe Author: Tomasz Pakuła Date: Sun May 10 14:23:52 2026 +0200 HID: pidff: Fix integer overflow in pidff_rescale commit 48d1677779ad6816978ad4a4f7588aec5ec960fe upstream. Rescaling values close to the max (U16_MAX) temporarily creates values that exceed the s32 range. This caused value overflow in case when, for example, a periodic effect phase was higer than 180 degrees. In turn, rescale function could return values outised of the logical range of the HID field. Fix by using 64 bit signed integer to store the value during calculation but still return only 32 bit integer. Closes: https://github.com/JacKeTUs/universal-pidff/issues/116 Fixes: 224ee88fe395 ("Input: add force feedback driver for PID devices") Cc: stable@vger.kernel.org Signed-off-by: Tomasz Pakuła Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 5c0830323689ef15224f0025276176988861b3b0 Author: Sangyun Kim Date: Mon Apr 20 14:13:18 2026 +0900 HID: appletb-kbd: run inactivity autodim from workqueues commit 1654e53349d4e657b331de354313461f401f5063 upstream. The autodim code in hid-appletb-kbd takes backlight_device->ops_lock via backlight_device_set_brightness() -> mutex_lock() from two different atomic contexts: * appletb_inactivity_timer() is a struct timer_list callback, so it runs in softirq context. Every expiry triggers BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591 Call Trace: __might_resched __mutex_lock backlight_device_set_brightness appletb_inactivity_timer call_timer_fn run_timer_softirq * reset_inactivity_timer() is called from appletb_kbd_hid_event() and appletb_kbd_inp_event(). On real USB hardware these run in softirq/IRQ context (URB completion and input-event dispatch). When the Touch Bar has already been dimmed or turned off, the reset path calls backlight_device_set_brightness() directly to restore brightness, producing the same warning. Both call sites hit the same mutex_lock()-from-atomic bug. Fix them together by moving the blocking work onto the system workqueue: * Convert the inactivity timer from struct timer_list to struct delayed_work; the callback (appletb_inactivity_work) now runs in process context where mutex_lock() is legal. * Add a dedicated struct work_struct restore_brightness_work and have reset_inactivity_timer() schedule it instead of calling backlight_device_set_brightness() directly. Cancel both works synchronously during driver tear-down alongside the existing backlight reference drop. The semantics are unchanged (same delays, same state transitions on dim, turn-off and user activity); only the execution context of the sleeping call changes. The timer field and callback are renamed to match their new type; reset_inactivity_timer() keeps its name because it is invoked from input event paths that read naturally as "reset the inactivity timer". Fixes: 93a0fc489481 ("HID: hid-appletb-kbd: add support for automatic brightness control while using the touchbar") Cc: stable@vger.kernel.org Signed-off-by: Sangyun Kim Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 59a79938ca5541fe55d675304116b7ea684afef0 Author: Sangyun Kim Date: Mon Apr 20 14:13:17 2026 +0900 HID: appletb-kbd: fix UAF in inactivity-timer cleanup path commit 4db2af929279c799b5653a39eb0795c72baffca4 upstream. Commit 38224c472a03 ("HID: appletb-kbd: fix slab use-after-free bug in appletb_kbd_probe") added timer_delete_sync(&kbd->inactivity_timer) to both the probe close_hw error path and appletb_kbd_remove(), but the way it was wired in left the inactivity timer reachable during driver tear-down via two distinct windows. Window A -- put_device() before timer_delete_sync(): put_device(&kbd->backlight_dev->dev); timer_delete_sync(&kbd->inactivity_timer); The inactivity_timer softirq reads kbd->backlight_dev and calls backlight_device_set_brightness() -> mutex_lock(&ops_lock). If a concurrent hid_appletb_bl unbind drops the last devm reference between these two calls, the backlight_device is freed and the mutex_lock() touches freed memory. Window B -- backlight cleanup before hid_hw_stop(): if (kbd->backlight_dev) { timer_delete_sync(...); put_device(...); } hid_hw_close(hdev); hid_hw_stop(hdev); Even after Window A is closed, hid_hw_close()/hid_hw_stop() still run afterwards, so a late ".event" callback from the HID core (USB URB completion on real Apple hardware) can arrive after timer_delete_sync() drained the softirq but before put_device() drops the reference. That callback reaches reset_inactivity_timer(), which calls mod_timer() and re-arms the timer. The freshly re-armed timer can then fire on the about-to-be-freed backlight_device. Both windows produce the same KASAN slab-use-after-free: BUG: KASAN: slab-use-after-free in __mutex_lock+0x1aab/0x21c0 Read of size 8 at addr ffff88803ee9a108 by task swapper/0/0 Call Trace: __mutex_lock backlight_device_set_brightness appletb_inactivity_timer call_timer_fn run_timer_softirq handle_softirqs Allocated by task N: devm_backlight_device_register appletb_bl_probe Freed by task M: (concurrent hid_appletb_bl unbind path) Close both windows at once by reworking the tear-down in appletb_kbd_remove() and in the probe close_hw error path so that 1) hid_hw_close()/hid_hw_stop() run before the backlight cleanup, guaranteeing no further .event callback can fire and re-arm the timer, and 2) inside the "if (kbd->backlight_dev)" block, timer_delete_sync() runs before put_device(), so the softirq is drained before the final reference is dropped. Fixes: 38224c472a03 ("HID: appletb-kbd: fix slab use-after-free bug in appletb_kbd_probe") Cc: stable@vger.kernel.org Signed-off-by: Sangyun Kim Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 7812694752a5f295eaa05a093b90a2c332666051 Author: T.J. Mercier Date: Fri Apr 17 08:47:02 2026 -0700 HID: playstation: Clamp num_touch_reports commit cac61b58a3b6340c52afa06bb15eac033158db2f upstream. A device would never lie about the number of touch reports would it? If it does the loop in dualshock4_parse_report will read off the end of the touch_reports array, up to about 2 KiB for the maximum number of 256 loop iteraions. The data that is read is emitted via evdev if the DS4_TOUCH_POINT_INACTIVE bit happens to be set. Protect against this by clamping the num_touch_reports value provided by the device to the maximum size of the touch_reports array. Fixes: 752038248808 ("HID: playstation: add DualShock4 touchpad support.") Cc: stable@vger.kernel.org Reported-by: Xingyu Jin Signed-off-by: T.J. Mercier Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 54defdf30fa99cd31133bfd7842946a827b5435a Author: Alexandre Frade Date: Sat May 16 06:44:33 2026 +0000 Linux 6.18.31-xanmod1 Signed-off-by: Alexandre Frade commit 24227aa5ae2d4bd2c5e661fe4aff0dcdb00ac5b8 Merge: 5e00669328ba 6c1de6e6aa8c Author: Alexandre Frade Date: Sat May 16 06:43:42 2026 +0000 Merge tag 'v6.18.31' into 6.18 This is the 6.18.31 stable release commit 6c1de6e6aa8cf45b3b3dba510ad0f72df7c61618 Author: Greg Kroah-Hartman Date: Fri May 15 14:52:18 2026 +0200 Linux 6.18.31 Signed-off-by: Greg Kroah-Hartman commit 2a93a4fac7b6051d3be7cd1b015fe7320cd0404d Author: Linus Torvalds Date: Wed May 13 11:37:18 2026 -0700 ptrace: slightly saner 'get_dumpable()' logic commit 31e62c2ebbfdc3fe3dbdf5e02c92a9dc67087a3a upstream. The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional "drop capabilities" model doesn't make any difference for this all. Make it all make a *bit* more sense by saying that if you don't have a MM pointer, we'll use a cached "last dumpability" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override. Reported-by: Qualys Security Advisory Cc: Oleg Nesterov Cc: Kees Cook Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5e00669328ba4c3c9a649f6b75a1a6a2d2f0ae2f Author: Alexandre Frade Date: Thu May 14 19:24:23 2026 +0000 Linux 6.18.30-xanmod1 Signed-off-by: Alexandre Frade commit 7fc23a0d268bb6f6f59b672c7210593a87a9dc67 Merge: 3c8a7708d26d 52dc660c85db Author: Alexandre Frade Date: Thu May 14 19:23:28 2026 +0000 Merge tag 'v6.18.30' into 6.18 This is the 6.18.30 stable release commit 52dc660c85dbab60c07c8f1a716d68a4b7d4fc7e Author: Greg Kroah-Hartman Date: Thu May 14 15:30:26 2026 +0200 Linux 6.18.30 Link: https://lore.kernel.org/r/20260512173938.452574370@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Peter Schneider Tested-by: Brett A C Sheffield Tested-by: Mark Brown Tested-by: Shuah Khan Link: https://lore.kernel.org/r/20260513153744.746440810@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Florian Fainelli Tested-by: Ron Economos Tested-by: Mark Brown Tested-by: Barry K. Nathan Tested-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 1aa60fea7f637c071f529ad6784aecca2f2f0c5f Author: Shota Zaizen Date: Tue Apr 28 19:02:55 2026 +0900 ksmbd: validate inherited ACE SID length commit 996454bc0da84d5a1dedb1a7861823087e01a7ae upstream. smb_inherit_dacl() walks the parent directory DACL loaded from the security descriptor xattr. It verifies that each ACE contains the fixed SID header before using it, but does not verify that the variable-length SID described by sid.num_subauth is fully contained in the ACE. A malformed inheritable ACE can advertise more subauthorities than are present in the ACE. compare_sids() may then read past the ACE. smb_set_ace() also clamps the copied destination SID, but used the unchecked source SID count to compute the inherited ACE size. That could advance the temporary inherited ACE buffer pointer and nt_size accounting past the allocated buffer. Fix this by validating the parent ACE SID count and SID length before using the SID during inheritance. Compute the inherited ACE size from the copied SID so the size matches the bounded destination SID. Reject the inherited DACL if size accumulation would overflow smb_acl.size or the security descriptor allocation size. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Signed-off-by: Shota Zaizen Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 28f5ed477eef166d678d6966762cbc1de9b4f436 Author: Prathyushi Nangia Date: Tue Dec 9 10:01:33 2025 -0600 x86/CPU/AMD: Prevent improper isolation of shared resources in Zen2's op cache commit c21b90f77687075115d989e53a8ec5e2bb427ab1 upstream. Make sure resources are not improperly shared in the op cache and cause instruction corruption this way. Signed-off-by: Prathyushi Nangia Co-developed-by: Borislav Petkov (AMD) Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a0e560d15ff1ce403a0eda17f25a1ee0c086794c Author: Gary Guo Date: Tue May 12 16:02:57 2026 +0100 rust: pin-init: fix incorrect accessor reference lifetime commit 68bf102226cf2199dc609b67c1e847cad4de4b57 upstream When a field has been initialized, `init!`/`pin_init!` create a reference or pinned reference to the field so it can be accessed later during the initialization of other fields. However, the reference it created is incorrectly `&'static` rather than just the scope of the initializer. This means that you can do init!(Foo { a: 1, _: { let b: &'static u32 = a; } }) which is unsound. This is caused by `&mut (*$slot).$ident`, which actually allows arbitrary lifetime, so this is effectively `'static`. Fix it by adding `let_binding` method on `DropGuard` to shorten lifetime. This results in exactly what we want for these accessors. The safety and invariant comments of `DropGuard` have been reworked; instead of reasoning about what caller can do with the guard, express it in a way that the ownership is transferred to the guard and `forget` takes it back, so the unsafe operations within the `DropGuard` can be more easily justified. Assisted-by: Claude:claude-3-opus Signed-off-by: Gary Guo Signed-off-by: Greg Kroah-Hartman commit 4af2e62cbcda575a174acd230c3f3a208135e16d Author: Sam Edwards Date: Sun May 10 09:54:16 2026 -0400 net: stmmac: Prevent NULL deref when RX memory exhausted [ Upstream commit 0bb05e6adfa99a2ea1fee1125cc0953409f83ed8 ] The CPU receives frames from the MAC through conventional DMA: the CPU allocates buffers for the MAC, then the MAC fills them and returns ownership to the CPU. For each hardware RX queue, the CPU and MAC coordinate through a shared ring array of DMA descriptors: one descriptor per DMA buffer. Each descriptor includes the buffer's physical address and a status flag ("OWN") indicating which side owns the buffer: OWN=0 for CPU, OWN=1 for MAC. The CPU is only allowed to set the flag and the MAC is only allowed to clear it, and both must move through the ring in sequence: thus the ring is used for both "submissions" and "completions." In the stmmac driver, stmmac_rx() bookmarks its position in the ring with the `cur_rx` index. The main receive loop in that function checks for rx_descs[cur_rx].own=0, gives the corresponding buffer to the network stack (NULLing the pointer), and increments `cur_rx` modulo the ring size. After the loop exits, stmmac_rx_refill(), which bookmarks its position with `dirty_rx`, allocates fresh buffers and rearms the descriptors (setting OWN=1). If it fails any allocation, it simply stops early (leaving OWN=0) and will retry where it left off when next called. This means descriptors have a three-stage lifecycle (terms my own): - `empty` (OWN=1, buffer valid) - `full` (OWN=0, buffer valid and populated) - `dirty` (OWN=0, buffer NULL) But because stmmac_rx() only checks OWN, it confuses `full`/`dirty`. In the past (see 'Fixes:'), there was a bug where the loop could cycle `cur_rx` all the way back to the first descriptor it dirtied, resulting in a NULL dereference when mistaken for `full`. The aforementioned commit resolved that *specific* failure by capping the loop's iteration limit at `dma_rx_size - 1`, but this is only a partial fix: if the previous stmmac_rx_refill() didn't complete, then there are leftover `dirty` descriptors that the loop might encounter without needing to cycle fully around. The current code therefore panics (see 'Closes:') when stmmac_rx_refill() is memory-starved long enough for `cur_rx` to catch up to `dirty_rx`. Fix this by explicitly checking, before advancing `cur_rx`, if the next entry is dirty; exit the loop if so. This prevents processing of the final, used descriptor until stmmac_rx_refill() succeeds, but fully prevents the `cur_rx == dirty_rx` ambiguity as the previous bugfix intended: so remove the clamp as well. Since stmmac_rx_zc() is a copy-paste-and-tweak of stmmac_rx() and the code structure is identical, any fix to stmmac_rx() will also need a corresponding fix for stmmac_rx_zc(). Therefore, apply the same check there. In stmmac_rx() (not stmmac_rx_zc()), a related bug remains: after the MAC sets OWN=0 on the final descriptor, it will be unable to send any further DMA-complete IRQs until it's given more `empty` descriptors. Currently, the driver simply *hopes* that the next stmmac_rx_refill() succeeds, risking an indefinite stall of the receive process if not. But this is not a regression, so it can be addressed in a future change. Fixes: b6cb4541853c7 ("net: stmmac: avoid rx queue overrun") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221010 Cc: stable@vger.kernel.org Suggested-by: Russell King Signed-off-by: Sam Edwards Link: https://patch.msgid.link/20260422044503.5349-1-CFSworks@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9d1774b33e1083012cc5f938c6428dae935b0607 Author: Russell King (Oracle) Date: Sun May 10 09:54:15 2026 -0400 net: stmmac: rename STMMAC_GET_ENTRY() -> STMMAC_NEXT_ENTRY() [ Upstream commit 6b4286e0550814cdc4b897f881ec1fa8b0313227 ] STMMAC_GET_ENTRY() doesn't describe what this macro is doing - it is incrementing the provided index for the circular array of descriptors. Replace "GET" with "NEXT" as this better describes the action here. Signed-off-by: Russell King (Oracle) Link: https://patch.msgid.link/E1w2vba-0000000DbWo-1oL5@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski Stable-dep-of: 0bb05e6adfa9 ("net: stmmac: Prevent NULL deref when RX memory exhausted") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5cffe3c136891aa4d579bf5c079a68f7cb371b0c Author: Thorsten Blum Date: Sat May 9 17:29:57 2026 -0400 crypto: caam - guard HMAC key hex dumps in hash_digest_key [ Upstream commit 177730a273b18e195263ed953853273e901b5064 ] Use print_hex_dump_devel() for dumping sensitive HMAC key bytes in hash_digest_key() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled. Fixes: 045e36780f11 ("crypto: caam - ahash hmac support") Fixes: 3f16f6c9d632 ("crypto: caam/qi2 - add support for ahash algorithms") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ef63ef44e86c64a3c1260c2b67b122d9f82e315e Author: Thorsten Blum Date: Sat May 9 17:29:56 2026 -0400 printk: add print_hex_dump_devel() [ Upstream commit d134feeb5df33fbf77f482f52a366a44642dba09 ] Add print_hex_dump_devel() as the hex dump equivalent of pr_devel(), which emits output only when DEBUG is enabled, but keeps call sites compiled otherwise. Suggested-by: Herbert Xu Signed-off-by: Thorsten Blum Reviewed-by: John Ogness Signed-off-by: Herbert Xu Stable-dep-of: 177730a273b1 ("crypto: caam - guard HMAC key hex dumps in hash_digest_key") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c9ce18e6bb2c467ec85756dc7989b547b7584fee Author: Junrui Luo Date: Fri May 8 23:22:29 2026 -0400 erofs: fix unsigned underflow in z_erofs_lz4_handle_overlap() [ Upstream commit 21e161de2dc660b1bb70ef5b156ab8e6e1cca3ab ] Some crafted images can have illegal (!partial_decoding && m_llen < m_plen) extents, and the LZ4 inplace decompression path can be wrongly hit, but it cannot handle (outpages < inpages) properly: "outpages - inpages" wraps to a large value and the subsequent rq->out[] access reads past the decompressed_pages array. However, such crafted cases can correctly result in a corruption report in the normal LZ4 non-inplace path. Let's add an additional check to fix this for backporting. Reproducible image (base64-encoded gzipped blob): H4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+g dilSJo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9i PNtbjhan04/9GtX4qVYc814WDqt6FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz 2DF/21+20T/ldgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1w ywAAAAAAAADwu14ATsEYtgBQAAA= $ mount -t erofs -o cache_strategy=disabled foo.erofs /mnt $ dd if=/mnt/data of=/dev/null bs=4096 count=1 Fixes: 598162d05080 ("erofs: support decompress big pcluster for lz4 backend") Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Reviewed-by: Gao Xiang Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 24da4cc6bf27bca15770bcbb15a84adb550fafd6 Author: Gao Xiang Date: Fri May 8 23:22:28 2026 -0400 erofs: tidy up z_erofs_lz4_handle_overlap() [ Upstream commit 9ae77198d4815c63fc8ebacc659c71d150d1e51b ] - Add some useful comments to explain inplace I/Os and decompression; - Rearrange the code to get rid of one unnecessary goto. Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Stable-dep-of: 21e161de2dc6 ("erofs: fix unsigned underflow in z_erofs_lz4_handle_overlap()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d309d3308de658d87c42d97e044c89a226327526 Author: Zilin Guan Date: Fri May 8 20:35:34 2026 -0400 hfsplus: fix held lock freed on hfsplus_fill_super() [ Upstream commit 90c500e4fd83fa33c09bc7ee23b6d9cc487ac733 ] hfsplus_fill_super() calls hfs_find_init() to initialize a search structure, which acquires tree->tree_lock. If the subsequent call to hfsplus_cat_build_key() fails, the function jumps to the out_put_root error label without releasing the lock. The later cleanup path then frees the tree data structure with the lock still held, triggering a held lock freed warning. Fix this by adding the missing hfs_find_exit(&fd) call before jumping to the out_put_root error label. This ensures that tree->tree_lock is properly released on the error path. 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 specifically designed to detect memory management issues. It is currently under active development and not yet publicly available. We confirmed the bug by runtime testing under QEMU with x86_64 defconfig, lockdep enabled, and CONFIG_HFSPLUS_FS=y. To trigger the error path, we used GDB to dynamically shrink the max_unistr_len parameter to 1 before hfsplus_asc2uni() is called. This forces hfsplus_asc2uni() to naturally return -ENAMETOOLONG, which propagates to hfsplus_cat_build_key() and exercises the faulty error path. The following warning was observed during mount: ========================= WARNING: held lock freed! 7.0.0-rc3-00016-gb4f0dd314b39 #4 Not tainted ------------------------- mount/174 is freeing memory ffff888103f92000-ffff888103f92fff, with a lock still held there! ffff888103f920b0 (&tree->tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0 2 locks held by mount/174: #0: ffff888103f960e0 (&type->s_umount_key#42/1){+.+.}-{4:4}, at: alloc_super.constprop.0+0x167/0xa40 #1: ffff888103f920b0 (&tree->tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0 stack backtrace: CPU: 2 UID: 0 PID: 174 Comm: mount Not tainted 7.0.0-rc3-00016-gb4f0dd314b39 #4 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x82/0xd0 debug_check_no_locks_freed+0x13a/0x180 kfree+0x16b/0x510 ? hfsplus_fill_super+0xcb4/0x18a0 hfsplus_fill_super+0xcb4/0x18a0 ? __pfx_hfsplus_fill_super+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? bdev_open+0x65f/0xc30 ? srso_return_thunk+0x5/0x5f ? pointer+0x4ce/0xbf0 ? trace_contention_end+0x11c/0x150 ? __pfx_pointer+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? bdev_open+0x79b/0xc30 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? vsnprintf+0x6da/0x1270 ? srso_return_thunk+0x5/0x5f ? __mutex_unlock_slowpath+0x157/0x740 ? __pfx_vsnprintf+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? mark_held_locks+0x49/0x80 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? irqentry_exit+0x17b/0x5e0 ? trace_irq_disable.constprop.0+0x116/0x150 ? __pfx_hfsplus_fill_super+0x10/0x10 ? __pfx_hfsplus_fill_super+0x10/0x10 get_tree_bdev_flags+0x302/0x580 ? __pfx_get_tree_bdev_flags+0x10/0x10 ? vfs_parse_fs_qstr+0x129/0x1a0 ? __pfx_vfs_parse_fs_qstr+0x3/0x10 vfs_get_tree+0x89/0x320 fc_mount+0x10/0x1d0 path_mount+0x5c5/0x21c0 ? __pfx_path_mount+0x10/0x10 ? trace_irq_enable.constprop.0+0x116/0x150 ? trace_irq_enable.constprop.0+0x116/0x150 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? kmem_cache_free+0x307/0x540 ? user_path_at+0x51/0x60 ? __x64_sys_mount+0x212/0x280 ? srso_return_thunk+0x5/0x5f __x64_sys_mount+0x212/0x280 ? __pfx___x64_sys_mount+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? trace_irq_enable.constprop.0+0x116/0x150 ? srso_return_thunk+0x5/0x5f do_syscall_64+0x111/0x680 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ffacad55eae Code: 48 8b 0d 85 1f 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 8 RSP: 002b:00007fff1ab55718 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffacad55eae RDX: 000055740c64e5b0 RSI: 000055740c64e630 RDI: 000055740c651ab0 RBP: 000055740c64e380 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000055740c64e5b0 R14: 000055740c651ab0 R15: 000055740c64e380 After applying this patch, the warning no longer appears. Fixes: 89ac9b4d3d1a ("hfsplus: fix longname handling") CC: stable@vger.kernel.org Signed-off-by: Zilin Guan Reviewed-by: Viacheslav Dubeyko Tested-by: Viacheslav Dubeyko Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a420904450962a562ad053a41a53a27755021b48 Author: Deepanshu Kartikey Date: Fri May 8 20:35:33 2026 -0400 hfsplus: fix uninit-value by validating catalog record size [ Upstream commit b6b592275aeff184aa82fcf6abccd833fb71b393 ] Syzbot reported a KMSAN uninit-value issue in hfsplus_strcasecmp(). The root cause is that hfs_brec_read() doesn't validate that the on-disk record size matches the expected size for the record type being read. When mounting a corrupted filesystem, hfs_brec_read() may read less data than expected. For example, when reading a catalog thread record, the debug output showed: HFSPLUS_BREC_READ: rec_len=520, fd->entrylength=26 HFSPLUS_BREC_READ: WARNING - entrylength (26) < rec_len (520) - PARTIAL READ! hfs_brec_read() only validates that entrylength is not greater than the buffer size, but doesn't check if it's less than expected. It successfully reads 26 bytes into a 520-byte structure and returns success, leaving 494 bytes uninitialized. This uninitialized data in tmp.thread.nodeName then gets copied by hfsplus_cat_build_key_uni() and used by hfsplus_strcasecmp(), triggering the KMSAN warning when the uninitialized bytes are used as array indices in case_fold(). Fix by introducing hfsplus_brec_read_cat() wrapper that: 1. Calls hfs_brec_read() to read the data 2. Validates the record size based on the type field: - Fixed size for folder and file records - Variable size for thread records (depends on string length) 3. Returns -EIO if size doesn't match expected For thread records, check against HFSPLUS_MIN_THREAD_SZ before reading nodeName.length to avoid reading uninitialized data at call sites that don't zero-initialize the entry structure. Also initialize the tmp variable in hfsplus_find_cat() as defensive programming to ensure no uninitialized data even if validation is bypassed. Reported-by: syzbot+d80abb5b890d39261e72@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d80abb5b890d39261e72 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Tested-by: syzbot+d80abb5b890d39261e72@syzkaller.appspotmail.com Reviewed-by: Viacheslav Dubeyko Tested-by: Viacheslav Dubeyko Suggested-by: Charalampos Mitrodimas Link: https://lore.kernel.org/all/20260120051114.1281285-1-kartikey406@gmail.com/ [v1] Link: https://lore.kernel.org/all/20260121063109.1830263-1-kartikey406@gmail.com/ [v2] Link: https://lore.kernel.org/all/20260212014233.2422046-1-kartikey406@gmail.com/ [v3] Link: https://lore.kernel.org/all/20260214002100.436125-1-kartikey406@gmail.com/T/ [v4] Link: https://lore.kernel.org/all/20260221061626.15853-1-kartikey406@gmail.com/T/ [v5] Signed-off-by: Deepanshu Kartikey Signed-off-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/20260307010302.41547-1-kartikey406@gmail.com Signed-off-by: Viacheslav Dubeyko Stable-dep-of: 90c500e4fd83 ("hfsplus: fix held lock freed on hfsplus_fill_super()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 23b814ec96a86f6687dc6ffa5d105bc86e7c8505 Author: Krzysztof Kozlowski Date: Fri May 8 10:52:59 2026 -0400 firmware: exynos-acpm: Drop fake 'const' on handle pointer [ Upstream commit a2be37eedb52ea26938fa4cc9de1ff84963c57ad ] All the functions operating on the 'handle' pointer are claiming it is a pointer to const thus they should not modify the handle. In fact that's a false statement, because first thing these functions do is drop the cast to const with container_of: struct acpm_info *acpm = handle_to_acpm_info(handle); And with such cast the handle is easily writable with simple: acpm->handle.ops.pmic_ops.read_reg = NULL; The code is not correct logically, either, because functions like acpm_get_by_node() and acpm_handle_put() are meant to modify the handle reference counting, thus they must modify the handle. Modification here happens anyway, even if the reference counting is stored in the container which the handle is part of. The code does not have actual visible bug, but incorrect 'const' annotations could lead to incorrect compiler decisions. Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20260224104203.42950-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Krzysztof Kozlowski [ dropped hunks for DVFS/clk-acpm files and `acpm_dvfs_ops` struct that don't exist in 6.18 ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bbcef208c5da076d8316a07b44c5ecd3a6e23eff Author: Kairui Song Date: Fri May 8 17:17:56 2026 -0400 mm, swap: speed up hibernation allocation and writeout [ Upstream commit 396f57b5720024638dbb503f6a4abd988a49d815 ] Since commit 0ff67f990bd4 ("mm, swap: remove swap slot cache"), hibernation has been using the swap slot slow allocation path for simplification, which turns out might cause regression for some devices because the allocator now rotates clusters too often, leading to slower allocation and more random distribution of data. Fast allocation is not complex, so implement hibernation support as well. Test result with Samsung SSD 830 Series (SATA II, 3.0 Gbps) shows the performance is several times better [1]: 6.19: 324 seconds After this series: 35 seconds Link: https://lkml.kernel.org/r/20260216-hibernate-perf-v4-1-1ba9f0bf1ec9@tencent.com Link: https://lore.kernel.org/linux-mm/8b4bdcfa-ce3f-4e23-839f-31367df7c18f@gmx.de/ [1] Signed-off-by: Kairui Song Fixes: 0ff67f990bd4 ("mm, swap: remove swap slot cache") Reported-by: Carsten Grohmann Closes: https://lore.kernel.org/linux-mm/20260206121151.dea3633d1f0ded7bbf49c22e@linux-foundation.org/ Cc: Baoquan He Cc: Barry Song Cc: Chris Li Cc: Kemeng Shi Cc: Nhat Pham Cc: Signed-off-by: Andrew Morton [ adjusted helper signatures ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4d7b42941c9be046a65a994012c9aafcb9b48d32 Author: Suman Kumar Chakraborty Date: Tue May 5 06:33:30 2026 -0400 crypto: qat - fix firmware loading failure for GEN6 devices [ Upstream commit e7dcb722bb75bb3f3992f580a8728a794732fd7a ] QAT GEN6 hardware requires a minimum 3 us delay during the acceleration engine reset sequence to ensure the hardware fully settles. Without this delay, the firmware load may fail intermittently. Add a delay after placing the AE into reset and before clearing the reset, matching the hardware requirements and ensuring stable firmware loading. Earlier generations remain unaffected. Fixes: 17fd7514ae68 ("crypto: qat - add qat_6xxx driver") Signed-off-by: Suman Kumar Chakraborty Cc: stable@vger.kernel.org Reviewed-by: Giovanni Cabiddu Reviewed-by: Andy Shevchenko Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fb6616806f3dec598eb4178faea6d506db3317c5 Author: Suman Kumar Chakraborty Date: Tue May 5 06:33:29 2026 -0400 crypto: qat - fix indentation of macros in qat_hal.c [ Upstream commit 4963b39e3a3feed07fbf4d5cc2b5df8498888285 ] The macros in qat_hal.c were using a mixture of tabs and spaces. Update all macro indentation to use tabs consistently, matching the predominant style. This does not introduce any functional change. Signed-off-by: Suman Kumar Chakraborty Reviewed-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Stable-dep-of: e7dcb722bb75 ("crypto: qat - fix firmware loading failure for GEN6 devices") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit afece4e3f2cd57bb4eef8c80ea02eeaa900063e2 Author: Luke Wang Date: Tue May 5 06:17:31 2026 -0400 mmc: core: Optimize time for secure erase/trim for some Kingston eMMCs [ Upstream commit d6bf2e64dec87322f2b11565ddb59c0e967f96e3 ] Kingston eMMC IY2964 and IB2932 takes a fixed ~2 seconds for each secure erase/trim operation regardless of size - that is, a single secure erase/trim operation of 1MB takes the same time as 1GB. With default calculated 3.5MB max discard size, secure erase 1GB requires ~300 separate operations taking ~10 minutes total. Add a card quirk, MMC_QUIRK_FIXED_SECURE_ERASE_TRIM_TIME, to set maximum secure erase size for those devices. This allows 1GB secure erase to complete in a single operation, reducing time from 10 minutes to just 2 seconds. Signed-off-by: Luke Wang Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f597ab044bea75601ce00f694d3e12d1476c2d68 Author: Avri Altman Date: Tue May 5 06:17:30 2026 -0400 mmc: core: Add quirk for incorrect manufacturing date [ Upstream commit 263ff314cc5602599d481b0912a381555fcbad28 ] Some eMMC vendors need to report manufacturing dates beyond 2025 but are reluctant to update the EXT_CSD revision from 8 to 9. Changing the Updating the EXT_CSD revision may involve additional testing or qualification steps with customers. To ease this transition and avoid a full re-qualification process, a workaround is needed. This patch introduces a temporary quirk that re-purposes the year codes corresponding to 2010, 2011, and 2012 to represent the years 2026, 2027, and 2028, respectively. This solution is only valid for this three-year period. After 2028, vendors must update their firmware to set EXT_CSD_REV=9 to continue reporting the correct manufacturing date in compliance with the JEDEC standard. The `MMC_QUIRK_BROKEN_MDT` is introduced and enabled for all Sandisk devices to handle this behavior. Signed-off-by: Avri Altman Signed-off-by: Ulf Hansson Stable-dep-of: d6bf2e64dec8 ("mmc: core: Optimize time for secure erase/trim for some Kingston eMMCs") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ebad723082715f6517f3591750c18b91bf45e1c0 Author: Avri Altman Date: Tue May 5 06:17:29 2026 -0400 mmc: core: Adjust MDT beyond 2025 [ Upstream commit 3e487a634bc019166e452ea276f7522710eda9f4 ] JEDEC JESD84-B51B which was released in September 2025, increases the manufacturing year limit for eMMC devices. The eMMC manufacturing year is stored in a 4-bit field in the CID register. Originally, it covered 1997–2012. Later, with EXT_CSD_REV=8, it was extended up to 2025. Now, with EXT_CSD_REV=9, the range is rolled over by another 16 years, up to 2038. The mapping is as follows: cid[8..11] | rev ≤ 4 | 8 ≥ rev > 4 | rev > 8 --------------------------------------------- 0 | 1997 | 2013 | 2029 1 | 1998 | 2014 | 2030 2 | 1999 | 2015 | 2031 3 | 2000 | 2016 | 2032 4 | 2001 | 2017 | 2033 5 | 2002 | 2018 | 2034 6 | 2003 | 2019 | 2035 7 | 2004 | 2020 | 2036 8 | 2005 | 2021 | 2037 9 | 2006 | 2022 | 2038 10 | 2007 | 2023 | 11 | 2008 | 2024 | 12 | 2009 | 2025 | 13 | 2010 | | 2026 14 | 2011 | | 2027 15 | 2012 | | 2028 Signed-off-by: Avri Altman Reviewed-by: Shawn Lin Signed-off-by: Ulf Hansson Stable-dep-of: d6bf2e64dec8 ("mmc: core: Optimize time for secure erase/trim for some Kingston eMMCs") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b0f4711b426a06fb4c4be85c36b9f5588d5140d3 Author: David Carlier Date: Tue May 5 05:49:31 2026 -0400 octeon_ep_vf: add NULL check for napi_build_skb() [ Upstream commit dd66b42854705e4e4ee7f14d260f86c578bed3e3 ] napi_build_skb() can return NULL on allocation failure. In __octep_vf_oq_process_rx(), the result is used directly without a NULL check in both the single-buffer and multi-fragment paths, leading to a NULL pointer dereference. Add NULL checks after both napi_build_skb() calls, properly advancing descriptors and consuming remaining fragments on failure. Fixes: 1cd3b407977c ("octeon_ep_vf: add Tx/Rx processing and interrupt support") Cc: stable@vger.kernel.org Signed-off-by: David Carlier Link: https://patch.msgid.link/20260409184009.930359-3-devnexen@gmail.com Signed-off-by: Jakub Kicinski [ inlined missing octep_vf_oq_next_idx() helper as read_idx++ with wraparound ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1869da3efe703b016b23d4885f3fe6c1751959c6 Author: Thomas Weißschuh Date: Mon May 4 20:15:22 2026 -0400 hwmon: (powerz) Avoid cacheline sharing for DMA buffer [ Upstream commit 3023c050af3600bf451153335dea5e073c9a3088 ] Depending on the architecture the transfer buffer may share a cacheline with the following mutex. As the buffer may be used for DMA, that is problematic. Use the high-level DMA helpers to make sure that cacheline sharing can not happen. Also drop the comment, as the helpers are documentation enough. https://sashiko.dev/#/message/20260408175814.934BFC19421%40smtp.kernel.org Fixes: 4381a36abdf1c ("hwmon: add POWER-Z driver") Cc: stable@vger.kernel.org # ca085faabb42: dma-mapping: add __dma_from_device_group_begin()/end() Signed-off-by: Thomas Weißschuh Link: https://lore.kernel.org/r/20260408-powerz-cacheline-alias-v1-1-1254891be0dd@weissschuh.net Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 609936df7ce11ef3398b4b3db89ffcf849cb8f93 Author: Michael S. Tsirkin Date: Mon May 4 20:15:21 2026 -0400 dma-mapping: add __dma_from_device_group_begin()/end() [ Upstream commit ca085faabb42c31ee204235facc5a430cb9e78a9 ] When a structure contains a buffer that DMA writes to alongside fields that the CPU writes to, cache line sharing between the DMA buffer and CPU-written fields can cause data corruption on non-cache-coherent platforms. Add __dma_from_device_group_begin()/end() annotations to ensure proper alignment to prevent this: struct my_device { spinlock_t lock1; __dma_from_device_group_begin(); char dma_buffer1[16]; char dma_buffer2[16]; __dma_from_device_group_end(); spinlock_t lock2; }; Message-ID: <19163086d5e4704c316f18f6da06bc1c72968904.1767601130.git.mst@redhat.com> Acked-by: Marek Szyprowski Reviewed-by: Petr Tesarik Signed-off-by: Michael S. Tsirkin Stable-dep-of: 3023c050af36 ("hwmon: (powerz) Avoid cacheline sharing for DMA buffer") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 25c2b77bc463f29ee71a54b883548baf9386a0db Author: Thomas Zimmermann Date: Mon May 4 10:19:38 2026 -0400 fbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info [ Upstream commit 9ded47ad003f09a94b6a710b5c47f4aa5ceb7429 ] Hold state of deferred I/O in struct fb_deferred_io_state. Allocate an instance as part of initializing deferred I/O and remove it only after the final mapping has been closed. If the fb_info and the contained deferred I/O meanwhile goes away, clear struct fb_deferred_io_state.info to invalidate the mapping. Any access will then result in a SIGBUS signal. Fixes a long-standing problem, where a device hot-unplug happens while user space still has an active mapping of the graphics memory. The hot- unplug frees the instance of struct fb_info. Accessing the memory will operate on undefined state. Signed-off-by: Thomas Zimmermann Fixes: 60b59beafba8 ("fbdev: mm: Deferred IO support") Cc: Helge Deller Cc: linux-fbdev@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: stable@vger.kernel.org # v2.6.22+ Signed-off-by: Helge Deller [ replaced kzalloc_obj(*fbdefio_state) with kzalloc(sizeof(*fbdefio_state), GFP_KERNEL) ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1de2db19a6028abe7d905875922faef5b873de67 Author: SeongJae Park Date: Sat Apr 11 14:36:36 2026 -0700 mm/damon/core: disallow non-power of two min_region_sz on damon_start() commit 95093e5cb4c5b50a5b1a4b79f2942b62744bd66a upstream. Commit d8f867fa0825 ("mm/damon: add damon_ctx->min_sz_region") introduced a bug that allows unaligned DAMON region address ranges. Commit c80f46ac228b ("mm/damon/core: disallow non-power of two min_region_sz") fixed it, but only for damon_commit_ctx() use case. Still, DAMON sysfs interface can emit non-power of two min_region_sz via damon_start(). Fix the path by adding the is_power_of_2() check on damon_start(). The issue was discovered by sashiko [1]. Link: https://lore.kernel.org/20260411213638.77768-1-sj@kernel.org Link: https://lore.kernel.org/20260403155530.64647-1-sj@kernel.org [1] Fixes: d8f867fa0825 ("mm/damon: add damon_ctx->min_sz_region") Signed-off-by: SeongJae Park Cc: # 6.18.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit d18099f19e53250f8ad2801498b88cec29d9107a Author: Alexei Starovoitov Date: Mon Apr 13 12:42:45 2026 -0700 bpf: Fix use-after-free in arena_vm_close on fork commit 4fddde2a732de60bb97e3307d4eb69ac5f1d2b74 upstream. arena_vm_open() only bumps vml->mmap_count but never registers the child VMA in arena->vma_list. The vml->vma always points at the parent VMA, so after parent munmap the pointer dangles. If the child then calls bpf_arena_free_pages(), zap_pages() reads the stale vml->vma triggering use-after-free. Fix this by preventing the arena VMA from being inherited across fork with VM_DONTCOPY, and preventing VMA splits via the may_split callback. Also reject mremap with a .mremap callback returning -EINVAL. A same-size mremap(MREMAP_FIXED) on the full arena VMA reaches copy_vma() through the following path: check_prep_vma() - returns 0 early: new_len == old_len skips VM_DONTEXPAND check prep_move_vma() - vm_start == old_addr and vm_end == old_addr + old_len so may_split is never called move_vma() copy_vma_and_data() copy_vma() vm_area_dup() - copies vm_private_data (vml pointer) vm_ops->open() - bumps vml->mmap_count vm_ops->mremap() - returns -EINVAL, rollback unmaps new VMA The refcount ensures the rollback's arena_vm_close does not free the vml shared with the original VMA. Reported-by: Weiming Shi Reported-by: Xiang Mei Fixes: 317460317a02 ("bpf: Introduce bpf_arena.") Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/r/20260413194245.21449-1-alexei.starovoitov@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit 737adda64f5142dd809c2b3f1d227fe5bb6cfd32 Author: Jens Axboe Date: Mon Apr 27 19:16:39 2026 -0600 io_uring/tw: serialize ctx->retry_llist with ->uring_lock Commit 17666e2d7592c3e85260cafd3950121524acc2c5 upstream. The DEFER_TASKRUN local task work paths all run under ctx->uring_lock, which serializes them with each other and with the rest of the ring's hot paths. io_move_task_work_from_local() is the exception - it's called from io_ring_exit_work() on a kworker without holding the lock and from the iopoll cancelation side right after dropping it. ->work_llist is fine with this, as it's only ever updated via the expected paths. But the ->retry_llist is updated while runing, and hence it could potentially race between normal task_work running and the task-has-exited shutdown path. Simply grab ->uring_lock while moving the local work to the fallback list for exit purposes, which nicely serializes it across both the normal additions and the exit prune path. Cc: stable@vger.kernel.org Fixes: f46b9cdb22f7 ("io_uring: limit local tw done") Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 2563d7880c4df175e59f13c5881d99f8b51e3e70 Author: Martin Michaelis Date: Thu Apr 23 15:54:11 2026 -0600 io_uring/kbuf: support min length left for incremental buffers Commit 7deba791ad495ce1d7921683f4f7d1190fa210d1 upstream. Incrementally consumed buffer rings are generally fully consumed, but it's quite possible that the application has a minimum size it needs to meet to avoid truncation. Currently that minimum limit is 1 byte, but this should be a setting that is the hands of the application. For recvmsg multishot, a prime use case for incrementally consumed buffers, the application may get spurious -EFAULT returned at the end of an incrementally consumed buffer, as less space is available than the headers need. Grab a u32 field in struct io_uring_buf_reg, which the application can use to inform the kernel of the minimum size that should be available in an incrementally consumed buffer. If less than that is available, the current buffer is fully processed and the next one will be picked. Cc: stable@vger.kernel.org Fixes: ae98dbf43d75 ("io_uring/kbuf: add support for incremental buffer consumption") Link: https://github.com/axboe/liburing/issues/1433 Signed-off-by: Martin Michaelis [axboe: write commit message, change io_buffer_list member name] Reviewed-by: Gabriel Krisman Bertazi Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 23900db3787a614f5aef31cabe96d54b7d4a0c3a Author: Huacai Chen Date: Mon May 4 09:00:20 2026 +0800 LoongArch: Use per-root-bridge PCIH flag to skip mem resource fixup commit 49f33840dcc907d21313d369e34872880846b61c upstream. When firmware enables 64-bit PCI host bridge support, some root bridges already provide valid 64-bit mem resource windows through ACPI. In this case, the LoongArch-specific mem resource high-bits fixup in acpi_prepare_root_resources() should not be applied unconditionally. Otherwise, the kernel may override the native resource layout derived from firmware, and later BAR assignment can fail to place device BARs into the intended 64-bit address space correctly. Add a per-root-bridge ACPI flag, PCIH, and evaluate it from the current root bridge device scope. When PCIH is set, skip the mem resource high- bits fixup path and let the kernel use the firmware-provided resource description directly. When PCIH is absent or cleared, keep the existing behavior and continue filling the high address bits from the host bridge address. This makes the behavior per-root-bridge configurable and avoids breaking valid 64-bit BAR space allocation on bridges whose 64-bit windows have already been fully described by firmware. Cc: stable@vger.kernel.org Suggested-by: Chao Li Tested-by: Dongyan Qian Signed-off-by: Dongyan Qian Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit aaaf41aee5ac69741f170758a3ed5454557b2b45 Author: Tao Cui Date: Mon May 4 09:00:38 2026 +0800 LoongArch: KVM: Use kvm_set_pte() in kvm_flush_pte() commit 81e18777d61440511451866c7c80b34a8bdd6b33 upstream. kvm_flush_pte() is the only caller that directly assigns *pte instead of using the kvm_set_pte() wrapper. Use the wrapper for consistency with the rest of the file. No functional change intended. Cc: stable@vger.kernel.org Reviewed-by: Bibo Mao Signed-off-by: Tao Cui Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 3d44ed6dd219f1a3ec39c8897bf8da3b1664d704 Author: Bibo Mao Date: Mon May 4 09:00:48 2026 +0800 LoongArch: KVM: Move unconditional delay into timer clear scenery commit 5a873d77ba792410a796595a917be6a440f9b7d2 upstream. When timer interrupt arrives in guest kernel, guest kernel clears the timer interrupt and program timer with the next incoming event. During this stage, timer tick is -1 and timer interrupt status is disabled in ESTAT register. KVM hypervisor need write zero with timer tick register and wait timer interrupt injection from HW side, and then clear timer interrupt. So there is 2 cycle delay in KVM hypervisor to emulate such scenery, and the delay is unnecessary if there is no need to clear the timer interrupt. Here move 2 cycle delay into timer clear scenery and add timer ESTAT checking after delay, and set max timer expire value if timer interrupt does not arrive still. Cc: stable@vger.kernel.org Signed-off-by: Bibo Mao Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit b715ceb72ed99ca1e88a33e8ad451e28bda707c2 Author: Bibo Mao Date: Mon May 4 09:00:48 2026 +0800 LoongArch: KVM: Fix HW timer interrupt lost when inject interrupt by software commit 2433f3f5724b3af569d9fb411ba728629524738b upstream. With passthrough HW timer, timer interrupt is injected by HW. When inject emulated CPU interrupt by software such SIP0/SIP1/IPI, HW timer interrupt may be lost. Here check whether there is timer tick value inversion before and after injecting emulated CPU interrupt by software, timer enabling by reading timer cfg register is skipped. If the timer tick value is detected with changing, then timer should be enabled. And inject a timer interrupt by software if there is. Cc: 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 1c32824fbdec3b0e165067cea0835e4546dcc87e Author: Xianglai Li Date: Mon May 4 09:00:37 2026 +0800 LoongArch: KVM: Fix "unreliable stack" for kvm_exc_entry commit b323a441da602dfdfc24f30d3190cac786ffebf2 upstream. Insert the appropriate UNWIND hint into the kvm_exc_entry assembly function to guide the generation of correct ORC table entries, thereby solving the timeout problem ("unreliable stack") while loading the livepatch-sample module on a physical machine running virtual machines with multiple vcpus. Cc: stable@vger.kernel.org Signed-off-by: Xianglai Li Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit e50d8573534fa3221a1ab4a3f8a864480c1ba93b Author: Qiang Ma Date: Mon May 4 09:00:37 2026 +0800 LoongArch: KVM: Cap KVM_CAP_NR_VCPUS by KVM_CAP_MAX_VCPUS commit b3e31a6650d4cab63f0814c37c0b360372c6ee9e upstream. It doesn't make sense to return the recommended maximum number of vCPUs which exceeds the maximum possible number of vCPUs. Other architectures have already done this, such as commit 57a2e13ebdda ("KVM: MIPS: Cap KVM_CAP_NR_VCPUS by KVM_CAP_MAX_VCPUS") 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 9e1aed63a5552958ef2a9bfd699a3f990e52a77f Author: Wentao Guan Date: Mon May 4 09:00:20 2026 +0800 LoongArch: Fix potential ADE in loongson_gpu_fixup_dma_hang() commit 8dfa2f8780e486d05b9a0ffce70b8f5fbd62053e upstream. The switch case in loongson_gpu_fixup_dma_hang() may not DC2 or DC3, and readl(crtc_reg) will access with random address, because the "device" is from "base+PCI_DEVICE_ID", "base" is from "pdev->devfn+1". This is wrong when my platform inserts a discrete GPU: lspci -tv -[0000:00]-+-00.0 Loongson Technology LLC Hyper Transport Bridge Controller ... +-06.0 Loongson Technology LLC LG100 GPU +-06.2 Loongson Technology LLC Device 7a37 ... Add a default switch case to fix the panic as below: Kernel ade access[#1]: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.136-loong64-desktop-hwe+ #4 pc 90000000017e5534 ra 90000000017e54c0 tp 90000001002f8000 sp 90000001002fb6c0 a0 80000efe00003100 a1 0000000000003100 a2 0000000000000000 a3 0000000000000002 a4 90000001002fb6b4 a5 900000087cdb58fd a6 90000000027af000 a7 0000000000000001 t0 00000000000085b9 t1 000000000000ffff t2 0000000000000000 t3 0000000000000000 t4 fffffffffffffffd t5 00000000fffb6d9c t6 0000000000083b00 t7 00000000000070c0 t8 900000087cdb4d94 u0 900000087cdb58fd s9 90000001002fb826 s0 90000000031c12c8 s1 7fffffffffffff00 s2 90000000031c12d0 s3 0000000000002710 s4 0000000000000000 s5 0000000000000000 s6 9000000100053000 s7 7fffffffffffff00 s8 90000000030d4000 ra: 90000000017e54c0 loongson_gpu_fixup_dma_hang+0x40/0x210 ERA: 90000000017e5534 loongson_gpu_fixup_dma_hang+0xb4/0x210 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 00000004 (PPLV0 +PIE -PWE) EUEN: 00000000 (-FPE -SXE -ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 00480000 [ADEM] (IS= ECode=8 EsubCode=1) BADV: 7fffffffffffff00 PRID: 0014d000 (Loongson-64bit, Loongson-3A6000-HV) Modules linked in: Process swapper/0 (pid: 1, threadinfo=(____ptrval____), task=(____ptrval____)) Stack : 0000000000000006 90000001002fb778 90000001002fb704 0000000000000007 0000000016a65700 90000000017e5690 000000000000ffff ffffffffffffffff 900000000209f7c0 9000000100053000 900000000209f7a8 9000000000eebc08 0000000000000000 0000000000000000 0000000000000006 90000001002fb778 90000001000530b8 90000000027af000 0000000000000000 9000000100054000 9000000100053000 9000000000ebb70c 9000000100004c00 9000000004000001 90000001002fb7e4 bae765461f31cb12 0000000000000000 0000000000000000 0000000000000006 90000000027af000 0000000000000030 90000000027af000 900000087cd6f800 9000000100053000 0000000000000000 9000000000ebc560 7a2500147cdaf720 bae765461f31cb12 0000000000000001 0000000000000030 ... Call Trace: [<90000000017e5534>] loongson_gpu_fixup_dma_hang+0xb4/0x210 [<9000000000eebc08>] pci_fixup_device+0x108/0x280 [<9000000000ebb70c>] pci_setup_device+0x24c/0x690 [<9000000000ebc560>] pci_scan_single_device+0xe0/0x140 [<9000000000ebc684>] pci_scan_slot+0xc4/0x280 [<9000000000ebdd00>] pci_scan_child_bus_extend+0x60/0x3f0 [<9000000000f5bc94>] acpi_pci_root_create+0x2b4/0x420 [<90000000017e5e74>] pci_acpi_scan_root+0x2d4/0x440 [<9000000000f5b02c>] acpi_pci_root_add+0x21c/0x3a0 [<9000000000f4ee54>] acpi_bus_attach+0x1a4/0x3c0 [<90000000010e200c>] device_for_each_child+0x6c/0xe0 [<9000000000f4bbf4>] acpi_dev_for_each_child+0x44/0x70 [<9000000000f4ef40>] acpi_bus_attach+0x290/0x3c0 [<90000000010e200c>] device_for_each_child+0x6c/0xe0 [<9000000000f4bbf4>] acpi_dev_for_each_child+0x44/0x70 [<9000000000f4ef40>] acpi_bus_attach+0x290/0x3c0 [<9000000000f5211c>] acpi_bus_scan+0x6c/0x280 [<900000000189c028>] acpi_scan_init+0x194/0x310 [<900000000189bc6c>] acpi_init+0xcc/0x140 [<9000000000220cdc>] do_one_initcall+0x4c/0x310 [<90000000018618fc>] kernel_init_freeable+0x258/0x2d4 [<900000000184326c>] kernel_init+0x28/0x13c [<9000000000222008>] ret_from_kernel_thread+0xc/0xa4 Cc: stable@vger.kernel.org Fixes: 95db0c9f526d ("LoongArch: Workaround LS2K/LS7A GPU DMA hang bug") Link: https://gist.github.com/opsiff/ebf2dac51b4013d22462f2124c55f807 Link: https://gist.github.com/opsiff/a62f2a73db0492b3c49bf223a339b133 Signed-off-by: Wentao Guan Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 7d3c27b54253cda91dc4d2c1bfc109c490837ab9 Author: Fuad Tabba Date: Fri Apr 24 09:49:07 2026 +0100 KVM: arm64: Fix pin leak and publication ordering in __pkvm_init_vcpu() commit 73b9c1e5da84cd69b1a86e374e450817cd051371 upstream. Two bugs exist in the vCPU initialisation path: 1. If a check fails after hyp_pin_shared_mem() succeeds, the cleanup path jumps to 'unlock' without calling unpin_host_vcpu() or unpin_host_sve_state(), permanently leaking pin references on the host vCPU and SVE state pages. Extract a register_hyp_vcpu() helper that performs the checks and the store. When register_hyp_vcpu() returns an error, call unpin_host_vcpu() and unpin_host_sve_state() inline before falling through to the existing 'unlock' label. 2. register_hyp_vcpu() publishes the new vCPU pointer into 'hyp_vm->vcpus[]' with a bare store, allowing a concurrent caller of pkvm_load_hyp_vcpu() to observe a partially initialised vCPU object. Ensure the store uses smp_store_release() and the load uses smp_load_acquire(). While 'vm_table_lock' currently serialises the store and the load, these barriers ensure the reader sees the fully initialised 'hyp_vcpu' object even if there were a lockless path or if the lock's own ordering guarantees were insufficient for nested object initialization. Fixes: 49af6ddb8e5c ("KVM: arm64: Add infrastructure to create and track pKVM instances at EL2") Reported-by: Ben Simner Co-developed-by: Will Deacon Signed-off-by: Will Deacon Signed-off-by: Fuad Tabba Link: https://patch.msgid.link/20260424084908.370776-6-tabba@google.com Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 931c9c777e35d2f1871f6a6fa5dd049e08df7ade Author: Fuad Tabba Date: Fri Apr 24 09:49:03 2026 +0100 KVM: arm64: Fix FEAT_Debugv8p9 to check DebugVer, not PMUVer commit 7fe2cd4e1a3ad230d8fcc00cc99c4bcce4412a75 upstream. FEAT_Debugv8p9 is incorrectly defined against ID_AA64DFR0_EL1.PMUVer instead of ID_AA64DFR0_EL1.DebugVer. All three consumers of the macro gate features that are architecturally tied to FEAT_Debugv8p9 (DebugVer = 0b1011, DDI0487 M.b A2.2.10): - HDFGRTR2_EL2.nMDSELR_EL1, HDFGWTR2_EL2.nMDSELR_EL1: MDSELR_EL1 is present only when FEAT_Debugv8p9 is implemented (D24.3.21). - MDCR_EL2.EBWE: the Extended Breakpoint and Watchpoint Enable bit is RES0 unless FEAT_Debugv8p9 is implemented (D24.3.17). Neither register has any dependency on PMUVer. FEAT_Debugv8p9 and FEAT_PMUv3p9 are independent. Per DDI0487 M.b A2.2.10, FEAT_Debugv8p9 is unconditionally mandatory from Armv8.9, whereas FEAT_PMUv3p9 is mandatory only when FEAT_PMUv3 is implemented. An Armv8.9 CPU without a PMU has DebugVer = 0b1011 but PMUVer = 0b0000, so the wrong field check would cause KVM to incorrectly treat EBWE and MDSELR_EL1 as RES0 on such hardware. Fixes: 4bc0fe089840 ("KVM: arm64: Add sanitisation for FEAT_FGT2 registers") Signed-off-by: Fuad Tabba Link: https://patch.msgid.link/20260424084908.370776-2-tabba@google.com Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 7e9f5f62f8d152957e03dde5ca4586377df8ac11 Author: Fuad Tabba Date: Fri Apr 24 09:49:05 2026 +0100 KVM: arm64: Fix FEAT_SPE_FnE to use PMSIDR_EL1.FnE, not PMSVer commit 08d715338287a1affb4c7ad5733decef4558a5c8 upstream. FEAT_SPE_FnE is architecturally detected via PMSIDR_EL1.FnE [6], not ID_AA64DFR0_EL1.PMSVer. The FEAT_X macro form (register, field, value) cannot encode a PMSIDR_EL1-based feature, so FEAT_SPE_FnE was defined identically to FEAT_SPEv1p2 (ID_AA64DFR0_EL1, PMSVer, V1P2), producing a duplicate that used PMSVer >= V1P2 as a proxy. Replace the macro with feat_spe_fne(), following the same pattern as the sibling feat_spe_fds(): guard on FEAT_SPEv1p2 and read PMSIDR_EL1.FnE [6] directly. Wire the two NEEDS_FEAT consumers to use the new function. Remove the now-unused FEAT_SPE_FnE macro. Fixes: 63d423a7635b ("KVM: arm64: Switch to table-driven FGU configuration") Signed-off-by: Fuad Tabba Link: https://patch.msgid.link/20260424084908.370776-4-tabba@google.com Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 81e7907fe542fbbf11a33484e41ff401e0a74724 Author: Quentin Perret Date: Fri Apr 24 09:49:08 2026 +0100 KVM: arm64: Fix initialisation order in __pkvm_init_finalise() commit 5bb0aed57ba944f8c201e4e82ec066e0187e0f85 upstream. fix_host_ownership() walks the hypervisor's stage-1 page-table to adjust the host's stage-2 accordingly. Any such adjustment that requires cache maintenance operations depends on the per-CPU hyp fixmap being present. However, fix_host_ownership() is currently called before fix_hyp_pgtable_refcnt() and hyp_create_fixmap(), so the fixmap does not yet exist when it runs. This is benign today because the host stage-2 starts empty and no CMOs are needed, but it becomes a latent crash as soon as fix_host_ownership() is extended to operate on a non-empty page-table. Reorder the calls so that fix_hyp_pgtable_refcnt() and hyp_create_fixmap() complete before fix_host_ownership() is invoked. Fixes: 0d16d12eb26e ("KVM: arm64: Fix-up hyp stage-1 refcounts for all pages mapped at EL2") Signed-off-by: Quentin Perret Signed-off-by: Fuad Tabba Link: https://patch.msgid.link/20260424084908.370776-7-tabba@google.com Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 7b99369b2c7a553f67eed3967d6486df8bbac521 Author: David Woodhouse Date: Tue Apr 7 21:27:02 2026 +0100 KVM: arm64: vgic: Fix IIDR revision field extracted from wrong value commit a0e6ae45af17e8b27958830595799c702ffbab8d upstream. The uaccess write handlers for GICD_IIDR in both GICv2 and GICv3 extract the revision field from 'reg' (the current IIDR value read back from the emulated distributor) instead of 'val' (the value userspace is trying to write). This means userspace can never actually change the implementation revision — the extracted value is always the current one. Fix the FIELD_GET to use 'val' so that userspace can select a different revision for migration compatibility. Fixes: 49a1a2c70a7f ("KVM: arm64: vgic-v3: Advertise GICR_CTLR.{IR, CES} as a new GICD_IIDR revision") Signed-off-by: David Woodhouse Link: https://patch.msgid.link/20260407210949.2076251-2-dwmw2@infradead.org Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 837db077779280ec417b8d79832387f340380bd2 Author: Marc Zyngier Date: Thu Apr 23 17:36:07 2026 +0100 KVM: arm64: Wake-up from WFI when iqrchip is in userspace commit 4ce98bf0865c349e7026ad9c14f48da264920953 upstream. It appears that there is nothing in the wake-up path that evaluates whether the in-kernel interrupts are pending unless we have a vgic. This means that the userspace irqchip support has been broken for about four years, and nobody noticed. It was also broken before as we wouldn't wake-up on a PMU interrupt, but hey, who cares... It is probably time to remove the feature altogether, because it was a terrible idea 10 years ago, and it still is. Fixes: b57de4ffd7c6d ("KVM: arm64: Simplify kvm_cpu_has_pending_timer()") Link: https://patch.msgid.link/20260423163607.486345-1-maz@kernel.org Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 8be551f538dc5b64183e27bd45a7a0795263f760 Author: Yongpeng Yang Date: Wed Mar 18 16:45:34 2026 +0800 f2fs: fix fsck inconsistency caused by FGGC of node block commit c3e238bd1f56993f205ef83889d406dfeaf717a8 upstream. During FGGC node block migration, fsck may incorrectly treat the migrated node block as fsync-written data. The reproduction scenario: root@vm:/mnt/f2fs# seq 1 2048 | xargs -n 1 ./test_sync // write inline inode and sync root@vm:/mnt/f2fs# rm -f 1 root@vm:/mnt/f2fs# sync root@vm:/mnt/f2fs# f2fs_io gc_range // move data block in sync mode and not write CP SPO, "fsck --dry-run" find inode has already checkpointed but still with DENT_BIT_SHIFT set The root cause is that GC does not clear the dentry mark and fsync mark during node block migration, leading fsck to misinterpret them as user-issued fsync writes. In BGGC mode, node block migration is handled by f2fs_sync_node_pages(), which guarantees the dentry and fsync marks are cleared before writing. This patch move the set/clear of the fsync|dentry marks into __write_node_folio to make the logic clearer, and ensures the fsync|dentry mark is cleared in FGGC. Cc: stable@kernel.org Fixes: da011cc0da8c ("f2fs: move node pages only in victim section during GC") Signed-off-by: Yongpeng Yang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 03806ec9c4cd5405780e127ab3eb86e724f1b151 Author: Yongpeng Yang Date: Wed Mar 18 16:46:35 2026 +0800 f2fs: fix inline data not being written to disk in writeback path commit fe9b8b30b97102859a9102be7bd2a09803bd90bd upstream. When f2fs_fiemap() is called with `fileinfo->fi_flags` containing the FIEMAP_FLAG_SYNC flag, it attempts to write data to disk before retrieving file mappings via filemap_write_and_wait(). However, there is an issue where the file does not get mapped as expected. The following scenario can occur: root@vm:/mnt/f2fs# dd if=/dev/zero of=data.3k bs=3k count=1 root@vm:/mnt/f2fs# xfs_io data.3k -c "fiemap -v 0 4096" data.3k: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..5]: 0..5 6 0x307 The root cause of this issue is that f2fs_write_single_data_page() only calls f2fs_write_inline_data() to copy data from the data folio to the inode folio, and it clears the dirty flag on the data folio. However, it does not mark the data folio as writeback. When __filemap_fdatawait_range() checks for folios with the writeback flag, it returns early, causing f2fs_fiemap() to report that the file has no mapping. To fix this issue, the solution is to call f2fs_write_single_node_folio() in f2fs_inline_data_fiemap() when getting fiemap with FIEMAP_FLAG_SYNC flags. This patch ensures that the inode folio is written back and the writeback process completes before proceeding. Cc: stable@kernel.org Fixes: 9ffe0fb5f3bb ("f2fs: handle inline data operations") Signed-off-by: Yongpeng Yang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 4bdc05b2032bafb6e652a1fc867e0f15d851e79e Author: Yongpeng Yang Date: Wed Mar 18 16:45:32 2026 +0800 f2fs: refactor f2fs_move_node_folio function commit 92c20989366e023b74fa0c1028af9436c1917dbf upstream. This patch refactor the f2fs_move_node_folio() function. No logical changes. Cc: stable@kernel.org Signed-off-by: Yongpeng Yang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 8d269aae6f73683b47dc1039d38f7dc73ce3219c Author: Guangshuo Li Date: Fri Apr 10 20:47:26 2026 +0800 f2fs: fix uninitialized kobject put in f2fs_init_sysfs() commit b635f2ecdb5ad34f9c967cabb704d6bed9382fd0 upstream. In f2fs_init_sysfs(), all failure paths after kset_register() jump to put_kobject, which unconditionally releases both f2fs_tune and f2fs_feat. If kobject_init_and_add(&f2fs_feat, ...) fails, f2fs_tune has not been initialized yet, so calling kobject_put(&f2fs_tune) is invalid. Fix this by splitting the unwind path so each error path only releases objects that were successfully initialized. Fixes: a907f3a68ee26ba4 ("f2fs: add a sysfs entry to reclaim POSIX_FADV_NOREUSE pages") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit b0e4395870eb3441ddc959f6710b5f6ca61aff26 Author: Yongpeng Yang Date: Fri Apr 3 22:40:17 2026 +0800 f2fs: fix node_cnt race between extent node destroy and writeback commit ed78aeebef05212ef7dca93bd931e4eff67c113f upstream. f2fs_destroy_extent_node() does not set FI_NO_EXTENT before clearing extent nodes. When called from f2fs_drop_inode() with I_SYNC set, concurrent kworker writeback can insert new extent nodes into the same extent tree, racing with the destroy and triggering f2fs_bug_on() in __destroy_extent_node(). The scenario is as follows: drop inode writeback - iput - f2fs_drop_inode // I_SYNC set - f2fs_destroy_extent_node - __destroy_extent_node - while (node_cnt) { write_lock(&et->lock) __free_extent_tree write_unlock(&et->lock) - __writeback_single_inode - f2fs_outplace_write_data - f2fs_update_read_extent_cache - __update_extent_tree_range // FI_NO_EXTENT not set, // insert new extent node } // node_cnt == 0, exit while - f2fs_bug_on(node_cnt) // node_cnt > 0 Additionally, __update_extent_tree_range() only checks FI_NO_EXTENT for EX_READ type, leaving EX_BLOCK_AGE updates completely unprotected. This patch set FI_NO_EXTENT under et->lock in __destroy_extent_node(), consistent with other callers (__update_extent_tree_range and __drop_extent_tree) and check FI_NO_EXTENT for both EX_READ and EX_BLOCK_AGE tree. Fixes: 3fc5d5a182f6 ("f2fs: fix to shrink read extent node in batches") Cc: stable@vger.kernel.org Signed-off-by: Yongpeng Yang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit d438a9fb20d01160cb37314d47faa6d6314c47f3 Author: Yongpeng Yang Date: Mon Mar 23 20:06:22 2026 +0800 f2fs: fix incorrect multidevice info in trace_f2fs_map_blocks() commit eb2ca3ca983551a80e16a4a25df5a4ce59df8484 upstream. When f2fs_map_blocks()->f2fs_map_blocks_cached() hits the read extent cache, map->m_multidev_dio is not updated, which leads to incorrect multidevice information being reported by trace_f2fs_map_blocks(). This patch updates map->m_multidev_dio in f2fs_map_blocks_cached() when the read extent cache is hit. Cc: stable@kernel.org Fixes: 0094e98bd147 ("f2fs: factor a f2fs_map_blocks_cached helper") Signed-off-by: Yongpeng Yang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit f37012cc7c270a8a434240bb2e627df8be13e5af Author: Yongpeng Yang Date: Tue Feb 3 21:36:35 2026 +0800 f2fs: fix incorrect file address mapping when inline inode is unwritten commit 68a0178981a0f493295afa29f8880246e561494c upstream. When `fileinfo->fi_flags` does not have the `FIEMAP_FLAG_SYNC` bit set and inline data has not been persisted yet, the physical address of the extent is calculated incorrectly for unwritten inline inodes. root@vm:/mnt/f2fs# dd if=/dev/zero of=data.3k bs=3k count=1 root@vm:/mnt/f2fs# f2fs_io fiemap 0 100 data.3k Fiemap: offset = 0 len = 100 logical addr. physical addr. length flags 0 0000000000000000 00000ffffffff16c 0000000000000c00 00000301 This patch fixes the issue by checking if the inode's address is valid. If the inline inode is unwritten, set the physical address to 0 and mark the extent with `FIEMAP_EXTENT_UNKNOWN | FIEMAP_EXTENT_DELALLOC` flags. Cc: stable@kernel.org Fixes: 67f8cf3cee6f ("f2fs: support fiemap for inline_data") Signed-off-by: Yongpeng Yang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit bedb710b63ae1bd617e65d0a8cf6cea1200b3753 Author: Yongpeng Yang Date: Tue Mar 10 17:36:12 2026 +0800 f2fs: fix fsck inconsistency caused by incorrect nat_entry flag usage commit 019f9dda7f66e55eb94cd32e1d3fff5835f73fbc upstream. f2fs_need_dentry_mark() reads nat_entry flags without mutual exclusion with the checkpoint path, which can result in an incorrect inode block marking state. The scenario is as follows: create & write & fsync 'file A' write checkpoint - f2fs_do_sync_file // inline inode - f2fs_write_inode // inode folio is dirty - f2fs_write_checkpoint - f2fs_flush_merged_writes - f2fs_sync_node_pages - f2fs_fsync_node_pages // no dirty node - f2fs_need_inode_block_update // return true - f2fs_fsync_node_pages // inode dirtied - f2fs_need_dentry_mark //return true - f2fs_flush_nat_entries - f2fs_write_checkpoint end - __write_node_folio // inode with DENT_BIT_SHIFT set SPO, "fsck --dry-run" find inode has already checkpointed but still with DENT_BIT_SHIFT set The state observed by f2fs_need_dentry_mark() can differ from the state observed in __write_node_folio() after acquiring sbi->node_write. The root cause is that the semantics of IS_CHECKPOINTED and HAS_FSYNCED_INODE are only guaranteed after the checkpoint write has fully completed. This patch moves set_dentry_mark() into __write_node_folio() and protects it with the sbi->node_write lock. Cc: stable@kernel.org Fixes: 88bd02c9472a ("f2fs: fix conditions to remain recovery information in f2fs_sync_file") Signed-off-by: Yongpeng Yang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 63c2d2ad40d1563f7307023b2f0287a711521e3b Author: Yongpeng Yang Date: Mon Mar 23 20:06:24 2026 +0800 f2fs: fix fiemap boundary handling when read extent cache is incomplete commit 95e159ad3e52f7478cfd22e44ec37c9f334f8993 upstream. f2fs_fiemap() calls f2fs_map_blocks() to obtain the block mapping a file, and then merges contiguous mappings into extents. If the mapping is found in the read extent cache, node blocks do not need to be read. However, in the following scenario, a contiguous extent can be split into two extents: $ dd if=/dev/zero of=data.128M bs=1M count=128 $ losetup -f data.128M $ mkfs.f2fs /dev/loop0 -f $ mount -o mode=lfs /dev/loop0 /mnt/f2fs/ $ cd /mnt/f2fs/ $ dd if=/dev/zero of=data.72M bs=1M count=72 && sync $ dd if=/dev/zero of=data.4M bs=1M count=4 && sync $ dd if=/dev/zero of=data.4M bs=1M count=2 seek=2 conv=notrunc && sync $ echo 3 > /proc/sys/vm/drop_caches $ dd if=/dev/zero of=data.4M bs=1M count=2 seek=0 conv=notrunc && sync $ dd if=/dev/zero of=data.4M bs=1M count=2 seek=0 conv=notrunc && sync $ f2fs_io fiemap 0 1024 data.4M Fiemap: offset = 0 len = 1024 logical addr. physical addr. length flags 0 0000000000000000 0000000006400000 0000000000200000 00001000 1 0000000000200000 0000000006600000 0000000000200000 00001001 Although the physical addresses of the ranges 0～2MB and 2M～4MB are contiguous, the mapping for the 2M～4MB range is not present in memory. When the physical addresses for the 0～2MB range are updated, no merge happens because the adjacent mapping is missing from the in-memory cache. As a result, fiemap reports two separate extents instead of a single contiguous one. The root cause is that the read extent cache does not guarantee that all blocks of an extent are present in memory. Therefore, when the extent length returned by f2fs_map_blocks_cached() is smaller than maxblocks, the remaining mappings are retrieved via f2fs_get_dnode_of_data() to ensure correct fiemap extent boundary handling. Cc: stable@kernel.org Fixes: cd8fc5226bef ("f2fs: remove the create argument to f2fs_map_blocks") Signed-off-by: Yongpeng Yang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 060029ed542e845fe71e36b46f15619dd255bddf Author: Cen Zhang Date: Wed Mar 18 15:32:53 2026 +0800 f2fs: add READ_ONCE() for i_blocks in f2fs_update_inode() commit 5471834a96fb697874be2ca0b052e74bcf3c23d1 upstream. f2fs_update_inode() reads inode->i_blocks without holding i_lock to serialize it to the on-disk inode, while concurrent truncate or allocation paths may modify i_blocks under i_lock. Since blkcnt_t is u64, this risks torn reads on 32-bit architectures. Following the approach in ext4_inode_blocks_set(), add READ_ONCE() to prevent potential compiler-induced tearing. Fixes: 19f99cee206c ("f2fs: add core inode operations") Cc: stable@vger.kernel.org Signed-off-by: Cen Zhang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 464747eae483e9ac9185012b85a7619f06721587 Author: Matthieu Baerts (NGI0) Date: Tue May 5 17:00:56 2026 +0200 mptcp: pm: ADD_ADDR rtx: return early if no retrans commit 62a9b19dce77e72426f049fb99b9d1d032b9a8ea upstream. No need to iterate over all subflows if there is no retransmission needed. Exit early in this case then. Fixes: 30549eebc4d8 ("mptcp: make ADD_ADDR retransmission timeout adaptive") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260505-net-mptcp-pm-fixes-7-1-rc3-v1-8-fca8091060a4@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 107e956ce5441192946f53d2aea186d9ca0bd745 Author: Matthieu Baerts (NGI0) Date: Tue May 5 17:00:54 2026 +0200 mptcp: pm: ADD_ADDR rtx: resched blocked ADD_ADDR quicker commit 3cf12492891c4b5ff54dda404a2de4ec54c9e1b5 upstream. When an ADD_ADDR needs to be retransmitted and another one has already been prepared -- e.g. multiple ADD_ADDRs have been sent in a row and need to be retransmitted later -- this additional retransmission will need to wait. In this case, the timer was reset to TCP_RTO_MAX / 8, which is ~15 seconds. This delay is unnecessary long: it should just be rescheduled at the next opportunity, e.g. after the retransmission timeout. Without this modification, some issues can be seen from time to time in the selftests when multiple ADD_ADDRs are sent, and the host takes time to process them, e.g. the "signal addresses, ADD_ADDR timeout" MPTCP Join selftest, especially with a debug kernel config. Note that on older kernels, 'timeout' is not available. It should be enough to replace it by one second (HZ). Fixes: 00cfd77b9063 ("mptcp: retransmit ADD_ADDR when timeout") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260505-net-mptcp-pm-fixes-7-1-rc3-v1-6-fca8091060a4@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b74ad20198652b6b39a761c277ba65ae82b1e107 Author: Matthieu Baerts (NGI0) Date: Tue May 5 17:00:53 2026 +0200 mptcp: pm: ADD_ADDR rtx: free sk if last commit b7b9a461569734d33d3259d58d2507adfac107ed upstream. When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(), and released at the end. If at that moment, it was the last reference being held, the sk would not be freed. sock_put() should then be called instead of __sock_put(). But that's not enough: if it is the last reference, sock_put() will call sk_free(), which will end up calling sk_stop_timer_sync() on the same timer, and waiting indefinitely to finish. So it is needed to mark that the timer is done at the end of the timer handler when it has not been rescheduled, not to call sk_stop_timer_sync() on "itself". Fixes: 00cfd77b9063 ("mptcp: retransmit ADD_ADDR when timeout") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260505-net-mptcp-pm-fixes-7-1-rc3-v1-5-fca8091060a4@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit acd3d3562315c99f3c0db16f0fcc5f0306638982 Author: Matthieu Baerts (NGI0) Date: Tue May 5 17:00:52 2026 +0200 mptcp: pm: ADD_ADDR rtx: always decrease sk refcount commit 9634cb35af17019baec21ca648516ce376fa10e6 upstream. When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(). It should then be released in all cases at the end. Some (unlikely) checks were returning directly instead of calling sock_put() to decrease the refcount. Jump to a new 'exit' label to call __sock_put() (which will become sock_put() in the next commit) to fix this potential leak. While at it, drop the '!msk' check which cannot happen because it is never reset, and explicitly mark the remaining one as "unlikely". Fixes: 00cfd77b9063 ("mptcp: retransmit ADD_ADDR when timeout") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260505-net-mptcp-pm-fixes-7-1-rc3-v1-4-fca8091060a4@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2ad56e434199ca24a812bb353667aa1c3860f513 Author: Matthieu Baerts (NGI0) Date: Tue May 5 17:00:51 2026 +0200 mptcp: pm: ADD_ADDR rtx: fix potential data-race commit 5cd6e0ad79d2615264f63929f8b457ad97ae550d upstream. This mptcp_pm_add_timer() helper is executed as a timer callback in softirq context. To avoid any data races, the socket lock needs to be held with bh_lock_sock(). If the socket is in use, retry again soon after, similar to what is done with the keepalive timer. Fixes: 00cfd77b9063 ("mptcp: retransmit ADD_ADDR when timeout") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260505-net-mptcp-pm-fixes-7-1-rc3-v1-3-fca8091060a4@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit cffc6fc446a27f3eb35779b6285089e6849259b7 Author: Matthieu Baerts (NGI0) Date: Tue May 5 17:00:50 2026 +0200 mptcp: pm: ADD_ADDR rtx: allow ID 0 commit 03f324f3f1f7619a47b9c91282cb12775ab0a2f1 upstream. ADD_ADDR can be sent for the ID 0, which corresponds to the local address and port linked to the initial subflow. Indeed, this address could be removed, and re-added later on, e.g. what is done in the "delete re-add signal" MPTCP Join selftests. So no reason to ignore it. Fixes: 00cfd77b9063 ("mptcp: retransmit ADD_ADDR when timeout") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260505-net-mptcp-pm-fixes-7-1-rc3-v1-2-fca8091060a4@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 07c2f3c29a8a03e80cdc073838448f58c5182855 Author: Matthieu Baerts (NGI0) Date: Tue May 5 17:00:49 2026 +0200 mptcp: pm: kernel: correctly retransmit ADD_ADDR ID 0 commit b12014d2d36eaed4e4bec5f1ac7e91110eeb100d upstream. When adding the ADD_ADDR to the list, the address including the IP, port and ID are copied. On the other hand, when the endpoint corresponds to the one from the initial subflow, the ID is set to 0, as specified by the MPTCP protocol. The issue is that the ID was reset after having copied the ID in the ADD_ADDR entry. So the retransmission was done, but using a different ID than the initial one. Fixes: 8b8ed1b429f8 ("mptcp: pm: reuse ID 0 after delete and re-add") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260505-net-mptcp-pm-fixes-7-1-rc3-v1-1-fca8091060a4@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6f5ba49da8b1ab9e0edcc8a69bdc074f1794b5ab Author: Matthieu Baerts (NGI0) Date: Tue May 5 17:00:57 2026 +0200 mptcp: pm: prio: skip closed subflows commit 166b78344031bf7ac9f55cb5282776cfd85f220e upstream. When sending an MP_PRIO, closed subflows need to be skipped. This fixes the case where the initial subflow got closed, re-opened later, then an MP_PRIO is needed for the same local address. Note that explicit MP_PRIO cannot be sent during the 3WHS, so it is fine to use __mptcp_subflow_active(). Fixes: 067065422fcd ("mptcp: add the outgoing MP_PRIO support") Cc: stable@vger.kernel.org Fixes: b29fcfb54cd7 ("mptcp: full disconnect implementation") Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260505-net-mptcp-pm-fixes-7-1-rc3-v1-9-fca8091060a4@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8a005fe451c73fd2b3d1faa5643c11e6bd07acfc Author: Gang Yan Date: Mon Apr 27 21:54:34 2026 +0200 mptcp: fix scheduling with atomic in timestamp sockopt commit b5c52908d52c6c8eb8933264aa6087a0600fd892 upstream. Using lock_sock_fast() (atomic context) around sock_set_timestamp() and sock_set_timestamping() is unsafe, as both helpers can sleep. Replace lock_sock_fast() with sleepable lock_sock()/release_sock() to avoid scheduling while atomic panic. Fixes: 9061f24bf82e ("mptcp: sockopt: propagate timestamp request to subflows") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260420093343.16443-1-gang.yan@linux.dev Signed-off-by: Gang Yan Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260427-net-mptcp-misc-fixes-7-1-rc2-v1-2-7432b7f279fa@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e6ad28d9d5bff3f7eb8212be8658fae31f3d273e Author: Paolo Abeni Date: Fri May 1 21:35:36 2026 +0200 mptcp: fix rx timestamp corruption on fastopen commit 6254a16d6f0c672e3809ca5d7c9a28a55d71f764 upstream. The skb cb offset containing the timestamp presence flag is cleared before loading such information. Cache such value before MPTCP CB initialization. Fixes: 36b122baf6a8 ("mptcp: add subflow_v(4,6)_send_synack()") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260501-net-mptcp-misc-fixes-7-1-rc3-v1-3-b70118df778e@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e083d1d8bbec1976dedcdbbe17bee5ee96df4855 Author: Matthieu Baerts (NGI0) Date: Fri May 1 21:35:37 2026 +0200 mptcp: sockopt: increase seq in mptcp_setsockopt_all_sf commit 70ece9d7021c54cf40c72b31b066e9088f5f75f5 upstream. mptcp_setsockopt_all_sf() was missing a call to sockopt_seq_inc(). This is required not to cause missing synchronization for newer subflows created later on. This helper is called each time a socket option is set on subflows, and future ones will need to inherit this option after their creation. Fixes: 51c5fd09e1b4 ("mptcp: add TCP_MAXSEG sockopt support") Cc: stable@vger.kernel.org Suggested-by: Paolo Abeni Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260501-net-mptcp-misc-fixes-7-1-rc3-v1-4-b70118df778e@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c7362eef3b70bc68255e0a7336308417d7c40bf1 Author: Gang Yan Date: Mon Apr 27 21:54:33 2026 +0200 mptcp: sockopt: set timestamp flags on subflow socket, not msk commit 5f95c21fc23a7ef22b4d27d1ed9bb55557ffb926 upstream. Both mptcp_setsockopt_sol_socket_tstamp() and mptcp_setsockopt_sol_socket_timestamping() iterate over subflows, acquire the subflow socket lock, but then erroneously pass the MPTCP msk socket to sock_set_timestamp() / sock_set_timestamping() instead of the subflow ssk. As a result, the timestamp flags are set on the wrong socket and have no effect on the actual subflows. Pass ssk instead of sk to both helpers. Fixes: 9061f24bf82e ("mptcp: sockopt: propagate timestamp request to subflows") Cc: stable@vger.kernel.org Signed-off-by: Gang Yan Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260427-net-mptcp-misc-fixes-7-1-rc2-v1-1-7432b7f279fa@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e74f33c8a2c79824f7725c09162fa01eb7e0728a Author: Shardul Bankar Date: Fri May 1 21:35:35 2026 +0200 mptcp: use MPTCP_RST_EMPTCP for ACK HMAC validation failure commit a6da02d4c00fdda2417e42ad2b762a9209e6cc49 upstream. When HMAC validation fails on a received ACK + MP_JOIN in subflow_syn_recv_sock(), the subflow is reset with reason MPTCP_RST_EPROHIBIT ("Administratively prohibited"). This is incorrect: HMAC validation failure is an MPTCP protocol-level error, not an administrative policy denial. The mirror site on the client, in subflow_finish_connect(), already uses MPTCP_RST_EMPTCP ("MPTCP-specific error") for the same kind of HMAC failure on the SYN/ACK + MP_JOIN. Use the same reason on the server side for symmetry and accuracy. Suggested-by: Matthieu Baerts (NGI0) Fixes: 443041deb5ef ("mptcp: fix NULL pointer in can_accept_new_subflow") Cc: stable@vger.kernel.org Signed-off-by: Shardul Bankar Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260501-net-mptcp-misc-fixes-7-1-rc3-v1-2-b70118df778e@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit fa26c8deed612e95c81425bc881ae1b4fa4ece93 Author: Shardul Bankar Date: Fri May 1 21:35:34 2026 +0200 mptcp: use MPJoinSynAckHMacFailure for SynAck HMAC failure commit c4a99a921949cddc590b22bb14eeb23dffcc3ba6 upstream. In subflow_finish_connect(), HMAC validation of the server's HMAC in SYN/ACK + MP_JOIN increments MPTCP_MIB_JOINACKMAC ("HMAC was wrong on ACK + MP_JOIN") on failure. The function processes the SYN/ACK, not the ACK; the matching MPTCP_MIB_JOINSYNACKMAC counter ("HMAC was wrong on SYN/ACK + MP_JOIN") exists but is not incremented anywhere in the tree. The mirror site on the server, subflow_syn_recv_sock(), already uses JOINACKMAC correctly for ACK HMAC failure. Use JOINSYNACKMAC at the SYN/ACK validation site so each counter reflects the packet whose HMAC actually failed. Suggested-by: Matthieu Baerts (NGI0) Fixes: fc518953bc9c ("mptcp: add and use MIB counter infrastructure") Cc: stable@vger.kernel.org Signed-off-by: Shardul Bankar Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260501-net-mptcp-misc-fixes-7-1-rc3-v1-1-b70118df778e@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4f269fc3c73af49aa3ee7769ab5d3e94fc7bba57 Author: Matthieu Baerts (NGI0) Date: Mon Apr 27 21:54:35 2026 +0200 mptcp: fastclose msk when linger time is 0 commit f14d6e9c3678a067f304abba561e0c5446c7e845 upstream. The SO_LINGER socket option has been supported for a while with MPTCP sockets [1], but it didn't cause the equivalent of a TCP reset as expected when enabled and its time was set to 0. This was causing some behavioural differences with TCP where some connections were not promptly stopped as expected. To fix that, an extra condition is checked at close() time before sending an MP_FASTCLOSE, the MPTCP equivalent of a TCP reset. Note that backporting up to [1] will be difficult as more changes are needed to be able to send MP_FASTCLOSE. It seems better to stop at [2], which was supposed to already imitate TCP. Validated with MPTCP packetdrill tests [3]. Fixes: 268b12387460 ("mptcp: setsockopt: support SO_LINGER") [1] Fixes: d21f83485518 ("mptcp: use fastclose on more edge scenarios") [2] Cc: stable@vger.kernel.org Reported-by: Lance Tuller Closes: https://github.com/lance0/xfr/pull/67 Link: https://github.com/multipath-tcp/packetdrill/pull/196 [3] Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260427-net-mptcp-misc-fixes-7-1-rc2-v1-3-7432b7f279fa@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2146145d6dd6827e5ea4bb710f5b0473bf4ea1cf Author: Matthieu Baerts (NGI0) Date: Tue May 5 17:00:59 2026 +0200 selftests: mptcp: pm: restrict 'unknown' check to pm_nl_ctl commit 53705ddfa18408f8e1f064331b6387509fa19f7f upstream. When pm_netlink.sh is executed with '-i', 'ip mptcp' is used instead of 'pm_nl_ctl'. IPRoute2 doesn't support the 'unknown' flag, which has only been added to 'pm_nl_ctl' for this specific check: to ensure that the kernel ignores such unsupported flag. No reason to add this flag to 'ip mptcp'. Then, this check should be skipped when 'ip mptcp' is used. Fixes: 0cef6fcac24d ("selftests: mptcp: ip_mptcp option for more scripts") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260505-net-mptcp-pm-fixes-7-1-rc3-v1-11-fca8091060a4@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2efd6bd0e9b19fc0ac75a5cad74ab2017319ca8c Author: Matthieu Baerts (NGI0) Date: Tue May 5 17:00:58 2026 +0200 selftests: mptcp: check output: catch cmd errors commit 65db7b27b90e2ea8d4966935aa9a50b6a60c31ac upstream. Using '${?}' inside the if-statement to check the returned value from the command that was evaluated as part of the if-statement is not correct: here, '${?}' will be linked to the previous instruction, not the one that is expected here (${cmd}). Instead, simply mark the error, except if an error is expected. If that's the case, 1 can be passed as the 4th argument of this helper. Three checks from pm_netlink.sh expect an error. While at it, improve the error message when the command unexpectedly fails or succeeds. Note that we could expect a specific returned value, but the checks currently expecting an error can be used with 'ip mptcp' or 'pm_nl_ctl', and these two tools don't return the same error code. Fixes: 2d0c1d27ea4e ("selftests: mptcp: add mptcp_lib_check_output helper") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260505-net-mptcp-pm-fixes-7-1-rc3-v1-10-fca8091060a4@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a8f4a82e5629cdf94c55a39c70a62310f73b46ce Author: David Carlier Date: Thu Apr 30 10:27:47 2026 +0100 sched_ext: idle: Recheck prev_cpu after narrowing allowed mask commit b34c82777a2c0648ee053595f4b290fd5249b093 upstream. scx_select_cpu_dfl() narrows @allowed to @cpus_allowed & @p->cpus_ptr when the BPF caller supplies a @cpus_allowed that differs from @p->cpus_ptr and @p doesn't have full affinity. However, @is_prev_allowed was computed against the original (wider) @cpus_allowed, so the prev_cpu fast paths could pick a @prev_cpu that is in @cpus_allowed but not in @p->cpus_ptr, violating the intended invariant that the returned CPU is always usable by @p. The kernel masks this via the SCX_EV_SELECT_CPU_FALLBACK fallback, but the behavior contradicts the documented contract. Move the @is_prev_allowed evaluation past the narrowing block so it tests against the final @allowed mask. Fixes: ee9a4e92799d ("sched_ext: idle: Properly handle invalid prev_cpu during idle selection") Cc: stable@vger.kernel.org # v6.16+ Assisted-by: Claude Signed-off-by: David Carlier Reviewed-by: Andrea Righi Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 0c63333ff97bd1275294fd12840a0efe9d7a4c59 Author: Jason Gunthorpe Date: Tue Apr 28 13:17:43 2026 -0300 RDMA/vmw_pvrdma: Fix double free on pvrdma_alloc_ucontext() error path commit e38e86995df27f1f854063dab1f0c6a513db3faf upstream. Sashiko points out that pvrdma_uar_free() is already called within pvrdma_dealloc_ucontext(), so calling it before triggers a double free. Cc: stable@vger.kernel.org Fixes: 29c8d9eba550 ("IB: Add vmw_pvrdma driver") Link: https://sashiko.dev/#/patchset/0-v1-e911b76a94d1%2B65d95-rdma_udata_rep_jgg%40nvidia.com?part=4 Link: https://patch.msgid.link/r/10-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 006a3a5f75345c6a0dbf13fd3ee01406e93b6733 Author: Michael Bommarito Date: Tue Apr 14 07:15:55 2026 -0400 RDMA/rxe: Reject unknown opcodes before ICRC processing commit 4c6f86d85d03cdb33addce86aa69aa795ca6c47a upstream. Even after applying commit 7244491dab34 ("RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv"), a single unauthenticated UDP packet can still trigger panic. That patch handled payload_size() underflow only for valid opcodes with short packets, not for packets carrying an unknown opcode. The unknown-opcode OOB read described below predates that commit and reaches back to the initial Soft RoCE driver. The check added there reads pkt->paylen < header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE where header_size(pkt) expands to rxe_opcode[pkt->opcode].length. The rxe_opcode[] array has 256 entries but is only populated for defined IB opcodes; any other entry (for example opcode 0xff) is zero-initialized, so length == 0 and the check degenerates to pkt->paylen < 0 + bth_pad(pkt) + RXE_ICRC_SIZE which does not constrain pkt->paylen enough. rxe_icrc_hdr() then computes rxe_opcode[pkt->opcode].length - RXE_BTH_BYTES which underflows when length == 0 and passes a huge value to rxe_crc32(), causing an out-of-bounds read of the skb payload. Reproduced on v7.0-rc7 with that fix applied, QEMU/KVM with CONFIG_RDMA_RXE=y and CONFIG_KASAN=y, after rdma link add rxe0 type rxe netdev eth0 A single 48-byte UDP packet to port 4791 with BTH opcode=0xff and QPN=IB_MULTICAST_QPN triggers: BUG: KASAN: slab-out-of-bounds in crc32_le+0x115/0x170 Read of size 1 at addr ... The buggy address is located 0 bytes to the right of allocated 704-byte region Call Trace: crc32_le+0x115/0x170 rxe_icrc_hdr.isra.0+0x226/0x300 rxe_icrc_check+0x13f/0x3a0 rxe_rcv+0x6e1/0x16e0 rxe_udp_encap_recv+0x20a/0x320 udp_queue_rcv_one_skb+0x7ed/0x12c0 Subsequent packets with the same shape fault on unmapped memory and panic the kernel. The trigger requires only module load and "rdma link add"; no QP, no connection, and no authentication. Fix this by rejecting packets whose opcode has no rxe_opcode[] entry, detected via the zero mask or zero length, before any length arithmetic runs. Cc: stable@vger.kernel.org Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://patch.msgid.link/r/20260414111555.3386793-1-michael.bommarito@gmail.com Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Michael Bommarito Reviewed-by: Zhu Yanjun Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 105bf79a23b85cf3a761d18a4f3e10ce88526bc1 Author: Michael Bommarito Date: Sat Apr 18 12:21:41 2026 -0400 RDMA/rxe: Reject non-8-byte ATOMIC_WRITE payloads commit 1114c87aa6f195cf07da55a27b2122ae26557b26 upstream. atomic_write_reply() at drivers/infiniband/sw/rxe/rxe_resp.c unconditionally dereferences 8 bytes at payload_addr(pkt): value = *(u64 *)payload_addr(pkt); check_rkey() previously accepted an ATOMIC_WRITE request with pktlen == resid == 0 because the length validation only compared pktlen against resid. A remote initiator that sets the RETH length to 0 therefore reaches atomic_write_reply() with a zero-byte logical payload, and the responder reads sizeof(u64) bytes from past the logical end of the packet into skb->head tailroom, then writes those 8 bytes into the attacker's MR via rxe_mr_do_atomic_write(). That is a remote disclosure of 4 bytes of kernel tailroom per probe (the other 4 bytes are the packet's own trailing ICRC). IBA oA19-28 defines ATOMIC_WRITE as exactly 8 bytes. Anything else is protocol-invalid. Hoist a strict length check into check_rkey() so the responder never reaches the unchecked dereference, and keep the existing WRITE-family length logic for the normal RDMA WRITE path. Reproduced on mainline with an unmodified rxe driver: a sustained zero-length ATOMIC_WRITE probe repeatedly leaks adjacent skb head-buffer bytes into the attacker's MR, including recognisable kernel strings and partial kernel-direct-map pointer words. With this patch applied the responder rejects the PDU and the MR stays all-zero. Cc: stable@vger.kernel.org Fixes: 034e285f8b99 ("RDMA/rxe: Make responder support atomic write on RC service") Link: https://patch.msgid.link/r/20260418162141.3610201-1-michael.bommarito@gmail.com Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Reviewed-by: Zhu Yanjun Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 8832626a483439e207734e027afff322ccdf726e Author: Jason Gunthorpe Date: Tue Apr 28 13:17:42 2026 -0300 RDMA/ocrdma: Don't NULL deref uctx on errors in ocrdma_copy_pd_uresp() commit 34fbf48cf3b410d2a6e8c586fa952a36331ca5ba upstream. Sashiko points out that pd->uctx isn't initialized until late in the function so all these error flow references are NULL and will crash. Use the uctx that isn't NULL. Cc: stable@vger.kernel.org Fixes: fe2caefcdf58 ("RDMA/ocrdma: Add driver for Emulex OneConnect IBoE RDMA adapter") Link: https://sashiko.dev/#/patchset/0-v1-e911b76a94d1%2B65d95-rdma_udata_rep_jgg%40nvidia.com?part=4 Link: https://patch.msgid.link/r/9-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit b087913ae88256df66620f7ba0a9776716aeef7e Author: Junrui Luo Date: Fri Apr 24 13:51:02 2026 +0800 RDMA/mlx5: Fix error path fall-through in mlx5_ib_dev_res_srq_init() commit c488df06bd552bb8b6e14fa0cfd5ad986c6e9525 upstream. mlx5_ib_dev_res_srq_init() allocates two SRQs, s0 and s1. When ib_create_srq() fails for s1, the error branch destroys s0 but falls through and unconditionally assigns the freed s0 and the ERR_PTR s1 to devr->s0 and devr->s1. This leads to several problems: the lock-free fast path checks "if (devr->s1) return 0;" and treats the ERR_PTR as already initialised; users in mlx5_ib_create_qp() dereference the freed SRQ or ERR_PTR via to_msrq(devr->s0)->msrq.srqn; and mlx5_ib_dev_res_cleanup() dereferences the ERR_PTR and double-frees s0 on teardown. Fix by adding the same `goto unlock` in the s1 failure path. Cc: stable@vger.kernel.org Fixes: 5895e70f2e6e ("IB/mlx5: Allocate resources just before first QP/SRQ is created") Link: https://patch.msgid.link/r/SYBPR01MB7881E1E0970268BD69C0BA75AF2B2@SYBPR01MB7881.ausprd01.prod.outlook.com Reported-by: Yuhao Jiang Signed-off-by: Junrui Luo Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit e01b8c9286c470b71a38acd320106f2c4f2826a1 Author: Jason Gunthorpe Date: Tue Apr 28 13:17:44 2026 -0300 RDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq() commit c54c7e4cb679c0aaa1cb489b9c3f2cd98e63a44c upstream. Sashiko points out that mlx4_srq_alloc() was not undone during error unwind, add the missing call to mlx4_srq_free(). Cc: stable@vger.kernel.org Fixes: 225c7b1feef1 ("IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters") Link: https://sashiko.dev/#/patchset/0-v1-e911b76a94d1%2B65d95-rdma_udata_rep_jgg%40nvidia.com?part=8 Link: https://patch.msgid.link/r/11-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 1e2a44875b6afb4add1115f7f3351dcbeb6f273d Author: Jason Gunthorpe Date: Tue Apr 28 13:17:45 2026 -0300 RDMA/mlx4: Fix mis-use of RCU in mlx4_srq_event() commit c9341307ea16b9395c2e4c9c94d8499d91fe31d0 upstream. Sashiko points out the radix_tree itself is RCU safe, but nothing ever frees the mlx4_srq struct with RCU, and it isn't even accessed within the RCU critical section. It also will crash if an event is delivered before the srq object is finished initializing. Use the spinlock since it isn't easy to make RCU work, use refcount_inc_not_zero() to protect against partially initialized objects, and order the refcount_set() to be after the srq is fully initialized. Cc: stable@vger.kernel.org Fixes: 30353bfc43a1 ("net/mlx4_core: Use RCU to perform radix tree lookup for SRQ") Link: https://sashiko.dev/#/patchset/0-v2-1c49eeb88c48%2B91-rdma_udata_rep_jgg%40nvidia.com?part=5 Link: https://patch.msgid.link/r/12-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 012796f9541fcd0c1fa8ae4da7eb4d83931ef838 Author: Jason Gunthorpe Date: Tue Apr 28 13:17:37 2026 -0300 RDMA/mana: Validate rx_hash_key_len commit 6dd2d4ad9c8429523b1c220c5132bd551c006425 upstream. Sashiko points out that rx_hash_key_len comes from a uAPI structure and is blindly passed to memcpy, allowing the userspace to trash kernel memory. Bounds check it so the memcpy cannot overflow. Cc: stable@vger.kernel.org Fixes: 0266a177631d ("RDMA/mana_ib: Add a driver for Microsoft Azure Network Adapter") Link: https://sashiko.dev/#/patchset/0-v2-1c49eeb88c48%2B91-rdma_udata_rep_jgg%40nvidia.com?part=1 Link: https://patch.msgid.link/r/4-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com Reviewed-by: Long Li Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 9ef65af26b2a6738bf15812042e84b3112402d3a Author: Jason Gunthorpe Date: Tue Apr 28 13:17:38 2026 -0300 RDMA/mana: Remove user triggerable WARN_ON() in mana_ib_create_qp_rss() commit 159f2efabc89d3f931d38f2d35876535d4abf0a3 upstream. Sashiko points out that the user can specify WQs sharing the same CQ as a part of the uAPI and this will trigger the WARN_ON() then go on to corrupt the kernel. Just reject it outright and fail the QP creation. Cc: stable@vger.kernel.org Fixes: c15d7802a424 ("RDMA/mana_ib: Add CQ interrupt support for RAW QP") Link: https://sashiko.dev/#/patchset/0-v2-1c49eeb88c48%2B91-rdma_udata_rep_jgg%40nvidia.com?part=1 Link: https://patch.msgid.link/r/5-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com Reviewed-by: Long Li Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit bb9cb36eaefa4dcb7c0d9f7a01e5c739abdd53a8 Author: Jason Gunthorpe Date: Tue Apr 28 13:17:39 2026 -0300 RDMA/mana: Fix mana_destroy_wq_obj() cleanup in mana_ib_create_qp_rss() commit 34ecf795692ee57c393109f4a24ccc313091e137 upstream. Sashiko points out there are two bugs here in the error unwind flow, both related to how the WQ table is unwound. First there is a double i-- on the first failure path due to the while loop having a i--, remove it. Second if mana_ib_install_cq_cb() fails then mana_create_wq_obj() is not undone due to the above i--. Cc: stable@vger.kernel.org Fixes: c15d7802a424 ("RDMA/mana_ib: Add CQ interrupt support for RAW QP") Link: https://sashiko.dev/#/patchset/0-v2-1c49eeb88c48%2B91-rdma_udata_rep_jgg%40nvidia.com?part=1 Link: https://patch.msgid.link/r/6-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com Reviewed-by: Long Li Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit ab64c63b460bbd0521480bf90d5695783f5e66bc Author: Jason Gunthorpe Date: Tue Apr 28 13:17:40 2026 -0300 RDMA/mana: Fix error unwind in mana_ib_create_qp_rss() commit 6aaa978c6b6218cfac15fe1dab17c76fe229ce3f upstream. Sashiko points out that mana_ib_cfg_vport_steering() is leaked, the normal destroy path cleans it up. Cc: stable@vger.kernel.org Fixes: 0266a177631d ("RDMA/mana_ib: Add a driver for Microsoft Azure Network Adapter") Link: https://sashiko.dev/#/patchset/0-v1-e911b76a94d1%2B65d95-rdma_udata_rep_jgg%40nvidia.com?part=4 Link: https://patch.msgid.link/r/7-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com Reviewed-by: Long Li Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit d886bcdcd00d7fca1ccbde2466d356ee145c416b Author: Jason Gunthorpe Date: Tue Apr 28 13:17:34 2026 -0300 RDMA/ionic: Fix typo in format string commit 70f780edcd1e86350202d8a409de026b2d2e2067 upstream. Applying the corrupted patch by hand mangled the format string, put the s in the right place. Cc: stable@vger.kernel.org Fixes: 654a27f25530 ("RDMA/ionic: bound node_desc sysfs read with %.64s") Link: https://patch.msgid.link/r/1-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com Reported-by: Brad Spengler Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 61df14f306f153bffa2f3c74a94ff5a85c99fa39 Author: Kai Zen Date: Tue Apr 7 12:20:22 2026 +0300 RDMA/ionic: bound node_desc sysfs read with %.64s commit 654a27f25530d052eeedf086e6c3e2d585c203bd upstream. node_desc[64] in struct ib_device is not guaranteed to be NUL- terminated. The core IB sysfs handler uses "%.64s" for exactly this reason (drivers/infiniband/core/sysfs.c:1307), since node_desc_store() performs a raw memcpy of up to IB_DEVICE_NODE_DESC_MAX bytes with no NUL termination: memcpy(desc.node_desc, buf, min_t(int, count, IB_DEVICE_NODE_DESC_MAX)); If exactly 64 bytes are written via the node_desc sysfs file, the array contains no NUL byte. The ionic hca_type_show() handler uses unbounded "%s" and will read past the end of node_desc into adjacent fields of struct ib_device until it encounters a NUL. ionic supports IB_DEVICE_MODIFY_NODE_DESC, so this is triggerable by userspace. Match the core handler and bound the format specifier. Cc: stable@vger.kernel.org Fixes: 2075bbe8ef03 ("RDMA/ionic: Register device ops for miscellaneous functionality") Link: https://patch.msgid.link/r/CALynFi7NAbhDCt1tdaDbf6TnLvAqbaHa6-Wqf6OkzREbA_PAfg@mail.gmail.com Signed-off-by: Kai Aizen Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 44905248dd87ee233c8a2fcc23cd6909b92cf6d1 Author: Dapeng Mi Date: Thu Apr 30 08:25:55 2026 +0800 perf/x86/intel: Always reprogram ACR events to prevent stale masks commit 8ba0b706a485b1e607594cf4210786d517ad1611 upstream. Members of an ACR group are logically linked via a bitmask of their hardware counter indices. If some members of the group are assigned new hardware counters during rescheduling, even events that keep their original counter index must be updated with a new mask. Without this, an event will continue to use a stale acr_mask that references the old indices of its group peers. Ensure all ACR events are reprogrammed during the scheduling path to maintain consistency across the group. Fixes: ec980e4facef ("perf/x86/intel: Support auto counter reload") Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260430002558.712334-3-dapeng1.mi@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 2546fb8c9acc8c7512ed4339ce2a982cb7407065 Author: Nilay Shroff Date: Wed Mar 11 19:13:31 2026 +0530 powerpc/xive: fix kmemleak caused by incorrect chip_data lookup commit 6771c54728c278bf1e4bfdab4fddbbb186e33498 upstream. The kmemleak reports the following memory leak: Unreferenced object 0xc0000002a7fbc640 (size 64): comm "kworker/8:1", pid 540, jiffies 4294937872 hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 09 04 00 04 00 00 ................ 00 00 a7 81 00 00 0a c0 00 00 08 04 00 04 00 00 ................ backtrace (crc 177d48f6): __kmalloc_cache_noprof+0x520/0x730 xive_irq_alloc_data.constprop.0+0x40/0xe0 xive_irq_domain_alloc+0xd0/0x1b0 irq_domain_alloc_irqs_parent+0x44/0x6c pseries_irq_domain_alloc+0x1cc/0x354 irq_domain_alloc_irqs_parent+0x44/0x6c msi_domain_alloc+0xb0/0x220 irq_domain_alloc_irqs_locked+0x138/0x4d0 __irq_domain_alloc_irqs+0x8c/0xfc __msi_domain_alloc_irqs+0x214/0x4d8 msi_domain_alloc_irqs_all_locked+0x70/0xf8 pci_msi_setup_msi_irqs+0x60/0x78 __pci_enable_msix_range+0x54c/0x98c pci_alloc_irq_vectors_affinity+0x16c/0x1d4 nvme_pci_enable+0xac/0x9c0 [nvme] nvme_probe+0x340/0x764 [nvme] This occurs when allocating MSI-X vectors for an NVMe device. During allocation the XIVE code creates a struct xive_irq_data and stores it in irq_data->chip_data. When the MSI-X irqdomain is later freed, xive_irq_free_data() is responsible for retrieving this structure and freeing it. However, after commit cc0cc23babc9 ("powerpc/xive: Untangle xive from child interrupt controller drivers"), xive_irq_free_data() retrieves the chip_data using irq_get_chip_data(), which looks up the data through the child domain. This is incorrect because the XIVE-specific irq data is associated with the XIVE (parent) domain. As a result the lookup fails and the allocated struct xive_irq_data is never freed, leading to the kmemleak report shown above. Fix this by retrieving the irq_data from the correct domain using irq_domain_get_irq_data() and then accessing the chip_data via irq_data_get_irq_chip_data(). Cc: stable@vger.kernel.org Fixes: cc0cc23babc9 ("powerpc/xive: Untangle xive from child interrupt controller drivers") Signed-off-by: Nilay Shroff Tested-by: Venkat Rao Bagalkote Reviewed-by: Nam Cao Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260311134336.326996-1-nilay@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 4b6886ca8114797ba80afe82ea67f877cf2f26fb Author: André Draszik Date: Mon Mar 2 13:32:05 2026 +0000 power: supply: max17042: avoid overflow when determining health commit 9a44949da669708f19d29141e65b3ac774d08f5a upstream. If vmax has the default value of INT_MAX (e.g. because not specified in DT), battery health is reported as over-voltage. This is because adding any value to vmax (the vmax tolerance in this case) causes it to wrap around, making it negative and smaller than the measured battery voltage. Avoid that by using size_add(). Fixes: edd4ab055931 ("power: max17042_battery: add HEALTH and TEMP_* properties support") Cc: stable@vger.kernel.org Signed-off-by: André Draszik Link: https://patch.msgid.link/20260302-max77759-fg-v3-6-3c5f01dbda23@linaro.org Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 1bf238ead7cc05519759ec80882886be9348656b Author: Lukas Wunner Date: Mon Feb 16 08:46:13 2026 +0100 PCI/ASPM: Fix pci_clear_and_set_config_dword() usage commit cc33985d26c92a5c908c0185239c59ec35b8637c upstream. When aspm_calc_l12_info() programs the L1 PM Substates Control 1 register fields Common_Mode_Restore_Time, LTR_L1.2_THRESHOLD_Value and _Scale, it invokes pci_clear_and_set_config_dword() in an incorrect way: For the bits to clear it selects those corresponding to the field. So far so good. But for the bits to set it passes a full register value. pci_clear_and_set_config_dword() performs a boolean OR operation which sets all bits of that value, not just the ones that were just cleared. Thus, when setting the LTR_L1.2_THRESHOLD_Value and _Scale on the child of an ASPM link, aspm_calc_l12_info() also sets the Common_Mode_Restore_Time. That's a spec violation: PCIe r7.0 sec 7.8.3.3 says this field is RsvdP for Upstream Ports. On Adrià's Pixelbook Eve, Common_Mode_Restore_Time of the Intel 7265 "Stone Peak" wifi card is zero, yet aspm_calc_l12_info() does not preserve the zero bits but instead programs the value calculated for the Root Port into the wifi card. Likewise, when setting the Common_Mode_Restore_Time on the Root Port, aspm_calc_l12_info() also changes the LTR_L1.2_THRESHOLD_Value and _Scale from the initial 163840 nsec to 237568 nsec (due to ORing those fields), only to reduce it afterwards to 106496 nsec. Amend all invocations of pci_clear_and_set_config_dword() to only set bits which are cleared. Finally, when setting the T_POWER_ON_Value and _Scale on the Root Port and the wifi card, aspm_calc_l12_info() fails to preserve bits declared RsvdP and instead overwrites them with zeroes. Replace pci_write_config_dword() with pci_clear_and_set_config_dword() to avoid this. Fixes: aeda9adebab8 ("PCI/ASPM: Configure L1 substate settings") Link: https://bugzilla.kernel.org/show_bug.cgi?id=220705#c22 Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Tested-by: Adrià Vilanova Martínez Cc: stable@vger.kernel.org # v4.11+ Link: https://patch.msgid.link/5c1752d7512eed0f4ea57b84b12d7ee08ca61fc5.1771226659.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman commit 24582f5044bf9e7deff923efa2bc364eb612268c Author: Lukas Wunner Date: Fri Mar 27 10:56:43 2026 +0100 PCI/AER: Stop ruling out unbound devices as error source commit 1ab4a3c805084d752ec571efc78272295a9f2f74 upstream. When searching for the error source, the AER driver rules out devices whose enable_cnt is zero. This was introduced in 2009 by commit 28eb27cf0839 ("PCI AER: support invalid error source IDs") without providing a rationale. Drivers typically call pci_enable_device() on probe, hence the enable_cnt check essentially filters out unbound devices. At the time of the commit, drivers had to opt in to AER by calling pci_enable_pcie_error_reporting() and so any AER-enabled device could be assumed to be bound to a driver. The check thus made sense because it allowed skipping config space accesses to devices which were known not to be the error source. But since 2022, AER is universally enabled on all devices when they are enumerated, cf. commit f26e58bf6f54 ("PCI/AER: Enable error reporting when AER is native"). Errors may very well be reported by unbound devices, e.g. due to link instability. By ruling them out as error source, errors reported by them are neither logged nor cleared. When they do get bound and another error occurs, the earlier error is reported together with the new error, which may confuse users. Stop doing so. Fixes: f26e58bf6f54 ("PCI/AER: Enable error reporting when AER is native") Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Reviewed-by: Stefan Roese Cc: stable@vger.kernel.org # v6.0+ Link: https://patch.msgid.link/734338c2e8b669db5a5a3b45d34131b55ffebfca.1774605029.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman commit 70a5d28dd27320bb5a793787b0b7e4625d4228de Author: Shuai Xue Date: Wed Feb 11 20:46:24 2026 +0800 PCI/AER: Clear only error bits in PCIe Device Status commit a8aeea1bf3c80cc87983689e0118770e019bd4f3 upstream. Currently, pcie_clear_device_status() clears the entire PCIe Device Status register (PCI_EXP_DEVSTA) by writing back the value read from the register, which affects not only the error status bits but also other writable bits. According to PCIe r7.0, sec 7.5.3.5, this register contains: - RW1C error status bits (CED, NFED, FED, URD at bits 0-3): These are the four error status bits that need to be cleared. - Read-only bits (AUXPD at bit 4, TRPND at bit 5): Writing to these has no effect. - Emergency Power Reduction Detected (bit 6): A RW1C non-error bit introduced in PCIe r5.0 (2019). This is currently the only writable non-error bit in the Device Status register. Unconditionally clearing this bit can interfere with other software components that rely on this power management indication. - Reserved bits (RsvdZ): These bits are required to be written as zero. Writing 1s to them (as the current implementation may do) violates the specification. To prevent unintended side effects, modify pcie_clear_device_status() to only write 1s to the four error status bits (CED, NFED, FED, URD), leaving the Emergency Power Reduction Detected bit and reserved bits unaffected. Fixes: ec752f5d54d7 ("PCI/AER: Clear device status bits during ERR_FATAL and ERR_NONFATAL") Suggested-by: Lukas Wunner Signed-off-by: Shuai Xue Signed-off-by: Bjorn Helgaas Reviewed-by: Kuppuswamy Sathyanarayanan Reviewed-by: Lukas Wunner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260211124624.49656-1-xueshuai@linux.alibaba.com Signed-off-by: Greg Kroah-Hartman commit 185d51ec3a54a1fc368908eafbec4d663eb5fdfb Author: Lukas Wunner Date: Wed Apr 15 17:56:06 2026 +0200 PCI: Update saved_config_space upon resource assignment commit 909f7bf9b080c10df3c3b38533906dbf09ff1d8b upstream. Bernd reports passthrough failure of a Digital Devices Cine S2 V6 DVB adapter plugged into an ASRock X570S PG Riptide board with BIOS version P5.41 (09/07/2023): ddbridge 0000:05:00.0: detected Digital Devices Cine S2 V6 DVB adapter ddbridge 0000:05:00.0: cannot read registers ddbridge 0000:05:00.0: fail BIOS assigns an incorrect BAR to the DVB adapter which doesn't fit into the upstream bridge window. The kernel corrects the BAR assignment: pci 0000:07:00.0: BAR 0 [mem 0xfffffffffc500000-0xfffffffffc50ffff 64bit]: can't claim; no compatible bridge window pci 0000:07:00.0: BAR 0 [mem 0xfc500000-0xfc50ffff 64bit]: assigned Correction of the BAR assignment happens in an x86-specific fs_initcall, pcibios_assign_resources(), after device enumeration in a subsys_initcall. This order was introduced at the behest of Linus in 2004: https://git.kernel.org/tglx/history/c/a06a30144bbc No other architecture performs such a late BAR correction. Bernd bisected the issue to commit a2f1e22390ac ("PCI/ERR: Ensure error recoverability at all times"), but it only occurs in the absence of commit 4d4c10f763d7 ("PCI: Explicitly put devices into D0 when initializing"). This combination exists in stable kernel v6.12.70, but not in mainline, hence Bernd cannot reproduce the issue with mainline. Since a2f1e22390ac, config space is saved on enumeration, prior to BAR correction. Upon passthrough, the corrected BAR is overwritten with the incorrect saved value by: vfio_pci_core_register_device() vfio_pci_set_power_state() pci_restore_state() But only if the device's current_state is PCI_UNKNOWN, as it was prior to commit 4d4c10f763d7. Since the commit, it is PCI_D0, which changes the behavior of vfio_pci_set_power_state() to no longer restore the state without saving it first. Alexandre is reporting the same issue as Bernd, but in his case, mainline is affected as well. The difference is that on Alexandre's system, the host kernel binds a driver to the device which is unbound prior to passthrough, whereas on Bernd's system no driver gets bound by the host kernel. Unbinding sets current_state to PCI_UNKNOWN in pci_device_remove(), so when vfio-pci is subsequently bound to the device, pci_restore_state() is once again called without invoking pci_save_state() first. To robustly fix the issue, always update saved_config_space upon resource assignment. Reported-by: Bernd Schumacher Closes: https://lore.kernel.org/r/acfZrlP0Ua_5D3U4@eldamar.lan/ Reported-by: Alexandre N. Closes: https://lore.kernel.org/r/dd3c3358-de0f-4a56-9c81-04aceaab4058@mailo.com/ Fixes: a2f1e22390ac ("PCI/ERR: Ensure error recoverability at all times") Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Tested-by: Bernd Schumacher Tested-by: Alexandre N. Cc: stable@vger.kernel.org # v6.12+ Link: https://patch.msgid.link/febc3f354e0c1f5a9f5b3ee9ffddaa44caccf651.1776268054.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman commit eafd6f5372d29b0dd213799b92c2c9c7ad31d7da Author: SeongJae Park Date: Thu Apr 23 08:02:51 2026 -0700 mm/damon/sysfs-schemes: protect memcg_path kfree() with damon_sysfs_lock commit 1e68eb96e8beb1abefd12dd22c5637795d8a877e upstream. Patch series "mm/damon/sysfs-schemes: fix use-after-free for [memcg_]path". Reads of 'memcg_path' and 'path' files in DAMON sysfs interface could race with their writes, results in use-after-free. Fix those. This patch (of 2): damon_sysfs_scheme_filter->mmecg_path can be read and written by users, via DAMON sysfs memcg_path file. It can also be indirectly read, for the parameters {on,off}line committing to DAMON. The reads for parameters committing are protected by damon_sysfs_lock to avoid the sysfs files being destroyed while any of the parameters are being read. But the user-driven direct reads and writes are not protected by any lock, while the write is deallocating the memcg_path-pointing buffer. As a result, the readers could read the already freed buffer (user-after-free). Note that the user-reads don't race when the same open file is used by the writer, due to kernfs's open file locking. Nonetheless, doing the reads and writes with separate open files would be common. Fix it by protecting both the user-direct reads and writes with damon_sysfs_lock. Link: https://lore.kernel.org/20260423150253.111520-1-sj@kernel.org Link: https://lore.kernel.org/20260423150253.111520-2-sj@kernel.org Fixes: 4f489fe6afb3 ("mm/damon/sysfs-schemes: free old damon_sysfs_scheme_filter->memcg_path on write") Co-developed-by: Junxi Qian Signed-off-by: Junxi Qian Signed-off-by: SeongJae Park Cc: # 6.16.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit cb825c22c00268823801e21ea8d7dd1e4d72adfd Author: SeongJae Park Date: Sun Apr 19 09:10:02 2026 -0700 mm/damon/stat: detect and use fresh enabled value commit f98590bc08d4aea435e1c2213e38bae0d9e9a7bb upstream. DAMON_STAT updates 'enabled' parameter value, which represents the running status of its kdamond, when the user explicitly requests start/stop of the kdamond. The kdamond can, however, be stopped even if the user explicitly requested the stop, if ctx->regions_score_histogram allocation failure at beginning of the execution of the kdamond. Hence, if the kdamond is stopped by the allocation failure, the value of the parameter can be stale. Users could show the stale value and be confused. The problem will only rarely happen in real and common setups because the allocation is arguably too small to fail. Also, unlike the similar bugs that are now fixed in DAMON_RECLAIM and DAMON_LRU_SORT, kdamond can be restarted in this case, because DAMON_STAT force-updates the enabled parameter value for user inputs. The bug is a bug, though. The issue stems from the fact that there are multiple events that can change the status, and following all the events is challenging. Dynamically detect and use the fresh status for the parameters when those are requested. The issue was dicovered [1] by Sashiko. Link: https://lore.kernel.org/20260419161003.79176-4-sj@kernel.org Link: https://lore.kernel.org/20260416040602.88665-1-sj@kernel.org [1] Fixes: 369c415e6073 ("mm/damon: introduce DAMON_STAT module") Signed-off-by: SeongJae Park Cc: Liew Rui Yan Cc: # 6.17.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit bb1703949dcaa9a49c338dee075f659f4634214d Author: Paolo Bonzini Date: Sun May 3 19:19:32 2026 +0200 KVM: x86: Do IRR scan in __kvm_apic_update_irr even if PIR is empty commit 33fd0ccd2590b470b65adcca288615ad3b5e3e06 upstream. Fall back to apic_find_highest_vector() when PID.ON is set but PIR turns out to be empty, to correctly report the highest pending interrupt from the existing IRR. In a nested VM stress test, the following WARNING fires in vmx_check_nested_events() when kvm_cpu_has_interrupt() reports a pending interrupt but the subsequent kvm_apic_has_interrupt() (which invokes vmx_sync_pir_to_irr() again) returns -1: WARNING: CPU: 99 PID: 57767 at arch/x86/kvm/vmx/nested.c:4449 vmx_check_nested_events+0x6bf/0x6e0 [kvm_intel] Call Trace: kvm_check_and_inject_events vcpu_enter_guest.constprop.0 vcpu_run kvm_arch_vcpu_ioctl_run kvm_vcpu_ioctl __x64_sys_ioctl do_syscall_64 entry_SYSCALL_64_after_hwframe The root cause is a race between vmx_sync_pir_to_irr() on the target vCPU and __vmx_deliver_posted_interrupt() on a sender vCPU. The sender performs two individually-atomic operations that are not a single transaction: 1. pi_test_and_set_pir(vector) -- sets the PIR bit 2. pi_test_and_set_on() -- sets PID.ON The following interleaving triggers the bug: Sender vCPU (IPI): Target vCPU (1st sync_pir_to_irr): B1: set PIR[vector] A1: pi_clear_on() A2: pi_harvest_pir() -> sees B1 bit A3: xchg() -> consumes bit, PIR=0 (1st sync returns correct max_irr) B2: set PID.ON = 1 Target vCPU (2nd sync_pir_to_irr): C1: pi_test_on() -> TRUE (from B2) C2: pi_clear_on() -> ON=0 C3: pi_harvest_pir() -> PIR empty C4: *max_irr = -1, early return IRR NOT SCANNED The interrupt is not lost (it resides in the IRR from the first sync and is recovered on the next vcpu_enter_guest() iteration), but the incorrect max_irr causes a spurious WARNING and a wasted L2 VM-Enter/VM-Exit cycle. Fixes: b41f8638b9d3 ("KVM: VMX: Isolate pure loads from atomic XCHG when processing PIR") Reported-by: Farrah Chen Analyzed-by: Chenyi Qiang Cc: stable@vger.kernel.org Reviewed-by: Sean Christopherson Link: https://lore.kernel.org/kvm/20260428070349.1633238-1-chenyi.qiang@intel.com/T/ Link: https://patch.msgid.link/20260503201703.108231-2-pbonzini@redhat.com/ Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit d6f4e217d663ede5becc2fd6cb612c749677387b Author: Paolo Bonzini Date: Mon Apr 27 14:25:40 2026 +0200 KVM: x86: check for nEPT/nNPT in slow flush hypercalls commit 464af6fc2b1dcc74005b7f58ee3812b17777efee upstream. Checking is_guest_mode(vcpu) is incorrect, because translate_nested_gpa() is only valid if an L2 guest is running *with nested EPT/NPT enabled*. Instead use the same condition as translate_nested_gpa() itself. Cc: stable@vger.kernel.org Reviewed-by: Sean Christopherson Fixes: aee738236dca ("KVM: x86: Prepare kvm_hv_flush_tlb() to handle L2's GPAs", 2022-11-18) Link: https://patch.msgid.link/20260503200905.106077-1-pbonzini@redhat.com/ Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit c688f3ed73d31943334ad2139cb02ec49664322a Author: Michael Bommarito Date: Mon Apr 20 10:47:47 2026 -0400 smb: client: validate dacloffset before building DACL pointers commit f98b48151cc502ada59d9778f0112d21f2586ca3 upstream. parse_sec_desc(), build_sec_desc(), and the chown path in id_mode_to_cifs_acl() all add the server-supplied dacloffset to pntsd before proving a DACL header fits inside the returned security descriptor. On 32-bit builds a malicious server can return dacloffset near U32_MAX, wrap the derived DACL pointer below end_of_acl, and then slip past the later pointer-based bounds checks. build_sec_desc() and id_mode_to_cifs_acl() can then dereference DACL fields from the wrapped pointer in the chmod/chown rewrite paths. Validate dacloffset numerically before building any DACL pointer and reuse the same helper at the three DACL entry points. Fixes: bc3e9dd9d104 ("cifs: Change SIDs in ACEs while transferring file ownership.") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Michael Bommarito Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit be1ef9512a3f5a755895c24f31b334342f4aa15b Author: Bjoern Doebel Date: Thu Apr 30 08:57:17 2026 +0000 smb: client: use kzalloc to zero-initialize security descriptor buffer commit 5e489c6c47a2ac15edbaca153b9348e42c1eacab upstream. Commit 62e7dd0a39c2d ("smb: common: change the data type of num_aces to le16") split struct smb_acl's __le32 num_aces field into __le16 num_aces and __le16 reserved. The reserved field corresponds to Sbz2 in the MS-DTYP ACL wire format, which must be zero [1]. When building an ACL descriptor in build_sec_desc(), we are using a kmalloc()'ed descriptor buffer and writing the fields explicitly using le16() writes now. This never writes to the 2 byte reserved field, leaving it as uninitialized heap data. When the reserved field happens to contain non-zero slab garbage, Samba rejects the security descriptor with "ndr_pull_security_descriptor failed: Range Error", causing chmod to fail with EINVAL. Change kmalloc() to kzalloc() to ensure the entire buffer is zero-initialized. Fixes: 62e7dd0a39c2d ("smb: common: change the data type of num_aces to le16") Cc: stable@vger.kernel.org Signed-off-by: Bjoern Doebel Assisted-by: Kiro:claude-opus-4.6 [1] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/20233ed8-a6c6-4097-aafa-dd545ed24428 Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit b8c8a704f0bc133deb171f6aeb6f3a684203e212 Author: Zisen Ye Date: Sat May 2 18:48:36 2026 +0800 smb/client: fix out-of-bounds read in symlink_data() commit d62b8d236fab503c6fec1d3e9a38bea71feaca20 upstream. Since smb2_check_message() returns success without length validation for the symlink error response, in symlink_data() it is possible for iov->iov_len to be smaller than sizeof(struct smb2_err_rsp). If the buffer only contains the base SMB2 header (64 bytes), accessing err->ErrorContextCount (at offset 66) or err->ByteCount later in symlink_data() will cause an out-of-bounds read. Link: https://lore.kernel.org/linux-cifs/297d8d9b-adf7-42fd-a1c2-5b1f230032bc@chenxiaosong.com/ Fixes: 76894f3e2f71 ("cifs: improve symlink handling for smb2+") Cc: Stable@vger.kernel.org Signed-off-by: Zisen Ye Reviewed-by: ChenXiaoSong Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 512d33bc8ea4ea5c19728ee118715f4b1f4d1926 Author: Zisen Ye Date: Wed May 6 11:49:08 2026 +0800 smb/client: fix out-of-bounds read in smb2_compound_op() commit 8d09328dfda089675e4c049f3f256064a1d1996b upstream. If a server sends a truncated response but a large OutputBufferLength, and terminates the EA list early, check_wsl_eas() returns success without validating that the entire OutputBufferLength fits within iov_len. Then smb2_compound_op() does: memcpy(idata->wsl.eas, data[0], size[0]); Where size[0] is OutputBufferLength. If iov_len is smaller than size[0], memcpy can read beyond the end of the rsp_iov allocation and leak adjacent kernel heap memory. Link: https://lore.kernel.org/linux-cifs/d998240c-aca9-420d-9dbd-f5ba24af19e0@chenxiaosong.com/ Fixes: ea41367b2a60 ("smb: client: introduce SMB2_OP_QUERY_WSL_EA") Cc: stable@vger.kernel.org Signed-off-by: Zisen Ye Reviewed-by: ChenXiaoSong Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 45dcc815fc5539e88154315f36cbcb11d3a52fc2 Author: Ranjan Kumar Date: Tue Apr 14 16:38:11 2026 +0530 scsi: mpt3sas: Limit NVMe request size to 2 MiB commit 04631f55afc543d5431a2bdee7f6cc0f2c0debe7 upstream. The HBA firmware reports NVMe MDTS values based on the underlying drive capability. However, because the driver allocates a fixed 4K buffer for the PRP list, accommodating at most 512 entries, the driver supports a maximum I/O transfer size of 2 MiB. Limit max_hw_sectors to the smaller of the reported MDTS and the 2 MiB driver limit to prevent issuing oversized I/O that may lead to a kernel oops. Cc: stable@vger.kernel.org Fixes: 9b8b84879d4a ("block: Increase BLK_DEF_MAX_SECTORS_CAP") Reported-by: Mira Limbeck Closes: https://lore.kernel.org/r/291f78bf-4b4a-40dd-867d-053b36c564b3@proxmox.com Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9b8b84879d4a Suggested-by: Keith Busch Signed-off-by: Ranjan Kumar Tested-by: Mira Limbeck Link: https://patch.msgid.link/20260414110811.85156-1-ranjan.kumar@broadcom.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit cf90a96b7a2d769c2ec88048f94b33539a362bf5 Author: Pengpeng Hou Date: Fri Apr 17 15:35:30 2026 +0800 s390/debug: Reject zero-length input before trimming a newline commit c366a7b5ed7564e41345c380285bd3f6cb98971b upstream. debug_get_user_string() duplicates the userspace buffer with memdup_user_nul() and then unconditionally looks at buffer[user_len - 1] to strip a trailing newline. A zero-length write reaches this helper unchanged, so the newline trim reads before the start of the allocated buffer. Reject empty writes before accessing the last input byte. Fixes: 66a464dbc8e0 ("[PATCH] s390: debug feature changes") Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou Reviewed-by: Benjamin Block Reviewed-by: Vasily Gorbik Tested-by: Vasily Gorbik Link: https://lore.kernel.org/r/20260417073530.96002-1-pengpeng@iscas.ac.cn Signed-off-by: Vasily Gorbik Signed-off-by: Alexander Gordeev Signed-off-by: Greg Kroah-Hartman commit e3eee7ea5ec57c1910afc45dbe3301b21dee1ebb Author: Vasily Gorbik Date: Fri Apr 17 14:33:43 2026 +0200 s390/debug: Reject zero-length input in debug_input_flush_fn() commit e14622a7584f9608927c59a7d6ae4a0999dc545e upstream. debug_input_flush_fn() always copies one byte from the userspace buffer with copy_from_user() regardless of the supplied write length. A zero-length write therefore reads one byte beyond the caller's buffer. If the stale byte happens to be '-' or a digit the debug log is silently flushed. With an unmapped buffer the call returns -EFAULT. Reject zero-length writes before copying from userspace. Cc: stable@vger.kernel.org # v5.10+ Acked-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Alexander Gordeev Signed-off-by: Greg Kroah-Hartman commit bd62c0f61bc722a097417401030c596cea8e21aa Author: Osama Abdelkader Date: Mon Mar 16 16:16:11 2026 +0100 riscv: kvm: fix vector context allocation leak commit b7c958d7c1eb1cb9b2be7b5ee4129fcd66cec978 upstream. When the second kzalloc (host_context.vector.datap) fails in kvm_riscv_vcpu_alloc_vector_context, the first allocation (guest_context.vector.datap) is leaked. Free it before returning. Fixes: 0f4b82579716 ("riscv: KVM: Add vector lazy save/restore support") Cc: stable@vger.kernel.org Signed-off-by: Osama Abdelkader Reviewed-by: Andy Chiu Link: https://lore.kernel.org/r/20260316151612.13305-1-osama.abdelkader@gmail.com Signed-off-by: Anup Patel Signed-off-by: Greg Kroah-Hartman commit 1912f78798505dc9c637081bbddfbf1c22494c49 Author: Jason Gunthorpe Date: Tue Apr 28 13:17:48 2026 -0300 RDMA/hns: Fix unlocked call to hns_roce_qp_remove() commit 0c99acbc8b6c6dd526ae475a48ee1897b61072fb upstream. Sashiko points out that hns_roce_qp_remove() requires the caller to hold locks. The error flow in hns_roce_create_qp_common() doesn't hold those locks for the error unwind so it risks corrupting memory. Grab the same locks the other two callers use. Cc: stable@vger.kernel.org Fixes: e088a685eae9 ("RDMA/hns: Support rq record doorbell for the user space") Link: https://sashiko.dev/#/patchset/0-v2-1c49eeb88c48%2B91-rdma_udata_rep_jgg%40nvidia.com?part=9 Link: https://patch.msgid.link/r/15-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com Reviewed-by: Junxian Huang Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit ac4bf66686bbbd14f74f8c791e5849995fccfa56 Author: David Carlier Date: Sat May 2 15:19:45 2026 +0100 psp: strip variable-length PSP header in psp_dev_rcv() commit 30cb24f97d44f6b81c14b85c5323de62eef1fb7f upstream. psp_dev_rcv() unconditionally removes a fixed PSP_ENCAP_HLEN, even when psph->hdrlen indicates that the PSP header carries optional fields. A frame whose PSP header advertises a non-zero VC or any extension would therefore be silently mis-decapsulated: option bytes would spill into the inner packet head and downstream parsing would fail on a corrupted skb. Compute the full PSP header length from psph->hdrlen, pull the optional bytes into the linear region, and strip the whole header when decapsulating. Optional fields (VC, ...) are still ignored, just discarded with the rest of the header instead of leaking. crypt_offset and the VIRT flag are intentionally not validated here - callers know their device's PSP implementation and can decide. Both in-tree callers gate on hardware-validated PSP, so this is a correctness fix rather than a reachable corruption path under current configurations. Fixes: 0eddb8023cee ("psp: provide decapsulation and receive helper for drivers") Reviewed-by: Willem de Bruijn Reviewed-by: Daniel Zahka Cc: stable@vger.kernel.org Signed-off-by: David Carlier Link: https://patch.msgid.link/20260502141945.14484-1-devnexen@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 51a7dd9cbae9210335ce398642ecaaa52c939eb5 Author: Ulf Hansson Date: Fri Apr 17 13:13:31 2026 +0200 pmdomain: core: Fix detach procedure for virtual devices in genpd commit 26735dfdd8930d9ef1fa92e590a9bf77726efdf6 upstream. If a device is attached to a PM domain through genpd_dev_pm_attach_by_id(), genpd calls pm_runtime_enable() for the corresponding virtual device that it registers. While this avoids boilerplate code in drivers, there is no corresponding call to pm_runtime_disable() in genpd_dev_pm_detach(). This means these virtual devices are typically detached from its genpd, while runtime PM remains enabled for them, which is not how things are designed to work. In worst cases it may lead to critical errors, like a NULL pointer dereference bug in genpd_runtime_suspend(), which was recently reported. For another case, we may end up keeping an unnecessary vote for a performance state for the device. To fix these problems, let's add this missing call to pm_runtime_disable() in genpd_dev_pm_detach(). Reported-by: Geert Uytterhoeven Closes: https://lore.kernel.org/all/CAMuHMdWapT40hV3c+CSBqFOW05aWcV1a6v_NiJYgoYi0i9_PDQ@mail.gmail.com/ Fixes: 3c095f32a92b ("PM / Domains: Add support for multi PM domains per device to genpd") Cc: stable@vger.kernel.org Tested-by: Geert Uytterhoeven Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 3df75fff46b1517eb479d8e6b8e3500763715dd0 Author: Ilya Maximets Date: Fri May 1 01:38:37 2026 +0200 openvswitch: vport: fix self-deadlock on release of tunnel ports commit aa69918bd418e700309fdd08509dba324fb24296 upstream. vports are used concurrently and protected by RCU, so netdev_put() must happen after the RCU grace period. So, either in an RCU call or after the synchronize_net(). The rtnl_delete_link() must happen under RTNL and so can't be executed in RCU context. Calling synchronize_net() while holding RTNL is not a good idea for performance and system stability under load in general, so calling netdev_put() in RCU call is the right solution here. However, when the device is deleted, rtnl_unlock() will call netdev_run_todo() and block until all the references are gone. In the current code this means that we never reach the call_rcu() and the vport is never freed and the reference is never released, causing a self-deadlock on device removal. Fix that by moving the rcu_call() before the rtnl_unlock(), so the scheduled RCU callback will be executed when synchronize_net() is called from the rtnl_unlock()->netdev_run_todo() while the RTNL itself is already released. Fixes: 6931d21f87bc ("openvswitch: defer tunnel netdev_put to RCU release") Cc: stable@vger.kernel.org Acked-by: Eelco Chaudron Signed-off-by: Ilya Maximets Acked-by: Aaron Conole Link: https://patch.msgid.link/20260430233848.440994-2-i.maximets@ovn.org Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 781f47d641432c26c19625b2cdd7f40825097592 Author: Chaitanya Kulkarni Date: Wed Apr 8 17:56:47 2026 -0700 nvmet: avoid recursive nvmet-wq flush in nvmet_ctrl_free commit aade8abd8b868b6ffa9697aadaea28ec7f65bee6 upstream. nvmet_tcp_release_queue_work() runs on nvmet-wq and can drop the final controller reference through nvmet_cq_put(). If that triggers nvmet_ctrl_free(), the teardown path flushes ctrl->async_event_work on the same nvmet-wq. Call chain: nvmet_tcp_schedule_release_queue() kref_put(&queue->kref, nvmet_tcp_release_queue) nvmet_tcp_release_queue() queue_work(nvmet_wq, &queue->release_work) <--- nvmet_wq process_one_work() nvmet_tcp_release_queue_work() nvmet_cq_put(&queue->nvme_cq) nvmet_cq_destroy() nvmet_ctrl_put(cq->ctrl) nvmet_ctrl_free() flush_work(&ctrl->async_event_work) <--- nvmet_wq Previously Scheduled by :- nvmet_add_async_event queue_work(nvmet_wq, &ctrl->async_event_work); This trips lockdep with a possible recursive locking warning. [ 5223.015876] run blktests nvme/003 at 2026-04-07 20:53:55 [ 5223.061801] loop0: detected capacity change from 0 to 2097152 [ 5223.072206] nvmet: adding nsid 1 to subsystem blktests-subsystem-1 [ 5223.088368] nvmet_tcp: enabling port 0 (127.0.0.1:4420) [ 5223.126086] nvmet: Created discovery controller 1 for subsystem nqn.2014-08.org.nvmexpress.discovery for NQN nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349. [ 5223.128453] nvme nvme1: new ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery", addr 127.0.0.1:4420, hostnqn: nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349 [ 5233.199447] nvme nvme1: Removing ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery" [ 5233.227718] ============================================ [ 5233.231283] WARNING: possible recursive locking detected [ 5233.234696] 7.0.0-rc3nvme+ #20 Tainted: G O N [ 5233.238434] -------------------------------------------- [ 5233.241852] kworker/u192:6/2413 is trying to acquire lock: [ 5233.245429] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90 [ 5233.251438] but task is already holding lock: [ 5233.255254] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0 [ 5233.261125] other info that might help us debug this: [ 5233.265333] Possible unsafe locking scenario: [ 5233.269217] CPU0 [ 5233.270795] ---- [ 5233.272436] lock((wq_completion)nvmet-wq); [ 5233.275241] lock((wq_completion)nvmet-wq); [ 5233.278020] *** DEADLOCK *** [ 5233.281793] May be due to missing lock nesting notation [ 5233.286195] 3 locks held by kworker/u192:6/2413: [ 5233.289192] #0: ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0 [ 5233.294569] #1: ffffc9000e2a7e40 ((work_completion)(&queue->release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x6e0 [ 5233.300128] #2: ffffffff82d7dc40 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530 [ 5233.304290] stack backtrace: [ 5233.306520] CPU: 4 UID: 0 PID: 2413 Comm: kworker/u192:6 Tainted: G O N 7.0.0-rc3nvme+ #20 PREEMPT(full) [ 5233.306524] Tainted: [O]=OOT_MODULE, [N]=TEST [ 5233.306525] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 5233.306527] Workqueue: nvmet-wq nvmet_tcp_release_queue_work [nvmet_tcp] [ 5233.306532] Call Trace: [ 5233.306534] [ 5233.306536] dump_stack_lvl+0x73/0xb0 [ 5233.306552] print_deadlock_bug+0x225/0x2f0 [ 5233.306556] __lock_acquire+0x13f0/0x2290 [ 5233.306563] lock_acquire+0xd0/0x300 [ 5233.306565] ? touch_wq_lockdep_map+0x26/0x90 [ 5233.306571] ? __flush_work+0x20b/0x530 [ 5233.306573] ? touch_wq_lockdep_map+0x26/0x90 [ 5233.306577] touch_wq_lockdep_map+0x3b/0x90 [ 5233.306580] ? touch_wq_lockdep_map+0x26/0x90 [ 5233.306583] ? __flush_work+0x20b/0x530 [ 5233.306585] __flush_work+0x268/0x530 [ 5233.306588] ? __pfx_wq_barrier_func+0x10/0x10 [ 5233.306594] ? xen_error_entry+0x30/0x60 [ 5233.306600] nvmet_ctrl_free+0x140/0x310 [nvmet] [ 5233.306617] nvmet_cq_put+0x74/0x90 [nvmet] [ 5233.306629] nvmet_tcp_release_queue_work+0x19f/0x360 [nvmet_tcp] [ 5233.306634] process_one_work+0x206/0x6e0 [ 5233.306640] worker_thread+0x184/0x320 [ 5233.306643] ? __pfx_worker_thread+0x10/0x10 [ 5233.306646] kthread+0xf1/0x130 [ 5233.306648] ? __pfx_kthread+0x10/0x10 [ 5233.306651] ret_from_fork+0x355/0x450 [ 5233.306653] ? __pfx_kthread+0x10/0x10 [ 5233.306656] ret_from_fork_asm+0x1a/0x30 [ 5233.306664] There is also no need to flush async_event_work from controller teardown. The admin queue teardown already fails outstanding AER requests before the final controller put :- nvmet_sq_destroy(admin sq) nvmet_async_events_failall(ctrl) The controller has already been removed from the subsystem list before nvmet_ctrl_free() quiesces outstanding work. Replace flush_work() with cancel_work_sync() so a pending async_event_work item is canceled and a running instance is waited on without recursing into the same workqueue. Fixes: 06406d81a2d7 ("nvmet: cancel fatal error and flush async work before free controller") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Chaitanya Kulkarni Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 67e1aaf93b495c2f10bc8a5fbba575fbb7f449b6 Author: Chaitanya Kulkarni Date: Wed Apr 8 00:51:31 2026 -0700 nvmet-tcp: fix race between ICReq handling and queue teardown commit 5293a8882c549fab4a878bc76b0b6c951f980a61 upstream. nvmet_tcp_handle_icreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown. If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before io_work drains the already buffered ICReq. In that case, nvmet_tcp_schedule_release_queue() sets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue reference under state_lock. If io_work later processes that ICReq, nvmet_tcp_handle_icreq() can still overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and allows a later socket state change to re-enter teardown and issue a second kref_put() on an already released queue. The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMET_TCP_Q_FAILED, again reopening the window for a second teardown path to drop the queue reference. Fix this by serializing both post-send state transitions with state_lock and bailing out if teardown has already started. Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET. Keep nvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes. Fixes: c46a6465bac2 ("nvmet-tcp: add NVMe over TCP target driver") Cc: stable@vger.kernel.org Reported-by: Shivam Kumar Tested-by: Shivam Kumar Signed-off-by: Chaitanya Kulkarni Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit c77c82935c0a6869e73ef581621ab1c1900e14c7 Author: Fedor Pchelkin Date: Wed Apr 8 17:18:14 2026 +0300 nvme-apple: drop invalid put of admin queue reference count commit ba9d308ccd6732dd97ed8080d834a4a89e758e14 upstream. Commit 03b3bcd319b3 ("nvme: fix admin request_queue lifetime") moved the admin queue reference ->put call into nvme_free_ctrl() - a controller device release callback performed for every nvme driver doing nvme_init_ctrl(). nvme-apple sets refcount of the admin queue to 1 at allocation during the probe function and then puts it twice now: nvme_free_ctrl() blk_put_queue(ctrl->admin_q) // #1 ->free_ctrl() apple_nvme_free_ctrl() blk_put_queue(anv->ctrl.admin_q) // #2 Note that there is a commit 941f7298c70c ("nvme-apple: remove an extra queue reference") which intended to drop taking an extra admin queue reference. Looks like at that moment it accidentally fixed a refcount leak, which existed since the driver's introduction. There were two ->get calls at driver's probe function and a single ->put inside apple_nvme_free_ctrl(). However now after commit 03b3bcd319b3 ("nvme: fix admin request_queue lifetime") the refcount is imbalanced again. Fix it by removing extra ->put call from apple_nvme_free_ctrl(). anv->dev and ctrl->dev point to the same device, so use ctrl->dev directly for simplification. Compile tested only. Found by Linux Verification Center (linuxtesting.org). Fixes: 03b3bcd319b3 ("nvme: fix admin request_queue lifetime") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Fedor Pchelkin Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 913d556e4bd1b56ed822815655b82c7bb54edc51 Author: Junrui Luo Date: Thu Apr 16 11:39:56 2026 +0800 md/raid10: fix divide-by-zero in setup_geo() with zero far_copies commit 9aa6d860b0930e2f72795665c42c44252a558a0c upstream. setup_geo() extracts near_copies (nc) and far_copies (fc) from the user-provided layout parameter without checking for zero. When fc=0 with the "improved" far set layout selected, 'geo->far_set_size = disks / fc' triggers a divide-by-zero. Validate nc and fc immediately after extraction, returning -1 if either is zero. Fixes: 475901aff158 ("MD RAID10: Improve redundancy for 'far' and 'offset' algorithms (part 1)") Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Link: https://lore.kernel.org/linux-raid/SYBPR01MB7881A5E2556806CC1D318582AF232@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Yu Kuai Signed-off-by: Greg Kroah-Hartman commit b7df9fbd4869fdfe09a3f501ffd228486521e062 Author: Raphael Zimmer Date: Tue Apr 21 10:27:01 2026 +0200 libceph: Fix slab-out-of-bounds access in auth message processing commit 1c439de70b1c3eb3c6bffa8245c16b9fc318f114 upstream. If a (potentially corrupted) message of type CEPH_MSG_AUTH_REPLY contains a positive value in its result field, it is treated as an error code by ceph_handle_auth_reply() and returned to handle_auth_reply(). Thereafter, an attempt is made to send the preallocated message of type CEPH_MSG_AUTH, where the returned value is interpreted as the size of the front segment to send. If the result value in the message is greater than the size of the memory buffer allocated for the front segment, an out-of-bounds access occurs, and the content of the memory region beyond this buffer is sent out. This patch fixes the issue by treating only negative values in the result field as errors. Positive values are therefore treated as success in the same way as a zero value. Additionally, a BUG_ON is added to __send_prepared_auth_request() comparing the len parameter to front_alloc_len to prevent sending the message if it exceeds the bounds of the allocation and to make it easier to catch any logic flaws leading to this. Cc: stable@vger.kernel.org Signed-off-by: Raphael Zimmer Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 7cdf18608302fcb55054b0b0f76d0c1cc74af4b1 Author: Christian A. Ehrhardt Date: Thu Mar 26 22:49:02 2026 +0100 lib/scatterlist: fix temp buffer in extract_user_to_sg() commit 118cf3f55975352ac357fb194405031458186819 upstream. Instead of allocating a temporary buffer for extracted user pages extract_user_to_sg() uses the end of the to be filled scatterlist as a temporary buffer. Fix the calculation of the start address if the scatterlist already contains elements. The unused space starts at sgtable->sgl + sgtable->nents not directly at sgtable->nents and the temporary buffer is placed at the end of this unused space. A subsequent commit will add kunit test cases that demonstrate that the patch is necessary. Pointed out by sashiko.dev on a previous iteration of this series. Link: https://lkml.kernel.org/r/20260326214905.818170-3-lk@c--e.de Fixes: 018584697533 ("netfs: Add a function to extract an iterator into a scatterlist") Signed-off-by: Christian A. Ehrhardt Cc: David Howells Cc: David Gow Cc: Kees Cook Cc: Petr Mladek Cc: [v6.5+] Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 8fbba6829057979149d1b37d65690c037f3ddf4d Author: Christian A. Ehrhardt Date: Thu Mar 26 22:49:01 2026 +0100 lib/scatterlist: fix length calculations in extract_kvec_to_sg commit 07b7d66e65d9cfe6b9c2c34aa22cfcaac37a5c45 upstream. Patch series "Fix bugs in extract_iter_to_sg()", v3. Fix bugs in the kvec and user variants of extract_iter_to_sg. This series is growing due to useful remarks made by sashiko.dev. The main bugs are: - The length for an sglist entry when extracting from a kvec can exceed the number of bytes in the page. This is obviously not intended. - When extracting a user buffer the sglist is temporarily used as a scratch buffer for extracted page pointers. If the sglist already contains some elements this scratch buffer could overlap with existing entries in the sglist. The series adds test cases to the kunit_iov_iter test that demonstrate all of these bugs. Additionally, there is a memory leak fix for the test itself. The bugs were orignally introduced into kernel v6.3 where the function lived in fs/netfs/iterator.c. It was later moved to lib/scatterlist.c in v6.5. Thus the actual fix is only marked for backports to v6.5+. This patch (of 5): When extracting from a kvec to a scatterlist, do not cross page boundaries. The required length was already calculated but not used as intended. Adjust the copied length if the loop runs out of sglist entries without extracting everything. While there, return immediately from extract_iter_to_sg if there are no sglist entries at all. A subsequent commit will add kunit test cases that demonstrate that the patch is necessary. Link: https://lkml.kernel.org/r/20260326214905.818170-1-lk@c--e.de Link: https://lkml.kernel.org/r/20260326214905.818170-2-lk@c--e.de Fixes: 018584697533 ("netfs: Add a function to extract an iterator into a scatterlist") Signed-off-by: Christian A. Ehrhardt Cc: David Gow Cc: David Howells Cc: Kees Cook Cc: Petr Mladek Cc: [v6.5+] Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 8637dfb4c1d8a7026ef681f2477c6de8b71c4003 Author: Lukas Wunner Date: Sun Apr 12 16:19:47 2026 +0200 lib/crypto: mpi: Fix integer underflow in mpi_read_raw_from_sgl() commit 8c2f1288250a90a4b5cabed5d888d7e3aeed4035 upstream. Yiming reports an integer underflow in mpi_read_raw_from_sgl() when subtracting "lzeros" from the unsigned "nbytes". For this to happen, the scatterlist "sgl" needs to occupy more bytes than the "nbytes" parameter and the first "nbytes + 1" bytes of the scatterlist must be zero. Under these conditions, the while loop iterating over the scatterlist will count more zeroes than "nbytes", subtract the number of zeroes from "nbytes" and cause the underflow. When commit 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") originally introduced the bug, it couldn't be triggered because all callers of mpi_read_raw_from_sgl() passed a scatterlist whose length was equal to "nbytes". However since commit 63ba4d67594a ("KEYS: asymmetric: Use new crypto interface without scatterlists"), the underflow can now actually be triggered. When invoking a KEYCTL_PKEY_ENCRYPT system call with a larger "out_len" than "in_len" and filling the "in" buffer with zeroes, crypto_akcipher_sync_prep() will create an all-zero scatterlist used for both the "src" and "dst" member of struct akcipher_request and thereby fulfil the conditions to trigger the bug: sys_keyctl() keyctl_pkey_e_d_s() asymmetric_key_eds_op() software_key_eds_op() crypto_akcipher_sync_encrypt() crypto_akcipher_sync_prep() crypto_akcipher_encrypt() rsa_enc() mpi_read_raw_from_sgl() To the user this will be visible as a DoS as the kernel spins forever, causing soft lockup splats as a side effect. Fix it. Reported-by: Yiming Qian # off-list Fixes: 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") Signed-off-by: Lukas Wunner Cc: stable@vger.kernel.org # v4.4+ Reviewed-by: Ignat Korchagin Reviewed-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/59eca92ff4f87e2081777f1423a0efaaadcfdb39.1776003111.git.lukas@wunner.de Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit cbb032fc7432167df1abc1e4ef70407336ec1a24 Author: Nicolin Chen Date: Tue Mar 17 00:59:16 2026 -0700 iommu/arm-smmu-v3: Add a missing dma_wmb() for hitless STE update commit 6fabce53f6b9c2419012a9103e1a46d40888cefa upstream. When writing a new (previously invalid) valid IOPTE to a page table, then installing the page table into an STE hitlesslessly (e.g. in S2TTB field), there is a window before an STE invalidation, where the page-table may be accessed by SMMU but the new IOPTE is still siting in the CPU cache. This could occur when we allocate an iommu_domain and immediately install it hitlessly, while there would be no dma_wmb() for the page table memory prior to the earliest point of HW reading the STE. Fix it by adding a dma_wmb() prior to updating the STE. Fixes: 56e1a4cc2588 ("iommu/arm-smmu-v3: Add unit tests for arm_smmu_write_entry") Cc: stable@vger.kernel.org Reported-by: Will Deacon Closes: https://lore.kernel.org/linux-iommu/aXdlnLLFUBwjT0V5@willie-the-truck/ Suggested-by: Jason Gunthorpe Signed-off-by: Nicolin Chen Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 3ea9ce757bd3de955b56e7bc5672fc479e40b045 Author: Zhenzhong Duan Date: Thu Apr 2 14:57:24 2026 +0800 iommu/vt-d: Block PASID attachment to nested domain with dirty tracking commit cc5bd898ff70710ffc41cd8e5c2741cb64750047 upstream. Kernel lacks dirty tracking support on nested domain attached to PASID, fails the attachment early if nesting parent domain is dirty tracking configured, otherwise dirty pages would be lost. Cc: stable@vger.kernel.org Fixes: 67f6f56b5912 ("iommu/vt-d: Add set_dev_pasid callback for nested domain") Suggested-by: Kevin Tian Signed-off-by: Zhenzhong Duan Reviewed-by: Kevin Tian Reviewed-by: Yi Liu Link: https://lore.kernel.org/r/20260330101108.12594-2-zhenzhong.duan@intel.com Signed-off-by: Lu Baolu Fixes: 67f6f56b5912 ("iommu/vt-d: Add set_dev_pasid callback for nested domain") Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 0d96652adc8fd0ce2a02fe66fbebecd682a18fa8 Author: Zhenzhong Duan Date: Sun Mar 29 23:07:55 2026 -0400 iommufd: Fix return value of iommufd_fault_fops_write() commit aaca2aa92785a6ab8e3183e7184bca447a99cd76 upstream. copy_from_user() may return number of bytes failed to copy, we should not pass over this number to user space to cheat that write() succeed. Instead, -EFAULT should be returned. Link: https://patch.msgid.link/r/20260330030755.12856-1-zhenzhong.duan@intel.com Cc: stable@vger.kernel.org Fixes: 07838f7fd529 ("iommufd: Add iommufd fault object") Signed-off-by: Zhenzhong Duan Reviewed-by: Lu Baolu Reviewed-by: Pranjal Shrivastava Reviewed-by: Shuai Xue Reviewed-by: Kevin Tian Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit afbafeddf23db13fe2edb2d5c0bf4bbb13d7881b Author: Michael Bommarito Date: Sun Apr 19 17:21:55 2026 -0400 isofs: validate block number from NFS file handle in isofs_export_iget commit 24376458138387fb251e782e624c7776e9826796 upstream. isofs_fh_to_dentry() and isofs_fh_to_parent() pass an attacker- controlled block number (ifid->block or ifid->parent_block) from the NFS file handle to isofs_export_iget(), which only rejects block == 0 before calling isofs_iget() and ultimately sb_bread(). A crafted file handle with fh_len sufficient to pass the check added by commit 0405d4b63d08 ("isofs: Prevent the use of too small fid") can still drive the server to read any in-range block on the backing device as if it were an iso_directory_record. That earlier fix was assigned CVE-2025-37780. sb_bread() on an out-of-range block returns NULL cleanly via the EIO path, so there is no memory-safety violation. For in-range reads of adjacent-partition data on the same block device, the unrelated bytes end up in iso_inode_info fields that reach the NFS client as dentry metadata. The deployment surface (isofs exported over NFS from loop-mounted images) is narrow and requires an authenticated NFS peer, but the malformed-file-handle class is reportable as hardening next to the existing CVE-2025-37780 fix. Reject block >= ISOFS_SB(sb)->s_nzones in isofs_export_iget() so the check covers both isofs_fh_to_dentry() and isofs_fh_to_parent() call sites with a single line. Fixes: 0405d4b63d08 ("isofs: Prevent the use of too small fid") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260419212155.2169382-3-michael.bommarito@gmail.com Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit e69da8eeab74b4f4505024c38a17bce060fe7df8 Author: Michael Bommarito Date: Sun Apr 19 17:21:54 2026 -0400 isofs: validate Rock Ridge CE continuation extent against volume size commit a36d990f591320e9dd379ab30063ebfe91d47e1f upstream. rock_continue() reads rs->cont_extent verbatim from the Rock Ridge CE record and passes it to sb_bread() without checking that the block number is within the mounted ISO 9660 volume. commit e595447e177b ("[PATCH] rock.c: handle corrupted directories") added cont_offset and cont_size rejection for the CE continuation but did not validate the extent block number itself. commit f54e18f1b831 ("isofs: Fix infinite looping over CE entries") later capped the CE chain length at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked. With a crafted ISO mounted via udisks2 (desktop optical auto-mount) or via CAP_SYS_ADMIN mount, rs->cont_extent can therefore point at an out-of-range block or at blocks belonging to an adjacent filesystem on the same block device. sb_bread() on an out-of-range block returns NULL cleanly via the block layer EIO path, so there is no memory-safety violation. For in-range reads of adjacent- filesystem data, the CE buffer is parsed as Rock Ridge records and only the text of SL sub-records reaches userspace through readlink(), which makes the info-leak channel narrow and difficult to exploit; still, rejecting the malformed CE outright matches the rejection shape already present in the same function for cont_offset and cont_size. Add an ISOFS_SB(sb)->s_nzones bounds check to rock_continue() next to the existing offset/size rejection, printing the same corrupted-directory-entry notice. Fixes: f54e18f1b831 ("isofs: Fix infinite looping over CE entries") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260419212155.2169382-2-michael.bommarito@gmail.com Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 1919acc5876c18f3e04d2408e39be3584a4f3655 Author: Eric Biggers Date: Thu Feb 5 20:59:21 2026 -0800 dm-verity-fec: correctly reject too-small hash devices commit 4355142245f7e55336dcc005ec03592df4d546f8 upstream. Fix verity_fec_ctr() to reject too-small hash devices by correctly taking hash_start into account. Note that this is necessary because dm-verity doesn't call dm_bufio_set_sector_offset() on the hash device's bufio client (v->bufio). Thus, dm_bufio_get_device_size(v->bufio) returns a size relative to 0 rather than hash_start. An alternative fix would be to call dm_bufio_set_sector_offset() on v->bufio, but then all the code that reads from the hash device would have to be adjusted accordingly. Fixes: a739ff3f543a ("dm verity: add support for forward error correction") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 9a484c8149b2096baf911d5d5a68677b30e04f05 Author: Eric Biggers Date: Thu Feb 5 20:59:20 2026 -0800 dm-verity-fec: correctly reject too-small FEC devices commit 2b14e0bb63cc671120e7791658f5c494fc66d072 upstream. Fix verity_fec_ctr() to reject too-small FEC devices by correctly computing the number of parity blocks as 'f->rounds * f->roots'. Previously it incorrectly used 'div64_u64(f->rounds * f->roots, v->fec->roots << SECTOR_SHIFT)' which is a much smaller value. Note that the units of 'rounds' are blocks, not bytes. This matches the units of the value returned by dm_bufio_get_device_size(), which are also blocks. A later commit will give 'rounds' a clearer name. Fixes: a739ff3f543a ("dm verity: add support for forward error correction") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 52b109f1b875b912d4ab2c5fdd8c322d47119d9b Author: David Carlier Date: Sat Apr 18 20:17:37 2026 +0100 eventfs: Hold eventfs_mutex and SRCU when remount walks events commit 07004a8c4b572171934390148ee48c4175c77eed upstream. Commit 340f0c7067a9 ("eventfs: Update all the eventfs_inodes from the events descriptor") had eventfs_set_attrs() recurse through ei->children on remount. The walk only holds the rcu_read_lock() taken by tracefs_apply_options() over tracefs_inodes, which is wrong: - list_for_each_entry over ei->children races with the list_del_rcu() in eventfs_remove_rec() -- LIST_POISON1 deref, same shape as d2603279c7d6. - eventfs_inodes are freed via call_srcu(&eventfs_srcu, ...). rcu_read_lock() does not extend an SRCU grace period, so ti->private can be reclaimed under the walk. - The writes to ei->attr race with eventfs_set_attr(), which holds eventfs_mutex. Reproducer: while :; do mount -o remount,uid=$((RANDOM%1000)) /sys/kernel/tracing; done & while :; do echo "p:kp submit_bio" > /sys/kernel/tracing/kprobe_events echo > /sys/kernel/tracing/kprobe_events done Wrap the events portion of tracefs_apply_options() in eventfs_remount_lock()/_unlock() that take eventfs_mutex and srcu_read_lock(&eventfs_srcu). eventfs_set_attrs() doesn't sleep so the nested rcu_read_lock() is fine; lockdep_assert_held() pins the contract. Comment in tracefs_drop_inode() said "RCU cycle" -- it is SRCU. Fixes: 340f0c7067a9 ("eventfs: Update all the eventfs_inodes from the events descriptor") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260418191737.10289-1-devnexen@gmail.com Signed-off-by: David Carlier Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 5af6a879e915ae7bcd83695c316ebb32e1c61bc2 Author: Mikulas Patocka Date: Thu Apr 9 17:49:58 2026 +0200 dm: fix a buffer overflow in ioctl processing commit 2fa49cc884f6496a915c35621ba4da35649bf159 upstream. Tony Asleson (using Claude) found a buffer overflow in dm-ioctl in the function retrieve_status: 1. The code in retrieve_status checks that the output string fits into the output buffer and writes the output string there 2. Then, the code aligns the "outptr" variable to the next 8-byte boundary: outptr = align_ptr(outptr); 3. The alignment doesn't check overflow, so outptr could point past the buffer end 4. The "for" loop is iterated again, it executes: remaining = len - (outptr - outbuf); 5. If "outptr" points past "outbuf + len", the arithmetics wraps around and the variable "remaining" contains unusually high number 6. With "remaining" being high, the code writes more data past the end of the buffer Luckily, this bug has no security implications because: 1. Only root can issue device mapper ioctls 2. The commonly used libraries that communicate with device mapper (libdevmapper and devicemapper-rs) use buffer size that is aligned to 8 bytes - thus, "outptr = align_ptr(outptr)" can't overshoot the input buffer and the bug can't happen accidentally Reported-by: Tony Asleson Signed-off-by: Mikulas Patocka Reviewed-by: Bryn M. Reeves Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit cb7c6a89e5d8d1e5d7a1214ae98558141e566c9e Author: Mikulas Patocka Date: Mon Mar 16 15:04:15 2026 +0100 dm: don't report warning when doing deferred remove commit b7cce3e2cca9cd78418f3c3784474b778e7996fe upstream. If dm_hash_remove_all was called from dm_deferred_remove, it would write a warning "remove_all left %d open device(s)" if there are some other devices active. The warning is bogus, so let's disable it in this case. Signed-off-by: Mikulas Patocka Reported-by: Zdenek Kabelac Cc: stable@vger.kernel.org Fixes: 2c140a246dc0 ("dm: allow remove to be deferred") Signed-off-by: Greg Kroah-Hartman commit 85311a585a26640760cd0f3349ab9f2905691044 Author: Mikulas Patocka Date: Mon Apr 20 19:56:44 2026 +0200 dm-thin: fix metadata refcount underflow commit 09a65adc7d8bbfce06392cb6d375468e2728ead5 upstream. There's a bug in dm-thin in the function rebalance_children. If the internal btree node has one entry, the code tries to copy all btree entries from the node's child to the node itself and then decrement the child's reference count. If the child node is shared (it has reference count > 1), we won't free it, so there would be two pointers to each of the grandchildren nodes. But the reference counts of the grandchildren is not increased, thus the reference count doesn't match the number of pointers that point to the grandchildren. This results in "device mapper: space map common: unable to decrement block" errors. Fix this bug by incrementing reference counts on the grandchildren if the btree node is shared. Signed-off-by: Mikulas Patocka Fixes: 3241b1d3e0aa ("dm: add persistent data library") Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit fb388eb58c1ba047ccabc33901839acfecadcf49 Author: Filipe Manana Date: Thu Apr 9 15:46:51 2026 +0100 btrfs: fix missing last_unlink_trans update when removing a directory commit 999757231c49376cd1a37308d2c8c4c9932571e1 upstream. When removing a directory we are not updating its last_unlink_trans field, which can result in incorrect fsync behaviour in case some one fsyncs the directory after it was removed because it's holding a file descriptor on it. Example scenario: mkdir /mnt/dir1 mkdir /mnt/dir1/dir2 mkdir /mnt/dir3 sync -f /mnt # Do some change to the directory and fsync it. chmod 700 /mnt/dir1 xfs_io -c fsync /mnt/dir1 # Move dir2 out of dir1 so that dir1 becomes empty. mv /mnt/dir1/dir2 /mnt/dir3/ open fd on /mnt/dir1 call rmdir(2) on path "/mnt/dir1" fsync fd When attempting to mount the filesystem, the log replay will fail with an -EIO error and dmesg/syslog has the following: [445771.626482] BTRFS info (device dm-0): first mount of filesystem 0368bbea-6c5e-44b5-b409-09abe496e650 [445771.626486] BTRFS info (device dm-0): using crc32c checksum algorithm [445771.627912] BTRFS info (device dm-0): start tree-log replay [445771.628335] page: refcount:2 mapcount:0 mapping:0000000061443ddc index:0x1d00 pfn:0x7072a5 [445771.629453] memcg:ffff89f400351b00 [445771.629892] aops:btree_aops [btrfs] ino:1 [445771.630737] flags: 0x17fffc00000402a(uptodate|lru|private|writeback|node=0|zone=2|lastcpupid=0x1ffff) [445771.632359] raw: 017fffc00000402a fffff47284d950c8 fffff472907b7c08 ffff89f458e412b8 [445771.633713] raw: 0000000000001d00 ffff89f6c51d1a90 00000002ffffffff ffff89f400351b00 [445771.635029] page dumped because: eb page dump [445771.635825] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=10 ino=258, invalid nlink: has 2 expect no more than 1 for dir [445771.638088] BTRFS info (device dm-0): leaf 30408704 gen 10 total ptrs 17 free space 14878 owner 5 [445771.638091] BTRFS info (device dm-0): refs 4 lock_owner 0 current 3581087 [445771.638094] item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160 [445771.638097] inode generation 3 transid 9 size 16 nbytes 16384 [445771.638098] block group 0 mode 40755 links 1 uid 0 gid 0 [445771.638100] rdev 0 sequence 2 flags 0x0 [445771.638102] atime 1775744884.0 [445771.660056] ctime 1775744885.645502983 [445771.660058] mtime 1775744885.645502983 [445771.660060] otime 1775744884.0 [445771.660062] item 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12 [445771.660064] index 0 name_len 2 [445771.660066] item 2 key (256 DIR_ITEM 1843588421) itemoff 16077 itemsize 34 [445771.660068] location key (259 1 0) type 2 [445771.660070] transid 9 data_len 0 name_len 4 [445771.660075] item 3 key (256 DIR_ITEM 2363071922) itemoff 16043 itemsize 34 [445771.660076] location key (257 1 0) type 2 [445771.660077] transid 9 data_len 0 name_len 4 [445771.660078] item 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34 [445771.660079] location key (257 1 0) type 2 [445771.660080] transid 9 data_len 0 name_len 4 [445771.660081] item 5 key (256 DIR_INDEX 3) itemoff 15975 itemsize 34 [445771.660082] location key (259 1 0) type 2 [445771.660083] transid 9 data_len 0 name_len 4 [445771.660084] item 6 key (257 INODE_ITEM 0) itemoff 15815 itemsize 160 [445771.660086] inode generation 9 transid 9 size 8 nbytes 0 [445771.660087] block group 0 mode 40777 links 1 uid 0 gid 0 [445771.660088] rdev 0 sequence 2 flags 0x0 [445771.660089] atime 1775744885.641174097 [445771.660090] ctime 1775744885.645502983 [445771.660091] mtime 1775744885.645502983 [445771.660105] otime 1775744885.641174097 [445771.660106] item 7 key (257 INODE_REF 256) itemoff 15801 itemsize 14 [445771.660107] index 2 name_len 4 [445771.660108] item 8 key (257 DIR_ITEM 2676584006) itemoff 15767 itemsize 34 [445771.660109] location key (258 1 0) type 2 [445771.660110] transid 9 data_len 0 name_len 4 [445771.660111] item 9 key (257 DIR_INDEX 2) itemoff 15733 itemsize 34 [445771.660112] location key (258 1 0) type 2 [445771.660113] transid 9 data_len 0 name_len 4 [445771.660114] item 10 key (258 INODE_ITEM 0) itemoff 15573 itemsize 160 [445771.660115] inode generation 9 transid 10 size 0 nbytes 0 [445771.660116] block group 0 mode 40755 links 2 uid 0 gid 0 [445771.660117] rdev 0 sequence 0 flags 0x0 [445771.660118] atime 1775744885.645502983 [445771.660119] ctime 1775744885.645502983 [445771.660120] mtime 1775744885.645502983 [445771.660121] otime 1775744885.645502983 [445771.660122] item 11 key (258 INODE_REF 257) itemoff 15559 itemsize 14 [445771.660123] index 2 name_len 4 [445771.660124] item 12 key (258 INODE_REF 259) itemoff 15545 itemsize 14 [445771.660125] index 2 name_len 4 [445771.660126] item 13 key (259 INODE_ITEM 0) itemoff 15385 itemsize 160 [445771.660127] inode generation 9 transid 10 size 8 nbytes 0 [445771.660128] block group 0 mode 40755 links 1 uid 0 gid 0 [445771.660129] rdev 0 sequence 1 flags 0x0 [445771.660130] atime 1775744885.645502983 [445771.660130] ctime 1775744885.645502983 [445771.660131] mtime 1775744885.645502983 [445771.660132] otime 1775744885.645502983 [445771.660133] item 14 key (259 INODE_REF 256) itemoff 15371 itemsize 14 [445771.660134] index 3 name_len 4 [445771.660135] item 15 key (259 DIR_ITEM 2676584006) itemoff 15337 itemsize 34 [445771.660136] location key (258 1 0) type 2 [445771.660137] transid 10 data_len 0 name_len 4 [445771.660138] item 16 key (259 DIR_INDEX 2) itemoff 15303 itemsize 34 [445771.660139] location key (258 1 0) type 2 [445771.660140] transid 10 data_len 0 name_len 4 [445771.660144] BTRFS error (device dm-0): block=30408704 write time tree block corruption detected [445771.661650] ------------[ cut here ]------------ [445771.662358] WARNING: fs/btrfs/disk-io.c:326 at btree_csum_one_bio+0x217/0x230 [btrfs], CPU#8: mount/3581087 [445771.663588] Modules linked in: btrfs f2fs xfs (...) [445771.671229] CPU: 8 UID: 0 PID: 3581087 Comm: mount Tainted: G W 7.0.0-rc6-btrfs-next-230+ #2 PREEMPT(full) [445771.672575] Tainted: [W]=WARN [445771.672987] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [445771.674460] RIP: 0010:btree_csum_one_bio+0x217/0x230 [btrfs] [445771.675222] Code: 89 44 24 (...) [445771.677364] RSP: 0018:ffffd23882247660 EFLAGS: 00010246 [445771.678029] RAX: 0000000000000000 RBX: ffff89f6c51d1a90 RCX: 0000000000000000 [445771.678975] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff89f406020000 [445771.679983] RBP: ffff89f821204000 R08: 0000000000000000 R09: 00000000ffefffff [445771.680905] R10: ffffd23882247448 R11: 0000000000000003 R12: ffffd23882247668 [445771.681978] R13: ffff89f458e40fc0 R14: ffff89f737f4f500 R15: ffff89f737f4f500 [445771.682912] FS: 00007f0447a98840(0000) GS:ffff89fb9771d000(0000) knlGS:0000000000000000 [445771.684393] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [445771.685230] CR2: 00007f0447bf1330 CR3: 000000017cb02002 CR4: 0000000000370ef0 [445771.686273] Call Trace: [445771.686646] [445771.686969] btrfs_submit_bbio+0x83f/0x860 [btrfs] [445771.687750] ? write_one_eb+0x28f/0x340 [btrfs] [445771.688428] btree_writepages+0x2e3/0x550 [btrfs] [445771.689180] ? kmem_cache_alloc_noprof+0x12a/0x490 [445771.689963] ? alloc_extent_state+0x19/0x120 [btrfs] [445771.690801] ? kmem_cache_free+0x135/0x380 [445771.691328] ? preempt_count_add+0x69/0xa0 [445771.691831] ? set_extent_bit+0x252/0x8e0 [btrfs] [445771.692468] ? xas_load+0x9/0xc0 [445771.692873] ? xas_find+0x14d/0x1a0 [445771.693304] do_writepages+0xc6/0x160 [445771.693756] filemap_writeback+0xb8/0xe0 [445771.694274] btrfs_write_marked_extents+0x61/0x170 [btrfs] [445771.694999] btrfs_write_and_wait_transaction+0x4e/0xc0 [btrfs] [445771.695818] btrfs_commit_transaction+0x5c8/0xd10 [btrfs] [445771.696530] ? kmem_cache_free+0x135/0x380 [445771.697120] ? release_extent_buffer+0x34/0x160 [btrfs] [445771.697786] btrfs_recover_log_trees+0x7be/0x7e0 [btrfs] [445771.698525] ? __pfx_replay_one_buffer+0x10/0x10 [btrfs] [445771.699206] open_ctree+0x11e5/0x1810 [btrfs] [445771.699776] btrfs_get_tree.cold+0xb/0x162 [btrfs] [445771.700463] ? fscontext_read+0x165/0x180 [445771.701146] ? rw_verify_area+0x50/0x180 [445771.701866] vfs_get_tree+0x25/0xd0 [445771.702491] vfs_cmd_create+0x59/0xe0 [445771.703125] __do_sys_fsconfig+0x303/0x610 [445771.703603] do_syscall_64+0xe9/0xf20 [445771.703974] entry_SYSCALL_64_after_hwframe+0x76/0x7e [445771.704700] RIP: 0033:0x7f0447cbd4aa [445771.705108] Code: 73 01 c3 (...) [445771.707263] RSP: 002b:00007ffc4e528318 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [445771.708107] RAX: ffffffffffffffda RBX: 00005561585d8c20 RCX: 00007f0447cbd4aa [445771.708931] RDX: 0000000000000000 RSI: 0000000000000006 RDI: 0000000000000003 [445771.709744] RBP: 00005561585d9120 R08: 0000000000000000 R09: 0000000000000000 [445771.710674] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [445771.711477] R13: 00007f0447e4f580 R14: 00007f0447e5126c R15: 00007f0447e36a23 [445771.712277] [445771.712541] ---[ end trace 0000000000000000 ]--- [445771.713382] BTRFS error (device dm-0): error while writing out transaction: -5 [445771.714679] BTRFS warning (device dm-0): Skipping commit of aborted transaction. [445771.715562] BTRFS error (device dm-0 state A): Transaction aborted (error -5) [445771.716459] BTRFS: error (device dm-0 state A) in cleanup_transaction:2068: errno=-5 IO failure [445771.717936] BTRFS error (device dm-0 state EA): failed to recover log trees with error: -5 [445771.719681] BTRFS error (device dm-0 state EA): open_ctree failed: -5 The problem is that such a fsync should have result in a fallback to a transaction commit, but that did not happen because through the btrfs_rmdir() we never update the directory's last_unlink_trans field. Any inode that had a link removed must have its last_unlink_trans updated to the ID of transaction used for the operation, otherwise fsync and log replay will not work correctly. btrfs_rmdir() calls btrfs_unlink_inode() and through that call chain we never call btrfs_record_unlink_dir() in order to update last_unlink_trans. However btrfs_unlink(), which is used for unlinking regular files, calls btrfs_record_unlink_dir() and then calls btrfs_unlink_inode(). So fix this by moving the call to btrfs_record_unlink_dir() from btrfs_unlink() to btrfs_unlink_inode(). A test case for fstests will follow soon. Reported-by: Slava0135 Link: https://lore.kernel.org/linux-btrfs/CAAJYhww5ov62Hm+n+tmhcL-e_4cBobg+OWogKjOJxVUXivC=MQ@mail.gmail.com/ CC: stable@vger.kernel.org Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 9a060970fd7b5e1c561e4ce73cb9949e4269a738 Author: Guangshuo Li Date: Wed Apr 1 18:56:19 2026 +0800 btrfs: fix double free in create_space_info() error path commit 3f487be81292702a59ea9dbc4088b3360a50e837 upstream. When kobject_init_and_add() fails, the call chain is: create_space_info() -> btrfs_sysfs_add_space_info_type() -> kobject_init_and_add() -> failure -> kobject_put(&space_info->kobj) -> space_info_release() -> kfree(space_info) Then control returns to create_space_info(): btrfs_sysfs_add_space_info_type() returns error -> goto out_free -> kfree(space_info) This causes a double free. Keep the direct kfree(space_info) for the earlier failure path, but after btrfs_sysfs_add_space_info_type() has called kobject_put(), let the kobject release callback handle the cleanup. Fixes: a11224a016d6d ("btrfs: fix memory leaks in create_space_info() error paths") CC: stable@vger.kernel.org # 6.19+ Reviewed-by: Qu Wenruo Signed-off-by: Guangshuo Li Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 48102d8890902f8f011757f294e57a9b7d8d2621 Author: Srinivas Kandagatla Date: Thu Apr 2 08:11:07 2026 +0000 ASoC: qcom: q6apm: remove child devices when apm is removed commit 4a0e1bcc98f7281d1605768bd2fe71eacc34f9b7 upstream. looks like q6apm driver does not remove the child driver q6apm-dai and q6apm-bedais when the this driver is removed. Fix this by depopulating them in remove callback. With this change when the dsp is shutdown all the devices associated with q6apm will now be removed. Fixes: 5477518b8a0e ("ASoC: qdsp6: audioreach: add q6apm support") Cc: Stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260402081118.348071-3-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 7cab9f2ad51c858263da836baebad050a1bc7914 Author: Srinivas Kandagatla Date: Thu Apr 2 08:11:09 2026 +0000 ASoC: qcom: q6apm-lpass-dai: Fix multiple graph opens commit 69acc488aaf39d0ddf6c3cf0e47c1873d39919a2 upstream. As prepare can be called mulitple times, this can result in multiple graph opens for playback path. This will result in a memory leaks, fix this by adding a check before opening. Fixes: be1fae62cf25 ("ASoC: q6apm-lpass-dai: close graph on prepare errors") Cc: Stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260402081118.348071-5-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6d43355a5b9efaf5c5d3734cad82ee2ddafe4b43 Author: Srinivas Kandagatla Date: Thu Apr 2 08:11:10 2026 +0000 ASoC: qcom: q6apm-dai: reset queue ptr on trigger stop commit cab45ab95ce7600fc0ff84585c77fd45b7b0d67c upstream. Reset queue pointer on SNDRV_PCM_TRIGGER_STOP event to be inline with resetting appl_ptr. Without this we will end up with a queue_ptr out of sync and driver could try to send data that is not ready yet. Fix this by resetting the queue_ptr. Fixes: 3d4a4411aa8bb ("ASoC: q6apm-dai: schedule all available frames to avoid dsp under-runs") Cc: Stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260402081118.348071-6-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 4e550b59315d6dabda09727d53d42c51d48453ab Author: Cássio Gabriel Date: Mon Apr 27 23:38:41 2026 -0300 ASoC: Intel: bytcr_wm5102: Fix MCLK leak on platform_clock_control error commit 13d30682e8dee191ac04e93642f0372a723e8b0c upstream. If byt_wm5102_prepare_and_enable_pll1() fails in the SND_SOC_DAPM_EVENT_ON() path, platform_clock_control() returns after clk_prepare_enable(priv->mclk) without disabling the clock again. This leaks an MCLK enable reference on failed power-up attempts. Add the missing clk_disable_unprepare() on the error path, matching the unwind used by the other Intel platform_clock_control() implementations. Fixes: 9a87fc1e0619 ("ASoC: Intel: bytcr_wm5102: Add machine driver for BYT/WM5102") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Reviewed-by: Cezary Rojewski Reviewed-by: Hans de Goede Link: https://patch.msgid.link/20260427-bytcr-wm5102-mclk-leak-v1-1-02b96d08e99c@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 846fcce3a6bbe34b01e1fe87591db4302d780430 Author: Joseph Salisbury Date: Mon Mar 16 14:05:45 2026 -0400 ASoC: fsl_easrc: fix comment typo commit 804dce6c73fdfa44184ee4e8b09abad7f5da408f upstream. The file contains a spelling error in a source comment (funciton). Typos in comments reduce readability and make text searches less reliable for developers and maintainers. Replace 'funciton' with 'function' in the affected comment. This is a comment-only cleanup and does not change behavior. Fixes: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers") Cc: stable@vger.kernel.org Signed-off-by: Joseph Salisbury Link: https://patch.msgid.link/20260316180545.144032-1-joseph.salisbury@oracle.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 3a5287c47b13b530e7217efc7786b5a248d5ced0 Author: Li Jian Date: Fri Apr 17 18:53:14 2026 +0800 ASoC: ES8389: convert to devm_clk_get_optional() to get clock commit 8ed3311131077712cdd0b3afec6909b9388ad3e4 upstream. When enabling ES8390 via ACPI description, es8389 would fail to obtain a clock source, causing the driver to fail to initialize. This was not an issue with older kernels, but since commit abae8e57e49a ("clk: generalize devm_clk_get() a bit"), devm_clk_get() would return an error pointer when a clock source was not detected (instead of falling back to a static clock), causing the driver to fail early. Use devm_clk_get_optional() instead to return to the previous behaviour, allowing the use of a static clock source. Cc: stable@vger.kernel.org Signed-off-by: Li Jian Link: https://patch.msgid.link/tencent_7C78374FB9F4B3A37101E5C719715D8BC40A@qq.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 65aabf8896687354e0628feb7298c39232e133e3 Author: Tommaso Soncin Date: Wed Apr 29 18:08:57 2026 +0200 ASoC: amd: yc: Add HP OMEN Gaming Laptop 16-ap0xxx product line in quirk table commit d63c219b7ff39f897da10c160a2edef76320f16c upstream. Add a DMI quirk for the HP OMEN Gaming Laptop 16-ap0xxx line fixing the issue where the internal microphone was not detected. Cc: stable@vger.kernel.org Signed-off-by: Tommaso Soncin Link: https://patch.msgid.link/20260429160858.538986-1-soncintommaso@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 54a44bbead390d95c68655df9ca6d6cb1fceac78 Author: Shrikanth Hegde Date: Wed Mar 11 11:47:09 2026 +0530 cpuidle: powerpc: avoid double clear when breaking snooze commit 64ed1e3e728afb57ba9acb59e69de930ead847d9 upstream. snooze_loop is done often in any system which has fair bit of idle time. So it qualifies for even micro-optimizations. When breaking the snooze due to timeout, TIF_POLLING_NRFLAG is cleared twice. Clearing the bit invokes atomics. Avoid double clear and thereby avoid one atomic write. dev->poll_time_limit indicates whether the loop was broken due to timeout. Use that instead of defining a new variable. Fixes: 7ded429152e8 ("cpuidle: powerpc: no memory barrier after break from idle") Cc: stable@vger.kernel.org Reviewed-by: Mukesh Kumar Chaurasiya (IBM) Signed-off-by: Shrikanth Hegde Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260311061709.1230440-1-sshegde@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit a0780aeea166a7cf4706c45af4cadbb2a43a1fc9 Author: Conor Dooley Date: Tue Feb 24 09:35:25 2026 +0000 clk: microchip: mpfs-ccc: fix out of bounds access during output registration commit 2f7ae8ab6aa73daaf080d5332110357c29df9c36 upstream. UBSAN reported an out of bounds access during registration of the last two outputs. This out of bounds access occurs because space is only allocated in the hws array for two PLLs and the four output dividers that each has, but the defined IDs contain two DLLS and their two outputs each, which are not supported by the driver. The ID order is PLLs -> DLLs -> PLL outputs -> DLL outputs. Decrement the PLL output IDs by two while adding them to the array to avoid the problem. Fixes: d39fb172760e ("clk: microchip: add PolarFire SoC fabric clock support") CC: stable@vger.kernel.org Reviewed-by: Brian Masney Signed-off-by: Conor Dooley Signed-off-by: Greg Kroah-Hartman commit 9eccdb76ad5e69cdf83563853d171614bc15c13e Author: Stefan Eichenberger Date: Thu Feb 12 16:57:50 2026 +0800 clk: imx: imx8-acm: fix flags for acm clocks commit f2c2fc93b4a3efdfcf3805ab74741826d343ff2c upstream. Currently, the flags for the ACM clocks are set to 0. This configuration causes the fsl-sai audio driver to fail when attempting to set the sysclk, returning an EINVAL error. The following error messages highlight the issue: fsl-sai 59090000.sai: ASoC: error at snd_soc_dai_set_sysclk on 59090000.sai: -22 imx-hdmi sound-hdmi: failed to set cpu sysclk: -22 By setting the flag CLK_SET_RATE_NO_REPARENT, we signal that the ACM driver does not support reparenting and instead relies on the clock tree as defined in the device tree. This change resolves the issue with the fsl-sai audio driver. CC: stable@vger.kernel.org Fixes: d3a0946d7ac9 ("clk: imx: imx8: add audio clock mux driver") Signed-off-by: Stefan Eichenberger Signed-off-by: Shengjiu Wang Reviewed-by: Peng Fan Link: https://patch.msgid.link/20260212085750.3253187-1-shengjiu.wang@nxp.com Signed-off-by: Abel Vesa Signed-off-by: Greg Kroah-Hartman commit b528c7ffdc3e56e6146d90bce3fcfd7db145fb89 Author: Steven Rostedt Date: Tue Apr 28 12:23:02 2026 -0400 tracing/probes: Limit size of event probe to 3K commit b2aa3b4d64e460ac606f386c24e7d8a873ce6f1a upstream. There currently isn't a max limit an event probe can be. One could make an event greater than PAGE_SIZE, which makes the event useless because if it's bigger than the max event that can be recorded into the ring buffer, then it will never be recorded. A event probe should never need to be greater than 3K, so make that the max size. As long as the max is less than the max that can be recorded onto the ring buffer, it should be fine. Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Acked-by: Masami Hiramatsu (Google) Fixes: 93ccae7a22274 ("tracing/kprobes: Support basic types on dynamic events") Link: https://patch.msgid.link/20260428122302.706610ba@gandalf.local.home Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit d50ef3553acbacce6f2843304d41d06dca358bb6 Author: Johan Hovold Date: Tue Apr 14 15:43:19 2026 +0200 spi: topcliff-pch: fix use-after-free on unbind commit 9d72732fe70c11424bc90ed466c7ccfa58b42a9a upstream. Give the driver a chance to flush its queue before releasing the DMA buffers on driver unbind Fixes: c37f3c2749b5 ("spi/topcliff_pch: DMA support") Cc: stable@vger.kernel.org # 3.1 Cc: Tomoya MORINAGA Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260414134319.978196-9-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b3bdc7a8dd44f097afa705265da1a2206e9d5b5e Author: Johan Hovold Date: Tue Apr 14 15:43:18 2026 +0200 spi: topcliff-pch: fix controller deregistration commit 5d6f477d6fc0767c57c5e1e6f55a1662820eef87 upstream. Make sure to deregister the controller before disabling and releasing underlying resources like interrupts and DMA during driver unbind. Fixes: e8b17b5b3f30 ("spi/topcliff: Add topcliff platform controller hub (PCH) spi bus driver") Cc: stable@vger.kernel.org # 2.6.37 Cc: Masayuki Ohtake Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260414134319.978196-8-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 4b16c06da7636d2a3f62bb0667a0dc565e0e8c80 Author: Thorsten Blum Date: Sat Mar 7 11:24:21 2026 +0100 thermal/drivers/sprd: Fix raw temperature clamping in sprd_thm_rawdata_to_temp commit b3414148bbc1f9cd56217e58a558c6ac4fd1b4a6 upstream. The raw temperature data was never clamped to SPRD_THM_RAW_DATA_LOW or SPRD_THM_RAW_DATA_HIGH because the return value of clamp() was not used. Fix this by assigning the clamped value to 'rawdata'. Casting SPRD_THM_RAW_DATA_LOW and SPRD_THM_RAW_DATA_HIGH to u32 is also redundant and can be removed. Fixes: 554fdbaf19b1 ("thermal: sprd: Add Spreadtrum thermal driver support") Signed-off-by: Thorsten Blum Signed-off-by: Daniel Lezcano Reviewed-by: Baolin Wang Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260307102422.306055-2-thorsten.blum@linux.dev Signed-off-by: Greg Kroah-Hartman commit 3933dfb360e04edb01c8957a338df7eb809f356e Author: Thorsten Blum Date: Sat Mar 7 11:24:20 2026 +0100 thermal/drivers/sprd: Fix temperature clamping in sprd_thm_temp_to_rawdata commit 83c0f9a5d679a6f8d84fc49b2f62ea434ccab4b6 upstream. The temperature was never clamped to SPRD_THM_TEMP_LOW or SPRD_THM_TEMP_HIGH because the return value of clamp() was not used. Fix this by assigning the clamped value to 'temp'. Casting SPRD_THM_TEMP_LOW and SPRD_THM_TEMP_HIGH to int is also redundant and can be removed. Fixes: 554fdbaf19b1 ("thermal: sprd: Add Spreadtrum thermal driver support") Signed-off-by: Thorsten Blum Signed-off-by: Daniel Lezcano Reviewed-by: Baolin Wang Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260307102422.306055-1-thorsten.blum@linux.dev Signed-off-by: Greg Kroah-Hartman commit eb295d2b6e70bbd83f8e6fcad4631c858707a245 Author: Rafael J. Wysocki Date: Tue Apr 7 15:58:34 2026 +0200 thermal: core: Free thermal zone ID later during removal commit daae9c18feec74566e023fc88cfb0ce26e39d868 upstream. The thermal zone removal ordering is different from the thermal zone registration rollback path ordering and the former is arguably problematic because freeing a thermal zone ID prematurely may cause it to be used during the registration of another thermal zone which may fail as a result. Prevent that from occurring by changing the thermal zone removal ordering to reflect the thermal zone registration rollback path ordering. Also more the ida_destroy() call from thermal_zone_device_unregister() to thermal_release() for consistency. Fixes: b31ef8285b19 ("thermal core: convert ID allocation to IDA") Cc: All applicable Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/5063934.GXAFRqVoOG@rafael.j.wysocki Signed-off-by: Greg Kroah-Hartman commit 1873eb81c65d3f849418d7386baa39c439c9fc38 Author: Michael Bommarito Date: Mon Apr 13 17:12:40 2026 -0400 udf: reject descriptors with oversized CRC length commit 55d41b0a20128e86b9e960dd2e3f0a2d69a18df7 upstream. udf_read_tagged() skips CRC verification when descCRCLength + sizeof(struct tag) exceeds the block size. A crafted UDF image can set descCRCLength to an oversized value to bypass CRC validation entirely; the descriptor is then accepted based solely on the 8-bit tag checksum, which is trivially recomputable. Reject such descriptors instead of silently accepting them. A legitimate single-block descriptor should never have a CRC length that exceeds the block. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Assisted-by: Codex:gpt-5-4 Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260413211240.853662-1-michael.bommarito@gmail.com Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit b1040af587713e0475f83f17b180d5a927da3346 Author: David Carlier Date: Sat Apr 4 14:47:47 2026 +0100 tracefs: Fix default permissions not being applied on initial mount commit e8368d1f4bedbb0cce4cfe33a1d2664bb0fd4f27 upstream. Commit e4d32142d1de ("tracing: Fix tracefs mount options") moved the option application from tracefs_fill_super() to tracefs_reconfigure() called from tracefs_get_tree(). This fixed mount options being ignored on user-space mounts when the superblock already exists, but introduced a regression for the initial kernel-internal mount. On the first mount (via simple_pin_fs during init), sget_fc() transfers fc->s_fs_info to sb->s_fs_info and sets fc->s_fs_info to NULL. When tracefs_get_tree() then calls tracefs_reconfigure(), it sees a NULL fc->s_fs_info and returns early without applying any options. The root inode keeps mode 0755 from simple_fill_super() instead of the intended TRACEFS_DEFAULT_MODE (0700). Furthermore, even on subsequent user-space mounts without an explicit mode= option, tracefs_apply_options(sb, true) gates the mode behind fsi->opts & BIT(Opt_mode), which is unset for the defaults. So the mode is never corrected unless the user explicitly passes mode=0700. Restore the tracefs_apply_options(sb, false) call in tracefs_fill_super() to apply default permissions on initial superblock creation, matching what debugfs does in debugfs_fill_super(). Cc: stable@vger.kernel.org Fixes: e4d32142d1de ("tracing: Fix tracefs mount options") Link: https://patch.msgid.link/20260404134747.98867-1-devnexen@gmail.com Signed-off-by: David Carlier Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 998f43196d732f20f9b71eb6ebd973736c9fa911 Author: Conor Dooley Date: Thu Apr 30 11:10:18 2026 +0100 spi: microchip-core-qspi: control built-in cs manually commit 7672749e1496215e8683ce57cf323119033954cf upstream. The coreQSPI IP supports only a single chip select, which is automagically operated by the hardware - set low when the transmit buffer first gets written to and set high when the number of bytes written to the TOTALBYTES field of the FRAMES register have been sent on the bus. Additional devices must use GPIOs for their chip selects. It was reported to me that if there are two devices attached to this QSPI controller that the in-built chip select is set low while linux tries to access the device attached to the GPIO. This went undetected as the boards that connected multiple devices to the SPI controller all exclusively used GPIOs for chip selects, not relying on the built-in chip select at all. It turns out that this was because the built-in chip select, when controlled automagically, is set low when active and high when inactive, thereby ruling out its use for active-high devices or devices that need to transmit with the chip select disabled. Modify the driver so that it controls chip select directly, retaining the behaviour for mem_ops of setting the chip select active for the entire duration of the transfer in the exec_op callback. For regular transfers, implement the set_cs callback for the core to use. As part of this, the existing setup callback, mchp_coreqspi_setup_op(), is removed. Modifying the CLKIDLE field is not safe to do during operation when there are multiple devices, so this code is removed entirely. Setting the MASTER and ENABLE fields is something that can be done once at probe, it doesn't need to be re-run for each device. Instead the new setup callback sets the built-in chip select to its inactive state for active-low devices, as the reset value of the chip select in software controlled mode is low. Fixes: 8f9cf02c88528 ("spi: microchip-core-qspi: Add regular transfers") Fixes: 8596124c4c1bc ("spi: microchip-core-qspi: Add support for microchip fpga qspi controllers") CC: stable@vger.kernel.org Signed-off-by: Conor Dooley Link: https://patch.msgid.link/20260430-hamstring-busload-f941d0347b5e@spud Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit ec9d0ddbde6003c303fa5e1d5cd48952852984d8 Author: Conor Dooley Date: Thu Apr 30 11:10:19 2026 +0100 spi: microchip-core-qspi: don't attempt to transmit during emulated read-only dual/quad operations commit eb56deaabf127e8985fc91fa6c97bf8a3b062844 upstream. The core will deal with reads by creating clock cycles itself, there's no need to generate clock cycles by transmitting garbage data at the driver level. Further, transmitting garbage data just bricks the transfer since QSPI doesn't have a dedicated master-out line like MOSI in regular SPI. I'm not entirely sure if the transfer is bricked because of the garbage data being transmitted on the bus or because the core loses track of whether it is supposed to be sending or receiving data. Fixes: 8f9cf02c88528 ("spi: microchip-core-qspi: Add regular transfers") CC: stable@vger.kernel.org Signed-off-by: Conor Dooley Link: https://patch.msgid.link/20260430-freezing-saloon-95b1f3d9dad0@spud Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit d945d71bbad58d727aa2d37e7d3503d08e2931b7 Author: Johan Hovold Date: Thu Apr 9 14:04:17 2026 +0200 spi: microchip-core-qspi: fix controller deregistration commit e6464140d439f2d42f072eb422a5b1fec470c5a6 upstream. Make sure to deregister the controller before disabling underlying resources like interrupts during driver unbind. Fixes: 8596124c4c1b ("spi: microchip-core-qspi: Add support for microchip fpga qspi controllers") Cc: stable@vger.kernel.org # 6.1 Cc: Naga Sureshkumar Relli Signed-off-by: Johan Hovold Acked-by: Conor Dooley Link: https://patch.msgid.link/20260409120419.388546-19-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 121d1f253aed515cd85748f68c664a6cb756e8ad Author: Guangshuo Li Date: Thu Apr 16 17:53:27 2026 -0700 ice: fix double free in ice_sf_eth_activate() error path commit 9aab1c3d7299285e2569cbc0ed5892d631a241b2 upstream. When auxiliary_device_add() fails, ice_sf_eth_activate() jumps to aux_dev_uninit and calls auxiliary_device_uninit(&sf_dev->adev). The device release callback ice_sf_dev_release() frees sf_dev, but the current error path falls through to sf_dev_free and calls kfree(sf_dev) again, causing a double free. Keep kfree(sf_dev) for the auxiliary_device_init() failure path, but avoid falling through to sf_dev_free after auxiliary_device_uninit(). Fixes: 13acc5c4cdbe ("ice: subfunction activation and base devlink ops") Cc: stable@vger.kernel.org Reviewed-by: Aleksandr Loktionov Signed-off-by: Guangshuo Li Reviewed-by: Simon Horman Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260416-iwl-net-submission-2026-04-14-v2-3-686c33c9828d@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c1f261863e65b508f37416dfbc5c5d911c9b9233 Author: Mingming Cao Date: Fri Apr 24 09:29:17 2026 -0700 ibmveth: Disable GSO for packets with small MSS commit cc427d24ac6442ffdeafd157a63c7c5b73ed4de4 upstream. Some physical adapters on Power systems do not support segmentation offload when the MSS is less than 224 bytes. Attempting to send such packets causes the adapter to freeze, stopping all traffic until manually reset. Implement ndo_features_check to disable GSO for packets with small MSS values. The network stack will perform software segmentation instead. The 224-byte minimum matches ibmvnic commit ("ibmvnic: Enforce stronger sanity checks on GSO packets") which uses the same physical adapters in SEA configurations. The issue occurs specifically when the hardware attempts to perform segmentation (gso_segs > 1) with a small MSS. Single-segment GSO packets (gso_segs == 1) do not trigger the problematic LSO code path and are transmitted normally without segmentation. Add an ndo_features_check callback to disable GSO when MSS < 224 bytes. Also call vlan_features_check() to ensure proper handling of VLAN packets, particularly QinQ (802.1ad) configurations where the hardware parser may not support certain offload features. Validated using iptables to force small MSS values. Without the fix, the adapter freezes. With the fix, packets are segmented in software and transmission succeeds. Comprehensive regression testing completedd (MSS tests, performance, stability). Fixes: 8641dd85799f ("ibmveth: Add support for TSO") Cc: stable@vger.kernel.org Reviewed-by: Brian King Tested-by: Shaik Abdulla Tested-by: Naveed Ahmed Signed-off-by: Mingming Cao Link: https://patch.msgid.link/20260424162917.65725-1-mmc@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4f82f046f913638ad732df473099f0aa025f9e23 Author: Dexuan Cui Date: Wed Apr 22 23:48:11 2026 -0700 hv_sock: Return -EIO for malformed/short packets commit 3d1f20727a635811f6b77801a7b57b8995268abd upstream. Commit f63152958994 fixes a regression, however it fails to report an error for malformed/short packets -- normally we should never see such packets, but let's report an error for them just in case. Fixes: f63152958994 ("hv_sock: Report EOF instead of -EIO for FIN") Cc: stable@vger.kernel.org Signed-off-by: Dexuan Cui Acked-by: Stefano Garzarella Link: https://patch.msgid.link/20260423064811.1371749-1-decui@microsoft.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 317e434e26af461a781dd9bf0be88bb4bbae7560 Author: Dexuan Cui Date: Thu Apr 16 12:14:33 2026 -0700 hv_sock: Report EOF instead of -EIO for FIN commit f6315295899415f1ddcf39f7c9cb46d25e2c6c6a upstream. Commit f0c5827d07cb unluckily causes a regression for the FIN packet, and the final read syscall gets an error rather than 0. Ideally, we would want to fix hvs_channel_readable_payload() so that it could return 0 in the FIN scenario, but it's not good for the hv_sock driver to use the VMBus ringbuffer's cached priv_read_index, which is internal data in the VMBus driver. Fix the regression in hv_sock by returning 0 rather than -EIO. Fixes: f0c5827d07cb ("hv_sock: Return the readable bytes in hvs_stream_has_data()") Cc: stable@vger.kernel.org Reported-by: Ben Hillis Reported-by: Mitchell Levy Signed-off-by: Dexuan Cui Acked-by: Stefano Garzarella Link: https://patch.msgid.link/20260416191433.840637-1-decui@microsoft.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d1b9424f7393e3353128f6ec43613ea5ff0444f8 Author: Hamza Mahfooz Date: Tue Apr 28 08:53:39 2026 -0400 hv_sock: fix ARM64 support commit b31681206e3f527970a7c7ed807fbf6a028fc25b upstream. VMBUS ring buffers must be page aligned. Therefore, the current value of 24K presents a challenge on ARM64 kernels (with 64K pages). So, use VMBUS_RING_SIZE() to ensure they are always aligned and large enough to hold all of the relevant data. Cc: stable@vger.kernel.org Fixes: 77ffe33363c0 ("hv_sock: use HV_HYP_PAGE_SIZE for Hyper-V communication") Tested-by: Dexuan Cui Reviewed-by: Dexuan Cui Signed-off-by: Hamza Mahfooz Acked-by: Stefano Garzarella Link: https://patch.msgid.link/20260428125339.13963-1-hamzamahfooz@linux.microsoft.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit cb028f72fb3b2d4af81c74883e904df58ad01db6 Author: Thomas Zimmermann Date: Thu Apr 2 11:09:15 2026 +0200 hv: Select CONFIG_SYSFB only for CONFIG_HYPERV_VMBUS commit d33db956c9618e7cb08c2520ce708437914214ec upstream. Hyperv's sysfb access only exists in the VMBUS support. Therefore only select CONFIG_SYSFB for CONFIG_HYPERV_VMBUS. Avoids sysfb code on systems that don't need it. Signed-off-by: Thomas Zimmermann Fixes: 96959283a58d ("Drivers: hv: Always select CONFIG_SYSFB for Hyper-V guests") Cc: Michael Kelley Cc: Saurabh Sengar Cc: Wei Liu Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Dexuan Cui Cc: Long Li Cc: linux-hyperv@vger.kernel.org Cc: # v6.16+ Reviewed-by: Saurabh Sengar Link: https://patch.msgid.link/20260402092305.208728-2-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit 5b958822126dbe7706a6551cb4900900f724844c Author: Bartosz Golaszewski Date: Mon Mar 9 13:42:37 2026 +0100 gpio: of: clear OF_POPULATED on hog nodes in remove path commit bbee90e750262bfb406d66dc65c46d616d2b6673 upstream. The previously set OF_POPULATED flag should be cleared on the hog nodes when removing the chip. Cc: stable@vger.kernel.org Fixes: 63636d956c455 ("gpio: of: Add DT overlay support for GPIO hogs") Acked-by: Linus Walleij Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20260309-gpio-hog-fwnode-v2-1-4e61f3dbf06a@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit bbf63275d4a5ee28c872bd730a1d788e59c23a13 Author: Xu Yang Date: Sat Nov 15 10:59:05 2025 +0800 extcon: ptn5150: handle pending IRQ events during system resume commit 4652fefcda3c604c83d1ae28ede94544e2142f06 upstream. When the system is suspended and ptn5150 wakeup interrupt is disabled, any changes on ptn5150 will only be record in interrupt status registers and won't fire an IRQ since its trigger type is falling edge. So the HW interrupt line will keep at low state and any further changes won't trigger IRQ anymore. To fix it, this will schedule a work to check whether any IRQ are pending and handle it accordingly. Fixes: 4ed754de2d66 ("extcon: Add support for ptn5150 extcon driver") Cc: stable@vger.kernel.org Reviewed-by: Krzysztof Kozlowski Acked-by: MyungJoo Ham Signed-off-by: Xu Yang Signed-off-by: Chanwoo Choi Link: https://lore.kernel.org/lkml/20251115025905.1395347-1-xu.yang_2@nxp.com/ Signed-off-by: Greg Kroah-Hartman commit 196efa8b254b51dd269a404a2b1e7e27b762fd46 Author: Shyam Prasad N Date: Mon Mar 30 16:19:59 2026 +0530 cifs: change_conf needs to be called for session setup commit c208a2b95811d6e1ebae65d0d2fc13f73707f8e7 upstream. Today we skip calling change_conf for negotiates and session setup requests. This can be a problem for mchan as the immediate next call after session setup could be due to an I/O that is made on the mount point. For single channel, this is not a problem as there will be several calls after setting up session. This change enforces calling change_conf when the total credits contain enough for reservations for echoes and oplocks. We expect this to happen during the last session setup response. This way, echoes and oplocks are not disabled before the first request to the server. So if that first request is an open, it does not need to disable requesting leases. Cc: Reviewed-by: Bharath SM Signed-off-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 064f2e49199c28095c3739c3decc9e90f05f1d73 Author: Shyam Prasad N Date: Tue Apr 28 21:37:47 2026 +0530 cifs: abort open_cached_dir if we don't request leases commit d68ce834f8cf6cb2e77f3331df65166b35466b53 upstream. It is possible that SMB2_open_init may not set lease context based on the requested oplock level. This can happen when leases have been temporarily or permanently disabled. When this happens, we will have open_cached_dir making an open without lease context and the response will anyway be rejected by open_cached_dir (thereby forcing a close to discard this open). That's unnecessary two round-trips to the server. This change adds a check before making the open request to the server to make sure that SMB2_open_init did add the expected lease context to the open in open_cached_dir. Cc: Reviewed-by: Bharath SM Signed-off-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 281a0014f46f22a1e964b0096a4e698c27888c95 Author: Jens Axboe Date: Mon May 4 08:34:32 2026 -0600 block: only read from sqe on initial invocation of blkdev_uring_cmd() commit 212ec34e4e726e8cd4af7bea4740db24de8a9dab upstream. This passthrough helper currently only supports discards. Part of that command is the start and length, which is read from the SQE. It does so on every invocation, where it really should just make it stable on the first invocation. This avoids needing to copy the SQE upfront, as we only really need those two 8b values stored in our per-req payload. Cc: stable@vger.kernel.org # 6.17+ Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit f17d521075325b8afc42d1baa1c28a5e9aca111f Author: Naman Jain Date: Fri Apr 10 15:34:13 2026 +0000 block: add pgmap check to biovec_phys_mergeable commit 13920e4b7b784b40cf4519ff1f0f3e513476a499 upstream. biovec_phys_mergeable() is used by the request merge, DMA mapping, and integrity merge paths to decide if two physically contiguous bvec segments can be coalesced into one. It currently has no check for whether the segments belong to different dev_pagemaps. When zone device memory is registered in multiple chunks, each chunk gets its own dev_pagemap. A single bio can legitimately contain bvecs from different pgmaps -- iov_iter_extract_bvecs() breaks at pgmap boundaries but the outer loop in bio_iov_iter_get_pages() continues filling the same bio. If such bvecs are physically contiguous, biovec_phys_mergeable() will coalesce them, making it impossible to recover the correct pgmap for the merged segment via page_pgmap(). Add a zone_device_pages_have_same_pgmap() check to prevent merging bvec segments that span different pgmaps. Fixes: 49580e690755 ("block: add check when merging zone device pages") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Naman Jain Link: https://patch.msgid.link/20260410153414.4159050-2-namjain@linux.microsoft.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit cb27e43c0511e9e1ca8818d231656070b11c18cf Author: Wentao Liang Date: Wed Apr 8 14:11:21 2026 +0000 pmdomain: mediatek: fix use-after-free in scpsys_get_bus_protection_legacy() commit ec1fcddb3117d9452210e838fd37389ee61e10e8 upstream. In scpsys_get_bus_protection_legacy(), of_find_node_with_property() returns a device node with its reference count incremented. The function then calls of_node_put(node) before checking whether syscon_regmap_lookup_by_phandle() returns an error. If an error occurs, dev_err_probe() dereferences the node pointer to print diagnostic information, but the node memory may have already been freed due to the earlier of_node_put(), leading to a use-after-free vulnerability. Fix this by moving the of_node_put() call after the error check, ensuring the node is still valid when accessed in the error path. Fixes: c29345fa5f66 ("pmdomain: mediatek: Refactor bus protection regmaps retrieval") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 8aacf87718b90af440e323e0f5f5d14aeb343090 Author: Breno Leitao Date: Tue May 5 09:02:13 2026 -0700 arm64/fpsimd: ptrace: zero target's fpsimd_state, not the tracer's commit 5cbb61bf4168859d97c068d88d364f4f1f440325 upstream. sve_set_common() is the backend for PTRACE_SETREGSET(NT_ARM_SVE) and PTRACE_SETREGSET(NT_ARM_SSVE). Every write in the function operates on the tracee (target) - except a single memset that uses current instead, zeroing the tracer's saved V0-V31 / FPSR / FPCR shadow on every ptrace SETREGSET call. The memset is meant to give the tracee a defined zero register image before the user-supplied payload is copied in (for partial writes, header-only writes, and FPSIMD<->SVE format switches). Aiming it at current both denies the tracee that clean slate and silently corrupts the tracer. The corruption of the tracer's saved FPSIMD state is not always observable. Where the tracer's state is live on a CPU, this may be reused without loading the corrupted state from memory, and will eventually be written back over the corrupted state. Where the tracer's state is saved in SVE_PT_REGS_SVE format, only the FPSR and FPCR are clobbered, and the effective copy of the vectors is in the task's sve_state. Reproducible on an arm64 kernel with SVE: a single-threaded tracer that loads a known pattern into V0-V31, issues PTRACE_SETREGSET(NT_ARM_SVE) on a child, and reads V0-V31 back observes them all zeroed within tens of thousands of iterations when a sibling thread keeps stealing the FPSIMD CPU binding. Fixes: 316283f276eb ("arm64/fpsimd: ptrace: Consistently handle partial writes to NT_ARM_(S)SVE") Cc: Signed-off-by: Breno Leitao Acked-by: Mark Rutland Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit c34c41446acf6c0d13b5b06c809be11e0f7f2729 Author: Jiexun Wang Date: Wed May 6 22:08:23 2026 +0800 af_unix: Reject SIOCATMARK on non-stream sockets commit d119775f2bad827edc28071c061fdd4a91f889a5 upstream. SIOCATMARK reports whether the receive queue is at the urgent mark for MSG_OOB. In AF_UNIX, MSG_OOB is supported only for SOCK_STREAM sockets. SOCK_DGRAM and SOCK_SEQPACKET reject MSG_OOB in sendmsg() and recvmsg(), so they should not support SIOCATMARK either. Return -EOPNOTSUPP for non-stream sockets before checking the receive queue. Fixes: 314001f0bf92 ("af_unix: Add OOB support") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Suggested-by: Kuniyuki Iwashima Signed-off-by: Jiexun Wang Signed-off-by: Ren Wei Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260506140825.2987635-1-n05ec@lzu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit aa4d6fee0449c376fc3b73f1fb223106c126bd57 Author: Myeonghun Pak Date: Fri Apr 24 22:50:51 2026 +0900 hwmon: (corsair-psu) Close HID device on probe errors commit 174606451fbb17db506ebaacdd5e203e57773d5f upstream. corsairpsu_probe() opens the HID device before sending the device init and firmware-info commands. If either command fails, the error path jumps directly to fail_and_stop and skips hid_hw_close(). Use the existing fail_and_close label for those post-open failures so the open count and low-level close callback are balanced before hid_hw_stop(). Fixes: d115b51e0e56 ("hwmon: add Corsair PSU HID controller driver") Cc: stable@vger.kernel.org Signed-off-by: Myeonghun Pak Reviewed-by: Wilken Gottwalt Link: https://lore.kernel.org/r/20260424135107.13720-1-mhun512@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 370d4deba194ae37148a7304b01b338036df32ca Author: Johan Hovold Date: Tue Apr 7 11:50:27 2026 +0200 clk: rk808: fix OF node reference imbalance commit de019f203b0d472c98ead4081ad4f05d92c9b826 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: 2dc51ca822e4 ("clk: RK808: Reduce 'struct rk808' usage") Cc: stable@vger.kernel.org # 6.5 Cc: Sebastian Reichel Signed-off-by: Johan Hovold Reviewed-by: Sebastian Reichel Reviewed-by: Brian Masney Reviewed-by: Heiko Stuebner Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 13a0f0204d54e038eb3c4e59842e6309256e575f Author: Sanman Pradhan Date: Thu Apr 16 21:59:40 2026 +0000 hwmon: (ltc2992) Fix u32 overflow in power read path commit 2da0c1fd01dbd6b22844e8676585153dfc660cbe upstream. ltc2992_get_power() computes the divisor for mul_u64_u32_div() as r_sense_uohm * 1000. This multiplication overflows u32 when r_sense_uohm exceeds about 4.29 ohms (4294967 micro-ohms), producing a truncated divisor and an incorrect power reading. Cancel the factor of 1000 from both the numerator (VADC_UV_LSB * IADC_NANOV_LSB = 312500000) and the divisor (r_sense_uohm * 1000), giving (VADC_UV_LSB / 1000) * IADC_NANOV_LSB = 312500 as the numerator and plain r_sense_uohm as the divisor. The cancellation is exact because LTC2992_VADC_UV_LSB (25000) is divisible by 1000. This is the read-path counterpart of the write-path fix applied in the preceding patch. Fixes: b0bd407e94b03 ("hwmon: (ltc2992) Add support") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan Link: https://lore.kernel.org/r/20260416215904.101969-3-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 357ef14bfde2adb4ea43d94410ce43912c2abddc Author: Sanman Pradhan Date: Thu Apr 16 21:59:30 2026 +0000 hwmon: (ltc2992) Clamp threshold writes to hardware range commit d6cc7c99bf1f73eda7d565d224d791d16239bb41 upstream. ltc2992_set_voltage(), ltc2992_set_current(), and ltc2992_set_power() do not validate the user-supplied value before converting it to a register value. This can result in: 1. Negative input values wrapping to large positive register values. For power, the negative long is implicitly cast to u64 in mul_u64_u32_div(), producing an incorrect value. For voltage and current, the negative converted value wraps when passed to ltc2992_write_reg() as a u32. 2. Intermediate arithmetic exceeding the range representable in u64 on 64-bit platforms. In ltc2992_set_voltage(), (u64)val * 1000 can exceed U64_MAX when val is a large positive long. In ltc2992_set_current(), (u64)val * r_sense_uohm can overflow similarly. In ltc2992_set_power(), the computed value may not fit in u64. 3. Register values exceeding the hardware field width. Voltage and current threshold registers are 12-bit (stored left-justified in 16 bits), and power threshold registers are 24-bit. Without clamping, bits above the field width are truncated in ltc2992_write_reg(). Fix by clamping negative values to zero, clamping positive values to the rounded hardware-representable maximum (the value returned by the read path for a full-scale register) to prevent intermediate overflow, and clamping the converted register value to the hardware field width before writing. The existing conversion formula and rounding behavior are preserved. In the power write path, cancel the factor of 1000 from both the numerator (r_sense_uohm * 1000) and the denominator (VADC_UV_LSB * IADC_NANOV_LSB) to also eliminate a u32 overflow of r_sense_uohm * 1000 when r_sense_uohm exceeds about 4.29 ohms. Fixes: b0bd407e94b03 ("hwmon: (ltc2992) Add support") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan Link: https://lore.kernel.org/r/20260416215904.101969-2-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 22b365ba1af3d8c6036b8e5112fffe80998b85a0 Author: Ivan Hu Date: Thu Apr 30 15:41:07 2026 +0800 x86/efi: Fix graceful fault handling after FPU softirq changes commit 088f65e206087bf903743bd18417261d7a4c9644 upstream. Since commit d02198550423 ("x86/fpu: Improve crypto performance by making kernel-mode FPU reliably usable in softirqs"), kernel_fpu_begin() calls fpregs_lock() which uses local_bh_disable() instead of the previous preempt_disable(). This sets SOFTIRQ_OFFSET in preempt_count during the entire EFI runtime service call, causing in_interrupt() to return true in normal task context. The graceful page fault handler efi_crash_gracefully_on_page_fault() uses in_interrupt() to bail out for faults in real interrupt context. With SOFTIRQ_OFFSET now set, the handler always bails out, leaving EFI firmware page faults unhandled. This escalates to die() which also sees in_interrupt() as true and calls panic("Fatal exception in interrupt"), resulting in a hard system freeze. On systems with buggy firmware that triggers page faults during EFI runtime calls (e.g., accessing unmapped memory in GetTime()), this causes an unrecoverable hang instead of the expected graceful EFI_ABORTED recovery. Fix by replacing in_interrupt() with !in_task(). This preserves the original intent of bailing for interrupts or NMI faults, while no longer falsely triggering from the FPU code path's local_bh_disable(). Fixes: d02198550423 ("x86/fpu: Improve crypto performance by making kernel-mode FPU reliably usable in softirqs") Cc: Signed-off-by: Ivan Hu [ardb: Sashiko spotted that using 'in_hardirq() || in_nmi()' leaves a window where a softirq may be taken before fpregs_lock() is called, but after efi_rts_work.efi_rts_id has been assigned, and any page faults occurring in that window will then be misidentified as having been caused by the firmware. Instead, use !in_task(), which incorporates in_serving_softirq(). ] Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit c9b620425fd03a1bbe922bcacf4a257ab4149c0f Author: Hongling Zeng Date: Sun May 3 12:17:44 2026 +0800 parisc: Fix IRQ leak in LASI driver commit 37b0dc5e279f35036fb638d1e187197b6c05a76d upstream. When request_irq() succeeds but gsc_common_setup() fails later, the IRQ is never released. Fix this by adding proper error handling with goto labels to ensure resources are released in LIFO order. Detected by Smatch: drivers/parisc/lasi.c:216 lasi_init_chip() warn: 'lasi->gsc_irq.irq' from request_irq() not released on lines: 207. Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202604180957.4QdAIxP6-lkp@intel.com/ Signed-off-by: Hongling Zeng Cc: stable@vger.kernel.org Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 23ae72e8c2f1c1d1da8cbd479320ddcfcc9c7435 Author: Tzung-Bi Shih Date: Tue May 5 05:34:03 2026 +0000 platform/chrome: cros_ec_typec: Init mutex in Thunderbolt registration commit 525cb7ba6661074c1c5cc3772bccc6afab6791ef upstream. cros_typec_register_thunderbolt() missed initializing the `adata->lock` mutex. This leads to a NULL dereference when the mutex is later acquired (e.g. in cros_typec_altmode_work()). Initialize the mutex in cros_typec_register_thunderbolt() to fix the issue. Cc: stable@vger.kernel.org Fixes: 3b00be26b16a ("platform/chrome: cros_ec_typec: Thunderbolt support") Reviewed-by: Benson Leung Reviewed-by: Abhishek Pandit-Subedi Link: https://lore.kernel.org/r/20260505053403.3335740-1-tzungbi@kernel.org Signed-off-by: Tzung-Bi Shih Signed-off-by: Greg Kroah-Hartman commit 2b56d7903ab804481f5233a259d5f341e9fd513c Author: Pavitra Jha Date: Fri May 1 07:07:12 2026 -0400 net: wwan: t7xx: validate port_count against message length in t7xx_port_enum_msg_handler commit 0e7c074cfcd9bd93765505f9eb8b42f03ed2a744 upstream. t7xx_port_enum_msg_handler() uses the modem-supplied port_count field as a loop bound over port_msg->data[] without checking that the message buffer contains sufficient data. A modem sending port_count=65535 in a 12-byte buffer triggers a slab-out-of-bounds read of up to 262140 bytes. Add a sizeof(*port_msg) check before accessing the port message header fields to guard against undersized messages. Add a struct_size() check after extracting port_count and before the loop. In t7xx_parse_host_rt_data(), guard the rt_feature header read with a remaining-buffer check before accessing data_len, validate feat_data_len against the actual remaining buffer to prevent OOB reads and signed integer overflow on offset. Pass msg_len from both call sites: skb->len at the DPMAIF path after skb_pull(), and the validated feat_data_len at the handshake path. Fixes: da45d2566a1d ("net: wwan: t7xx: Add control port") Cc: stable@vger.kernel.org Signed-off-by: Pavitra Jha Link: https://patch.msgid.link/20260501110713.145563-1-jhapavitra98@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 14ef6fd18db2494098b21e0471bf27a1d8e9993e Author: Nan Li Date: Fri May 1 09:08:44 2026 +0800 net/rds: handle zerocopy send cleanup before the message is queued commit 44b550d88b267320459d518c0743a241ab2108fa upstream. A zerocopy send can fail after user pages have been pinned but before the message is attached to the sending socket. The purge path currently infers zerocopy state from rm->m_rs, so an unqueued message can be cleaned up as if it owned normal payload pages. However, zerocopy ownership is really determined by the presence of op_mmp_znotifier, regardless of whether the message has reached the socket queue. Capture op_mmp_znotifier up front in rds_message_purge() and use it as the cleanup discriminator. If the message is already associated with a socket, keep the existing completion path. Otherwise, drop the pinned page accounting directly and release the notifier before putting the payload pages. This keeps early send failure cleanup consistent with the zerocopy lifetime rules without changing the normal queued completion path. Fixes: 0cebaccef3ac ("rds: zerocopy Tx support.") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Co-developed-by: Xiao Liu Signed-off-by: Xiao Liu Signed-off-by: Nan Li Signed-off-by: Ren Wei Reviewed-by: Allison Henderson Link: https://patch.msgid.link/d2ea98a6313d5467bac00f7c9fef8c7acddb9258.1777550074.git.tonanli66@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 3d47d62c134801eb260c2573ba9e5c4eb0651eb8 Author: Breno Leitao Date: Fri May 1 02:58:41 2026 -0700 netpoll: pass buffer size to egress_dev() to avoid MAC truncation commit 76b93a8107574006b25495664304ea9237494d70 upstream. egress_dev() formats np->dev_mac via snprintf() but receives buf as a bare char *, so it cannot derive the buffer size from the pointer. The size argument was hardcoded to MAC_ADDR_STR_LEN (3 * ETH_ALEN - 1 = 17), which is silly wrong in two ways: 1) misleading kernel log output on the MAC-selected target path (np->dev_name[0] == '\0'); for example "aa:bb:cc:dd:ee:ff doesn't exist, aborting" was logged as "aa:bb:cc:dd:ee:f doesn't exist, aborting". 2) the second argument of snprintf is the size of the buffer, not the size of what you want to write. Add a bufsz parameter to egress_dev() and pass sizeof(buf) from each caller, matching the standard snprintf() idiom and removing the hardcoded size from the helper. Every caller already declares "char buf[MAC_ADDR_STR_LEN + 1]" so the formatted MAC continues to fit. Tested by booting with netconsole=6665@/aa:bb:cc:dd:ee:ff,6666@10.0.0.1/00:11:22:33:44:55 on a kernel without a matching device. Pre-fix dmesg shows "aa:bb:cc:dd:ee:f doesn't exist, aborting"; post-fix shows the full "aa:bb:cc:dd:ee:ff doesn't exist, aborting". Fixes: f8a10bed32f5 ("netconsole: allow selection of egress interface via MAC address") Cc: stable@vger.kernel.org Signed-off-by: Breno Leitao Link: https://patch.msgid.link/20260501-netpoll_snprintf_fix-v1-1-84b0566e6597@debian.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1bca036fe3607182c21f05e2b262167edbef086c Author: Jiawen Wu Date: Wed Apr 29 16:37:43 2026 +0800 net: libwx: use request_irq for VF misc interrupt commit 7a33345153eeeda195c55f15be27074e4c3b5109 upstream. Currently, request_threaded_irq() is used with a primary handler but a NULL threaded handler, while also setting the IRQF_ONESHOT flag. This specific combination triggers a WARNING since the commit aef30c8d569c ("genirq: Warn about using IRQF_ONESHOT without a threaded handler"). WARNING: kernel/irq/manage.c:1502 at __setup_irq+0x4fa/0x760 Fix the issue by switching to request_irq(), which is the appropriate interface or a non-threaded interrupt handler, and removing the unnecessary IRQF_ONESHOT flag. Fixes: eb4898fde1de ("net: libwx: add wangxun vf common api") Cc: stable@vger.kernel.org Signed-off-by: Jiawen Wu Link: https://patch.msgid.link/786DDC7D5CCA6D0A+20260429083743.88961-2-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e70cfb40c3a99b232cd42c6a6a10f0d8e039dc82 Author: Maoyi Xie Date: Thu Apr 30 18:33:18 2026 +0800 ip6_gre: Use cached t->net in ip6erspan_changelink(). commit 1d324c2f43f70c965f25c58cc3611c779adbe47e upstream. After commit 5e72ce3e3980 ("net: ipv6: Use link netns in newlink() of rtnl_link_ops"), ip6erspan_newlink() correctly resolves the per-netns ip6gre hash via link_net. ip6erspan_changelink() was not converted in that series and still uses dev_net(dev), which diverges from the device's creation netns after IFLA_NET_NS_FD migration. This re-inserts the tunnel into the wrong per-netns hash. The original netns keeps a stale entry. When that netns is later destroyed, ip6gre_exit_rtnl_net() walks the stale entry, producing a slab-use-after-free reported by KASAN, followed by a kernel BUG at net/core/dev.c (LIST_POISON1) in unregister_netdevice_many_notify(). Reachable from an unprivileged user namespace (unshare --user --map-root-user --net). ip6gre_changelink() earlier in the same file already uses the cached t->net; only ip6erspan_changelink() has the wrong shape. Fixes: 2d665034f239 ("net: ip6_gre: Fix ip6erspan hlen calculation") Cc: stable@vger.kernel.org # v5.15+ Signed-off-by: Maoyi Xie Reviewed-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260430103318.3206018-1-maoyi.xie@ntu.edu.sg Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 33c5bb50b9c40e8451e6aec4487a31d794b98d92 Author: Jiawen Wu Date: Wed Apr 29 16:37:42 2026 +0800 net: libwx: fix VF illegal register access commit 694de316f607fe2473d52ca0707e3918e72c1562 upstream. Register WX_CFG_PORT_ST is a PF restricted register. When a VF is initialized, attempting to read this register triggers an illegal register access, which lead to a system hang. When the device is VF, the bus function ID can be obtained directly from the PCI_FUNC(pdev->devfn). Fixes: a04ea57aae37 ("net: libwx: fix device bus LAN ID") Cc: stable@vger.kernel.org Signed-off-by: Jiawen Wu Link: https://patch.msgid.link/4D1F4452D21DE107+20260429083743.88961-1-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 62951b49754aceda027e0a017dc9bb52ef5094fd Author: Ritesh Harjani (IBM) Date: Fri May 1 09:41:44 2026 +0530 pseries/papr-hvpipe: Fix the usage of copy_to_user() commit d48654bd8b1a75f662e224d257db54de475120dc upstream. copy_to_user() return bytes_not_copied to the user buffer. If there was an error writing bytes into the user buffer, i.e. if copy_to_user returns a non-zero value, then we should simply return -EFAULT from the ->read() call. Otherwise, in the non-patched version, we may end up mixing "bytes_not_copied + bytes_copied (HVPIPE_HDR_LEN)" as the return value to the user in ->read() call Also let's make sure we clear the hvpipe_status flag, if we have consumed the hvpipe msg by making the rtas call. ret = -EFAULT means copy_to_user has failed but that still means that the msg was read from the hvpipe, hence for both cases, success & -EFAULT, we should clear the HVPIPE_MSG_AVAILABLE flag in hvpipe_status. Cc: stable@vger.kernel.org Fixes: cebdb522fd3edd1 ("powerpc/pseries: Receive payload with ibm,receive-hvpipe-msg RTAS") Signed-off-by: Ritesh Harjani (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/8fda3212a1ad48879c174e92f67472d9b9f1c3b7.1777606826.git.ritesh.list@gmail.com Signed-off-by: Greg Kroah-Hartman commit 2b1335edaac5fec564b37883d5703912d97d8c5d Author: Ritesh Harjani (IBM) Date: Fri May 1 09:41:43 2026 +0530 pseries/papr-hvpipe: Fix & simplify error handling in papr_hvpipe_init() commit 713e468cdbc2277db6ce949c32c1acbd83501733 upstream. Remove such 3 levels of nesting patterns to check success return values from function calls. ret = enable_hvpipe_IRQ() if (!ret) ret = set_hvpipe_sys_param(1) if (!ret) ret = misc_register() Instead just bail out to "out*:" labels, in case of any error. This simplifies the init flow. While at it let's also fix the following error handling logic: We have already enabled interrupt sources and enabled hvpipe to received interrupts, if misc_register() fails, we will destroy the workqueue, but the HMC might send us a msg via hvpipe which will call, queue work on the workqueue which might be destroyed. So instead, let's reverse the order of enabling set_hvpipe_sys_param(1) and in case of an error let's remove the misc dev by calling misc_deregister(). Cc: stable@vger.kernel.org Fixes: 39a08a4f94980 ("powerpc/pseries: Enable hvpipe with ibm,set-system-parameter RTAS") Signed-off-by: Ritesh Harjani (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/f2141eafb80e7780395e03aa9a22e8a37be80513.1777606826.git.ritesh.list@gmail.com Signed-off-by: Greg Kroah-Hartman commit 0479b6e9f999cc1cbad7d9f09f574fc387e605d5 Author: Ritesh Harjani (IBM) Date: Fri May 1 09:41:41 2026 +0530 pseries/papr-hvpipe: Prevent kernel stack memory leak to userspace commit cefeed44296261173a806bef988b26bc565da4be upstream. The hdr variable is allocated on the stack and only hdr.version and hdr.flags are initialized explicitly. Because the struct papr_hvpipe_hdr contains reserved padding bytes (reserved[3] and reserved2[40]), these could leak the uninitialized bytes to userspace after copy_to_user(). This patch fixes that by initializing the whole struct to 0. Cc: stable@vger.kernel.org Fixes: cebdb522fd3ed ("powerpc/pseries: Receive payload with ibm,receive-hvpipe-msg RTAS") Signed-off-by: Ritesh Harjani (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/7bfe03b65a282c856ed8182d1871bb973c0b78f2.1777606826.git.ritesh.list@gmail.com Signed-off-by: Greg Kroah-Hartman commit 0ff2b713f406e9ecadb406014d74e7a020ac12b1 Author: SeungJu Cheon Date: Sun Apr 26 20:12:39 2026 +0900 sound: ua101: fix division by zero at probe commit d1f73f169c1014463b5060e3f60813e13ddc7b87 upstream. Add a missing sanity check for bNrChannels in detect_usb_format() to prevent a division by zero in playback_urb_complete() and capture_urb_complete(). USB core does not validate class-specific descriptor fields such as bNrChannels, so drivers must verify them before use. If a device provides bNrChannels = 0, frame_bytes becomes zero and is later used as a divisor in the URB completion handlers, leading to a kernel crash. Fixes: 63978ab3e3e9 ("sound: add Edirol UA-101 support") Cc: stable@vger.kernel.org Signed-off-by: SeungJu Cheon Link: https://patch.msgid.link/20260426111239.103296-1-suunj1331@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit aab56b95bee3ff79176b13443cd9d7cfe9747df0 Author: Dapeng Mi Date: Thu Apr 30 08:25:54 2026 +0800 perf/x86/intel: Improve validation and configuration of ACR masks commit 5ad732a56be46aabf158c16aa0c095291727aaef upstream. Currently there are several issues on the user space ACR mask validation and configuration. - The validation for user space ACR mask (attr.config2) is incomplete, e.g., the ACR mask could include the index which belongs to another ACR events group, but it's not validated. - An early return on an invalid ACR mask caused all subsequent ACR groups to be skipped. - The stale hardware ACR mask (hw.config1) is not cleared before setting new hardware ACR mask. The following changes address all of the above issues. - Figure out the event index group of an ACR group. Any bits in the user-space mask not present in the index group are now dropped. - Instead of an early return on invalid bits, drop only the invalid portions and continue iterating through all ACR events to ensure full configuration. - Explicitly clear the stale hardware ACR mask for each event prior to writing the new configuration. Besides, a non-leader event member of ACR group could be disabled in theory. This could cause bit-shifting errors in the acr_mask of remaining group members. But since ACR sampling requires all events to be active, this should not be a big concern in real use case. Add a "FIXME" comment to notice this risk. Fixes: ec980e4facef ("perf/x86/intel: Support auto counter reload") Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260430002558.712334-2-dapeng1.mi@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 4bf22a0afb27c7fdce2230d0cf30eee57cc1c883 Author: Matthieu Baerts (NGI0) Date: Tue May 5 17:00:55 2026 +0200 mptcp: pm: ADD_ADDR rtx: skip inactive subflows commit c6d395e2de1306b5fef0344a3c3835fbbfaa18be upstream. When looking at the maximum RTO amongst the subflows, inactive subflows were taken into account: that includes stale ones, and the initial one if it has been already been closed. Unusable subflows are now simply skipped. Stale ones are used as an alternative: if there are only stale ones, to take their maximum RTO and avoid to eventually fallback to net.mptcp.add_addr_timeout, which is set to 2 minutes by default. Fixes: 30549eebc4d8 ("mptcp: make ADD_ADDR retransmission timeout adaptive") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260505-net-mptcp-pm-fixes-7-1-rc3-v1-7-fca8091060a4@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit fbe0e6197225e6a83cf113a67a4b425f8de0bcd5 Author: Kai Zen Date: Thu Apr 30 18:26:48 2026 +0300 net: rtnetlink: zero ifla_vf_broadcast to avoid stack infoleak in rtnl_fill_vfinfo commit 4b9e327991815e128ad3af75c3a04630a63ce3e0 upstream. rtnl_fill_vfinfo() declares struct ifla_vf_broadcast on the stack without initialisation: struct ifla_vf_broadcast vf_broadcast; The struct contains a single fixed 32-byte field: /* include/uapi/linux/if_link.h */ struct ifla_vf_broadcast { __u8 broadcast[32]; }; The function then copies dev->broadcast into it using dev->addr_len as the length: memcpy(vf_broadcast.broadcast, dev->broadcast, dev->addr_len); On Ethernet devices (the overwhelming majority of SR-IOV NICs) dev->addr_len is 6, so only the first 6 bytes of broadcast[] are written. The remaining 26 bytes retain whatever was previously on the kernel stack. The full struct is then handed to userspace via: nla_put(skb, IFLA_VF_BROADCAST, sizeof(vf_broadcast), &vf_broadcast) leaking up to 26 bytes of uninitialised kernel stack per VF per RTM_GETLINK request, repeatable. The other vf_* structs in the same function are explicitly zeroed for exactly this reason - see the memset() calls for ivi, vf_vlan_info, node_guid and port_guid a few lines above. vf_broadcast was simply missed when it was added. Reachability: any unprivileged local process can open AF_NETLINK / NETLINK_ROUTE without capabilities and send RTM_GETLINK with an IFLA_EXT_MASK attribute carrying RTEXT_FILTER_VF. The kernel walks each VF and emits IFLA_VF_BROADCAST, leaking 26 bytes of stack per VF per request. Stack residue at this call site can include return addresses and transient sensitive data; KASAN with stack instrumentation, or KMSAN, will flag the nla_put() when reproduced. Zero the on-stack struct before the partial memcpy, matching the existing pattern used for the other vf_* structs in the same function. Fixes: 75345f888f70 ("ipoib: show VF broadcast address") Cc: stable@vger.kernel.org Signed-off-by: Kai Zen Link: https://patch.msgid.link/3c506e8f936e52b57620269b55c348af05d413a2.1777557228.git.kai.aizen.dev@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 52070a91956fe758e33a029ea8307bb71023a214 Author: Huacai Chen Date: Mon May 4 09:00:01 2026 +0800 LoongArch: Fix SYM_SIGFUNC_START definition for 32BIT commit 98b8aebb14fdc0133939fd8fe07d0d98333dc976 upstream. The SYM_SIGFUNC_START definition should match sigcontext that the length of GPRs are 8 bytes for both 32BIT and 64BIT. So replace SZREG with 8 to fix it. Cc: stable@vger.kernel.org Fixes: e4878c37f6679fde ("LoongArch: vDSO: Emit GNU_EH_FRAME correctly") Suggested-by: Xi Ruoyao Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 8f75597dfc67bd8c6b9c0ea9fc42abb28e3f6b04 Author: Sang-Heon Jeon Date: Wed Apr 22 23:33:53 2026 +0900 mm/hugetlb_cma: round up per_node before logging it commit 8f5ce56b76303c55b78a87af996e2e0f8535f979 upstream. When the user requests a total hugetlb CMA size without per-node specification, hugetlb_cma_reserve() computes per_node from hugetlb_cma_size and the number of nodes that have memory per_node = DIV_ROUND_UP(hugetlb_cma_size, nodes_weight(hugetlb_bootmem_nodes)); The reservation loop later computes size = round_up(min(per_node, hugetlb_cma_size - reserved), PAGE_SIZE << order); So the actually reserved per_node size is multiple of (PAGE_SIZE << order), but the logged per_node is not rounded up, so it may be smaller than the actual reserved size. For example, as the existing comment describes, if a 3 GB area is requested on a machine with 4 NUMA nodes that have memory, 1 GB is allocated on the first three nodes, but the printed log is hugetlb_cma: reserve 3072 MiB, up to 768 MiB per node Round per_node up to (PAGE_SIZE << order) before logging so that the printed log always matches the actual reserved size. No functional change to the actual reservation size, as the following case analysis shows 1. remaining (hugetlb_cma_size - reserved) >= rounded per_node - AS-IS: min() picks unrounded per_node; round_up() returns rounded per_node - TO-BE: min() picks rounded per_node; round_up() returns rounded per_node (no-op) 2. remaining < unrounded per_node - AS-IS: min() picks remaining; round_up() returns round_up(remaining) - TO-BE: min() picks remaining; round_up() returns round_up(remaining) 3. unrounded per_node <= remaining < rounded per_node - AS-IS: min() picks unrounded per_node; round_up() returns rounded per_node - TO-BE: min() picks remaining; round_up() returns round_up(remaining) equals rounded per_node Link: https://lore.kernel.org/20260422143353.852257-1-ekffu200098@gmail.com Fixes: cf11e85fc08c ("mm: hugetlb: optionally allocate gigantic hugepages using cma") # 5.7 Signed-off-by: Sang-Heon Jeon Reviewed-by: Muchun Song Cc: David Hildenbrand Cc: Oscar Salvador Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 10c252577ccdb0f05bf4cb1e3972e9613db69895 Author: Kevin Brodsky Date: Mon Apr 27 13:03:33 2026 +0100 arm64: signal: Preserve POR_EL0 if poe_context is missing commit 030e8a40fff65ca6ac1c04a4d3c08afe72438922 upstream. Commit 2e8a1acea859 ("arm64: signal: Improve POR_EL0 handling to avoid uaccess failures") delayed the write to POR_EL0 in rt_sigreturn to avoid spurious uaccess failures. This change however relies on the poe_context frame record being present: on a system supporting POE, calling sigreturn without a poe_context record now results in writing arbitrary data from the kernel stack into POR_EL0. Fix this by adding a __valid_fields member to struct user_access_state, and zeroing the struct on allocation. restore_poe_context() then indicates that the por_el0 field is valid by setting the corresponding bit in __valid_fields, and restore_user_access_state() only touches POR_EL0 if there is a valid value to set it to. This is in line with how POR_EL0 was originally handled; all frame records are currently optional, except fpsimd_context. To ensure that __valid_fields is kept in sync, fields (currently just por_el0) are now accessed via accessors and prefixed with __ to discourage direct access. Fixes: 2e8a1acea859 ("arm64: signal: Improve POR_EL0 handling to avoid uaccess failures") Cc: Reported-by: Will Deacon Signed-off-by: Kevin Brodsky Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 34bdcfb496b29f9a52431194f94473b37fb8c162 Author: Tudor Ambarus Date: Fri Apr 17 15:24:39 2026 +0000 mtd: spi-nor: debugfs: fix out-of-bounds read in spi_nor_params_show() commit e47029b977e747cb3a9174308fd55762cce70147 upstream. Sashiko noticed an out-of-bounds read [1]. In spi_nor_params_show(), the snor_f_names array is passed to spi_nor_print_flags() using sizeof(snor_f_names). Since snor_f_names is an array of pointers, sizeof() returns the total number of bytes occupied by the pointers (element_count * sizeof(void *)) rather than the element count itself. On 64-bit systems, this makes the passed length 8x larger than intended. Inside spi_nor_print_flags(), the 'names_len' argument is used to bounds-check the 'names' array access. An out-of-bounds read occurs if a flag bit is set that exceeds the array's actual element count but is within the inflated byte-size count. Correct this by using ARRAY_SIZE() to pass the actual number of string pointers in the array. Cc: stable@vger.kernel.org Fixes: 0257be79fc4a ("mtd: spi-nor: expose internal parameters via debugfs") Closes: https://sashiko.dev/#/patchset/20260417-die-erase-fix-v2-1-73bb7004ebad%40infineon.com [1] Signed-off-by: Tudor Ambarus Reviewed-by: Takahiro Kuwano Reviewed-by: Michael Walle Reviewed-by: Pratyush Yadav Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 83b131a214f1fd112bc3d42f3b7ca1419b963759 Author: Fuad Tabba Date: Fri Apr 24 09:49:06 2026 +0100 KVM: arm64: Fix kvm_vcpu_initialized() macro parameter commit d89fdda7dd8a488f922e1175e6782f781ba8a23b upstream. The macro is defined with parameter 'v' but the body references the literal token 'vcpu' instead, causing it to silently operate on whatever 'vcpu' resolves to in the caller's scope rather than the value passed by the caller. All current call sites happen to use a variable named 'vcpu', so the bug is latent. Fixes: e016333745c7 ("KVM: arm64: Only reset vCPU-scoped feature ID regs once") Signed-off-by: Fuad Tabba Link: https://patch.msgid.link/20260424084908.370776-5-tabba@google.com Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 7baa02b0ae9d17ec5f08836d8ea88ce1927d0678 Author: Miklos Szeredi Date: Fri Apr 10 16:49:47 2026 +0200 fanotify: fix false positive on permission events commit 7746e3bd4cc19b5092e00d32d676e329bfcb6900 upstream. fsnotify_get_mark_safe() may return false for a mark on an unrelated group, which results in bypassing the permission check. Fix by skipping over detached marks that are not in the current group. CC: stable@vger.kernel.org Fixes: abc77577a669 ("fsnotify: Provide framework for dropping SRCU lock in ->handle_event") Signed-off-by: Miklos Szeredi Link: https://patch.msgid.link/20260410144950.156160-1-mszeredi@redhat.com Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit d71240d2609bebe9e2074c5912a60fe76415d238 Author: Johan Hovold Date: Fri Apr 24 12:49:10 2026 +0200 staging: vme_user: fix root device leak on init failure commit 32c91e8ee039777d0b95b914633fc6a42607959c upstream. Make sure to deregister and free the root device in case module initialisation fails. Fixes: 658bcdae9c67 ("vme: Adding Fake VME driver") Cc: stable@vger.kernel.org # 4.9 Cc: Martyn Welch Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260424104910.2619349-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 1b66f16a571a10ba8889ac471755c8af9c5b9266 Author: Johan Hovold Date: Fri Apr 10 11:49:25 2026 +0200 spi: s3c64xx: fix NULL-deref on driver unbind commit 45daacbead8a009844bd5dba6cfa731332184d17 upstream. A change moving DMA channel allocation from probe() back to s3c64xx_spi_prepare_transfer() failed to remove the corresponding deallocation from remove(). Drop the bogus DMA channel release from remove() to avoid triggering a NULL-pointer dereference on driver unbind. This issue was flagged by Sashiko when reviewing a controller deregistration fix. Fixes: f52b03c70744 ("spi: s3c64xx: requests spi-dma channel only during data transfer") Cc: stable@vger.kernel.org # 6.0 Cc: Adithya K V Link: https://sashiko.dev/#/patchset/20260410081757.503099-1-johan%40kernel.org Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410094925.518343-1-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 4f0dd529990d6668aae19d39bd6fae40cab962ef Author: Johan Hovold Date: Fri Apr 10 10:17:55 2026 +0200 spi: zynqmp-gqspi: fix controller deregistration commit 6895fc4faafc9082e15e4e624b23dd5f0c98feb5 upstream. Make sure to deregister the controller before disabling underlying resources like clocks during driver unbind. Fixes: dfe11a11d523 ("spi: Add support for Zynq Ultrascale+ MPSoC GQSPI controller") Cc: stable@vger.kernel.org # 4.2: 64640f6c972e Cc: stable@vger.kernel.org # 4.2 Cc: Ranjit Waghmode Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-26-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 93f83b3a50efa249c655796fb70f64325aa00d08 Author: Johan Hovold Date: Fri Apr 10 10:17:49 2026 +0200 spi: sun6i: fix controller deregistration commit d874a1c33aee0d88fb4ba2f8aeadaa9f1965209a upstream. Make sure to deregister the controller before disabling underlying resources like clocks during driver unbind. Fixes: 3558fe900e8a ("spi: sunxi: Add Allwinner A31 SPI controller driver") Cc: stable@vger.kernel.org # 3.15 Cc: Maxime Ripard Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-20-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 9df7d2530412e33f78ffa101dd6ecc4086db054d Author: Johan Hovold Date: Fri Apr 10 10:17:53 2026 +0200 spi: ti-qspi: fix controller deregistration commit 0c18a1bacbb1d8b8aa34d3d004a2cb8226c8b1ea upstream. Make sure to deregister the controller before disabling underlying resources like clocks during driver unbind. Note that the controller is suspended before disabling and releasing resources since commit 3ac066e2227c ("spi: spi-ti-qspi: Suspend the queue before removing the device") which avoids issues like unclocked accesses but prevents SPI device drivers from doing I/O during deregistration. Fixes: 3b3a80019ff1 ("spi: ti-qspi: one only one interrupt handler") Cc: stable@vger.kernel.org # 3.13 Cc: Sebastian Andrzej Siewior Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-24-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 9aea3d4f23ca3995081357511fc68fbc44a6bc7c Author: Johan Hovold Date: Fri Apr 10 10:17:48 2026 +0200 spi: sun4i: fix controller deregistration commit 42108a2f03e0fdeabe9d02d085bdb058baa1189f upstream. Make sure to deregister the controller before disabling underlying resources like clocks during driver unbind. Fixes: b5f6517948cc ("spi: sunxi: Add Allwinner A10 SPI controller driver") Cc: stable@vger.kernel.org # 3.15 Cc: Maxime Ripard Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-19-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 40db1bd1ffc6081fb4738f520bfd9dce7b2c2667 Author: Johan Hovold Date: Fri Apr 10 10:17:50 2026 +0200 spi: syncuacer: fix controller deregistration commit 75d849c3452e9611de031db45b3149ba9a99035f upstream. Make sure to deregister the controller before disabling underlying resources like clocks during driver unbind. Fixes: b0823ee35cf9 ("spi: Add spi driver for Socionext SynQuacer platform") Cc: stable@vger.kernel.org # 5.3 Cc: Masahisa Kojima Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-21-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit ca488ac3b08330d7e980ced0d16c37858b52ac1c Author: Miguel Ojeda Date: Sun Apr 26 16:42:01 2026 +0200 rust: allow `clippy::collapsible_if` globally commit 2adc8664018c1cc595c7c0c98474a33c7fe32a85 upstream. Similar to `clippy::collapsible_match` (globally allowed in the previous commit), the `clippy::collapsible_if` lint [1] can make code harder to read in certain cases. Thus just let developers decide on their own. In addition, remove the existing `expect` we had. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Suggested-by: Gary Guo Link: https://lore.kernel.org/rust-for-linux/DGROP5CHU1QZ.1OKJRAUZXE9WC@garyguo.net/ Link: https://rust-lang.github.io/rust-clippy/master/index.html#collapsible_if [1] Reviewed-by: Gary Guo Link: https://patch.msgid.link/20260426144201.227108-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 16a7e845c3a0e5130f1d51d1f92e611d6cfd26f1 Author: Miguel Ojeda Date: Sun Apr 26 16:42:00 2026 +0200 rust: allow `clippy::collapsible_match` globally commit 838d852da8503372f3a1779bfbd1ccb93153ab4e upstream. The `clippy::collapsible_match` lint [1] can make code harder to read in certain cases [2], e.g. CLIPPY P rust/libmacros.so - due to command line change warning: this `if` can be collapsed into the outer `match` --> rust/pin-init/internal/src/helpers.rs:91:17 | 91 | / if nesting == 1 { 92 | | impl_generics.push(tt.clone()); 93 | | impl_generics.push(tt); 94 | | skip_until_comma = false; 95 | | } | |_________________^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#collapsible_match = note: `-W clippy::collapsible-match` implied by `-W clippy::all` = help: to override `-W clippy::all` add `#[allow(clippy::collapsible_match)]` help: collapse nested if block | 90 ~ TokenTree::Punct(p) if skip_until_comma && p.as_char() == ',' 91 ~ && nesting == 1 => { 92 | impl_generics.push(tt.clone()); 93 | impl_generics.push(tt); 94 | skip_until_comma = false; 95 ~ } | The lint does not have much upside -- when the suggestion may be a good one, it would still read fine when nested anyway. And it is the kind of lint that may easily bias people to just apply the suggestion instead of allowing it. [ In addition, as Gary points out [3], the suggestion is also wrong [4] and in the process of being fixed [5], possibly for Rust 1.97.0: Link: https://lore.kernel.org/rust-for-linux/DI3YV94TH9I3.1SOHW51552497@garyguo.net/ [3] Link: https://github.com/rust-lang/rust-clippy/issues/16875 [4] Link: https://github.com/rust-lang/rust-clippy/pull/16878 [5] - Miguel ] Thus just let developers decide on their own. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://rust-lang.github.io/rust-clippy/master/index.html#collapsible_match [1] Link: https://lore.kernel.org/rust-for-linux/CANiq72nWYJna_hdFxjQCQZK6yJBrr1Mb86iKavivV0U0BgufeA@mail.gmail.com/ [2] Reviewed-by: Gary Guo Link: https://patch.msgid.link/20260426144201.227108-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 4ea3b2e469fc60a76b7bdd1fb25d3703dbf2b161 Author: Eliot Courtney Date: Thu Apr 23 21:36:52 2026 +0900 rust: drm: gem: clean up GEM state in init failure case commit 2e42a17b8f6bc3c0cd69d7556b588011d3ec2394 upstream. Currently, if `drm_gem_object_init` fails, the object is freed without any cleanup. Perform the cleanup in that case. Cc: stable@vger.kernel.org Fixes: c284d3e42338 ("rust: drm: gem: Add GEM object abstraction") Signed-off-by: Eliot Courtney Reviewed-by: Alice Ryhl Reviewed-by: Onur Özkan Link: https://patch.msgid.link/20260423-fix-gem-1-v1-1-e12e35f7bba9@nvidia.com [ Move safety comment closer to unsafe block to avoid a clippy warning. - Danilo ] Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 32bd343803d4ba47cc516f9d5f037f01b855d767 Author: Siwei Zhang Date: Wed Apr 15 16:53:36 2026 -0400 Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_get_sndtimeo_cb() commit 78a88d43dab8d23aeef934ed8ce34d40e6b3d613 upstream. Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb(). Fixes: 8d836d71e222 ("Bluetooth: Access sk_sndtimeo indirectly in l2cap_core.c") Cc: stable@kernel.org Signed-off-by: Siwei Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 1810e42ff6716f320c7269d5850eca48b07b7427 Author: Siwei Zhang Date: Wed Apr 15 16:51:36 2026 -0400 Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb() commit 2ff1a41a912de8517b4482e946dd951b7d80edbf upstream. Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb(). Fixes: 89bc500e41fc ("Bluetooth: Add state tracking to struct l2cap_chan") Cc: stable@kernel.org Signed-off-by: Siwei Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 741e6024e31587b0c021b6616a9e428a4ea0b64a Author: Siwei Zhang Date: Wed Apr 15 16:49:59 2026 -0400 Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_new_connection_cb() commit 0a120d96166301d7a95be75b52f843837dbd1219 upstream. Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb(). Fixes: 80808e431e1e ("Bluetooth: Add l2cap_chan_ops abstraction") Cc: stable@kernel.org Signed-off-by: Siwei Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 77981a507aa0fc001dc37f0dd6631dd2042fed17 Author: Luiz Augusto von Dentz Date: Fri Apr 10 15:29:52 2026 -0400 Bluetooth: hci_event: Fix OOB read and infinite loop in hci_le_create_big_complete_evt commit 5ddb8014261137cadaf83ab5617a588d80a22586 upstream. hci_le_create_big_complete_evt() iterates over BT_BOUND connections for a BIG handle using a while loop, accessing ev->bis_handle[i++] on each iteration. However, there is no check that i stays within ev->num_bis before the array access. When a controller sends a LE_Create_BIG_Complete event with fewer bis_handle entries than there are BT_BOUND connections for that BIG, or with num_bis=0, the loop reads beyond the valid bis_handle[] flex array into adjacent heap memory. Since the out-of-bounds values typically exceed HCI_CONN_HANDLE_MAX (0x0EFF), hci_conn_set_handle() rejects them and the connection remains in BT_BOUND state. The same connection is then found again by hci_conn_hash_lookup_big_state(), creating an infinite loop with hci_dev_lock held. Fix this by terminating the BIG if in case not all BIS could be setup properly. Fixes: a0bfde167b50 ("Bluetooth: ISO: Add support for connecting multiple BISes") Cc: stable@vger.kernel.org Signed-off-by: ZhiTao Ou Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 624fb79dadc1b65757986a9d0fdde5c0cf3fe179 Author: Tristan Madani Date: Tue Apr 21 11:14:54 2026 +0000 Bluetooth: btmtk: validate WMT event SKB length before struct access commit 634a4408c0615c523cf7531790f4f14a422b9206 upstream. btmtk_usb_hci_wmt_sync() casts the WMT event response SKB data to struct btmtk_hci_wmt_evt (7 bytes) and struct btmtk_hci_wmt_evt_funcc (9 bytes) without first checking that the SKB contains enough data. A short firmware response causes out-of-bounds reads from SKB tailroom. Use skb_pull_data() to validate and advance past the base WMT event header. For the FUNC_CTRL case, pull the additional status field bytes before accessing them. Fixes: d019930b0049 ("Bluetooth: btmtk: move btusb_mtk_hci_wmt_sync to btmtk.c") Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 3485c7236c59c8c34a41af1c4b52982437554e79 Author: Michael Bommarito Date: Tue Apr 21 13:08:45 2026 -0400 Bluetooth: virtio_bt: validate rx pkt_type header length commit daf23014e5d975e72ea9c02b5160d3fcf070ea47 upstream. virtbt_rx_handle() reads the leading pkt_type byte from the RX skb and forwards the remainder to hci_recv_frame() for every event/ACL/SCO/ISO type, without checking that the remaining payload is at least the fixed HCI header for that type. After the preceding patch bounds the backend-supplied used.len to [1, VIRTBT_RX_BUF_SIZE], a one-byte completion still reaches hci_recv_frame() with skb->len already pulled to 0. If the byte happened to be HCI_ACLDATA_PKT, the ACL-vs-ISO classification fast-path in hci_dev_classify_pkt_type() dereferences hci_acl_hdr(skb)->handle whenever the HCI device has an active CIS_LINK, BIS_LINK, or PA_LINK connection, reading two bytes of uninitialized RX-buffer data. The same hazard exists for every packet type the driver accepts because none of the switch cases in virtbt_rx_handle() check skb->len against the per-type minimum HCI header size before handing the frame to the core. After stripping pkt_type, require skb->len to cover the fixed header size for the selected type (event 2, ACL 4, SCO 3, ISO 4) before calling hci_recv_frame(); drop ratelimited otherwise. Unknown pkt_type values still take the original kfree_skb() default path. Use bt_dev_err_ratelimited() because both the length and pkt_type values come from an untrusted backend that can otherwise flood the kernel log. Fixes: 160fbcf3bfb9 ("Bluetooth: virtio_bt: Use skb_put to set length") Cc: stable@vger.kernel.org Cc: Soenke Huster Signed-off-by: Michael Bommarito Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit b40cdd1b1370d76e9e760af4490cb4a351cceead Author: Michael Bommarito Date: Tue Apr 21 13:08:44 2026 -0400 Bluetooth: virtio_bt: clamp rx length before skb_put commit 21bd244b6de5d2fe1063c23acc93fbdd2b20d112 upstream. virtbt_rx_work() calls skb_put(skb, len) where len comes directly from virtqueue_get_buf() with no validation against the buffer we posted to the device. The RX skb is allocated in virtbt_add_inbuf() and exposed to virtio as exactly 1000 bytes via sg_init_one(). Checking len against skb_tailroom(skb) is not sufficient because alloc_skb() can leave more tailroom than the 1000 bytes actually handed to the device. A malicious or buggy backend can therefore report used.len between 1001 and skb_tailroom(skb), causing skb_put() to include uninitialized kernel heap bytes that were never written by the device. The same path also accepts len == 0, in which case skb_put(skb, 0) leaves the skb empty but virtbt_rx_handle() still reads the pkt_type byte from skb->data, consuming uninitialized memory. Define VIRTBT_RX_BUF_SIZE once and reuse it in alloc_skb() and sg_init_one(), and gate virtbt_rx_work() on that same constant so the bound checked matches the buffer actually exposed to the device. Reject used.len == 0 in the same gate so an empty completion can no longer reach virtbt_rx_handle(). Use bt_dev_err_ratelimited() because the length value comes from an untrusted backend that can otherwise flood the kernel log. Same class of bug as commit c04db81cd028 ("net/9p: Fix buffer overflow in USB transport layer"), which hardened the USB 9p transport against unchecked device-reported length. Fixes: 160fbcf3bfb9 ("Bluetooth: virtio_bt: Use skb_put to set length") Cc: stable@vger.kernel.org Cc: Soenke Huster Signed-off-by: Michael Bommarito Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 53ad20efd20a2cf0be4c03c4083ece17b2bae910 Author: Tao Cui Date: Mon May 4 09:00:38 2026 +0800 LoongArch: KVM: Fix missing EMULATE_FAIL in kvm_emu_mmio_read() commit f26faae96c411a70641e4d21b759475caa6122d5 upstream. In the ldptr (0x24...0x27) opcode decoding path, the default case only breaks out but without setting "ret" value to EMULATE_FAIL. This leaves run->mmio.len uninitialized (stale from a previous MMIO operation) while "ret" value remains EMULATE_DO_MMIO, causing the code to proceed with an incorrect MMIO length. Add "ret = EMULATE_FAIL" to match the other default branches in the same function (e.g. the 0x28...0x2e and 0x38 cases). Cc: stable@vger.kernel.org Reviewed-by: Bibo Mao Signed-off-by: Tao Cui Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 05b63fbddfca7dd434b952a9e94dc170eb36ea37 Author: Stephen Smalley Date: Tue May 5 08:49:50 2026 -0400 selinux: prune /sys/fs/selinux/user commit ad1ac3d740cc6b858a99ab9c45c8c0574be7d1d3 upstream. Remove the previously deprecated /sys/fs/selinux/user interface aside from a residual stub for userspace compatibility. Commit d7b6918e22c7 ("selinux: Deprecate /sys/fs/selinux/user") started the deprecation process for /sys/fs/selinux/user: The selinuxfs "user" node allows userspace to request a list of security contexts that can be reached for a given SELinux user from a given starting context. This was used by libselinux when various login-style programs requested contexts for users, but libselinux stopped using it in 2020. Kernel support will be removed no sooner than Dec 2025. A pr_warn() message has been in place since Linux v6.13, and a 5 second sleep was introduced since Linux v6.17 to help make it more noticeable. We are now past the stated deadline of Dec 2025, so remove the underlying functionality and replace it with a stub that returns a '0\0' buffer to avoid breaking userspace. This also avoids a local DoS from logspam and an uninterruptible sleep delay. Cc: stable@vger.kernel.org Signed-off-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 058a5e705424814c91d585fb84c6059e5edbcba5 Author: Stephen Smalley Date: Tue May 5 08:49:49 2026 -0400 selinux: prune /sys/fs/selinux/disable commit 19cfa0099024bb9cd40f6d950caa7f47ff8e77f6 upstream. Commit f22f9aaf6c3d ("selinux: remove the runtime disable functionality") removed the underlying SELinux runtime disable functionality but left everything else intact and started logging an error message to warn any residual users. Prune it to just log an error message once and to return count (i.e. all bytes written successfully) to avoid breaking userspace. This also fixes a local DoS from logspam. Cc: stable@vger.kernel.org Signed-off-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 52a5d9608da54fc9f1907001b1154ea22408fad0 Author: Stephen Smalley Date: Tue May 5 08:49:48 2026 -0400 selinux: prune /sys/fs/selinux/checkreqprot commit 644132a48f4e28a1d949d162160869286f3e75de upstream. commit a7e4676e8e2cb ("selinux: remove the 'checkreqprot' functionality") removed the ability to modify the checkreqprot setting but left everything except the updating of the checkreqprot value intact. Aside from unnecessary processing, this could produce a local DoS from log spam and incorrectly calls selinux_ima_measure_state() on each write even though no state has changed. Prune it to just log an error message once and return count (i.e. all bytes written successfully) so that userspace never breaks. Cc: stable@vger.kernel.org Signed-off-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit e5c12a115ed5b73e75013f0b00811d5811a3b859 Author: Stephen Smalley Date: Thu Apr 30 14:36:52 2026 -0400 selinux: shrink critical section in sel_write_load() commit 868f31e4061eca8c3cd607d79d954d5e54f204aa upstream. Currently sel_write_load() takes the policy mutex earlier than necessary. Move the taking of the mutex later. This avoids holding it unnecessarily across the vmalloc() and copy_from_user() of the policy data. Cc: stable@vger.kernel.org Signed-off-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 71e68e863a7e18b2b68e5990dbca7d670f0ab5c8 Author: David Windsor Date: Sun Apr 26 19:23:49 2026 -0400 selinux: don't reserve xattr slot when we won't fill it commit 1e5a8eed7821e7a43a31b4c1b3675a91be6bc6f6 upstream. Move lsm_get_xattr_slot() below the SBLABEL_MNT check so we don't leave a NULL-named slot in the array when returning -EOPNOTSUPP; filesystem initxattrs() callbacks stop iterating at the first NULL ->name, silently dropping xattrs installed by later LSMs. Cc: stable@vger.kernel.org Signed-off-by: David Windsor Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit d350fef4bc2467fe1bce15f7a20fe60e01ce41ad Author: Zongyao Chen Date: Fri Apr 24 15:37:53 2026 +0800 selinux: use sk blob accessor in socket permission helpers commit 032e70aff025d7c519af9ab791cd084380619263 upstream. SELinux socket state lives in the composite LSM socket blob. sock_has_perm() and nlmsg_sock_has_extended_perms() currently dereference sk->sk_security directly, which assumes the SELinux socket blob is at offset zero. In stacked configurations that assumption does not hold. If another LSM allocates socket blob storage before SELinux, these helpers may read the wrong blob and feed invalid SID and class values into AVC checks. Use selinux_sock() instead of accessing sk->sk_security directly. Fixes: d1d991efaf34 ("selinux: Add netlink xperm support") Cc: stable@vger.kernel.org # v6.13+ Signed-off-by: Zongyao Chen Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit e3e722ea88e051ae5361dc540c01ba18f87b5ffd Author: Stephen Smalley Date: Fri Apr 10 15:29:50 2026 -0400 selinux: fix avdcache auditing commit f92d542577db878acfd21cc18dab23d03023b217 upstream. The per-task avdcache was incorrectly saving and reusing the audited vector computed by avc_audit_required() rather than recomputing based on the currently requested permissions and distinguishing the denied versus allowed cases. As a result, some permission checks were not being audited, e.g. directory write checks after a previously cached directory search check. Cc: stable@vger.kernel.org Fixes: dde3a5d0f4dce ("selinux: move avdcache to per-task security struct") Signed-off-by: Stephen Smalley [PM: line wrap tweaks] Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 7db99a09b3bc87268287bc7ab5f2e7f382b5ad87 Author: Michael Bommarito Date: Sun Apr 19 18:35:42 2026 -0400 xfrm: ah: account for ESN high bits in async callbacks commit ec54093e6a8f87e800bb6aa15eb7fc1e33faa524 upstream. AH allocates its temporary auth/ICV layout differently when ESN is enabled: the async ahash setup appends a 4-byte seqhi slot before the ICV or auth_data area, but the async completion callbacks still reconstruct the temporary layout as if seqhi were absent. With an async AH implementation selected, that makes AH copy or compare the wrong bytes on both the IPv4 and IPv6 paths. In UML repro on IPv4 AH with ESN and forced async hmac(sha1), ping fails with 100% packet loss, and the callback logs show the pre-fix drift: ah4 output_done: esn=1 err=0 icv_off=20 expected_off=24 ah4 input_done: esn=1 auth_off=20 expected_auth_off=24 icv_off=32 expected_icv_off=36 Reconstruct the callback-side layout the same way the setup path built it by skipping the ESN seqhi slot before locating the saved auth_data or ICV. Per RFC 4302, the ESN high-order 32 bits participate in the AH ICV computation, so the async callbacks must account for the seqhi slot. Post-fix, the same IPv4 AH+ESN+forced-async-hmac(sha1) UML repro shows the corrected offset (ah4 output_done: esn=1 err=0 icv_off=24 expected_off=24) and ping succeeds; net/ipv4/ah4.o and net/ipv6/ah6.o build clean at W=1. IPv6 AH+ESN was not exercised at runtime, and the change has not been tested against a real async hardware AH engine. Fixes: d4d573d0334d ("{IPv4,xfrm} Add ESN support for AH egress part") Fixes: d8b2a8600b0e ("{IPv4,xfrm} Add ESN support for AH ingress part") Fixes: 26dd70c3fad3 ("{IPv6,xfrm} Add ESN support for AH egress part") Fixes: 8d6da6f32557 ("{IPv6,xfrm} Add ESN support for AH ingress part") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5-4 Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 9d5047782f9bd2829e529df69209bf3232eb561f Author: Yilin Zhu Date: Sun Apr 12 13:07:54 2026 +0800 ipv6: xfrm6: release dst on error in xfrm6_rcv_encap() commit bc0fcb9823cd0894934cf968b525c575833d7078 upstream. xfrm6_rcv_encap() performs an IPv6 route lookup when the skb does not already have a dst attached. ip6_route_input_lookup() returns a referenced dst entry even when the lookup resolves to an error route. If dst->error is set, xfrm6_rcv_encap() drops the skb without attaching the dst to the skb and without releasing the reference returned by the lookup. Repeated packets hitting this path therefore leak dst entries. Release the dst before jumping to the drop path. Fixes: 0146dca70b87 ("xfrm: add support for UDPv6 encapsulation of ESP") Cc: stable@kernel.org Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Tested-by: Ruide Cao Signed-off-by: Yilin Zhu Signed-off-by: Ren Wei Reviewed-by: Simon Horman Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 4980162de555cb838f1a189ce7d2cbf5d2e7b050 Author: Michal Kosiorek Date: Wed Apr 29 10:54:51 2026 +0200 xfrm: defensively unhash xfrm_state lists in __xfrm_state_delete commit 14acf9652e5690de3c7486c6db5fb8dafd0a32a3 upstream. KASAN reproduces a slab-use-after-free in __xfrm_state_delete()'s hlist_del_rcu calls under syzkaller load on linux-6.12.y stable (reproduced on 6.12.47, also reachable via the same code path on torvalds/master and on the ipsec tree). Nine unique signatures cluster in the xfrm_state lifecycle, the load-bearing one being: BUG: KASAN: slab-use-after-free in __hlist_del include/linux/list.h:990 [inline] BUG: KASAN: slab-use-after-free in hlist_del_rcu include/linux/rculist.h:516 [inline] BUG: KASAN: slab-use-after-free in __xfrm_state_delete net/xfrm/xfrm_state.c Write of size 8 at addr ffff8881198bcb70 by task kworker/u8:9/435 Workqueue: netns cleanup_net Call Trace: __hlist_del / hlist_del_rcu __xfrm_state_delete xfrm_state_delete xfrm_state_flush xfrm_state_fini ops_exit_list cleanup_net The other observed signatures hit the same slab object from __xfrm_state_lookup, xfrm_alloc_spi, __xfrm_state_insert and an OOB write variant of __xfrm_state_delete, all on the byseq/byspi hash chains. __xfrm_state_delete() guards its byseq and byspi unhashes with value-based predicates: if (x->km.seq) hlist_del_rcu(&x->byseq); if (x->id.spi) hlist_del_rcu(&x->byspi); while everywhere else in the file (e.g. state_cache, state_cache_input) the safer hlist_unhashed() check is used. xfrm_alloc_spi() sets x->id.spi = newspi inside xfrm_state_lock and then immediately inserts into byspi, but a path that observes x->id.spi != 0 outside of xfrm_state_lock can still skip-or-hit the byspi unhash inconsistently with whether x is actually on the list. The same holds for x->km.seq versus byseq, and the bydst/bysrc unhashes have no predicate at all, so a second __xfrm_state_delete() on the same object writes through LIST_POISON pprev. The defensive change here: - Use hlist_del_init_rcu() instead of hlist_del_rcu() on bydst, bysrc, byseq and byspi so a second deletion is a no-op rather than a write through LIST_POISON pprev. The byseq/byspi nodes are already initialised in xfrm_state_alloc(). - Test hlist_unhashed() rather than the value predicate for byseq/byspi, so the unhash decision tracks list state rather than mutable scalar fields. Empirical verification: applied this patch on top of v6.12.47, rebuilt, and re-ran the same syzkaller harness for 1h16m on a previously-crashy configuration that produced ~100 hits each of slab-use-after-free Read in xfrm_alloc_spi / Read in __xfrm_state_lookup / Write in __xfrm_state_delete. After the patch, 7.1M execs across 32 VMs at ~1550 exec/sec produced zero xfrm_state UAF/OOB hits. /proc/slabinfo confirms the xfrm_state slab is actively allocated and freed during the run (~143 KiB resident), so the fuzzer is still exercising those code paths -- they just no longer crash. Reproduction: - Linux 6.12.47 x86_64 + KASAN_GENERIC + KASAN_INLINE + KCOV - syzkaller @ 746545b8b1e4c3a128db8652b340d3df90ce61db - 32 QEMU/KVM VMs x 2 vCPU on AWS c5.metal bare metal - 9 unique signatures collected in ~9h, all within xfrm_state lifecycle Fixes: fe9f1d8779cb ("xfrm: add state hashtable keyed by seq") Fixes: 7b4dc3600e48 ("[XFRM]: Do not add a state whose SPI is zero to the SPI hash.") Reported-by: Michal Kosiorek Tested-by: Michal Kosiorek Cc: stable@vger.kernel.org Signed-off-by: Michal Kosiorek Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 0fe995ac77a81e6768474f9829d57b143e2f00cb Author: Ruijie Li Date: Wed Apr 29 00:41:43 2026 +0800 xfrm: provide message size for XFRM_MSG_MAPPING commit 28465227c80fe417b4013c432be1f3737cb9f9a3 upstream. The compat 64=>32 translation path handles XFRM_MSG_MAPPING, but xfrm_msg_min[] does not provide the native payload size for this message type. Add the missing XFRM_MSG_MAPPING entry so compat translation can size and translate mapping notifications correctly. Fixes: 5461fc0c8d9f ("xfrm/compat: Add 64=>32-bit messages translator") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Ruijie Li Signed-off-by: Ren Wei Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit c73fdf2e911d5700c8f3b468a1a0a69b95aef5a7 Author: Ard Biesheuvel Date: Fri May 1 09:16:38 2026 +0200 x86/efi: Restore IRQ state in EFI page fault handler commit 2c340aab5485ebe9e33c01437dd4815ef33c8df5 upstream. The kernel's softirq API does not permit re-enabling softirqs while IRQs are disabled. The reason for this is that local_bh_enable() will not only re-enable delivery of softirqs over the back of IRQs, it will also handle any pending softirqs immediately, regardless of whether IRQs are enabled at that point. For this reason, commit d02198550423 ("x86/fpu: Improve crypto performance by making kernel-mode FPU reliably usable in softirqs") disables softirqs only when IRQs are enabled, as it is not permitted otherwise, but also unnecessary, given that asynchronous softirq delivery never happens to begin with while IRQs are disabled. However, this does mean that entering a kernel mode FPU section with IRQs enabled and leaving it with IRQs disabled leads to problems, as identified by Sashiko [0]: the EFI page fault handler is called from page_fault_oops() with IRQs disabled, and thus ends the kernel mode FPU section with IRQs disabled as well, regardless of whether IRQs were enabled when it was started. This may result in schedule() being called with a non-zero preempt_count, causing a BUG(). So take care to re-enable IRQs when handling any EFI page faults if they were taken with IRQs enabled. [0] https://sashiko.dev/#/patchset/20260430074107.27051-1-ivan.hu%40canonical.com Cc: Eric Biggers Cc: Ivan Hu Cc: x86@kernel.org Cc: Fixes: d02198550423 ("x86/fpu: Improve crypto performance by making kernel-mode FPU reliably usable in softirqs") Reviewed-by: Eric Biggers Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit ef49059fce11673b513475d369075003655af7c1 Author: Sourabh Jain Date: Tue Apr 7 18:13:44 2026 +0530 powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o commit b3a97f9484080c6e71db9e803e3cc1bb372a9bc7 upstream. KASAN instrumentation is intended to be disabled for the kexec core code, but the existing Makefile entry misses the object suffix. As a result, the flag is not applied correctly to core_$(BITS).o. So when KASAN is enabled, kexec_copy_flush and copy_segments in kexec/core_64.c are instrumented, which can result in accesses to shadow memory via normal address translation paths. Since these run with the MMU disabled, such accesses may trigger page faults (bad_page_fault) that cannot be handled in the kdump path, ultimately causing a hang and preventing the kdump kernel from booting. The same is true for kexec as well, since the same functions are used there. Update the entry to include the “.o” suffix so that KASAN instrumentation is properly disabled for this object file. Fixes: 2ab2d5794f14 ("powerpc/kasan: Disable address sanitization in kexec paths") Reported-by: Venkat Rao Bagalkote Closes: https://lore.kernel.org/all/1dee8891-8bcc-46b4-93f3-fc3a774abd5b@linux.ibm.com/ Cc: stable@vger.kernel.org Reviewed-by: Ritesh Harjani (IBM) Tested-by: Venkat Rao Bagalkote Acked-by: Mahesh Salgaonkar Reviewed-by: Aboorva Devarajan Tested-by: Aboorva Devarajan Signed-off-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260407124349.1698552-1-sourabhjain@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 9ef79d48f137facdaf0e0512b77362e724215d08 Author: Cássio Gabriel Date: Wed May 6 00:15:48 2026 -0300 ALSA: seq: Fix UMP group 16 filtering commit 92429ca999db99febced82f23362a71b2ba4c1d8 upstream. The sequencer UAPI defines group_filter as an unsigned int bitmap. Bit 0 filters groupless messages and bits 1-16 filter UMP groups 1-16. The internal snd_seq_client storage is only unsigned short, so bit 16 is truncated when userspace sets the filter. The same truncation affects the automatic UMP client filter used to avoid delivery to inactive groups, so events for group 16 cannot be filtered. Store the internal bitmap as unsigned int and keep both userspace-provided and automatically generated values limited to the defined UAPI bits. Fixes: d2b706077792 ("ALSA: seq: Add UMP group filter") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260506-alsa-seq-ump-group16-filter-v1-1-b75160bf6993@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 878c19dd4fbeaece17df54394f359ff3816b52d6 Author: Cássio Gabriel Date: Wed May 6 00:34:47 2026 -0300 ALSA: core: Serialize deferred fasync state checks commit 5337213381df578058e2e41da93cbd0e4639935f upstream. snd_fasync_helper() updates fasync->on under snd_fasync_lock, and snd_fasync_work_fn() now also evaluates fasync->on under the same lock. snd_kill_fasync() still tests the flag before taking the lock, leaving an unsynchronized read against FASYNC enable/disable updates. Move the enabled-state check into the locked section. Also clear fasync->on under snd_fasync_lock in snd_fasync_free() before unlinking the pending entry. Together with the locked sender-side check, this publishes teardown before flushing the deferred work and prevents a racing sender from requeueing the entry after free has started. Fixes: ef34a0ae7a26 ("ALSA: core: Add async signal helpers") Fixes: 8146cd333d23 ("ALSA: core: Fix potential data race at fasync handling") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260506-alsa-core-fasync-on-lock-v1-1-ea48c77d6ca4@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d761428f6cc7c1a5b27a0551b07df6bf28f47546 Author: Cássio Gabriel Date: Sun May 3 21:55:52 2026 -0300 ALSA: firewire-tascam: Do not drop unread control events commit 0749daa8eb5ab90334aaad3b0671efd7150d43b1 upstream. tscm_hwdep_read_queue() copies as many queued control events as fit in the userspace buffer. When the buffer is smaller than the current contiguous queue segment, length is rounded down to the number of bytes that can be copied. However, after copying that shortened length, the code advances pull_pos to the original tail_pos, marking the whole contiguous segment as consumed. Any events between the copied portion and tail_pos are lost. Limit tail_pos to the position after the entries actually copied before updating pull_pos. When the whole segment fits, this is equivalent to the old tail_pos update; when the buffer is smaller, the remaining events stay queued for the next read. Fixes: a8c0d13267a4 ("ALSA: firewire-tascam: notify events of change of state for userspace applications") Cc: stable@vger.kernel.org Suggested-by: Takashi Sakamoto Signed-off-by: Cássio Gabriel Reviewed-by: Takashi Sakamoto Co-developed-by: Takashi Sakamoto Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260503-alsa-firewire-tascam-read-queue-v2-1-126c6efd7642@gmail.com Signed-off-by: Greg Kroah-Hartman commit d829caccb426c70165f4259fd4540342ff00f744 Author: Yuriy Padlyak Date: Thu Apr 30 01:09:03 2026 +0300 ALSA: hda/realtek: Fix speaker silence after S3 resume on Xiaomi Mi Laptop Pro 15 commit 92a8b5e2eff6920bf815cd6a80b088ec3fdf01a3 upstream. The Xiaomi Mi Laptop Pro 15 (TM1905, subsystem 1d72:1905) ships with the Realtek ALC256 codec on Intel Comet Lake PCH-LP. After S3 resume the codec sets coefficient register 0x10 to 0x0220 instead of 0x0020 — bit 9 is erroneously set, which silences the internal speaker. Bluetooth and HDMI audio are unaffected because they use different paths. This is the same mechanism fixed for Clevo NJ51CU by commit edca7cc4b0ac ("ALSA: hda/realtek: Fix quirk for Clevo NJ51CU"), but the existing ALC256_FIXUP_MIC_NO_PRESENCE_AND_RESUME also reconfigures pin 0x19 as a front mic, which is wrong for this Xiaomi where pin 0x19 default is 0x411111f0 (disabled). Add a minimal fixup that only clears the stuck coef bit, and add the Xiaomi SSID to the quirk table. Verified by reading coef 0x10 with hda-verb after resume (returns 0x0220), writing 0x0020, and confirming the internal speaker resumes output. With this fixup applied the bit is cleared on every codec init, including post-resume. Signed-off-by: Yuriy Padlyak Cc: Tested-by: Yuriy Padlyak Link: https://patch.msgid.link/20260429220903.14918-1-yuriypadlyak@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ac3e9b55b7da6f0be51720bd330a0edc1a8b61f1 Author: Takashi Iwai Date: Fri Apr 24 13:21:55 2026 +0200 ALSA: pcm: oss: Fix data race at accessing runtime.oss.trigger commit 901ac0ff15edf9503162e2cf6579bd11a30f1ed4 upstream. Currently the runtime.oss.trigger field may be accessed concurrently without protection, which may lead to the data race. And, in this case, it may lead to more severe problem because it's a bit field; as writing the data, it may overwrite other bit fields as well, which confuses the operation completely, as spotted by fuzzing. Fix it by covering runtime.oss.trigger bit fled also with the existing params_lock mutex in both snd_pcm_oss_get_trigger() and snd_pcm_oss_poll(). Reported-and-tested-by: Jaeyoung Chung Closes: https://lore.kernel.org/20260423145330.210035-1-jjy600901@snu.ac.kr Cc: Link: https://patch.msgid.link/20260424112205.123703-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f8ad9ef7715658e7eebed5f96ea008dbb21e766c Author: Cássio Gabriel Date: Thu Apr 23 10:11:31 2026 -0300 ALSA: hda: cs35l56: Propagate ASP TX source control errors commit 0faacc0841d66f3cf51989c10a83f3a82d52ff2c upstream. cs35l56_hda_mixer_get() ignores regmap_read() and cs35l56_hda_mixer_put() ignores regmap_update_bits_check(). This makes the ASP TX source controls report success when a regmap access fails. The write path returns no change instead of an error, and the read path continues after a failed read instead of aborting the control callback. Propagate the regmap errors, matching the posture and volume controls in this driver. Fixes: 73cfbfa9caea ("ALSA: hda/cs35l56: Add driver for Cirrus Logic CS35L56 amplifier") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Reviewed-by: Richard Fitzgerald Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260423-alsa-cs35l56-asp-tx-source-errors-v1-1-17ea7c62ec31@gmail.com Signed-off-by: Greg Kroah-Hartman commit 0c1c186f8f488bde2d744d8e98b2e02a140acfaf Author: Xu Yang Date: Fri Apr 24 15:40:09 2026 +0800 usb: typec: tcpm: fix debug accessory mode detection for sink ports commit f6ec9bb4acc7182b25a793ad094a764e1cb819a7 upstream. The port in debug accessory mode can be either a source or sink. The previous tcpm_port_is_debug() function only checked for source port. Commit 8db73e6a42b6 ("usb: typec: tcpm: allow sink (ufp) to toggle into accessory mode debug") changed the detection logic to support both roles, but left some logic in _tcpm_cc_change() unchanged, This causes the state machine to transition to an incorrect state when operating as a sink in debug accessory mode. Log as below: [ 978.637541] CC1: 0 -> 5, CC2: 0 -> 5 [state TOGGLING, polarity 0, connected] [ 978.637567] state change TOGGLING -> SRC_ATTACH_WAIT [rev1 NONE_AMS] [ 978.637596] pending state change SRC_ATTACH_WAIT -> DEBUG_ACC_ATTACHED @ 180 ms [rev1 NONE_AMS] [ 978.647098] CC1: 5 -> 0, CC2: 5 -> 5 [state SRC_ATTACH_WAIT, polarity 0, connected] [ 978.647115] state change SRC_ATTACH_WAIT -> SRC_ATTACH_WAIT [rev1 NONE_AMS] It should go to SNK_ATTACH_WAIT instead of SRC_ATTACH_WAIT state. To fix this, add tcpm_port_is_debug_source() and tcpm_port_is_debug_sink() helper to explicitly identify the power mode in debug accessory mode. Update the state transition logic in _tcpm_cc_change() to ensure the state machine transitions comply with Type-C specification. Also update the logic in run_state_machine() to keep consistency. Fixes: 8db73e6a42b6 ("usb: typec: tcpm: allow sink (ufp) to toggle into accessory mode debug") Cc: stable Signed-off-by: Xu Yang Acked-by: Heikki Krogerus Reviewed-by: Amit Sunil Dhamne Link: https://patch.msgid.link/20260424074009.2979266-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 2a71e01b2cf9b4329ff67102c1bea7448c2a2d2d Author: Felix Gu Date: Tue Apr 7 21:21:22 2026 +0800 usb: ulpi: fix memory leak on ulpi_register() error paths commit 0b9fcab1b8608d429e5f239afb197de928d4de7d upstream. Commit 01af542392b5 ("usb: ulpi: fix double free in ulpi_register_interface() error path") removed kfree(ulpi) from ulpi_register_interface() to fix a double-free when device_register() fails. But when ulpi_of_register() or ulpi_read_id() fail before device_register() is called, the ulpi allocation is leaked. Add kfree(ulpi) on both error paths to properly clean up the allocation. Fixes: 01af542392b5 ("usb: ulpi: fix double free in ulpi_register_interface() error path") Cc: stable Signed-off-by: Felix Gu Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260407-ulpi-v1-1-f3fafe53f7b2@gmail.com Signed-off-by: Greg Kroah-Hartman commit 6ef872d157f49ae27d01e20b809223c3353de92c Author: Fabio Porcedda Date: Mon Apr 27 11:17:46 2026 +0200 USB: serial: option: add Telit Cinterion LE910Cx compositions commit 100201d349edd226ca3470c894c92dccc67ee7a8 upstream. Add the following Telit Cinterion LE910Cx compositions: 0x1251: RNDIS + tty (AT/NMEA) + tty (AT) + tty (AT) + tty (SAP) T: Bus=01 Lev=01 Prnt=21 Port=06 Cnt=01 Dev#=108 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1bc7 ProdID=1251 Rev=03.18 S: Manufacturer=Android S: Product=LE910C1-EU S: SerialNumber=0123456789ABCDEF C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=02 Prot=ff Driver=rndis_host E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8a(I) Atr=03(Int.) MxPS= 10 Ivl=32ms 0x1253: ECM + tty (AT/NMEA) + tty (AT) + tty (AT) + tty (SAP) T: Bus=01 Lev=01 Prnt=21 Port=06 Cnt=01 Dev#=121 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1bc7 ProdID=1253 Rev=03.18 S: Manufacturer=Android S: Product=LE910C1-EU S: SerialNumber=0123456789ABCDEF C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl=32ms I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8a(I) Atr=03(Int.) MxPS= 10 Ivl=32ms 0x1254: tty (AT) + tty (AT) T: Bus=01 Lev=01 Prnt=21 Port=06 Cnt=01 Dev#=122 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1bc7 ProdID=1254 Rev=03.18 S: Manufacturer=Android S: Product=LE910C1-EU S: SerialNumber=0123456789ABCDEF C: #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms 0x1255: tty (AT/NMEA) + tty (AT) + tty (AT) + tty (SAP) T: Bus=01 Lev=01 Prnt=21 Port=06 Cnt=01 Dev#=123 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1bc7 ProdID=1255 Rev=03.18 S: Manufacturer=Android S: Product=LE910C1-EU S: SerialNumber=0123456789ABCDEF C: #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=03(Int.) MxPS= 10 Ivl=32ms Cc: stable@vger.kernel.org Signed-off-by: Fabio Porcedda Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 52a0cf7cde26ae35ac0b7c8a89bb8143115c46f3 Author: Aaro Koskinen Date: Mon Apr 13 21:49:12 2026 +0300 USB: omap_udc: DMA: Don't enable burst 4 mode commit 3f91484f6c13c434bd573ca6b6779c26adb0ddab upstream. Commit 65111084c63d7 ("USB: more omap_udc updates (dma and omap1710)") added setting for DMA burst 4 mode. But I think this should be undone for two reasons: - It breaks DMA on 15xx boards - transfers just silently stall. - On newer OMAP1 boards, like Nokia 770 (omap1710), there is no measurable performance impact when testing TCP throughput with g_ether with large 15000 byte MTU size. It's also worth noting that when the original change was made, the OMAP_DMA_DATA_BURST_4 handling in arch/arm/plat-omap/dma.c was broken, and actually resulted in the same as the OMAP_DMA_DATA_BURST_DIS i.e. burst disabled. This was fixed not until a couple kernel releases later in an unrelated commit 1a8bfa1eb998a ("[ARM] 3142/1: OMAP 2/5: Update files common to omap1 and omap2"). So based on this it seems there was never really a very good reason to enable this burst mode in omap_udc, so remove it now to allow 15xx DMA to work again (it provides 2x throughput compared to PIO mode). Fixes: 65111084c63d ("[PATCH] USB: more omap_udc updates (dma and omap1710)") Cc: stable Signed-off-by: Aaro Koskinen Link: https://patch.msgid.link/ad06qHLclWHeSGnV@darkstar.musicnaut.iki.fi Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 411f2f7274e3e8b58ac16b235102625a32f3a704 Author: Cássio Gabriel Date: Fri Apr 24 18:50:10 2026 -0300 ALSA: usb-audio: Fix UAC3 cluster descriptor size check commit 26265dd69da32d88a88d21987853cec899d9e21f upstream. The UAC3 cluster descriptor length check in snd_usb_get_audioformat_uac3()was added to make sure that the buffer is large enough for a struct uac3_cluster_header_descriptor before the returned data is cast and used. However, the check uses sizeof(cluster), where cluster is a pointer, not the size of the descriptor header. This makes the validation depend on the architecture pointer size and does not match the intended object size. Check against sizeof(*cluster) instead. Fixes: fb4e2a6e8f28 ("ALSA: usb-audio: Fix out-of-bounds read in snd_usb_get_audioformat_uac3()") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260424-alsa-usb-uac3-cluster-size-v1-1-99a5808898a3@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit be09b47ed8677d76962e3240c145502e2ad9f3c8 Author: Takashi Iwai Date: Mon Apr 27 17:22:15 2026 +0200 ALSA: usb-audio: Avoid potential endless loop in convert_chmap_v3() commit 6e7247d8f5fefeceb0bb9cc80a5388a636b219cd upstream. The convert_chmap_v3() has a loop with its increment size of cs_desc->wLength, but we forgot to validate cs_desc->wLength itself, which may lead to potential endless loop by a malformed descriptor. Add a proper size check to abort the loop for plugging the hole. Fixes: ecfd41166b72 ("ALSA: usb-audio: Validate UAC3 cluster segment descriptors") Cc: Link: https://patch.msgid.link/20260427152224.15276-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 00e095dc5787832f584980ec4ed35f1e06124c7f Author: Cássio Gabriel Date: Mon May 4 11:08:45 2026 -0300 ALSA: usb-audio: midi2: Restart output URBs on resume commit f3c57c9c2a49a21d784b7c04a2c883bffc070659 upstream. USB MIDI 2.0 suspend saves the endpoint running state, clears it and kills all endpoint URBs. Resume restores the running state, but only restarts input endpoints. For a running output endpoint, this leaves the endpoint marked running with an empty URB queue. Output transfer progress depends on either the rawmidi trigger path starting the queue or an output completion refilling it. After suspend there is no completion left, and output data that remains queued in the raw UMP or legacy rawmidi buffer can stay stalled until userspace happens to trigger the stream again. Restore the saved state with atomic accessors, keep input endpoints restarted as before, and restart output endpoints that were running before suspend. Clear the saved suspend state after restoring it. Fixes: ff49d1df79ae ("ALSA: usb-audio: USB MIDI 2.0 UMP support") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260504-usb-midi2-output-resume-v1-1-c089cc8ad3c6@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 762a6ccf391db0d629e590a803a3a2231e17dd3f Author: Greg Kroah-Hartman Date: Mon Apr 20 18:11:04 2026 +0200 usb: usblp: fix uninitialized heap leak via LPGETSTATUS ioctl commit b38e53cbfb9d84732e5984fbd73e128d592415c5 upstream. Just like in a previous problem in this driver, usblp_ctrl_msg() will collapse the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred. Ideally that short command should be detected and error out, but many printers are known to send "incorrect" responses back so we can't just do that. statusbuf is kmalloc(8) at probe time and never filled before the first LPGETSTATUS ioctl. usblp_read_status() requests 1 byte. If a malicious printer responds with zero bytes, *statusbuf is one byte of stale kmalloc heap, sign-extended into the local int status, which the LPGETSTATUS path then copy_to_user()s directly to the ioctl caller. Fix this all by just zapping out the memory buffer when allocated at probe time. If a later call does a short read, the data will be identical to what the device sent it the last time, so there is no "leak" of information happening. Cc: Pete Zaitcev Assisted-by: gkh_clanker_t1000 Cc: stable Link: https://patch.msgid.link/2026042011-shredder-savage-48c6@gregkh Signed-off-by: Greg Kroah-Hartman commit 8247f52d822180e94ccbfdab91613af386a4e34d Author: Greg Kroah-Hartman Date: Mon Apr 20 18:11:03 2026 +0200 usb: usblp: fix heap leak in IEEE 1284 device ID via short response commit 7a400c6fe3617e31e690e3f7ca37bb335e0498f3 upstream. usblp_ctrl_msg() collapses the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred. A broken printer can complete the GET_DEVICE_ID control transfer short and the driver has no way to know. usblp_cache_device_id_string() reads the 2-byte big-endian length prefix from the response and trusts it (clamped only to the buffer bounds). The buffer is kmalloc(1024) at probe time. A device that sends exactly two bytes (e.g. 0x03 0xFF, claiming a 1023-byte ID) leaves device_id_string[2..1022] holding stale kmalloc heap. That stale data is then exposed: - via the ieee1284_id sysfs attribute (sprintf("%s", buf+2), truncated at the first NUL in the stale heap), and - via the IOCNR_GET_DEVICE_ID ioctl, which copy_to_user()s the full claimed length regardless of NULs, up to 1021 bytes of uninitialized heap, with the leak size chosen by the device. Fix this up by just zapping the buffer with zeros before each request sent to the device. Cc: Pete Zaitcev Assisted-by: gkh_clanker_t1000 Cc: stable Link: https://patch.msgid.link/2026042002-unicorn-greedily-3c63@gregkh Signed-off-by: Greg Kroah-Hartman commit 658d2e46c2e9a8eb9b80c5e803ce3c89885b3366 Author: Marek Szyprowski Date: Thu Apr 16 11:33:39 2026 +0200 wifi: brcmfmac: Fix potential use-after-free issue when stopping watchdog task commit c623b63580880cc742255eaed3d79804c1b91143 upstream. Watchdog task might end between send_sig() and kthread_stop() calls, what results in the use-after-free issue. Fix this by increasing watchdog task reference count before calling send_sig() and dropping it by switching to kthread_stop_put(). Cc: stable@vger.kernel.org Fixes: 373c83a801f1 ("brcmfmac: stop watchdog before detach and free everything") Fixes: a9ffda88be74 ("brcm80211: fmac: abstract bus_stop interface function pointer") Signed-off-by: Marek Szyprowski Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260416093339.2066829-1-m.szyprowski@samsung.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit d7029879bafdac2006c67553807d122283dc6cbf Author: Tristan Madani Date: Fri Apr 17 11:11:44 2026 +0000 wifi: b43: enforce bounds check on firmware key index in b43_rx() commit 1f4f78bf8549e6ac4f04fba4176854f3a6e0c332 upstream. The firmware-controlled key index in b43_rx() can exceed the dev->key[] array size (58 entries). The existing B43_WARN_ON is non-enforcing in production builds, allowing an out-of-bounds read. Make the B43_WARN_ON check enforcing by dropping the frame when the firmware returns an invalid key index. Suggested-by: Jonas Gorski Acked-by: Michael Büsch Fixes: e4d6b7951812 ("[B43]: add mac80211-based driver for modern BCM43xx devices") Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Link: https://patch.msgid.link/20260417111145.2694196-1-tristmd@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 9e28654f79f443bca9b29ff3ae7cf18abfba58a0 Author: Johannes Berg Date: Tue May 5 15:15:34 2026 +0200 wifi: mac80211: remove station if connection prep fails commit 283fc9e44ff5b5ac967439b4951b80bd4299f4e4 upstream. If connection preparation fails for MLO connections, then the interface is completely reset to non-MLD. In this case, we must not keep the station since it's related to the link of the vif being removed. Delete an existing station. Any "new_sta" is already being removed, so that doesn't need changes. This fixes a use-after-free/double-free in debugfs if that's enabled, because a vif going from MLD (and to MLD, but that's not relevant here) recreates its entire debugfs. Cc: stable@vger.kernel.org Fixes: 81151ce462e5 ("wifi: mac80211: support MLO authentication/association with one link") Reviewed-by: Miriam Rachel Korenblit Link: https://patch.msgid.link/20260505151533.c4e52deb06ad.Iafe56cec7de8512626169496b134bce3a6c17010@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit e9f1081bc775146156def0dbc821b92f35d56afb Author: Jiri Slaby (SUSE) Date: Tue Dec 9 11:04:59 2025 +0100 wifi: ath5k: do not access array OOB commit d748603f12baff112caa3ab7d39f50100f010dbd upstream. Vincent reports: > The ath5k driver seems to do an array-index-out-of-bounds access as > shown by the UBSAN kernel message: > UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath5k/base.c:1741:20 > index 4 is out of range for type 'ieee80211_tx_rate [4]' > ... > Call Trace: > > dump_stack_lvl+0x5d/0x80 > ubsan_epilogue+0x5/0x2b > __ubsan_handle_out_of_bounds.cold+0x46/0x4b > ath5k_tasklet_tx+0x4e0/0x560 [ath5k] > tasklet_action_common+0xb5/0x1c0 It is real. 'ts->ts_final_idx' can be 3 on 5212, so: info->status.rates[ts->ts_final_idx + 1].idx = -1; with the array defined as: struct ieee80211_tx_rate rates[IEEE80211_TX_MAX_RATES]; while the size is: #define IEEE80211_TX_MAX_RATES 4 is indeed bogus. Set this 'idx = -1' sentinel only if the array index is less than the array size. As mac80211 will not look at rates beyond the size (IEEE80211_TX_MAX_RATES). Note: The effect of the OOB write is negligible. It just overwrites the next member of info->status, i.e. ack_signal. Signed-off-by: Jiri Slaby (SUSE) Reported-by: Vincent Danjean Link: https://lore.kernel.org/all/aQYUkIaT87ccDCin@eldamar.lan Closes: https://bugs.debian.org/1119093 Fixes: 6d7b97b23e11 ("ath5k: fix tx status reporting issues") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251209100459.2253198-1-jirislaby@kernel.org Signed-off-by: Jeff Johnson Signed-off-by: Greg Kroah-Hartman commit 7577a4b8a10fab45a6ee2045ea038a5adadbb585 Author: Benjamin Berg Date: Tue May 5 15:15:40 2026 +0200 wifi: mac80211: use safe list iteration in radar detect work commit ac8eb3e18f41e2cc8492cc1d358bcb786c850270 upstream. The call to ieee80211_dfs_cac_cancel can cause the iterated chanctx to be freed and removed from the list. Guard against this to avoid a slab-use-after-free error. Cc: stable@vger.kernel.org Fixes: bca8bc0399ac ("wifi: mac80211: handle ieee80211_radar_detected() for MLO") Signed-off-by: Benjamin Berg Link: https://patch.msgid.link/20260505151539.236d63a1b736.I35dbb9e96a2d4a480be208770fdd99ba3b817b79@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 4f9a4ae8d2c198f01611ea376034c326ef43ab56 Author: Jeongjun Park Date: Thu Apr 23 02:38:46 2026 +0900 wifi: rsi: fix kthread lifetime race between self-exit and external-stop commit db57a1aa54ff68669781976e4edb045e09e2b65b upstream. RSI driver use both self-exit(kthread_complete_and_exit) and external-stop (kthread_stop) when killing a kthread. Generally, kthread_stop() is called first, and in this case, no particular issues occur. However, in rare instances where kthread_complete_and_exit() is called first and then kthread_stop() is called, a UAF occurs because the kthread object, which has already exited and been freed, is accessed again. Therefore, to prevent this with minimal modification, you must remove kthread_stop() and change the code to wait until the self-exit operation is completed. Cc: Reported-by: syzbot+5de83f57cd8531f55596@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/69e5d03b.a00a0220.1bd0ca.0064.GAE@google.com/ Fixes: 4c62764d0fc2 ("rsi: improve kernel thread handling to fix kernel panic") Signed-off-by: Jeongjun Park Link: https://patch.msgid.link/20260422173846.37640-1-aha310510@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit e131562d6f2b958148c35c98831b007f47f0e3d3 Author: Catherine Date: Fri Apr 24 21:14:36 2026 +0800 wifi: mac80211: drop stray 'static' from fast-RX rx_result commit 7a5b81e0c87a075afd572f659d8eb68c9c4cd2ba upstream. ieee80211_invoke_fast_rx() is documented as safe for parallel RX, but its per-invocation rx_result is declared static. Concurrent callers then share one instance and can overwrite each other's result between ieee80211_rx_mesh_data() and the switch on res. That can make a packet that was queued or consumed by ieee80211_rx_mesh_data() fall through into ieee80211_rx_8023(), or make a packet that should continue return as queued. Make res an automatic variable so each invocation keeps its own result. Fixes: 3468e1e0c639 ("wifi: mac80211: add mesh fast-rx support") Cc: stable@vger.kernel.org Signed-off-by: Catherine Link: https://patch.msgid.link/20260424131435.83212-2-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 9d1bc155802943e92c57a5fb923d23edfbf0b525 Author: Tristan Madani Date: Fri Apr 17 11:11:45 2026 +0000 wifi: b43legacy: enforce bounds check on firmware key index in RX path commit a035766f970bde2d4298346a31a80685be5c0205 upstream. Same fix as b43: the firmware-controlled key index in b43legacy_rx() can exceed dev->max_nr_keys. The existing B43legacy_WARN_ON is non-enforcing in production builds, allowing an out-of-bounds read of dev->key[]. Make the check enforcing by dropping the frame for invalid indices. Fixes: 75388acd0cd8 ("[B43LEGACY]: add mac80211-based driver for legacy BCM43xx devices") Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Link: https://patch.msgid.link/20260417111145.2694196-2-tristmd@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 6d55948a62aba02730330367424de0ed4b242d61 Author: Quan Zhou Date: Fri Jan 23 10:16:25 2026 +0800 wifi: mt76: mt7921: fix ROC abort flow interruption in mt7921_roc_work commit fdfa39f9f4fbae532b162da913a67b2410caf38f upstream. The mt7921_set_roc API may be executed concurrently with mt7921_roc_work, specifically between the following code paths: - The check and clear of MT76_STATE_ROC in mt7921_roc_work: if (!test_and_clear_bit(MT76_STATE_ROC, &phy->mt76->state)) return; - The execution of ieee80211_iterate_active_interfaces. This race condition can interrupt the ROC abort flow, resulting in the ROC process failing to abort as expected. To address this defect, the modification of MT76_STATE_ROC is now protected by mt792x_mutex_acquire(phy->dev). This ensures that changes to the ROC state are properly synchronized, preventing race conditions and ensuring the ROC abort flow is not interrupted. Fixes: 034ae28b56f1 ("wifi: mt76: mt7921: introduce remain_on_channel support") Cc: stable@vger.kernel.org Signed-off-by: Quan Zhou Reviewed-by: Sean Wang Link: https://patch.msgid.link/2568ece8b557e5dda79391414c834ef3233049b6.1769133724.git.quan.zhou@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 0aa63d33742b805d1a218d18d12b983cce4b2f7b Author: Leon Yen Date: Thu Oct 9 10:01:58 2025 +0800 wifi: mt76: mt7921: fix a potential clc buffer length underflow commit 5373f8b19e568b5c217832b9bbef165bd2b2df14 upstream. The buf_len is used to limit the iterations for retrieving the country power setting and may underflow under certain conditions due to changes in the power table in CLC. This underflow leads to an almost infinite loop or an invalid power setting resulting in driver initialization failure. Cc: stable@vger.kernel.org Fixes: fa6ad88e023d ("wifi: mt76: mt7921: fix country count limitation for CLC") Signed-off-by: Leon Yen Signed-off-by: Ming Yen Hsieh Link: https://patch.msgid.link/20251009020158.1923429-1-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 6fc7c8b414ce1f1fe9dde805c6ca3f978d05fab6 Author: Ming Yen Hsieh Date: Mon Sep 8 15:25:26 2025 +0800 wifi: mt76: mt7925: fix incorrect length field in txpower command commit ccb186326bb6b7f20d77982f855568e7087ad0d7 upstream. Set `tx_power_tlv->len` to `msg_len` instead of `sizeof(*tx_power_tlv)` to ensure the correct message length is sent to firmware. Cc: stable@vger.kernel.org Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: Ming Yen Hsieh Link: https://patch.msgid.link/20250908072526.1833938-1-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 5860ab3ddeaab0c84313f5d5f106235c83ea012d Author: Quan Zhou Date: Thu Nov 27 15:49:11 2025 +0800 wifi: mt76: mt7925: fix AMPDU state handling in mt7925_tx_check_aggr commit bb8e38fcdbf7290d7f0cd572d2d8fdb2b641b492 upstream. Previously, the AMPDU state bit for a given TID was set before attempting to start a BA session, which could result in the AMPDU state being marked active even if ieee80211_start_tx_ba_session() failed. This patch changes the logic to only set the AMPDU state bit after successfully starting a BA session, ensuring proper synchronization between AMPDU state and BA session status. This fixes potential issues with aggregation state tracking and improves compatibility with mac80211 BA session management. Fixes: 44eb173bdd4f ("wifi: mt76: mt7925: add link handling in mt7925_txwi_free") Cc: stable@vger.kernel.org Signed-off-by: Quan Zhou Reviewed-by: Sean Wang Link: https://patch.msgid.link/d5960fbced0beaf33c30203f7f8fb91d0899c87b.1764228973.git.quan.zhou@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 6f49f94f3b11fe8bff1bf2a054143789e76aaf17 Author: Jann Horn Date: Mon May 11 08:55:11 2026 -0700 exit: prevent preemption of oopsing TASK_DEAD task commit c1fa0bb633e4a6b11e83ffc57fa5abe8ebb87891 upstream. When an already-exiting task oopses, make_task_dead() currently calls do_task_dead() with preemption enabled. That is forbidden: do_task_dead() calls __schedule(), which has a comment saying "WARNING: must be called with preemption disabled!". If an oopsing task is preempted in do_task_dead(), between becoming TASK_DEAD and entering the scheduler explicitly, bad things happen: finish_task_switch() assumes that once the scheduler has switched away from a TASK_DEAD task, the task can never run again and its stack is no longer needed; but that assumption apparently doesn't hold if the dead task was preempted (the SM_PREEMPT case). This means that the scheduler ends up repeatedly dropping references on the dead task's stack, which can lead to use-after-free or double-free of the entire task stack; in other words, two tasks can end up running on the same stack, resulting in various kinds of memory corruption. (This does not just affect "recursively oopsing" tasks; it is enough to oops once during task exit, for example in a file_operations::release handler) Fixes: 7f80a2fd7db9 ("exit: Stop poorly open coding do_task_dead in make_task_dead") Cc: stable@kernel.org Signed-off-by: Jann Horn Acked-by: Peter Zijlstra Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 8d09618840b99ef00154d3e731ce9b11e096196d Author: Jamal Hadi Salim Date: Thu Apr 30 11:29:55 2026 -0400 net/sched: sch_red: Replace direct dequeue call with peek and qdisc_dequeue_peeked commit 458d5615272d3de535748342eb68ca492343048c upstream. When red qdisc has children (eg qfq qdisc) whose peek() callback is qdisc_peek_dequeued(), we could get a kernel panic. When the parent of such qdiscs (eg illustrated in patch #3 as tbf) wants to retrieve an skb from its child (red in this case), it will do the following: 1a. do a peek() - and when sensing there's an skb the child can offer, then - the child in this case(red) calls its child's (qfq) peek. qfq does the right thing and will return the gso_skb queue packet. Note: if there wasnt a gso_skb entry then qfq will store it there. 1b. invoke a dequeue() on the child (red). And herein lies the problem. - red will call the child's dequeue() which will essentially just try to grab something of qfq's queue. [ 78.667668][ T363] KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f] [ 78.667927][ T363] CPU: 1 UID: 0 PID: 363 Comm: ping Not tainted 7.1.0-rc1-00033-g46f74a3f7d57-dirty #790 PREEMPT(full) [ 78.668263][ T363] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 78.668486][ T363] RIP: 0010:qfq_dequeue+0x446/0xc90 [sch_qfq] [ 78.668718][ T363] Code: 54 c0 e8 dd 90 00 f1 48 c7 c7 e0 03 54 c0 48 89 de e8 ce 90 00 f1 48 8d 7b 48 b8 ff ff 37 00 48 89 fa 48 c1 e0 2a 48 c1 ea 03 <80> 3c 02 00 74 05 e8 ef a1 e1 f1 48 8b 7b 48 48 8d 54 24 58 48 8d [ 78.669312][ T363] RSP: 0018:ffff88810de573e0 EFLAGS: 00010216 [ 78.669533][ T363] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 78.669790][ T363] RDX: 0000000000000009 RSI: 0000000000000004 RDI: 0000000000000048 [ 78.670044][ T363] RBP: ffff888110dc4000 R08: ffffffffb1b0885a R09: fffffbfff6ba9078 [ 78.670297][ T363] R10: 0000000000000003 R11: ffff888110e31c80 R12: 0000001880000000 [ 78.670560][ T363] R13: ffff888110dc4150 R14: ffff888110dc42b8 R15: 0000000000000200 [ 78.670814][ T363] FS: 00007f66a8f09c40(0000) GS:ffff888163428000(0000) knlGS:0000000000000000 [ 78.671110][ T363] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 78.671324][ T363] CR2: 000055db4c6a30a8 CR3: 000000010da67000 CR4: 0000000000750ef0 [ 78.671585][ T363] PKRU: 55555554 [ 78.671713][ T363] Call Trace: [ 78.671843][ T363] [ 78.671936][ T363] ? __pfx_qfq_dequeue+0x10/0x10 [sch_qfq] [ 78.672148][ T363] ? __pfx__printk+0x10/0x10 [ 78.672322][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.672496][ T363] ? lockdep_hardirqs_on_prepare+0xa8/0x1a0 [ 78.672706][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.672875][ T363] ? trace_hardirqs_on+0x19/0x1a0 [ 78.673047][ T363] red_dequeue+0x65/0x270 [sch_red] [ 78.673217][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.673385][ T363] tbf_dequeue.cold+0xb0/0x70c [sch_tbf] [ 78.673566][ T363] __qdisc_run+0x169/0x1900 The right thing to do in #1b is to grab the skb off gso_skb queue. This patchset fixes that issue by changing #1b to use qdisc_dequeue_peeked() method instead. Fixes: 77be155cba4e ("pkt_sched: Add peek emulation for non-work-conserving qdiscs.") Reported-by: Manas Reported-by: Rakshit Awasthi Signed-off-by: Jamal Hadi Salim Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260430152957.194015-2-jhs@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 33fe95663d105df6398a0cb71c0114e8ae3b5346 Author: Ovidiu Panait Date: Thu Nov 13 11:27:21 2025 +0000 net: stmmac: Disable EEE RX clock stop when VLAN is enabled commit c171e679ee66d7c0e2b58db9531af96797a76bca upstream. On the Renesas RZ/V2H EVK platform, where the stmmac MAC is connected to a Microchip KSZ9131RNXI PHY, creating or deleting VLAN interfaces may fail with timeouts: # ip link add link end1 name end1.5 type vlan id 5 15c40000.ethernet end1: Timeout accessing MAC_VLAN_Tag_Filter RTNETLINK answers: Device or resource busy Disabling EEE at runtime avoids the problem: # ethtool --set-eee end1 eee off # ip link add link end1 name end1.5 type vlan id 5 # ip link del end1.5 The stmmac hardware requires the receive clock to be running when writing certain registers, such as those used for MAC address configuration or VLAN filtering. However, by default the driver enables Energy Efficient Ethernet (EEE) and allows the PHY to stop the receive clock when the link is idle. As a result, the RX clock might be stopped when attempting to access these registers, leading to timeouts and other issues. Commit dd557266cf5fb ("net: stmmac: block PHY RXC clock-stop") addressed this issue for most register accesses by wrapping them in phylink_rx_clk_stop_block()/phylink_rx_clk_stop_unblock() calls. However, VLAN add/delete operations may be invoked with bottom halves disabled, where sleeping is not allowed, so using these helpers is not possible. Therefore, to fix this, disable the RX clock stop feature in the phylink configuration if VLAN features are set. This ensures the RX clock remains active and register accesses succeed during VLAN operations. Signed-off-by: Ovidiu Panait Reviewed-by: Russell King (Oracle) Link: https://patch.msgid.link/20251113112721.70500-3-ovidiu.panait.rb@renesas.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 53e821fd9baec14bf19b462b5e47359b0af52390 Author: Paolo Bonzini Date: Mon Mar 9 12:40:52 2026 +0100 KVM: SVM: check validity of VMCB controls when returning from SMM commit be5fa8737d42c5ba16d2ea72c23681f8abbb07e8 upstream. The VMCB12 is stored in guest memory and can be mangled while in SMM; it is then reloaded by svm_leave_smm(), but it is not checked again for validity. Move the cached vmcb12 control and save consistency checks out of svm_set_nested_state() and into a helper, and reuse it in svm_leave_smm(). Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit edd446ee7cd3d02cac246168063d5b3e9ea68460 Author: Zhengchuan Liang Date: Sun Mar 22 11:46:08 2026 -0700 net: af_key: zero aligned sockaddr tail in PF_KEY exports [ Upstream commit 426c355742f02cf743b347d9d7dbdc1bfbfa31ef ] PF_KEY export paths use `pfkey_sockaddr_size()` when reserving sockaddr payload space, so IPv6 addresses occupy 32 bytes on the wire. However, `pfkey_sockaddr_fill()` initializes only the first 28 bytes of `struct sockaddr_in6`, leaving the final 4 aligned bytes uninitialized. Not every PF_KEY message is affected. The state and policy dump builders already zero the whole message buffer before filling the sockaddr payloads. Keep the fix to the export paths that still append aligned sockaddr payloads with plain `skb_put()`: - `SADB_ACQUIRE` - `SADB_X_NAT_T_NEW_MAPPING` - `SADB_X_MIGRATE` Fix those paths by clearing only the aligned sockaddr tail after `pfkey_sockaddr_fill()`. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Fixes: 08de61beab8a ("[PFKEYV2]: Extension for dynamic update of endpoint address(es)") Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Tested-by: Xiao Liu Signed-off-by: Zhengchuan Liang Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 9dea2aeabc86c2c441d2c89a5b6ebbfc96e56bfb Author: Yi Kuo Date: Fri May 8 10:15:47 2026 +0200 smb: client/smbdirect: fix MR registration for coalesced SG lists commit 9900b9fee5a0e0f72d7c744b37c7c851d5785ac6 upstream. The stable backport to < 7.1 patches a different file. Also the Fixes tag below is adjusted for the old code path. ib_dma_map_sg() modifies the provided scatterlist and returns the number of mapped entries, which can be fewer than the requested mr->sgt.nents if the DMA controller coalesces contiguous memory segments. Passing the original, uncoalesced count to ib_map_mr_sg() causes memory registration failures if coalescing actually occurs. Capture the actual mapped count returned by ib_dma_map_sg() and pass it to ib_map_mr_sg() to ensure correct MR registration. Also update the ib_dma_map_sg() error logging to drop the error pointer formatting, since the return value is an integer count rather than an error code. Ensure a proper error code (-EIO) is assigned when DMA mapping or MR registration fails. Fixes: c7398583340a ("CIFS: SMBD: Implement RDMA memory registration") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221408 Reviewed-by: Stefan Metzmacher Acked-by: Namjae Jeon Signed-off-by: Yi Kuo Signed-off-by: Steve French Cc: stable@vger.kernel.org Signed-off-by: Stefan Metzmacher Signed-off-by: Sasha Levin commit ff9e4d5e9bbaeadea98e6438ed72a636219f7aa8 Author: Gang Yan Date: Wed May 6 13:20:41 2026 +0200 mptcp: sync the msk->sndbuf at accept() time commit fcf04b14334641f4b0b8647824480935e9416d52 upstream. On passive MPTCP connections, the msk sndbuf is not updated correctly. The root cause is an order issue in the accept path: - tcp_check_req() -> subflow_syn_recv_sock() -> mptcp_sk_clone_init() calls __mptcp_propagate_sndbuf() to copy the ssk sndbuf into msk - Later, tcp_child_process() -> tcp_init_transfer() -> tcp_sndbuf_expand() grows the ssk sndbuf. So __mptcp_propagate_sndbuf() runs before the ssk sndbuf has been expanded and the msk ends up with a much smaller sndbuf than the subflow: MPTCP: msk->sndbuf:20480, msk->first->sndbuf:2626560 Fix this by moving the __mptcp_propagate_sndbuf() call from mptcp_sk_clone_init() -- the ssk sndbuf is not yet finalized there -- to __mptcp_propagate_sndbuf() at accept() time, when the ssk sndbuf has been fully expanded by tcp_sndbuf_expand(). Fixes: 8005184fd1ca ("mptcp: refactor sndbuf auto-tuning") Cc: stable@vger.kernel.org Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/602 Signed-off-by: Gang Yan Acked-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260420-net-mptcp-sync-sndbuf-accept-v1-1-e3523e3aeb44@kernel.org Signed-off-by: Paolo Abeni [ No conflicts, but move __mptcp_propagate_sndbuf() above the for-loop (mptcp_for_each_subflow()) present in this version, which will modify 'subflow' used by __mptcp_propagate_sndbuf() in this new patch. ] Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Sasha Levin commit 0d00b9015069712944934bab09eaa6c542143049 Author: Qingfang Deng Date: Wed Apr 15 10:24:50 2026 +0800 flow_dissector: do not dissect PPPoE PFC frames [ Upstream commit d6c19b31a3c1d519fabdcf0aa239e6b6109b9473 ] RFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOT RECOMMENDED for PPPoE. In practice, pppd does not support negotiating PFC for PPPoE sessions, and the flow dissector driver has assumed an uncompressed frame until the blamed commit. During the review process of that commit [1], support for PFC is suggested. However, having a compressed (1-byte) protocol field means the subsequent PPP payload is shifted by one byte, causing 4-byte misalignment for the network header and an unaligned access exception on some architectures. The exception can be reproduced by sending a PPPoE PFC frame to an ethernet interface of a MIPS board, with RPS enabled, even if no PPPoE session is active on that interface: $ 0 : 00000000 80c40000 00000000 85144817 $ 4 : 00000008 00000100 80a75758 81dc9bb8 $ 8 : 00000010 8087ae2c 0000003d 00000000 $12 : 000000e0 00000039 00000000 00000000 $16 : 85043240 80a75758 81dc9bb8 00006488 $20 : 0000002f 00000007 85144810 80a70000 $24 : 81d1bda0 00000000 $28 : 81dc8000 81dc9aa8 00000000 805ead08 Hi : 00009d51 Lo : 2163358a epc : 805e91f0 __skb_flow_dissect+0x1b0/0x1b50 ra : 805ead08 __skb_get_hash_net+0x74/0x12c Status: 11000403 KERNEL EXL IE Cause : 40800010 (ExcCode 04) BadVA : 85144817 PrId : 0001992f (MIPS 1004Kc) Call Trace: [<805e91f0>] __skb_flow_dissect+0x1b0/0x1b50 [<805ead08>] __skb_get_hash_net+0x74/0x12c [<805ef330>] get_rps_cpu+0x1b8/0x3fc [<805fca70>] netif_receive_skb_list_internal+0x324/0x364 [<805fd120>] napi_complete_done+0x68/0x2a4 [<8058de5c>] mtk_napi_rx+0x228/0xfec [<805fd398>] __napi_poll+0x3c/0x1c4 [<805fd754>] napi_threaded_poll_loop+0x234/0x29c [<805fd848>] napi_threaded_poll+0x8c/0xb0 [<80053544>] kthread+0x104/0x12c [<80002bd8>] ret_from_kernel_thread+0x14/0x1c Code: 02d51821 1060045b 00000000 <8c640000> 3084000f 2c820005 144001a2 00042080 8e220000 To reduce the attack surface and maintain performance, do not process PPPoE PFC frames. [1] https://lore.kernel.org/r/20220630231016.GA392@debian.home Fixes: 46126db9c861 ("flow_dissector: Add PPPoE dissectors") Signed-off-by: Qingfang Deng Link: https://patch.msgid.link/20260415022456.141758-1-qingfang.deng@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6200f41d6fcf2ac7e24866431e381cbc914560e4 Author: Sam Edwards Date: Tue May 5 18:43:03 2026 -0700 ceph: fix num_ops off-by-one when crypto allocation fails commit a0d9555bf9eaeba34fe6b6bb86f442fe08ba3842 upstream. move_dirty_folio_in_page_array() may fail if the file is encrypted, the dirty folio is not the first in the batch, and it fails to allocate a bounce buffer to hold the ciphertext. When that happens, ceph_process_folio_batch() simply redirties the folio and flushes the current batch -- it can retry that folio in a future batch. However, if this failed folio is not contiguous with the last folio that did make it into the batch, then ceph_process_folio_batch() has already incremented `ceph_wbc->num_ops`; because it doesn't follow through and add the discontiguous folio to the array, ceph_submit_write() -- which expects that `ceph_wbc->num_ops` accurately reflects the number of contiguous ranges (and therefore the required number of "write extent" ops) in the writeback -- will panic the kernel: BUG_ON(ceph_wbc->op_idx + 1 != req->r_num_ops); This issue can be reproduced on affected kernels by writing to fscrypt-enabled CephFS file(s) with a 4KiB-written/4KiB-skipped/repeat pattern (total filesize should not matter) and gradually increasing the system's memory pressure until a bounce buffer allocation fails. Fix this crash by decrementing `ceph_wbc->num_ops` back to the correct value when move_dirty_folio_in_page_array() fails, but the folio already started counting a new (i.e. still-empty) extent. The defect corrected by this patch has existed since 2022 (see first `Fixes:`), but another bug blocked multi-folio encrypted writeback until recently (see second `Fixes:`). The second commit made it into 6.18.16, 6.19.6, and 7.0-rc1, unmasking the panic in those versions. This patch therefore fixes a regression (panic) introduced by cac190c7674f. Cc: stable@vger.kernel.org Fixes: d55207717ded ("ceph: add encryption support to writepage and writepages") Fixes: cac190c7674f ("ceph: fix write storm on fscrypted files") Signed-off-by: Sam Edwards Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 738ec97b1855df6c08fe2369f798fa0b972e556b Author: Sean Christopherson Date: Tue May 5 08:58:57 2026 +0200 KVM: x86: Fix shadow paging use-after-free due to unexpected GFN commit 0cb2af2ea66ad8ff195c156ea690f11216285bdf upstream. The shadow MMU computes GFNs for direct shadow pages using sp->gfn plus the SPTE index. This assumption breaks for shadow paging if the guest page tables are modified between VM entries (similar to commit aad885e77496, "KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE", 2026-03-27). The flow is as follows: - a PDE is installed for a 2MB mapping, and a page in that area is accessed. KVM creates a kvm_mmu_page consisting of 512 4KB pages; the kvm_mmu_page is marked by FNAME(fetch) as direct-mapped because the guest's mapping is a huge page (and thus contiguous). - the PDE mapping is changed from outside the guest. - the guest accesses another page in the same 2MB area. KVM installs a new leaf SPTE and rmap entry; the SPTE uses the "correct" GFN (i.e. based on the new mapping, as changed in the previous step) but that GFN is outside of the [sp->gfn, sp->gfn + 511] range; therefore the rmap entry cannot be found and removed when the kvm_mmu_page is zapped. - the memslot that covers the first 2MB mapping is deleted, and the kvm_mmu_page for the now-invalid GPA is zapped. However, rmap_remove() only looks at the [sp->gfn, sp->gfn + 511] range established in step 1, and fails to find the rmap entry that was recorded by step 3. - any operation that causes an rmap walk for the same page accessed by step 3 then walks a stale rmap and dereferences a freed kvm_mmu_page. This includes dirty logging or MMU notifier invalidations (e.g., from MADV_DONTNEED). The underlying issue is that KVM's walking of shadow PTEs assumes that if a SPTE is present when KVM wants to install a non-leaf SPTE, then the existing kvm_mmu_page must be for the correct gfn. Because the only way for the gfn to be wrong is if KVM messed up and failed to zap a SPTE... which shouldn't happen, but *actually* only happens in response to a guest write. That bug dates back literally forever, as even the first version of KVM assumes that the GFN matches and walks into the "wrong" shadow page. However, that was only an imprecision until 2032a93d66fa ("KVM: MMU: Don't allocate gfns page for direct mmu pages") came along. Fix it by checking for a target gfn mismatch and zapping the existing SPTE. That way the old SP and rmap entries are gone, KVM installs the rmap in the right location, and everyone is happy. Fixes: 2032a93d66fa ("KVM: MMU: Don't allocate gfns page for direct mmu pages") Fixes: 6aa8b732ca01 ("kvm: userspace interface") Reported-by: Alexander Bulekov Reported-by: Fred Griffoul Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Link: https://patch.msgid.link/20260503201029.106481-1-pbonzini@redhat.com/ Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit ccee9833e33ba810a57f9a6e1f75657bf62df3ea Author: DaeMyung Kang Date: Sat Apr 25 18:38:28 2026 +0900 ksmbd: rewrite stop_sessions() with restartable iteration commit c444139cb747bf6de1922b39900fdf02281490f4 upstream. stop_sessions() walks conn_list with hash_for_each() and, for every entry, drops conn_list_lock across the transport ->shutdown() call before re-acquiring the read lock to continue the loop. The hash walk relies on cross-iteration state (the current bucket and the hlist position), which is not preserved across unlock/relock: if another thread performs a list mutation during the unlocked window, the ongoing iteration becomes unreliable and can re-visit connections that have already been handled or skip connections that have not. The outer `if (!hash_empty(conn_list)) goto again;` retry masks the symptom in the common case but does not address the unsafe iteration itself. Reframe the loop so it never relies on iterator state across unlock/relock. Under conn_list_lock held for read, pick the first connection whose ->shutdown() has not yet been issued by this path, pin it by taking an extra reference, record that fact on the connection and mark it EXITING while still inside the locked walk, then drop the lock. Then call ->shutdown() outside the lock, drop the pin (freeing the connection if the handler already released its reference), and restart from the top. Use a new per-connection flag, conn->stop_called, as the "shutdown issued from stop_sessions()" marker rather than reusing the status state. ksmbd_conn_set_exiting() is also invoked by ksmbd_sessions_deregister() on sibling channels of a multichannel session without issuing a transport shutdown, so treating KSMBD_SESS_EXITING as "already handled here" would skip connections that still need shutdown() to wake their handler out of recv(), leaving the outer retry waiting indefinitely for the hash to drain. stop_sessions() is serialised by init_lock in ksmbd_conn_transport_destroy(), so writing stop_called under the read lock has no other writer. Set EXITING inside the locked walk so the selection, the stop_called marker, and the status transition all happen together, and guard against regressing a connection that has already advanced to KSMBD_SESS_RELEASING on its own (for example, if the handler exited its receive loop for an unrelated reason between teardown steps). When the pin drop is the last put, release the transport and pair ida_destroy(&target->async_ida) with the ida_init() done in ksmbd_conn_alloc(), so stop_sessions() retiring a connection on its own does not leak the xarray backing of the embedded async_ida. The outer retry with msleep() is kept to wait for handler threads to reach ksmbd_conn_free() and drain the hash. Observed with an instrumented build that logs one line per visit and widens the unlocked window before ->shutdown() by 200 ms, under five concurrent cifs mounts (nosharesock, one connection each): * Current code: the same connection address is revisited many times during a single stop_sessions() call and ->shutdown() is invoked well beyond the number of live connections before the hash finally drains. * Rewritten code: each live connection produces exactly one ->shutdown() call; the function returns as soon as the hash is empty. Functional teardown via `ksmbd.control --shutdown` with the same five mounts completes cleanly on the rewritten path. Performance is observably unchanged. Tearing down N concurrent nosharesock cifs connections with `ksmbd.control --shutdown` + `rmmod ksmbd` takes essentially the same wall time before and after the rewrite: N before after 10 4.93s 5.34s 30 7.34s 7.03s 50 7.31s 7.01s (3-run avg: 7.04s vs 7.25s) 100 6.98s 6.78s 200 6.77s 6.89s and the number of ->shutdown() calls equals the number of live connections on both paths when the race is not widened. The teardown is dominated by the msleep(100)-based outer retry waiting for handler threads to run ksmbd_conn_free(), not by the iteration itself; the restartable loop's worst-case O(N^2) visit cost is in the microseconds even at N=200 and sits far below the msleep(100) granularity. Applied alone on top of ksmbd-for-next-next, this patch does not introduce a new leak site. Under the same reproducer (10x concurrent-holders + ss -K + ksmbd.control --shutdown + rmmod), the tree still shows the pre-existing per-connection transport leak count that arises when the last refcount drop lands in one of ksmbd_conn_r_count_dec(), __free_opinfo() or session_fd_check() - all of which end with a bare kfree() today. kmemleak backtraces for the unreferenced objects point into the TCP accept path (sk_clone -> inet_csk_clone_lock, sock_alloc_inode) and none involve stop_sessions(). Plugging those bare-kfree sites is the responsibility of the follow-up patch. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Signed-off-by: DaeMyung Kang Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 21a316f27095df2898e02dd0d9d9c92dd0033470 Author: Johan Hovold Date: Tue Mar 24 09:23:23 2026 +0100 spi: rockchip: fix controller deregistration commit 53e7a16070feb7d1d4d81a583eaac5e25048b9c3 upstream. Make sure to deregister the controller before freeing underlying resources like DMA channels during driver unbind. Fixes: 64e36824b32b ("spi/rockchip: add driver for Rockchip RK3xxx SoCs integrated SPI") Cc: stable@vger.kernel.org # 3.17 Cc: addy ke Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260324082326.901043-3-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 8c4339dbab499d37ccd3f996989413befbf5f086 Author: Quan Zhou Date: Wed Feb 25 17:47:22 2026 +0800 wifi: mt76: mt7925: fix incorrect TLV length in CLC command commit 62e037aa8cf5a69b7ea63336705a35c897b9db2b upstream. The previous implementation of __mt7925_mcu_set_clc() set the TLV length field (.len) incorrectly during CLC command construction. The length was initialized as sizeof(req) - 4, regardless of the actual segment length. This could cause the WiFi firmware to misinterpret the command payload, resulting in command execution errors. This patch moves the TLV length assignment to after the segment is selected, and sets .len to sizeof(req) + seg->len - 4, matching the actual command content. This ensures the firmware receives the correct TLV length and parses the command properly. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Cc: stable@vger.kernel.org Signed-off-by: Quan Zhou Acked-by: Sean Wang Link: https://patch.msgid.link/f56ae0e705774dfa8aab3b99e5bbdc92cd93523e.1772011204.git.quan.zhou@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 0f0c0c1397a42aacaacae828206ee1b921623952 Author: Mark Brown Date: Thu Mar 26 14:52:41 2026 +0000 ASoC: SOF: Don't allow pointer operations on unconfigured streams commit c5b6285aae050ff1c3ea824ca3d88ac4be1e69c8 upstream. When reporting the pointer for a compressed stream we report the current I/O frame position by dividing the position by the number of channels multiplied by the number of container bytes. These values default to 0 and are only configured as part of setting the stream parameters so this allows a divide by zero to be configured. Validate that they are non zero, returning an error if not Fixes: c1a731c71359 ("ASoC: SOF: compress: Add support for computing timestamps") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260326-asoc-compress-tstamp-params-v1-1-3dc735b3d599@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 9a2d03d324b2c74a6014d607cec7555036f30cb0 Author: Sina Hassani Date: Fri Apr 10 11:32:44 2026 -0700 iommufd: Fix a race with concurrent allocation and unmap commit 8602018b1f17fbdaa5e5d79f4c8603ad20640c12 upstream. iopt_unmap_iova_range() releases the lock on iova_rwsem inside the loop body when getting to the more expensive unmap operations. This is fine on its own, except the loop condition is based on the first area that matches the unmap address range. If a concurrent call to map picks an area that was unmapped in previous iterations, the loop mistakenly tries to unmap it. This is reproducible by having one userspace thread map buffers and pass them to another thread that unmaps them. The problem manifests as EBUSY errors with single page mappings. Fix this by advancing the start pointer after unmapping an area. This ensures each iteration only examines the IOVA range that remains mapped, which is guaranteed not to have overlaps. Cc: stable@vger.kernel.org Fixes: 51fe6141f0f6 ("iommufd: Data structure to provide IOVA to PFN mapping") Link: https://patch.msgid.link/r/CAAJpGJSR4r_ds1JOjmkqHtsBPyxu8GntoeW08Sk5RNQPmgi+tg@mail.gmail.com Signed-off-by: Sina Hassani Reviewed-by: Kevin Tian Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 2c5b8eeea006eb694c81631cd5713d494b80be90 Author: David Carlier Date: Mon Apr 13 20:06:01 2026 +0100 tracepoint: balance regfunc() on func_add() failure in tracepoint_add_func() commit fad217e16fded7f3c09f8637b0f6a224d58b5f2e upstream. When a tracepoint goes through the 0 -> 1 transition, tracepoint_add_func() invokes the subsystem's ext->regfunc() before attempting to install the new probe via func_add(). If func_add() then fails (for example, when allocate_probes() cannot allocate a new probe array under memory pressure and returns -ENOMEM), the function returns the error without calling the matching ext->unregfunc(), leaving the side effects of regfunc() behind with no installed probe to justify them. For syscall tracepoints this is particularly unpleasant: syscall_regfunc() bumps sys_tracepoint_refcount and sets SYSCALL_TRACEPOINT on every task. After a leaked failure, the refcount is stuck at a non-zero value with no consumer, and every task continues paying the syscall trace entry/exit overhead until reboot. Other subsystems providing regfunc()/unregfunc() pairs exhibit similarly scoped persistent state. Mirror the existing 1 -> 0 cleanup and call ext->unregfunc() in the func_add() error path, gated on the same condition used there so the unwind is symmetric with the registration. Fixes: 8cf868affdc4 ("tracing: Have the reg function allow to fail") Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Link: https://patch.msgid.link/20260413190601.21993-1-devnexen@gmail.com Signed-off-by: David Carlier Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 540fa6a86b912ed7b4794e885865289f02f4e87d Author: Shivam Kalra Date: Sun Apr 26 19:38:41 2026 +0530 ACPI: video: force native backlight on HP OMEN 16 (8A44) commit 4b506ea5351a1f5937ac632a4a5c35f6f796cc41 upstream. The HP OMEN 16 Gaming Laptop (board name 8A44) has a mux-less hybrid GPU configuration with AMD Rembrandt (Radeon 680M) and NVIDIA GA104 (RTX 3070 Ti). The internal eDP panel is wired to the AMD iGPU. When Nouveau loads without GSP firmware, the ACPI video backlight device (acpi_video0) gets registered alongside the native AMD backlight (amdgpu_bl2). In this state, writes to amdgpu_bl2 update the software brightness value but fail to change the physical panel brightness. Force native backlight to prevent acpi_video0 from registering. Confirmed that booting with acpi_backlight=native resolves the issue. Cc: All applicable Signed-off-by: Shivam Kalra Link: https://patch.msgid.link/20260426-omen-16-backlight-fix-v1-1-62364f268ea6@zohomail.in Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 70446f52251f241b1f215f9b913c5b8584760c68 Author: Jinjie Ruan Date: Fri Apr 17 12:01:12 2026 +0800 ACPI: CPPC: Fix related_cpus inconsistency during CPU hotplug commit 75141a770f4f8225d316f6c7e146723a32e9720e upstream. When concurrently bringing up and down two SMT threads of a physical core, many warning call traces occur as below: The issue timeline is as follows: 1. When the system starts, cpufreq: CPU: 220, policy->related_cpus: 220-221, policy->cpus: 220-221 2. Offline CPU 220 and CPU 221. 3. Online CPU 220 - CPU 221 is now offline, as acpi_get_psd_map() use for_each_online_cpu(), so the cpu_data->shared_cpu_map, policy->cpus, and related_cpus has only CPU 220. cpufreq: CPU: 220, policy->related_cpus: 220, policy->cpus: 220 4. Offline CPU 220 5. Online CPU 221, the below call trace occurs: - Since CPU 220 and CPU 221 share one policy, and policy->related_cpus = 220 after step 3, so CPU 221 is not in policy->related_cpus but per_cpu(cpufreq_cpu_data, cpu221) is not NULL. After reverting commit 56eb0c0ed345 ("ACPI: CPPC: Fix remaining for_each_possible_cpu() to use online CPUs"), the issue disappeared. The _PSD (P-State Dependency) defines the hardware-level dependency of frequency control across CPU cores. Since this relationship is a physical attribute of the hardware topology, it remains constant regardless of the online or offline status of the CPUs. Using for_each_online_cpu() in acpi_get_psd_map() is problematic. If a CPU is offline, it will be excluded from the shared_cpu_map. Consequently, if that CPU is brought online later, the kernel will fail to recognize it as part of any shared frequency domain. Switch back to for_each_possible_cpu() to ensure that all cores defined in the ACPI tables are correctly mapped into their respective performance domains from the start. This aligns with the logic of policy->related_cpus, which must encompass all potentially available cores in the domain to prevent logic gaps during CPU hotplug operations. To resolve the original issue regarding the "nosmt" or "nosmt=force" boot parameter, as send_pcc_cmd() function already does if (!desc) continue, so reverting that loop back to for_each_possible_cpu() is ok, only need to change the match_cpc_ptr NULL case in acpi_get_psd_map() to continue as Sean suggested. How to reproduce, on arm64 machine with SMT support which use acpi cppc cpufreq driver: bash test.sh 220 & bash test.sh 221 & The test.sh is as below: while true do echo 0 > /sys/devices/system/cpu/cpu${1}/online sleep 0.5 cat /sys/devices/system/cpu/cpu${1}/cpufreq/related_cpus echo 1 > /sys/devices/system/cpu/cpu${1}/online cat /sys/devices/system/cpu/cpu${1}/cpufreq/related_cpus done CPU: 221 PID: 1119 Comm: cpuhp/221 Kdump: loaded Not tainted 6.6.0debug+ #5 Hardware name: To be filled by O.E.M. S920X20/BC83AMDA01-7270Z, BIOS 20.39 09/04/2024 pstate: a1400009 (NzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : cpufreq_online+0x8ac/0xa90 lr : cpuhp_cpufreq_online+0x18/0x30 sp : ffff80008739bce0 x29: ffff80008739bce0 x28: 0000000000000000 x27: ffff28400ca32200 x26: 0000000000000000 x25: 0000000000000003 x24: ffffd483503ff000 x23: ffffd483504051a0 x22: ffffd48350024a00 x21: 00000000000000dd x20: 000000000000001d x19: ffff28400ca32000 x18: 0000000000000000 x17: 0000000000000020 x16: ffffd4834e6a3fc8 x15: 0000000000000020 x14: 0000000000000008 x13: 0000000000000001 x12: 00000000ffffffff x11: 0000000000000040 x10: ffffd48350430728 x9 : ffffd4834f087c78 x8 : 0000000000000001 x7 : ffff2840092bdf00 x6 : ffffd483504264f0 x5 : ffffd48350405000 x4 : ffff283f7f95cc60 x3 : 0000000000000000 x2 : ffff53bc2f94b000 x1 : 00000000000000dd x0 : 0000000000000000 Call trace: cpufreq_online+0x8ac/0xa90 cpuhp_cpufreq_online+0x18/0x30 cpuhp_invoke_callback+0x128/0x580 cpuhp_thread_fun+0x110/0x1b0 smpboot_thread_fn+0x140/0x190 kthread+0xec/0x100 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- Cc: All applicable Fixes: 56eb0c0ed345 ("ACPI: CPPC: Fix remaining for_each_possible_cpu() to use online CPUs") Co-developed-by: Sean Kelley Signed-off-by: Sean Kelley Signed-off-by: Jinjie Ruan [ rjw: Changelog edits ] Link: https://patch.msgid.link/20260417040112.3727756-1-ruanjinjie@huawei.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 42f83350394a39630db8f45034952417ed415d09 Author: Jan Schär Date: Sat Apr 11 11:26:06 2026 +0200 ACPI: video: Add backlight=native quirk for Dell OptiPlex 7770 AIO commit ad7997f5a01af6f711fe6b6a2df578b964109d49 upstream. The Dell OptiPlex 7770 AIO needs the same quirk as the 7760 AIO. The backlight can be controlled with the native controller, intel_backlight, but not with dell_uart_backlight. I dumped the DSDT using acpidump, acpixtract and iasl, and confirmed that it contains the DELL0501 device. When loading the dell_uart_backlight driver with `rmmod dell_uart_backlight`, `modprobe dell_uart_backlight dyndbg`, it reports "Firmware version: GL_Re_V18". Fixes: cd8e468efb4f ("ACPI: video: Add Dell UART backlight controller detection") Cc: All applicable Signed-off-by: Jan Schär Reviewed-by: Hans de Goede Link: https://patch.msgid.link/20260411092606.47925-1-jan@jschaer.ch Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 7f0a53c2b94ca8ceb6e3203003bb54507daa25c9 Author: Guangshuo Li Date: Mon Apr 13 21:53:43 2026 +0800 ACPI: scan: Use acpi_dev_put() in object add error paths commit 9c0acc169ac71535477caedea8315f7041c5f07c upstream. After acpi_init_device_object(), the lifetime of struct acpi_device is managed by the driver core through reference counting. Both acpi_add_power_resource() and acpi_add_single_object() call acpi_init_device_object() and then invoke acpi_device_add(). If that fails, their error paths call the release callback directly instead of dropping the device reference through acpi_dev_put(). This bypasses the normal device lifetime rules and frees the object without releasing the reference acquired by device_initialize(), which may lead to a refcount leak. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fix both error paths by using acpi_dev_put() and let the release callback handle the final cleanup. Fixes: 781d737c7466 ("ACPI: Drop power resources driver") Fixes: 718fb0de8ff88 ("ACPI: fix NULL bug for HID/UID string") Cc: All applicable Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260413135343.2884481-1-lgs201920130244@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit da9b065cedfd3b574f229d5be594e6aa47a27ae6 Author: Rajat Gupta Date: Sun May 3 20:51:10 2026 -0700 fbdev: udlfb: add vm_ops to dlfb_ops_mmap to prevent use-after-free commit 8de779dc40d35d39fa07387b6f921eb11df0f511 upstream. dlfb_ops_mmap() uses remap_pfn_range() to map vmalloc framebuffer pages to userspace but sets no vm_ops on the VMA. This means the kernel cannot track active mmaps. When dlfb_realloc_framebuffer() replaces the backing buffer via FBIOPUT_VSCREENINFO, existing mmap PTEs are not invalidated. On USB disconnect, dlfb_ops_destroy() calls vfree() on the old pages while userspace PTEs still reference them, resulting in a use-after-free: the process retains read/write access to freed kernel pages. Add vm_operations_struct with open/close callbacks that maintain an atomic mmap_count on struct dlfb_data. In dlfb_realloc_framebuffer(), check mmap_count and return -EBUSY if the buffer is currently mapped, preventing buffer replacement while userspace holds stale PTEs. Tested with PoC using dummy_hcd + raw_gadget USB device emulation. Signed-off-by: Rajat Gupta Acked-by: Greg Kroah-Hartman Cc: stable@vger.kernel.org Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit bc13fce9eeec88c4950924754c3347c6dc66ff4c Author: Corey Minyard Date: Mon Apr 20 13:02:18 2026 -0500 ipmi:si: Return state to normal if message allocation fails commit 09dd798270ff582d7309f285d4aaf5dbebae01cb upstream. There were places where nothing would get started if a message allocation failed, so the driver needs to return to normal state. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman commit 42432b579a594b66ac32e5e7b7c26e6bc578ec89 Author: Corey Minyard Date: Mon Apr 20 12:50:09 2026 -0500 ipmi: Check event message buffer response for bad data commit 36920f30e78e69df01f9691c470b6f3ba8aebf98 upstream. The event message buffer response data size got checked later when processing, but check it right after the response comes back. It appears some BMCs may return an empty message instead of an error when fetching events. There are apparently some new BMCs that make this error, so we need to compensate. Reported-by: Matt Fleming Closes: https://lore.kernel.org/lkml/20260415115930.3428942-1-matt@readmodwrite.com/ Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman commit 3d37d2165df9504ea99d9e6181552dc4d2d1ab37 Author: Corey Minyard Date: Mon Apr 20 12:39:51 2026 -0500 ipmi: Add limits to event and receive message requests commit c4cca236968683eb0d59abfb12d5c7e4d8514227 upstream. The driver would just fetch events and receive messages until the BMC said it was done. To avoid issues with BMCs that never say they are done, add a limit of 10 fetches at a time. In addition, an si interface has an attn state it can return from the hardware which is supposed to cause a flag fetch to see if the driver needs to fetch events or message or a few other things. If the attn bit gets stuck, it's a similar problem. So allow messages in between flag fetches so the driver itself doesn't get stuck. This is a more general fix than the previous fix for the specific bad BMC, but should fix the more general issue of a BMC that won't stop saying it has data. This has been there from the beginning of the driver. It's not a bug per-se, but it is accounting for bugs in BMCs. Reported-by: Matt Fleming Closes: https://lore.kernel.org/lkml/20260415115930.3428942-1-matt@readmodwrite.com/ Fixes: <1da177e4c3f4> ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman commit 00d91bfdce5033f5d9b4915638ae9b0553848b5d Author: Greg Kroah-Hartman Date: Sat Apr 11 14:06:00 2026 +0200 scsi: target: configfs: Bound snprintf() return in tg_pt_gp_members_show() commit 772a896a56e0e3ef9424a025cec9176f9d8f4552 upstream. target_tg_pt_gp_members_show() formats LUN paths with snprintf() into a 256-byte stack buffer, then will memcpy() cur_len bytes from that buffer. snprintf() returns the length the output would have had, which can exceed the buffer size when the fabric WWN is long because iSCSI IQN names can be up to 223 bytes. The check at the memcpy() site only guards the destination page write, not the source read, so memcpy() will read past the stack buffer and copy adjacent stack contents to the sysfs reader, which when CONFIG_FORTIFY_SOURCE is enabled, fortify_panic() will be triggered. Commit 27e06650a5ea ("scsi: target: target_core_configfs: Add length check to avoid buffer overflow") added the same bound to the target_lu_gp_members_show() but the tg_pt_gp variant was missed so resolve that here. Cc: Martin K. Petersen Fixes: c66ac9db8d4a ("[SCSI] target: Add LIO target core v4.0.0-rc6") Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2026041159-garter-theft-3be0@gregkh Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 291696c6d6dbe262e6f3a88b917289f977fef44c Author: Alexandre Frade Date: Mon May 11 16:58:44 2026 +0000 Linux 6.18.29-rt-xanmod1 Signed-off-by: Alexandre Frade commit 7bfe90e90e7f4bf8de0cc3b52a9281d0776b00e2 Merge: 00ac7cb3bb2a 3c8a7708d26d Author: Alexandre Frade Date: Mon May 11 16:58:10 2026 +0000 Merge branch '6.18' into 6.18-rt commit 3c8a7708d26d30925010b21b0c412d9b99bda05c Author: Alexandre Frade Date: Mon May 11 16:51:36 2026 +0000 Linux 6.18.29-xanmod1 Signed-off-by: Alexandre Frade commit 369de376366a0e8833568e892001f4179f81b852 Merge: 386484d53ce6 d31a849ff501 Author: Alexandre Frade Date: Mon May 11 16:49:52 2026 +0000 Merge tag 'v6.18.29' into 6.18 This is the 6.18.29 stable release commit d31a849ff5011dad5c271b53819a0b279e367d68 Author: Greg Kroah-Hartman Date: Mon May 11 08:20:52 2026 +0200 Linux 6.18.29 Signed-off-by: Greg Kroah-Hartman commit 3eae0f4f9f7206a4801efa5e0235c25bbd5a412c Author: Hyunwoo Kim Date: Fri May 8 17:53:09 2026 +0900 rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present commit aa54b1d27fe0c2b78e664a34fd0fdf7cd1960d71 upstream. The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained skb_has_frag_list()) falls through to the in-place decryption path, which binds the frag pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). Extend the gate to also unshare when skb_has_frag_list() or skb_has_shared_frag() is true. This catches the splice-loopback vector and other externally-shared frag sources while preserving the zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC page_pool RX, GRO). The OOM/trace handling already in place is reused. Fixes: d0d5c0cd1e71 ("rxrpc: Use skb_unshare() rather than skb_cow_data()") Cc: stable@vger.kernel.org Signed-off-by: Hyunwoo Kim Reviewed-by: Jiayuan Chen Acked-by: David Howells Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c31b94a4231c974dca12e6b83f2af1d1d95dfc5e Author: Greg Kroah-Hartman Date: Fri May 8 08:40:23 2026 +0200 Linux 6.18.28 Signed-off-by: Greg Kroah-Hartman commit 71a1d9d985d26716f74d21f18ee8cac821b06e97 Author: Kuan-Ting Chen Date: Mon May 4 23:27:12 2026 +0800 xfrm: esp: avoid in-place decrypt on shared skb frags commit f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4 upstream. MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(), so later paths that may modify packet data can first make a private copy. The IPv4/IPv6 datagram append paths did not set this flag when splicing pages into UDP skbs. That leaves an ESP-in-UDP packet made from shared pipe pages looking like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW fast path for uncloned skbs without a frag_list and decrypts in place over data that is not owned privately by the skb. Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching TCP. Also make ESP input fall back to skb_cow_data() when the flag is present, so ESP does not decrypt externally backed frags in place. Private nonlinear skb frags still use the existing fast path. This intentionally does not change ESP output. In esp_output_head(), the path that appends the ESP trailer to existing skb tailroom without calling skb_cow_data() is not reachable for nonlinear skbs: skb_tailroom() returns zero when skb->data_len is nonzero, while ESP tailen is positive. Thus ESP output will either use the separate destination-frag path or fall back to skb_cow_data(). Fixes: cac2661c53f3 ("esp4: Avoid skb_cow_data whenever possible") Fixes: 03e2a30f6a27 ("esp6: Avoid skb_cow_data whenever possible") Fixes: 7da0dde68486 ("ip, udp: Support MSG_SPLICE_PAGES") Fixes: 6d8192bd69bb ("ip6, udp6: Support MSG_SPLICE_PAGES") Reported-by: Hyunwoo Kim Reported-by: Kuan-Ting Chen Tested-by: Hyunwoo Kim Cc: stable@vger.kernel.org Signed-off-by: Kuan-Ting Chen Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 386484d53ce6c8cccbf80262cbec1c688b645393 Author: Alexandre Frade Date: Thu May 7 17:35:31 2026 +0000 Linux 6.18.27-xanmod1 Signed-off-by: Alexandre Frade commit 95bd50e63f30f62b00ea5485171fc393c6fcd926 Merge: b7e7f36157eb ce685b6a03dc Author: Alexandre Frade Date: Thu May 7 17:34:52 2026 +0000 Merge tag 'v6.18.27' into 6.18 This is the 6.18.27 stable release commit ce685b6a03dc0270f78bc7aaf2c9ada9cbd45a86 Author: Greg Kroah-Hartman Date: Thu May 7 06:12:03 2026 +0200 Linux 6.18.27 Link: https://lore.kernel.org/r/20260504135142.929052779@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Peter Schneider Tested-by: Wentao Guan Tested-by: Florian Fainelli Tested-by: Ron Economos Tested-by: Miguel Ojeda Tested-by: Mark Brown Tested-by: Shuah Khan Tested-by: Dileep Malepu Signed-off-by: Greg Kroah-Hartman commit 97d35052a816875ad16bc37ae163ebc873b2928d Author: Corey Minyard Date: Tue Apr 21 06:50:22 2026 -0500 ipmi:ssif: NULL thread on error commit a8aebe93a4938c0ca1941eeaae821738f869be3d upstream. Cleanup code was checking the thread for NULL, but it was possibly a PTR_ERR() in one spot. Spotted with static analysis. Link: https://sourceforge.net/p/openipmi/mailman/message/59324676/ Fixes: 75c486cb1bca ("ipmi:ssif: Clean up kthread on errors") Cc: # 91eb7ec72612: ipmi:ssif: Remove unnecessary indention Cc: stable@vger.kernel.org Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman commit 52a7c9a2823da0d06b1a659b1bea1290a79a5044 Author: Corey Minyard Date: Mon Apr 13 07:09:15 2026 -0500 ipmi:ssif: Remove unnecessary indention commit 91eb7ec7261254b6875909df767185838598e21e upstream. A section was in {} that didn't need to be, move the variable definition to the top and set th eindentino properly. Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman commit 6f820139d16a4c9865a145d4a9cf9c92cc632c14 Author: Kai Ma Date: Wed Apr 22 22:54:18 2026 +0800 netfilter: reject zero shift in nft_bitwise commit fe11e5c40817b84abaa5d83bfb6586d8412bfd07 upstream. Reject zero shift operands for nft_bitwise left and right shift expressions during initialization. The carry propagation logic computes the carry from the adjacent 32-bit word using BITS_PER_TYPE(u32) - shift. A zero shift operand turns this into a 32-bit shift, which is undefined behaviour. Reject zero shift operands in the control plane, alongside the existing check for values greater than or equal to 32, so malformed rules never reach the packet path. Fixes: 567d746b55bc ("netfilter: bitwise: add support for shifts.") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Kai Ma Signed-off-by: Ren Wei Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit b778b6d095421619c331fd2d7751143cd5387103 Author: Andrea Mayer Date: Tue Apr 21 11:47:35 2026 +0200 net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels commit f9c52a6ba9780bd27e0bf4c044fd91c13c778b6e upstream. seg6_input_core() and rpl_input() call ip6_route_input() which sets a NOREF dst on the skb, then pass it to dst_cache_set_ip6() invoking dst_hold() unconditionally. On PREEMPT_RT, ksoftirqd is preemptible and a higher-priority task can release the underlying pcpu_rt between the lookup and the caching through a concurrent FIB lookup on a shared nexthop. Simplified race sequence: ksoftirqd/X higher-prio task (same CPU X) ----------- -------------------------------- seg6_input_core(,skb)/rpl_input(skb) dst_cache_get() -> miss ip6_route_input(skb) -> ip6_pol_route(,skb,flags) [RT6_LOOKUP_F_DST_NOREF in flags] -> FIB lookup resolves fib6_nh [nhid=N route] -> rt6_make_pcpu_route() [creates pcpu_rt, refcount=1] pcpu_rt->sernum = fib6_sernum [fib6_sernum=W] -> cmpxchg(fib6_nh.rt6i_pcpu, NULL, pcpu_rt) [slot was empty, store succeeds] -> skb_dst_set_noref(skb, dst) [dst is pcpu_rt, refcount still 1] rt_genid_bump_ipv6() -> bumps fib6_sernum [fib6_sernum from W to Z] ip6_route_output() -> ip6_pol_route() -> FIB lookup resolves fib6_nh [nhid=N] -> rt6_get_pcpu_route() pcpu_rt->sernum != fib6_sernum [W <> Z, stale] -> prev = xchg(rt6i_pcpu, NULL) -> dst_release(prev) [prev is pcpu_rt, refcount 1->0, dead] dst = skb_dst(skb) [dst is the dead pcpu_rt] dst_cache_set_ip6(dst) -> dst_hold() on dead dst -> WARN / use-after-free For the race to occur, ksoftirqd must be preemptible (PREEMPT_RT without PREEMPT_RT_NEEDS_BH_LOCK) and a concurrent task must be able to release the pcpu_rt. Shared nexthop objects provide such a path, as two routes pointing to the same nhid share the same fib6_nh and its rt6i_pcpu entry. Fix seg6_input_core() and rpl_input() by calling skb_dst_force() after ip6_route_input() to force the NOREF dst into a refcounted one before caching. The output path is not affected as ip6_route_output() already returns a refcounted dst. Fixes: af4a2209b134 ("ipv6: sr: use dst_cache in seg6_input") Fixes: a7a29f9c361f ("net: ipv6: add rpl sr tunnel") Cc: stable@vger.kernel.org Signed-off-by: Andrea Mayer Reviewed-by: Simon Horman Reviewed-by: Justin Iurman Link: https://patch.msgid.link/20260421094735.20997-1-andrea.mayer@uniroma2.it Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit a8d95d274be241ad21f6523bf2d6ba0d7d7e46b7 Author: Harry Yoo (Oracle) Date: Mon Apr 27 16:09:53 2026 +0900 mm/slab: return NULL early from kmalloc_nolock() in NMI on UP commit 5b31044e649e3e54c2caef135c09b371c2fbcd08 upstream. On UP kernels (!CONFIG_SMP), spin_trylock() is a no-op that unconditionally succeeds even when the lock is already held. As a result, kmalloc_nolock() called from NMI context can re-enter the slab allocator and acquire n->list_lock that the interrupted context is already holding, corrupting slab state. With CONFIG_DEBUG_SPINLOCK on UP, the following BUG is triggered with the slub_kunit test module: BUG: spinlock trylock failure on UP on CPU#0, kunit_try_catch/243 [...] Call Trace: dump_stack_lvl+0x3f/0x60 do_raw_spin_trylock+0x41/0x50 _raw_spin_trylock+0x24/0x50 get_from_partial_node+0x120/0x4d0 ___slab_alloc+0x8a/0x4c0 kmalloc_nolock_noprof+0x164/0x310 [...] Fix this by returning NULL early when invoked from NMI on a UP kernel. Link: https://lore.kernel.org/linux-mm/ad_cqe51pvr1WaDg@hyeyoo Cc: stable@vger.kernel.org Fixes: af92793e52c3 ("slab: Introduce kmalloc_nolock() and kfree_nolock().") Signed-off-by: Harry Yoo (Oracle) Link: https://patch.msgid.link/20260427-nolock-api-fix-v2-2-a6b83a92d9a4@kernel.org Signed-off-by: Vlastimil Babka (SUSE) Signed-off-by: Greg Kroah-Hartman commit 05b4ed8bef30bba4f559c8d835e2dd20c48cf8a4 Author: Harry Yoo (Oracle) Date: Mon Apr 27 16:09:52 2026 +0900 mm/page_alloc: return NULL early from alloc_frozen_pages_nolock() in NMI on UP commit 620b46ed6ae17c8438d889c8c0cfddab36a1476c upstream. On UP kernels (!CONFIG_SMP), spin_trylock() is a no-op that unconditionally succeeds even when the lock is already held. As a result, alloc_frozen_pages_nolock() called from NMI context can re-enter rmqueue() and acquire the zone lock that the interrupted context is already holding, corrupting the freelists. With CONFIG_DEBUG_SPINLOCK on UP, the following BUG is triggered with the slub_kunit test module: BUG: spinlock trylock failure on UP on CPU#0, kunit_try_catch/243 [...] Call Trace: dump_stack_lvl+0x3f/0x60 do_raw_spin_trylock+0x41/0x50 _raw_spin_trylock+0x24/0x50 rmqueue.isra.0+0x2a9/0xa70 get_page_from_freelist+0xeb/0x450 alloc_frozen_pages_nolock_noprof+0x111/0x1e0 allocate_slab+0x42a/0x500 ___slab_alloc+0xa7/0x4c0 kmalloc_nolock_noprof+0x164/0x310 [...] Fix this by returning NULL early when invoked from NMI on a UP kernel. Link: https://lore.kernel.org/linux-mm/ad_cqe51pvr1WaDg@hyeyoo Cc: stable@vger.kernel.org Fixes: d7242af86434 ("mm: Introduce alloc_frozen_pages_nolock()") Signed-off-by: Harry Yoo (Oracle) Link: https://patch.msgid.link/20260427-nolock-api-fix-v2-1-a6b83a92d9a4@kernel.org Signed-off-by: Vlastimil Babka (SUSE) Signed-off-by: Greg Kroah-Hartman commit e9b057a44deff4c59c13f44672a5cc74dcd57522 Author: Marco Elver Date: Mon Apr 20 13:47:26 2026 +0200 vmalloc: fix buffer overflow in vrealloc_node_align() commit 82d1f01292d3f09bf063f829f8ab8de12b4280a1 upstream. Commit 4c5d3365882d ("mm/vmalloc: allow to set node and align in vrealloc") added the ability to force a new allocation if the current pointer is on the wrong NUMA node, or if an alignment constraint is not met, even if the user is shrinking the allocation. On this path (need_realloc), the code allocates a new object of 'size' bytes and then memcpy()s 'old_size' bytes into it. If the request is to shrink the object (size < old_size), this results in an out-of-bounds write on the new buffer. Fix this by bounding the copy length by the new allocation size. Link: https://lore.kernel.org/20260420114805.3572606-2-elver@google.com Fixes: 4c5d3365882d ("mm/vmalloc: allow to set node and align in vrealloc") Signed-off-by: Marco Elver Reported-by: Harry Yoo (Oracle) Reviewed-by: Uladzislau Rezki (Sony) Acked-by: Vlastimil Babka (SUSE) Reviewed-by: Harry Yoo (Oracle) Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit bdd9503c3d222d2735b56c7a8b4422ccf3de6e5c Author: Cássio Gabriel Date: Fri Apr 24 09:48:41 2026 -0300 ALSA: aloop: Fix peer runtime UAF during format-change stop commit e5c33cdc6f402eab8abd36ecf436b22c9d3a8aff upstream. loopback_check_format() may stop the capture side when playback starts with parameters that no longer match a running capture stream. Commit 826af7fa62e3 ("ALSA: aloop: Fix racy access at PCM trigger") moved the peer lookup under cable->lock, but the actual snd_pcm_stop() still runs after dropping that lock. A concurrent close can clear the capture entry from cable->streams[] and detach or free its runtime while the playback trigger path still holds a stale peer substream pointer. Keep a per-cable count of in-flight peer stops before dropping cable->lock, and make free_cable() wait for those stops before detaching the runtime. This preserves the existing behavior while making the peer runtime lifetime explicit. Reported-by: syzbot+8fa95c41eafbc9d2ff6f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=8fa95c41eafbc9d2ff6f Fixes: 597603d615d2 ("ALSA: introduce the snd-aloop module for the PCM loopback") Cc: stable@vger.kernel.org Suggested-by: Takashi Iwai Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260424-alsa-aloop-peer-stop-uaf-v2-1-94e68101db8a@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6153878c5255bb69b7d0868105ca078ef13cbcf8 Author: Deepanshu Kartikey Date: Sun Apr 26 05:49:34 2026 +0530 ALSA: caiaq: fix usb_dev refcount leak on probe failure commit 7a5f1cd22d47f8ca4b760b6334378ae42c1bd24b upstream. create_card() takes a reference on the USB device with usb_get_dev() and stores the matching usb_put_dev() in card_free(), which is installed as the snd_card's ->private_free destructor. However, ->private_free is only assigned near the end of init_card(), after several failure points (usb_set_interface(), EP type checks, usb_submit_urb(), the EP1_CMD_GET_DEVICE_INFO exchange, and its timeout). When any of those fail, init_card() returns an error to snd_probe(), which calls snd_card_free(card). Because ->private_free is still NULL, card_free() never runs, the usb_get_dev() reference is not dropped, and the struct usb_device leaks along with its descriptor allocations and device_private. syzbot reproduces this with a malformed UAC3 device whose only valid altsetting is 0; init_card()'s usb_set_interface(usb_dev, 0, 1) call fails with -EIO and triggers the leak. Move the ->private_free assignment into create_card(), immediately after usb_get_dev(), so that every error path reaching snd_card_free() balances the reference. card_free()'s callees (snd_usb_caiaq_input_free, free_urbs, kfree) already tolerate the partially-initialized state because the chip private area is zero-initialized by snd_card_new(). Fixes: 80bb50e2d459 ("ALSA: caiaq: take a reference on the USB device in create_card()") Reported-by: syzbot+2afd7e71155c7e241560@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=2afd7e71155c7e241560 Tested-by: syzbot+2afd7e71155c7e241560@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Deepanshu Kartikey Link: https://patch.msgid.link/20260426001934.70813-1-kartikey406@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 30c000a49094ec568c9b51b7421f7a4a3f0b0298 Author: Arjan van de Ven Date: Mon Apr 20 14:57:15 2026 -0700 drm/amdgpu: fix zero-size GDS range init on RDNA4 commit 095a8b0ad3c3b5cdc3850d961adb8a8f735220bb upstream. RDNA4 (GFX 12) hardware removes the GDS, GWS, and OA on-chip memory resources. The gfx_v12_0 initialisation code correctly leaves adev->gds.gds_size, adev->gds.gws_size, and adev->gds.oa_size at zero to reflect this. amdgpu_ttm_init() unconditionally calls amdgpu_ttm_init_on_chip() for each of these resources regardless of size. When the size is zero, amdgpu_ttm_init_on_chip() forwards the call to ttm_range_man_init(), which calls drm_mm_init(mm, 0, 0). drm_mm_init() immediately fires DRM_MM_BUG_ON(start + size <= start) -- trivially true when size is zero -- crashing the kernel during modprobe of amdgpu on an RX 9070 XT. Guard against this by returning 0 early from amdgpu_ttm_init_on_chip() when size_in_page is zero. This skips TTM resource manager registration for hardware resources that are absent, without affecting any other GPU type. DRM_MM_BUG_ON() only asserts if CONFIG_DRM_DEBUG_MM is enabled in the kernel config. This is apparently rarely enabled as these chips have been in the market for over a year and this issue was only reported now. Link: https://lore.kernel.org/all/bug-221376-2300@https.bugzilla.kernel.org%2F/ Link: https://bugzilla.kernel.org/show_bug.cgi?id=221376 Oops-Analysis: http://oops.fenrus.org/reports/bugzilla.korg/221376/report.html Assisted-by: GitHub Copilot:Claude Sonnet 4.6 linux-kernel-oops-x86. Signed-off-by: Arjan van de Ven Cc: Alex Deucher Cc: "Christian König" Cc: amd-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Alex Deucher (cherry picked from commit 5719ce5865279cad4fd5f01011fe037168503f2d) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit c261d07a80576dc8ccf394ef8f074f8c67a06b37 Author: Greg Kroah-Hartman Date: Tue Apr 21 15:16:33 2026 +0200 ipv6: rpl: reserve mac_len headroom when recompressed SRH grows commit 9e6bf146b55999a095bb14f73a843942456d1adc upstream. ipv6_rpl_srh_rcv() decompresses an RFC 6554 Source Routing Header, swaps the next segment into ipv6_hdr->daddr, recompresses, then pulls the old header and pushes the new one plus the IPv6 header back. The recompressed header can be larger than the received one when the swap reduces the common-prefix length the segments share with daddr (CmprI=0, CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes). pskb_expand_head() was gated on segments_left == 0, so on earlier segments the push consumed unchecked headroom. Once skb_push() leaves fewer than skb->mac_len bytes in front of data, skb_mac_header_rebuild()'s call to: skb_set_mac_header(skb, -skb->mac_len); will store (data - head) - mac_len into the u16 mac_header field, which wraps to ~65530, and the following memmove() writes mac_len bytes ~64KiB past skb->head. A single AF_INET6/SOCK_RAW/IPV6_HDRINCL packet over lo with a two segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one pass; KASAN reports a 14-byte OOB write in ipv6_rthdr_rcv. Fix this by expanding the head whenever the remaining room is less than the push size plus mac_len, and request that much extra so the rebuilt MAC header fits afterwards. Fixes: 8610c7c6e3bd ("net: ipv6: add support for rpl sr exthdr") Cc: stable Reported-by: Anthropic Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2026042133-gout-unvented-1bd9@gregkh Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3d46009e2ad467cfd2eda23165f92d9e3c1e8480 Author: Takashi Iwai Date: Mon Apr 27 16:56:15 2026 +0200 ALSA: caiaq: Don't abort when no input device is available commit b32ae47a2b0a1fb4bd4942242847966d9b178222 upstream. The previous fix to handle the error from setup_card() caused a regression for the models that have no dedicated input device; snd_usb_caiaq_input_init() just returns -EINVAL, and we treat it as a fatal error although it should be ignored. As a regression fix, change the error code to -ENODEV, and ignore this error in the callee, to continue probing. Fixes: 28abd224db4a ("ALSA: caiaq: Handle probe errors properly") Cc: Link: https://bugzilla.kernel.org/show_bug.cgi?id=221423 Link: https://patch.msgid.link/20260427145642.6637-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1d160e30aa42b7c41163e51366bb34432367260d Author: Takashi Iwai Date: Mon Apr 27 14:37:53 2026 +0200 ALSA: caiaq: Fix potentially leftover ep1_in_urb at error path commit 0a7b5221b5b51cc798fcfc3be00d02eade149d69 upstream. The previous fix for handling the error from setup_card() missed that an internal URB cdev->ep1_in_urb might have been already submitted beforehand. In the normal case, this URB gets killed at the disconnection, but in the error path, we didn't do it, hence there can be a potential leak. Fix it in the error path for setup_card(), too. Fixes: 28abd224db4a ("ALSA: caiaq: Handle probe errors properly") Cc: Link: https://patch.msgid.link/20260427123819.890185-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b8c5acce56e07eb6654d0ff0427945875d9179f8 Author: Douglas Anderson Date: Mon Apr 13 19:59:11 2026 -0700 driver core: Add kernel-doc for DEV_FLAG_COUNT enum value commit 5b484311507b5d403c1f7a45f6aa3778549e268b upstream. Even though nobody should use this value (except when declaring the "flags" bitmap), kernel-doc still gets upset that it's not documented. It reports: WARNING: ../include/linux/device.h:519 Enum value 'DEV_FLAG_COUNT' not described in enum 'struct_device_flags' Add the description of DEV_FLAG_COUNT. Fixes: a2225b6e834a ("driver core: Don't let a device probe until it's ready") Reported-by: Randy Dunlap Closes: https://lore.kernel.org/f318cd43-81fd-48b9-abf7-92af85f12f91@infradead.org Signed-off-by: Douglas Anderson Tested-by: Randy Dunlap Reviewed-by: Randy Dunlap Link: https://patch.msgid.link/20260413195910.1.I23aca74fe2d3636a47df196a80920fecb2643220@changeid Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit b42821c15445f93daea3e76ada682b2b7181c476 Author: Yucheng Lu Date: Wed Apr 22 21:45:04 2026 +0800 crypto: authencesn - reject short ahash digests during instance creation commit 5db6ef9847717329f12c5ea8aba7e9f588a980c0 upstream. authencesn requires either a zero authsize or an authsize of at least 4 bytes because the ESN encrypt/decrypt paths always move 4 bytes of high-order sequence number data at the end of the authenticated data. While crypto_authenc_esn_setauthsize() already rejects explicit non-zero authsizes in the range 1..3, crypto_authenc_esn_create() still copied auth->digestsize into inst->alg.maxauthsize without validating it. The AEAD core then initialized the tfm's default authsize from that value. As a result, selecting an ahash with digest size 1..3, such as cbcmac(cipher_null), exposed authencesn instances whose default authsize was invalid even though setauthsize() would have rejected the same value. AF_ALG could then trigger the ESN tail handling with a too-short tag and hit an out-of-bounds access. Reject authencesn instances whose ahash digest size is in the invalid non-zero range 1..3 so that no tfm can inherit an unsupported default authsize. Fixes: f15f05b0a5de ("crypto: ccm - switch to separate cbcmac driver") Cc: stable@kernel.org Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Tested-by: Yuhang Zheng Reviewed-by: Eric Biggers Signed-off-by: Yucheng Lu Signed-off-by: Ren Wei Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 5cf6d5e5e3b804a44692fbf548a5179442e2e923 Author: Manivannan Sadhasivam Date: Mon May 4 03:40:08 2026 -0400 net: qrtr: ns: Limit the total number of nodes [ Upstream commit 27d5e84e810b0849d08b9aec68e48570461ce313 ] Currently, the nameserver doesn't limit the number of nodes it handles. This can be an attack vector if a malicious client starts registering random nodes, leading to memory exhaustion. Hence, limit the maximum number of nodes to 64. Note that, limit of 64 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased. Cc: stable@vger.kernel.org Fixes: 0c2204a4ad71 ("net: qrtr: Migrate nameservice to kernel from userspace") Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260409-qrtr-fix-v3-4-00a8a5ff2b51@oss.qualcomm.com Signed-off-by: Jakub Kicinski [ dropped comment/define changes for missing QRTR_NS_MAX_SERVERS/LOOKUPS prereqs and kept plain kzalloc instead of kzalloc_obj ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 20855cef7e659ef84ac73251256fa530819b2346 Author: Manivannan Sadhasivam Date: Sun May 3 13:55:04 2026 -0400 net: qrtr: ns: Limit the maximum number of lookups [ Upstream commit 5640227d9a21c6a8be249a10677b832e7f40dc55 ] Current code does no bound checking on the number of lookups a client can perform. Though the code restricts the lookups to local clients, there is still a possibility of a malicious local client sending a flood of NEW_LOOKUP messages over the same socket. Fix this issue by limiting the maximum number of lookups to 64 globally. Since the nameserver allows only atmost one local observer, this global lookup count will ensure that the lookups stay within the limit. Note that, limit of 64 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased. Cc: stable@vger.kernel.org Fixes: 0c2204a4ad71 ("net: qrtr: Migrate nameservice to kernel from userspace") Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260409-qrtr-fix-v3-2-00a8a5ff2b51@oss.qualcomm.com Signed-off-by: Jakub Kicinski [ adapted comment block to only mention QRTR_NS_MAX_LOOKUPS and kept kzalloc() instead of kzalloc_obj() due to missing prerequisite commits ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 35fb4a0c077c5d1049c2628b769e0a1b1e65df0d Author: Manivannan Sadhasivam Date: Sun May 3 13:54:25 2026 -0400 net: qrtr: ns: Limit the maximum server registration per node [ Upstream commit d5ee2ff98322337951c56398e79d51815acbf955 ] Current code does no bound checking on the number of servers added per node. A malicious client can flood NEW_SERVER messages and exhaust memory. Fix this issue by limiting the maximum number of server registrations to 256 per node. If the NEW_SERVER message is received for an old port, then don't restrict it as it will get replaced. While at it, also rate limit the error messages in the failure path of qrtr_ns_worker(). Note that the limit of 256 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased. Cc: stable@vger.kernel.org Fixes: 0c2204a4ad71 ("net: qrtr: Migrate nameservice to kernel from userspace") Reported-by: Yiming Qian Reviewed-by: Simon Horman Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260409-qrtr-fix-v3-1-00a8a5ff2b51@oss.qualcomm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5e9f1bad26df3d3afb3cbbfa408b6d6e809708ac Author: Antoniu Miclaus Date: Sun May 3 00:24:55 2026 -0400 iio: frequency: admv1013: fix NULL pointer dereference on str [ Upstream commit aac0a51b16700b403a55b67ba495de021db78763 ] When device_property_read_string() fails, str is left uninitialized but the code falls through to strcmp(str, ...), dereferencing a garbage pointer. Replace manual read/strcmp with device_property_match_property_string() and consolidate the SE mode enums into a single sequential enum, mapping to hardware register values via a switch consistent with other bitfields in the driver. Several cleanup patches have been applied to this driver recently so this will need a manual backport. Fixes: da35a7b526d9 ("iio: frequency: admv1013: add support for ADMV1013") Reviewed-by: Nuno Sá Signed-off-by: Antoniu Miclaus Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c772e9efe2b1f1b1dcd481474e36eae42a42176d Author: Antoniu Miclaus Date: Sun May 3 00:24:54 2026 -0400 iio: frequency: admv1013: add dev variable [ Upstream commit e61b5bb0e91390adee41eaddc0a1a7d55d5652b2 ] Introduce a local struct device pointer in functions that reference &spi->dev for device-managed resource calls and device property reads, improving code readability. Signed-off-by: Antoniu Miclaus Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Stable-dep-of: aac0a51b1670 ("iio: frequency: admv1013: fix NULL pointer dereference on str") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0adac0ee2c42027d80bac02ea9b576a88f8955d3 Author: Oliver Neukum Date: Fri May 1 15:12:22 2026 -0400 media: rc: igorplugusb: heed coherency rules [ Upstream commit eac69475b01fe1e861dfe3960b57fa95671c132e ] In a control request, the USB request structure can be subject to DMA on some HCs. Hence it must obey the rules for DMA coherency. Allocate it separately. Fixes: b1c97193c6437 ("[media] rc: port IgorPlug-USB to rc-core") Cc: stable@vger.kernel.org Signed-off-by: Oliver Neukum Signed-off-by: Sean Young Signed-off-by: Hans Verkuil [ replaced kzalloc_obj(*ir->request, GFP_KERNEL) with kzalloc(sizeof(*ir->request), GFP_KERNEL) ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7ba734027b2beeaa24a6f76614004a4126cccf74 Author: Oliver Neukum Date: Fri May 1 11:42:03 2026 -0400 media: rc: ttusbir: respect DMA coherency rules [ Upstream commit 50acaad3d202c064779db8dc3d010007347f59c7 ] Buffers must not share a cache line with other data structures. Allocate separately. Fixes: 0938069fa0897 ("[media] rc: Add support for the TechnoTrend USB IR Receiver") Cc: stable@vger.kernel.org Signed-off-by: Oliver Neukum Signed-off-by: Sean Young Signed-off-by: Hans Verkuil [ kept kzalloc(sizeof(*tt), GFP_KERNEL) instead of kzalloc_obj() ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7d7863018f40df0c6d32714a1723ae0c119abba0 Author: Sean Wang Date: Thu Apr 30 12:31:35 2026 -0400 wifi: mt76: mt792x: fix mt7925u USB WFSYS reset handling [ Upstream commit 56154fef47d104effa9f29ed3db4f805cbc0d640 ] mt7925u uses different reset/status registers from mt7921u. Reusing the mt7921u register set causes the WFSYS reset to fail. Add a chip-specific descriptor in mt792xu_wfsys_reset() to select the correct registers and fix mt7925u failing to initialize after a warm reboot. Fixes: d28e1a48952e ("wifi: mt76: mt792x: introduce mt792x-usb module") Cc: stable@vger.kernel.org Signed-off-by: Sean Wang Link: https://patch.msgid.link/20260311002825.15502-2-sean.wang@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0bc155c4ca4776f9de1851d54d457671d676ac57 Author: Sean Wang Date: Thu Apr 30 12:31:34 2026 -0400 wifi: mt76: mt792x: describe USB WFSYS reset with a descriptor [ Upstream commit e6f48512c1ceebcd1ce6bb83df3b3d56a261507d ] Prepare mt792xu_wfsys_reset() for chips that share the same USB WFSYS reset flow but use different register definitions. This is a pure refactor of the current mt7921u path and keeps the reset sequence unchanged. Signed-off-by: Sean Wang Link: https://patch.msgid.link/20260311002825.15502-1-sean.wang@kernel.org Signed-off-by: Felix Fietkau Stable-dep-of: 56154fef47d1 ("wifi: mt76: mt792x: fix mt7925u USB WFSYS reset handling") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 09e1c96594afb2a13e4090119728545ca9c06dfd Author: Elson Serrao Date: Fri May 1 09:18:56 2026 -0400 phy: qcom: m31-eusb2: clear PLL_EN during init [ Upstream commit 520a98bdf7ae0130e22d8adced3d69a2e211b41f ] The driver currently sets bit 0 of USB_PHY_CFG1 (PLL_EN) during PHY initialization. According to the M31 EUSB2 PHY hardware documentation, this bit is intended only for test/debug scenarios and does not control mission mode operation. Keeping PLL_EN asserted causes the PHY to draw additional current during USB bus suspend. Clearing this bit results in lower suspend power consumption without affecting normal operation. Update the driver to leave PLL_EN cleared as recommended by the hardware documentation. Fixes: 9c8504861cc4 ("phy: qcom: Add M31 based eUSB2 PHY driver") Cc: stable@vger.kernel.org Signed-off-by: Elson Serrao Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260217201130.2804550-1-elson.serrao@oss.qualcomm.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 37ef11ab2cf3ce04a92e4a5c1a59a74670c88a24 Author: Ronak Raheja Date: Fri May 1 09:18:55 2026 -0400 phy: qcom: m31-eusb2: Update init sequence to set PHY_ENABLE [ Upstream commit 7044ed6749c8a7d49e67b2f07f42da2f29d26be6 ] Certain platforms may not have the PHY_ENABLE bit set on power on reset. Update the current sequence to explicitly write to enable the PHY_ENABLE bit. This ensures that regardless of the platform, the PHY is properly enabled. Signed-off-by: Ronak Raheja Signed-off-by: Wesley Cheng Reviewed-by: Dmitry Baryshkov Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20250920032158.242725-1-wesley.cheng@oss.qualcomm.com Signed-off-by: Vinod Koul Stable-dep-of: 520a98bdf7ae ("phy: qcom: m31-eusb2: clear PLL_EN during init") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit da4a33e739dc886cdbc63984430b8870dba18ff3 Author: Alexander Usyskin Date: Tue Apr 28 06:12:05 2026 -0400 mei: me: add nova lake point H DID [ Upstream commit a5a1804332afc7035d5c5b880548262e81d796bc ] Add Nova Lake H device id. Cc: stable Co-developed-by: Tomas Winkler Signed-off-by: Tomas Winkler Signed-off-by: Alexander Usyskin Link: https://patch.msgid.link/20260405141758.1634556-1-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 09033be12a82b796a4c3b8f1ef8860bda26b745b Author: Alexander Usyskin Date: Tue Apr 28 06:12:04 2026 -0400 mei: me: use PCI_DEVICE_DATA macro [ Upstream commit 9e7a2409ecf4d411b7cc91615b08f6a7576f0aaa ] Drop old local MEI_PCI_DEVICE macro and use common PCI_DEVICE_DATA instead. Update defines to adhere to current naming convention. Suggested-by: Andy Shevchenko Reviewed-by: Andy Shevchenko Signed-off-by: Alexander Usyskin Link: https://patch.msgid.link/20260201094358.1440593-2-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: a5a1804332af ("mei: me: add nova lake point H DID") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 38f113f81d3f0adc658a4475dd3ecaec985e21d3 Author: Alistair Popple Date: Tue Apr 28 10:31:11 2026 -0400 lib: test_hmm: evict device pages on file close to avoid use-after-free [ Upstream commit 744dd97752ef1076a8d8672bb0d8aa2c7abc1144 ] Patch series "Minor hmm_test fixes and cleanups". Two bugfixes a cleanup for the HMM kernel selftests. These were mostly reported by Zenghui Yu with special thanks to Lorenzo for analysing and pointing out the problems. This patch (of 3): When dmirror_fops_release() is called it frees the dmirror struct but doesn't migrate device private pages back to system memory first. This leaves those pages with a dangling zone_device_data pointer to the freed dmirror. If a subsequent fault occurs on those pages (eg. during coredump) the dmirror_devmem_fault() callback dereferences the stale pointer causing a kernel panic. This was reported [1] when running mm/ksft_hmm.sh on arm64, where a test failure triggered SIGABRT and the resulting coredump walked the VMAs faulting in the stale device private pages. Fix this by calling dmirror_device_evict_chunk() for each devmem chunk in dmirror_fops_release() to migrate all device private pages back to system memory before freeing the dmirror struct. The function is moved earlier in the file to avoid a forward declaration. Link: https://lore.kernel.org/20260331063445.3551404-1-apopple@nvidia.com Link: https://lore.kernel.org/20260331063445.3551404-2-apopple@nvidia.com Fixes: b2ef9f5a5cb3 ("mm/hmm/test: add selftest driver for HMM") Signed-off-by: Alistair Popple Reported-by: Zenghui Yu Closes: https://lore.kernel.org/linux-mm/8bd0396a-8997-4d2e-a13f-5aac033083d7@linux.dev/ Reviewed-by: Balbir Singh Tested-by: Zenghui Yu Cc: David Hildenbrand Cc: Jason Gunthorpe Cc: Leon Romanovsky Cc: Liam Howlett Cc: Lorenzo Stoakes (Oracle) Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Zenghui Yu Cc: Matthew Brost Cc: Signed-off-by: Andrew Morton [ kept the existing simpler `dmirror_device_evict_chunk()` body instead of the upstream compound-folio version ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1e67c82fb7781d6af2ff999ec206515820bd9457 Author: Ryan Roberts Date: Tue Apr 28 10:32:38 2026 -0400 arm64: mm: Fix rodata=full block mapping support for realm guests [ Upstream commit f12b435de2f2bb09ce406467020181ada528844c ] Commit a166563e7ec37 ("arm64: mm: support large block mapping when rodata=full") enabled the linear map to be mapped by block/cont while still allowing granular permission changes on BBML2_NOABORT systems by lazily splitting the live mappings. This mechanism was intended to be usable by realm guests since they need to dynamically share dma buffers with the host by "decrypting" them - which for Arm CCA, means marking them as shared in the page tables. However, it turns out that the mechanism was failing for realm guests because realms need to share their dma buffers (via __set_memory_enc_dec()) much earlier during boot than split_kernel_leaf_mapping() was able to handle. The report linked below showed that GIC's ITS was one such user. But during the investigation I found other callsites that could not meet the split_kernel_leaf_mapping() constraints. The problem is that we block map the linear map based on the boot CPU supporting BBML2_NOABORT, then check that all the other CPUs support it too when finalizing the caps. If they don't, then we stop_machine() and split to ptes. For safety, split_kernel_leaf_mapping() previously wouldn't permit splitting until after the caps were finalized. That ensured that if any secondary cpus were running that didn't support BBML2_NOABORT, we wouldn't risk breaking them. I've fix this problem by reducing the black-out window where we refuse to split; there are now 2 windows. The first is from T0 until the page allocator is inititialized. Splitting allocates memory for the page allocator so it must be in use. The second covers the period between starting to online the secondary cpus until the system caps are finalized (this is a very small window). All of the problematic callers are calling __set_memory_enc_dec() before the secondary cpus come online, so this solves the problem. However, one of these callers, swiotlb_update_mem_attributes(), was trying to split before the page allocator was initialized. So I have moved this call from arch_mm_preinit() to mem_init(), which solves the ordering issue. I've added warnings and return an error if any attempt is made to split in the black-out windows. Note there are other issues which prevent booting all the way to user space, which will be fixed in subsequent patches. Reported-by: Jinjiang Tu Closes: https://lore.kernel.org/all/0b2a4ae5-fc51-4d77-b177-b2e9db74f11d@huawei.com/ Fixes: a166563e7ec3 ("arm64: mm: support large block mapping when rodata=full") Cc: stable@vger.kernel.org Reviewed-by: Kevin Brodsky Signed-off-by: Ryan Roberts Reviewed-by: Suzuki K Poulose Tested-by: Suzuki K Poulose Signed-off-by: Catalin Marinas [ adjusted context to use `__ASSEMBLY__` instead of `__ASSEMBLER__` ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5e07126d7ab8f22ae88dffda7498bf63e75ec676 Author: Kevin Brodsky Date: Tue Apr 28 10:32:37 2026 -0400 arm64: mm: Simplify check in arch_kfence_init_pool() [ Upstream commit b7737c38e7cb611c2fbd87af3b09afeb92c96fe7 ] TL;DR: checking force_pte_mapping() in arch_kfence_init_pool() is sufficient Commit ce2b3a50ad92 ("arm64: mm: Don't sleep in split_kernel_leaf_mapping() when in atomic context") recently added an arm64 implementation of arch_kfence_init_pool() to ensure that the KFENCE pool is PTE-mapped. Assuming that the pool was not initialised early, block splitting is necessary if the linear mapping is not fully PTE-mapped, in other words if force_pte_mapping() is false. arch_kfence_init_pool() currently makes another check: whether BBML2-noabort is supported, i.e. whether we are *able* to split block mappings. This check is however unnecessary, because force_pte_mapping() is always true if KFENCE is enabled and BBML2-noabort is not supported. This must be the case by design, since KFENCE requires PTE-mapped pages in all cases. We can therefore remove that check. The situation is different in split_kernel_leaf_mapping(), as that function is called unconditionally regardless of the configuration. If BBML2-noabort is not supported, it cannot do anything and bails out. If force_pte_mapping() is true, there is nothing to do and it also bails out, but these are independent checks. Commit 53357f14f924 ("arm64: mm: Tidy up force_pte_mapping()") grouped these checks into a helper, split_leaf_mapping_possible(). This isn't so helpful as only split_kernel_leaf_mapping() should check both. Revert the parts of that commit that introduced the helper, reintroducing the more accurate comments in split_kernel_leaf_mapping(). Signed-off-by: Kevin Brodsky Reviewed-by: Ryan Roberts Signed-off-by: Catalin Marinas Stable-dep-of: f12b435de2f2 ("arm64: mm: Fix rodata=full block mapping support for realm guests") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6f977b0472f700e4bcb981342ceacf2f1b1a3671 Author: Anthony Yznaga Date: Tue Apr 28 16:05:33 2026 -0400 mm: prevent droppable mappings from being locked [ Upstream commit d239462787b072c78eb19fc1f155c3d411256282 ] Droppable mappings must not be lockable. There is a check for VMAs with VM_DROPPABLE set in mlock_fixup() along with checks for other types of unlockable VMAs which ensures this when calling mlock()/mlock2(). For mlockall(MCL_FUTURE), the check for unlockable VMAs is different. In apply_mlockall_flags(), if the flags parameter has MCL_FUTURE set, the current task's mm's default VMA flag field mm->def_flags has VM_LOCKED applied to it. VM_LOCKONFAULT is also applied if MCL_ONFAULT is also set. When these flags are set as default in this manner they are cleared in __mmap_complete() for new mappings that do not support mlock. A check for VM_DROPPABLE in __mmap_complete() is missing resulting in droppable mappings created with VM_LOCKED set. To fix this and reduce that chance of similar bugs in the future, introduce and use vma_supports_mlock(). Link: https://lkml.kernel.org/r/20260310155821.17869-1-anthony.yznaga@oracle.com Fixes: 9651fcedf7b9 ("mm: add MAP_DROPPABLE for designating always lazily freeable mappings") Signed-off-by: Anthony Yznaga Suggested-by: David Hildenbrand Acked-by: David Hildenbrand (Arm) Reviewed-by: Pedro Falcato Reviewed-by: Lorenzo Stoakes (Oracle) Tested-by: Lorenzo Stoakes (Oracle) Cc: Jann Horn Cc: Jason A. Donenfeld Cc: Liam Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton [ added const to is_vm_hugetlb_page and stubbed vma_supports_mlock in vma_internal.h instead of the split-out stubs.h ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bbc4bfae9e432af8afd8ca38a01b6dd95b334029 Author: Andrea Mayer Date: Sat Apr 18 18:28:38 2026 +0200 seg6: fix seg6 lwtunnel output redirect for L2 reduced encap mode commit ade67d5f588832c7ba131aadd4215a94ce0a15c8 upstream. When SEG6_IPTUN_MODE_L2ENCAP_RED (L2ENCAP_RED) was introduced, the condition in seg6_build_state() that excludes L2 encap modes from setting LWTUNNEL_STATE_OUTPUT_REDIRECT was not updated to account for the new mode. As a consequence, L2ENCAP_RED routes incorrectly trigger seg6_output() on the output path, where the packet is silently dropped because skb_mac_header_was_set() fails on L3 packets. Extend the check to also exclude L2ENCAP_RED, consistent with L2ENCAP. Fixes: 13f0296be8ec ("seg6: add support for SRv6 H.L2Encaps.Red behavior") Cc: stable@vger.kernel.org Signed-off-by: Andrea Mayer Reviewed-by: Justin Iurman Link: https://patch.msgid.link/20260418162838.31979-1-andrea.mayer@uniroma2.it Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 13e550fbfccdb311e76ec96892dfe35f0dba0657 Author: Yang Xiuwei Date: Mon Mar 30 09:49:52 2026 +0800 scsi: sd: fix missing put_disk() when device_add(&disk_dev) fails commit 1e111c4b3a726df1254670a5cc4868cedb946d37 upstream. If device_add(&sdkp->disk_dev) fails, put_device() runs scsi_disk_release(), which frees the scsi_disk but leaves the gendisk referenced. The device_add_disk() error path in sd_probe() calls put_disk(gd); call put_disk(gd) here to mirror that cleanup. Fixes: 265dfe8ebbab ("scsi: sd: Free scsi_disk device via put_device()") Cc: stable@vger.kernel.org Reviewed-by: John Garry Signed-off-by: Yang Xiuwei Link: https://patch.msgid.link/20260330014952.152776-1-yangxiuwei@kylinos.cn Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 9da6e314ea5fa246b8c1906b7422537175968f8e Author: Andrea Righi Date: Wed Mar 25 22:21:00 2026 +0100 sched_ext: Documentation: Clarify ops.dispatch() role in task lifecycle commit a313357a346839d40b3a4dec393c71bf30cbb34c upstream. ops.dispatch() is invoked when a CPU becomes available. This can occur when a task voluntarily yields the CPU, exhausts its time slice, or is preempted for other reasons. If the task is still runnable, refilling its time slice in ops.dispatch() (either by the BPF scheduler or the sched_ext core) allows it to continue running without triggering ops.stopping(). However, this behavior is not clearly reflected in the current task lifecycle diagram. Update the diagram to better represent this interaction. Fixes: 9465f44d2df2 ("sched_ext: Documentation: Clarify time slice handling in task lifecycle") Cc: stable@vger.kernel.org # v6.17+ Signed-off-by: Andrea Righi Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 43222ac484f93b3ec2d240a7575e1cedd31f5fa4 Author: David Howells Date: Wed Apr 22 17:14:34 2026 +0100 rxgk: Fix potential integer overflow in length check commit 6929350080f4da292d111a3b33e53138fee51cec upstream. Fix potential integer overflow in rxgk_extract_token() when checking the length of the ticket. Rather than rounding up the value to be tested (which might overflow), round down the size of the available data. Fixes: 2429a1976481 ("rxrpc: Fix untrusted unsigned subtract") Closes: https://sashiko.dev/#/patchset/20260408121252.2249051-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/20260422161438.2593376-6-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3fb7394a837740770f0d6b4b30567e60786a63f2 Author: Keenan Dong Date: Wed Apr 8 16:46:00 2026 +0800 rtmutex: Use waiter::task instead of current in remove_waiter() commit 3bfdc63936dd4773109b7b8c280c0f3b5ae7d349 upstream. remove_waiter() is used by the slowlock paths, but it is also used for proxy-lock rollback in rt_mutex_start_proxy_lock() when invoked from futex_requeue(). In the latter case waiter::task is not current, but remove_waiter() operates on current for the dequeue operation. That results in several problems: 1) the rbtree dequeue happens without waiter::task::pi_lock being held 2) the waiter task's pi_blocked_on state is not cleared, which leaves a dangling pointer primed for UAF around. 3) rt_mutex_adjust_prio_chain() operates on the wrong top priority waiter task Use waiter::task instead of current in all related operations in remove_waiter() to cure those problems. [ tglx: Fixup rt_mutex_adjust_prio_chain(), add a comment and amend the changelog ] Fixes: 8161239a8bcc ("rtmutex: Simplify PI algorithm and make highest prio task get lock") Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Keenan Dong Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit f1af27cec07a9fd0847166bdb23c99e86b05bfdc Author: Tobias Gaertner Date: Sun Mar 29 04:17:03 2026 -0700 ntfs3: fix integer overflow in run_unpack() volume boundary check commit 984a415f019536ea2d24de9010744e5302a9a948 upstream. The volume boundary check `lcn + len > sbi->used.bitmap.nbits` uses raw addition which can wrap around for large lcn and len values, bypassing the validation. Use check_add_overflow() as is already done for the adjacent prev_lcn + dlcn and vcn64 + len checks added by commit 3ac37e100385 ("ntfs3: Fix integer overflow in run_unpack()"). Found by fuzzing with a source-patched harness (LibAFL + QEMU). Fixes: 82cae269cfa95 ("fs/ntfs3: Add initialization of super block") Cc: stable@vger.kernel.org Signed-off-by: Tobias Gaertner Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit d3012690a7065d9ca86521a525ad11e8af491d45 Author: Tobias Gaertner Date: Sun Mar 29 04:17:02 2026 -0700 ntfs3: add buffer boundary checks to run_unpack() commit b62567bca47408e6739dee75f02a2113548af875 upstream. run_unpack() checks `run_buf < run_last` at the top of the while loop but then reads size_size and offset_size bytes via run_unpack_s64() without verifying they fit within the remaining buffer. A crafted NTFS image with truncated run data in an MFT attribute triggers an OOB heap read of up to 15 bytes when the filesystem is mounted. Add boundary checks before each run_unpack_s64() call to ensure the declared field size does not exceed the remaining buffer. Found by fuzzing with a source-patched harness (LibAFL + QEMU). Fixes: 82cae269cfa95 ("fs/ntfs3: Add initialization of super block") Cc: stable@vger.kernel.org Signed-off-by: Tobias Gaertner Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit 83e31039e0d7f779f059a7873a8afc6fbe2ee6c3 Author: Tushar Sariya Date: Sat Apr 4 11:58:03 2026 -0230 NFSv4.1: Apply session size limits on clone path commit 8c787b286f39c7584440b97b92f87cbe934c13ff upstream. nfs4_clone_server() builds a child nfs_server for same-server automounted submounts but never calls nfs4_session_limit_rwsize() or nfs4_session_limit_xasize() after nfs_clone_server(). This means the child mount can end up with rsize/wsize values that exceed the negotiated session channel limits, causing NFS4ERR_REQ_TOO_BIG and EIO on servers that enforce tight max_request_size budgets. Top-level mounts go through nfs4_server_common_setup() which calls these limiters after nfs_probe_server(). Apply the same clamping on the clone path for consistency. Fixes: 2b092175f5e3 ("NFS: Fix inheritance of the block sizes when automounting") Cc: stable@vger.kernel.org Signed-off-by: Tushar Sariya Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit fc8d81f189f080ab6679f6c1b825319536905230 Author: Steven Rostedt Date: Mon Apr 20 14:24:26 2026 -0400 ktest: Fix the month in the name of the failure directory commit 768059ede35f197575a38b10797b52402d9d4d2f upstream. The Perl localtime() function returns the month starting at 0 not 1. This caused the date produced to create the directory for saving files of a failed run to have the month off by one. machine-test-useconfig-fail-20260314073628 The above happened in April, not March. The correct name should have been: machine-test-useconfig-fail-20260414073628 This was somewhat confusing. Cc: stable@vger.kernel.org Cc: John 'Warthog9' Hawley Link: https://patch.msgid.link/20260420142426.33ad0293@fedora Fixes: 7faafbd69639b ("ktest: Add open and close console and start stop monitor") Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 9f4ba5966c7816fb8d2e13c3c16491d5b95505d9 Author: Chen Zhao Date: Sun Apr 5 18:44:55 2026 +0300 IB/core: Fix zero dmac race in neighbor resolution commit 5e6de34d82b49cab9d8a42063e9cd0f22a4f31e5 upstream. dst_fetch_ha() checks nud_state without holding the neighbor lock, then copies ha under the seqlock. A race in __neigh_update() where nud_state is set to NUD_REACHABLE before ha is written allows dst_fetch_ha() to read a zero MAC address while the seqlock reports no concurrent writer. netevent_callback amplifies this by waking ALL pending addr_req workers when ANY neighbor becomes NUD_VALID. At scale (N peers resolving ARP concurrently), the hit probability scales as N^2, making it near-certain for large RDMA workloads. N(A): neigh_update(A) W(A): addr_resolve(A) | [sleep] | write_lock_bh(&A->lock) | | A->nud_state = NUD_REACHABLE | | // A->ha is still 0 | | [woken by netevent_cb() of | another neighbour] | | dst_fetch_ha(A) | | A->nud_state & NUD_VALID | | read_seqbegin(&A->ha_lock) | | snapshot = A->ha /* 0 */ | | read_seqretry(&A->ha_lock) | | return snapshot | seqlock(&A->ha_lock) | A->ha = mac_A /* too late */ | sequnlock(&A->ha_lock) | write_unlock_bh(&A->lock) The incorrect/zero mac is read and programmed in the device QP while it was not yet updated. This causes silent packet loss and eventual RETRY_EXC_ERR. Fix by holding the neighbor read lock across the nud_state check and ha copy in dst_fetch_ha(), ensuring it synchronizes with __neigh_update() which is updating while holding the write lock. Cc: stable@vger.kernel.org Fixes: 92ebb6a0a13a ("IB/cm: Remove now useless rcu_lock in dst_fetch_ha") Link: https://patch.msgid.link/r/20260405-fix-dmac-race-v1-1-cfa1ec2ce54a@nvidia.com Signed-off-by: Chen Zhao Reviewed-by: Parav Pandit Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 4db061a405435c35c2be9087ea3958eed95bb42a Author: David Carlier Date: Fri Apr 17 06:54:08 2026 +0100 gtp: disable BH before calling udp_tunnel_xmit_skb() commit 5638504a2aa9e1b9d72af9060df1a160cce2d379 upstream. gtp_genl_send_echo_req() runs as a generic netlink doit handler in process context with BH not disabled. It calls udp_tunnel_xmit_skb(), which eventually invokes iptunnel_xmit() — that uses __this_cpu_inc/dec on softnet_data.xmit.recursion to track the tunnel xmit recursion level. Without local_bh_disable(), the task may migrate between dev_xmit_recursion_inc() and dev_xmit_recursion_dec(), breaking the per-CPU counter pairing. The result is stale or negative recursion levels that can later produce false-positive SKB_DROP_REASON_RECURSION_LIMIT drops on either CPU. The other udp_tunnel_xmit_skb() call sites in gtp.c are unaffected: the data path runs under ndo_start_xmit and the echo response handlers run from the UDP encap rx softirq, both with BH already disabled. Fix it by disabling BH around the udp_tunnel_xmit_skb() call, mirroring commit 2cd7e6971fc2 ("sctp: disable BH before calling udp_tunnel_xmit_skb()"). Fixes: 6f1a9140ecda ("net: add xmit recursion limit to tunnel xmit functions") Cc: stable@vger.kernel.org Signed-off-by: David Carlier Link: https://patch.msgid.link/20260417055408.4667-1-devnexen@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b91e535f208c48a5e7464f1aa38338a30e7912df Author: Max Kellermann Date: Fri Mar 27 17:23:08 2026 +0100 ceph: only d_add() negative dentries when they are unhashed commit 803447f93d75ab6e40c85e6d12b5630d281d70d6 upstream. Ceph can call d_add(dentry, NULL) on a negative dentry that is already present in the primary dcache hash. In the current VFS that is not safe. d_add() goes through __d_add() to __d_rehash(), which unconditionally reinserts dentry->d_hash into the hlist_bl bucket. If the dentry is already hashed, reinserting the same node can corrupt the bucket, including creating a self-loop. Once that happens, __d_lookup() can spin forever in the hlist_bl walk, typically looping only on the d_name.hash mismatch check and eventually triggering RCU stall reports like this one: rcu: INFO: rcu_sched self-detected stall on CPU rcu: 87-....: (2100 ticks this GP) idle=3a4c/1/0x4000000000000000 softirq=25003319/25003319 fqs=829 rcu: (t=2101 jiffies g=79058445 q=698988 ncpus=192) CPU: 87 UID: 2952868916 PID: 3933303 Comm: php-cgi8.3 Not tainted 6.18.17-i1-amd #950 NONE Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.6 09/22/2023 RIP: 0010:__d_lookup+0x46/0xb0 Code: c1 e8 07 48 8d 04 c2 48 8b 00 49 89 fc 49 89 f5 48 89 c3 48 83 e3 fe 48 83 f8 01 77 0f eb 2d 0f 1f 44 00 00 48 8b 1b 48 85 db <74> 20 39 6b 18 75 f3 48 8d 7b 78 e8 ba 85 d0 00 4c 39 63 10 74 1f RSP: 0018:ff745a70c8253898 EFLAGS: 00000282 RAX: ff26e470054cb208 RBX: ff26e470054cb208 RCX: 000000006e958966 RDX: ff26e48267340000 RSI: ff745a70c82539b0 RDI: ff26e458f74655c0 RBP: 000000006e958966 R08: 0000000000000180 R09: 9cd08d909b919a89 R10: ff26e458f74655c0 R11: 0000000000000000 R12: ff26e458f74655c0 R13: ff745a70c82539b0 R14: d0d0d0d0d0d0d0d0 R15: 2f2f2f2f2f2f2f2f FS: 00007f5770896980(0000) GS:ff26e482c5d88000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5764de50c0 CR3: 000000a72abb5001 CR4: 0000000000771ef0 PKRU: 55555554 Call Trace: lookup_fast+0x9f/0x100 walk_component+0x1f/0x150 link_path_walk+0x20e/0x3d0 path_lookupat+0x68/0x180 filename_lookup+0xdc/0x1e0 vfs_statx+0x6c/0x140 vfs_fstatat+0x67/0xa0 __do_sys_newfstatat+0x24/0x60 do_syscall_64+0x6a/0x230 entry_SYSCALL_64_after_hwframe+0x76/0x7e This is reachable with reused cached negative dentries. A Ceph lookup or atomic_open can be handed a negative dentry that is already hashed, and fs/ceph/dir.c then hits one of two paths that incorrectly assume "negative" also means "unhashed": - ceph_finish_lookup(): MDS reply is -ENOENT with no trace -> d_add(dentry, NULL) - ceph_lookup(): local ENOENT fast path for a complete directory with shared caps -> d_add(dentry, NULL) Both paths can therefore re-add an already-hashed negative dentry. Ceph already uses the correct pattern elsewhere: ceph_fill_trace() only calls d_add(dn, NULL) for a negative null-dentry reply when d_unhashed(dn) is true. Fix both fs/ceph/dir.c sites the same way: only call d_add() for a negative dentry when it is actually unhashed. If the negative dentry is already hashed, leave it in place and reuse it as-is. This preserves the existing behavior for unhashed dentries while avoiding d_hash list corruption for reused hashed negatives. Cc: stable@vger.kernel.org Fixes: 2817b000b02c ("ceph: directory operations") Signed-off-by: Max Kellermann Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 87c99a50e0fdc68a5b9b52a94d49452cd3ff02ca Author: Junrui Luo Date: Sun Mar 1 21:10:58 2026 +0800 dm mirror: fix integer overflow in create_dirty_log() commit 4c788c6f921b22f9b6c3f316c4a071c05683e7de upstream. The argument count calculation in create_dirty_log() performs `*args_used = 2 + param_count` before validating against argc. When a user provides a param_count close to UINT_MAX via the device mapper table string, this unsigned addition wraps around to a small value, causing the subsequent `argc < *args_used` check to be bypassed. The overflowed param_count is then passed as argc to dm_dirty_log_create(), where it can cause out-of-bounds reads on the argv array. Fix by comparing param_count against argc - 2 before performing the addition, following the same pattern used by parse_features() in the same file. Since argc >= 2 is already guaranteed, the subtraction is safe. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Yuhao Jiang Signed-off-by: Junrui Luo Reviewed-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit a616126cb0806c1f4f65302dcc189e2d0fcace3c Author: Gustavo A. R. Silva Date: Tue Mar 17 17:40:02 2026 -0600 crypto: nx - Fix packed layout in struct nx842_crypto_header commit b0bfa49c03e3c65737eafa73d8a698eaf55379a6 upstream. struct nx842_crypto_header is declared with the __packed attribute, however the fields grouped with struct_group_tagged() were not packed. This caused the grouped header portion of the structure to lose the packed layout guarantees of the containing structure. Fix this by replacing struct_group_tagged() with __struct_group(..., ..., __packed, ...) so the grouped fields are packed, and the original layout is preserved, restoring the intended packed layout of the structure. Before changes: struct nx842_crypto_header { union { struct { __be16 magic; /* 0 2 */ __be16 ignore; /* 2 2 */ u8 groups; /* 4 1 */ }; /* 0 6 */ struct nx842_crypto_header_hdr hdr; /* 0 6 */ }; /* 0 6 */ struct nx842_crypto_header_group group[]; /* 6 0 */ /* size: 6, cachelines: 1, members: 2 */ /* last cacheline: 6 bytes */ } __attribute__((__packed__)); After changes: struct nx842_crypto_header { union { struct { __be16 magic; /* 0 2 */ __be16 ignore; /* 2 2 */ u8 groups; /* 4 1 */ } __attribute__((__packed__)); /* 0 5 */ struct nx842_crypto_header_hdr hdr; /* 0 5 */ }; /* 0 5 */ struct nx842_crypto_header_group group[]; /* 5 0 */ /* size: 5, cachelines: 1, members: 2 */ /* last cacheline: 5 bytes */ } __attribute__((__packed__)); Fixes: 1e6b251ce175 ("crypto: nx - Avoid -Wflex-array-member-not-at-end warning") Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva Reviewed-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 354a27e28447d919058cac2ed38e0d2ce78ba6a1 Author: Thorsten Blum Date: Wed Mar 11 16:56:49 2026 +0100 crypto: nx - fix context leak in nx842_crypto_free_ctx commit 344e6a4f7ff4756b9b3f75e0eb7eaec297e35540 upstream. Since the scomp conversion, nx842_crypto_alloc_ctx() allocates the context separately, but nx842_crypto_free_ctx() never releases it. Add the missing kfree(ctx) to nx842_crypto_free_ctx(), and reuse nx842_crypto_free_ctx() in the allocation error path. Fixes: 980b5705f4e7 ("crypto: nx - Migrate to scomp API") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Reviewed-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 5c07962fed66e1238fad7635fa150570bd38b4c5 Author: Thorsten Blum Date: Wed Mar 11 16:56:47 2026 +0100 crypto: nx - fix bounce buffer leaks in nx842_crypto_{alloc,free}_ctx commit adb3faf2db1a66d0f015b44ac909a32dfc7f2f9c upstream. The bounce buffers are allocated with __get_free_pages() using BOUNCE_BUFFER_ORDER (order 2 = 4 pages), but both the allocation error path and nx842_crypto_free_ctx() release the buffers with free_page(). Use free_pages() with the matching order instead. Fixes: ed70b479c2c0 ("crypto: nx - add hardware 842 crypto comp alg") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 2ae365e32998409acef0a02f2905b19184c9856d Author: Thorsten Blum Date: Fri Feb 20 14:31:36 2026 +0100 crypto: atmel-sha204a - Fix uninitialized data access on OTP read error commit de4e66b763d1e81188cb2803ec109466582fc9d1 upstream. Return early if atmel_i2c_send_receive() fails to avoid checking potentially uninitialized data in 'cmd.data'. Cc: stable@vger.kernel.org Fixes: e05ce444e9e5 ("crypto: atmel-sha204a - add reading from otp zone") Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 1193c12126d39bf986a5a9214827b73707b193ab Author: Thorsten Blum Date: Sat Mar 14 20:36:29 2026 +0100 crypto: atmel-sha204a - Fix potential UAF and memory leak in remove path commit bab1adf3b87e4bfac92c4f5963c63db434d561c1 upstream. Unregister the hwrng to prevent new ->read() calls and flush the Atmel I2C workqueue before teardown to prevent a potential UAF if a queued callback runs while the device is being removed. Drop the early return to ensure sysfs entries are removed and ->hwrng.priv is freed, preventing a memory leak. Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 64ea9dbf4c779e2af2c47844d63280f8e1fe52e3 Author: Thorsten Blum Date: Sun Feb 15 21:51:53 2026 +0100 crypto: atmel-sha204a - Fix error codes in OTP reads commit 094c276da6a0d4971c3faae09a36b51d096659b2 upstream. Return -EINVAL from atmel_i2c_init_read_otp_cmd() on invalid addresses instead of -1. Since the OTP zone is accessed in 4-byte blocks, valid addresses range from 0 to OTP_ZONE_SIZE / 4 - 1. Fix the bounds check accordingly. In atmel_sha204a_otp_read(), propagate the actual error code from atmel_i2c_init_read_otp_cmd() instead of -1. Also, return -EIO instead of -EINVAL when the device is not ready. Cc: stable@vger.kernel.org Fixes: e05ce444e9e5 ("crypto: atmel-sha204a - add reading from otp zone") Signed-off-by: Thorsten Blum Reviewed-by: Lothar Rubusch Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 863d11b3927703ad95077c81a8a6489c5c7872f7 Author: Thorsten Blum Date: Sat Mar 7 16:31:10 2026 +0100 crypto: atmel-tdes - fix DMA sync direction commit c8a9a647532f5c2a04180352693215e24e9dba03 upstream. Before DMA output is consumed by the CPU, ->dma_addr_out must be synced with dma_sync_single_for_cpu() instead of dma_sync_single_for_device(). Using the wrong direction can return stale cache data on non-coherent platforms. Fixes: 13802005d8f2 ("crypto: atmel - add Atmel DES/TDES driver") Fixes: 1f858040c2f7 ("crypto: atmel-tdes - add support for latest release of the IP (0x700)") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 910f335786a0a0f0b46c3c8c19a13d25cb4454b6 Author: Haoxiang Li Date: Mon Mar 30 11:34:02 2026 +0800 crypto: ccree - fix a memory leak in cc_mac_digest() commit 02c64052fad03699b9c6d1df2f9b444d17e4ac50 upstream. Add cc_unmap_result() if cc_map_hash_request_final() fails to prevent potential memory leak. Fixes: 63893811b0fc ("crypto: ccree - add ahash support") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 808685bfd124d9666b49ac53e735744bc78123b6 Author: Thomas Fourier Date: Mon Mar 30 17:19:32 2026 +0200 crypto: hisilicon - Fix dma_unmap_single() direction commit 1ee57ab93b75eb59f426aef37b5498a7ffc28278 upstream. The direction used to map the buffer skreq->iv is DMA_TO_DEVICE but it is unmapped with direction DMA_BIDIRECTIONAL in the error path. Change the unmap to match the mapping. Fixes: 915e4e8413da ("crypto: hisilicon - SEC security accelerator driver") Cc: Signed-off-by: Thomas Fourier Reviewed-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 9c032781c2b1fbe49ba941ddb208b030035f5902 Author: Thorsten Blum Date: Fri Feb 20 15:03:13 2026 +0100 crypto: atmel-ecc - Release client on allocation failure commit 095d50008d55d13f8fcf1bbeb7c6eba51779bc85 upstream. Call atmel_ecc_i2c_client_free() to release the I2C client reserved by atmel_ecc_i2c_client_alloc() when crypto_alloc_kpp() fails. Otherwise ->tfm_count will be out of sync. Fixes: 11105693fa05 ("crypto: atmel-ecc - introduce Microchip / Atmel ECC driver") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 61516b4a5b2647dc3f8f67b5dffaf038be997511 Author: Thorsten Blum Date: Wed Mar 11 03:07:35 2026 +0100 crypto: atmel-aes - Fix 3-page memory leak in atmel_aes_buff_cleanup commit 3fcfff4ed35f963380a68741bcd52742baff7f76 upstream. atmel_aes_buff_init() allocates 4 pages using __get_free_pages() with ATMEL_AES_BUFFER_ORDER, but atmel_aes_buff_cleanup() frees only the first page using free_page(), leaking the remaining 3 pages. Use free_pages() with ATMEL_AES_BUFFER_ORDER to fix the memory leak. Fixes: bbe628ed897d ("crypto: atmel-aes - improve performances of data transfer") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 4d713333dd32110245f8c54e101b0b9589fd2d28 Author: Eric Biggers Date: Wed Feb 18 13:34:49 2026 -0800 crypto: arm64/aes - Fix 32-bit aes_mac_update() arg treated as 64-bit commit f8f08d7cc43237e91e3aedf7b67d015d24c38fcc upstream. Since the 'enc_after' argument to neon_aes_mac_update() and ce_aes_mac_update() has type 'int', it needs to be accessed using the corresponding 32-bit register, not the 64-bit register. The upper half of the corresponding 64-bit register may contain garbage. Fixes: 4860620da7e5 ("crypto: arm64/aes - add NEON/Crypto Extensions CBCMAC/CMAC/XCBC driver") Cc: stable@vger.kernel.org Reviewed-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260218213501.136844-4-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 343a5bf68a8ff9affcf2b70677ea4cf40c195ee4 Author: Giovanni Cabiddu Date: Thu Apr 16 18:07:00 2026 +0100 crypto: acomp - fix wrong pointer stored by acomp_save_req() commit d7e20b9bd6c990773cf0c09e2642250b8a70263d upstream. acomp_save_req() stores &req->chain in req->base.data. When acomp_reqchain_done() is invoked on asynchronous completion, it receives &req->chain as the data argument but casts it directly to struct acomp_req. Since data points to the chain member, all subsequent field accesses are at a wrong offset, resulting in memory corruption. The issue occurs when an asynchronous hardware implementation, such as the QAT driver, completes a request that uses the DMA virtual address interface (e.g. acomp_request_set_src_dma()). This combination causes crypto_acomp_compress() to enter the acomp_do_req_chain() path, which sets acomp_reqchain_done() as the completion callback via acomp_save_req(). With KASAN enabled, this manifests as a general protection fault in acomp_reqchain_done(): general protection fault, probably for non-canonical address 0xe000040000000000 KASAN: probably user-memory-access in range [0x0000400000000000-0x0000400000000007] RIP: 0010:acomp_reqchain_done+0x15b/0x4e0 Call Trace: qat_comp_alg_callback+0x5d/0xa0 [intel_qat] adf_ring_response_handler+0x376/0x8b0 [intel_qat] adf_response_handler+0x60/0x170 [intel_qat] tasklet_action_common+0x223/0x820 handle_softirqs+0x1ab/0x640 Fix this by storing the request itself in req->base.data instead of &req->chain, so that acomp_reqchain_done() receives the correct pointer. Simplify acomp_restore_req() accordingly to access req->chain directly. Fixes: 64929fe8c0a4 ("crypto: acomp - Remove request chaining") Cc: stable@vger.kernel.org Signed-off-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit c524c124e3094d2de12235a513854c03d06a2b58 Author: Johan Hovold Date: Fri Mar 27 11:45:20 2026 +0100 can: ucan: fix devres lifetime commit fed4626501c871890da287bec62a96e52da1af89 upstream. USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the control message buffer lifetime so that it is released on driver unbind. Fixes: 9f2d3eae88d2 ("can: ucan: add driver for Theobroma Systems UCAN devices") Cc: stable@vger.kernel.org # 4.19 Cc: Jakob Unterwurzacher Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260327104520.1310158-1-johan@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 1656698656f61957355998d7eb5e60f00769d33a Author: Qiang Yu Date: Tue Mar 3 01:02:13 2026 -0800 bus: mhi: host: pci_generic: Switch to async power up to avoid boot delays commit cfdb41adf1c2822ad1b1791d4d11093edb5582b6 upstream. Some modem devices can take significant time (up to 20 secs for sdx75) to enter mission mode during initialization. Currently, mhi_sync_power_up() waits for this entire process to complete, blocking other driver probes and delaying system boot. Switch to mhi_async_power_up() so probe can return immediately while MHI initialization continues in the background. This eliminates lengthy boot delays and allows other drivers to probe in parallel, improving overall system boot performance. Fixes: 5571519009d0 ("bus: mhi: host: pci_generic: Add SDX75 based modem support") Signed-off-by: Qiang Yu Signed-off-by: Manivannan Sadhasivam Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260303-b4-async_power_on-v2-1-d3db81eb457d@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit e08d75753db17aa943d7622f09d9c217b5bfd3b8 Author: Shuvam Pandey Date: Thu Apr 9 00:32:30 2026 +0545 Bluetooth: hci_event: fix potential UAF in SSP passkey handlers commit 85fa3512048793076eef658f66489112dcc91993 upstream. hci_conn lookup and field access must be covered by hdev lock in hci_user_passkey_notify_evt() and hci_keypress_notify_evt(), otherwise the connection can be freed concurrently. Extend the hci_dev_lock critical section to cover all conn usage in both handlers. Keep the existing keypress notification behavior unchanged by routing the early exits through a common unlock path. Fixes: 92a25256f142 ("Bluetooth: mgmt: Implement support for passkey notification") Cc: stable@vger.kernel.org Signed-off-by: Shuvam Pandey Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit b4339521bb4309dcf0468ce2aaf565e8cf43d295 Author: Cengiz Can Date: Tue Feb 10 11:17:14 2026 +0300 apparmor: use target task's context in apparmor_getprocattr() commit 4afc61702bdcc3b9b519749ef966cf762a6e7051 upstream. apparmor_getprocattr() incorrectly calls task_ctx(current) instead of task_ctx(task) when retrieving prev and exec attributes, returning the caller's labels rather than the target's. Fix by passing task to task_ctx(). The issue can be reproduced when a process with an onexec transition (e.g., configured by a container runtime) is inspected via /proc//attr/apparmor/exec. The reader's own value is returned instead of the target's. Reported-by: Qualys Security Advisory Fixes: 3b529a7600d8 ("apparmor: move task domain change info to task security") Cc: stable@vger.kernel.org Co-developed-by: Cengiz Can Signed-off-by: Cengiz Can Co-developed-by: John Johansen Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit b7a953374db91a911959e17e5020edbeab9ba8a1 Author: Brian Mak Date: Wed Mar 25 15:30:24 2026 -0700 mfd: core: Preserve OF node when ACPI handle is present commit caa5a5d44d8ae4fd13b744857d66c9313b712d1f upstream. Switch device_set_node to set_primary_fwnode, so that the ACPI fwnode does not overwrite the of_node with NULL. This allows MFD children with both OF nodes and ACPI handles to have OF nodes again. Cc: stable@vger.kernel.org Fixes: 51e3b257099d ("mfd: core: Make use of device_set_node()") Signed-off-by: Brian Mak Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20260325223024.35992-1-makb@juniper.net Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit e88827bb039904d323aa619d771ae4e54c5b1e2a Author: Yiyang Chen Date: Mon Mar 30 03:00:40 2026 +0800 taskstats: set version in TGID exit notifications commit 16c4f0211aaa1ec1422b11b59f64f1abe9009fc0 upstream. delay accounting started populating taskstats records with a valid version field via fill_pid() and fill_tgid(). Later, commit ad4ecbcba728 ("[PATCH] delay accounting taskstats interface send tgid once") changed the TGID exit path to send the cached signal->stats aggregate directly instead of building the outgoing record through fill_tgid(). Unlike fill_tgid(), fill_tgid_exit() only accumulates accounting data and never initializes stats->version. As a result, TGID exit notifications can reach userspace with version == 0 even though PID exit notifications and TASKSTATS_CMD_GET replies carry a valid taskstats version. This is easy to reproduce with `tools/accounting/getdelays.c`. I have a small follow-up patch for that tool which: 1. increases the receive buffer/message size so the pid+tgid combined exit notification is not dropped/truncated 2. prints `stats->version`. With that patch, the reproducer is: Terminal 1: ./getdelays -d -v -l -m 0 Terminal 2: taskset -c 0 python3 -c 'import threading,time; t=threading.Thread(target=time.sleep,args=(0.1,)); t.start(); t.join()' That produces both PID and TGID exit notifications for the same process. The PID exit record reports a valid taskstats version, while the TGID exit record reports `version 0`. This patch (of 2): Set stats->version = TASKSTATS_VERSION after copying the cached TGID aggregate into the outgoing netlink payload so all taskstats records are self-describing again. Link: https://lkml.kernel.org/r/ba83d934e59edd431b693607de573eb9ca059309.1774810498.git.cyyzero16@gmail.com Fixes: ad4ecbcba728 ("[PATCH] delay accounting taskstats interface send tgid once") Signed-off-by: Yiyang Chen Cc: Balbir Singh Cc: Dr. Thomas Orgis Cc: Fan Yu Cc: Wang Yaxin Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 83bb57635d7cbafde32f865b577ecfd969f02337 Author: Zhenzhong Wu Date: Wed Apr 22 10:45:53 2026 +0800 tcp: call sk_data_ready() after listener migration commit 3864c6ba1e041bc75342353a70fa2a2c6f909923 upstream. When inet_csk_listen_stop() migrates an established child socket from a closing listener to another socket in the same SO_REUSEPORT group, the target listener gets a new accept-queue entry via inet_csk_reqsk_queue_add(), but that path never notifies the target listener's waiters. A nonblocking accept() still works because it checks the queue directly, but poll()/epoll_wait() waiters and blocking accept() callers can also remain asleep indefinitely. Call READ_ONCE(nsk->sk_data_ready)(nsk) after a successful migration in inet_csk_listen_stop(). However, after inet_csk_reqsk_queue_add() succeeds, the ref acquired in reuseport_migrate_sock() is effectively transferred to nreq->rsk_listener. Another CPU can then dequeue nreq via accept() or listener shutdown, hit reqsk_put(), and drop that listener ref. Since listeners are SOCK_RCU_FREE, wrap the post-queue_add() dereferences of nsk in rcu_read_lock()/rcu_read_unlock(), which also covers the existing sock_net(nsk) access in that path. The reqsk_timer_handler() path does not need the same changes for two reasons: half-open requests become readable only after the final ACK, where tcp_child_process() already wakes the listener; and once nreq is visible via inet_ehash_insert(), the success path no longer touches nsk directly. Fixes: 54b92e841937 ("tcp: Migrate TCP_ESTABLISHED/TCP_SYN_RECV sockets in accept queues.") Cc: stable@vger.kernel.org Suggested-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Signed-off-by: Zhenzhong Wu Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260422024554.130346-2-jt26wzz@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 69c4d137b22d14a6fd7f8bd2f7689ff027eef41a Author: Yi Cong Date: Fri Mar 6 15:16:27 2026 +0800 wifi: rtl8xxxu: fix potential use of uninitialized value commit f8a2fc809bfeb49130709b31a4d357a049f28547 upstream. The local variables 'mcs' and 'nss' in rtl8xxxu_update_ra_report() are passed to rtl8xxxu_desc_to_mcsrate() as output parameters. If the helper function encounters an unhandled rate index, it may return without setting these values, leading to the use of uninitialized stack data. Remove the helper rtl8xxxu_desc_to_mcsrate() and inline the logic into rtl8xxxu_update_ra_report(). This fixes the use of uninitialized 'mcs' and 'nss' variables for legacy rates. The new implementation explicitly handles: - Legacy rates: Set bitrate only. - HT rates (MCS0-15): Set MCS flags, index, and NSS (1 or 2) directly. - Invalid rates: Return early. Fixes: 7de16123d9e2 ("wifi: rtl8xxxu: Introduce rtl8xxxu_update_ra_report") Cc: stable@vger.kernel.org Suggested-by: Ping-Ke Shih Signed-off-by: Yi Cong Link: https://lore.kernel.org/all/96e31963da0c42dcb52ce44f818963d7@realtek.com/ Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260306071627.56501-1-cong.yi@linux.dev Signed-off-by: Greg Kroah-Hartman commit 4f3374c990fb2adec06d20fd6d780927811c9aa0 Author: Rick Edgecombe Date: Thu Apr 9 11:43:30 2026 -0700 x86/shstk: Prevent deadlock during shstk sigreturn commit 9874b2917b9fbc30956fee209d3c4aa47201c64e upstream. During sigreturn the shadow stack signal frame is popped. The kernel does this by reading the shadow stack using normal read accesses. When it can't assume the memory is shadow stack, it takes extra steps to makes sure it is reading actual shadow stack memory and not other normal readable memory. It does this by holding the mmap read lock while doing the access and checking the flags of the VMA. Unfortunately that is not safe. If the read of the shadow stack sigframe hits a page fault, the fault handler will try to recursively grab another mmap read lock. This normally works ok, but if a writer on another CPU is also waiting, the second read lock could fail and cause a deadlock. Fix this by not holding mmap lock during the read access to userspace. Instead use mmap_lock_speculate_...() to watch for changes between dropping mmap lock and the userspace access. Retry if anything grabbed an mmap write lock in between and could have changed the VMA. These mmap_lock_speculate_...() helpers use mm::mm_lock_seq, which is only available when PER_VMA_LOCK is configured. So make X86_USER_SHADOW_STACK depend on it. On x86, PER_VMA_LOCK is a default configuration for SMP kernels. So drop support for the other configs under the assumption that the !SMP shadow stack user base does not exist. Currently there is a check that skips the lookup work when the SSP can be assumed to be on a shadow stack. While reorganizing the function, remove the optimization to make the tricky code flows more common, such that issues like this cannot escape detection for so long. Fixes: 7fad2a432cd3 ("x86/shstk: Check that signal frame is shadow stack mem") Suggested-by: Linus Torvalds Signed-off-by: Rick Edgecombe Signed-off-by: Thomas Gleixner Reviewed-by: Dave Hansen Reviewed-by: Thomas Gleixner Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ef7ce8f4a341c57b0b760bbb52c89a480278c28c Author: Dave Hansen Date: Tue Apr 21 09:31:36 2026 -0700 x86/cpu: Disable FRED when PTI is forced on commit 932d922285ef4d0d655a6f5def2779ae86ca0d73 upstream. FRED and PTI were never intended to work together. No FRED hardware is vulnerable to Meltdown and all of it should have LASS anyway. Nevertheless, if you boot a system with pti=on and fred=on, the kernel tries to do what is asked of it and dies a horrible death on the first attempt to run userspace (since it never switches to the user page tables). Disable FRED when PTI is forced on, and print a warning about it. A quick brain dump about what a FRED+PTI implementation would look like is below. I'm not sure it would make any sense to do it, but never say never. All I know is that it's way too complicated to be worth it today. The SWITCH_TO_USER/KERNEL_CR3 bits are simple to fix (or at least we have the assembly tools to do it already), as is sticking the FRED entry text in .entry.text (it's not in there today). The nasty part is the stacks. Today, the CPU pops into the kernel on MSR_IA32_FRED_RSP0 which is normal old kernel memory and not mapped to userspace. The hardware pushes gunk on to MSR_IA32_FRED_RSP0, which is currently the task stacks. MSR_IA32_FRED_RSP0 would need to point elsewhere, probably cpu_entry_stack(). Then, start playing games with stacks on entry/exit, including copying gunk to and from the task stack. While I'd *like* to have PTI everywhere, I'm not sure it's worth mucking up the FRED code with PTI kludges. If a user wants fast entry/exit, they use FRED. If you want PTI (and sekuritay), you certainly don't care about fast entry and FRED isn't going to help you *all* that much, so you can just stay with the IDT. Plus, FRED hardware should have LASS which gives you a similar security profile to PTI without the CR3 munging. Reported-by: Gayatri Kammela Signed-off-by: Dave Hansen Reviewed-by: Borislav Petkov (AMD) Tested-by: Maciej Wieczor-Retman Cc:stable@vger.kernel.org Link: https://patch.msgid.link/20260421163136.E7C6788A@davehans-spike.ostc.intel.com Signed-off-by: Greg Kroah-Hartman commit fdaa42ca370d056428e5e171247c8fdce8dff36a Author: Chia-Ming Chang Date: Tue Feb 24 17:34:42 2026 +0800 inotify: fix watch count leak when fsnotify_add_inode_mark_locked() fails commit 6a320935fa4293e9e599ec9f85dc9eb3be7029f8 upstream. When fsnotify_add_inode_mark_locked() fails in inotify_new_watch(), the error path calls inotify_remove_from_idr() but does not call dec_inotify_watches() to undo the preceding inc_inotify_watches(). This leaks a watch count, and repeated failures can exhaust the max_user_watches limit with -ENOSPC even when no watches are active. Prior to commit 1cce1eea0aff ("inotify: Convert to using per-namespace limits"), the watch count was incremented after fsnotify_add_mark_locked() succeeded, so this path was not affected. The conversion moved inc_inotify_watches() before the mark insertion without adding the corresponding rollback. Add the missing dec_inotify_watches() call in the error path. Fixes: 1cce1eea0aff ("inotify: Convert to using per-namespace limits") Cc: stable@vger.kernel.org Signed-off-by: Chia-Ming Chang Signed-off-by: robbieko Reviewed-by: Nikolay Borisov Link: https://patch.msgid.link/20260224093442.3076294-1-chiamingc@synology.com Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 371f4dc806017e68a616d236b0b9d7287e640b99 Author: Aditya Garg Date: Sat Apr 4 15:14:34 2026 +0530 HID: apple: ensure the keyboard backlight is off if suspending commit 1f95a6cd5ad78ed27a31a20cbd1facff6f10b33d upstream. Some users reported that upon suspending their keyboard backlight remained on. Fix this by adding the missing LED_CORE_SUSPENDRESUME flag. Cc: stable@vger.kernel.org Fixes: 394ba612f941 ("HID: apple: Add support for magic keyboard backlight on T2 Macs") Fixes: 9018eacbe623 ("HID: apple: Add support for keyboard backlight on certain T2 Macs.") Reported-by: André Eikmeyer Tested-by: André Eikmeyer Signed-off-by: Aditya Garg Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit ea43a34452a6a58507e42d7edfdfc4ae95744f9f Author: Arnd Bergmann Date: Fri Mar 6 17:33:07 2026 +0100 check-uapi: link into shared objects commit a261f6dff3c1653c19c065c3b3650c625447b8a7 upstream. While testing ABI changes across all architectures, I found that abidiff sometimes produces nonsensical output. Further debugging identified missing or broken libelf support for architecture specific relocations in ET_REL binaries as the source of the problem[1]. Change the script to no longer produce a relocatable object file but instead create a shared library for each header. This makes abidiff work for all of the architectures in upstream linux kernels. Link: https://sourceware.org/bugzilla/show_bug.cgi?id=33869 Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann Reviewed-by: Thomas Weißschuh Acked-by: Nathan Chancellor Link: https://patch.msgid.link/20260306163309.2015837-2-arnd@kernel.org Signed-off-by: Nicolas Schier Signed-off-by: Greg Kroah-Hartman commit 73ce72edd113374801045924d4417199963f73a3 Author: Junrui Luo Date: Sat Apr 4 15:44:35 2026 +0800 md/raid5: validate payload size before accessing journal metadata commit b0cc3ae97e893bf54bbce447f4e9fd2e0b88bff9 upstream. r5c_recovery_analyze_meta_block() and r5l_recovery_verify_data_checksum_for_mb() iterate over payloads in a journal metadata block using on-disk payload size fields without validating them against the remaining space in the metadata block. A corrupted journal contains payload sizes extending beyond the PAGE_SIZE boundary can cause out-of-bounds reads when accessing payload fields or computing offsets. Add bounds validation for each payload type to ensure the full payload fits within meta_size before processing. Fixes: b4c625c67362 ("md/r5cache: r5cache recovery: part 1") Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Link: https://lore.kernel.org/linux-raid/SYBPR01MB78815E78D829BB86CD7C8015AF5FA@SYBPR01MB7881.ausprd01.prod.outlook.com/ Signed-off-by: Yu Kuai Signed-off-by: Greg Kroah-Hartman commit 1985cb3247e87ff6b8ca4bc5f9626f4f51024507 Author: Chia-Ming Chang Date: Thu Apr 2 14:14:06 2026 +0800 md/raid5: fix soft lockup in retry_aligned_read() commit 7f9f7c697474268d9ef9479df3ddfe7cdcfbbffc upstream. When retry_aligned_read() encounters an overlapped stripe, it releases the stripe via raid5_release_stripe() which puts it on the lockless released_stripes llist. In the next raid5d loop iteration, release_stripe_list() drains the stripe onto handle_list (since STRIPE_HANDLE is set by the original IO), but retry_aligned_read() runs before handle_active_stripes() and removes the stripe from handle_list via find_get_stripe() -> list_del_init(). This prevents handle_stripe() from ever processing the stripe to resolve the overlap, causing an infinite loop and soft lockup. Fix this by using __release_stripe() with temp_inactive_list instead of raid5_release_stripe() in the failure path, so the stripe does not go through the released_stripes llist. This allows raid5d to break out of its loop, and the overlap will be resolved when the stripe is eventually processed by handle_stripe(). Fixes: 773ca82fa1ee ("raid5: make release_stripe lockless") Cc: stable@vger.kernel.org Signed-off-by: FengWei Shih Signed-off-by: Chia-Ming Chang Link: https://lore.kernel.org/linux-raid/20260402061406.455755-1-chiamingc@synology.com/ Signed-off-by: Yu Kuai Signed-off-by: Greg Kroah-Hartman commit 9142f00a9287ca38152717e3e88a033a27774e7f Author: Yu Kuai Date: Mon Feb 23 10:40:35 2026 +0800 md/md-llbitmap: raise barrier before state machine transition commit ef4ca3d4bf09716cff9ba00eb0351deadc8417ab upstream. Move the barrier raise operation before calling llbitmap_state_machine() in both llbitmap_start_write() and llbitmap_start_discard(). This ensures the barrier is in place before any state transitions occur, preventing potential race conditions where the state machine could complete before the barrier is properly raised. Cc: stable@vger.kernel.org Fixes: 5ab829f1971d ("md/md-llbitmap: introduce new lockless bitmap") Link: https://lore.kernel.org/linux-raid/20260223024038.3084853-3-yukuai@fnnas.com Signed-off-by: Yu Kuai Signed-off-by: Greg Kroah-Hartman commit 98623c7e2a51eab1833c8628d33fa9c6ef3ce325 Author: Yu Kuai Date: Mon Feb 23 10:40:34 2026 +0800 md/md-llbitmap: skip reading rdevs that are not in_sync commit 7701e68b5072faa03a8f30b4081dc16df9092381 upstream. When reading bitmap pages from member disks, the code iterates through all rdevs and attempts to read from the first available one. However, it only checks for raid_disk assignment and Faulty flag, missing the In_sync flag check. This can cause bitmap data to be read from spare disks that are still being rebuilt and don't have valid bitmap information yet. Reading stale or uninitialized bitmap data from such disks can lead to incorrect dirty bit tracking, potentially causing data corruption during recovery or normal operation. Add the In_sync flag check to ensure bitmap pages are only read from fully synchronized member disks that have valid bitmap data. Cc: stable@vger.kernel.org Fixes: 5ab829f1971d ("md/md-llbitmap: introduce new lockless bitmap") Link: https://lore.kernel.org/linux-raid/20260223024038.3084853-2-yukuai@fnnas.com Signed-off-by: Yu Kuai Signed-off-by: Greg Kroah-Hartman commit f7d9d0e4a64fe42c4f25e2a4fbabe3887efbb490 Author: David (Ming Qiang) Wu Date: Mon Mar 9 18:48:37 2026 -0400 amdgpu/jpeg: fix deepsleep register for jpeg 5_0_0 and 5_0_2 commit e90dc3b2d73986610476b02c29d0074aa4d92fb0 upstream. PCTL0__MMHUB_DEEPSLEEP_IB is 0x69004 on MMHUB 4,1,0 and and 0x60804 on MMHUB 4,2,0. 0x62a04 is on MMHUB 1,8,0/1. The DS bits are adjusted to cover more JPEG engines and MMHUB version. Signed-off-by: David (Ming Qiang) Wu Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ac858718219f9cd9807408196da21235cd303150 Author: Miquel Raynal Date: Wed Mar 25 18:04:50 2026 +0100 mtd: spinand: winbond: Declare the QE bit on W25NxxJW commit 7866ce992cf0d3c3b50fe8bf4acb1dbb173a2304 upstream. Factory default for this bit is "set" (at least on the chips I have), but we must make sure it is actually set by Linux explicitly, as the bit is writable by an earlier stage. Fixes: 6a804fb72de5 ("mtd: spinand: winbond: add support for serial NAND flash") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 134975be170b4772288319d4756b8edd04888cd3 Author: Sanjaikumar V S Date: Wed Mar 11 10:30:56 2026 +0000 mtd: spi-nor: sst: Fix write enable before AAI sequence commit a0f64241d3566a49c0a9b33ba7ae458ae22003a9 upstream. When writing to SST flash starting at an odd address, a single byte is first programmed using the byte program (BP) command. After this operation completes, the flash hardware automatically clears the Write Enable Latch (WEL) bit. If an AAI (Auto Address Increment) word program sequence follows, it requires WEL to be set. Without re-enabling writes, the AAI sequence fails. Add spi_nor_write_enable() after the odd-address byte program when more data needs to be written. Use a local boolean for clarity. Fixes: b199489d37b2 ("mtd: spi-nor: add the framework for SPI NOR") Cc: stable@vger.kernel.org Signed-off-by: Sanjaikumar V S Tested-by: Hendrik Donner Reviewed-by: Hendrik Donner Signed-off-by: Pratyush Yadav (Google) Signed-off-by: Greg Kroah-Hartman commit 1e6b0a69bf2c9c819255c7566e4355536d81d9cf Author: Sohei Koyama Date: Mon Apr 6 16:48:30 2026 +0900 ext4: fix missing brelse() in ext4_xattr_inode_dec_ref_all() commit 77d059519382bd66283e6a4e83ee186e87e7708f upstream. The commit c8e008b60492 ("ext4: ignore xattrs past end") introduced a refcount leak in when block_csum is false. ext4_xattr_inode_dec_ref_all() calls ext4_get_inode_loc() to get iloc.bh, but never releases it with brelse(). Fixes: c8e008b60492 ("ext4: ignore xattrs past end") Signed-off-by: Sohei Koyama Reviewed-by: Andreas Dilger Reviewed-by: Ritesh Harjani (IBM) Cc: stable@vger.kernel.org Reviewed-by: Zhang Yi Reviewed-by: Baokun Li Link: https://patch.msgid.link/20260406074830.8480-1-skoyama@ddn.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 537e065977022aa22f2c2503e8accaf16622e0fd Author: Deepanshu Kartikey Date: Sat Mar 28 20:30:38 2026 +0530 ext4: fix bounds check in check_xattrs() to prevent out-of-bounds access commit eceafc31ea7b42c984ece10d79d505c0bb6615d5 upstream. The bounds check for the next xattr entry in check_xattrs() uses (void *)next >= end, which allows next to point within sizeof(u32) bytes of end. On the next loop iteration, IS_LAST_ENTRY() reads 4 bytes via *(__u32 *)(entry), which can overrun the valid xattr region. For example, if next lands at end - 1, the check passes since next < end, but IS_LAST_ENTRY() reads 4 bytes starting at end - 1, accessing 3 bytes beyond the valid region. Fix this by changing the check to (void *)next + sizeof(u32) > end, ensuring there is always enough space for the IS_LAST_ENTRY() read on the subsequent iteration. Fixes: 3478c83cf26b ("ext4: improve xattr consistency checking and error reporting") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20260224231429.31361-1-kartikey406@gmail.com/T/ [v1] Signed-off-by: Deepanshu Kartikey Link: https://patch.msgid.link/20260328150038.349497-1-kartikey406@gmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 6b4bf6519e5071492f7bcd3e237dceb57457b8b6 Author: Masami Hiramatsu (Google) Date: Fri Apr 24 15:52:10 2026 +0900 ring-buffer: Do not double count the reader_page commit 92d5a606721f759ebebf448b3bd2b7a781d50bd0 upstream. Since the cpu_buffer->reader_page is updated if there are unwound pages. After that update, we should skip the page if it is the original reader_page, because the original reader_page is already checked. Cc: stable@vger.kernel.org Cc: Catalin Marinas Cc: Will Deacon Cc: Mathieu Desnoyers Cc: Ian Rogers Link: https://patch.msgid.link/177701353063.2223789.1471163147644103306.stgit@mhiramat.tok.corp.google.com Fixes: ca296d32ece3 ("tracing: ring_buffer: Rewind persistent ring buffer on reboot") Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit f9c279ffee6b13ff87d24cef33d401e39fb20eb8 Author: Brian Ruley Date: Wed Apr 15 18:12:48 2026 +0100 ARM: 9472/1: fix race condition on PG_dcache_clean in __sync_icache_dcache() commit 75f9a484e817adea211c73f89ed938a2b2f90953 upstream. This bug was already discovered and fixed for arm64 in commit 588a513d3425 ("arm64: Fix race condition on PG_dcache_clean in __sync_icache_dcache()"). Verified with added instrumentation to track dcache flushes in a ring buffer, as shown by the (distilled) output: kernel: SIGILL at b6b80ac0 cpu 1 pid 32663 linux_pte=8eff659f hw_pte=8eff6e7e young=1 exec=1 kernel: dcache flush START cpu0 pfn=8eff6 ts=48629557020154 kernel: dcache flush SKIPPED cpu1 pfn=8eff6 ts=48629557020154 kernel: dcache flush FINISH cpu0 pfn=8eff6 ts=48629557036154 audisp-syslog: comm="journalctl" exe="/usr/bin/journalctl" sig=4 [...] Discussions in the mailing list mentioned that arch/arm is also affected but the fix was never applied to it [1][2]. Apply the change now, since the race condition can cause sporadic SIGILL's and SEGV's especially while under high memory pressure. Link: https://lore.kernel.org/all/adzMOdySgMIePcue@willie-the-truck [1] Link: https://lore.kernel.org/all/20210514095001.13236-1-catalin.marinas@arm.com [2] Signed-off-by: Brian Ruley Reviewed-by: Will Deacon Cc: Fixes: 6012191aa9c6 ("ARM: 6380/1: Introduce __sync_icache_dcache() for VIPT caches") Signed-off-by: Will Deacon Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman commit cd2689d625b01165442d181a9b2eb18c41baf5f8 Author: Rong Bao Date: Fri May 1 20:22:05 2026 +0800 perf annotate: Use jump__delete when freeing LoongArch jumps [ Upstream commit a355eefc36c4481188249b067832b40a2c45fa5c ] Currently, the initialization of loongarch_jump_ops does not contain an assignment to its .free field. This causes disasm_line__free() to fall through to ins_ops__delete() for LoongArch jump instructions. ins_ops__delete() will free ins_operands.source.raw and ins_operands.source.name, and these fields overlaps with ins_operands.jump.raw_comment and ins_operands.jump.raw_func_start. Since in loongarch_jump__parse(), these two fields are populated by strchr()-ing the same buffer, trying to free them will lead to undefined behavior. This invalid free usually leads to crashes: Process 1712902 (perf) of user 1000 dumped core. Stack trace of thread 1712902: #0 0x00007fffef155c58 n/a (libc.so.6 + 0x95c58) #1 0x00007fffef0f7a94 raise (libc.so.6 + 0x37a94) #2 0x00007fffef0dd6a8 abort (libc.so.6 + 0x1d6a8) #3 0x00007fffef145490 n/a (libc.so.6 + 0x85490) #4 0x00007fffef1646f4 n/a (libc.so.6 + 0xa46f4) #5 0x00007fffef164718 n/a (libc.so.6 + 0xa4718) #6 0x00005555583a6764 __zfree (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x106764) #7 0x000055555854fb70 disasm_line__free (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x2afb70) #8 0x000055555853d618 annotated_source__purge (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x29d618) #9 0x000055555852300c __hist_entry__tui_annotate (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x28300c) #10 0x0000555558526718 do_annotate (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x286718) #11 0x000055555852ed94 evsel__hists_browse (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x28ed94) #12 0x000055555831fdd0 cmd_report (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x7fdd0) #13 0x000055555839b644 handle_internal_command (/home/csmantle/dist/linux-arch/tools/perf/perf + 0xfb644) #14 0x00005555582fe6ac main (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x5e6ac) #15 0x00007fffef0ddd90 n/a (libc.so.6 + 0x1dd90) #16 0x00007fffef0ddf0c __libc_start_main (libc.so.6 + 0x1df0c) #17 0x00005555582fed10 _start (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x5ed10) ELF object binary architecture: LoongArch ... and it can be confirmed with Valgrind: ==1721834== Invalid free() / delete / delete[] / realloc() ==1721834== at 0x4EA9014: free (in /usr/lib/valgrind/vgpreload_memcheck-loongarch64-linux.so) ==1721834== by 0x4106287: __zfree (zalloc.c:13) ==1721834== by 0x42ADC8F: disasm_line__free (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x429B737: annotated_source__purge (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42811EB: __hist_entry__tui_annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42848D7: do_annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x428CF33: evsel__hists_browse (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== Address 0x7d34303 is 35 bytes inside a block of size 62 alloc'd ==1721834== at 0x4EA59B8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-loongarch64-linux.so) ==1721834== by 0x6B80B6F: strdup (strdup.c:42) ==1721834== by 0x42AD917: disasm_line__new (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42AE5A3: symbol__disassemble_objdump (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42AF0A7: symbol__disassemble (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x429B3CF: symbol__annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x429C233: symbol__annotate2 (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42804D3: __hist_entry__tui_annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42848D7: do_annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x428CF33: evsel__hists_browse (in /home/csmantle/dist/linux-arch/tools/perf/perf) This patch adds the missing free() specialization in loongarch_jump_ops, which prevents disasm_line__free() from invoking the default cleanup function. Fixes: fb7fd2a14a503b9a ("perf annotate: Move raw_comment and raw_func_start fields out of 'struct ins_operands'") Cc: stable@vger.kernel.org Cc: WANG Rui Cc: Huacai Chen Cc: WANG Xuerui Cc: loongarch@lists.linux.dev Signed-off-by: Rong Bao Tested-by: WANG Rui Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 5955e053ff001702257bce630f3c41153812aefb Author: Sean Christopherson Date: Tue Mar 3 16:22:23 2026 -0800 KVM: nSVM: Always intercept VMMCALL when L2 is active commit 33d3617a52f9930d22b2af59f813c2fbdefa6dd5 upstream. Always intercept VMMCALL now that KVM properly synthesizes a #UD as appropriate, i.e. when L1 doesn't want to intercept VMMCALL, to avoid putting L2 into an infinite #UD loop if KVM_X86_QUIRK_FIX_HYPERCALL_INSN is enabled. By letting L2 execute VMMCALL natively and thus #UD, for all intents and purposes KVM morphs the VMMCALL intercept into a #UD intercept (KVM always intercepts #UD). When the hypercall quirk is enabled, KVM "emulates" VMMCALL in response to the #UD by trying to fixup the opcode to the "right" vendor, then restarts the guest, without skipping the VMMCALL. As a result, the guest sees an endless stream of #UDs since it's already executing the correct vendor hypercall instruction, i.e. the emulator doesn't anticipate that the #UD could be due to lack of interception, as opposed to a truly undefined opcode. Fixes: 0d945bd93511 ("KVM: SVM: Don't allow nested guest to VMMCALL into host") Cc: stable@vger.kernel.org Reviewed-by: Yosry Ahmed Reviewed-by: Vitaly Kuznetsov Link: https://patch.msgid.link/20260304002223.1105129-3-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 009c0f726abeaa67aad1d96b883bdce01d405ce2 Author: Kevin Cheng Date: Tue Mar 3 16:22:22 2026 -0800 KVM: nSVM: Raise #UD if unhandled VMMCALL isn't intercepted by L1 commit c36991c6f8d2ab56ee67aff04e3c357f45cfc76c upstream. Explicitly synthesize a #UD for VMMCALL if L2 is active, L1 does NOT want to intercept VMMCALL, nested_svm_l2_tlb_flush_enabled() is true, and the hypercall is something other than one of the supported Hyper-V hypercalls. When all of the above conditions are met, KVM will intercept VMMCALL but never forward it to L1, i.e. will let L2 make hypercalls as if it were L1. The TLFS says a whole lot of nothing about this scenario, so go with the architectural behavior, which says that VMMCALL #UDs if it's not intercepted. Opportunistically do a 2-for-1 stub trade by stub-ifying the new API instead of the helpers it uses. The last remaining "single" stub will soon be dropped as well. Suggested-by: Sean Christopherson Fixes: 3f4a812edf5c ("KVM: nSVM: hyper-v: Enable L2 TLB flush") Cc: Vitaly Kuznetsov Cc: stable@vger.kernel.org Signed-off-by: Kevin Cheng Link: https://patch.msgid.link/20260228033328.2285047-5-chengkev@google.com [sean: rewrite changelog and comment, tag for stable, remove defunct stubs] Reviewed-by: Yosry Ahmed Reviewed-by: Vitaly Kuznetsov Link: https://patch.msgid.link/20260304002223.1105129-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 83f7e055c138b7a30d4c04af1812f7a88813aaa6 Author: Yosry Ahmed Date: Tue Mar 3 00:34:09 2026 +0000 KVM: nSVM: Add missing consistency check for nCR3 validity commit b71138fcc362c67ebe66747bb22cb4e6b4d6a651 upstream. From the APM Volume #2, 15.25.4 (24593—Rev. 3.42—March 2024): When VMRUN is executed with nested paging enabled (NP_ENABLE = 1), the following conditions are considered illegal state combinations, in addition to those mentioned in “Canonicalization and Consistency Checks”: • Any MBZ bit of nCR3 is set. • Any G_PAT.PA field has an unsupported type encoding or any reserved field in G_PAT has a nonzero value. Add the consistency check for nCR3 being a legal GPA with no MBZ bits set. Note, the G_PAT.PA check is being handled separately[*]. Link: https://lore.kernel.org/kvm/20260205214326.1029278-3-jmattson@google.com [*] Fixes: 4b16184c1cca ("KVM: SVM: Initialize Nested Nested MMU context on VMRUN") Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260303003421.2185681-16-yosry@kernel.org [sean: capture everything in CC(), massage changelog formatting] Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 0d1f3fd2664b22f95f8589bd583b929a110cd013 Author: Yosry Ahmed Date: Tue Mar 3 00:34:08 2026 +0000 KVM: nSVM: Drop the non-architectural consistency check for NP_ENABLE commit e0b6f031d64c086edd563e7af9c0c0a2261dd2a4 upstream. KVM currenty fails a nested VMRUN and injects VMEXIT_INVALID (aka SVM_EXIT_ERR) if L1 sets NP_ENABLE and the host does not support NPTs. On first glance, it seems like the check should actually be for guest_cpu_cap_has(X86_FEATURE_NPT) instead, as it is possible for the host to support NPTs but the guest CPUID to not advertise it. However, the consistency check is not architectural to begin with. The APM does not mention VMEXIT_INVALID if NP_ENABLE is set on a processor that does not have X86_FEATURE_NPT. Hence, NP_ENABLE should be ignored if X86_FEATURE_NPT is not available for L1, so sanitize it when copying from the VMCB12 to KVM's cache. Apart from the consistency check, NP_ENABLE in VMCB12 is currently ignored because the bit is actually copied from VMCB01 to VMCB02, not from VMCB12. Fixes: 4b16184c1cca ("KVM: SVM: Initialize Nested Nested MMU context on VMRUN") Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260303003421.2185681-15-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit aabd785f9565bcc3c9651d48cf46a8f43bc46f35 Author: Yosry Ahmed Date: Tue Mar 3 00:34:10 2026 +0000 KVM: nSVM: Add missing consistency check for EFER, CR0, CR4, and CS commit 96bd3e76a171a8e21a6387e54e4c420a81968492 upstream. According to the APM Volume #2, 15.5, Canonicalization and Consistency Checks (24593—Rev. 3.42—March 2024), the following condition (among others) results in a #VMEXIT with VMEXIT_INVALID (aka SVM_EXIT_ERR): EFER.LME, CR0.PG, CR4.PAE, CS.L, and CS.D are all non-zero. In the list of consistency checks done when EFER.LME and CR0.PG are set, add a check that CS.L and CS.D are not both set, after the existing check that CR4.PAE is set. This is functionally a nop because the nested VMRUN results in SVM_EXIT_ERR in HW, which is forwarded to L1, but KVM makes all consistency checks before a VMRUN is actually attempted. Fixes: 3d6368ef580a ("KVM: SVM: Add VMRUN handler") Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260303003421.2185681-17-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit d79720fc99594e2ec8c7421d45ca64624e89d25c Author: Yosry Ahmed Date: Tue Mar 3 00:34:06 2026 +0000 KVM: nSVM: Clear tracking of L1->L2 NMI and soft IRQ on nested #VMEXIT commit 8998e1d012f3f45d0456f16706682cef04c3c436 upstream. KVM clears tracking of L1->L2 injected NMIs (i.e. nmi_l1_to_l2) and soft IRQs (i.e. soft_int_injected) on a synthesized #VMEXIT(INVALID) due to failed VMRUN. However, they are not explicitly cleared in other synthesized #VMEXITs. soft_int_injected is always cleared after the first VMRUN of L2 when completing interrupts, as any re-injection is then tracked by KVM (instead of purely in vmcb02). nmi_l1_to_l2 is not cleared after the first VMRUN if NMI injection failed, as KVM still needs to keep track that the NMI originated from L1 to avoid blocking NMIs for L1. It is only cleared when the NMI injection succeeds. KVM could synthesize a #VMEXIT to L1 before successfully injecting the NMI into L2 (e.g. due to a #NPF on L2's NMI handler in L1's NPTs). In this case, nmi_l1_to_l2 will remain true, and KVM may not correctly mask NMIs and intercept IRET when injecting an NMI into L1. Clear both nmi_l1_to_l2 and soft_int_injected in nested_svm_vmexit(), i.e. for all #VMEXITs except those that occur due to failed consistency checks, as those happen before nmi_l1_to_l2 or soft_int_injected are set. Fixes: 159fc6fa3b7d ("KVM: nSVM: Transparently handle L1 -> L2 NMI re-injection") Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260303003421.2185681-13-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit b6656ba2652595ee88ca4ed92ec015206f7d9eb9 Author: Yosry Ahmed Date: Tue Mar 3 00:34:05 2026 +0000 KVM: nSVM: Clear EVENTINJ fields in vmcb12 on nested #VMEXIT commit 69b721a86d0dcb026f6db7d111dcde7550442d2e upstream. According to the APM, from the reference of the VMRUN instruction: Upon #VMEXIT, the processor performs the following actions in order to return to the host execution context: ... clear EVENTINJ field in VMCB KVM already syncs EVENTINJ fields from vmcb02 to cached vmcb12 on every L2->L0 #VMEXIT. Since these fields are zeroed by the CPU on #VMEXIT, they will mostly be zeroed in vmcb12 on nested #VMEXIT by nested_svm_vmexit(). However, this is not the case when: 1. Consistency checks fail, as nested_svm_vmexit() is not called. 2. Entering guest mode fails before L2 runs (e.g. due to failed load of CR3). (2) was broken by commit 2d8a42be0e2b ("KVM: nSVM: synchronize VMCB controls updated by the processor on every vmexit"), as prior to that nested_svm_vmexit() always zeroed EVENTINJ fields. Explicitly clear the fields in all nested #VMEXIT code paths. Fixes: 3d6368ef580a ("KVM: SVM: Add VMRUN handler") Fixes: 2d8a42be0e2b ("KVM: nSVM: synchronize VMCB controls updated by the processor on every vmexit") Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260303003421.2185681-12-yosry@kernel.org [sean: massage changelog formatting] Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit c2fad967e652c307f4ddcc9e851dc72eda665393 Author: Yosry Ahmed Date: Tue Mar 3 00:34:04 2026 +0000 KVM: nSVM: Clear GIF on nested #VMEXIT(INVALID) commit f85a6ce06e4a0d49652f57967a649ab09e06287c upstream. According to the APM, GIF is set to 0 on any #VMEXIT, including an #VMEXIT(INVALID) due to failed consistency checks. Clear GIF on consistency check failures. Fixes: 3d6368ef580a ("KVM: SVM: Add VMRUN handler") Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260303003421.2185681-11-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit d6f6371bbea6d17cb947ddeb14348e2dd5f8f09f Author: Yosry Ahmed Date: Tue Mar 3 00:34:02 2026 +0000 KVM: nSVM: Triple fault if mapping VMCB12 fails on nested #VMEXIT commit 1b30e7551767cb95b3e49bb169c72bbd76b56e05 upstream. KVM currently injects a #GP and hopes for the best if mapping VMCB12 fails on nested #VMEXIT, and only if the failure mode is -EINVAL. Mapping the VMCB12 could also fail if creating host mappings fails. After the #GP is injected, nested_svm_vmexit() bails early, without cleaning up (e.g. KVM_REQ_GET_NESTED_STATE_PAGES is set, is_guest_mode() is true, etc). Instead of optionally injecting a #GP, triple fault the guest if mapping VMCB12 fails since KVM cannot make a sane recovery. The APM states that a #VMEXIT will triple fault if host state is illegal or an exception occurs while loading host state, so the behavior is not entirely made up. Do not return early from nested_svm_vmexit(), continue cleaning up the vCPU state (e.g. switch back to vmcb01), to handle the failure as gracefully as possible. Fixes: cf74a78b229d ("KVM: SVM: Add VMEXIT handler and intercepts") CC: stable@vger.kernel.org Co-developed-by: Sean Christopherson Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260303003421.2185681-9-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 410ea5575c6675fe6aeac8ff89841ba7d4ef5a66 Author: Yosry Ahmed Date: Tue Mar 3 00:34:01 2026 +0000 KVM: nSVM: Refactor writing vmcb12 on nested #VMEXIT as a helper commit dcf3648ab71437b504abbfdc4e74622a0f1a56e3 upstream. Move mapping vmcb12 and updating it out of nested_svm_vmexit() into a helper, no functional change intended. CC: stable@vger.kernel.org Co-developed-by: Sean Christopherson Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260303003421.2185681-8-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 72fe7d04a6698da23e73338883e43153024b95c5 Author: Yosry Ahmed Date: Tue Mar 3 00:34:00 2026 +0000 KVM: nSVM: Refactor checking LBRV enablement in vmcb12 into a helper commit 290c8d82023ab0e1d2782d37136541e017174d7c upstream. Refactor the vCPU cap and vmcb12 flag checks into a helper. The unlikely() annotation is dropped, it's unlikely (huh) to make a difference and the CPU will probably predict it better on its own. CC: stable@vger.kernel.org Co-developed-by: Sean Christopherson Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260303003421.2185681-7-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 49c8b2395bacd552051a9bfacbfe6a60d396fdd8 Author: Yosry Ahmed Date: Tue Mar 3 00:33:59 2026 +0000 KVM: nSVM: Always inject a #GP if mapping VMCB12 fails on nested VMRUN commit 01ddcdc55e097ca38c28ae656711b8e6d1df71f8 upstream. nested_svm_vmrun() currently only injects a #GP if kvm_vcpu_map() fails with -EINVAL. But it could also fail with -EFAULT if creating a host mapping failed. Inject a #GP in all cases, no reason to treat failure modes differently. Fixes: 8c5fbf1a7231 ("KVM/nSVM: Use the new mapping API for mapping guest memory") CC: stable@vger.kernel.org Co-developed-by: Sean Christopherson Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260303003421.2185681-6-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 2b922a42b531a82d7881add14a7698dcdc5e1f0a Author: Yosry Ahmed Date: Tue Mar 3 00:33:57 2026 +0000 KVM: SVM: Add missing save/restore handling of LBR MSRs commit 3700f0788da6acf73b2df56690f4b201aa4aefd2 upstream. MSR_IA32_DEBUGCTLMSR and LBR MSRs are currently not enumerated by KVM_GET_MSR_INDEX_LIST, and LBR MSRs cannot be set with KVM_SET_MSRS. So save/restore is completely broken. Fix it by adding the MSRs to msrs_to_save_base, and allowing writes to LBR MSRs from userspace only (as they are read-only MSRs) if LBR virtualization is enabled. Additionally, to correctly restore L1's LBRs while L2 is running, make sure the LBRs are copied from the captured VMCB01 save area in svm_copy_vmrun_state(). Note, for VMX, this also fixes a flaw where MSR_IA32_DEBUGCTLMSR isn't reported as an MSR to save/restore. Note #2, over-reporting MSR_IA32_LASTxxx on Intel is ok, as KVM already handles unsupported reads and writes thanks to commit b5e2fec0ebc3 ("KVM: Ignore DEBUGCTL MSRs with no effect") (kvm_do_msr_access() will morph the unsupported userspace write into a nop). Fixes: 24e09cbf480a ("KVM: SVM: enable LBR virtualization") Cc: stable@vger.kernel.org Reported-by: Jim Mattson Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260303003421.2185681-4-yosry@kernel.org [sean: guard with lbrv checks, massage changelog] Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 18ff4ab16412ecb9b1d5f8799610a8e1b110ede0 Author: Yosry Ahmed Date: Tue Mar 3 00:33:56 2026 +0000 KVM: SVM: Switch svm_copy_lbrs() to a macro commit 361dbe8173c460a2bf8aee23920f6c2dbdcabb94 upstream. In preparation for using svm_copy_lbrs() with 'struct vmcb_save_area' without a containing 'struct vmcb', and later even 'struct vmcb_save_area_cached', make it a macro. Macros are generally not preferred compared to functions, mainly due to type-safety. However, in this case it seems like having a simple macro copying a few fields is better than copy-pasting the same 5 lines of code in different places. Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260303003421.2185681-3-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit a5ea402844f175d075ac6a2936f29ad912fa1911 Author: Sean Christopherson Date: Wed Mar 4 16:06:56 2026 -0800 KVM: nSVM: Delay setting soft IRQ RIP tracking fields until vCPU run commit c64bc6ed1764c1b7e3c0017019f743196074092f upstream. In the save+restore path, when restoring nested state, the values of RIP and CS base passed into nested_vmcb02_prepare_control() are mostly incorrect. They are both pulled from the vmcb02. For CS base, the value is only correct if system regs are restored before nested state. The value of RIP is whatever the vCPU had in vmcb02 before restoring nested state (zero on a freshly created vCPU). Instead, take a similar approach to NextRIP, and delay initializing the RIP tracking fields until shortly before the vCPU is run, to make sure the most up-to-date values of RIP and CS base are used regardless of KVM_SET_SREGS, KVM_SET_REGS, and KVM_SET_NESTED_STATE's relative ordering. Fixes: cc440cdad5b7 ("KVM: nSVM: implement KVM_GET_NESTED_STATE and KVM_SET_NESTED_STATE") CC: stable@vger.kernel.org Suggested-by: Sean Christopherson Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260225005950.3739782-8-yosry@kernel.org [sean: deal with the svm_cancel_injection() madness] Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit a3f0981a5a0e0bd51ad74cc7d9eed32294b24002 Author: Yosry Ahmed Date: Tue Mar 3 00:33:55 2026 +0000 KVM: nSVM: Avoid clearing VMCB_LBR in vmcb12 commit b53ab5167a81537777ac780bbd93d32613aa3bda upstream. svm_copy_lbrs() always marks VMCB_LBR dirty in the destination VMCB. However, nested_svm_vmexit() uses it to copy LBRs to vmcb12, and clearing clean bits in vmcb12 is not architecturally defined. Move vmcb_mark_dirty() to callers and drop it for vmcb12. This also facilitates incoming refactoring that does not pass the entire VMCB to svm_copy_lbrs(). Fixes: d20c796ca370 ("KVM: x86: nSVM: implement nested LBR virtualization") Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260303003421.2185681-2-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 88572f9d83d7d25a5c333f2f2e7494d83d8cf97a Author: Yosry Ahmed Date: Tue Feb 3 20:10:10 2026 +0000 KVM: nSVM: Use vcpu->arch.cr2 when updating vmcb12 on nested #VMEXIT commit 5c247d08bc81bbad4c662dcf5654137a2f8483ec upstream. KVM currently uses the value of CR2 from vmcb02 to update vmcb12 on nested #VMEXIT. This value is incorrect in some cases, causing L1 to run L2 with a corrupted CR2. This could lead to segfaults or data corruption if L2 is in the middle of handling a #PF and reads a corrupted CR2. Use the correct value in vcpu->arch.cr2 instead. The value in vcpu->arch.cr2 is sync'd to vmcb02 shortly before a VMRUN of L2, and sync'd back to vcpu->arch.cr2 shortly after. The value are only out-of-sync in two cases: after save+restore, and after a #PF is injected into L2. In either case, if a #VMEXIT to L1 is synthesized before L2 runs, using the value in vmcb02 would be incorrect. After save+restore, the value of CR2 is restored by KVM_SET_SREGS into vcpu->arch.cr2. It is not reflect in vmcb02 until a VMRUN of L2. Before that, it holds whatever was in vmcb02 before restore, which would be zero on a new vCPU that never ran nested. If a #VMEXIT to L1 is synthesized before L2 ever runs, using vcpu->arch.cr2 to update vmcb12 is the right thing to do. The #PF injection case is more nuanced. Although the APM is a bit unclear about when CR2 is written during a #PF, the SDM is more clear: Processors update CR2 whenever a page fault is detected. If a second page fault occurs while an earlier page fault is being delivered, the faulting linear address of the second fault will overwrite the contents of CR2 (replacing the previous address). These updates to CR2 occur even if the page fault results in a double fault or occurs during the delivery of a double fault. KVM injecting the exception surely counts as the #PF being "detected". More importantly, when an exception is injected into L2 at the time of a synthesized #VMEXIT, KVM updates exit_int_info in vmcb12 accordingly, such that an L1 hypervisor can re-inject the exception. If CR2 is not written at that point, the L1 hypervisor have no way of correctly re-injecting the #PF. Hence, if a #VMEXIT to L1 is synthesized after the #PF is injected into L2 but before it actually runs, using vcpu->arch.cr2 to update vmcb12 is also the right thing to do. Note that KVM does _not_ update vcpu->arch.cr2 when a #PF is pending for L2, only when it is injected. The distinction is important, because only injected (but not intercepted) exceptions are propagated to L1 through exit_int_info. It would be incorrect to update CR2 in vmcb12 for a pending #PF, as L1 would perceive an updated CR2 value with no #PF. Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260203201010.1871056-1-yosry.ahmed@linux.dev Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 3a95eb7c695090defaf2fd88f2664a9382381547 Author: Yosry Ahmed Date: Wed Feb 25 00:59:48 2026 +0000 KVM: nSVM: Delay stuffing L2's current RIP into NextRIP until vCPU run commit a0592461f39c00b28f552fe842a063a00043eaa8 upstream. For guests with NRIPS disabled, L1 does not provide NextRIP when running an L2 with an injected soft interrupt, instead it advances L2's RIP before running it. KVM uses L2's current RIP as the NextRIP in vmcb02 to emulate a CPU without NRIPS. However, in svm_set_nested_state(), the value used for L2's current RIP comes from vmcb02, which is just whatever the vCPU had in vmcb02 before restoring nested state (zero on a freshly created vCPU). Passing the cached RIP value instead (i.e. kvm_rip_read()) would only fix the issue if registers are restored before nested state. Instead, split the logic of setting NextRIP in vmcb02. Handle the 'normal' case of initializing vmcb02's NextRIP using NextRIP from vmcb12 (or KVM_GET_NESTED_STATE's payload) in nested_vmcb02_prepare_control(). Delay the special case of stuffing L2's current RIP into vmcb02's NextRIP until shortly before the vCPU is run, to make sure the most up-to-date value of RIP is used regardless of KVM_SET_REGS and KVM_SET_NESTED_STATE's relative ordering. Fixes: cc440cdad5b7 ("KVM: nSVM: implement KVM_GET_NESTED_STATE and KVM_SET_NESTED_STATE") CC: stable@vger.kernel.org Suggested-by: Sean Christopherson Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260225005950.3739782-7-yosry@kernel.org [sean: use new helper, svm_fixup_nested_rips()] Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 3428ed1529a1af4cce5aff6c5bd2fcc39ad726bb Author: Yosry Ahmed Date: Wed Feb 25 00:59:47 2026 +0000 KVM: nSVM: Always use NextRIP as vmcb02's NextRIP after first L2 VMRUN commit 8d397582f6b5e9fbcf09781c7c934b4910e94a50 upstream. For guests with NRIPS disabled, L1 does not provide NextRIP when running an L2 with an injected soft interrupt, instead it advances the current RIP before running it. KVM uses the current RIP as the NextRIP in vmcb02 to emulate a CPU without NRIPS. However, after L2 runs the first time, NextRIP will be updated by the CPU and/or KVM, and the current RIP is no longer the correct value to use in vmcb02. Hence, after save/restore, use the current RIP if and only if a nested run is pending, otherwise use NextRIP. Give soft_int_next_rip the same treatment, as it's the same logic, just for a narrower use case. Fixes: cc440cdad5b7 ("KVM: nSVM: implement KVM_GET_NESTED_STATE and KVM_SET_NESTED_STATE") CC: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260225005950.3739782-6-yosry@kernel.org [sean: give soft_int_next_rip the same treatment] Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 46b3827abc4473e1f907f4609f9e0190c2fd6d52 Author: Yosry Ahmed Date: Tue Feb 24 22:50:17 2026 +0000 KVM: nSVM: Ensure AVIC is inhibited when restoring a vCPU to guest mode commit 24f7d36b824b65cf1a2db3db478059187b2a37b0 upstream. On nested VMRUN, KVM ensures AVIC is inhibited by requesting KVM_REQ_APICV_UPDATE, triggering a check of inhibit reasons, finding APICV_INHIBIT_REASON_NESTED, and disabling AVIC. However, when KVM_SET_NESTED_STATE is performed on a vCPU not in guest mode with AVIC enabled, KVM_REQ_APICV_UPDATE is not requested, and AVIC is not inhibited. Request KVM_REQ_APICV_UPDATE in the KVM_SET_NESTED_STATE path if AVIC is active, similar to the nested VMRUN path. Fixes: f44509f849fe ("KVM: x86: SVM: allow AVIC to co-exist with a nested guest running") Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260224225017.3303870-1-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 8302e9be9f9cb9fcd9f3f2ed2397522c1a1e288d Author: Sean Christopherson Date: Wed Feb 18 15:09:51 2026 -0800 KVM: SVM: Explicitly mark vmcb01 dirty after modifying VMCB intercepts commit d5bde6113aed8315a2bfe708730b721be9c2f48b upstream. When reacting to an intercept update, explicitly mark vmcb01's intercepts dirty, as KVM always initially operates on vmcb01, and nested_svm_vmexit() isn't guaranteed to mark VMCB_INTERCEPTS as dirty. I.e. if L2 is active, KVM will modify the intercepts for L1, but might not mark them as dirty before the next VMRUN of L1. Fixes: 116a0a23676e ("KVM: SVM: Add clean-bit for intercetps, tsc-offset and pause filter count") Cc: stable@vger.kernel.org Reviewed-by: Yosry Ahmed Link: https://patch.msgid.link/20260218230958.2877682-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit c15392ed9e49c1a16b4d3a3ccf1b3bf2318a6c28 Author: Kevin Cheng Date: Sat Feb 28 03:33:26 2026 +0000 KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0 commit d99df02ff427f461102230f9c5b90a6c64ee8e23 upstream. INVLPGA should cause a #UD when EFER.SVME is not set. Add a check to properly inject #UD when EFER.SVME=0. Fixes: ff092385e828 ("KVM: SVM: Implement INVLPGA") Cc: stable@vger.kernel.org Signed-off-by: Kevin Cheng Reviewed-by: Yosry Ahmed Link: https://patch.msgid.link/20260228033328.2285047-3-chengkev@google.com [sean: tag for stable@] Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 497f6af9679fc9c6ce2f438e11ed5d51b1aa8297 Author: Yosry Ahmed Date: Wed Feb 25 00:59:44 2026 +0000 KVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2 commit 03bee264f8ebfd39e0254c98e112d033a7aa9055 upstream. After VMRUN in guest mode, nested_sync_control_from_vmcb02() syncs fields written by the CPU from vmcb02 to the cached vmcb12. This is because the cached vmcb12 is used as the authoritative copy of some of the controls, and is the payload when saving/restoring nested state. int_state is also written by the CPU, specifically bit 0 (i.e. SVM_INTERRUPT_SHADOW_MASK) for nested VMs, but it is not sync'd to cached vmcb12. This does not cause a problem if KVM_SET_NESTED_STATE preceeds KVM_SET_VCPU_EVENTS in the restore path, as an interrupt shadow would be correctly restored to vmcb02 (KVM_SET_VCPU_EVENTS overwrites what KVM_SET_NESTED_STATE restored in int_state). However, if KVM_SET_VCPU_EVENTS preceeds KVM_SET_NESTED_STATE, an interrupt shadow would be restored into vmcb01 instead of vmcb02. This would mostly be benign for L1 (delays an interrupt), but not for L2. For L2, the vCPU could hang (e.g. if a wakeup interrupt is delivered before a HLT that should have been in an interrupt shadow). Sync int_state to the cached vmcb12 in nested_sync_control_from_vmcb02() to avoid this problem. With that, KVM_SET_NESTED_STATE restores the correct interrupt shadow state, and if KVM_SET_VCPU_EVENTS follows it would overwrite it with the same value. Fixes: cc440cdad5b7 ("KVM: nSVM: implement KVM_GET_NESTED_STATE and KVM_SET_NESTED_STATE") CC: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260225005950.3739782-3-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 076ab13fe3213f51820f0732611873aec5679b78 Author: Yosry Ahmed Date: Wed Feb 25 00:59:43 2026 +0000 KVM: nSVM: Sync NextRIP to cached vmcb12 after VMRUN of L2 commit 778d8c1b2a6ffe622ddcd3bb35b620e6e41f4da0 upstream. After VMRUN in guest mode, nested_sync_control_from_vmcb02() syncs fields written by the CPU from vmcb02 to the cached vmcb12. This is because the cached vmcb12 is used as the authoritative copy of some of the controls, and is the payload when saving/restoring nested state. NextRIP is also written by the CPU (in some cases) after VMRUN, but is not sync'd to the cached vmcb12. As a result, it is corrupted after save/restore (replaced by the original value written by L1 on nested VMRUN). This could cause problems for both KVM (e.g. when injecting a soft IRQ) or L1 (e.g. when using NextRIP to advance RIP after emulating an instruction). Fix this by sync'ing NextRIP to the cache after VMRUN of L2, but only after completing interrupts (not in nested_sync_control_from_vmcb02()), as KVM may update NextRIP (e.g. when re-injecting a soft IRQ). Fixes: cc440cdad5b7 ("KVM: nSVM: implement KVM_GET_NESTED_STATE and KVM_SET_NESTED_STATE") CC: stable@vger.kernel.org Co-developed-by: Sean Christopherson Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260225005950.3739782-2-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit e07ad47e53e9bfd132f3e3ac20c53970faa10f25 Author: Yosry Ahmed Date: Tue Feb 10 01:08:06 2026 +0000 KVM: nSVM: Mark all of vmcb02 dirty when restoring nested state commit e63fb1379f4b9300a44739964e69549bebbcdca4 upstream. When restoring a vCPU in guest mode, any state restored before KVM_SET_NESTED_STATE (e.g. KVM_SET_SREGS) will mark the corresponding dirty bits in vmcb01, as it is the active VMCB before switching to vmcb02 in svm_set_nested_state(). Hence, mark all fields in vmcb02 dirty in svm_set_nested_state() to capture any previously restored fields. Fixes: cc440cdad5b7 ("KVM: nSVM: implement KVM_GET_NESTED_STATE and KVM_SET_NESTED_STATE") CC: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260210010806.3204289-1-yosry.ahmed@linux.dev Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit c098979293dae1dcc59a3a269765e4136e77b065 Author: Sean Christopherson Date: Tue Feb 17 16:54:38 2026 -0800 KVM: x86: Defer non-architectural deliver of exception payload to userspace read commit d0ad1b05bbe6f8da159a4dfb6692b3b7ce30ccc8 upstream. When attempting to play nice with userspace that hasn't enabled KVM_CAP_EXCEPTION_PAYLOAD, defer KVM's non-architectural delivery of the payload until userspace actually reads relevant vCPU state, and more importantly, force delivery of the payload in *all* paths where userspace saves relevant vCPU state, not just KVM_GET_VCPU_EVENTS. Ignoring userspace save/restore for the moment, delivering the payload before the exception is injected is wrong regardless of whether L1 or L2 is running. To make matters even more confusing, the flaw *currently* being papered over by the !is_guest_mode() check isn't even the same bug that commit da998b46d244 ("kvm: x86: Defer setting of CR2 until #PF delivery") was trying to avoid. At the time of commit da998b46d244, KVM didn't correctly handle exception intercepts, as KVM would wait until VM-Entry into L2 was imminent to check if the queued exception should morph to a nested VM-Exit. I.e. KVM would deliver the payload to L2 and then synthesize a VM-Exit into L1. But the payload was only the most blatant issue, e.g. waiting to check exception intercepts would also lead to KVM incorrectly escalating a should-be-intercepted #PF into a #DF. That underlying bug was eventually fixed by commit 7709aba8f716 ("KVM: x86: Morph pending exceptions to pending VM-Exits at queue time"), but in the interim, commit a06230b62b89 ("KVM: x86: Deliver exception payload on KVM_GET_VCPU_EVENTS") came along and subtly added another dependency on the !is_guest_mode() check. While not recorded in the changelog, the motivation for deferring the !exception_payload_enabled delivery was to fix a flaw where a synthesized MTF (Monitor Trap Flag) VM-Exit would drop a pending #DB and clobber DR6. On a VM-Exit, VMX CPUs save pending #DB information into the VMCS, which is emulated by KVM in nested_vmx_update_pending_dbg() by grabbing the payload from the queue/pending exception. I.e. prematurely delivering the payload would cause the pending #DB to not be recorded in the VMCS, and of course, clobber L2's DR6 as seen by L1. Jumping back to save+restore, the quirked behavior of forcing delivery of the payload only works if userspace does KVM_GET_VCPU_EVENTS *before* CR2 or DR6 is saved, i.e. before KVM_GET_SREGS{,2} and KVM_GET_DEBUGREGS. E.g. if userspace does KVM_GET_SREGS before KVM_GET_VCPU_EVENTS, then the CR2 saved by userspace won't contain the payload for the exception save by KVM_GET_VCPU_EVENTS. Deliberately deliver the payload in the store_regs() path, as it's the least awful option even though userspace may not be doing save+restore. Because if userspace _is_ doing save restore, it could elide KVM_GET_SREGS knowing that SREGS were already saved when the vCPU exited. Link: https://lore.kernel.org/all/20200207103608.110305-1-oupton@google.com Cc: Yosry Ahmed Cc: stable@vger.kernel.org Reviewed-by: Yosry Ahmed Tested-by: Yosry Ahmed Link: https://patch.msgid.link/20260218005438.2619063-1-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 26f01d03775e4580b31dc9c79322d11af079f11f Author: Tao Cui Date: Thu Apr 9 18:56:36 2026 +0800 LoongArch: KVM: Use CSR_CRMD_PLV in kvm_arch_vcpu_in_kernel() commit da773ea3f59032f659bfc4c450ca86e384786168 upstream. The function reads LOONGARCH_CSR_CRMD but uses CSR_PRMD_PPLV to extract the privilege level. While both masks have the same value (0x3), CSR_CRMD_PLV is the semantically correct constant for CRMD. Cc: stable@vger.kernel.org Reviewed-by: Bibo Mao Signed-off-by: Tao Cui Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit fe06ea2f7b7f8eeec0d11cc9e411f907011b01d1 Author: Denis M. Karpov Date: Thu Apr 9 13:33:45 2026 +0300 userfaultfd: allow registration of ranges below mmap_min_addr commit 161ce69c2c89781784b945d8e281ff2da9dede9c upstream. The current implementation of validate_range() in fs/userfaultfd.c performs a hard check against mmap_min_addr. This is redundant because UFFDIO_REGISTER operates on memory ranges that must already be backed by a VMA. Enforcing mmap_min_addr or capability checks again in userfaultfd is unnecessary and prevents applications like binary compilers from using UFFD for valid memory regions mapped by application. Remove the redundant check for mmap_min_addr. We started using UFFD instead of the classic mprotect approach in the binary translator to track application writes. During development, we encountered this bug. The translator cannot control where the translated application chooses to map its memory and if the app requires a low-address area, UFFD fails, whereas mprotect would work just fine. I believe this is a genuine logic bug rather than an improvement, and I would appreciate including the fix in stable. Link: https://lore.kernel.org/20260409103345.15044-1-komlomal@gmail.com Fixes: 86039bd3b4e6 ("userfaultfd: add new syscall to provide memory externalization") Signed-off-by: Denis M. Karpov Reviewed-by: Lorenzo Stoakes Acked-by: Harry Yoo (Oracle) Reviewed-by: Pedro Falcato Reviewed-by: Liam R. Howlett Reviewed-by: Mike Rapoport (Microsoft) Cc: Alexander Viro Cc: Al Viro Cc: Christian Brauner Cc: Jan Kara Cc: Jann Horn Cc: Peter Xu Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 0fedd09ef95209a53dcea1aeb10976ce2a0b35d1 Author: SeongJae Park Date: Sun Mar 29 08:23:05 2026 -0700 mm/damon/core: use time_in_range_open() for damos quota window start commit 049a57421dd67a28c45ae7e92c36df758033e5fa upstream. damos_adjust_quota() uses time_after_eq() to show if it is time to start a new quota charge window, comparing the current jiffies and the scheduled next charge window start time. If it is, the next charge window start time is updated and the new charge window starts. The time check and next window start time update is skipped while the scheme is deactivated by the watermarks. Let's suppose the deactivation is kept more than LONG_MAX jiffies (assuming CONFIG_HZ of 250, more than 99 days in 32 bit systems and more than one billion years in 64 bit systems), resulting in having the jiffies larger than the next charge window start time + LONG_MAX. Then, the time_after_eq() call can return false until another LONG_MAX jiffies are passed. This means the scheme can continue working after being reactivated by the watermarks. But, soon, the quota will be exceeded and the scheme will again effectively stop working until the next charge window starts. Because the current charge window is extended to up to LONG_MAX jiffies, however, it will look like it stopped unexpectedly and indefinitely, from the user's perspective. Fix this by using !time_in_range_open() instead. The issue was discovered [1] by sashiko. Link: https://lore.kernel.org/20260329152306.45796-1-sj@kernel.org Link: https://lore.kernel.org/20260324040722.57944-1-sj@kernel.org [1] Fixes: ee801b7dd782 ("mm/damon/schemes: activate schemes based on a watermarks mechanism") Signed-off-by: SeongJae Park Cc: # 5.16.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b09958e235f2b9cd3898b85a8529172afa80d212 Author: SeongJae Park Date: Sat Mar 28 21:38:59 2026 -0700 mm/damon/core: validate damos_quota_goal->nid for node_mem_{used,free}_bp commit 40250b2dded0604a112be605f3828700d80ad7c2 upstream. Patch series "mm/damon/core: validate damos_quota_goal->nid". node_mem[cg]_{used,free}_bp DAMOS quota goals receive the node id. The node id is used for si_meminfo_node() and NODE_DATA() without proper validation. As a result, privileged users can trigger an out of bounds memory access using DAMON_SYSFS. Fix the issues. The issue was originally reported [1] with a fix by another author. The original author announced [2] that they will stop working including the fix that was still in the review stage. Hence I'm restarting this. This patch (of 2): Users can set damos_quota_goal->nid with arbitrary value for node_mem_{used,free}_bp. But DAMON core is using those for si_meminfo_node() without the validation of the value. This can result in out of bounds memory access. The issue can actually triggered using DAMON user-space tool (damo), like below. $ sudo ./damo start --damos_action stat \ --damos_quota_goal node_mem_used_bp 50% -1 \ --damos_quota_interval 1s $ sudo dmesg [...] [ 65.565986] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098 Fix this issue by adding the validation of the given node. If an invalid node id is given, it returns 0% for used memory ratio, and 100% for free memory ratio. Link: https://lore.kernel.org/20260329043902.46163-2-sj@kernel.org Link: https://lore.kernel.org/20260325073034.140353-1-objecting@objecting.org [1] Link: https://lore.kernel.org/20260327040924.68553-1-sj@kernel.org [2] Fixes: 0e1c773b501f ("mm/damon/core: introduce damos quota goal metrics for memory node utilization") Signed-off-by: SeongJae Park Cc: # 6.16.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 8a62c58411cbd748d7aeab0e5b0963e33ff47a7a Author: Jackie Liu Date: Tue Mar 31 18:15:53 2026 +0800 mm/damon/stat: fix memory leak on damon_start() failure in damon_stat_start() commit e04ed278d25bf15769800bf6e35c6737f137186f upstream. Destroy the DAMON context and reset the global pointer when damon_start() fails. Otherwise, the context allocated by damon_stat_build_ctx() is leaked, and the stale damon_stat_context pointer will be overwritten on the next enable attempt, making the old allocation permanently unreachable. Link: https://lore.kernel.org/20260331101553.88422-1-liu.yun@linux.dev Fixes: 369c415e6073 ("mm/damon: introduce DAMON_STAT module") Signed-off-by: Jackie Liu Reviewed-by: SeongJae Park Cc: # 6.17.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit c42a7efb9060d89b72708ffaf255d0002c2164a7 Author: Jackie Liu Date: Wed Apr 1 08:57:02 2026 +0800 mm/mempolicy: fix memory leaks in weighted_interleave_auto_store() commit 6fae274ce0e3109cbbc4c18b354eaace1f0af7d7 upstream. weighted_interleave_auto_store() fetches old_wi_state inside the if (!input) block only. This causes two memory leaks: 1. When a user writes "false" and the current mode is already manual, the function returns early without freeing the freshly allocated new_wi_state. 2. When a user writes "true", old_wi_state stays NULL because the fetch is skipped entirely. The old state is then overwritten by rcu_assign_pointer() but never freed, since the cleanup path is gated on old_wi_state being non-NULL. A user can trigger this repeatedly by writing "1" in a loop. Fix both leaks by moving the old_wi_state fetch before the input check, making it unconditional. This also allows a unified early return for both "true" and "false" when the requested mode matches the current mode. Link: https://lore.kernel.org/20260401005702.7096-1-liu.yun@linux.dev Link: https://sashiko.dev/#/patchset/20260331100740.84906-1-liu.yun@linux.dev Fixes: e341f9c3c841 ("mm/mempolicy: Weighted Interleave Auto-tuning") Signed-off-by: Jackie Liu Reviewed-by: Joshua Hahn Reviewed by: Donet Tom Cc: Gregory Price Cc: Alistair Popple Cc: Byungchul Park Cc: David Hildenbrand Cc: # v6.16+ Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 687ccdf582169cd680aeaf24cc953807c4cd4345 Author: Uladzislau Rezki (Sony) Date: Mon Apr 13 21:26:46 2026 +0200 mm/vmalloc: take vmap_purge_lock in shrinker commit ec05f51f1e65bce95528543eb73fda56fd201d94 upstream. decay_va_pool_node() can be invoked concurrently from two paths: __purge_vmap_area_lazy() when pools are being purged, and the shrinker via vmap_node_shrink_scan(). However, decay_va_pool_node() is not safe to run concurrently, and the shrinker path currently lacks serialization, leading to races and possible leaks. Protect decay_va_pool_node() by taking vmap_purge_lock in the shrinker path to ensure serialization with purge users. Link: https://lore.kernel.org/20260413192646.14683-1-urezki@gmail.com Fixes: 7679ba6b36db ("mm: vmalloc: add a shrinker to drain vmap pools") Signed-off-by: Uladzislau Rezki (Sony) Reviewed-by: Baoquan He Cc: chenyichong Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 5184e2c065e3b667663300f104d1053d7cfb2eb0 Author: Johan Hovold Date: Tue Apr 7 14:27:17 2026 +0200 rtc: ntxec: fix OF node reference imbalance commit 30c4d2f26bb3538c328035cea2e6265c8320539e 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: 435af89786c6 ("rtc: New driver for RTC in Netronix embedded controller") Cc: stable@vger.kernel.org # 5.13 Cc: Jonathan Neuschäfer Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260407122717.2676774-1-johan@kernel.org Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit b5856e85a1f0b9fb6d03fcacfb58ce7a07f1d7ea Author: Jacqueline Wong Date: Wed Apr 15 16:00:06 2026 +0000 tpm: tpm_tis: stop transmit if retries are exhausted commit 949692da7211572fac419b2986b6abc0cd1aeb76 upstream. tpm_tis_send_main() will attempt to retry sending data TPM_RETRY times. Currently, if those retries are exhausted, the driver will attempt to call execute. The TPM will be in the wrong state, leading to the operation simply timing out. Instead, if there is still an error after retries are exhausted, return that error immediately. Cc: stable@vger.kernel.org # v6.6+ Fixes: 280db21e153d8 ("tpm_tis: Resend command to recover from data transfer errors") Signed-off-by: Jacqueline Wong Signed-off-by: Jordan Hand Link: https://lore.kernel.org/r/20260415160006.2275325-3-jacqwong@google.com Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 6503775a5c4161dbdd2174bccdb9901dc09c2b07 Author: Jacqueline Wong Date: Wed Apr 15 16:00:05 2026 +0000 tpm: tpm_tis: add error logging for data transfer commit 0471921e2d1043dcc6de5cffb49dd37709521abe upstream. Add logging to more easily determine reason for transmit failure Cc: stable@vger.kernel.org # v6.6+ Fixes: 280db21e153d8 ("tpm_tis: Resend command to recover from data transfer errors") Signed-off-by: Jacqueline Wong Signed-off-by: Jordan Hand Link: https://lore.kernel.org/r/20260415160006.2275325-2-jacqwong@google.com Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 53e6d2d834df40960b655b353e7a8ff4d927e1c7 Author: Gunnar Kudrjavets Date: Thu Apr 9 17:20:54 2026 +0000 tpm: Use kfree_sensitive() to free auth session in tpm_dev_release() commit c424d2664f08c77f08b4580b5f0cbaabf7c229b2 upstream. tpm_dev_release() uses plain kfree() to free chip->auth, which contains sensitive cryptographic material including HMAC session keys, nonces, and passphrase data (struct tpm2_auth). Every other code path that frees this structure uses kfree_sensitive() to zero the memory before releasing it: both tpm2_end_auth_session() and tpm_buf_check_hmac_response() do so. The tpm_dev_release() path is the only one that does not, leaving key material in freed slab memory until it is eventually overwritten. Use kfree_sensitive() for consistency with the rest of the driver and to ensure session keys are scrubbed during device teardown. Cc: stable@vger.kernel.org # v6.10+ Fixes: 699e3efd6c64 ("tpm: Add HMAC session start and end functions") Signed-off-by: Gunnar Kudrjavets Reviewed-by: Justinien Bouron Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 726ce504235956f4d0a0422ec843aee762c7a36a Author: Gunnar Kudrjavets Date: Wed Apr 8 12:00:27 2026 +0300 tpm: Fix auth session leak in tpm2_get_random() error path commit 666c1a2ca603d8314231200bf8bbb3a81bd64c6b upstream. When tpm_buf_fill_hmac_session() fails inside the do-while loop in tpm2_get_random(), the function returns directly after destroying the buffer, without ending the auth session via tpm2_end_auth_session(). This leaks the TPM auth session resource. All other error paths within the loop correctly reach the 'out' label which calls both tpm_buf_destroy() and tpm2_end_auth_session(). Fix this by replacing the early return with a goto to the existing 'out' label, which already handles both cleanup operations. The redundant tpm_buf_destroy() call is removed since 'out' takes care of it. Cc: stable@vger.kernel.org # v6.19+ Fixes: 6e9722e9a7bf ("tpm2-sessions: Fix out of range indexing in name_size") Signed-off-by: Gunnar Kudrjavets Reviewed-by: Justinien Bouron Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit f8775d9d9062da662cc861f9ff7722a65896d4cd Author: Gunnar Kudrjavets Date: Wed Apr 15 03:00:03 2026 +0300 tpm2-sessions: Fix missing tpm_buf_destroy() in tpm2_read_public() commit f0f75a3d98b7959a8677b6363e23190f3018636b upstream. tpm2_read_public() calls tpm_buf_init() but fails to call tpm_buf_destroy() on two exit paths, leaking a page allocation: 1. When name_size() returns an error (unrecognized hash algorithm), the function returns directly without destroying the buffer. 2. On the success path, the buffer is never destroyed before returning. All other error paths in the function correctly call tpm_buf_destroy() before returning. Fix both by adding the missing tpm_buf_destroy() calls. Cc: stable@vger.kernel.org # v6.19+ Fixes: bda1cbf73c6e ("tpm2-sessions: Fix tpm2_read_public range checks") Signed-off-by: Gunnar Kudrjavets Reviewed-by: Justinien Bouron Reviewed-by: Paul Menzel Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 82aa32a4d69707fa71a4b0ce1fd246f412fb8e26 Author: Viorel Suman (OSS) Date: Wed Mar 11 14:33:09 2026 +0200 pwm: imx-tpm: Count the number of enabled channels in probe commit 3962c24f2d14e8a7f8a23f56b7ce320523947342 upstream. On a soft reset TPM PWM IP may preserve its internal state from previous runtime, therefore on a subsequent OS boot and driver probe "enable_count" value and TPM PWM IP internal channels "enabled" states may get unaligned. In consequence on a suspend/resume cycle the call "if (--tpm->enable_count == 0)" may lead to "enable_count" overflow the system being blocked from entering suspend due to: if (tpm->enable_count > 0) return -EBUSY; Fix the problem by counting the enabled channels in probe function. Signed-off-by: Viorel Suman (OSS) Fixes: 738a1cfec2ed ("pwm: Add i.MX TPM PWM driver support") Link: https://patch.msgid.link/20260311123309.348904-1-viorel.suman@oss.nxp.com Cc: stable@vger.kernel.org Signed-off-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman commit dedaa897b9d785aeb311344d4459cdaf0382e884 Author: Paul Louvel Date: Mon Mar 30 12:28:19 2026 +0200 crypto: talitos - rename first/last to first_desc/last_desc commit a1b80018b8cec27fc06a8b04a7f8b5f6cfe86eae upstream. Previous commit introduces a new last_request variable in the context structure. Renaming the first/last existing member variable in the context structure to improve readability. Cc: stable@vger.kernel.org Signed-off-by: Paul Louvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 4861d6cd923f9c218f3be6a0e4488b7ccdd0f83a Author: Paul Louvel Date: Mon Mar 30 12:28:18 2026 +0200 crypto: talitos - fix SEC1 32k ahash request limitation commit 655ef638a2bc3cd0a9eff99a02f83cab94a3a917 upstream. Since commit c662b043cdca ("crypto: af_alg/hash: Support MSG_SPLICE_PAGES"), the crypto core may pass large scatterlists spanning multiple pages to drivers supporting ahash operations. As a result, a driver can now receive large ahash requests. The SEC1 engine has a limitation where a single descriptor cannot process more than 32k of data. The current implementation attempts to handle the entire request within a single descriptor, which leads to failures raised by the driver: "length exceeds h/w max limit" Address this limitation by splitting large ahash requests into multiple descriptors, each respecting the 32k hardware limit. This allows processing arbitrarily large requests. Cc: stable@vger.kernel.org Fixes: c662b043cdca ("crypto: af_alg/hash: Support MSG_SPLICE_PAGES") Signed-off-by: Paul Louvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 75d40ccf38ca7768e85eb8e369c0ad543c4e0964 Author: Thomas Zimmermann Date: Tue Feb 17 16:56:11 2026 +0100 firmware: google: framebuffer: Do not unregister platform device commit 5cd28bd28c8ce426b56ce4230dbd17537181d5ad upstream. The native driver takes over the framebuffer aperture by removing the system- framebuffer platform device. Afterwards the pointer in drvdata is dangling. Remove the entire logic around drvdata and let the kernel's aperture helpers handle this. The platform device depends on the native hardware device instead of the coreboot device anyway. When commit 851b4c14532d ("firmware: coreboot: Add coreboot framebuffer driver") added the coreboot framebuffer code, the kernel did not support device-based aperture management. Instead native driviers only removed the conflicting fbdev device. At that point, unregistering the framebuffer device most likely worked correctly. It was definitely broken after commit d9702b2a2171 ("fbdev/simplefb: Do not use struct fb_info.apertures"). So take this commit for the Fixes tag. Earlier releases might work depending on the native hardware driver. Signed-off-by: Thomas Zimmermann Fixes: d9702b2a2171 ("fbdev/simplefb: Do not use struct fb_info.apertures") Acked-by: Tzung-Bi Shih Acked-by: Julius Werner Cc: Thomas Zimmermann Cc: Javier Martinez Canillas Cc: Hans de Goede Cc: linux-fbdev@vger.kernel.org Cc: # v6.3+ Link: https://patch.msgid.link/20260217155836.96267-2-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit 5c293a1e1ef0f838772d20ae8afae4cbd87cd3f9 Author: Haoxiang Li Date: Wed Apr 1 12:02:41 2026 +0800 xfs: fix a resource leak in xfs_alloc_buftarg() commit 29a7b2614357393b176ef06ba5bc3ff5afc8df69 upstream. In the error path, call fs_put_dax() to drop the DAX device reference. Fixes: 6f643c57d57c ("xfs: implement ->notify_failure() for XFS") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit fe570daa51930b066a4ecc2086df308e88a95d0e Author: Hans Holmberg Date: Wed Mar 25 13:43:12 2026 +0100 xfs: start gc on zonegc_low_space attribute updates commit 181ea4e2de422aa0a66f355bd59bccccdd169826 upstream. Start gc if the agressiveness of zone garbage collection is changed by the user (if the file system is not read only). Without this change, the new setting will not be taken into account until the gc thread is woken up by e.g. a write. Cc: stable@vger.kernel.org # v6.15 Fixes: 845abeb1f06a8a ("xfs: add tunable threshold parameter for triggering zone GC") Signed-off-by: Hans Holmberg Reviewed-by: Christoph Hellwig Reviewed-by: Damien Le Moal Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 27f561bf894e46bdc2d6209c50884adad79d8277 Author: Giovanni Cabiddu Date: Wed Apr 1 10:31:11 2026 +0100 crypto: qat - fix IRQ cleanup on 6xxx probe failure commit 95aed2af87ec43fa7624cc81dd13d37824ad4972 upstream. When adf_dev_up() partially completes and then fails, the IRQ handlers registered during adf_isr_resource_alloc() are not detached before the MSI-X vectors are released. Since the device is enabled with pcim_enable_device(), calling pci_alloc_irq_vectors() internally registers pcim_msi_release() as a devres action. On probe failure, devres runs pcim_msi_release() which calls pci_free_irq_vectors(), tearing down the MSI-X vectors while IRQ handlers (for example 'qat0-bundle0') are still attached. This causes remove_proc_entry() warnings: [ 22.163964] remove_proc_entry: removing non-empty directory 'irq/143', leaking at least 'qat0-bundle0' Moving the devm_add_action_or_reset() before adf_dev_up() does not solve the problem since devres runs in LIFO order and pcim_msi_release(), registered later inside adf_dev_up(), would still fire before adf_device_down(). Fix by calling adf_dev_down() explicitly when adf_dev_up() fails, to properly free IRQ handlers before devres releases the MSI-X vectors. Fixes: 17fd7514ae68 ("crypto: qat - add qat_6xxx driver") Cc: stable@vger.kernel.org Signed-off-by: Giovanni Cabiddu Reviewed-by: Ahsan Atta Reviewed-by: Laurent M Coquerel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 6d8087a7d0f342dfeb341dc75e10009613b10753 Author: Francesco Dolcini Date: Fri Mar 20 08:30:30 2026 +0100 arm64: dts: ti: am62-verdin: Enable pullup for eMMC data pins commit d5325810814ee995debfa0b6c4a22e0391598bef upstream. Verdin AM62 board does not have external pullups on eMMC DAT1-DAT7 pins. Enable internal pullups on DAT1-DAT7 considering: - without a host-side pullup, these lines rely solely on the eMMC device's internal pullup (R_int, 10kohm-150kohm per JEDEC), which may exceed the recommended 50kohm max for 1.8V VCCQ - JEDEC JESD84-B51 Table 200 requires host-side pullups (R_DAT, 10kohm-100kohm) on all data lines to prevent bus floating Fixes: 316b80246b16 ("arm64: dts: ti: add verdin am62") Cc: stable@vger.kernel.org Signed-off-by: Francesco Dolcini Link: https://patch.msgid.link/20260320073032.10427-1-francesco@dolcini.it Signed-off-by: Vignesh Raghavendra Signed-off-by: Greg Kroah-Hartman commit 52e1a80bacc66863aca1c3a9ef0dc2da76ca42b3 Author: Shawn Lin Date: Wed Apr 8 15:18:49 2026 +0800 mmc: sdhci-of-dwcmshc: Disable clock before DLL configuration commit 6546a49bbe656981d99a389195560999058c89c4 upstream. According to the ASIC design recommendations, the clock must be disabled before operating the DLL to prevent glitches that could affect the internal digital logic. In extreme cases, failing to do so may cause the controller to malfunction completely. Adds a step to disable the clock before DLL configuration and re-enables it at the end. Fixes: 08f3dff799d4 ("mmc: sdhci-of-dwcmshc: add rockchip platform support") Cc: stable@vger.kernel.org Signed-off-by: Shawn Lin Acked-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit d73c3a4070dce0f86a64415c00ac090cf462be5d Author: Bin Liu Date: Wed Mar 25 08:49:47 2026 -0500 mmc: block: use single block write in retry commit c7c6d4f5103864f73ee3a78bfd6da241f84197dd upstream. Due to errata i2493[0], multi-block write would still fail in retries. With i2493, the MMC interface has the potential of write failures when issuing multi-block writes operating in HS200 mode with excessive IO supply noise. While the errata provides guidance in hardware design and layout to minimize the IO supply noise, in theory the write failure cannot be resolved in hardware. The software solution to ensure the data integrity is to add minimum 5us delay between block writes. Single-block write is the practical way to introduce the delay. This patch reuses recovery_mode flag, and switches to single-block write in retry when multi-block write fails. It covers both CQE and non-CQE cases. [0] https://www.ti.com/lit/pdf/sprz582 Cc: stable@vger.kernel.org Suggested-by: Jens Axboe Signed-off-by: Bin Liu Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit d780f24a4939862e1df9def415fe7de59280fc7c Author: Ryan Roberts Date: Tue Mar 3 15:08:38 2026 +0000 randomize_kstack: Maintain kstack_offset per task commit 37beb42560165869838e7d91724f3e629db64129 upstream. kstack_offset was previously maintained per-cpu, but this caused a couple of issues. So let's instead make it per-task. Issue 1: add_random_kstack_offset() and choose_random_kstack_offset() expected and required to be called with interrupts and preemption disabled so that it could manipulate per-cpu state. But arm64, loongarch and risc-v are calling them with interrupts and preemption enabled. I don't _think_ this causes any functional issues, but it's certainly unexpected and could lead to manipulating the wrong cpu's state, which could cause a minor performance degradation due to bouncing the cache lines. By maintaining the state per-task those functions can safely be called in preemptible context. Issue 2: add_random_kstack_offset() is called before executing the syscall and expands the stack using a previously chosen random offset. choose_random_kstack_offset() is called after executing the syscall and chooses and stores a new random offset for the next syscall. With per-cpu storage for this offset, an attacker could force cpu migration during the execution of the syscall and prevent the offset from being updated for the original cpu such that it is predictable for the next syscall on that cpu. By maintaining the state per-task, this problem goes away because the per-task random offset is updated after the syscall regardless of which cpu it is executing on. Fixes: 39218ff4c625 ("stack: Optionally randomize kernel stack offset each syscall") Closes: https://lore.kernel.org/all/dd8c37bc-795f-4c7a-9086-69e584d8ab24@arm.com/ Cc: stable@vger.kernel.org Acked-by: Mark Rutland Signed-off-by: Ryan Roberts Link: https://patch.msgid.link/20260303150840.3789438-2-ryan.roberts@arm.com Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman commit 95d48e37a1304d6148406c799479c0fb505aefa7 Author: Sanman Pradhan Date: Fri Apr 10 00:25:55 2026 +0000 hwmon: (pt5161l) Fix bugs in pt5161l_read_block_data() commit 24c73e93d6a756e1b8626bb259d2e07c5b89b370 upstream. Fix two bugs in pt5161l_read_block_data(): 1. Buffer overrun: The local buffer rbuf is declared as u8 rbuf[24], but i2c_smbus_read_block_data() can return up to I2C_SMBUS_BLOCK_MAX (32) bytes. The i2c-core copies the data into the caller's buffer before the return value can be checked, so the post-read length validation does not prevent a stack overrun if a device returns more than 24 bytes. Resize the buffer to I2C_SMBUS_BLOCK_MAX. 2. Unexpected positive return on length mismatch: When all three retries are exhausted because the device returns data with an unexpected length, i2c_smbus_read_block_data() returns a positive byte count. The function returns this directly, and callers treat any non-negative return as success, processing stale or incomplete buffer contents. Return -EIO when retries are exhausted with a positive return value, preserving the negative error code on I2C failure. Fixes: 1b2ca93cd0592 ("hwmon: Add driver for Astera Labs PT5161L retimer") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan Link: https://lore.kernel.org/r/20260410002549.424162-1-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 6b11dfb3c5173ef7ce69fe48cdeb23d3118464a0 Author: Brahmajit Das Date: Mon Dec 22 00:25:31 2025 +0530 ASoC: Intel: avs: replace strcmp with sysfs_streq commit 45e9066f3a487e9e26b842644364d045af054775 upstream. allmodconfig failes to build with GCC 16 with the following build error sound/soc/intel/avs/path.c:137:38: error: ‘strcmp’ reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread] 137 | return id->id == id2->id && !strcmp(id->tplg_name, id2->tplg_name); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ‘avs_condpaths_walk’: events 1-3 137 | return id->id == id2->id && !strcmp(id->tplg_name, id2->tplg_name); | ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | | | (3) warning happens here | (1) when the condition is evaluated to true ...... 155 | if (id->id != path->template->owner->id || | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | (2) when the condition is evaluated to false 156 | strcmp(id->tplg_name, path->template->owner->owner->name)) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from sound/soc/intel/avs/path.h:14, from sound/soc/intel/avs/path.c:15: sound/soc/intel/avs/topology.h: In function ‘avs_condpaths_walk’: sound/soc/intel/avs/topology.h:152:13: note: at offset 4 into source object ‘id’ of size 4 152 | u32 id; | ^~ Using the sysfs_streq as an alternative to strcmp helps getting around this build failure. Please also refer https://docs.kernel.org/core-api/kernel-api.html#c.__sysfs_match_string Signed-off-by: Brahmajit Das Link: https://patch.msgid.link/20251221185531.6453-1-listout@listout.xyz Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 77eb3e79a3e75b1dff8d8a8a6772a7d0ceaeccb5 Author: Tiezhu Yang Date: Thu Oct 16 14:51:17 2025 +0800 drm/amd: Fix set but not used warnings commit 46791d147d3ab3262298478106ef2a52fc7192e2 upstream. There are many set but not used warnings under drivers/gpu/drm/amd when compiling with the latest upstream mainline GCC: drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c:305:18: warning: variable ‘p’ set but not used [-Wunused-but-set-variable=] drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h:103:26: warning: variable ‘internal_reg_offset’ set but not used [-Wunused-but-set-variable=] ... drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h:164:26: warning: variable ‘internal_reg_offset’ set but not used [-Wunused-but-set-variable=] ... drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:445:13: warning: variable ‘pipe_idx’ set but not used [-Wunused-but-set-variable=] drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:875:21: warning: variable ‘pipe_idx’ set but not used [-Wunused-but-set-variable=] Remove the variables actually not used or add __maybe_unused attribute for the variables actually used to fix them, compile tested only. Signed-off-by: Tiezhu Yang Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit b3166d1657534a6cc598adc8745d9b9a96b81e90 Author: Amir Goldstein Date: Mon Mar 30 10:27:51 2026 +0200 fs: prepare for adding LSM blob to backing_file commit 880bd496ec72a6dcb00cb70c430ef752ba242ae7 upstream. In preparation to adding LSM blob to backing_file struct, factor out helpers init_backing_file() and backing_file_free(). Cc: stable@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org Cc: linux-unionfs@vger.kernel.org Cc: linux-erofs@lists.ozlabs.org Signed-off-by: Amir Goldstein Reviewed-by: Serge Hallyn [PM: use the term "LSM blob", fix comment style to match file] Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit b69a8729f84a8f3a471cbd331957c27675ede140 Author: Sanman Pradhan Date: Fri Apr 10 00:26:19 2026 +0000 hwmon: (isl28022) Fix integer overflow in power calculation on 32-bit commit a7c0aaa50e40ffd8fd703d006d5a04b540b9ca92 upstream. isl28022_read_power() computes: *val = ((51200000L * ((long)data->gain)) / (long)data->shunt) * (long)regval; On 32-bit platforms, 'long' is 32 bits. With gain=8 and shunt=10000 (the default configuration): (51200000 * 8) / 10000 = 40960 40960 * 65535 = 2,684,313,600 This exceeds LONG_MAX (2,147,483,647), resulting in signed integer overflow. Additionally, dividing before multiplying by regval loses precision unnecessarily. Use u64 arithmetic with div_u64() and multiply before dividing to retain precision. The intermediate product cannot overflow u64 (worst case: 51200000 * 8 * 65535 = 26843136000000). Power is inherently non-negative, so unsigned types are the natural fit. Cap the result to LONG_MAX before returning it through the hwmon callback. Fixes: 39671a14df4f2 ("hwmon: (isl28022) new driver for ISL28022 power monitor") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan Link: https://lore.kernel.org/r/20260410002613.424557-1-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit bff7dbfc326a295b3f82eda9280bf020eb84461e Author: Krzysztof Kozlowski Date: Fri Feb 20 18:49:39 2026 +0100 power: supply: axp288_charger: Do not cancel work before initializing it commit 658342fd75b582cbb06544d513171c3d645faead upstream. Driver registered devm handler to cancel_work_sync() before even the work was initialized, thus leading to possible warning from kernel/workqueue.c on (!work->func) check, if the error path was hit before the initialization happened. Use devm_work_autocancel() on each work item independently, which handles the initialization and handler to cancel work. Fixes: 165c2357744e ("power: supply: axp288_charger: Properly stop work on probe-error / remove") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski Reviewed-by: Hans de Goede Reviewed-by: Chen-Yu Tsai Link: https://patch.msgid.link/20260220174938.672883-5-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 988eff645be4e54dc01060f9660b1415d59d550a Author: Huacai Chen Date: Wed Apr 22 15:45:12 2026 +0800 LoongArch: Show CPU vulnerabilites correctly commit 37e57e8ad96cdec4a57b55fd10bef50f7370a954 upstream. Most LoongArch processors are vulnerable to Spectre-V1 Proof-of-Concept (PoC). And the generic mechanism, __user pointer sanitization, can be used as a mitigation. This means to use array_index_nospec() to prevent out of boundry access in syscall and other critical paths. Implement the arch-specific cpu_show_spectre_v1() to show CPU Spectre-V1 vulnerabilites correctly. Cc: stable@vger.kernel.org Link: https://cc-sw.com/chinese-loongarch-architecture-evaluation-part-3-of-3/ Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit c5dfddc57f1b6b4e4df6610e917baceb114b8f6e Author: Arnd Bergmann Date: Fri Mar 22 14:22:48 2024 +0100 tpm: avoid -Wunused-but-set-variable commit 6f1d4d2ecfcd1b577dc87350ea965fe81f272e83 upstream. Outside of the EFI tpm code, the TPM_MEMREMAP()/TPM_MEMUNMAP functions are defined as trivial macros, leading to the mapping_size variable ending up unused: In file included from drivers/char/tpm/tpm-sysfs.c:16: In file included from drivers/char/tpm/tpm.h:28: include/linux/tpm_eventlog.h:167:6: error: variable 'mapping_size' set but not used [-Werror,-Wunused-but-set-variable] 167 | int mapping_size; Turn the stubs into inline functions to avoid this warning. Cc: stable@vger.kernel.org # v5.3+ Fixes: c46f3405692d ("tpm: Reserve the TPM final events table") Signed-off-by: Arnd Bergmann Reviewed-by: Thorsten Blum Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 80f54d6f91426b9994e9074e8e167547859622f3 Author: Nathan Chancellor Date: Wed Mar 25 18:19:15 2026 -0700 extract-cert: Wrap key_pass with '#ifdef USE_PKCS11_ENGINE' commit 4f96b7c68a9904e01049ef610d701b382dca9574 upstream. A recent strengthening of -Wunused-but-set-variable (enabled with -Wall) in clang under a new subwarning, -Wunused-but-set-global, points out an unused static global variable in certs/extract-cert.c: certs/extract-cert.c:46:20: error: variable 'key_pass' set but not used [-Werror,-Wunused-but-set-global] 46 | static const char *key_pass; | ^ After commit 558bdc45dfb2 ("sign-file,extract-cert: use pkcs11 provider for OPENSSL MAJOR >= 3"), key_pass is only used with the OpenSSL engine API, not the new provider API. Wrap key_pass's declaration and assignment with '#ifdef USE_PKCS11_ENGINE' so that it is only included with its use to clear up the warning. While this is a little uglier than just marking key_pass with the unused attribute, this will make it easier to clean up all code associated with the use of the engine API if it were ever removed in the future. While in the area, use a tab for the key_pass assignment line to match the rest of the file. Cc: stable@vger.kernel.org Fixes: 558bdc45dfb2 ("sign-file,extract-cert: use pkcs11 provider for OPENSSL MAJOR >= 3") Reviewed-by: Nick Desaulniers Tested-by: Nick Desaulniers Link: https://patch.msgid.link/20260325-certs-extract-cert-key_pass-unused-but-set-global-v1-1-ecf94326d532@kernel.org Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit 11baa8b24bcb07ae2048f2566a220021d766abe0 Author: Johan Hovold Date: Fri Apr 10 17:49:06 2026 +0200 spi: fix resource leaks on device setup failure commit db357034f7e0cf23f233f414a8508312dfe8fbbe upstream. Make sure to call controller cleanup() if spi_setup() fails while registering a device to avoid leaking any resources allocated by setup(). Fixes: c7299fea6769 ("spi: Fix spi device unregister flow") Cc: stable@vger.kernel.org # 5.13 Cc: Saravana Kannan Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410154907.129248-2-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 016bc663657366d386993f63eb31072eb45a2b77 Author: Raphael Zimmer Date: Wed Mar 18 18:09:03 2026 +0100 libceph: Prevent potential null-ptr-deref in ceph_handle_auth_reply() commit 5199c125d25aeae8615c4fc31652cc0fe624338e upstream. If a message of type CEPH_MSG_AUTH_REPLY contains a zero value for both protocol and result, this is currently not treated as an error. In case of ac->negotiating == true and ac->protocol > 0, this leads to setting ac->protocol = 0 and ac->ops = NULL. Thereafter, the check for ac->protocol != protocol returns false, and init_protocol() is not called. Subsequently, ac->ops->handle_reply() is called, which leads to a null pointer dereference, because ac->ops is still NULL. This patch changes the check for ac->protocol != protocol to !ac->protocol, as this also includes the case when the protocol was set to zero in the message. This causes the message to be treated as containing a bad auth protocol. Cc: stable@vger.kernel.org Signed-off-by: Raphael Zimmer Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit c2178ff1c70ebfc2ab9651b230c58a34683db759 Author: Ruide Cao Date: Tue Apr 21 12:16:31 2026 +0800 ipv4: icmp: validate reply type before using icmp_pointers commit 67bf002a2d7387a6312138210d0bd06e3cf4879b upstream. Extended echo replies use ICMP_EXT_ECHOREPLY as the outbound reply type. That value is outside the range covered by icmp_pointers[], which only describes the traditional ICMP types up to NR_ICMP_TYPES. Avoid consulting icmp_pointers[] for reply types outside that range, and use array_index_nospec() for the remaining in-range lookup. Normal ICMP replies keep their existing behavior unchanged. Fixes: d329ea5bd884 ("icmp: add response to RFC 8335 PROBE messages") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Ruide Cao Signed-off-by: Ren Wei Reviewed-by: Simon Horman Link: https://patch.msgid.link/0dace90c01a5978e829ca741ef684dbd7304ce62.1776628519.git.caoruide123@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9b924f3a26b21330a837cfe72e819b6393bbeeaa Author: hkbinbin Date: Wed Apr 1 12:19:07 2026 +0000 RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv commit 7244491dab347f648e661da96dc0febadd9daec3 upstream. rxe_rcv() currently checks only that the incoming packet is at least header_size(pkt) bytes long before payload_size() is used. However, payload_size() subtracts both the attacker-controlled BTH pad field and RXE_ICRC_SIZE from pkt->paylen: payload_size = pkt->paylen - offset[RXE_PAYLOAD] - bth_pad(pkt) - RXE_ICRC_SIZE This means a short packet can still make payload_size() underflow even if it includes enough bytes for the fixed headers. Simply requiring header_size(pkt) + RXE_ICRC_SIZE is not sufficient either, because a packet with a forged non-zero BTH pad can still leave payload_size() negative and pass an underflowed value to later receive-path users. Fix this by validating pkt->paylen against the full minimum length required by payload_size(): header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE. Cc: stable@vger.kernel.org Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://patch.msgid.link/r/20260401121907.1468366-1-hkbinbinbin@gmail.com Signed-off-by: hkbinbin Reviewed-by: Zhu Yanjun Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit f344f04e33bfeb8655996f0c6c71e460e86d4319 Author: Masami Hiramatsu (Google) Date: Mon Apr 20 23:00:48 2026 +0900 tracing/fprobe: Reject registration of a registered fprobe before init commit 6ad51ada17ed80c9a5f205b4c01c424cac8b0d46 upstream. Reject registration of a registered fprobe which is on the fprobe hash table before initializing fprobe. The add_fprobe_hash() checks this re-register fprobe, but since fprobe_init() clears hlist_array field, it is too late to check it. It has to check the re-registration before touncing fprobe. Link: https://lore.kernel.org/all/177669364845.132053.18375367916162315835.stgit@mhiramat.tok.corp.google.com/ Fixes: 4346ba160409 ("fprobe: Rewrite fprobe on function-graph tracer") Cc: stable@vger.kernel.org Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman commit 38387ccc0fbe38d14fb4c2ad7ee1d7404e5e59fd Author: Marco Elver Date: Thu Apr 16 15:25:07 2026 +0200 slub: fix data loss and overflow in krealloc() commit 082a6d03a2d685a83a332666b500ad3966349588 upstream. Commit 2cd8231796b5 ("mm/slub: allow to set node and align in k[v]realloc") introduced the ability to force a reallocation if the original object does not satisfy new alignment or NUMA node, even when the object is being shrunk. This introduced two bugs in the reallocation fallback path: 1. Data loss during NUMA migration: The jump to 'alloc_new' happens before 'ks' and 'orig_size' are initialized. As a result, the memcpy() in the 'alloc_new' block would copy 0 bytes into the new allocation. 2. Buffer overflow during shrinking: When shrinking an object while forcing a new alignment, 'new_size' is smaller than the old size. However, the memcpy() used the old size ('orig_size ?: ks'), leading to an out-of-bounds write. The same overflow bug exists in the kvrealloc() fallback path, where the old bucket size ksize(p) is copied into the new buffer without being bounded by the new size. A simple reproducer: // e.g. add to lkdtm as KREALLOC_SHRINK_OVERFLOW while (1) { void *p = kmalloc(128, GFP_KERNEL); p = krealloc_node_align(p, 64, 256, GFP_KERNEL, NUMA_NO_NODE); kfree(p); } demonstrates the issue: ================================================================== BUG: KFENCE: out-of-bounds write in memcpy_orig+0x68/0x130 Out-of-bounds write at 0xffff8883ad757038 (120B right of kfence-#47): memcpy_orig+0x68/0x130 krealloc_node_align_noprof+0x1c8/0x340 lkdtm_KREALLOC_SHRINK_OVERFLOW+0x8c/0xc0 [lkdtm] lkdtm_do_action+0x3a/0x60 [lkdtm] ... kfence-#47: 0xffff8883ad756fc0-0xffff8883ad756fff, size=64, cache=kmalloc-64 allocated by task 316 on cpu 7 at 97.680481s (0.021813s ago): krealloc_node_align_noprof+0x19c/0x340 lkdtm_KREALLOC_SHRINK_OVERFLOW+0x8c/0xc0 [lkdtm] lkdtm_do_action+0x3a/0x60 [lkdtm] ... ================================================================== Fix it by moving the old size calculation to the top of __do_krealloc() and bounding all copy lengths by the new allocation size. Fixes: 2cd8231796b5 ("mm/slub: allow to set node and align in k[v]realloc") Cc: stable@vger.kernel.org Reported-by: https://sashiko.dev/#/patchset/20260415143735.2974230-1-elver%40google.com Signed-off-by: Marco Elver Link: https://patch.msgid.link/20260416132837.3787694-1-elver@google.com Reviewed-by: Harry Yoo (Oracle) Signed-off-by: Vlastimil Babka (SUSE) Signed-off-by: Greg Kroah-Hartman commit 9eed57e9defdb9054eacb0411244255df0bd043c Author: Luca Ceresoli Date: Thu Apr 2 18:42:20 2026 +0200 drm/arcpgu: fix device node leak commit ad3ac32a3893a2bbcad545efc005a8e4e7ecf10c upstream. This function gets a device_node reference via of_graph_get_remote_port_parent() and stores it in encoder_node, but never puts that reference. Add it. There used to be a of_node_put(encoder_node) but it has been removed by mistake during a rework in commit 3ea66a794fdc ("drm/arc: Inline arcpgu_drm_hdmi_init"). Fixes: 3ea66a794fdc ("drm/arc: Inline arcpgu_drm_hdmi_init") Cc: stable@vger.kernel.org Reviewed-by: Louis Chauvet Link: https://patch.msgid.link/20260402-drm-arcgpu-fix-device-node-leak-v2-1-d773cf754ae5@bootlin.com Signed-off-by: Luca Ceresoli Signed-off-by: Greg Kroah-Hartman commit e9be7d2fb0b1c96540f0f61e17b9c7256c73f054 Author: Marek Vasut Date: Thu Apr 16 01:09:45 2026 +0200 net: ks8851: Avoid excess softirq scheduling commit 22230e68b2cf1ab6b027be8cf1198164a949c4fa upstream. The code injects a packet into netif_rx() repeatedly, which will add it to its internal NAPI and schedule a softirq, and process it. It is more efficient to queue multiple packets and process them all at the local_bh_enable() time. Reviewed-by: Sebastian Andrzej Siewior Fixes: e0863634bf9f ("net: ks8851: Queue RX packets in IRQ handler instead of disabling BHs") Cc: stable@vger.kernel.org Signed-off-by: Marek Vasut Link: https://patch.msgid.link/20260415231020.455298-2-marex@nabladev.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f826f0000100511707f85eb74c01fb2973f6d27a Author: Yuan Zhaoming Date: Fri Apr 17 22:13:40 2026 +0800 net: mctp: fix don't require received header reserved bits to be zero commit a663bac71a2f0b3ac6c373168ca57b2a6e6381aa upstream. From the MCTP Base specification (DSP0236 v1.2.1), the first byte of the MCTP header contains a 4 bit reserved field, and 4 bit version. On our current receive path, we require those 4 reserved bits to be zero, but the 9500-8i card is non-conformant, and may set these reserved bits. DSP0236 states that the reserved bits must be written as zero, and ignored when read. While the device might not conform to the former, we should accept these message to conform to the latter. Relax our check on the MCTP version byte to allow non-zero bits in the reserved field. Fixes: 889b7da23abf ("mctp: Add initial routing framework") Signed-off-by: Yuan Zhaoming Cc: stable@vger.kernel.org Acked-by: Jeremy Kerr Link: https://patch.msgid.link/20260417141340.5306-1-yuanzhaoming901030@126.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 20ba739bd62775a407a94fb1d78a7ce983bde636 Author: Breno Leitao Date: Mon Apr 20 03:18:36 2026 -0700 netconsole: avoid out-of-bounds access on empty string in trim_newline() commit 7079c8c13f2d33992bc846240517d88f4ab07781 upstream. trim_newline() unconditionally dereferences s[len - 1] after computing len = strnlen(s, maxlen). When the string is empty, len is 0 and the expression underflows to s[(size_t)-1], reading (and potentially writing) one byte before the buffer. The two callers feed trim_newline() with the result of strscpy() from configfs store callbacks (dev_name_store, userdatum_value_store). configfs guarantees count >= 1 reaches the callback, but the byte itself can be NUL: a userspace write(fd, "\0", 1) leaves the destination empty after strscpy() and triggers the underflow. The OOB write only fires if the adjacent byte happens to be '\n', so this is not a security issue, but the access is undefined behaviour either way. This pattern is commonly flagged by LLM-based code reviewers. While it is not a security fix, the underlying access is undefined behaviour and the change is small and self-contained, so it is a reasonable candidate for the stable trees. Guard the dereference on a non-zero length. Fixes: ae001dc67907 ("net: netconsole: move newline trimming to function") Cc: stable@vger.kernel.org Signed-off-by: Breno Leitao Reviewed-by: Gustavo Luiz Duarte Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260420-netcons_trim_newline-v1-1-dc35889aeedf@debian.org Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 5424e678f9b304e148cf5dcc047cffc7a56a3bb5 Author: Zhengchuan Liang Date: Mon Apr 13 17:08:46 2026 +0800 net: bridge: use a stable FDB dst snapshot in RCU readers commit df4601653201de21b487c3e7fffd464790cab808 upstream. Local FDB entries can be rewritten in place by `fdb_delete_local()`, which updates `f->dst` to another port or to `NULL` while keeping the entry alive. Several bridge RCU readers inspect `f->dst`, including `br_fdb_fillbuf()` through the `brforward_read()` sysfs path. These readers currently load `f->dst` multiple times and can therefore observe inconsistent values across the check and later dereference. In `br_fdb_fillbuf()`, this means a concurrent local-FDB update can change `f->dst` after the NULL check and before the `port_no` dereference, leading to a NULL-ptr-deref. Fix this by taking a single `READ_ONCE()` snapshot of `f->dst` in each affected RCU reader and using that snapshot for the rest of the access sequence. Also publish the in-place `f->dst` updates in `fdb_delete_local()` with `WRITE_ONCE()` so the readers and writer use matching access patterns. Fixes: 960b589f86c7 ("bridge: Properly check if local fdb entry can be deleted in br_fdb_change_mac_address") Cc: stable@kernel.org Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Tested-by: Ren Wei Signed-off-by: Zhengchuan Liang Signed-off-by: Ren Wei Reviewed-by: Ido Schimmel Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/6570fabb85ecadb8baaf019efe856f407711c7b9.1776043229.git.zcliangcn@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit be8aad558b4675f45b43080f81a9ffdeddea73a5 Author: Marek Vasut Date: Thu Apr 16 01:09:44 2026 +0200 net: ks8851: Reinstate disabling of BHs around IRQ handler commit 5c9fcac3c872224316714d0d8914d9af16c76a6d upstream. If the driver executes ks8851_irq() AND a TX packet has been sent, then the driver enables TX queue via netif_wake_queue() which schedules TX softirq to queue packets for this device. If CONFIG_PREEMPT_RT=y is set AND a packet has also been received by the MAC, then ks8851_rx_pkts() calls netdev_alloc_skb_ip_align() to allocate SKBs for the received packets. If netdev_alloc_skb_ip_align() is called with BH enabled, then local_bh_enable() at the end of netdev_alloc_skb_ip_align() will trigger the pending softirq processing, which may ultimately call the .xmit callback ks8851_start_xmit_par(). The ks8851_start_xmit_par() will try to lock struct ks8851_net_par .lock spinlock, which is already locked by ks8851_irq() from which ks8851_start_xmit_par() was called. This leads to a deadlock, which is reported by the kernel, including a trace listed below. If CONFIG_PREEMPT_RT is not set, then since commit 0913ec336a6c0 ("net: ks8851: Fix deadlock with the SPI chip variant") the deadlock can also be triggered without received packet in the RX FIFO. The pending softirqs will be processed on return from spin_unlock_bh(&ks->statelock) in ks8851_irq(), which triggers the deadlock as well. Fix the problem by disabling BH around critical sections, including the IRQ handler, thus preventing the net_tx_action() softirq from triggering during these critical sections. The net_tx_action() softirq is triggered once BH are re-enabled and at the end of the IRQ handler, once all the other IRQ handler actions have been completed. __schedule from schedule_rtlock+0x1c/0x34 schedule_rtlock from rtlock_slowlock_locked+0x548/0x904 rtlock_slowlock_locked from rt_spin_lock+0x60/0x9c rt_spin_lock from ks8851_start_xmit_par+0x74/0x1a8 ks8851_start_xmit_par from netdev_start_xmit+0x20/0x44 netdev_start_xmit from dev_hard_start_xmit+0xd0/0x188 dev_hard_start_xmit from sch_direct_xmit+0xb8/0x25c sch_direct_xmit from __qdisc_run+0x1f8/0x4ec __qdisc_run from qdisc_run+0x1c/0x28 qdisc_run from net_tx_action+0x1f0/0x268 net_tx_action from handle_softirqs+0x1a4/0x270 handle_softirqs from __local_bh_enable_ip+0xcc/0xe0 __local_bh_enable_ip from __alloc_skb+0xd8/0x128 __alloc_skb from __netdev_alloc_skb+0x3c/0x19c __netdev_alloc_skb from ks8851_irq+0x388/0x4d4 ks8851_irq from irq_thread_fn+0x24/0x64 irq_thread_fn from irq_thread+0x178/0x28c irq_thread from kthread+0x12c/0x138 kthread from ret_from_fork+0x14/0x28 Reviewed-by: Sebastian Andrzej Siewior Fixes: e0863634bf9f ("net: ks8851: Queue RX packets in IRQ handler instead of disabling BHs") Cc: stable@vger.kernel.org Signed-off-by: Marek Vasut Link: https://patch.msgid.link/20260415231020.455298-1-marex@nabladev.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ea0b5d0fe96356dce38f98375a57c52a04e13712 Author: Ruijie Li Date: Wed Apr 22 23:40:18 2026 +0800 net/smc: avoid early lgr access in smc_clc_wait_msg commit 5a8db80f721deee8e916c2cfdee78decda02ce4f upstream. A CLC decline can be received while the handshake is still in an early stage, before the connection has been associated with a link group. The decline handling in smc_clc_wait_msg() updates link-group level sync state for first-contact declines, but that state only exists after link group setup has completed. Guard the link-group update accordingly and keep the per-socket peer diagnosis handling unchanged. This preserves the existing sync_err handling for established link-group contexts and avoids touching link-group state before it is available. Fixes: 0cfdd8f92cac ("smc: connection and link group creation") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Ruijie Li Signed-off-by: Ren Wei Reviewed-by: Dust Li Link: https://patch.msgid.link/08c68a5c817acf198cce63d22517e232e8d60718.1776850759.git.ruijieli51@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1c2afc4a1dd1d3f2a9b0e27bf2ada030e499c736 Author: Jiawen Wu Date: Wed Apr 22 15:18:37 2026 +0800 net: txgbe: fix firmware version check commit c263f644add3d6ad81f9d62a99284fde408f0caa upstream. For the device SP, the firmware version is a 32-bit value where the lower 20 bits represent the base version number. And the customized firmware version populates the upper 12 bits with a specific identification number. For other devices AML 25G and 40G, the upper 12 bits of the firmware version is always non-zero, and they have other naming conventions. Only SP devices need to check this to tell if XPCS will work properly. So the judgement of MAC type is added here. And the original logic compared the entire 32-bit value against 0x20010, which caused the outdated base firmwares bypass the version check without a warning. Apply a mask 0xfffff to isolate the lower 20 bits for an accurate base version comparison. Fixes: ab928c24e6cd ("net: txgbe: add FW version warning") Cc: stable@vger.kernel.org Signed-off-by: Jiawen Wu Reviewed-by: Jacob Keller Link: https://patch.msgid.link/C787AA5C07598B13+20260422071837.372731-1-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 033370ffb3c9c0264d19f8ba9ef769523266589a Author: Ao Zhou Date: Wed Apr 22 22:52:07 2026 +0800 net: rds: fix MR cleanup on copy error commit 8141a2dc70080eda1aedc0389ed2db2b292af5bd upstream. __rds_rdma_map() hands sg/pages ownership to the transport after get_mr() succeeds. If copying the generated cookie back to user space fails after that point, the error path must not free those resources again before dropping the MR reference. Remove the duplicate unpin/free from the put_user() failure branch so that MR teardown is handled only through the existing final cleanup path. Fixes: 0d4597c8c5ab ("net/rds: Track user mapped pages through special API") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Ao Zhou Signed-off-by: Ren Wei Reviewed-by: Allison Henderson Link: https://patch.msgid.link/79c8ef73ec8e5844d71038983940cc2943099baf.1776764247.git.draw51280@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 154fc7fe3f62c46891c3c4302f4b5b5391c932e6 Author: Manivannan Sadhasivam Date: Thu Apr 9 23:04:14 2026 +0530 net: qrtr: ns: Free the node during ctrl_cmd_bye() commit 68efba36446a7774ea5b971257ade049272a07ac upstream. A node sends the BYE packet when it is about to go down. So the nameserver should advertise the removal of the node to all remote and local observers and free the node finally. But currently, the nameserver doesn't free the node memory even after processing the BYE packet. This causes the node memory to leak. Hence, remove the node from Xarray list and free the node memory during both success and failure case of ctrl_cmd_bye(). Cc: stable@vger.kernel.org Fixes: 0c2204a4ad71 ("net: qrtr: Migrate nameservice to kernel from userspace") Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260409-qrtr-fix-v3-3-00a8a5ff2b51@oss.qualcomm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7ef5b521785baf5ce8e0fd101f2a1d636ee0d199 Author: Robert Marko Date: Tue Jan 27 13:32:15 2026 +0100 arm64: dts: marvell: uDPU: add ethernet aliases commit 38f09c97340cd23f976242e6cb1e7aa4c8ed28d0 upstream. On eDPU plus, which is an updated revision of eDPU which uses an external MV88E6361 switch we are relying on U-Boot to detect the board, and then enable and disable the required nodes for that revision. However, it seems that I missed adding the required aliases for ethernet controllers, and this worked as in OpenWrt we had added those locally. Cc: stable@vger.kernel.org Fixes: 660b8b2f3944 ("arm64: dts: marvell: eDPU: add support for version with external switch") Signed-off-by: Robert Marko Signed-off-by: Gregory CLEMENT Signed-off-by: Greg Kroah-Hartman commit d29cafc7e4ee9e28a150ba17e9a565ec5d881fbc Author: Jiawen Wu Date: Tue Apr 7 17:40:41 2026 +0800 net: txgbe: fix RTNL assertion warning when remove module commit e159f05e12cc1111a3103b99375ddf0dfd0e7d63 upstream. For the copper NIC with external PHY, the driver called phylink_connect_phy() during probe and phylink_disconnect_phy() during remove. It caused an RTNL assertion warning in phylink_disconnect_phy() upon module remove. To fix this, add rtnl_lock() and rtnl_unlock() around the phylink_disconnect_phy() in remove function. ------------[ cut here ]------------ RTNL: assertion failed at drivers/net/phy/phylink.c (2351) WARNING: drivers/net/phy/phylink.c:2351 at phylink_disconnect_phy+0xd8/0xf0 [phylink], CPU#0: rmmod/4464 Modules linked in: ... CPU: 0 UID: 0 PID: 4464 Comm: rmmod Kdump: loaded Not tainted 7.0.0-rc4+ Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024 RIP: 0010:phylink_disconnect_phy+0xe4/0xf0 [phylink] Code: 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 f6 31 ff e9 3a 38 8f e7 48 8d 3d 48 87 e2 ff ba 2f 09 00 00 48 c7 c6 c1 22 24 c0 <67> 48 0f b9 3a e9 34 ff ff ff 66 90 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffce7288363ac0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff89654b2a1a00 RCX: 0000000000000000 RDX: 000000000000092f RSI: ffffffffc02422c1 RDI: ffffffffc0239020 RBP: ffffce7288363ae8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8964c4022000 R13: ffff89654fce3028 R14: ffff89654ebb4000 R15: ffffffffc0226348 FS: 0000795e80d93780(0000) GS:ffff896c52857000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005b528b592000 CR3: 0000000170d0f000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: txgbe_remove_phy+0xbb/0xd0 [txgbe] txgbe_remove+0x4c/0xb0 [txgbe] pci_device_remove+0x41/0xb0 device_remove+0x43/0x80 device_release_driver_internal+0x206/0x270 driver_detach+0x4a/0xa0 bus_remove_driver+0x83/0x120 driver_unregister+0x2f/0x60 pci_unregister_driver+0x40/0x90 txgbe_driver_exit+0x10/0x850 [txgbe] __do_sys_delete_module.isra.0+0x1c3/0x2f0 __x64_sys_delete_module+0x12/0x20 x64_sys_call+0x20c3/0x2390 do_syscall_64+0x11c/0x1500 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_syscall_64+0x15a/0x1500 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_fault+0x312/0x580 ? srso_alias_return_thunk+0x5/0xfbef5 ? __handle_mm_fault+0x9d5/0x1040 ? srso_alias_return_thunk+0x5/0xfbef5 ? count_memcg_events+0x101/0x1d0 ? srso_alias_return_thunk+0x5/0xfbef5 ? handle_mm_fault+0x1e8/0x2f0 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_user_addr_fault+0x2f8/0x820 ? srso_alias_return_thunk+0x5/0xfbef5 ? irqentry_exit+0xb2/0x600 ? srso_alias_return_thunk+0x5/0xfbef5 ? exc_page_fault+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: 02b2a6f91b90 ("net: txgbe: support copper NIC with external PHY") Cc: stable@vger.kernel.org Signed-off-by: Jiawen Wu Reviewed-by: Russell King (Oracle) Link: https://patch.msgid.link/8B47A5872884147D+20260407094041.4646-1-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 491344b826a58f122a851ec792fed20ae3e2318d Author: Yiyang Chen Date: Mon Mar 30 03:00:41 2026 +0800 tools/accounting: handle truncated taskstats netlink messages commit cc82b3dcc6a8fa259fbda12ab00d6fc00908a49e upstream. procacct and getdelays use a fixed receive buffer for taskstats generic netlink messages. A multi-threaded process exit can emit a single PID+TGID notification large enough to exceed that buffer on newer kernels. Switch to recvmsg() so MSG_TRUNC is detected explicitly, increase the message buffer size, and report truncated datagrams clearly instead of misparsing them as fatal netlink errors. Also print the taskstats version in debug output to make version mismatches easier to diagnose while inspecting taskstats traffic. Link: https://lkml.kernel.org/r/520308bb4cbbaf8dc2c7296b5f60f11e12fb30a5.1774810498.git.cyyzero16@gmail.com Signed-off-by: Yiyang Chen Cc: Balbir Singh Cc: Dr. Thomas Orgis Cc: Fan Yu Cc: Wang Yaxin Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit ff591df2cd7f3216fbe87f3112bf686176e0300f Author: Prasanna Kumar T S M Date: Sun Mar 22 06:11:39 2026 -0700 EDAC/versalnet: Fix memory leak in remove and probe error paths commit 1b6f292cb94d95c9bc22e1efe592daf62c60bc2e upstream. The mcdi object allocated using kzalloc() in the setup_mcdi() is not freed in the remove path or in probe's error handling path leading to a memory leak. Fix it by freeing the allocated memory. Fixes: d5fe2fec6c40d ("EDAC: Add a driver for the AMD Versal NET DDR controller") Signed-off-by: Prasanna Kumar T S M Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260322131139.1684716-1-ptsm@linux.microsoft.com Signed-off-by: Greg Kroah-Hartman commit 761c37b761ede21102c067205b6053854a6d2b99 Author: David Howells Date: Thu Apr 23 21:09:06 2026 +0100 rxrpc: Fix rxrpc_input_call_event() to only unshare DATA packets commit 55b2984c96c37f909bbfe8851f13152693951382 upstream. Fix rxrpc_input_call_event() to only unshare DATA packets and not ACK, ABORT, etc.. And with that, rxrpc_input_packet() doesn't need to take a pointer to the pointer to the packet, so change that to just a pointer. Fixes: 1f2740150f90 ("rxrpc: Fix potential UAF after skb_unshare() failure") Closes: https://sashiko.dev/#/patchset/20260422161438.2593376-4-dhowells@redhat.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/20260423200909.3049438-2-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 76cb9a2d252274adfae6e293a292434631a7d472 Author: David Howells Date: Thu Apr 23 21:09:07 2026 +0100 rxrpc: Fix re-decryption of RESPONSE packets commit 0422e7a4883f25101903f3e8105c0808aa5f4ce9 upstream. If a RESPONSE packet gets a temporary failure during processing, it may end up in a partially decrypted state - and then get requeued for a retry. Fix this by just discarding the packet; we will send another CHALLENGE packet and thereby elicit a further response. Similarly, discard an incoming CHALLENGE packet if we get an error whilst generating a RESPONSE; the server will send another CHALLENGE. Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Closes: https://sashiko.dev/#/patchset/20260422161438.2593376-4-dhowells@redhat.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/20260423200909.3049438-3-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 293095ef618818852bac5488c1bc223935e2ca17 Author: David Howells Date: Thu Apr 23 21:09:08 2026 +0100 rxrpc: Fix error handling in rxgk_extract_token() commit 3476c8bb960f48e49355d6f93fb7673211e0163f upstream. Fix a missing bit of error handling in rxgk_extract_token(): in the event that rxgk_decrypt_skb() returns -ENOMEM, it should just return that rather than continuing on (for anything else, it generates an abort). Fixes: 64863f4ca494 ("rxrpc: Fix unhandled errors in rxgk_verify_packet_integrity()") Closes: https://sashiko.dev/#/patchset/20260422161438.2593376-4-dhowells@redhat.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/20260423200909.3049438-4-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f0d3efd03b2a9e0f1ffa6df8fcb264af3d494286 Author: David Howells Date: Wed Apr 22 17:14:31 2026 +0100 rxrpc: Fix rxkad crypto unalignment handling commit def304aae2edf321d2671fd6ca766a93c21f877e upstream. Fix handling of a packet with a misaligned crypto length. Also handle non-ENOMEM errors from decryption by aborting. Further, remove the WARN_ON_ONCE() so that it can't be remotely triggered (a trace line can still be emitted). Fixes: f93af41b9f5f ("rxrpc: Fix missing error checks for rxkad encryption/decryption failure") Closes: https://sashiko.dev/#/patchset/20260408121252.2249051-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/20260422161438.2593376-3-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ca71ac2de389b01eecdc48bfafbdf073ec232044 Author: David Howells Date: Wed Apr 22 17:14:33 2026 +0100 rxrpc: Fix conn-level packet handling to unshare RESPONSE packets commit 24481a7f573305706054c59e275371f8d0fe919f upstream. The security operations that verify the RESPONSE packets decrypt bits of it in place - however, the sk_buff may be shared with a packet sniffer, which would lead to the sniffer seeing an apparently corrupt packet (actually decrypted). Fix this by handing a copy of the packet off to the specific security handler if the packet was cloned. Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Closes: https://sashiko.dev/#/patchset/20260408121252.2249051-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/20260422161438.2593376-5-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 861b9a0a1823bf064a7b810d29502a9ef043f40f Author: David Howells Date: Wed Apr 22 17:14:30 2026 +0100 rxrpc: Fix memory leaks in rxkad_verify_response() commit 34f61a07e0cdefaecd3ec03bb5fb22215643678f upstream. Fix rxkad_verify_response() to free the ticket and the server key under all circumstances by initialising the ticket pointer to NULL and then making all paths through the function after the first allocation has been done go through a single common epilogue that just releases everything - where all the releases skip on a NULL pointer. Fixes: 57af281e5389 ("rxrpc: Tidy up abort generation infrastructure") Fixes: ec832bd06d6f ("rxrpc: Don't retain the server key in the connection") Closes: https://sashiko.dev/#/patchset/20260408121252.2249051-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/20260422161438.2593376-2-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 996b0487b3cdda4c91811dbb1c9564626bc840bd Author: David Howells Date: Wed Apr 22 17:14:32 2026 +0100 rxrpc: Fix potential UAF after skb_unshare() failure commit 1f2740150f904bfa60e4bad74d65add3ccb5e7f8 upstream. If skb_unshare() fails to unshare a packet due to allocation failure in rxrpc_input_packet(), the skb pointer in the parent (rxrpc_io_thread()) will be NULL'd out. This will likely cause the call to trace_rxrpc_rx_done() to oops. Fix this by moving the unsharing down to where rxrpc_input_call_event() calls rxrpc_input_call_packet(). There are a number of places prior to that where we ignore DATA packets for a variety of reasons (such as the call already being complete) for which an unshare is then avoided. And with that, rxrpc_input_packet() doesn't need to take a pointer to the pointer to the packet, so change that to just a pointer. Fixes: 2d1faf7a0ca3 ("rxrpc: Simplify skbuff accounting in receive path") Closes: https://sashiko.dev/#/patchset/20260408121252.2249051-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/20260422161438.2593376-4-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d42d5404782fe4cd6617b01e45f197baa802f64a Author: Jonathan Santos Date: Mon Feb 23 08:59:35 2026 -0300 iio: adc: ad7768-1: remove switch to one-shot mode commit 81fdc3127d013a552465c3bf9829afbed5184406 upstream. wideband low ripple FIR Filter is not available in one-shot mode. In order to make direct reads work for all filter options, remove the switch for one-shot mode and guarantee device is always in continuous conversion mode. Fixes: fb1d3b24ebf5 ("iio: adc: ad7768-1: add filter type and oversampling ratio attributes") Signed-off-by: Jonathan Santos Reviewed-by: David Lechner Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 4ca3746d9492da660b28638bc262b73dd742af21 Author: Jonathan Santos Date: Mon Feb 23 08:59:26 2026 -0300 iio: adc: ad7768-1: fix one-shot mode data acquisition commit 8be19e233744961db6069da9c9ab63eb085a0447 upstream. According to the datasheet, one-shot mode requires a SYNC_IN pulse to trigger a new sample conversion. In the current implementation, No sync pulse was sent after switching to one-shot mode and reinit_completion() was called before mode switching, creating a race condition where spurious interrupts during mode change could trigger completion prematurely. Fix by sending a sync pulse after configuring one-shot mode and reinit_completion() to ensure it only waits for the actual conversion completion. Fixes: a5f8c7da3dbe ("iio: adc: Add AD7768-1 ADC basic support") Signed-off-by: Jonathan Santos Reviewed-by: David Lechner Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 54af1a51bb8b9d3c116d7f4913dd01cf79457dc6 Author: Cássio Gabriel Date: Tue Apr 21 10:03:06 2026 -0300 ALSA: pcmtest: Fix resource leaks in module init error paths commit d5d5f80416a3a749906c04d56575e2290792654b upstream. pcmtest allocates its pattern buffers and creates its debugfs tree before registering the platform device and driver, but mod_init() does not release those resources when a later init step fails. As a result, a debugfs directory creation failure leaks the pattern buffers, while platform_device_register() and platform_driver_register() failures leave both the pattern buffers and the debugfs tree behind. The recent fix for failed device registration only dropped the embedded device reference. Add the missing cleanup for the debugfs tree and pattern buffers in the remaining module init error paths. Fixes: 315a3d57c64c ("ALSA: Implement the new Virtual PCM Test Driver") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260421-alsa-pcmtest-init-unwind-v1-1-03fe0c423dbb@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 91c8e75ba1f162db50ade4151a9068f45a197986 Author: Guangshuo Li Date: Thu Apr 16 03:31:38 2026 +0800 ALSA: pcmtest: fix reference leak on failed device registration commit 4ff036f95238f02c87e5d7c0a9d93748582a8950 upstream. When platform_device_register() fails in mod_init(), the embedded struct device in pcmtst_pdev has already been initialized by device_initialize(), but the failure path returns the error without dropping the device reference for the current platform device: mod_init() -> platform_device_register(&pcmtst_pdev) -> device_initialize(&pcmtst_pdev.dev) -> setup_pdev_dma_masks(&pcmtst_pdev) -> platform_device_add(&pcmtst_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: 315a3d57c64c5 ("ALSA: Implement the new Virtual PCM Test Driver") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260415193138.3861297-1-lgs201920130244@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 89ed38540e6be0c956af3dd980df36c7c9a0e3e2 Author: Spencer Payton Date: Tue Apr 21 10:49:18 2026 +0200 ALSA: hda/realtek - Add mute LED support for HP Victus 15-fa2xxx commit eacda758e3c01db98b5c231f56cf9a6e05ced75c upstream. The mute LED on this laptop uses ALC245 but requires a quirk to work. This patch enables the existing ALC245_FIXUP_HP_MUTE_LED_COEFBIT quirk for the device. Tested my Victus 15-fa2xxx (PCI SSID 103c:8dcd). The LED behaviour works as intended. Cc: stable@vger.kernel.org Signed-off-by: Spencer Payton Link: https://patch.msgid.link/20260421084918.14685-1-spayton681@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1ac67f49ae2cd6ba590b80c5b2a0aef7ac580d61 Author: Cássio Gabriel Date: Thu Apr 16 10:24:40 2026 -0300 ALSA: 6fire: Fix input volume change detection commit dc88eef8f55e85e92d016cdf7e291f5560efd79b upstream. usb6fire_control_input_vol_put() stores the analog capture volume as a signed offset in rt->input_vol[] (-15..+15), but it compares the cached value against the user-visible mixer value (0..30) before subtracting 15. This mixes two domains in the change detection path. Since the runtime is zero-initialized, the visible default is 15; writing 0 right after probe is ignored, while writing 15 is reported as a change even though the cached value remains 0. Normalize the user value before comparing it with the cached offset. Fixes: 06bb4e743501 ("ALSA: snd-usb-6fire: add analog input volume control") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260416-alsa-6fire-input-volume-change-detection-v1-1-ec78299168df@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e59ecd4ee3a450db6cb4e4ecaa3efdd593f80056 Author: Takashi Iwai Date: Tue Apr 14 12:59:00 2026 +0200 ALSA: caiaq: Handle probe errors properly commit 28abd224db4a49560b452115bca3672a20e45b2f upstream. The probe procedure of setup_card() in caiaq driver doesn't treat the error cases gracefully, e.g. the error from snd_card_register() calls snd_card_free() but continues. This would lead to a UAF for the further calls like snd_usb_caiaq_control_init(), as Berk suggested in another patch in the link below. However, the problem is not only that; in general, this function drops the all error handlings (as it's a void function) although its caller can propagate an error to snd_probe(), which eventually calls snd_card_free() as a proper error path. That said, we should treat each error case in setup_card(), and just return the error code promptly, which is then handled later as a fatal error in snd_probe(). This patch achieves it by changing the setup_card() to return an error code. Also, the superfluous snd_card_free() call is removed, too. Note that card->private_free can be set still safely at returning an error. All called functions in card_free() have checks of the unassigned resources or NULL checks. Fixes: 8e3cd08ed8e5 ("[ALSA] caiaq - add control API and more input features") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/20260413034941.1131465-2-berkcgoksel@gmail.com Link: https://patch.msgid.link/20260414105916.364073-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 30bd9ed68c84f060319c7edea9ab7f7b64565ef5 Author: Cássio Gabriel Date: Fri Apr 17 10:41:33 2026 -0300 ALSA: caiaq: Fix control_put() result and cache rollback commit a3542d1b30f92307f545f2def14e8d988dffdff0 upstream. control_put() always returns 1 and updates cdev->control_state[] before sending the USB command. It also ignores transport errors from usb_bulk_msg(), snd_usb_caiaq_send_command(), and snd_usb_caiaq_send_command_bank(). That breaks the ALSA .put() contract and can leave control_get() reporting a cached value the device never accepted. Return 0 for unchanged values, propagate transport failures, and restore the cached byte when the write fails. Fixes: 8e3cd08ed8e59 ("[ALSA] caiaq - add control API and more input features") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260417-caiaq-control-put-v1-1-c37826e92447@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 33df746736749a8899be6406dfc56df19c3113d7 Author: Takashi Iwai Date: Mon Apr 20 08:17:20 2026 +0200 ALSA: core: Fix potential data race at fasync handling commit 8146cd333d235ed32d48bb803fdf743472d7c783 upstream. In snd_fasync_work_fn(), which is the offload work for traversing and processing the pending fasync list, the call of kill_fasync() is done outside the snd_fasync_lock for avoiding deadlocks. The problem is that its the references of fasync->on, fasync->signal and fasync->poll are done there also outside the lock. Since these may be modified by snd_kill_fasync() call concurrently from other process, inconsistent values might be passed to kill_fasync(). Although there shouldn't be critical UAF, it's still better to be addressed. This patch moves the kill_fasync() argument evaluations inside the snd_fasync_lock for avoiding the data races above. The handling in fasync->on flag is optimized in the loop to skip directly. Also, for more clarity, snd_fasync_free() takes the lock and unlink the pending entry more directly instead of clearing fasync->on flag. Reported-by: Jake Lamberson Fixes: ef34a0ae7a26 ("ALSA: core: Add async signal helpers") Cc: Link: https://patch.msgid.link/20260420061721.3253644-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9678e1b7f512b9d376e14f3ca8c01dc71569a3c4 Author: Jens Axboe Date: Tue Apr 21 13:24:33 2026 -0600 io_uring/poll: ensure EPOLL_ONESHOT is propagated for EPOLL_URING_WAKE commit 1967f0b1cafdde37aa9e08e6021c14bcc484b7a5 upstream. Commit: aacf2f9f382c ("io_uring: fix req->apoll_events") fixed an issue where poll->events and req->apoll_events weren't synchronized, but then when the commit referenced in Fixes got added, it didn't ensure the same thing. If we mask in EPOLLONESHOT in the regular EPOLL_URING_WAKE path, then ensure it's done for both. Including a link to the original report below, even though it's mostly nonsense. But it includes a reproducer that does show that IORING_CQE_F_MORE is set in the previous CQE, while no more CQEs will be generated for this request. Just ignore anything that pretends this is security related in any way, it's just the typical AI nonsense. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/io-uring/CAM0zi7yQzF3eKncgHo4iVM5yFLAjsiob_ucqyWKs=hyd_GqiMg@mail.gmail.com/ Reported-by: Azizcan Daştan Fixes: 4464853277d0 ("io_uring: pass in EPOLL_URING_WAKE for eventfd signaling and wakeups") Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit ea0697129807d718037f618221037aa0660ee3c5 Author: Longxuan Yu Date: Sun Apr 12 16:38:20 2026 +0800 io_uring/poll: fix signed comparison in io_poll_get_ownership() commit 326941b22806cbf2df1fbfe902b7908b368cce42 upstream. io_poll_get_ownership() uses a signed comparison to check whether poll_refs has reached the threshold for the slowpath: if (unlikely(atomic_read(&req->poll_refs) >= IO_POLL_REF_BIAS)) atomic_read() returns int (signed). When IO_POLL_CANCEL_FLAG (BIT(31)) is set in poll_refs, the value becomes negative in signed arithmetic, so the >= 128 comparison always evaluates to false and the slowpath is never taken. Fix this by casting the atomic_read() result to unsigned int before the comparison, so that the cancel flag is treated as a large positive value and correctly triggers the slowpath. Fixes: a26a35e9019f ("io_uring: make poll refs more robust") Cc: stable@vger.kernel.org Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Tested-by: Zhengchuan Liang Signed-off-by: Longxuan Yu Signed-off-by: Ren Wei Reviewed-by: Pavel Begunkov Link: https://patch.msgid.link/3a3508b08bcd7f1bc3beff848ae6e1d73d355043.1775965597.git.ylong030@ucr.edu Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 23b4b18bac285619c73dd79f6d6e1809c03891c7 Author: David Lechner Date: Sat Mar 14 16:12:24 2026 -0500 iio: adc: ti-ads7950: use iio_push_to_buffers_with_ts_unaligned() commit 7806c060cceb2d6895efbb6cff2f2f17cf1ec5de upstream. Use iio_push_to_buffers_with_ts_unaligned() to avoid unaligned access when writing the timestamp in the rx_buf. The previous implementation would have been fine on architectures that support 4-byte alignment of 64-bit integers but could cause issues on architectures that require 8-byte alignment. Fixes: 902c4b2446d4 ("iio: adc: New driver for TI ADS7950 chips") Signed-off-by: David Lechner Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 8661370e0865c8670ed367e21c90ca166e7875a7 Author: Naman Jain Date: Fri Apr 10 15:34:14 2026 +0000 block: relax pgmap check in bio_add_page for compatible zone device pages commit 41c665aae2b5dbecddddcc8ace344caf630cc7a4 upstream. bio_add_page() and bio_integrity_add_page() reject pages from different dev_pagemaps entirely, returning 0 even when those pages have compatible DMA mapping requirements. This forces callers to start a new bio when buffers span pgmap boundaries, even though the pages could safely coexist as separate bvec entries. This matters for guests where memory is registered through devm_memremap_pages() with MEMORY_DEVICE_GENERIC in multiple calls, creating separate dev_pagemaps for each chunk. When a direct I/O buffer spans two such chunks, bio_add_page() rejects the second page, forcing an unnecessary bio split or I/O failure. Introduce zone_device_pages_compatible() in blk.h to check whether two pages can coexist in the same bio as separate bvec entries. The block DMA iterator (blk_dma_map_iter_start) caches the P2PDMA mapping state from the first segment and applies it to all others, so P2PDMA pages from different pgmaps must not be mixed, and neither must P2PDMA and non-P2PDMA pages. All other combinations (MEMORY_DEVICE_GENERIC pages from different pgmaps, or MEMORY_DEVICE_GENERIC with normal RAM) use the same dma_map_phys path and are safe. Replace the blanket zone_device_pages_have_same_pgmap() rejection with zone_device_pages_compatible(), while keeping zone_device_pages_have_same_pgmap() as a merge guard. Pages from different pgmaps can be added as separate bvec entries but must not be coalesced into the same segment, as that would make it impossible to recover the correct pgmap via page_pgmap(). Fixes: 49580e690755 ("block: add check when merging zone device pages") Cc: stable@vger.kernel.org Signed-off-by: Naman Jain Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260410153414.4159050-3-namjain@linux.microsoft.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit dd154d768db5ebc610dd05dc37c112ae0bcdd1cb Author: Pavel Begunkov Date: Mon Mar 2 13:10:34 2026 +0000 io_uring/timeout: check unused sqe fields commit 484ae637a3e3d909718de7c07afd3bb34b6b8504 upstream. Zero check unused SQE fields addr3 and pad2 for timeout and timeout update requests. They're not needed now, but could be used sometime in the future. Cc: stable@vger.kernel.org Signed-off-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 81880f84cb3611914014f90147766a0a435d2144 Author: Damien Le Moal Date: Fri Feb 27 22:19:45 2026 +0900 block: fix zone write plugs refcount handling in disk_zone_wplug_schedule_bio_work() commit 0a8b8af896e0ef83e188e1fe20f98f2bbb1c2459 upstream. The function disk_zone_wplug_schedule_bio_work() always takes a reference on the zone write plug of the BIO work being scheduled. This ensures that the zone write plug cannot be freed while the BIO work is being scheduled but has not run yet. However, this unconditional reference taking is fragile since the reference taken is released by the BIO work blk_zone_wplug_bio_work() function, which implies that there always must be a 1:1 relation between the work being scheduled and the work running. Make sure to drop the reference taken when scheduling the BIO work if the work is already scheduled, that is, when queue_work() returns false. Fixes: 9e78c38ab30b ("block: Hold a reference on zone write plugs to schedule submission") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Reviewed-by: Christoph Hellwig Reviewed-by: Bart Van Assche Reviewed-by: Johannes Thumshirn Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit ad0126ffcba8777109852979eaaa6dca6703abdb Author: Dawei Feng Date: Sun Apr 19 17:03:48 2026 +0800 rbd: fix null-ptr-deref when device_add_disk() fails commit d1fef92e414433ca7b89abf85cb0df42b8d475eb upstream. do_rbd_add() publishes the device with device_add() before calling device_add_disk(). If device_add_disk() fails after device_add() succeeds, the error path calls rbd_free_disk() directly and then later falls through to rbd_dev_device_release(), which calls rbd_free_disk() again. This double teardown can leave blk-mq cleanup operating on invalid state and trigger a null-ptr-deref in __blk_mq_free_map_and_rqs(), reached from blk_mq_free_tag_set(). Fix this by following the normal remove ordering: call device_del() before rbd_dev_device_release() when device_add_disk() fails after device_add(). That keeps the teardown sequence consistent and avoids re-entering disk cleanup through the wrong 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. We reproduced the bug on v7.0 with a real Ceph backend and a QEMU x86_64 guest booted with KASAN and CONFIG_FAILSLAB enabled. The reproducer confines failslab injections to the __add_disk() range and injects fail-nth while mapping an RBD image through /sys/bus/rbd/add_single_major. On the unpatched kernel, fail-nth=4 reliably triggered the fault: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 UID: 0 PID: 273 Comm: bash Not tainted 7.0.0-01247-gd60bc1401583 #6 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:__blk_mq_free_map_and_rqs+0x8c/0x240 Code: 00 00 48 8b 6b 60 41 89 f4 49 c1 e4 03 4c 01 e5 45 85 ed 0f 85 0a 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 e9 48 c1 e9 03 <80> 3c 01 00 0f 85 31 01 00 00 4c 8b 6d 00 4d 85 ed 0f 84 e2 00 00 RSP: 0018:ff1100000ab0fac8 EFLAGS: 00000246 RAX: dffffc0000000000 RBX: ff1100000c4806a0 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000000 RDI: ff1100000c4806f4 RBP: 0000000000000000 R08: 0000000000000001 R09: ffe21c000189001b R10: ff1100000c4800df R11: ff1100006cf37be0 R12: 0000000000000000 R13: 0000000000000000 R14: ff1100000c480700 R15: ff1100000c480004 FS: 00007f0fbe8fe740(0000) GS:ff110000e5851000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe53473b2e0 CR3: 0000000012eef000 CR4: 00000000007516f0 PKRU: 55555554 Call Trace: blk_mq_free_tag_set+0x77/0x460 do_rbd_add+0x1446/0x2b80 ? __pfx_do_rbd_add+0x10/0x10 ? lock_acquire+0x18c/0x300 ? find_held_lock+0x2b/0x80 ? sysfs_file_kobj+0xb6/0x1b0 ? __pfx_sysfs_kf_write+0x10/0x10 kernfs_fop_write_iter+0x2f4/0x4a0 vfs_write+0x98e/0x1000 ? expand_files+0x51f/0x850 ? __pfx_vfs_write+0x10/0x10 ksys_write+0xf2/0x1d0 ? __pfx_ksys_write+0x10/0x10 do_syscall_64+0x115/0x690 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f0fbea15907 Code: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 RSP: 002b:00007ffe22346ea8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000058 RCX: 00007f0fbea15907 RDX: 0000000000000058 RSI: 0000563ace6c0ef0 RDI: 0000000000000001 RBP: 0000563ace6c0ef0 R08: 0000563ace6c0ef0 R09: 6b6435726d694141 R10: 5250337279762f78 R11: 0000000000000246 R12: 0000000000000058 R13: 00007f0fbeb1c780 R14: ff1100000c480700 R15: ff1100000c480004 With this fix applied, rerunning the reproducer over fail-nth=1..256 yields no KASAN reports. [ idryomov: rename err_out_device_del -> err_out_device ] Cc: stable@vger.kernel.org Fixes: 27c97abc30e2 ("rbd: add add_disk() error handling") Signed-off-by: Zilin Guan Signed-off-by: Dawei Feng Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 4d79d0cf65386b345030d525cf9fb183bbf872eb Author: Mickaël Salaün Date: Thu Apr 2 21:26:05 2026 +0200 selftests/landlock: Skip stale records in audit_match_record() commit 07c2572a87573b2a2f0fd6b9f538cd1aeef2eee7 upstream. Domain deallocation records are emitted asynchronously from kworker threads (via free_ruleset_work()). Stale deallocation records from a previous test can arrive during the current test's deallocation read loop and be picked up by audit_match_record() instead of the expected record, causing a domain ID mismatch. The audit.layers test (which creates 16 nested domains) is particularly vulnerable because it reads 16 deallocation records in sequence, providing a large window for stale records to interleave. The same issue affects audit_flags.signal, where deallocation records from a previous test (audit.layers) can leak into the next test and be picked up by audit_match_record() instead of the expected record. Fix this by continuing to read records when the type matches but the content pattern does not. Stale records are silently consumed, and the loop only stops when both type and pattern match (or the socket times out with -EAGAIN). Additionally, extend matches_log_domain_deallocated() with an expected_domain_id parameter. When set, the regex pattern includes the specific domain ID as a literal hex value, so that deallocation records for a different domain do not match the pattern at all. This handles the case where the stale record has the same denial count as the expected one (e.g. both have denials=1), which the type+pattern loop alone cannot distinguish. Callers that already know the expected domain ID (from a prior denial or allocation record) now pass it to filter precisely. When expected_domain_id is set, matches_log_domain_deallocated() also temporarily increases the socket timeout to audit_tv_dom_drop (1 second) to wait for the asynchronous kworker deallocation, and restores audit_tv_default afterward. This removes the need for callers to manage the timeout switch manually. Cc: Günther Noack Cc: stable@vger.kernel.org Fixes: 6a500b22971c ("selftests/landlock: Add tests for audit flags and domain IDs") Link: https://lore.kernel.org/r/20260402192608.1458252-5-mic@digikod.net Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit 127ae2e73e6175616abee6f58b1ede51276f70f2 Author: Mickaël Salaün Date: Thu Apr 2 21:26:02 2026 +0200 selftests/landlock: Fix snprintf truncation checks in audit helpers commit b566f7a4f0e4f15f78f2e5fac273fa954991e03a upstream. snprintf() returns the number of characters that would have been written, excluding the terminating NUL byte. When the output is truncated, this return value equals or exceeds the buffer size. Fix matches_log_domain_allocated() and matches_log_domain_deallocated() to detect truncation with ">=" instead of ">". Cc: Günther Noack Cc: stable@vger.kernel.org Fixes: 6a500b22971c ("selftests/landlock: Add tests for audit flags and domain IDs") Reviewed-by: Günther Noack Link: https://lore.kernel.org/r/20260402192608.1458252-2-mic@digikod.net Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit 1e85a1ae1452948dcd680baf0fb3d99479c0ea84 Author: Mickaël Salaün Date: Thu Apr 2 21:26:06 2026 +0200 selftests/landlock: Fix format warning for __u64 in net_test commit a060ac0b8c3345639f5f4a01e2c435d34adf7e3d upstream. On architectures where __u64 is unsigned long (e.g. powerpc64), using %llx to format a __u64 triggers a -Wformat warning because %llx expects unsigned long long. Cast the argument to unsigned long long. Cc: Günther Noack Cc: stable@vger.kernel.org Fixes: a549d055a22e ("selftests/landlock: Add network tests") Reported-by: kernel test robot Closes: https://lore.kernel.org/r/202604020206.62zgOTeP-lkp@intel.com/ Reviewed-by: Günther Noack Link: https://lore.kernel.org/r/20260402192608.1458252-6-mic@digikod.net Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit a496488e1702df0918472b5559463bdc4b4fc35a Author: Mickaël Salaün Date: Thu Apr 2 21:26:04 2026 +0200 selftests/landlock: Drain stale audit records on init commit 3647a4977fb73da385e5a29b9775a4749733470d upstream. Non-audit Landlock tests generate audit records as side effects when audit_enabled is non-zero (e.g. from boot configuration). These records accumulate in the kernel audit backlog while no audit daemon socket is open. When the next test opens a new netlink socket and registers as the audit daemon, the stale backlog is delivered, causing baseline record count checks to fail spuriously. Fix this by draining all pending records in audit_init() right after setting the receive timeout. The 1-usec SO_RCVTIMEO causes audit_recv() to return -EAGAIN once the backlog is empty, naturally terminating the drain loop. Domain deallocation records are emitted asynchronously from a work queue, so they may still arrive after the drain. Remove records.domain == 0 checks that are not preceded by audit_match_record() calls, which would otherwise consume stale records before the count. Document this constraint above audit_count_records(). Increasing the drain timeout to catch in-flight deallocation records was considered but rejected: a longer timeout adds latency to every audit_init() call even when no stale record is pending, and any fixed timeout is still not guaranteed to catch all records under load. Removing the unprotected checks is simpler and avoids the spurious failures. Cc: Günther Noack Cc: stable@vger.kernel.org Fixes: 6a500b22971c ("selftests/landlock: Add tests for audit flags and domain IDs") Reviewed-by: Günther Noack Link: https://lore.kernel.org/r/20260402192608.1458252-4-mic@digikod.net Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit 2fcde49092aac55d5beef43fdd3633217672f7d1 Author: Mickaël Salaün Date: Tue Apr 7 18:41:04 2026 +0200 landlock: Fix LOG_SUBDOMAINS_OFF inheritance across fork() commit 874c8f83826c95c62c21d9edfe9ef43e5c346724 upstream. hook_cred_transfer() only copies the Landlock security blob when the source credential has a domain. This is inconsistent with landlock_restrict_self() which can set LOG_SUBDOMAINS_OFF on a credential without creating a domain (via the ruleset_fd=-1 path): the field is committed but not preserved across fork() because the child's prepare_creds() calls hook_cred_transfer() which skips the copy when domain is NULL. This breaks the documented use case where a process mutes subdomain logs before forking sandboxed children: the children lose the muting and their domains produce unexpected audit records. Fix this by unconditionally copying the Landlock credential blob. Cc: Günther Noack Cc: Jann Horn Cc: stable@vger.kernel.org Fixes: ead9079f7569 ("landlock: Add LANDLOCK_RESTRICT_SELF_LOG_SUBDOMAINS_OFF") Reviewed-by: Günther Noack Link: https://lore.kernel.org/r/20260407164107.2012589-1-mic@digikod.net Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit df865a3bb91b822069a60e139f974f97db94bb3a Author: Simon Liebold Date: Thu Mar 12 14:02:00 2026 +0000 selftests/mqueue: Fix incorrectly named file commit 64fac99037689020ad97e472ae898e96ea3616dc upstream. Commit 85506aca2eb4 ("selftests/mqueue: Set timeout to 180 seconds") intended to increase the timeout for mq_perf_tests from the default kselftest limit of 45 seconds to 180 seconds. Unfortunately, the file storing this information was incorrectly named `setting` instead of `settings`, causing the kselftest runner not to pick up the limit and keep using the default 45 seconds limit. Fix this by renaming it to `settings` to ensure that the kselftest runner uses the increased timeout of 180 seconds for this test. Fixes: 85506aca2eb4 ("selftests/mqueue: Set timeout to 180 seconds") Cc: # 5.10.y Signed-off-by: Simon Liebold Link: https://lore.kernel.org/r/20260312140200.2224850-1-simonlie@amazon.de Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman commit 558aa1e2cd11741ebc5dd57fd17cb3fd98c5fd64 Author: Joseph Salisbury Date: Fri Apr 3 17:00:14 2026 -0400 sched: Use u64 for bandwidth ratio calculations commit c6e80201e057dfb7253385e60bf541121bf5dc33 upstream. to_ratio() computes BW_SHIFT-scaled bandwidth ratios from u64 period and runtime values, but it returns unsigned long. tg_rt_schedulable() also stores the current group limit and the accumulated child sum in unsigned long. On 32-bit builds, large bandwidth ratios can be truncated and the RT group sum can wrap when enough siblings are present. That can let an overcommitted RT hierarchy pass the schedulability check, and it also narrows the helper result for other callers. Return u64 from to_ratio() and use u64 for the RT group totals so bandwidth ratios are preserved and compared at full width on both 32-bit and 64-bit builds. Fixes: b40b2e8eb521 ("sched: rt: multi level group constraints") Assisted-by: Codex:GPT-5 Signed-off-by: Joseph Salisbury Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260403210014.2713404-1-joseph.salisbury@oracle.com Signed-off-by: Greg Kroah-Hartman commit 961db0b89200a4e1e53e2855f103a6dc99943f0a Author: Tommaso Merciai Date: Thu Mar 12 15:50:38 2026 +0100 reset: rzv2h-usb2phy: Keep PHY clock enabled for entire device lifetime commit 8889b289ce1bd11a5102b9617742a1b93bb4843e upstream. The driver was disabling the USB2 PHY clock immediately after register initialization in probe() and after each reset operation. This left the PHY unclocked even though it must remain active for USB functionality. The behavior appeared to work only when another driver (e.g., USB controller) had already enabled the clock, making operation unreliable and hardware-dependent. In configurations where this driver is the sole clock user, USB functionality would fail. Fix this by: - Enabling the clock once in probe() via pm_runtime_resume_and_get() - Removing all pm_runtime_put() calls from assert/deassert/status - Registering a devm cleanup action to release the clock at removal - Removed rzv2h_usbphy_assert_helper() and its call in rzv2h_usb2phy_reset_probe() This ensures the PHY clock remains enabled for the entire device lifetime, preventing instability and aligning with hardware requirements. Cc: stable@vger.kernel.org Fixes: e3911d7f865b ("reset: Add USB2PHY port reset driver for Renesas RZ/V2H(P)") Signed-off-by: Tommaso Merciai Reviewed-by: Philipp Zabel Signed-off-by: Philipp Zabel Signed-off-by: Greg Kroah-Hartman commit 06d0bed2552fd0dae27d374d4492a2b672e24eed Author: Ben Levinsky Date: Tue Mar 3 15:51:27 2026 -0800 remoteproc: xlnx: Only access buffer information if IPI is buffered commit 38dd6ccfdfbbe865569a52fe1ba9fa1478f672e6 upstream. In the receive callback check if message is NULL to prevent possibility of crash by NULL pointer dereferencing. Signed-off-by: Ben Levinsky Signed-off-by: Tanmay Shah Fixes: 5dfb28c257b7 ("remoteproc: xilinx: Add mailbox channels for rpmsg") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20260303235127.2317955-3-tanmay.shah@amd.com Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit 8ba804869382ce307f2a15f5f6f2adfd791f41dc Author: Long Li Date: Wed Mar 25 12:40:57 2026 -0700 RDMA/mana_ib: Disable RX steering on RSS QP destroy commit dbeb256e8dd87233d891b170c0b32a6466467036 upstream. When an RSS QP is destroyed (e.g. DPDK exit), mana_ib_destroy_qp_rss() destroys the RX WQ objects but does not disable vPort RX steering in firmware. This leaves stale steering configuration that still points to the destroyed RX objects. If traffic continues to arrive (e.g. peer VM is still transmitting) and the VF interface is subsequently brought up (mana_open), the firmware may deliver completions using stale CQ IDs from the old RX objects. These CQ IDs can be reused by the ethernet driver for new TX CQs, causing RX completions to land on TX CQs: WARNING: mana_poll_tx_cq+0x1b8/0x220 [mana] (is_sq == false) WARNING: mana_gd_process_eq_events+0x209/0x290 (cq_table lookup fails) Fix this by disabling vPort RX steering before destroying RX WQ objects. Note that mana_fence_rqs() cannot be used here because the fence completion is delivered on the CQ, which is polled by user-mode (e.g. DPDK) and not visible to the kernel driver. Refactor the disable logic into a shared mana_disable_vport_rx() in mana_en, exported for use by mana_ib, replacing the duplicate code. The ethernet driver's mana_dealloc_queues() is also updated to call this common function. Fixes: 0266a177631d ("RDMA/mana_ib: Add a driver for Microsoft Azure Network Adapter") Cc: stable@vger.kernel.org Signed-off-by: Long Li Link: https://patch.msgid.link/20260325194100.1929056-1-longli@microsoft.com Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman commit dffdcbeabaac077e23caa3155926b09fa6ea451b Author: Aksh Garg Date: Thu Apr 2 14:25:45 2026 +0530 PCI: cadence: Use cdns_pcie_read_sz() for byte or word read access commit d9cf7154deed71a4f23e81101571c79cdc77be00 upstream. The commit 18ac51ae9df9 ("PCI: cadence: Implement capability search using PCI core APIs") assumed all the platforms using Cadence PCIe controller support byte and word register accesses. This is not true for all platforms (e.g., TI J721E SoC, which only supports dword register accesses). This causes capability searches via cdns_pcie_find_capability() to fail on such platforms. Fix this by using cdns_pcie_read_sz() for config read functions, which properly handles size-aligned accesses. Remove the now-unused byte and word read wrapper functions (cdns_pcie_readw and cdns_pcie_readb). Fixes: 18ac51ae9df9 ("PCI: cadence: Implement capability search using PCI core APIs") Signed-off-by: Aksh Garg Signed-off-by: Manivannan Sadhasivam Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260402085545.284457-1-a-garg7@ti.com Signed-off-by: Greg Kroah-Hartman commit 1fe317364cb5bf4893d50880bc903198ab94ce45 Author: Helge Deller Date: Fri Apr 10 16:12:31 2026 +0200 parisc: Drop ip_fast_csum() inline assembly implementation commit 3dd31a370c1dccb580f729af7c580ccb1ae3c0c9 upstream. The assembly code of ip_fast_csum() triggers unaligned access warnings if the IP header isn't correctly aligned: Kernel: unaligned access to 0x173d22e76 in inet_gro_receive+0xbc/0x2e8 (iir 0x0e8810b6) Kernel: unaligned access to 0x173d22e7e in inet_gro_receive+0xc4/0x2e8 (iir 0x0e88109a) Kernel: unaligned access to 0x173d22e82 in inet_gro_receive+0xc8/0x2e8 (iir 0x0e90109d) Kernel: unaligned access to 0x173d22e7a in inet_gro_receive+0xd0/0x2e8 (iir 0x0e9810b8) Kernel: unaligned access to 0x173d22e86 in inet_gro_receive+0xdc/0x2e8 (iir 0x0e8810b8) We have the option to a) ignore the warnings, b) work around it by adding more code to check for alignment, or c) to switch to the generic implementation and rely on the compiler to optimize the code. Let's go with c), because a) isn't nice, and b) would effectively lead to an implementation which is basically equal to c). Signed-off-by: Helge Deller Cc: stable@vger.kernel.org # v7.0+ Signed-off-by: Greg Kroah-Hartman commit e6e3724c7870da9afb0bcb7d239213a2841cf3ba Author: Helge Deller Date: Tue Apr 7 23:56:28 2026 +0200 parisc: _llseek syscall is only available for 32-bit userspace commit da3680f564bd787ce974f9931e6e924d908b3b2a upstream. Cc: stable@vger.kernel.org Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit c2462d54af3cb83ed843bf369f74ef0312e0feb8 Author: Robert Beckett Date: Fri Mar 20 19:22:08 2026 +0000 nvme: respect NVME_QUIRK_DISABLE_WRITE_ZEROES when wzsl is set commit 40f0496b617b431f8d2dd94d7f785c1121f8a68a upstream. The NVM Command Set Identify Controller data may report a non-zero Write Zeroes Size Limit (wzsl). When present, nvme_init_non_mdts_limits() unconditionally overrides max_zeroes_sectors from wzsl, even if NVME_QUIRK_DISABLE_WRITE_ZEROES previously set it to zero. This effectively re-enables write zeroes for devices that need it disabled, defeating the quirk. Several Kingston OM* drives rely on this quirk to avoid firmware issues with write zeroes commands. Check for the quirk before applying the wzsl override. Fixes: 5befc7c26e5a ("nvme: implement non-mdts command limits") Cc: stable@vger.kernel.org Signed-off-by: Robert Beckett Assisted-by: claude-opus-4-6-v1 Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 8bcc66896e01f93377d7883698cc7d88d2662480 Author: Robert Beckett Date: Fri Mar 20 19:22:09 2026 +0000 nvme-pci: add NVME_QUIRK_DISABLE_WRITE_ZEROES for Kingston OM3SGP4 commit a8eebf9699d69987cc49cec4e4fdb4111ab32423 upstream. The Kingston OM3SGP42048K2-A00 (PCI ID 2646:502f) firmware has a race condition when processing concurrent write zeroes and DSM (discard) commands, causing spurious "LBA Out of Range" errors and IOMMU page faults at address 0x0. The issue is reliably triggered by running two concurrent mkfs commands on different partitions of the same drive, which generates interleaved write zeroes and discard operations. Disable write zeroes for this device, matching the pattern used for other Kingston OM* drives that have similar firmware issues. Cc: stable@vger.kernel.org Signed-off-by: Robert Beckett Assisted-by: claude-opus-4-6-v1 Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit d89044889ecd11b0c2f86663597246e9bdd25679 Author: James Kim Date: Mon Mar 9 15:05:12 2026 +0900 mtd: docg3: fix use-after-free in docg3_release() commit ca19808bc6fac7e29420d8508df569b346b3e339 upstream. In docg3_release(), the docg3 pointer is obtained from cascade->floors[0]->priv before the loop that calls doc_release_device() on each floor. doc_release_device() frees the docg3 struct via kfree(docg3) at line 1881. After the loop, docg3->cascade->bch dereferences the already-freed pointer. Fix this by accessing cascade->bch directly, which is equivalent since docg3->cascade points back to the same cascade struct, and is already available as a local variable. This also removes the now-unused docg3 local variable. Fixes: c8ae3f744ddc ("lib/bch: Rework a little bit the exported function names") Cc: stable@vger.kernel.org Signed-off-by: James Kim Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 2774bcf714739cc6bb86f8812167bb9fbda70f6a Author: Thorsten Blum Date: Thu Apr 9 12:54:40 2026 +0200 mm/hugetlb: fix early boot crash on parameters without '=' separator commit c45b354911d01565156e38d7f6bc07edb51fc34c upstream. If hugepages, hugepagesz, or default_hugepagesz are specified on the kernel command line without the '=' separator, early parameter parsing passes NULL to hugetlb_add_param(), which dereferences it in strlen() and can crash the system during early boot. Reject NULL values in hugetlb_add_param() and return -EINVAL instead. Link: https://lore.kernel.org/20260409105437.108686-4-thorsten.blum@linux.dev Fixes: 5b47c02967ab ("mm/hugetlb: convert cmdline parameters from setup to early") Signed-off-by: Thorsten Blum Reviewed-by: Muchun Song Cc: David Hildenbrand Cc: Frank van der Linden Cc: Oscar Salvador Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 2691332ad88b57179c38653e2cd613d5820a52cf Author: SeongJae Park Date: Fri Mar 27 16:33:14 2026 -0700 mm/damon/core: fix damon_call() vs kdamond_fn() exit race commit 55da81663b9642dd046b26dd6f1baddbcf337c1e upstream. Patch series "mm/damon/core: fix damon_call()/damos_walk() vs kdmond exit race". damon_call() and damos_walk() can leak memory and/or deadlock when they race with kdamond terminations. Fix those. This patch (of 2); When kdamond_fn() main loop is finished, the function cancels all remaining damon_call() requests and unset the damon_ctx->kdamond so that API callers and API functions themselves can know the context is terminated. damon_call() adds the caller's request to the queue first. After that, it shows if the kdamond of the damon_ctx is still running (damon_ctx->kdamond is set). Only if the kdamond is running, damon_call() starts waiting for the kdamond's handling of the newly added request. The damon_call() requests registration and damon_ctx->kdamond unset are protected by different mutexes, though. Hence, damon_call() could race with damon_ctx->kdamond unset, and result in deadlocks. For example, let's suppose kdamond successfully finished the damon_call() requests cancelling. Right after that, damon_call() is called for the context. It registers the new request, and shows the context is still running, because damon_ctx->kdamond unset is not yet done. Hence the damon_call() caller starts waiting for the handling of the request. However, the kdamond is already on the termination steps, so it never handles the new request. As a result, the damon_call() caller threads infinitely waits. Fix this by introducing another damon_ctx field, namely call_controls_obsolete. It is protected by the damon_ctx->call_controls_lock, which protects damon_call() requests registration. Initialize (unset) it in kdamond_fn() before letting damon_start() returns and set it just before the cancelling of remaining damon_call() requests is executed. damon_call() reads the obsolete field under the lock and avoids adding a new request. After this change, only requests that are guaranteed to be handled or cancelled are registered. Hence the after-registration DAMON context termination check is no longer needed. Remove it together. Note that the deadlock will not happen when damon_call() is called for repeat mode request. In tis case, damon_call() returns instead of waiting for the handling when the request registration succeeds and it shows the kdamond is running. However, if the request also has dealloc_on_cancel, the request memory would be leaked. The issue is found by sashiko [1]. Link: https://lore.kernel.org/20260327233319.3528-1-sj@kernel.org Link: https://lore.kernel.org/20260327233319.3528-2-sj@kernel.org Link: https://lore.kernel.org/20260325141956.87144-1-sj@kernel.org [1] Fixes: 42b7491af14c ("mm/damon/core: introduce damon_call()") Signed-off-by: SeongJae Park Cc: # 6.14.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit d5b495ba9de0423ef39f8bd86729a885870c7efe Author: Hao Ge Date: Tue Mar 31 16:13:12 2026 +0800 mm/alloc_tag: clear codetag for pages allocated before page_ext initialization commit 6b1842775a460245e97d36d3a67d0cfba7c4ff79 upstream. Due to initialization ordering, page_ext is allocated and initialized relatively late during boot. Some pages have already been allocated and freed before page_ext becomes available, leaving their codetag uninitialized. A clear example is in init_section_page_ext(): alloc_page_ext() calls kmemleak_alloc(). If the slab cache has no free objects, it falls back to the buddy allocator to allocate memory. However, at this point page_ext is not yet fully initialized, so these newly allocated pages have no codetag set. These pages may later be reclaimed by KASAN, which causes the warning to trigger when they are freed because their codetag ref is still empty. Use a global array to track pages allocated before page_ext is fully initialized. The array size is fixed at 8192 entries, and will emit a warning if this limit is exceeded. When page_ext initialization completes, set their codetag to empty to avoid warnings when they are freed later. This warning is only observed with CONFIG_MEM_ALLOC_PROFILING_DEBUG=Y and mem_profiling_compressed disabled: [ 9.582133] ------------[ cut here ]------------ [ 9.582137] alloc_tag was not set [ 9.582139] WARNING: ./include/linux/alloc_tag.h:164 at __pgalloc_tag_sub+0x40f/0x550, CPU#5: systemd/1 [ 9.582190] CPU: 5 UID: 0 PID: 1 Comm: systemd Not tainted 7.0.0-rc4 #1 PREEMPT(lazy) [ 9.582192] Hardware name: Red Hat KVM, BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 9.582194] RIP: 0010:__pgalloc_tag_sub+0x40f/0x550 [ 9.582196] Code: 00 00 4c 29 e5 48 8b 05 1f 88 56 05 48 8d 4c ad 00 48 8d 2c c8 e9 87 fd ff ff 0f 0b 0f 0b e9 f3 fe ff ff 48 8d 3d 61 2f ed 03 <67> 48 0f b9 3a e9 b3 fd ff ff 0f 0b eb e4 e8 5e cd 14 02 4c 89 c7 [ 9.582197] RSP: 0018:ffffc9000001f940 EFLAGS: 00010246 [ 9.582200] RAX: dffffc0000000000 RBX: 1ffff92000003f2b RCX: 1ffff110200d806c [ 9.582201] RDX: ffff8881006c0360 RSI: 0000000000000004 RDI: ffffffff9bc7b460 [ 9.582202] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff3a62324 [ 9.582203] R10: ffffffff9d311923 R11: 0000000000000000 R12: ffffea0004001b00 [ 9.582204] R13: 0000000000002000 R14: ffffea0000000000 R15: ffff8881006c0360 [ 9.582206] FS: 00007ffbbcf2d940(0000) GS:ffff888450479000(0000) knlGS:0000000000000000 [ 9.582208] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9.582210] CR2: 000055ee3aa260d0 CR3: 0000000148b67005 CR4: 0000000000770ef0 [ 9.582211] PKRU: 55555554 [ 9.582212] Call Trace: [ 9.582213] [ 9.582214] ? __pfx___pgalloc_tag_sub+0x10/0x10 [ 9.582216] ? check_bytes_and_report+0x68/0x140 [ 9.582219] __free_frozen_pages+0x2e4/0x1150 [ 9.582221] ? __free_slab+0xc2/0x2b0 [ 9.582224] qlist_free_all+0x4c/0xf0 [ 9.582227] kasan_quarantine_reduce+0x15d/0x180 [ 9.582229] __kasan_slab_alloc+0x69/0x90 [ 9.582232] kmem_cache_alloc_noprof+0x14a/0x500 [ 9.582234] do_getname+0x96/0x310 [ 9.582237] do_readlinkat+0x91/0x2f0 [ 9.582239] ? __pfx_do_readlinkat+0x10/0x10 [ 9.582240] ? get_random_bytes_user+0x1df/0x2c0 [ 9.582244] __x64_sys_readlinkat+0x96/0x100 [ 9.582246] do_syscall_64+0xce/0x650 [ 9.582250] ? __x64_sys_getrandom+0x13a/0x1e0 [ 9.582252] ? __pfx___x64_sys_getrandom+0x10/0x10 [ 9.582254] ? do_syscall_64+0x114/0x650 [ 9.582255] ? ksys_read+0xfc/0x1d0 [ 9.582258] ? __pfx_ksys_read+0x10/0x10 [ 9.582260] ? do_syscall_64+0x114/0x650 [ 9.582262] ? do_syscall_64+0x114/0x650 [ 9.582264] ? __pfx_fput_close_sync+0x10/0x10 [ 9.582266] ? file_close_fd_locked+0x178/0x2a0 [ 9.582268] ? __x64_sys_faccessat2+0x96/0x100 [ 9.582269] ? __x64_sys_close+0x7d/0xd0 [ 9.582271] ? do_syscall_64+0x114/0x650 [ 9.582273] ? do_syscall_64+0x114/0x650 [ 9.582275] ? clear_bhb_loop+0x50/0xa0 [ 9.582277] ? clear_bhb_loop+0x50/0xa0 [ 9.582279] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 9.582280] RIP: 0033:0x7ffbbda345ee [ 9.582282] Code: 0f 1f 40 00 48 8b 15 29 38 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff c3 0f 1f 40 00 f3 0f 1e fa 49 89 ca b8 0b 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d fa 37 0d 00 f7 d8 64 89 01 48 [ 9.582284] RSP: 002b:00007ffe2ad8de58 EFLAGS: 00000202 ORIG_RAX: 000000000000010b [ 9.582286] RAX: ffffffffffffffda RBX: 000055ee3aa25570 RCX: 00007ffbbda345ee [ 9.582287] RDX: 000055ee3aa25570 RSI: 00007ffe2ad8dee0 RDI: 00000000ffffff9c [ 9.582288] RBP: 0000000000001000 R08: 0000000000000003 R09: 0000000000001001 [ 9.582289] R10: 0000000000001000 R11: 0000000000000202 R12: 0000000000000033 [ 9.582290] R13: 00007ffe2ad8dee0 R14: 00000000ffffff9c R15: 00007ffe2ad8deb0 [ 9.582292] [ 9.582293] ---[ end trace 0000000000000000 ]--- Link: https://lore.kernel.org/20260331081312.123719-1-hao.ge@linux.dev Fixes: dcfe378c81f72 ("lib: introduce support for page allocation tagging") Signed-off-by: Hao Ge Suggested-by: Suren Baghdasaryan Acked-by: Suren Baghdasaryan Cc: Kent Overstreet Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 3c52d09469770c57dffad55677f2ade3e35596fa Author: Marek Vasut Date: Thu Jan 22 12:13:21 2026 +0100 mfd: stpmic1: Attempt system shutdown twice in case PMIC is confused commit ffdc5c51f8bcd0e5e8255ca275a0a3b958475d99 upstream. Attempt to shut down again, in case the first attempt failed. The STPMIC1 might get confused and the first regmap_update_bits() returns with -ETIMEDOUT / -110 . If that or similar transient failure occurs, try to shut down again. If the second attempt fails, there is some bigger problem, report it to user. Cc: stable@vger.kernel.org Fixes: 6e9df38f359a ("mfd: stpmic1: Add PMIC poweroff via sys-off handler") Signed-off-by: Marek Vasut Link: https://patch.msgid.link/20260122111423.62591-1-marex@nabladev.com Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 377f5ad257fb32767b7435a9d4f1db64c9832adb Author: Jens Axboe Date: Mon Apr 20 13:41:38 2026 -0600 io_uring/register: fix ring resizing with mixed/large SQEs/CQEs Commit 45cd95763e198d74d369ede43aef0b1955b8dea4 upstream. The ring resizing only properly handles "normal" sized SQEs or CQEs, if there are pending entries around a resize. This normally should not be the case, but the code is supposed to handle this regardless. For the mixed SQE/CQE cases, the current copying works fine as they are indexed in the same way. Each half is just copied separately. But for fixed large SQEs and CQEs, the iteration and copy need to take that into account. Cc: stable@kernel.org Fixes: 79cfe9e59c2a ("io_uring/register: add IORING_REGISTER_RESIZE_RINGS") Reviewed-by: Gabriel Krisman Bertazi Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit cac2106bb9a2180b288079b49ed626414fb5bc45 Author: Josh Hunt Date: Mon Mar 2 19:56:19 2026 -0500 md/raid10: fix deadlock with check operation and nowait requests commit 7d96f3120a7fb7210d21b520c5b6f495da6ba436 upstream. When an array check is running it will raise the barrier at which point normal requests will become blocked and increment the nr_pending value to signal there is work pending inside of wait_barrier(). NOWAIT requests do not block and so will return immediately with an error, and additionally do not increment nr_pending in wait_barrier(). Upstream change commit 43806c3d5b9b ("raid10: cleanup memleak at raid10_make_request") added a call to raid_end_bio_io() to fix a memory leak when NOWAIT requests hit this condition. raid_end_bio_io() eventually calls allow_barrier() and it will unconditionally do an atomic_dec_and_test(&conf->nr_pending) even though the corresponding increment on nr_pending didn't happen in the NOWAIT case. This can be easily seen by starting a check operation while an application is doing nowait IO on the same array. This results in a deadlocked state due to nr_pending value underflowing and so the md resync thread gets stuck waiting for nr_pending to == 0. Output of r10conf state of the array when we hit this condition: crash> struct r10conf barrier = 1, nr_pending = { counter = -41 }, nr_waiting = 15, nr_queued = 0, Example of md_sync thread stuck waiting on raise_barrier() and other requests stuck in wait_barrier(): md1_resync [<0>] raise_barrier+0xce/0x1c0 [<0>] raid10_sync_request+0x1ca/0x1ed0 [<0>] md_do_sync+0x779/0x1110 [<0>] md_thread+0x90/0x160 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30 kworker/u1040:2+flush-253:4 [<0>] wait_barrier+0x1de/0x220 [<0>] regular_request_wait+0x30/0x180 [<0>] raid10_make_request+0x261/0x1000 [<0>] md_handle_request+0x13b/0x230 [<0>] __submit_bio+0x107/0x1f0 [<0>] submit_bio_noacct_nocheck+0x16f/0x390 [<0>] ext4_io_submit+0x24/0x40 [<0>] ext4_do_writepages+0x254/0xc80 [<0>] ext4_writepages+0x84/0x120 [<0>] do_writepages+0x7a/0x260 [<0>] __writeback_single_inode+0x3d/0x300 [<0>] writeback_sb_inodes+0x1dd/0x470 [<0>] __writeback_inodes_wb+0x4c/0xe0 [<0>] wb_writeback+0x18b/0x2d0 [<0>] wb_workfn+0x2a1/0x400 [<0>] process_one_work+0x149/0x330 [<0>] worker_thread+0x2d2/0x410 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30 Fixes: 43806c3d5b9b ("raid10: cleanup memleak at raid10_make_request") Cc: stable@vger.kernel.org Signed-off-by: Josh Hunt Link: https://lore.kernel.org/linux-raid/20260303005619.1352958-1-johunt@akamai.com Signed-off-by: Yu Kuai Signed-off-by: Greg Kroah-Hartman commit bdf33ba450afe2cde36f3e03fb5a5928da18dc34 Author: Sean Christopherson Date: Thu Feb 12 18:38:41 2026 +0800 KVM: selftests: Fix reserved value WRMSR testcase for multi-feature MSRs commit 9396cc1e282a280bcba2e932e03994e0aada4cd8 upstream. When determining whether or not a WRMSR with reserved bits will #GP or succeed due to the WRMSR not existing per the guest virtual CPU model, expect failure if and only if _all_ features associated with the MSR are unsupported. Checking only the primary feature results in false failures when running on AMD and Hygon CPUs with only one of RDPID or RDTSCP, as AMD/Hygon CPUs ignore MSR_TSC_AUX[63:32], i.e. don't treat the bits as reserved, and so #GP only if the MSR is unsupported. Fixes: 9c38ddb3df94 ("KVM: selftests: Add an MSR test to exercise guest/host and read/write") Reported-by: Zhiquan Li Closes: https://lore.kernel.org/all/20260209041305.64906-6-zhiquan_li@163.com Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260212103841.171459-5-zhiquan_li@163.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 2b2fee890250ab647a601124471a334bb01a0790 Author: Zhang Yi Date: Thu Apr 9 19:42:03 2026 +0800 jbd2: fix deadlock in jbd2_journal_cancel_revoke() commit 981fcc5674e67158d24d23e841523eccba19d0e7 upstream. Commit f76d4c28a46a ("fs/jbd2: use sleeping version of __find_get_block()") changed jbd2_journal_cancel_revoke() to use __find_get_block_nonatomic() which holds the folio lock instead of i_private_lock. This breaks the lock ordering (folio -> buffer) and causes an ABBA deadlock when the filesystem blocksize < pagesize: T1 T2 ext4_mkdir() ext4_init_new_dir() ext4_append() ext4_getblk() lock_buffer() <- A sync_blockdev() blkdev_writepages() writeback_iter() writeback_get_folio() folio_lock() <- B ext4_journal_get_create_access() jbd2_journal_cancel_revoke() __find_get_block_nonatomic() folio_lock() <- B block_write_full_folio() lock_buffer() <- A This can occasionally cause generic/013 to hang. Fix by only calling __find_get_block_nonatomic() when the passed buffer_head doesn't belong to the bdev, which is the only case that we need to look up its bdev alias. Otherwise, the lookup is redundant since the found buffer_head is equal to the one we passed in. Fixes: f76d4c28a46a ("fs/jbd2: use sleeping version of __find_get_block()") Signed-off-by: Zhang Yi Link: https://patch.msgid.link/20260409114204.917154-1-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 858bc8b9edb6eaf0522900128bb9053e2df6b0f6 Author: Corey Minyard Date: Mon Apr 13 08:00:23 2026 -0500 ipmi:ssif: Clean up kthread on errors commit 75c486cb1bcaa1a3ec3a6438498176a3a4998ae4 upstream. If an error occurs after the ssif kthread is created, but before the main IPMI code starts the ssif interface, the ssif kthread will not be stopped. So make sure the kthread is stopped on an error condition if it is running. Fixes: 259307074bfc ("ipmi: Add SMBus interface driver (SSIF)") Reported-by: Li Xiao <<252270051@hdu.edu.cn> Cc: stable@vger.kernel.org Reviewed-by: Li Xiao <252270051@hdu.edu.cn> Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman commit 8ebb951a284b7446e025afc7dc5e9516ef9a7214 Author: Gao Xiang Date: Tue Apr 21 15:59:52 2026 +0800 erofs: fix the out-of-bounds nameoff handling for trailing dirents commit d18a3b5d337fa412a38e776e6b4b857a58836575 upstream. Currently we already have boundary-checks for nameoffs, but the trailing dirents are special since the namelens are calculated with strnlen() with unchecked nameoffs. If a crafted EROFS has a trailing dirent with nameoff >= maxsize, maxsize - nameoff can underflow, causing strnlen() to read past the directory block. nameoff0 should also be verified to be a multiple of `sizeof(struct erofs_dirent)` as well [1]. [1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com Fixes: 3aa8ec716e52 ("staging: erofs: add directory operations") Fixes: 33bac912840f ("staging: erofs: keep corrupted fs from crashing kernel in erofs_readdir()") Reported-by: Yuhao Jiang Reported-by: Junrui Luo Closes: https://lore.kernel.org/r/A0FD7E0F-7558-49B0-8BC8-EB1ECDB2479A@outlook.com Cc: stable@vger.kernel.org Signed-off-by: Gao Xiang Reviewed-by: Chao Yu Signed-off-by: Greg Kroah-Hartman commit 33074b1e6c18fad4d9e3504178bdf08d64a1c512 Author: Cássio Gabriel Date: Tue Mar 24 16:59:41 2026 -0300 ALSA: seq_oss: return full count for successful SEQ_FULLSIZE writes commit bbc6c0dda54fc0ad8f8aed0b796c23e186e1a188 upstream. snd_seq_oss_write() currently returns the raw load_patch() callback result for SEQ_FULLSIZE events. That callback is documented as returning 0 on success and -errno on failure, but snd_seq_oss_write() is the file write path and should report the number of user bytes consumed on success. Some in-tree backends also return backend-specific positive values, which can still be shorter than the original write size. Return the full byte count for successful SEQ_FULLSIZE writes. Preserve negative errors and convert any nonnegative completion to the original count. Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260324-alsa-seq-oss-fullsize-write-return-v1-1-66d448510538@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 09496158f6ebba8830593f8972035c02f97124c1 Author: Harin Lee Date: Mon Apr 6 16:49:13 2026 +0900 ALSA: ctxfi: Add fallback to default RSR for S/PDIF commit 7d61662197ecdc458e33e475b6ada7f6da61d364 upstream. spdif_passthru_playback_get_resources() uses atc->pll_rate as the RSR for the MSR calculation loop. However, pll_rate is only updated in atc_pll_init() and not in hw_pll_init(), so it remains 0 after the card init. When spdif_passthru_playback_setup() skips atc_pll_init() for 32000 Hz, (rsr * desc.msr) always becomes 0, causing the loop to spin indefinitely. Add fallback to use atc->rsr when atc->pll_rate is 0. This reflects the hardware state, since hw_card_init() already configures the PLL to the default RSR. Fixes: 8cc72361481f ("ALSA: SB X-Fi driver merge") Cc: stable@vger.kernel.org Signed-off-by: Harin Lee Link: https://patch.msgid.link/20260406074913.217374-1-me@harin.net Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8d3124290a03d5c6b45b77d7e60832c99194c0ae Author: Thorsten Blum Date: Tue Mar 10 11:29:20 2026 +0100 ALSA: aoa: Skip devices with no codecs in i2sbus_resume() commit fd7df93013c5118812e63a52635dc6c3a805a1de upstream. In i2sbus_resume(), skip devices with an empty codec list, which avoids using an uninitialized 'sysclock_factor' in the 32-bit format path in i2sbus_pcm_prepare(). In i2sbus_pcm_prepare(), replace two list_for_each_entry() loops with a single list_first_entry() now that the codec list is guaranteed to be non-empty by all callers. Fixes: f3d9478b2ce4 ("[ALSA] snd-aoa: add snd-aoa") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Link: https://patch.msgid.link/20260310102921.210109-3-thorsten.blum@linux.dev Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit df462e82e82c8d438e3fcd7964014a13894b1942 Author: Cássio Gabriel Date: Mon Mar 30 01:00:34 2026 -0300 ALSA: aoa: i2sbus: fix OF node lifetime handling commit 4ec93f070eda6b765b62efcaed9241c3b3b0b6ad upstream. i2sbus_add_dev() keeps the matched "sound" child pointer after for_each_child_of_node() has dropped the iterator reference. Take an extra reference before saving that node and drop it after the layout-id/device-id lookup is complete. The function also stores np in dev->sound.ofdev.dev.of_node without taking a reference for the embedded soundbus device. Since i2sbus overrides the embedded platform device release callback, balance that reference explicitly in the local error path and in i2sbus_release_dev(). Fixes: f3d9478b2ce4 ("[ALSA] snd-aoa: add snd-aoa") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260330-aoa-i2sbus-ofnode-lifetime-v1-1-51c309f4ff06@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e79427ee11a868071e39b46b4afa5e950a0a7cec Author: Cássio Gabriel Date: Tue Mar 31 18:14:04 2026 -0300 ALSA: aoa: i2sbus: clear stale prepared state commit 5ed060d5491597490fb53ec69da3edc4b1e8c165 upstream. The i2sbus PCM code uses pi->active to constrain the sibling stream to an already prepared duplex format and rate in i2sbus_pcm_open(). That state is set from i2sbus_pcm_prepare(), but the current code only clears it on close. As a result, the sibling stream can inherit stale constraints after the prepared state has been torn down. Clear pi->active when hw_params() or hw_free() tears down the prepared state, and set it again only after prepare succeeds. Replace the stale FIXME in the duplex constraint comment with a description of the current driver behavior: i2sbus still programs a single shared transport configuration for both directions, so mixed formats are not supported in duplex mode. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202604010125.AvkWBYKI-lkp@intel.com/ Fixes: f3d9478b2ce4 ("[ALSA] snd-aoa: add snd-aoa") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260331-aoa-i2sbus-clear-stale-active-v2-1-3764ae2889a1@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 0ae7d28dda5c0978d7c0a5e8e9975ba6627a8ef2 Author: Shigeru Yoshida Date: Sat Mar 21 22:29:11 2026 +0900 mm/zsmalloc: copy KMSAN metadata in zs_page_migrate() commit 4fb61d95ad21c3b6f1c09f357ff49d70abb0535e upstream. zs_page_migrate() uses copy_page() to copy the contents of a zspage page during migration. However, copy_page() is not instrumented by KMSAN, so the shadow and origin metadata of the destination page are not updated. As a result, subsequent accesses to the migrated page are reported as use-after-free by KMSAN, despite the data being correctly copied. Add a kmsan_copy_page_meta() call after copy_page() to propagate the KMSAN metadata to the new page, matching what copy_highpage() does internally. Link: https://lkml.kernel.org/r/20260321132912.93434-1-syoshida@redhat.com Fixes: afb2d666d025 ("zsmalloc: use copy_page for full page copy") Signed-off-by: Shigeru Yoshida Reviewed-by: Sergey Senozhatsky Cc: Mark-PK Tsai Cc: Minchan Kim Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 2dde6377ab2e46bb80cf066c659ef016f3ad7a9b Author: Vasiliy Kovalev Date: Sat Apr 4 18:20:11 2026 +0300 ext2: reject inodes with zero i_nlink and valid mode in ext2_iget() commit 25947cc5b2374cd5bf627fe3141496444260d04f upstream. ext2_iget() already rejects inodes with i_nlink == 0 when i_mode is zero or i_dtime is set, treating them as deleted. However, the case of i_nlink == 0 with a non-zero mode and zero dtime slips through. Since ext2 has no orphan list, such a combination can only result from filesystem corruption - a legitimate inode deletion always sets either i_dtime or clears i_mode before freeing the inode. A crafted image can exploit this gap to present such an inode to the VFS, which then triggers WARN_ON inside drop_nlink() (fs/inode.c) via ext2_unlink(), ext2_rename() and ext2_rmdir(): WARNING: CPU: 3 PID: 609 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 3 UID: 0 PID: 609 Comm: syz-executor Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_unlink+0x26c/0x300 fs/ext2/namei.c:295 vfs_unlink+0x2fc/0x9b0 fs/namei.c:4477 do_unlinkat+0x53e/0x730 fs/namei.c:4541 __x64_sys_unlink+0xc6/0x110 fs/namei.c:4587 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f WARNING: CPU: 0 PID: 646 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 0 UID: 0 PID: 646 Comm: syz.0.17 Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_rename+0x35e/0x850 fs/ext2/namei.c:374 vfs_rename+0xf2f/0x2060 fs/namei.c:5021 do_renameat2+0xbe2/0xd50 fs/namei.c:5178 __x64_sys_rename+0x7e/0xa0 fs/namei.c:5223 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f WARNING: CPU: 0 PID: 634 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 0 UID: 0 PID: 634 Comm: syz-executor Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_rmdir+0xca/0x110 fs/ext2/namei.c:311 vfs_rmdir+0x204/0x690 fs/namei.c:4348 do_rmdir+0x372/0x3e0 fs/namei.c:4407 __x64_sys_unlinkat+0xf0/0x130 fs/namei.c:4577 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f Extend the existing i_nlink == 0 check to also catch this case, reporting the corruption via ext2_error() and returning -EFSCORRUPTED. This rejects the inode at load time and prevents it from reaching any of the namei.c paths. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Vasiliy Kovalev Link: https://patch.msgid.link/20260404152011.2590197-1-kovalev@altlinux.org Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 2e127ceb1c415e246076d8e09e23e443a7a2038f Author: Manivannan Sadhasivam Date: Thu Apr 9 23:04:16 2026 +0530 net: qrtr: ns: Fix use-after-free in driver remove() commit 7809fea20c9404bfcfa6112ec08d1fe1d3520beb upstream. In the remove callback, if a packet arrives after destroy_workqueue() is called, but before sock_release(), the qrtr_ns_data_ready() callback will try to queue the work, causing use-after-free issue. Fix this issue by saving the default 'sk_data_ready' callback during qrtr_ns_init() and use it to replace the qrtr_ns_data_ready() callback at the start of remove(). This ensures that even if a packet arrives after destroy_workqueue(), the work struct will not be dereferenced. Note that it is also required to ensure that the RX threads are completed before destroying the workqueue, because the threads could be using the qrtr_ns_data_ready() callback. Cc: stable@vger.kernel.org Fixes: 0c2204a4ad71 ("net: qrtr: Migrate nameservice to kernel from userspace") Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260409-qrtr-fix-v3-5-00a8a5ff2b51@oss.qualcomm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit da47f8a5958ce8e7a8d5d3eb774fa41d7117b2d5 Author: Chen Ni Date: Wed Feb 4 10:48:59 2026 +0800 media: i2c: imx219: Check return value of devm_gpiod_get_optional() in imx219_probe() commit 943b1f27a3eead21b22e2531a5432ea5910b60eb upstream. The devm_gpiod_get_optional() function may return an error pointer (ERR_PTR) in case of a genuine failure during GPIO acquisition, not just NULL which indicates the legitimate absence of an optional GPIO. Add an IS_ERR() check after the function call to catch such errors and propagate them to the probe function, ensuring the driver fails to load safely rather than proceeding with an invalid pointer. Fixes: 1283b3b8f82b ("media: i2c: Add driver for Sony IMX219 sensor") Cc: stable@vger.kernel.org Signed-off-by: Chen Ni Reviewed-by: Dave Stevenson Reviewed-by: Jai Luthra Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 4d3a4638e9d21dd0e4aa44ee150880486ad282ec Author: Josh Law Date: Sun Mar 8 20:20:28 2026 +0000 lib/ts_kmp: fix integer overflow in pattern length calculation commit 8cdf30813ea8ce881cecc08664144416dbdb3e16 upstream. The ts_kmp algorithm stores its prefix_tbl[] table and pattern in a single allocation sized from the pattern length. If the prefix_tbl[] size calculation wraps, the resulting allocation can be too small and subsequent pattern copies can overflow it. Fix this by rejecting zero-length patterns and by using overflow helpers before calculating the combined allocation size. This fixes a potential heap overflow. The pattern length calculation can wrap during a size_t addition, leading to an undersized allocation. Because the textsearch library is reachable from userspace via Netfilter's xt_string module, this is a security risk that should be backported to LTS kernels. Link: https://lkml.kernel.org/r/20260308202028.2889285-2-objecting@objecting.org Signed-off-by: Josh Law Reviewed-by: Andrew Morton Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit dca29d20ab236f0f587bac76a4b7fc86ac172562 Author: Daniel Hodges Date: Fri Feb 6 15:05:29 2026 -0500 PCI: epf-mhi: Return 0, not remaining timeout, when eDMA ops complete commit 36bfc3642b19a98f1302aed4437c331df9b481f0 upstream. pci_epf_mhi_edma_read() and pci_epf_mhi_edma_write() start DMA operations and wait for completion with a timeout. On successful completion, they previously returned the remaining timeout, which callers may treat as an error. In particular, mhi_ep_ring_add_element(), which calls pci_epf_mhi_edma_write() via mhi_cntrl->write_sync(), interprets any non-zero return value as failure. Return 0 on success instead of the remaining timeout to prevent mhi_ep_ring_add_element() from treating successful completion as an error. Fixes: 7b99aaaddabb ("PCI: epf-mhi: Add eDMA support") Signed-off-by: Daniel Hodges [mani: changed commit log as per https://lore.kernel.org/linux-pci/20260227191510.GA3904799@bhelgaas] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Krishna Chaitanya Chundru Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260206200529.10784-1-git@danielhodges.dev Signed-off-by: Greg Kroah-Hartman commit 127a1fe59c78d89e61637e3141f77b5e01570de1 Author: Rong Zhang Date: Wed Mar 4 03:47:56 2026 +0800 Revert "ALSA: usb: Increase volume range that triggers a warning" commit 41d78cb724f4b40b7548af420ccfe524b14023bb upstream. UAC uses 2 bytes to store volume values, so the maximum volume range is 0xFFFF (65535, val = -32768/32767/1). The reverted commit bumpped the range of triggering the warning to > 65535, effectively making the range check a no-op. It didn't fix anything but covered any potential problems and deviated from the original intention of the range check. This reverts commit 6b971191fcfc9e3c2c0143eea22534f1f48dbb62. Fixes: 6b971191fcfc ("ALSA: usb: Increase volume range that triggers a warning") Cc: stable@vger.kernel.org Signed-off-by: Rong Zhang Acked-by: Arun Raghavan Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260303194805.266158-2-i@rong.moe Signed-off-by: Greg Kroah-Hartman commit 65fc57c8b8f0b31be62be291cb1bb01755cec85d Author: Koichiro Den Date: Thu Feb 26 17:41:39 2026 +0900 PCI: endpoint: pci-epf-ntb: Remove duplicate resource teardown commit 3446beddba450c8d6f9aca2f028712ac527fead3 upstream. epf_ntb_epc_destroy() duplicates the teardown that the caller is supposed to do later. This leads to an oops when .allow_link fails or when .drop_link is performed. Remove the helper. Also drop pci_epc_put(). EPC device refcounting is tied to configfs EPC group lifetime, and pci_epc_put() in the .drop_link path is sufficient. Fixes: 8b821cf76150 ("PCI: endpoint: Add EP function driver to provide NTB functionality") Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Reviewed-by: Frank Li Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260226084142.2226875-3-den@valinux.co.jp Signed-off-by: Greg Kroah-Hartman commit 4ca4351d269f8ae4276af45167f68846c2606e9a Author: Thorsten Blum Date: Mon Feb 16 08:45:51 2026 +0100 crypto: atmel-sha204a - Fix OTP sysfs read and error handling commit 635c3a757a567b2479639237f5f0d4d9439015f1 upstream. Fix otp_show() to read and print all 64 bytes of the OTP zone. Previously, the loop only printed half of the OTP (32 bytes), and partial output was returned on read errors. Propagate the actual error from atmel_sha204a_otp_read() instead of producing partial output. Replace sprintf() with sysfs_emit_at(), which is preferred for formatting sysfs output because it provides safer bounds checking. Cc: stable@vger.kernel.org Fixes: 13909a0c8897 ("crypto: atmel-sha204a - provide the otp content") Signed-off-by: Thorsten Blum Reviewed-by: Lothar Rubusch Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 26506a30e0e26d612f82a7bf0e395626968a44e6 Author: Fan Wu Date: Wed Mar 4 03:19:34 2026 +0000 media: mtk-jpeg: fix use-after-free in release path due to uncancelled work commit 34c519feef3e4fcff1078dc8bdb25fbbbd10303f upstream. The mtk_jpeg_release() function frees the context structure (ctx) without first cancelling any pending or running work in ctx->jpeg_work. This creates a race window where the workqueue callback may still be accessing the context memory after it has been freed. Race condition: CPU 0 (release) CPU 1 (workqueue) ---------------- ------------------ close() mtk_jpeg_release() mtk_jpegenc_worker() ctx = work->data // accessing ctx kfree(ctx) // freed! access ctx // UAF! The work is queued via queue_work() during JPEG encode/decode operations (via mtk_jpeg_device_run). If the device is closed while work is pending or running, the work handler will access freed memory. Fix this by calling cancel_work_sync() BEFORE acquiring the mutex. This ordering is critical: if cancel_work_sync() is called after mutex_lock(), and the work handler also tries to acquire the same mutex, it would cause a deadlock. Note: The open error path does NOT need cancel_work_sync() because INIT_WORK() only initializes the work structure - it does not schedule it. Work is only scheduled later during ioctl operations. Fixes: 5fb1c2361e56 ("mtk-jpegenc: add jpeg encode worker interface") Cc: stable@vger.kernel.org Signed-off-by: Fan Wu Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 19ca9475f18f991735f98a22e735c43e95e6298d Author: Luxiao Xu Date: Sat Apr 11 23:10:10 2026 +0800 net: strparser: fix skb_head leak in strp_abort_strp() commit fe72340daaf1af588be88056faf98965f39e6032 upstream. When the stream parser is aborted, for example after a message assembly timeout, it can still hold a reference to a partially assembled message in strp->skb_head. That skb is not released in strp_abort_strp(), which leaks the partially assembled message and can be triggered repeatedly to exhaust memory. Fix this by freeing strp->skb_head and resetting the parser state in the abort path. Leave strp_stop() unchanged so final cleanup still happens in strp_done() after the work and timer have been synchronized. Fixes: 43a0c6751a32 ("strparser: Stream parser for messages") Cc: stable@kernel.org Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Tested-by: Yuan Tan Signed-off-by: Luxiao Xu Signed-off-by: Ren Wei Link: https://patch.msgid.link/ade3857a9404999ce9a1c27ec523efc896072678.1775482694.git.rakukuip@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 63d21a3aa0108b9dde4e99b0d3d5d679ac68c0f9 Author: Zhengchuan Liang Date: Sat Apr 11 23:10:26 2026 +0800 net: caif: clear client service pointer on teardown commit f7cf8ece8cee3c1ee361991470cdb1eb65ab02e8 upstream. `caif_connect()` can tear down an existing client after remote shutdown by calling `caif_disconnect_client()` followed by `caif_free_client()`. `caif_free_client()` releases the service layer referenced by `adap_layer->dn`, but leaves that pointer stale. When the socket is later destroyed, `caif_sock_destructor()` calls `caif_free_client()` again and dereferences the freed service pointer. Clear the client/service links before releasing the service object so repeated teardown becomes harmless. Fixes: 43e369210108 ("caif: Move refcount from service layer to sock and dev.") Cc: stable@kernel.org Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Tested-by: Ren Wei Signed-off-by: Zhengchuan Liang Signed-off-by: Ren Wei Link: https://patch.msgid.link/9f3d37847c0037568aae698ca23cd47c6691acb0.1775897577.git.zcliangcn@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 654c818a69c21d2bea4e8fd9eae7da865df9a5c8 Author: Ziqing Chen Date: Tue Apr 14 21:24:37 2026 +0800 ALSA: control: Validate buf_len before strnlen() in snd_ctl_elem_init_enum_names() commit e0da8a8cac74f4b9f577979d131f0d2b88a84487 upstream. snd_ctl_elem_init_enum_names() advances pointer p through the names buffer while decrementing buf_len. If buf_len reaches zero but items remain, the next iteration calls strnlen(p, 0). While strnlen(p, 0) returns 0 and would hit the existing name_len == 0 error path, CONFIG_FORTIFY_SOURCE's fortified strnlen() first checks maxlen against __builtin_dynamic_object_size(). When Clang loses track of p's object size inside the loop, this triggers a BRK exception panic before the return value is examined. Add a buf_len == 0 guard at the loop entry to prevent calling fortified strnlen() on an exhausted buffer. Found by kernel fuzz testing through Xiaomi Smartphone. Fixes: 8d448162bda5 ("ALSA: control: add support for ENUMERATED user space controls") Cc: stable@vger.kernel.org Signed-off-by: Ziqing Chen Link: https://patch.msgid.link/20260414132437.261304-1-chenziqing@xiaomi.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit fdc150dac1adb9a98be9d6956cff0348838b024a Author: Ming Qian Date: Fri Mar 6 14:59:50 2026 +0800 media: amphion: Fix race between m2m job_abort and device_run commit 8cd35ceadcfc8c5da2eb7f7ce24525ce9d4ee62e upstream. Fix kernel panic caused by race condition where v4l2_m2m_ctx_release() frees m2m_ctx while v4l2_m2m_try_run() is about to call device_run with the same context. Race sequence: v4l2_m2m_try_run(): v4l2_m2m_ctx_release(): lock/unlock v4l2_m2m_cancel_job() job_abort() v4l2_m2m_job_finish() kfree(m2m_ctx) <- frees ctx device_run() <- use-after-free crash at 0x538 Crash trace: Unable to handle kernel read from unreadable memory at virtual address 0000000000000538 v4l2_m2m_try_run+0x78/0x138 v4l2_m2m_device_run_work+0x14/0x20 The amphion vpu driver does not rely on the m2m framework's device_run callback to perform encode/decode operations. Fix the race by preventing m2m framework job scheduling entirely: - Add job_ready callback returning 0 (no jobs ready for m2m framework) - Remove job_abort callback to avoid the race condition Fixes: 3cd084519c6f ("media: amphion: add vpu v4l2 m2m support") Cc: stable@vger.kernel.org Signed-off-by: Ming Qian Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit e0a621459c61384fe648a13287cb1a6dee07d853 Author: Richard Zhu Date: Sat Feb 28 16:09:25 2026 +0800 PCI: imx6: Skip waiting for L2/L3 Ready on i.MX6SX commit 5f73cf1db829c21b7fd44a8d2587cd395b1b2d76 upstream. On i.MX6SX, the LTSSM registers become inaccessible after the PME_Turn_Off message is sent to the link. So there is no way to verify whether the link has entered L2/L3 Ready state or not. Hence, set IMX_PCIE_FLAG_SKIP_L23_READY flag for i.MX6SX SoC to skip the L2/L3 Ready state polling and let the DWC core wait for 10ms after sending the PME_Turn_Off message as per the PCIe spec r6.0, sec 5.3.3.2.1. Fixes: a528d1a72597 ("PCI: imx6: Use DWC common suspend resume method") Signed-off-by: Richard Zhu [mani: commit log] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Frank Li Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260228080925.1558395-1-hongxing.zhu@nxp.com Signed-off-by: Greg Kroah-Hartman commit b6e61356ad24987be40bf25369d22dd8dd00a513 Author: Felix Gu Date: Mon Mar 23 00:04:08 2026 +0800 EDAC/versalnet: Fix device_node leak in mc_probe() commit 5c709b376460ff322580c41600e31c02f7cc0307 upstream. of_parse_phandle() returns a device_node reference that must be released with of_node_put(). The original code never freed r5_core_node on any exit path, causing a memory leak. Fix this by using the automatic cleanup attribute __free(device_node) which ensures of_node_put() is called when the variable goes out of scope. Fixes: d5fe2fec6c40 ("EDAC: Add a driver for the AMD Versal NET DDR controller") Signed-off-by: Felix Gu Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Shubhrajyoti Datta Cc: Link: https://patch.msgid.link/20260323-versalnet-v1-1-4ab3012635ef@gmail.com Signed-off-by: Greg Kroah-Hartman commit b6cb07f02253bdefd2339e57eaa1428a7b28cd0f Author: Sanman Pradhan Date: Fri Apr 10 00:25:41 2026 +0000 hwmon: (powerz) Fix missing usb_kill_urb() on signal interrupt commit b66437cb20a2d9ef201f40b675569f8ea7787c9f upstream. wait_for_completion_interruptible_timeout() returns -ERESTARTSYS when interrupted. This needs to abort the URB and return an error. No data has been received from the device so any reads from the transfer buffer are invalid. The original code tests !ret, which only catches the timeout case (0). On signal delivery (-ERESTARTSYS), !ret is false so the function skips usb_kill_urb() and falls through to read from the unfilled transfer buffer. Fix by capturing the return value into a long (matching the function return type) and handling signal (negative) and timeout (zero) cases with separate checks that both call usb_kill_urb() before returning. Fixes: 4381a36abdf1c ("hwmon: add POWER-Z driver") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan Link: https://lore.kernel.org/r/20260410002521.422645-3-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 5b6122a67a295f8a08b7c18d908a1bd974dfaec8 Author: Wentao Liang Date: Thu Apr 9 03:48:59 2026 +0000 of: unittest: fix use-after-free in testdrv_probe() commit 07fd339b2c253205794bea5d9b4b7548a4546c56 upstream. The function testdrv_probe() retrieves the device_node from the PCI device, applies an overlay, and then immediately calls of_node_put(dn). This releases the reference held by the PCI core, potentially freeing the node if the reference count drops to zero. Later, the same freed pointer 'dn' is passed to of_platform_default_populate(), leading to a use-after-free. The reference to pdev->dev.of_node is owned by the device model and should not be released by the driver. Remove the erroneous of_node_put() to prevent premature freeing. Fixes: 26409dd04589 ("of: unittest: Add pci_dt_testdrv pci driver") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260409034859.429071-1-vulab@iscas.ac.cn Signed-off-by: Rob Herring (Arm) Signed-off-by: Greg Kroah-Hartman commit 7f0f0926f3010b10cff5e93446258f971e42f2fd Author: Wentao Liang Date: Thu Apr 9 02:22:33 2026 +0000 of: unittest: fix use-after-free in of_unittest_changeset() commit faecdd423c27f0d6090156a435ba9dbbac0eaddb upstream. The variable 'parent' is assigned the value of 'nchangeset' earlier in the function, meaning both point to the same struct device_node. The call to of_node_put(nchangeset) can decrement the reference count to zero and free the node if there are no other holders. After that, the code still uses 'parent' to check for the presence of a property and to read a string property, leading to a use-after-free. Fix this by moving the of_node_put() call after the last access to 'parent', avoiding the UAF. Fixes: 1c668ea65506 ("of: unittest: Use of_property_present()") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260409022233.418103-1-vulab@iscas.ac.cn Signed-off-by: Rob Herring (Arm) Signed-off-by: Greg Kroah-Hartman commit 824897e69d7ae94f9a65790b74e8e37032e3393c Author: Swamil Jain Date: Wed Apr 15 16:34:09 2026 +0530 dt-bindings: display: ti, am65x-dss: Fix AM62L DSS reg and clock constraints commit 9c469240997584449cfac51a75d1d3d71968c76f upstream. The AM62L DSS [1] support incorrectly used the same register and clock constraints as AM65x, but AM62L has a single video port Fix this by adding conditional constraints that properly define the register regions and clocks for AM62L DSS (single video port) versus other AM65x variants (dual video port). [1]: Section 12.7 (Display Subsystem and Peripherals) Link : https://www.ti.com/lit/pdf/sprujb4 Fixes: cb8d4323302c ("dt-bindings: display: ti,am65x-dss: Add support for AM62L DSS") Cc: stable@vger.kernel.org Signed-off-by: Swamil Jain Reviewed-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20260415110409.2577633-1-s-jain1@ti.com Signed-off-by: Rob Herring (Arm) Signed-off-by: Greg Kroah-Hartman commit 77d55bc8675ee851ed639dc9be77325a8024cf67 Author: Herbert Xu Date: Thu Apr 16 17:00:50 2026 +0800 crypto: pcrypt - Fix handling of MAY_BACKLOG requests commit 915b692e6cb723aac658c25eb82c58fd81235110 upstream. MAY_BACKLOG requests can return EBUSY. Handle them by checking for that value and filtering out EINPROGRESS notifications. Reported-by: Yiming Qian Fixes: 5a1436beec57 ("crypto: pcrypt - call the complete function on error") Signed-off-by: Herbert Xu Cc: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit ebc235675f24b0e3f8bc92b8419471d42f837d8f Author: Douya Le Date: Sun Apr 19 16:52:59 2026 +0800 crypto: algif_aead - snapshot IV for async AEAD requests commit 5aa58c3a572b3e3b6c786953339f7978b845cc52 upstream. AF_ALG AEAD AIO requests currently use the socket-wide IV buffer during request processing. For async requests, later socket activity can update that shared state before the original request has fully completed, which can lead to inconsistent IV handling. Snapshot the IV into per-request storage when preparing the AEAD request, so in-flight operations no longer depend on mutable socket state. Fixes: d887c52d6ae4 ("crypto: algif_aead - overhaul memory management") Cc: stable@kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Tested-by: Yucheng Lu Signed-off-by: Douya Le Signed-off-by: Ren Wei Signed-off-by: Herbert Xu Cc: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit efc52947247a21bbf79059539bbbd40f4ea76f00 Author: Matthew Wilcox (Oracle) Date: Wed Apr 29 18:22:22 2026 +0100 mm: call ->free_folio() directly in folio_unmap_invalidate() commit 615d9bb2ccad42f9e21d837431e401db2e471195 upstream. We can only call filemap_free_folio() if we have a reference to (or hold a lock on) the mapping. Otherwise, we've already removed the folio from the mapping so it no longer pins the mapping and the mapping can be removed, causing a use-after-free when accessing mapping->a_ops. Follow the same pattern as __remove_mapping() and load the free_folio function pointer before dropping the lock on the mapping. That lets us make filemap_free_folio() static as this was the only caller outside filemap.c. Link: https://lore.kernel.org/20260413184314.3419945-1-willy@infradead.org Fixes: fb7d3bc41493 ("mm/filemap: drop streaming/uncached pages when writeback completes") Signed-off-by: Matthew Wilcox (Oracle) Reported-by: Google Big Sleep Cc: Jens Axboe Cc: Jan Kara Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit ff8a7996dc8bf433efe2126ffdaee5b374a89e30 Author: Johan Hovold Date: Fri Mar 27 11:43:04 2026 +0100 spi: ch341: fix memory leaks on probe failures commit b99e3ddb91b499d920e63a2daff8880be68cfe9e upstream. Make sure to deregister the controller, disable pins, and kill and free the RX URB on probe failures to mirror disconnect and avoid memory leaks and use-after-free. Also add an explicit URB kill on disconnect for symmetry (even if that is not strictly required as USB core would have stopped it in the current setup). Fixes: 8846739f52af ("spi: add ch341a usb2spi driver") Cc: stable@vger.kernel.org # 6.11 Cc: Johannes Thumshirn Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260327104305.1309915-2-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 132e47030b0b5e398e0da6c59df5a5dae9b52cff Author: Johan Hovold Date: Tue Mar 24 09:23:22 2026 +0100 spi: imx: fix use-after-free on unbind commit 1c78c2002380a1fe31bfb01a3d5f29809e55a096 upstream. The SPI subsystem frees the controller and any subsystem allocated driver data as part of deregistration (unless the allocation is device managed). Take another reference before deregistering the controller so that the driver data is not freed until the driver is done with it. Fixes: 307c897db762 ("spi: spi-imx: replace struct spi_imx_data::bitbang by pointer to struct spi_controller") Cc: stable@vger.kernel.org # 5.19 Acked-by: Marc Kleine-Budde Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260324082326.901043-2-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 75f8f3c3e09122270986de9d7aa347d701676761 Author: Rafael J. Wysocki Date: Tue Apr 7 15:55:19 2026 +0200 thermal: core: Fix thermal zone governor cleanup issues commit 41ff66baf81c6541f4f985dd7eac4494d03d9440 upstream. If thermal_zone_device_register_with_trips() fails after adding a thermal governor to the thermal zone being registered, the governor is not removed from it as appropriate which may lead to a memory leak. In turn, thermal_zone_device_unregister() calls thermal_set_governor() without acquiring the thermal zone lock beforehand which may race with a governor update via sysfs and may lead to a use-after-free in that case. Address these issues by adding two thermal_set_governor() calls, one to thermal_release() to remove the governor from the given thermal zone, and one to the thermal zone registration error path to cover failures preceding the thermal zone device registration. Fixes: e33df1d2f3a0 ("thermal: let governors have private data for each thermal zone") Cc: All applicable Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/5092923.31r3eYUQgx@rafael.j.wysocki Signed-off-by: Greg Kroah-Hartman commit 2810fc760aaf9d60aa2047e90e1ca5cd938062b0 Author: Michael Bommarito Date: Wed Apr 8 03:01:02 2026 -0400 um: drivers: call kernel_strrchr() explicitly in cow_user.c commit 91e901c65b4da02a6fd543e3f0049829ae9645b7 upstream. Building ARCH=um on glibc >= 2.43 fails: arch/um/drivers/cow_user.c: error: implicit declaration of function 'strrchr' [-Wimplicit-function-declaration] glibc 2.43's C23 const-preserving strrchr() macro does not survive UML's global -Dstrrchr=kernel_strrchr remap from arch/um/Makefile. Call kernel_strrchr() directly in cow_user.c so the source no longer depends on the -D rewrite. Fixes: 2c51a4bc0233 ("um: fix strrchr() problems") Suggested-by: Johannes Berg Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Assisted-by: Codex:gpt-5-4 Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260408070102.2325572-1-michael.bommarito@gmail.com [remove unnecessary 'extern'] Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 5d6c349c9823eb819fed8b537b088cf38126018c Author: Prasanna Kumar T S M Date: Fri Apr 17 14:27:56 2026 -0600 vfio/cdx: Fix NULL pointer dereference in interrupt trigger path commit 5ea5880764cbb164afb17a62e76ca75dc371409d upstream. Add validation to ensure MSI is configured before accessing cdx_irqs array in vfio_cdx_set_msi_trigger(). Without this check, userspace can trigger a NULL pointer dereference by calling VFIO_DEVICE_SET_IRQS with VFIO_IRQ_SET_DATA_BOOL or VFIO_IRQ_SET_DATA_NONE flags before ever setting up interrupts via VFIO_IRQ_SET_DATA_EVENTFD. The vfio_cdx_msi_enable() function allocates the cdx_irqs array and sets config_msi to 1 only when called through the EVENTFD path. The trigger loop (for DATA_BOOL/DATA_NONE) assumed this had already been done, but there was no enforcement of this call ordering. This matches the protection used in the PCI VFIO driver where vfio_pci_set_msi_trigger() checks irq_is() before the trigger loop. Fixes: 848e447e000c ("vfio/cdx: add interrupt support") Cc: stable@vger.kernel.org Signed-off-by: Prasanna Kumar T S M Acked-by: Nipun Gupta Signed-off-by: Alex Williamson Acked-by: Nikhil Agarwal Link: https://lore.kernel.org/r/20260417202800.88287-2-alex.williamson@nvidia.com Signed-off-by: Alex Williamson Signed-off-by: Greg Kroah-Hartman commit 7b436ade16cc81095d79b79f8efa3af0a4f5c5a2 Author: Alex Williamson Date: Fri Apr 17 14:27:57 2026 -0600 vfio/cdx: Serialize VFIO_DEVICE_SET_IRQS with a per-device mutex commit 670e8864b1a218d72f08db40d0103adf38fa1d9b upstream. vfio_cdx_set_msi_trigger() reads vdev->config_msi and operates on the vdev->cdx_irqs array based on its value, but provides no serialization against concurrent VFIO_DEVICE_SET_IRQS ioctls. Two callers can race such that one observes config_msi as set while another clears it and frees cdx_irqs via vfio_cdx_msi_disable(), resulting in a use-after-free of the cdx_irqs array. Add a cdx_irqs_lock mutex to struct vfio_cdx_device and acquire it in vfio_cdx_set_msi_trigger(), which is the single chokepoint through which all updates to config_msi, cdx_irqs, and msi_count flow, covering both the ioctl path and the close-device cleanup path. This keeps the test of config_msi atomic with the subsequent enable, disable, or trigger operations. Drop the pre-call !cdx_irqs test from vfio_cdx_irqs_cleanup() as part of this change: the optimization it provided is redundant with the !config_msi early-return inside vfio_cdx_msi_disable(), and leaving the test in place would be an unsynchronized read of state the new lock is meant to protect. Fixes: 848e447e000c ("vfio/cdx: add interrupt support") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Alex Williamson Acked-by: Nikhil Agarwal Link: https://lore.kernel.org/r/20260417202800.88287-3-alex.williamson@nvidia.com Signed-off-by: Alex Williamson Signed-off-by: Greg Kroah-Hartman commit 08da3594c8ba49da00ef4c75ff5a5f7b38fa6cfe Author: Alex Williamson Date: Tue Apr 14 14:06:19 2026 -0600 vfio/virtio: Convert list_lock from spinlock to mutex commit 903570835f12b7436ca0edb0a9ed351c0349121e upstream. The list_lock spinlock with IRQ disabling was copied from the mlx5 vfio-pci variant driver, where it is justified by a hardirq async command completion callback that accesses the protected lists. The virtio driver has no such interrupt context usage; all list_lock acquisitions occur in process context via file read/write operations or state transitions under state_mutex. Convert list_lock to a mutex to be consistent with peer vfio-pci variant drivers (hisilicon, pds, qat, xe) which all use mutexes for equivalent migration data protection. This also fixes a mismatched spin_lock()/spin_unlock_irq() pair in virtiovf_read_device_context_chunk() that could incorrectly enable interrupts. Reported-by: Jinhui Guo Closes: https://lore.kernel.org/all/20260413073603.30538-1-guojinhui.liam@bytedance.com Fixes: 0bbc82e4ec79 ("vfio/virtio: Add support for the basic live migration functionality") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Alex Williamson Reviewed-by: Yishai Hadas Link: https://lore.kernel.org/r/20260414200625.3601509-2-alex.williamson@nvidia.com Signed-off-by: Alex Williamson Signed-off-by: Greg Kroah-Hartman commit 7aa27b20e938bfd1b0035f423474b1e26bc7e9c3 Author: Manish Honap Date: Tue Mar 17 10:44:02 2026 +0530 vfio: selftests: Fix VLA initialisation in vfio_pci_irq_set() commit 4f42d716707654134789a0205a050b0d022be948 upstream. C does not permit an initialiser expression on a variable-length array (C99 Section 6.7.9 constraint: "The type of the entity to be initialized shall not be a variable length array type"). vfio_pci_irq_set() declared: u8 buf[sizeof(struct vfio_irq_set) + sizeof(int) * count] = {}; where `count` is a runtime function parameter, making `buf` a VLA. GCC rejects this with (tried with GCC-9.4.0): error: variable-sized object may not be initialized Fix by removing the `= {}` initialiser and inserting an explicit memset() immediately after the declaration. memset() on a VLA is perfectly legal and achieves the same zero-initialisation on all conforming C implementations. Fixes: 19faf6fd969c ("vfio: selftests: Add a helper library for VFIO selftests") Cc: stable@vger.kernel.org Reviewed-by: Dave Jiang Reviewed-by: David Matlack Signed-off-by: Manish Honap Link: https://lore.kernel.org/r/20260317051402.3725670-1-mhonap@nvidia.com Signed-off-by: Alex Williamson Signed-off-by: Greg Kroah-Hartman commit 4e179a60a60c0a5aea245e8e67768343c0f070b8 Author: Daniel Hodges Date: Fri Feb 6 14:44:01 2026 -0500 wifi: mwifiex: fix use-after-free in mwifiex_adapter_cleanup() commit ae5e95d4157481693be2317e3ffcd84e36010cbb upstream. The mwifiex_adapter_cleanup() function uses timer_delete() (non-synchronous) for the wakeup_timer before the adapter structure is freed. This is incorrect because timer_delete() does not wait for any running timer callback to complete. If the wakeup_timer callback (wakeup_timer_fn) is executing when mwifiex_adapter_cleanup() is called, the callback will continue to access adapter fields (adapter->hw_status, adapter->if_ops.card_reset, etc.) which may be freed by mwifiex_free_adapter() called later in the mwifiex_remove_card() path. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning. Fixes: 4636187da60b ("mwifiex: add wakeup timer based recovery mechanism") Cc: stable@vger.kernel.org Signed-off-by: Daniel Hodges Link: https://patch.msgid.link/20260206194401.2346-1-git@danielhodges.dev Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 000134a20bbf89b1152520a2eef71f91fdb83a5b Author: Fedor Pchelkin Date: Fri Feb 20 12:47:30 2026 +0300 wifi: rtw88: check for PCI upstream bridge existence commit eb101d2abdcccb514ca4fccd3b278dd8267374f6 upstream. pci_upstream_bridge() returns NULL if the device is on a root bus. If 8821CE is installed in the system with such a PCI topology, the probing routine will crash. This has probably been unnoticed as 8821CE is mostly supplied in laptops where there is a PCI-to-PCI bridge located upstream from the device. However the card might be installed on a system with different configuration. Check if the bridge does exist for the specific workaround to be applied. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool. Fixes: 24f5e38a13b5 ("rtw88: Disable PCIe ASPM while doing NAPI poll on 8821CE") Cc: stable@vger.kernel.org Signed-off-by: Fedor Pchelkin Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260220094730.49791-1-pchelkin@ispras.ru Signed-off-by: Greg Kroah-Hartman commit a02363f71a79b755daa78a70d6b217f9c13c8c85 Author: Sergey Senozhatsky Date: Tue Mar 31 16:42:44 2026 +0900 zram: do not forget to endio for partial discard requests commit e3668b371329ea036ff022ce8ecc82f8befcf003 upstream. As reported by Qu Wenruo and Avinesh Kumar, the following getconf PAGESIZE 65536 blkdiscard -p 4k /dev/zram0 takes literally forever to complete. zram doesn't support partial discards and just returns immediately w/o doing any discard work in such cases. The problem is that we forget to endio on our way out, so blkdiscard sleeps forever in submit_bio_wait(). Fix this by jumping to end_bio label, which does bio_endio(). Link: https://lore.kernel.org/20260331074255.777019-1-senozhatsky@chromium.org Fixes: 0120dd6e4e20 ("zram: make zram_bio_discard more self-contained") Signed-off-by: Sergey Senozhatsky Reported-by: Qu Wenruo Closes: https://lore.kernel.org/linux-block/92361cd3-fb8b-482e-bc89-15ff1acb9a59@suse.com Tested-by: Qu Wenruo Reported-by: Avinesh Kumar Closes: https://bugzilla.suse.com/show_bug.cgi?id=1256530 Reviewed-by: Christoph Hellwig Cc: Brian Geffon Cc: Jens Axboe Cc: Minchan Kim Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit a516d43886623e3cca5fa3446bed8fc7c7982be2 Author: Dmitry Torokhov Date: Fri Apr 10 21:13:43 2026 -0700 Input: edt-ft5x06 - fix use-after-free in debugfs teardown commit f5f9e07060519e2287e99019a6de1eb3ebb65c37 upstream. The commit 68743c500c6e ("Input: edt-ft5x06 - use per-client debugfs directory") removed the manual debugfs teardown, relying on the I2C core to handle it. However, this creates a window where debugfs files are still accessible after edt_ft5x06_ts_teardown_debugfs() frees tsdata->raw_buffer. To prevent a use-after-free, protect the freeing of raw_buffer with the device mutex and set raw_buffer to NULL. The debugfs read function already checks if raw_buffer is NULL under the same mutex, so this safely avoids the use-after-free. Fixes: 68743c500c6e ("Input: edt-ft5x06 - use per-client debugfs directory") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/adnJicDh-bTUaWXP@google.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 3c636a3edca9c3f180b3079f94fe7e115730d9c6 Author: Heming Zhao Date: Thu Apr 2 21:43:27 2026 +0800 ocfs2: split transactions in dio completion to avoid credit exhaustion commit d647c5b2fbf81560818dacade360abc8c00a9665 upstream. During ocfs2 dio operations, JBD2 may report warnings via following call trace: ocfs2_dio_end_io_write ocfs2_mark_extent_written ocfs2_change_extent_flag ocfs2_split_extent ocfs2_try_to_merge_extent ocfs2_extend_rotate_transaction ocfs2_extend_trans jbd2__journal_restart start_this_handle output: JBD2: kworker/6:2 wants too many credits credits:5450 rsv_credits:0 max:5449 To prevent exceeding the credits limit, modify ocfs2_dio_end_io_write() to handle extents in a batch of transaction. Additionally, relocate ocfs2_del_inode_from_orphan(). The orphan inode should only be removed from the orphan list after the extent tree update is complete. This ensures that if a crash occurs in the middle of extent tree updates, we won't leave stale blocks beyond EOF. This patch also changes the logic for updating the inode size and removing orphan, making it similar to ext4_dio_write_end_io(). Both operations are performed only when everything looks good. Finally, thanks to Jans and Joseph for providing the bug fix prototype and suggestions. Link: https://lkml.kernel.org/r/20260402134328.27334-2-heming.zhao@suse.com Signed-off-by: Heming Zhao Suggested-by: Jan Kara Suggested-by: Joseph Qi Reviewed-by: Jan Kara Reviewed-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: Greg Kroah-Hartman commit 944a6864aa06d8bd393272515ed0a2a629933cac Author: Usama Arif Date: Thu Mar 12 03:47:23 2026 -0700 mm: migrate: requeue destination folio on deferred split queue commit a2e0c0668a3486f96b86c50e02872c8e94fd4f9c upstream. During folio migration, __folio_migrate_mapping() removes the source folio from the deferred split queue, but the destination folio is never re-queued. This causes underutilized THPs to escape the shrinker after NUMA migration, since they silently drop off the deferred split list. Fix this by recording whether the source folio was on the deferred split queue and its partially mapped state before move_to_new_folio() unqueues it, and re-queuing the destination folio after a successful migration if it was. By the time migrate_folio_move() runs, partially mapped folios without a pin have already been split by migrate_pages_batch(). So only two cases remain on the deferred list at this point: 1. Partially mapped folios with a pin (split failed). 2. Fully mapped but potentially underused folios. The recorded partially_mapped state is forwarded to deferred_split_folio() so that the destination folio is correctly re-queued in both cases. Because THPs are removed from the deferred_list, THP shinker cannot split the underutilized THPs in time. As a result, users will show less free memory than before. Link: https://lkml.kernel.org/r/20260312104723.1351321-1-usama.arif@linux.dev Fixes: dafff3f4c850 ("mm: split underused THPs") Signed-off-by: Usama Arif Reported-by: Johannes Weiner Acked-by: Johannes Weiner Acked-by: Zi Yan Acked-by: David Hildenbrand (Arm) Acked-by: SeongJae Park Reviewed-by: Wei Yang Cc: Alistair Popple Cc: Byungchul Park Cc: Gregory Price Cc: "Huang, Ying" Cc: Joshua Hahn Cc: Matthew Brost Cc: Matthew Wilcox (Oracle) Cc: Nico Pache Cc: Rakie Kim Cc: Ying Huang Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 3f8805b8ca23023ad75fcfb54f92e6df5c383221 Author: Anshuman Khandual Date: Mon Mar 9 02:57:24 2026 +0000 arm64/mm: Enable batched TLB flush in unmap_hotplug_range() commit 48478b9f791376b4b89018d7afdfd06865498f65 upstream. During a memory hot remove operation, both linear and vmemmap mappings for the memory range being removed, get unmapped via unmap_hotplug_range() but mapped pages get freed only for vmemmap mapping. This is just a sequential operation where each table entry gets cleared, followed by a leaf specific TLB flush, and then followed by memory free operation when applicable. This approach was simple and uniform both for vmemmap and linear mappings. But linear mapping might contain CONT marked block memory where it becomes necessary to first clear out all entire in the range before a TLB flush. This is as per the architecture requirement. Hence batch all TLB flushes during the table tear down walk and finally do it in unmap_hotplug_range(). Prior to this fix, it was hypothetically possible for a speculative access to a higher address in the contiguous block to fill the TLB with shattered entries for the entire contiguous range after a lower address had already been cleared and invalidated. Due to the table entries being shattered, the subsequent TLB invalidation for the higher address would not then clear the TLB entries for the lower address, meaning stale TLB entries could persist. Besides it also helps in improving the performance via TLBI range operation along with reduced synchronization instructions. The time spent executing unmap_hotplug_range() improved 97% measured over a 2GB memory hot removal in KVM guest. This scheme is not applicable during vmemmap mapping tear down where memory needs to be freed and hence a TLB flush is required after clearing out page table entry. Cc: Will Deacon Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Closes: https://lore.kernel.org/all/aWZYXhrT6D2M-7-N@willie-the-truck/ Fixes: bbd6ec605c0f ("arm64/mm: Enable memory hot remove") Cc: stable@vger.kernel.org Reviewed-by: David Hildenbrand (Arm) Reviewed-by: Ryan Roberts Signed-off-by: Ryan Roberts Signed-off-by: Anshuman Khandual Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit ecb3e4fa31ffa90b1398668e7950a3fdd52b0fc1 Author: Thomas Zimmermann Date: Tue Feb 17 16:56:12 2026 +0100 firmware: google: framebuffer: Do not mark framebuffer as busy commit f3850d399de3b6142b02315227ef9e772ed0c302 upstream. Remove the flag IORESOURCE_BUSY flag from coreboot's framebuffer resource. It prevents simpledrm from successfully requesting the range for its own use; resulting in errors such as [ 2.775430] simple-framebuffer simple-framebuffer.0: [drm] could not acquire memory region [mem 0x80000000-0x80407fff flags 0x80000200] As with other uses of simple-framebuffer, the simple-framebuffer device should only declare it's I/O resources, but not actively use them. Signed-off-by: Thomas Zimmermann Fixes: 851b4c14532d ("firmware: coreboot: Add coreboot framebuffer driver") Acked-by: Tzung-Bi Shih Acked-by: Julius Werner Cc: Samuel Holland Cc: Greg Kroah-Hartman Cc: Tzung-Bi Shih Cc: Brian Norris Cc: Julius Werner Cc: chrome-platform@lists.linux.dev Cc: # v4.18+ Link: https://patch.msgid.link/20260217155836.96267-3-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit f51f85c044809fbd39ac8ae07ac99bc43ce32bd5 Author: Lorenzo Stoakes (Oracle) Date: Fri Mar 20 22:39:35 2026 +0000 fs: afs: revert mmap_prepare() change commit fbfc6578eaca12daa0c09df1e9ba7f2c657b49da upstream. Partially reverts commit 9d5403b1036c ("fs: convert most other generic_file_*mmap() users to .mmap_prepare()"). This is because the .mmap invocation establishes a refcount, but .mmap_prepare is called at a point where a merge or an allocation failure might happen after the call, which would leak the refcount increment. Functionality is being added to permit the use of .mmap_prepare in this case, but in the interim, we need to fix this. Link: https://lkml.kernel.org/r/08804c94e39d9102a3a8fbd12385e8aa079ba1d3.1774045440.git.ljs@kernel.org Fixes: 9d5403b1036c ("fs: convert most other generic_file_*mmap() users to .mmap_prepare()") Signed-off-by: Lorenzo Stoakes (Oracle) Acked-by: Vlastimil Babka (SUSE) Cc: Alexander Shishkin Cc: Alexandre Torgue Cc: Al Viro Cc: Arnd Bergmann Cc: Bodo Stroesser Cc: Christian Brauner Cc: Clemens Ladisch Cc: David Hildenbrand Cc: David Howells Cc: Dexuan Cui Cc: Greg Kroah-Hartman Cc: Haiyang Zhang Cc: Jan Kara Cc: Jann Horn Cc: Jonathan Corbet Cc: K. Y. Srinivasan Cc: Liam Howlett Cc: Long Li Cc: Marc Dionne Cc: "Martin K. Petersen" Cc: Maxime Coquelin Cc: Michal Hocko Cc: Mike Rapoport Cc: Miquel Raynal Cc: Pedro Falcato Cc: Richard Weinberger Cc: Ryan Roberts Cc: Suren Baghdasaryan Cc: Vignesh Raghavendra Cc: Vlastimil Babka (SUSE) Cc: Wei Liu Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit d4d0c91a0afcc021bfbc8845bc536c0de7c8bb5f Author: Miguel Ojeda Date: Tue Mar 31 22:58:48 2026 +0200 kbuild: rust: allow `clippy::uninlined_format_args` commit 10eea3c147141c90cf409b8df56d245c9d7f88d9 upstream. Clippy in Rust 1.88.0 (only) reports [1]: warning: variables can be used directly in the `format!` string --> rust/macros/module.rs:112:23 | 112 | let content = format!("{param}:{content}", param = param, content = content); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args = note: `-W clippy::uninlined-format-args` implied by `-W clippy::all` = help: to override `-W clippy::all` add `#[allow(clippy::uninlined_format_args)]` help: change this to | 112 - let content = format!("{param}:{content}", param = param, content = content); 112 + let content = format!("{param}:{content}"); warning: variables can be used directly in the `format!` string --> rust/macros/module.rs:198:14 | 198 | t => panic!("Unsupported parameter type {}", t), | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args = note: `-W clippy::uninlined-format-args` implied by `-W clippy::all` = help: to override `-W clippy::all` add `#[allow(clippy::uninlined_format_args)]` help: change this to | 198 - t => panic!("Unsupported parameter type {}", t), 198 + t => panic!("Unsupported parameter type {t}"), | The reason it only triggers in that version is that the lint was moved from `pedantic` to `style` in Rust 1.88.0 and then back to `pedantic` in Rust 1.89.0 [2][3]. In the first case, the suggestion is fair and a pure simplification, thus we will clean it up separately. To keep the behavior the same across all versions, and since the lint does not work for all macros (e.g. custom ones like `pr_info!`), disable it globally. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://lore.kernel.org/rust-for-linux/CANiq72=drAtf3y_DZ-2o4jb6Az9J3Yj4QYwWnbRui4sm4AJD3Q@mail.gmail.com/ [1] Link: https://github.com/rust-lang/rust-clippy/pull/15287 [2] Link: https://github.com/rust-lang/rust-clippy/issues/15151 [3] Link: https://patch.msgid.link/20260331205849.498295-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 5447be57b311e983366fc7b733939839441646bd Author: Danilo Krummrich Date: Sat Mar 21 18:27:46 2026 +0100 rust: dma: remove DMA_ATTR_NO_KERNEL_MAPPING from public attrs commit 18fb5f1f0289b8217c0c43d54d12bccc201dd640 upstream. When DMA_ATTR_NO_KERNEL_MAPPING is passed to dma_alloc_attrs(), the returned CPU address is not a pointer to the allocated memory but an opaque handle (e.g. struct page *). Coherent (or CoherentAllocation respectively) stores this value as NonNull and exposes methods that dereference it and even modify its contents. Remove the flag from the public attrs module such that drivers cannot pass it to Coherent (or CoherentAllocation respectively) in the first place. Instead DMA_ATTR_NO_KERNEL_MAPPING can be supported with an additional opaque type (e.g. CoherentHandle) which does not provide access to the allocated memory. Cc: stable@vger.kernel.org Fixes: ad2907b4e308 ("rust: add dma coherent allocator abstraction") Signed-off-by: Danilo Krummrich Reviewed-by: Alice Ryhl Reviewed-by: Alexandre Courbot Reviewed-by: Gary Guo Link: https://patch.msgid.link/20260321172749.592387-1-dakr@kernel.org Signed-off-by: Alexandre Courbot Signed-off-by: Greg Kroah-Hartman commit 4404d7d2dda4f3cc84a8fb6ac5417a2afc3b22d6 Author: David Carlier Date: Sat Apr 11 07:29:38 2026 +0100 drm/nouveau: fix nvkm_device leak on aperture removal failure commit 6597ff1d8de3f583be169587efeafd8af134e138 upstream. When aperture_remove_conflicting_pci_devices() fails during probe, the error path returns directly without unwinding the nvkm_device that was just allocated by nvkm_device_pci_new(). This leaks both the device wrapper and the pci_enable_device() reference taken inside it. Jump to the existing fail_nvkm label so nvkm_device_del() runs and balances both. The leak was introduced when the intermediate nvkm_device_del() between detection and aperture removal was dropped in favor of creating the pci device once. Fixes: c0bfe34330b5 ("drm/nouveau: create pci device once") Cc: stable@vger.kernel.org Signed-off-by: David Carlier Link: https://patch.msgid.link/20260411062938.22925-1-devnexen@gmail.com Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit fa9a4c5e69aaae47df95328fa96b3f2931e3180a Author: Douglas Anderson Date: Tue Mar 17 09:01:20 2026 -0700 device property: Make modifications of fwnode "flags" thread safe commit f72e77c33e4b5657af35125e75bab249256030f3 upstream. In various places in the kernel, we modify the fwnode "flags" member by doing either: fwnode->flags |= SOME_FLAG; fwnode->flags &= ~SOME_FLAG; This type of modification is not thread-safe. If two threads are both mucking with the flags at the same time then one can clobber the other. While flags are often modified while under the "fwnode_link_lock", this is not universally true. Create some accessor functions for setting, clearing, and testing the FWNODE flags and move all users to these accessor functions. New accessor functions use set_bit() and clear_bit(), which are thread-safe. Cc: stable@vger.kernel.org Fixes: c2c724c868c4 ("driver core: Add fw_devlink_parse_fwtree()") Reviewed-by: Andy Shevchenko Acked-by: Mark Brown Reviewed-by: Wolfram Sang Signed-off-by: Douglas Anderson Reviewed-by: Rafael J. Wysocki (Intel) Reviewed-by: Saravana Kannan Link: https://patch.msgid.link/20260317090112.v2.1.I0a4d03104ecd5103df3d76f66c8d21b1d15a2e38@changeid [ Fix fwnode_clear_flag() argument alignment, restore dropped blank line in fwnode_dev_initialized(), and remove unnecessary parentheses around fwnode_test_flag() calls. - Danilo ] Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 3e8fefd2997c85e98de81f35380616c0a51430a4 Author: Douglas Anderson Date: Mon Apr 6 16:22:54 2026 -0700 driver core: Don't let a device probe until it's ready commit a2225b6e834a838ae3c93709760edc0a169eb2f2 upstream. The moment we link a "struct device" into the list of devices for the bus, it's possible probe can happen. This is because another thread can load the driver at any time and that can cause the device to probe. This has been seen in practice with a stack crawl that looks like this [1]: really_probe() __driver_probe_device() driver_probe_device() __driver_attach() bus_for_each_dev() driver_attach() bus_add_driver() driver_register() __platform_driver_register() init_module() [some module] do_one_initcall() do_init_module() load_module() __arm64_sys_finit_module() invoke_syscall() As a result of the above, it was seen that device_links_driver_bound() could be called for the device before "dev->fwnode->dev" was assigned. This prevented __fw_devlink_pickup_dangling_consumers() from being called which meant that other devices waiting on our driver's sub-nodes were stuck deferring forever. It's believed that this problem is showing up suddenly for two reasons: 1. Android has recently (last ~1 year) implemented an optimization to the order it loads modules [2]. When devices opt-in to this faster loading, modules are loaded one-after-the-other very quickly. This is unlike how other distributions do it. The reproduction of this problem has only been seen on devices that opt-in to Android's "parallel module loading". 2. Android devices typically opt-in to fw_devlink, and the most noticeable issue is the NULL "dev->fwnode->dev" in device_links_driver_bound(). fw_devlink is somewhat new code and also not in use by all Linux devices. Even though the specific symptom where "dev->fwnode->dev" wasn't assigned could be fixed by moving that assignment higher in device_add(), other parts of device_add() (like the call to device_pm_add()) are also important to run before probe. Only moving the "dev->fwnode->dev" assignment would likely fix the current symptoms but lead to difficult-to-debug problems in the future. Fix the problem by preventing probe until device_add() has run far enough that the device is ready to probe. If somehow we end up trying to probe before we're allowed, __driver_probe_device() will return -EPROBE_DEFER which will make certain the device is noticed. In the race condition that was seen with Android's faster module loading, we will temporarily add the device to the deferred list and then take it off immediately when device_add() probes the device. Instead of adding another flag to the bitfields already in "struct device", instead add a new "flags" field and use that. This allows us to freely change the bit from different thread without worrying about corrupting nearby bits (and means threads changing other bit won't corrupt us). [1] Captured on a machine running a downstream 6.6 kernel [2] https://cs.android.com/android/platform/superproject/main/+/main:system/core/libmodprobe/libmodprobe.cpp?q=LoadModulesParallel Cc: stable@vger.kernel.org Fixes: 2023c610dc54 ("Driver core: add new device to bus's list before probing") Reviewed-by: Alan Stern Reviewed-by: Rafael J. Wysocki (Intel) Reviewed-by: Danilo Krummrich Acked-by: Greg Kroah-Hartman Acked-by: Marek Szyprowski Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20260406162231.v5.1.Id750b0fbcc94f23ed04b7aecabcead688d0d8c17@changeid Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit c1c2417c60dbdca5ebb00462f21ee71c2d7f7083 Author: Tyllis Xu Date: Sat Mar 14 11:58:05 2026 -0500 ibmasm: fix heap over-read in ibmasm_send_i2o_message() commit 9aad71144fa3682cca3837a06c8623016790e7ec upstream. The ibmasm_send_i2o_message() function uses get_dot_command_size() to compute the byte count for memcpy_toio(), but this value is derived from user-controlled fields in the dot_command_header (command_size: u8, data_size: u16) and is never validated against the actual allocation size. A root user can write a small buffer with inflated header fields, causing memcpy_toio() to read up to ~65 KB past the end of the allocation into adjacent kernel heap, which is then forwarded to the service processor over MMIO. Silently clamping the copy size is not sufficient: if the header fields claim a larger size than the buffer, the SP receives a dot command whose own header is inconsistent with the I2O message length, which can cause the SP to desynchronize. Reject such commands outright by returning failure. Validate command_size before calling get_mfa_inbound() to avoid leaking an I2O message frame: reading INBOUND_QUEUE_PORT dequeues a hardware frame from the controller's free pool, and returning without a corresponding set_mfa_inbound() call would permanently exhaust it. Additionally, clamp command_size to I2O_COMMAND_SIZE before the memcpy_toio() so the MMIO write stays within the I2O message frame, consistent with the clamping already performed by outgoing_message_size() for the header field. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Tyllis Xu Link: https://patch.msgid.link/20260314165805.548293-1-LivelyCarpet87@gmail.com Signed-off-by: Greg Kroah-Hartman commit ee5737891464030a189837467df3b81a273718ad Author: Tyllis Xu Date: Sat Mar 14 11:53:54 2026 -0500 ibmasm: fix OOB reads in command_file_write due to missing size checks commit 0eb09f737428e482a32a2e31e5e223f2b35a71d3 upstream. The command_file_write() handler allocates a kernel buffer of exactly count bytes and copies user data into it, but does not validate the buffer against the dot command protocol before passing it to get_dot_command_size() and get_dot_command_timeout(). Since both the allocation size (count) and the header fields (command_size, data_size) are independently user-controlled, an attacker can cause get_dot_command_size() to return a value exceeding the allocation, triggering OOB reads in get_dot_command_timeout() and an out-of-bounds memcpy_toio() that leaks kernel heap memory to the service processor. Fix with two guards: reject writes smaller than sizeof(struct dot_command_header) before allocation, then after copying user data reject commands where the buffer is smaller than the total size declared by the header (sizeof(header) + command_size + data_size). This ensures all subsequent header and payload field accesses stay within the buffer. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Tyllis Xu Link: https://patch.msgid.link/20260314165355.548119-1-LivelyCarpet87@gmail.com Signed-off-by: Greg Kroah-Hartman commit 22a16d3eafee92a165c756081587c95850127107 Author: Tyllis Xu Date: Sun Mar 8 00:21:08 2026 -0600 misc: ibmasm: fix OOB MMIO read in ibmasm_handle_mouse_interrupt() commit 4b6e6ead556734bdc14024c5f837132b1e7a4b84 upstream. ibmasm_handle_mouse_interrupt() performs an out-of-bounds MMIO read when the queue reader or writer index from hardware exceeds REMOTE_QUEUE_SIZE (60). A compromised service processor can trigger this by writing an out-of-range value to the reader or writer MMIO register before asserting an interrupt. Since writer is re-read from hardware on every loop iteration, it can also be set to an out-of-range value after the loop has already started. The root cause is that get_queue_reader() and get_queue_writer() return raw readl() values that are passed directly into get_queue_entry(), which computes: queue_begin + reader * sizeof(struct remote_input) with no bounds check. This unchecked MMIO address is then passed to memcpy_fromio(), reading 8 bytes from unintended device registers. For sufficiently large values the address falls outside the PCI BAR mapping entirely, triggering a machine check exception. Fix by checking both indices against REMOTE_QUEUE_SIZE at the top of the loop body, before any call to get_queue_entry(). On an out-of-range value, reset the reader register to 0 via set_queue_reader() before breaking, so that normal queue operation can resume if the corrupted hardware state is transient. Reported-by: Yuhao Jiang Fixes: 278d72ae8803 ("[PATCH] ibmasm driver: redesign handling of remote control events") Cc: stable@vger.kernel.org Cc: ychen@northwestern.edu Signed-off-by: Tyllis Xu Link: https://patch.msgid.link/20260308062108.258940-1-LivelyCarpet87@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit b2801647c203a38e013802e9e9616b5bfac64968 Author: Weigang He Date: Mon Mar 30 12:08:00 2026 +0000 greybus: gb-beagleplay: fix sleep in atomic context in hdlc_tx_frames() commit 6b526dca0966f2370835765019a54319b78fca8d upstream. hdlc_append() calls usleep_range() to wait for circular buffer space, but it is called with tx_producer_lock (a spinlock) held via hdlc_tx_frames() -> hdlc_append_tx_frame()/hdlc_append_tx_u8()/etc. Sleeping while holding a spinlock is illegal and can trigger "BUG: scheduling while atomic". Fix this by moving the buffer-space wait out of hdlc_append() and into hdlc_tx_frames(), before the spinlock is acquired. The new flow: 1. Pre-calculate the worst-case encoded frame length. 2. Wait (with sleep) outside the lock until enough space is available, kicking the TX consumer work to drain the buffer. 3. Acquire the spinlock, re-verify space, and write the entire frame atomically. This ensures that sleeping only happens without any lock held, and that frames are either fully enqueued or not written at all. This bug is found by CodeQL static analysis tool (interprocedural sleep-in-atomic query) and my code review. Fixes: ec558bbfea67 ("greybus: Add BeaglePlay Linux Driver") Cc: stable Cc: Ayush Singh Cc: Johan Hovold Cc: Alex Elder Cc: Greg Kroah-Hartman Signed-off-by: Weigang He Link: https://patch.msgid.link/20260330120801.981506-1-geoffreyhe2@gmail.com Signed-off-by: Greg Kroah-Hartman commit fb91d4e49fcbea0b5091394ac5b8f7d4124265c3 Author: Pengpeng Hou Date: Thu Apr 2 13:40:16 2026 +0800 greybus: gb-beagleplay: bound bootloader receive buffering commit 1214bf28965ceaf584fb20d357731264dd2e10e1 upstream. cc1352_bootloader_rx() appends each serdev chunk into the fixed rx_buffer before parsing bootloader packets. The helper can keep leftover bytes between callbacks and may receive multiple packets in one callback, so a single count value is not constrained by one packet length. Check that the incoming chunk fits in the remaining receive buffer space before memcpy(). If it does not, drop the staged data and consume the bytes instead of overflowing rx_buffer. Fixes: 0cf7befa3ea2 ("greybus: gb-beagleplay: Add firmware upload API") Cc: stable Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260402054016.38587-1-pengpeng@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit 438e357b3cc6cd6900df271e4bc567bfe1142281 Author: Greg Kroah-Hartman Date: Thu Feb 19 15:34:35 2026 +0100 leds: qcom-lpg: Check for array overflow when selecting the high resolution commit d45963a93c1495e9f1338fde91d0ebba8fd22474 upstream. When selecting the high resolution values from the array, FIELD_GET() is used to pull from a 3 bit register, yet the array being indexed has only 5 values in it. Odds are the hardware is sane, but just to be safe, properly check before just overflowing and reading random data and then setting up chip values based on that. Cc: stable Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2026021934-nearby-playroom-036b@gregkh Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 332884f5eb79dd60a7162b079d09d39208567a31 Author: Greg Kroah-Hartman Date: Mon Apr 20 21:16:09 2026 +0200 drm/nouveau: fix u32 overflow in pushbuf reloc bounds check commit 2fc87d37be1b730a149b035f9375fdb8cc5333a5 upstream. nouveau_gem_pushbuf_reloc_apply() validates each relocation with if (r->reloc_bo_offset + 4 > nvbo->bo.base.size) but reloc_bo_offset is __u32 (uapi/drm/nouveau_drm.h) and the integer literal 4 promotes to unsigned int, so the addition is performed in 32 bits and wraps before the comparison against the size_t bo size. Cast to u64 so the addition happens in 64-bit arithmetic. Cc: Lyude Paul Cc: Danilo Krummrich Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Simona Vetter Reported-by: Anthropic Cc: stable Assisted-by: gkh_clanker_t1000 Fixes: a1606a9596e5 ("drm/nouveau: new gem pushbuf interface, bump to 0.0.16") Signed-off-by: Greg Kroah-Hartman [ Add Fixes: tag. - Danilo ] Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 85cbf7fb568af5358aae61925c4e66b8f5e1439d Author: Greg Kroah-Hartman Date: Wed Apr 22 15:45:12 2026 +0800 LoongArch: Add spectre boundry for syscall dispatch table commit 0c965d2784fbbd7f8e3b96d875c9cfdf7c00da3d upstream. The LoongArch syscall number is directly controlled by userspace, but does not have a array_index_nospec() boundry to prevent access past the syscall function pointer tables. Cc: stable@vger.kernel.org Assisted-by: gkh_clanker_2000 Signed-off-by: Greg Kroah-Hartman Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit c578b48b9fdf4d048ee083e1eb6720de426001fc Author: Takashi Iwai Date: Fri Apr 10 16:32:19 2026 +0200 ALSA: usb-audio: Evaluate packsize caps at the right place commit 52521e8398839105ef8eb22b3f0993f9b0d11a57 upstream. We introduced the upper bound checks of the packet sizes by the ep->maxframesize for avoiding the URB submission errors. However, the check was applied at an incorrect place in the function snd_usb_endpoint_set_params() where ep->maxframesize isn't defined yet; the value is defined at a bit later position. So this ended up with a failure at the first run while the second run works. For fixing it, move the check at the correct place, right after the calculation of ep->maxframesize in the same function. Fixes: 7fe8dec3f628 ("ALSA: usb-audio: Cap the packet size pre-calculations") Link: https://bugzilla.kernel.org/show_bug.cgi?id=221292 Cc: Link: https://patch.msgid.link/20260410143220.1676344-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b216de91c0c048b2b451923889a3f0c8cd3416bb Author: Xu Yang Date: Thu Apr 2 15:14:56 2026 +0800 usb: chipidea: core: allow ci_irq_handler() handle both ID and VBUS change commit b94b631d9f78e653855f7fb58dbcb86c2a856f6f upstream. For USB role switch-triggered IRQ, ID and VBUS change come together, for example when switching from host to device mode. ID indicate a role switch and VBUS is required to determine whether the device controller can start operating. Currently, ci_irq_handler() handles only a single event per invocation. This can cause an issue where switching to device mode results in the device controller not working at all. Allowing ci_irq_handler() to handle both ID and VBUS change in one call resolves this issue. Meanwhile, this change also affects the VBUS event handling logic. Previously, if an ID event indicated host mode the VBUS IRQ will be ignored as the device disable BSE when stop() is called. With the new behavior, if ID and VBUS IRQ occur together and the target mode is host, the VBUS event is queued and ci_handle_vbus_change() will call usb_gadget_vbus_connect(), after which USBMODE is switched to device mode, causing host mode to stop working. To prevent this, an additional check is added to skip handling VBUS event when current role is not device mode. Suggested-by: Peter Chen Fixes: e1b5d2bed67c ("usb: chipidea: core: handle usb role switch in a common way") Cc: stable@vger.kernel.org Signed-off-by: Xu Yang Link: https://patch.msgid.link/20260402071457.2516021-2-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman commit 6f480aa64d4db89639b5e0cd38ffd6d013b3d76b Author: Xu Yang Date: Thu Apr 2 15:14:57 2026 +0800 usb: chipidea: otg: not wait vbus drop if use role_switch commit a4e99587102a83ee911c670752fbca694c7e557f upstream. The usb role switch will update ID and VBUS states at the same time, and vbus will not drop when execute data role swap in Type-C usecase. So lets not wait vbus drop in usb role switch case too. Fixes: e1b5d2bed67c ("usb: chipidea: core: handle usb role switch in a common way") Cc: stable@vger.kernel.org Acked-by: Peter Chen Reviewed-by: Jun Li Signed-off-by: Xu Yang Link: https://patch.msgid.link/20260402071457.2516021-3-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman commit 49340680d41fd540c1e67b98cf4d5310c7d6a35d Author: Michal Pecio Date: Thu Apr 2 16:13:42 2026 +0300 usb: xhci: Make usb_host_endpoint.hcpriv survive endpoint_disable() commit 25e531b422dc2ac90cdae3b6e74b5cdeb081440d upstream. xHCI hardware maintains its endpoint state between add_endpoint() and drop_endpoint() calls followed by successful check_bandwidth(). So does the driver. Core may call endpoint_disable() during xHCI endpoint life, so don't clear host_ep->hcpriv then, because this breaks endpoint_reset(). If a driver calls usb_set_interface(), submits URBs which make host sequence state non-zero and calls usb_clear_halt(), the device clears its sequence state but xhci_endpoint_reset() bails out. The next URB malfunctions: USB2 loses one packet, USB3 gets Transaction Error or may not complete at all on some (buggy?) HCs from ASMedia and AMD. This is triggered by uvcvideo on bulk video devices. The code was copied from ehci_endpoint_disable() but it isn't needed here - hcpriv should only be NULL on emulated root hub endpoints. It might prevent resetting and inadvertently enabling a disabled and dropped endpoint, but core shouldn't try to reset dropped endpoints. Document xhci requirements regarding hcpriv. They are currently met. Fixes: 18b74067ac78 ("xhci: Fix use-after-free regression in xhci clear hub TT implementation") Cc: stable@vger.kernel.org Signed-off-by: Michal Pecio Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20260402131342.2628648-26-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit f28a8281792b0ec47e85aabe36543369e0823de7 Author: Cássio Gabriel Date: Tue Apr 21 22:07:41 2026 -0300 ALSA: usb-audio: Fix Audio Advantage Micro II SPDIF switch commit a9224f26b754b5034719248891ff3c2ea0d11144 upstream. snd_microii_spdif_switch_put() returns 0 when the requested vendor register value differs from the cached one. This comparison was inverted by the resume-support conversion, so real SPDIF switch toggles are ignored while no-op writes still issue SET_CUR and report success. Return early only when the requested value matches the cached one. Fixes: 288673beae6c ("ALSA: usb-audio: Add resume support for MicroII SPDIF ctls") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260421-microii-spdif-switch-fix-v1-1-5c50dc28b88f@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9bbbbbd404d30df74076010a60e165b56e3e7f6d Author: Cássio Gabriel Date: Tue Apr 21 21:53:52 2026 -0300 ALSA: usb-audio: Avoid false E-MU sample-rate notifications commit fca9c850042a7ab4828ce3a9caa8bc40ea09856a upstream. snd_emuusb_set_samplerate() unconditionally notifies the E-MU SampleRate Extension Unit control after issuing SET_CUR. If snd_usb_mixer_set_ctl_value() fails, the control value has not changed, yet snd_usb_mixer_notify_id() still invalidates the cache and emits a value-change event to userspace. Notify the control only after a successful write. Fixes: 7d2b451e65d2 ("ALSA: usb-audio - Added functionality for E-mu 0404USB/0202USB/TrackerPre") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260421-alsa-emuusb-samplerate-notify-v1-1-8b63bbc1d7f1@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4d7893a137eadb6163ea4298bf67d74b811d76ef Author: Cássio Gabriel Date: Wed Apr 15 12:04:53 2026 -0300 ALSA: usb-audio: stop parsing UAC2 rates at MAX_NR_RATES commit 3c318f97dcc50b2e0556a1813bd6958678e881fd upstream. parse_uac2_sample_rate_range() caps the number of enumerated rates at MAX_NR_RATES, but it only breaks out of the current rate loop. A malformed UAC2 RANGE response with additional triplets continues parsing the remaining triplets and repeatedly prints "invalid uac2 rates" while probe still holds register_mutex. Stop the whole parse once the cap is reached and return the number of rates collected so far. Fixes: 4fa0e81b8350 ("ALSA: usb-audio: fix possible hang and overflow in parse_uac2_sample_rate_range()") Cc: stable@vger.kernel.org Reported-by: syzbot+d56178c27a4710960820@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d56178c27a4710960820 Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260415-usb-audio-uac2-rate-cap-v1-1-5ecbafc120d8@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1fe06068166d4fc16722201f267b1fe19efad639 Author: Greg Kroah-Hartman Date: Thu Apr 30 11:13:53 2026 +0200 Linux 6.18.26 Signed-off-by: Greg Kroah-Hartman commit d5f59216650c51e5e3fcb7517c825bc8047f60ef Author: Juergen Gross Date: Fri Mar 27 14:13:38 2026 +0100 Buffer overflow in drivers/xen/sys-hypervisor.c commit 27fdbab4221b375de54bf91919798d88520c6e28 upstream. The build id returned by HYPERVISOR_xen_version(XENVER_build_id) is neither NUL terminated nor a string. The first causes a buffer overflow as sprintf in buildid_show will read and copy till it finds a NUL. 00000000 f4 91 51 f4 dd 38 9e 9d 65 47 52 eb 10 71 db 50 |..Q..8..eGR..q.P| 00000010 b9 a8 01 42 6f 2e 32 |...Bo.2| 00000017 So use a memcpy instead of sprintf to have the correct value: 00000000 f4 91 51 f4 dd 00 9e 9d 65 47 52 eb 10 71 db 50 |..Q.....eGR..q.P| 00000010 b9 a8 01 42 |...B| 00000014 (the above have a hack to embed a zero inside and check it's returned correctly). This is XSA-485 / CVE-2026-31786 Fixes: 84b7625728ea ("xen: add sysfs node for hypervisor build id") Signed-off-by: Frediano Ziglio Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 446ee446d9ae66f36e95c3c90bbcc4e56b94cde0 Author: Juergen Gross Date: Fri Apr 10 09:20:04 2026 +0200 xen/privcmd: fix double free via VMA splitting commit 24daca4fc07f3ff8cd0e3f629cd982187f48436a upstream. privcmd_vm_ops defines .close (privcmd_close), but neither .may_split nor .open. When userspace does a partial munmap() on a privcmd mapping, the kernel splits the VMA via __split_vma(). Since may_split is NULL, the split is allowed. vm_area_dup() copies vm_private_data (a pages array allocated in alloc_empty_pages()) into the new VMA without any fixup, because there is no .open callback. Both VMAs now point to the same pages array. When the unmapped portion is closed, privcmd_close() calls: - xen_unmap_domain_gfn_range() - xen_free_unpopulated_pages() - kvfree(pages) The surviving VMA still holds the dangling pointer. When it is later destroyed, the same sequence runs again, which leads to a double free. Fix this issue by adding a .may_split callback denying the VMA split. This is XSA-487 / CVE-2026-31787 Fixes: d71f513985c2 ("xen: privcmd: support autotranslated physmap guests.") Reported-by: Atharva Vartak Suggested-by: Atharva Vartak Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Greg Kroah-Hartman commit 00ac7cb3bb2a98a617859c4c4fc1baf50e34a9e3 Author: Alexandre Frade Date: Mon Apr 27 23:11:51 2026 +0000 Linux 6.18.25-rt-xanmod1 Signed-off-by: Alexandre Frade commit 41926056cec4eb5930441ce30be4a720a625d07e Merge: 6e9f8d2b9557 b7e7f36157eb Author: Alexandre Frade Date: Mon Apr 27 23:10:48 2026 +0000 Merge branch '6.18' into 6.18-rt commit b7e7f36157ebffb84c0a8c0b774914eb8055afc8 Author: Alexandre Frade Date: Mon Apr 27 22:59:26 2026 +0000 Linux 6.18.25-xanmod1 Signed-off-by: Alexandre Frade commit 3dac54db8c6c50aa852a179d6b214ea69c12cba9 Merge: 4e28c6d769e4 a256b1e6892e Author: Alexandre Frade Date: Mon Apr 27 22:56:57 2026 +0000 Merge tag 'v6.18.25' into 6.18 This is the 6.18.25 stable release commit a256b1e6892e7fe840f0f9746316fa938e9a421f Author: Greg Kroah-Hartman Date: Mon Apr 27 07:27:31 2026 -0600 Linux 6.18.25 Link: https://lore.kernel.org/r/20260424132430.006424517@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Florian Fainelli Tested-by: Peter Schneider Tested-by: Mark Brown Tested-by: Shuah Khan Tested-by: Brett A C Sheffield Tested-by: Miguel Ojeda Tested-by: Wentao Guan Tested-by: Dileep Malepu Tested-by: Barry K. Nathan Signed-off-by: Greg Kroah-Hartman commit ce383ba615339f8eaec646a166d2c2b015bb5ca0 Author: Anderson Nascimento Date: Wed Apr 22 17:14:35 2026 +0100 rxrpc: Fix missing validation of ticket length in non-XDR key preparsing commit ac33733b10b484d666f97688561670afd5861383 upstream. In rxrpc_preparse(), there are two paths for parsing key payloads: the XDR path (for large payloads) and the non-XDR path (for payloads <= 28 bytes). While the XDR path (rxrpc_preparse_xdr_rxkad()) correctly validates the ticket length against AFSTOKEN_RK_TIX_MAX, the non-XDR path fails to do so. This allows an unprivileged user to provide a very large ticket length. When this key is later read via rxrpc_read(), the total token size (toksize) calculation results in a value that exceeds AFSTOKEN_LENGTH_MAX, triggering a WARN_ON(). [ 2001.302904] WARNING: CPU: 2 PID: 2108 at net/rxrpc/key.c:778 rxrpc_read+0x109/0x5c0 [rxrpc] Fix this by adding a check in the non-XDR parsing path of rxrpc_preparse() to ensure the ticket length does not exceed AFSTOKEN_RK_TIX_MAX, bringing it into parity with the XDR parsing logic. Fixes: 8a7a3eb4ddbe ("KEYS: RxRPC: Use key preparsing") Fixes: 84924aac08a4 ("rxrpc: Fix checker warning") Reported-by: Anderson Nascimento Signed-off-by: Anderson Nascimento 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/20260422161438.2593376-7-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2937f17bbeefb8e7608ff1f78cffbeb3d0281e5e Author: Sean Christopherson Date: Fri Mar 13 10:57:31 2026 -0700 crypto: ccp: Don't attempt to copy ID to userspace if PSP command failed commit 4f685dbfa87c546e51d9dc6cab379d20f275e114 upstream. When retrieving the ID for the CPU, don't attempt to copy the ID blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 64 at addr ffff8881867f5960 by task syz.0.906/24388 CPU: 130 UID: 0 PID: 24388 Comm: syz.0.906 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_get_id2+0x361/0x490 ../drivers/crypto/ccp/sev-dev.c:2222 sev_ioctl+0x25f/0x490 ../drivers/crypto/ccp/sev-dev.c:2575 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error. Reported-by: Alexander Potapenko Reported-by: Sebastian Alba Vives Fixes: d6112ea0cb34 ("crypto: ccp - introduce SEV_GET_ID2 command") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 051e51aa55fd4cdc3e8283cf4476aeeb5f563274 Author: Sean Christopherson Date: Fri Mar 13 10:48:53 2026 -0700 crypto: ccp: Don't attempt to copy PDH cert to userspace if PSP command failed commit e76239fed3cffd6d304d8ca3ce23984fd24f57d3 upstream. When retrieving the PDH cert, don't attempt to copy the blobs to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff8885c4ab8aa0 by task syz.0.186/21033 CPU: 51 UID: 0 PID: 21033 Comm: syz.0.186 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.84.12-0 11/17/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pdh_export+0x3d3/0x7c0 ../drivers/crypto/ccp/sev-dev.c:2347 sev_ioctl+0x2a2/0x490 ../drivers/crypto/ccp/sev-dev.c:2568 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error. Reported-by: Alexander Potapenko Reported-by: Sebastian Alba Vives Fixes: 76a2b524a4b1 ("crypto: ccp: Implement SEV_PDH_CERT_EXPORT ioctl command") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 111dcc6d0f016076745824a787d25609d0022f4c Author: Sean Christopherson Date: Fri Mar 13 10:43:16 2026 -0700 crypto: ccp: Don't attempt to copy CSR to userspace if PSP command failed commit abe4a6d6f606113251868c2c4a06ba904bb41eed upstream. When retrieving the PEK CSR, don't attempt to copy the blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff898144612e20 by task syz.9.219/21405 CPU: 14 UID: 0 PID: 21405 Comm: syz.9.219 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pek_csr+0x31f/0x590 ../drivers/crypto/ccp/sev-dev.c:1872 sev_ioctl+0x3a4/0x490 ../drivers/crypto/ccp/sev-dev.c:2562 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error. Reported-by: Alexander Potapenko Reported-by: Sebastian Alba Vives Fixes: e799035609e1 ("crypto: ccp: Implement SEV_PEK_CSR ioctl command") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 28324a3b62d9ce7f9bdd65a8ce63f382041d1b27 Author: Bingquan Chen Date: Sat Apr 18 19:20:06 2026 +0800 net/packet: fix TOCTOU race on mmap'd vnet_hdr in tpacket_snd() commit 2c054e17d9d41f1020376806c7f750834ced4dc5 upstream. In tpacket_snd(), when PACKET_VNET_HDR is enabled, vnet_hdr points directly into the mmap'd TX ring buffer shared with userspace. The kernel validates the header via __packet_snd_vnet_parse() but then re-reads all fields later in virtio_net_hdr_to_skb(). A concurrent userspace thread can modify the vnet_hdr fields between validation and use, bypassing all safety checks. The non-TPACKET path (packet_snd()) already correctly copies vnet_hdr to a stack-local variable. All other vnet_hdr consumers in the kernel (tun.c, tap.c, virtio_net.c) also use stack copies. The TPACKET TX path is the only caller of virtio_net_hdr_to_skb() that reads directly from user-controlled shared memory. Fix this by copying vnet_hdr from the mmap'd ring buffer to a stack-local variable before validation and use, consistent with the approach used in packet_snd() and all other callers. Fixes: 1d036d25e560 ("packet: tpacket_snd gso and checksum offload") Signed-off-by: Bingquan Chen Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260418112006.78823-1-patzilla007@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6473ed16df1fe88051140611b3eb9a49be7f429e Author: Berk Cem Goksel Date: Mon Apr 13 06:49:41 2026 +0300 ALSA: caiaq: take a reference on the USB device in create_card() commit 80bb50e2d459213cccff3111d5ef98ed4238c0d5 upstream. The caiaq driver stores a pointer to the parent USB device in cdev->chip.dev but never takes a reference on it. The card's private_free callback, snd_usb_caiaq_card_free(), can run asynchronously via snd_card_free_when_closed() after the USB device has already been disconnected and freed, so any access to cdev->chip.dev in that path dereferences a freed usb_device. On top of the refcounting issue, the current card_free implementation calls usb_reset_device(cdev->chip.dev). A reset in a free callback is inappropriate: the device is going away, the call takes the device lock in a teardown context, and the reset races with the disconnect path that the callback is already cleaning up after. Take a reference on the USB device in create_card() with usb_get_dev(), drop it with usb_put_dev() in the free callback, and remove the usb_reset_device() call. Fixes: b04dcbb7f7b1 ("ALSA: caiaq: Use snd_card_free_when_closed() at disconnection") Cc: stable@vger.kernel.org Cc: Andrey Konovalov Signed-off-by: Berk Cem Goksel Link: https://patch.msgid.link/20260413034941.1131465-3-berkcgoksel@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f8397fc0ff9a423092a3731814c641e7d79ed325 Author: Eric Naim Date: Mon Apr 13 23:48:17 2026 +0800 ALSA: hda/realtek: Add quirk for Legion S7 15IMH commit 67f4c61a73e9b17dc9593bf27badc6785ecadd78 upstream. Fix speaker output on the Lenovo Legion S7 15IMH05. Cc: stable@vger.kernel.org Signed-off-by: Eric Naim Link: https://patch.msgid.link/20260413154818.351597-1-dnaim@cachyos.org Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1d30e8d4a07c161914cd0f6de4e2968d198869be Author: Cryolitia PukNgae Date: Thu Apr 2 13:36:57 2026 +0800 ALSA: usb-audio: apply quirk for MOONDROP JU Jiu commit 4513d3e0bbc0585b86ccf2631902593ff97e88f5 upstream. It(ID 31b2:0111 JU Jiu) reports a MIN value -12800 for volume control, but will mute when setting it less than -10880. Thanks to my girlfriend Kagura for reporting this issue. Cc: Kagura Cc: stable@vger.kernel.org Signed-off-by: Cryolitia PukNgae Link: https://patch.msgid.link/20260402-syy-v1-1-068d3bc30ddc@linux.dev Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c76cf339b87975ae5b2c06d2d774d5667d25a12a Author: George Saad Date: Mon Mar 23 11:21:23 2026 +0000 f2fs: fix use-after-free of sbi in f2fs_compress_write_end_io() commit 39d4ee19c1e7d753dd655aebee632271b171f43a upstream. In f2fs_compress_write_end_io(), dec_page_count(sbi, type) can bring the F2FS_WB_CP_DATA counter to zero, unblocking f2fs_wait_on_all_pages() in f2fs_put_super() on a concurrent unmount CPU. The unmount path then proceeds to call f2fs_destroy_page_array_cache(sbi), which destroys sbi->page_array_slab via kmem_cache_destroy(), and eventually kfree(sbi). Meanwhile, the bio completion callback is still executing: when it reaches page_array_free(sbi, ...), it dereferences sbi->page_array_slab — a destroyed slab cache — to call kmem_cache_free(), causing a use-after-free. This is the same class of bug as CVE-2026-23234 (which fixed the equivalent race in f2fs_write_end_io() in data.c), but in the compressed writeback completion path that was not covered by that fix. Fix this by moving dec_page_count() to after page_array_free(), so that all sbi accesses complete before the counter decrement that can unblock unmount. For non-last folios (where atomic_dec_return on cic->pending_pages is nonzero), dec_page_count is called immediately before returning — page_array_free is not reached on this path, so there is no post-decrement sbi access. For the last folio, page_array_free runs while the F2FS_WB_CP_DATA counter is still nonzero (this folio has not yet decremented it), keeping sbi alive, and dec_page_count runs as the final operation. Fixes: 4c8ff7095bef ("f2fs: support data compression") Cc: stable@vger.kernel.org Signed-off-by: George Saad Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 028103656b84273c73e9e271cf95c9f3421f4b8a Author: Jan Kara Date: Mon Apr 13 11:36:19 2026 +0200 writeback: Fix use after free in inode_switch_wbs_work_fn() commit 6689f01d6740cf358932b3e97ee968c6099800d9 upstream. inode_switch_wbs_work_fn() has a loop like: wb_get(new_wb); while (1) { list = llist_del_all(&new_wb->switch_wbs_ctxs); /* Nothing to do? */ if (!list) break; ... process the items ... } Now adding of items to the list looks like: wb_queue_isw() if (llist_add(&isw->list, &wb->switch_wbs_ctxs)) queue_work(isw_wq, &wb->switch_work); Because inode_switch_wbs_work_fn() loops when processing isw items, it can happen that wb->switch_work is pending while wb->switch_wbs_ctxs is empty. This is a problem because in that case wb can get freed (no isw items -> no wb reference) while the work is still pending causing use-after-free issues. We cannot just fix this by cancelling work when freeing wb because that could still trigger problematic 0 -> 1 transitions on wb refcount due to wb_get() in inode_switch_wbs_work_fn(). It could be all handled with more careful code but that seems unnecessarily complex so let's avoid that until it is proven that the looping actually brings practical benefit. Just remove the loop from inode_switch_wbs_work_fn() instead. That way when wb_queue_isw() queues work, we are guaranteed we have added the first item to wb->switch_wbs_ctxs and nobody is going to remove it (and drop the wb reference it holds) until the queued work runs. Fixes: e1b849cfa6b6 ("writeback: Avoid contention on wb->list_lock when switching inodes") CC: stable@vger.kernel.org Signed-off-by: Jan Kara Link: https://patch.msgid.link/20260413093618.17244-2-jack@suse.cz Acked-by: Tejun Heo Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit feefd5d5b5ee258082d7f8687b0b209cbfa539f6 Author: DaeMyung Kang Date: Sun Apr 19 02:28:44 2026 +0900 ksmbd: reset rcount per connection in ksmbd_conn_wait_idle_sess_id() commit def036ef87f8641c1c525d5ae17438d7a1006491 upstream. rcount is intended to be connection-specific: 2 for curr_conn, 1 for every other connection sharing the same session. However, it is initialised only once before the hash iteration and is never reset. After the loop visits curr_conn, later sibling connections are also checked against rcount == 2, so a sibling with req_running == 1 is incorrectly treated as idle. This makes the outcome depend on the hash iteration order: whether a given sibling is checked against the loose (< 2) or the strict (< 1) threshold is decided by whether it happens to be visited before or after curr_conn. The function's contract is "wait until every connection sharing this session is idle" so that destroy_previous_session() can safely tear the session down. The latched rcount violates that contract and reopens the teardown race window the wait logic was meant to close: destroy_previous_session() may proceed before sibling channels have actually quiesced, overlapping session teardown with in-flight work on those connections. Recompute rcount inside the loop so each connection is compared against its own threshold regardless of iteration order. This is a code-inspection fix for an iteration-order-dependent logic error; a targeted reproducer would require SMB3 multichannel with in-flight work on a sibling channel landing after curr_conn in hash order, which is not something that can be triggered reliably. Fixes: 76e98a158b20 ("ksmbd: fix race condition between destroy_previous_session() and smb2 operations()") Cc: stable@vger.kernel.org Signed-off-by: DaeMyung Kang Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 5e7b8f3c539d69b2ed5f2408e2f75e68ce7eef43 Author: Tristan Madani Date: Fri Apr 17 19:54:57 2026 +0000 ksmbd: use check_add_overflow() to prevent u16 DACL size overflow commit 299f962c0b02d048fb45d248b4da493d03f3175d upstream. set_posix_acl_entries_dacl() and set_ntacl_dacl() accumulate ACE sizes in u16 variables. When a file has many POSIX ACL entries, the accumulated size can wrap past 65535, causing the pointer arithmetic (char *)pndace + *size to land within already-written ACEs. Subsequent writes then overwrite earlier entries, and pndacl->size gets a truncated value. Use check_add_overflow() at each accumulation point to detect the wrap before it corrupts the buffer, consistent with existing check_mul_overflow() usage elsewhere in smbacl.c. Cc: stable@vger.kernel.org Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Signed-off-by: Tristan Madani Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 790304c02bf9bd7b8171feda4294d6e62d32ae8f Author: Tristan Madani Date: Fri Apr 17 19:33:17 2026 +0000 ksmbd: fix out-of-bounds write in smb2_get_ea() EA alignment commit 30010c952077a1c89ecdd71fc4d574c75a8f5617 upstream. smb2_get_ea() applies 4-byte alignment padding via memset() after writing each EA entry. The bounds check on buf_free_len is performed before the value memcpy, but the alignment memset fires unconditionally afterward with no check on remaining space. When the EA value exactly fills the remaining buffer (buf_free_len == 0 after value subtraction), the alignment memset writes 1-3 NUL bytes past the buf_free_len boundary. In compound requests where the response buffer is shared across commands, the first command (e.g., READ) can consume most of the buffer, leaving a tight remainder for the QUERY_INFO EA response. The alignment memset then overwrites past the physical kvmalloc allocation into adjacent kernel heap memory. Add a bounds check before the alignment memset to ensure buf_free_len can accommodate the padding bytes. This is the same bug pattern fixed by commit beef2634f81f ("ksmbd: fix potencial OOB in get_file_all_info() for compound requests") and commit fda9522ed6af ("ksmbd: fix OOB write in QUERY_INFO for compound requests"), both of which added bounds checks before unconditional writes in QUERY_INFO response handlers. Cc: stable@vger.kernel.org Fixes: e2b76ab8b5c9 ("ksmbd: add support for read compound") Signed-off-by: Tristan Madani Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 3e5360b422dd741cb315654a191fa73869a37414 Author: Michael Bommarito Date: Fri Apr 17 14:45:57 2026 -0400 ksmbd: validate num_aces and harden ACE walk in smb_inherit_dacl() commit 3e4e2ea2a781018ed5d75f969e3e5606beb66e48 upstream. smb_inherit_dacl() trusts the on-disk num_aces value from the parent directory's DACL xattr and uses it to size a heap allocation: aces_base = kmalloc(sizeof(struct smb_ace) * num_aces * 2, ...); num_aces is a u16 read from le16_to_cpu(parent_pdacl->num_aces) without checking that it is consistent with the declared pdacl_size. An authenticated client whose parent directory's security.NTACL is tampered (e.g. via offline xattr corruption or a concurrent path that bypasses parse_dacl()) can present num_aces = 65535 with minimal actual ACE data. This causes a ~8 MB allocation (not kzalloc, so uninitialized) that the subsequent loop only partially populates, and may also overflow the three-way size_t multiply on 32-bit kernels. Additionally, the ACE walk loop uses the weaker offsetof(struct smb_ace, access_req) minimum size check rather than the minimum valid on-wire ACE size, and does not reject ACEs whose declared size is below the minimum. Reproduced on UML + KASAN + LOCKDEP against the real ksmbd code path. A legitimate mount.cifs client creates a parent directory over SMB (ksmbd writes a valid security.NTACL xattr), then the NTACL blob on the backing filesystem is rewritten to set num_aces = 0xFFFF while keeping the posix_acl_hash bytes intact so ksmbd_vfs_get_sd_xattr()'s hash check still passes. A subsequent SMB2 CREATE of a child under that parent drives smb2_open() into smb_inherit_dacl() (share has "vfs objects = acl_xattr" set), which fails the page allocator: WARNING: mm/page_alloc.c:5226 at __alloc_frozen_pages_noprof+0x46c/0x9c0 Workqueue: ksmbd-io handle_ksmbd_work __alloc_frozen_pages_noprof+0x46c/0x9c0 ___kmalloc_large_node+0x68/0x130 __kmalloc_large_node_noprof+0x24/0x70 __kmalloc_noprof+0x4c9/0x690 smb_inherit_dacl+0x394/0x2430 smb2_open+0x595d/0xabe0 handle_ksmbd_work+0x3d3/0x1140 With the patch applied the added guard rejects the tampered value with -EINVAL before any large allocation runs, smb2_open() falls back to smb2_create_sd_buffer(), and the child is created with a default SD. No warning, no splat. Fix by: 1. Validating num_aces against pdacl_size using the same formula applied in parse_dacl(). 2. Replacing the raw kmalloc(sizeof * num_aces * 2) with kmalloc_array(num_aces * 2, sizeof(...)) for overflow-safe allocation. 3. Tightening the per-ACE loop guard to require the minimum valid ACE size (offsetof(smb_ace, sid) + CIFS_SID_BASE_SIZE) and rejecting under-sized ACEs, matching the hardening in smb_check_perm_dacl() and parse_dacl(). v1 -> v2: - Replace the synthetic test-module splat in the changelog with a real-path UML + KASAN reproduction driven through mount.cifs and SMB2 CREATE; Namjae flagged the kcifs3_test_inherit_dacl_old name in v1 since it does not exist in ksmbd. - Drop the commit-hash citation from the code comment per Namjae's review; keep the parse_dacl() pointer. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Michael Bommarito Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 299db777ea0cfa5c407e41b045c24a14c034c27b Author: Michael Bommarito Date: Wed Apr 15 07:25:00 2026 -0400 ksmbd: validate response sizes in ipc_validate_msg() commit d6a6aa81eac2c9bff66dc6e191179cb69a14426b upstream. ipc_validate_msg() computes the expected message size for each response type by adding (or multiplying) attacker-controlled fields from the daemon response to a fixed struct size in unsigned int arithmetic. Three cases can overflow: KSMBD_EVENT_RPC_REQUEST: msg_sz = sizeof(struct ksmbd_rpc_command) + resp->payload_sz; KSMBD_EVENT_SHARE_CONFIG_REQUEST: msg_sz = sizeof(struct ksmbd_share_config_response) + resp->payload_sz; KSMBD_EVENT_LOGIN_REQUEST_EXT: msg_sz = sizeof(struct ksmbd_login_response_ext) + resp->ngroups * sizeof(gid_t); resp->payload_sz is __u32 and resp->ngroups is __s32. Each addition can wrap in unsigned int; the multiplication by sizeof(gid_t) mixes signed and size_t, so a negative ngroups is converted to SIZE_MAX before the multiply. A wrapped value of msg_sz that happens to equal entry->msg_sz bypasses the size check on the next line, and downstream consumers (smb2pdu.c:6742 memcpy using rpc_resp->payload_sz, kmemdup in ksmbd_alloc_user using resp_ext->ngroups) then trust the unverified length. Use check_add_overflow() on the RPC_REQUEST and SHARE_CONFIG_REQUEST paths to detect integer overflow without constraining functional payload size; userspace ksmbd-tools grows NDR responses in 4096-byte chunks for calls like NetShareEnumAll, so a hard transport cap is unworkable on the response side. For LOGIN_REQUEST_EXT, reject resp->ngroups outside the signed [0, NGROUPS_MAX] range up front and report the error from ipc_validate_msg() so it fires at the IPC boundary; with that bound the subsequent multiplication and addition stay well below UINT_MAX. The now-redundant ngroups check and pr_err in ksmbd_alloc_user() are removed. This is the response-side analogue of aab98e2dbd64 ("ksmbd: fix integer overflows on 32 bit systems"), which hardened the request side. Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers") Fixes: a77e0e02af1c ("ksmbd: add support for supplementary groups") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Assisted-by: Codex:gpt-5-4 Signed-off-by: Michael Bommarito Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 078fae8f50adebb903ccf2252b44391324571e78 Author: Michael Bommarito Date: Sun Apr 19 19:35:19 2026 -0400 smb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO path commit a58c5af19ff0d6f44f6e9fe31e33a2c92223f77e upstream. smb2_ioctl_query_info() has two response-copy branches: PASSTHRU_FSCTL and the default QUERY_INFO path. The QUERY_INFO branch clamps qi.input_buffer_length to the server-reported OutputBufferLength and then copies qi.input_buffer_length bytes from qi_rsp->Buffer to userspace, but it never verifies that the flexible-array payload actually fits within rsp_iov[1].iov_len. A malicious server can return OutputBufferLength larger than the actual QUERY_INFO response, causing copy_to_user() to walk past the response buffer and expose adjacent kernel heap to userspace. Guard the QUERY_INFO copy with a bounds check on the actual Buffer payload. Use struct_size(qi_rsp, Buffer, qi.input_buffer_length) rather than an open-coded addition so the guard cannot overflow on 32-bit builds. Fixes: f5778c398713 ("SMB3: Allow SMB3 FSCTL queries to be sent to server from tools") Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Assisted-by: Claude:claude-opus-4-6 Assisted-by: Codex:gpt-5-4 Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 38a69f08ee82c450d3e4168707fff2e317dc3ff7 Author: Michael Bommarito Date: Mon Apr 20 09:50:58 2026 -0400 smb: client: require a full NFS mode SID before reading mode bits commit 2757ad3e4b6f9e0fed4c7739594e702abc5cab21 upstream. parse_dacl() treats an ACE SID matching sid_unix_NFS_mode as an NFS mode SID and reads sid.sub_auth[2] to recover the mode bits. That assumes the ACE carries three subauthorities, but compare_sids() only compares min(a, b) subauthorities. A malicious server can return an ACE with num_subauth = 2 and sub_auth[] = {88, 3}, which still matches sid_unix_NFS_mode and then drives the sub_auth[2] read four bytes past the end of the ACE. Require num_subauth >= 3 before treating the ACE as an NFS mode SID. This keeps the fix local to the special-SID mode path without changing compare_sids() semantics for the rest of cifsacl. Fixes: e2f8fbfb8d09 ("cifs: get mode bits from special sid on stat") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Michael Bommarito Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 3943e4565aae70edd79cff1ee4f41cd570001ec8 Author: DaeMyung Kang Date: Fri Apr 17 06:17:35 2026 +0900 smb: server: fix max_connections off-by-one in tcp accept path commit ce23158bfe584bd90d1918f279fdf9de57802012 upstream. The global max_connections check in ksmbd's TCP accept path counts the newly accepted connection with atomic_inc_return(), but then rejects the connection when the result is greater than or equal to server_conf.max_connections. That makes the effective limit one smaller than configured. For example: - max_connections=1 rejects the first connection - max_connections=2 allows only one connection The per-IP limit in the same function uses <= correctly because it counts only pre-existing connections. The global limit instead checks the post-increment total, so it should reject only when that total exceeds the configured maximum. Fix this by changing the comparison from >= to >, so exactly max_connections simultaneous connections are allowed and the next one is rejected. This matches the documented meaning of max_connections in fs/smb/server/ksmbd_netlink.h as the "Number of maximum simultaneous connections". Fixes: 0d0d4680db22 ("ksmbd: add max connections parameter") Cc: stable@vger.kernel.org Signed-off-by: DaeMyung Kang Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 283027aa93380380a0994f35dde3ec95318f2654 Author: Michael Bommarito Date: Tue Apr 14 18:54:38 2026 -0400 smb: server: fix active_num_conn leak on transport allocation failure commit 6551300dc452ac16a855a83dbd1e74899542d3b3 upstream. Commit 77ffbcac4e56 ("smb: server: fix leak of active_num_conn in ksmbd_tcp_new_connection()") addressed the kthread_run() failure path. The earlier alloc_transport() == NULL path in the same function has the same leak, is reachable pre-authentication via any TCP connect to port 445, and was empirically reproduced on UML (ARCH=um, v7.0-rc7): a small number of forced allocation failures were sufficient to put ksmbd into a state where every subsequent connection attempt was rejected for the remainder of the boot. ksmbd_kthread_fn() increments active_num_conn before calling ksmbd_tcp_new_connection() and discards the return value, so when alloc_transport() returns NULL the socket is released and -ENOMEM returned without decrementing the counter. Each such failure permanently consumes one slot from the max_connections pool; once cumulative failures reach the cap, atomic_inc_return() hits the threshold on every subsequent accept and every new connection is rejected. The counter is only reset by module reload. An unauthenticated remote attacker can drive the server toward the memory pressure that makes alloc_transport() fail by holding open connections with large RFC1002 lengths up to MAX_STREAM_PROT_LEN (0x00FFFFFF); natural transient allocation failures on a loaded host produce the same drift more slowly. Mirror the existing rollback pattern in ksmbd_kthread_fn(): on the alloc_transport() failure path, decrement active_num_conn gated on server_conf.max_connections. Repro details: with the patch reverted, forced alloc_transport() NULL returns leaked counter slots and subsequent connection attempts -- including legitimate connects issued after the forced-fail window had closed -- were all rejected with "Limit the maximum number of connections". With this patch applied, the same connect sequence produces no rejections and the counter cycles cleanly between zero and one on every accept. Fixes: 0d0d4680db22 ("ksmbd: add max connections parameter") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Assisted-by: Codex:gpt-5-4 Signed-off-by: Michael Bommarito Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 90089584b2e25c4510b7b987387b4405f0673ece Author: Michael Bommarito Date: Tue Apr 14 15:15:33 2026 -0400 ksmbd: require minimum ACE size in smb_check_perm_dacl() commit d07b26f39246a82399661936dd0c853983cfade7 upstream. Both ACE-walk loops in smb_check_perm_dacl() only guard against an under-sized remaining buffer, not against an ACE whose declared `ace->size` is smaller than the struct it claims to describe: if (offsetof(struct smb_ace, access_req) > aces_size) break; ace_size = le16_to_cpu(ace->size); if (ace_size > aces_size) break; The first check only requires the 4-byte ACE header to be in bounds; it does not require access_req (4 bytes at offset 4) to be readable. An attacker who has set a crafted DACL on a file they own can declare ace->size == 4 with aces_size == 4, pass both checks, and then granted |= le32_to_cpu(ace->access_req); /* upper loop */ compare_sids(&sid, &ace->sid); /* lower loop */ reads access_req at offset 4 (OOB by up to 4 bytes) and ace->sid at offset 8 (OOB by up to CIFS_SID_BASE_SIZE + SID_MAX_SUB_AUTHORITIES * 4 bytes). Tighten both loops to require ace_size >= offsetof(struct smb_ace, sid) + CIFS_SID_BASE_SIZE which is the smallest valid on-wire ACE layout (4-byte header + 4-byte access_req + 8-byte sid base with zero sub-auths). Also reject ACEs whose sid.num_subauth exceeds SID_MAX_SUB_AUTHORITIES before letting compare_sids() dereference sub_auth[] entries. parse_sec_desc() already enforces an equivalent check (lines 441-448); smb_check_perm_dacl() simply grew weaker validation over time. Reachability: authenticated SMB client with permission to set an ACL on a file. On a subsequent CREATE against that file, the kernel walks the stored DACL via smb_check_perm_dacl() and triggers the OOB read. Not pre-auth, and the OOB read is not reflected to the attacker, but KASAN reports and kernel state corruption are possible. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Assisted-by: Codex:gpt-5-4 Signed-off-by: Michael Bommarito Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 3fa185e320197a29aec768837f8933a48094ff3d Author: Miklos Szeredi Date: Thu Apr 2 20:19:55 2026 +0200 fuse: fuse_dev_ioctl_clone() should wait for device file to be initialized commit da6fcc6dbddbef80e603d2f0c1554a9f2ac03742 upstream. Use fuse_get_dev() not __fuse_get_dev() on the old fd, since in the case of synchronous INIT the caller will want to wait for the device file to be available for cloning, just like I/O wants to wait instead of returning an error. Fixes: dfb84c330794 ("fuse: allow synchronous FUSE_INIT") Cc: stable@vger.kernel.org # v6.18 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 9ef130452eaf13fcab9de8ad554df5e97e4930d0 Author: Darrick J. Wong Date: Mon Feb 23 15:06:50 2026 -0800 fuse: quiet down complaints in fuse_conn_limit_write commit 129a45f9755a89f573c6a513a6b9e3d234ce89b0 upstream. gcc 15 complains about an uninitialized variable val that is passed by reference into fuse_conn_limit_write: control.c: In function ‘fuse_conn_congestion_threshold_write’: include/asm-generic/rwonce.h:55:37: warning: ‘val’ may be used uninitialized [-Wmaybe-uninitialized] 55 | *(volatile typeof(x) *)&(x) = (val); \ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ include/asm-generic/rwonce.h:61:9: note: in expansion of macro ‘__WRITE_ONCE’ 61 | __WRITE_ONCE(x, val); \ | ^~~~~~~~~~~~ control.c:178:9: note: in expansion of macro ‘WRITE_ONCE’ 178 | WRITE_ONCE(fc->congestion_threshold, val); | ^~~~~~~~~~ control.c:166:18: note: ‘val’ was declared here 166 | unsigned val; | ^~~ Unfortunately there's enough macro spew involved in kstrtoul_from_user that I think gcc gives up on its analysis and sprays the above warning. AFAICT it's not actually a bug, but we could just zero-initialize the variable to enable using -Wmaybe-uninitialized to find real problems. Previously we would use some weird uninitialized_var annotation to quiet down the warnings, so clearly this code has been like this for quite some time. Cc: stable@vger.kernel.org # v5.9 Fixes: 3f649ab728cda8 ("treewide: Remove uninitialized_var() usage") Signed-off-by: Darrick J. Wong Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 1381635aeb7f874acbf38a917ad86332854aacbe Author: Bernd Schubert Date: Sun Jan 11 12:48:07 2026 +0100 fuse: Check for large folio with SPLICE_F_MOVE commit 59ba47b6be9cd0146ef9a55c6e32e337e11e7625 upstream. xfstest generic/074 and generic/075 complain result in kernel warning messages / page dumps. This is easily reproducible (on 6.19) with CONFIG_TRANSPARENT_HUGEPAGE_SHMEM_HUGE_ALWAYS=y CONFIG_TRANSPARENT_HUGEPAGE_TMPFS_HUGE_ALWAYS=y This just adds a test for large folios fuse_try_move_folio with the same page copy fallback, but to avoid the warnings from fuse_check_folio(). Cc: stable@vger.kernel.org Signed-off-by: Bernd Schubert Signed-off-by: Horst Birthelmer Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 0c7fca880a40a209a9c92be14143996d14b93ff6 Author: Miklos Szeredi Date: Mon Mar 16 14:10:00 2026 +0100 fuse: abort on fatal signal during sync init commit 204aa22a686bfee48daca7db620c1e017615f2ff upstream. When sync init is used and the server exits for some reason (error, crash) while processing FUSE_INIT, the filesystem creation will hang. The reason is that while all other threads will exit, the mounting thread (or process) will keep the device fd open, which will prevent an abort from happening. This is a regression from the async mount case, where the mount was done first, and the FUSE_INIT processing afterwards, in which case there's no such recursive syscall keeping the fd open. Fixes: dfb84c330794 ("fuse: allow synchronous FUSE_INIT") Cc: stable@vger.kernel.org # v6.18 Reviewed-by: Joanne Koong Reviewed-by: Bernd Schubert Reviewed-by: "Darrick J. Wong" Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 7de93abfaae1b2dc94da8a07a36421bd073f1d8f Author: Samuel Page Date: Mon Apr 20 11:01:37 2026 +0200 fuse: reject oversized dirents in page cache commit 51a8de6c50bf947c8f534cd73da4c8f0a13e7bed upstream. fuse_add_dirent_to_cache() computes a serialized dirent size from the server-controlled namelen field and copies the dirent into a single page-cache page. The existing logic only checks whether the dirent fits in the remaining space of the current page and advances to a fresh page if not. It never checks whether the dirent itself exceeds PAGE_SIZE. As a result, a malicious FUSE server can return a dirent with namelen=4095, producing a serialized record size of 4120 bytes. On 4 KiB page systems this causes memcpy() to overflow the cache page by 24 bytes into the following kernel page. Reject dirents that cannot fit in a single page before copying them into the readdir cache. Fixes: 69e34551152a ("fuse: allow caching readdir") Cc: stable@vger.kernel.org # v6.16+ Assisted-by: Bynario AI Signed-off-by: Samuel Page Reported-by: Qi Tang Reported-by: Zijun Hu Signed-off-by: Miklos Szeredi Link: https://patch.msgid.link/20260420090139.662772-1-mszeredi@redhat.com Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit 59970b2586fef4b13e96527b9d232bed30b640cd Author: Chao Yu Date: Mon Mar 9 02:22:37 2026 +0000 f2fs: fix to avoid uninit-value access in f2fs_sanity_check_node_footer commit 7b9161a605e91d0987e2596a245dc1f21621b23f upstream. syzbot reported a f2fs bug as below: BUG: KMSAN: uninit-value in f2fs_sanity_check_node_footer+0x374/0xa20 fs/f2fs/node.c:1520 f2fs_sanity_check_node_footer+0x374/0xa20 fs/f2fs/node.c:1520 f2fs_finish_read_bio+0xe1e/0x1d60 fs/f2fs/data.c:177 f2fs_read_end_io+0x6ab/0x2220 fs/f2fs/data.c:-1 bio_endio+0x1006/0x1160 block/bio.c:1792 submit_bio_noacct+0x533/0x2960 block/blk-core.c:891 submit_bio+0x57a/0x620 block/blk-core.c:926 blk_crypto_submit_bio include/linux/blk-crypto.h:203 [inline] f2fs_submit_read_bio+0x12c/0x360 fs/f2fs/data.c:557 f2fs_submit_page_bio+0xee2/0x1450 fs/f2fs/data.c:775 read_node_folio+0x384/0x4b0 fs/f2fs/node.c:1481 __get_node_folio+0x5db/0x15d0 fs/f2fs/node.c:1576 f2fs_get_inode_folio+0x40/0x50 fs/f2fs/node.c:1623 do_read_inode fs/f2fs/inode.c:425 [inline] f2fs_iget+0x1209/0x9380 fs/f2fs/inode.c:596 f2fs_fill_super+0x8f5a/0xb2e0 fs/f2fs/super.c:5184 get_tree_bdev_flags+0x6e6/0x920 fs/super.c:1694 get_tree_bdev+0x38/0x50 fs/super.c:1717 f2fs_get_tree+0x35/0x40 fs/f2fs/super.c:5436 vfs_get_tree+0xb3/0x5d0 fs/super.c:1754 fc_mount fs/namespace.c:1193 [inline] do_new_mount_fc fs/namespace.c:3763 [inline] do_new_mount+0x885/0x1dd0 fs/namespace.c:3839 path_mount+0x7a2/0x20b0 fs/namespace.c:4159 do_mount fs/namespace.c:4172 [inline] __do_sys_mount fs/namespace.c:4361 [inline] __se_sys_mount+0x704/0x7f0 fs/namespace.c:4338 __x64_sys_mount+0xe4/0x150 fs/namespace.c:4338 x64_sys_call+0x39f0/0x3ea0 arch/x86/include/generated/asm/syscalls_64.h:166 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x134/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is: in f2fs_finish_read_bio(), we may access uninit data in folio if we failed to read the data from device into folio, let's add a check condition to avoid such issue. Cc: stable@kernel.org Fixes: 50ac3ecd8e05 ("f2fs: fix to do sanity check on node footer in {read,write}_end_io") Reported-by: syzbot+9aac813cdc456cdd49f8@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-f2fs-devel/69a9ca26.a70a0220.305d9a.0000.GAE@google.com Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 047c0aef6af37a2a35181aa085c616ad286386f1 Author: Chao Yu Date: Wed Mar 4 16:22:31 2026 +0800 f2fs: fix to avoid memory leak in f2fs_rename() commit 3cf11e6f36c170050c12171dd6fd3142711478fc upstream. syzbot reported a f2fs bug as below: BUG: memory leak unreferenced object 0xffff888127f70830 (size 16): comm "syz.0.23", pid 6144, jiffies 4294943712 hex dump (first 16 bytes): 3c af 57 72 5b e6 8f ad 6e 8e fd 33 42 39 03 ff <.Wr[...n..3B9.. backtrace (crc 925f8a80): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4520 [inline] slab_alloc_node mm/slub.c:4844 [inline] __do_kmalloc_node mm/slub.c:5237 [inline] __kmalloc_noprof+0x3bd/0x560 mm/slub.c:5250 kmalloc_noprof include/linux/slab.h:954 [inline] fscrypt_setup_filename+0x15e/0x3b0 fs/crypto/fname.c:364 f2fs_setup_filename+0x52/0xb0 fs/f2fs/dir.c:143 f2fs_rename+0x159/0xca0 fs/f2fs/namei.c:961 f2fs_rename2+0xd5/0xf20 fs/f2fs/namei.c:1308 vfs_rename+0x7ff/0x1250 fs/namei.c:6026 filename_renameat2+0x4f4/0x660 fs/namei.c:6144 __do_sys_renameat2 fs/namei.c:6173 [inline] __se_sys_renameat2 fs/namei.c:6168 [inline] __x64_sys_renameat2+0x59/0x80 fs/namei.c:6168 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 The root cause is in commit 40b2d55e0452 ("f2fs: fix to create selinux label during whiteout initialization"), we added a call to f2fs_setup_filename() without a matching call to f2fs_free_filename(), fix it. Fixes: 40b2d55e0452 ("f2fs: fix to create selinux label during whiteout initialization") Cc: stable@kernel.org Reported-by: syzbot+cf7946ab25b21abc4b66@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-f2fs-devel/69a75fe1.a70a0220.b118c.0014.GAE@google.com Suggested-by: Eric Biggers Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 963d2e24d9d92a31e6773b0f642214f10013ebf7 Author: Yongpeng Yang Date: Fri Feb 27 15:30:52 2026 +0800 f2fs: fix UAF caused by decrementing sbi->nr_pages[] in f2fs_write_end_io() commit 2d9c4a4ed4eef1f82c5b16b037aee8bad819fd53 upstream. The xfstests case "generic/107" and syzbot have both reported a NULL pointer dereference. The concurrent scenario that triggers the panic is as follows: F2FS_WB_CP_DATA write callback umount - f2fs_write_checkpoint - f2fs_wait_on_all_pages(sbi, F2FS_WB_CP_DATA) - blk_mq_end_request - bio_endio - f2fs_write_end_io : dec_page_count(sbi, F2FS_WB_CP_DATA) : wake_up(&sbi->cp_wait) - kill_f2fs_super - kill_block_super - f2fs_put_super : iput(sbi->node_inode) : sbi->node_inode = NULL : f2fs_in_warm_node_list - is_node_folio // sbi->node_inode is NULL and panic The root cause is that f2fs_put_super() calls iput(sbi->node_inode) and sets sbi->node_inode to NULL after sbi->nr_pages[F2FS_WB_CP_DATA] is decremented to zero. As a result, f2fs_in_warm_node_list() may dereference a NULL node_inode when checking whether a folio belongs to the node inode, leading to a panic. This patch fixes the issue by calling f2fs_in_warm_node_list() before decrementing sbi->nr_pages[F2FS_WB_CP_DATA], thus preventing the use-after-free condition. Cc: stable@kernel.org Fixes: 50fa53eccf9f ("f2fs: fix to avoid broken of dnode block list") Reported-by: syzbot+6e4cb1cac5efc96ea0ca@syzkaller.appspotmail.com Signed-off-by: Yongpeng Yang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 748c5d08f1a92eb56d1d381e8811cd1c51cdca7f Author: Chao Yu Date: Wed Mar 11 21:35:42 2026 +0800 f2fs: fix to do sanity check on dcc->discard_cmd_cnt conditionally commit 6af249c996f7d73a3435f9e577956fa259347d18 upstream. Syzbot reported a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:1900! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 6527 Comm: syz.5.110 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026 RIP: 0010:f2fs_issue_discard_timeout+0x59b/0x5a0 fs/f2fs/segment.c:1900 Code: d9 80 e1 07 80 c1 03 38 c1 0f 8c d6 fe ff ff 48 89 df e8 a8 5e fa fd e9 c9 fe ff ff e8 4e 46 94 fd 90 0f 0b e8 46 46 94 fd 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc9000494f940 EFLAGS: 00010283 RAX: ffffffff843009ca RBX: 0000000000000001 RCX: 0000000000080000 RDX: ffffc9001ca78000 RSI: 00000000000029f3 RDI: 00000000000029f4 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffed100893a431 R12: 1ffff1100893a430 R13: 1ffff1100c2b702c R14: dffffc0000000000 R15: ffff8880449d2160 FS: 00007ffa35fed6c0(0000) GS:ffff88812643d000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2b68634000 CR3: 0000000039f62000 CR4: 00000000003526f0 Call Trace: __f2fs_remount fs/f2fs/super.c:2960 [inline] f2fs_reconfigure+0x108a/0x1710 fs/f2fs/super.c:5443 reconfigure_super+0x227/0x8a0 fs/super.c:1080 do_remount fs/namespace.c:3391 [inline] path_mount+0xdc5/0x10e0 fs/namespace.c:4151 do_mount fs/namespace.c:4172 [inline] __do_sys_mount fs/namespace.c:4361 [inline] __se_sys_mount+0x31d/0x420 fs/namespace.c:4338 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ffa37dbda0a The root cause is there will be race condition in between f2fs_ioc_fitrim() and f2fs_remount(): - f2fs_remount - f2fs_ioc_fitrim - f2fs_issue_discard_timeout - __issue_discard_cmd - __drop_discard_cmd - __wait_all_discard_cmd - f2fs_trim_fs - f2fs_write_checkpoint - f2fs_clear_prefree_segments - f2fs_issue_discard - __issue_discard_async - __queue_discard_cmd - __update_discard_tree_range - __insert_discard_cmd - __create_discard_cmd : atomic_inc(&dcc->discard_cmd_cnt); - sanity check on dcc->discard_cmd_cnt (expect discard_cmd_cnt to be zero) This will only happen when fitrim races w/ remount rw, if we remount to readonly filesystem, remount will wait until mnt_pcp.mnt_writers to zero, that means fitrim is not in process at that time. Cc: stable@kernel.org Fixes: 2482c4325dfe ("f2fs: detect bug_on in f2fs_wait_discard_bios") Reported-by: syzbot+62538b67389ee582837a@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-f2fs-devel/69b07d7c.050a0220.8df7.09a1.GAE@google.com Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 0112e6279420d4005b3d57af36fb45c01b8d0116 Author: Greg Kroah-Hartman Date: Thu Apr 9 16:37:15 2026 +0200 fs/ntfs3: validate rec->used in journal-replay file record check commit 0ca0485e4b2e837ebb6cbd4f2451aba665a03e4b upstream. check_file_record() validates rec->total against the record size but never validates rec->used. The do_action() journal-replay handlers read rec->used from disk and use it to compute memmove lengths: DeleteAttribute: memmove(attr, ..., used - asize - roff) CreateAttribute: memmove(..., attr, used - roff) change_attr_size: memmove(..., used - PtrOffset(rec, next)) When rec->used is smaller than the offset of a validated attribute, or larger than the record size, these subtractions can underflow allowing us to copy huge amounts of memory in to a 4kb buffer, generally considered a bad idea overall. This requires a corrupted filesystem, which isn't a threat model the kernel really needs to worry about, but checking for such an obvious out-of-bounds value is good to keep things robust, especially on journal replay Fix this up by bounding rec->used correctly. This is much like commit b2bc7c44ed17 ("fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot") which checked different values in this same switch statement. Cc: Konstantin Komarov Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Cc: stable Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit f218fb82877b173312ecdae95bce93234e8561ee Author: Nathan Chancellor Date: Mon Apr 20 17:36:46 2026 -0700 scripts/dtc: Remove unused dts_version in dtc-lexer.l This patch is for stable only. Commit 5a09df20872c ("scripts/dtc: Update to upstream version v1.7.2-69-g53373d135579") upstream applied it as part of a regular scripts/dtc sync, which may be unsuitable for older versions of stable where the warning it fixes is present. A recent strengthening of -Wunused-but-set-variable (enabled with -Wall) in clang under a new subwarning, -Wunused-but-set-global, points out an unused static global variable in dtc-lexer.lex.c (compiled from dtc-lexer.l): scripts/dtc/dtc-lexer.lex.c:641:12: warning: variable 'dts_version' set but not used [-Wunused-but-set-global] 641 | static int dts_version = 1; | ^ Remove it to clear up the warning, as it is truly unused. Fixes: 658f29a51e98 ("of/flattree: Update dtc to current mainline.") Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit c846ed5ac80fa62d7d977899705c53aafd51c217 Author: Eric Biggers Date: Tue Apr 21 14:05:54 2026 -0700 lib/crypto: tests: Drop the default to CRYPTO_SELFTESTS commit 6d80749becf8fc5ffa004194e578f79b558235ef upstream. Defaulting the crypto KUnit tests to KUNIT_ALL_TESTS || CRYPTO_SELFTESTS instead of simply KUNIT_ALL_TESTS was originally intended to make it easy to enable all the crypto KUnit tests. This additional default is nonstandard for KUnit tests, though, and it can cause all the KUnit tests to be built-in unexpectedly if CRYPTO_SELFTESTS is set. It also constitutes a back-reference to crypto/ from lib/crypto/, which is something that we should be avoiding in order to get clean layering. Now that we provide a lib/crypto/.kunitconfig file that enables all crypto KUnit tests, let's consider that to be the supported way to enable all these tests, and drop the default of CRYPTO_SELFTESTS. Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260317040626.5697-1-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit ca47b87f24571cb787a48a1638b68633a1ffc09c Author: Eric Biggers Date: Tue Apr 21 14:05:53 2026 -0700 kunit: configs: Enable all crypto library tests in all_tests.config commit 8d547482231fef30d0d6440629b73560ad3e937c upstream. The new option CONFIG_CRYPTO_LIB_ENABLE_ALL_FOR_KUNIT enables all the crypto library code that has KUnit tests, causing CONFIG_KUNIT_ALL_TESTS to enable all these tests. Add this option to all_tests.config so that kunit.py will run them when passed the --alltests option. Link: https://lore.kernel.org/r/20260314035927.51351-3-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 95c05443aa34e40e8a4a0c036ea7b5655f75f100 Author: Eric Biggers Date: Tue Apr 21 14:05:52 2026 -0700 lib/crypto: tests: Introduce CRYPTO_LIB_ENABLE_ALL_FOR_KUNIT commit ed1767442d919f57aaf83d69c33853da2644d902 upstream. For kunit.py to run all the crypto library tests when passed the --alltests option, tools/testing/kunit/configs/all_tests.config needs to enable options that satisfy the test dependencies. This is the same as what lib/crypto/.kunitconfig already does. However, the strategy that lib/crypto/.kunitconfig currently uses to select all the hidden library options isn't going to scale up well when it needs to be repeated in two places. Instead let's go ahead and introduce an option CRYPTO_LIB_ENABLE_ALL_FOR_KUNIT that depends on KUNIT and selects all the crypto library options that have corresponding KUnit tests. Update lib/crypto/.kunitconfig to use this option. Link: https://lore.kernel.org/r/20260314035927.51351-2-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit b0ca42c01883782227711593d145cd39bb643c29 Author: Eric Biggers Date: Tue Apr 21 14:05:51 2026 -0700 lib/crypto: tests: Add a .kunitconfig file commit 20d6f07004d639967dcb00994d56ce6d16118e9e upstream. Add a .kunitconfig file to the lib/crypto/ directory so that the crypto library tests can be run more easily using kunit.py. Example with UML: tools/testing/kunit/kunit.py run --kunitconfig=lib/crypto Example with QEMU: tools/testing/kunit/kunit.py run --kunitconfig=lib/crypto --arch=arm64 --make_options LLVM=1 Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260301040140.490310-1-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 05f723be4d641b421e23a597d29dd28d0250694e Author: Eric Biggers Date: Tue Apr 21 14:05:50 2026 -0700 kunit: configs: Enable all CRC tests in all_tests.config commit 44ff3791d6295f7b51dd2711aad6a03dd79aef22 upstream. The new option CONFIG_CRC_ENABLE_ALL_FOR_KUNIT enables all the CRC code that has KUnit tests, causing CONFIG_KUNIT_ALL_TESTS to enable all these tests. Add this option to all_tests.config so that kunit.py will run them when passed the --alltests option. Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260314172224.15152-1-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 04c61029a3b76f5507b0fd2513cde984d8094b6c Author: Eric Biggers Date: Tue Apr 21 14:05:49 2026 -0700 lib/crc: tests: Add a .kunitconfig file commit c13cee2fc7f137dd25ed50c63eddcc578624f204 upstream. Add a .kunitconfig file to the lib/crc/ directory so that the CRC library tests can be run more easily using kunit.py. Example with UML: tools/testing/kunit/kunit.py run --kunitconfig=lib/crc Example with QEMU: tools/testing/kunit/kunit.py run --kunitconfig=lib/crc --arch=arm64 --make_options LLVM=1 Link: https://lore.kernel.org/r/20260306033557.250499-4-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 6897bdfa505f97f1d82c2b53af7fc71fce3e9292 Author: Eric Biggers Date: Tue Apr 21 14:05:48 2026 -0700 lib/crc: tests: Add CRC_ENABLE_ALL_FOR_KUNIT commit cdf22aeaad8430905c3aa3b3d0f2686c65395c22 upstream. Now that crc_kunit uses the standard "depends on" pattern, enabling the full set of CRC tests is a bit difficult, mainly due to CRC7 being rarely used. Add a kconfig option to make it easier. It is visible only when KUNIT, so hopefully the extra prompt won't be too annoying. Link: https://lore.kernel.org/r/20260306033557.250499-3-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit e70c01412893c7a8f4c27c2cd162e61e97c004b6 Author: Eric Biggers Date: Tue Apr 21 14:05:47 2026 -0700 lib/crc: tests: Make crc_kunit test only the enabled CRC variants commit 85c9f3a2b805eb96d899da7bcc38a16459aa3c16 upstream. Like commit 4478e8eeb871 ("lib/crypto: tests: Depend on library options rather than selecting them") did with the crypto library tests, make crc_kunit depend on the code it tests rather than selecting it. This follows the standard convention for KUnit and fixes an issue where enabling KUNIT_ALL_TESTS enabled non-test code. crc_kunit does differ from the crypto library tests in that it consolidates the tests for multiple CRC variants, with 5 kconfig options, into one KUnit suite. Since depending on *all* of these kconfig options would greatly restrict the ability to enable crc_kunit, instead just depend on *any* of these options. Update crc_kunit accordingly to test only the reachable code. Alternatively we could split crc_kunit into 5 test suites. But keeping it as one is simpler for now. Fixes: e47d9b1a76ed ("lib/crc_kunit.c: add KUnit test suite for CRC library functions") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20260306033557.250499-2-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 28f77fca444977a8ea4c93e1008b424137098e7d Author: Peter Zijlstra Date: Wed Apr 1 15:20:21 2026 +0200 sched/debug: Fix avg_vruntime() usage commit e08d007f9d813616ce7093600bc4fdb9c9d81d89 upstream. John reported that stress-ng-yield could make his machine unhappy and managed to bisect it to commit b3d99f43c72b ("sched/fair: Fix zero_vruntime tracking"). The commit in question changes avg_vruntime() from a function that is a pure reader, to a function that updates variables. This turns an unlocked sched/debug usage of this function from a minor mistake into a data corruptor. Fixes: af4cf40470c2 ("sched/fair: Add cfs_rq::avg_vruntime") Fixes: b3d99f43c72b ("sched/fair: Fix zero_vruntime tracking") Reported-by: John Stultz Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Vincent Guittot Tested-by: K Prateek Nayak Tested-by: John Stultz Link: https://patch.msgid.link/20260401132355.196370805@infradead.org Signed-off-by: John Stultz Signed-off-by: Greg Kroah-Hartman commit c6c87a23de4bdf5a8a8a26d9d269f4026e35afef Author: Catalin Marinas Date: Tue Apr 21 11:00:17 2026 +0100 arm64: errata: Work around early CME DVMSync acknowledgement commit 0baba94a9779c13c857f6efc55807e6a45b1d4e4 upstream. C1-Pro acknowledges DVMSync messages before completing the SME/CME memory accesses. Work around this by issuing an IPI to the affected CPUs if they are running in EL0 with SME enabled. Note that we avoid the local DSB in the IPI handler as the kernel runs with SCTLR_EL1.IESB=1. This is sufficient to complete SME memory accesses at EL0 on taking an exception to EL1. On the return to user path, no barrier is necessary either. See the comment in sme_set_active() and the more detailed explanation in the link below. To avoid a potential IPI flood from malicious applications (e.g. madvise(MADV_PAGEOUT) in a tight loop), track where a process is active via mm_cpumask() and only interrupt those CPUs. Link: https://lore.kernel.org/r/ablEXwhfKyJW1i7l@J2N7QTR9R3 Cc: Will Deacon Cc: Mark Rutland Cc: James Morse Cc: Mark Brown Reviewed-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit ee5ce483d42809b6c9e5bb25c33601e54229128f Author: Catalin Marinas Date: Tue Apr 21 11:00:16 2026 +0100 arm64: cputype: Add C1-Pro definitions commit 2c99561016c591f4c3d5ad7d22a61b8726e79735 upstream. Add cputype definitions for C1-Pro. These will be used for errata detection in subsequent patches. These values can be found in "Table A-303: MIDR_EL1 bit descriptions" in issue 07 of the C1-Pro TRM: https://documentation-service.arm.com/static/6930126730f8f55a656570af Acked-by: Mark Rutland Cc: Will Deacon Cc: James Morse Reviewed-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 456d6040bb3b23dc60935d29f321409695f1209a Author: Catalin Marinas Date: Tue Apr 21 11:00:15 2026 +0100 arm64: tlb: Pass the corresponding mm to __tlbi_sync_s1ish() commit d9fb08ba946a6190c371dcd9f9e465d0d52c5021 upstream. The mm structure will be used for workarounds that need limiting to specific tasks. Acked-by: Mark Rutland Cc: Will Deacon Reviewed-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit e785d2751b1dbe3bd3e314056335e64091fc6cb9 Author: Catalin Marinas Date: Tue Apr 21 11:00:14 2026 +0100 arm64: tlb: Introduce __tlbi_sync_s1ish_{kernel,batch}() for TLB maintenance commit 6bfbf574a39139da11af9fdf6e8d56fe1989cd3e upstream. Add __tlbi_sync_s1ish_kernel() similar to __tlbi_sync_s1ish() and use it for kernel TLB maintenance. Also use this function in flush_tlb_all() which is only used in relation to kernel mappings. Subsequent patches can differentiate between workarounds that apply to user only or both user and kernel. A subsequent patch will add mm_struct to __tlbi_sync_s1ish(). Since arch_tlbbatch_flush() is not specific to an mm, add a corresponding __tlbi_sync_s1ish_batch() helper. Acked-by: Mark Rutland Cc: Will Deacon Reviewed-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 243cec136a7485e6f59b679391569c2e1f06d031 Author: Mark Rutland Date: Tue Apr 21 11:00:13 2026 +0100 arm64: tlb: Optimize ARM64_WORKAROUND_REPEAT_TLBI commit a8f78680ee6bf795086384e8aea159a52814f827 upstream. The ARM64_WORKAROUND_REPEAT_TLBI workaround is used to mitigate several errata where broadcast TLBI;DSB sequences don't provide all the architecturally required synchronization. The workaround performs more work than necessary, and can have significant overhead. This patch optimizes the workaround, as explained below. The workaround was originally added for Qualcomm Falkor erratum 1009 in commit: d9ff80f83ecb ("arm64: Work around Falkor erratum 1009") As noted in the message for that commit, the workaround is applied even in cases where it is not strictly necessary. The workaround was later reused without changes for: * Arm Cortex-A76 erratum #1286807 SDEN v33: https://developer.arm.com/documentation/SDEN-885749/33-0/ * Arm Cortex-A55 erratum #2441007 SDEN v16: https://developer.arm.com/documentation/SDEN-859338/1600/ * Arm Cortex-A510 erratum #2441009 SDEN v19: https://developer.arm.com/documentation/SDEN-1873351/1900/ The important details to note are as follows: 1. All relevant errata only affect the ordering and/or completion of memory accesses which have been translated by an invalidated TLB entry. The actual invalidation of TLB entries is unaffected. 2. The existing workaround is applied to both broadcast and local TLB invalidation, whereas for all relevant errata it is only necessary to apply a workaround for broadcast invalidation. 3. The existing workaround replaces every TLBI with a TLBI;DSB;TLBI sequence, whereas for all relevant errata it is only necessary to execute a single additional TLBI;DSB sequence after any number of TLBIs are completed by a DSB. For example, for a sequence of batched TLBIs: TLBI [, ] TLBI [, ] TLBI [, ] DSB ISH ... the existing workaround will expand this to: TLBI [, ] DSB ISH // additional TLBI [, ] // additional TLBI [, ] DSB ISH // additional TLBI [, ] // additional TLBI [, ] DSB ISH // additional TLBI [, ] // additional DSB ISH ... whereas it is sufficient to have: TLBI [, ] TLBI [, ] TLBI [, ] DSB ISH TLBI [, ] // additional DSB ISH // additional Using a single additional TBLI and DSB at the end of the sequence can have significantly lower overhead as each DSB which completes a TLBI must synchronize with other PEs in the system, with potential performance effects both locally and system-wide. 4. The existing workaround repeats each specific TLBI operation, whereas for all relevant errata it is sufficient for the additional TLBI to use *any* operation which will be broadcast, regardless of which translation regime or stage of translation the operation applies to. For example, for a single TLBI: TLBI ALLE2IS DSB ISH ... the existing workaround will expand this to: TLBI ALLE2IS DSB ISH TLBI ALLE2IS // additional DSB ISH // additional ... whereas it is sufficient to have: TLBI ALLE2IS DSB ISH TLBI VALE1IS, XZR // additional DSB ISH // additional As the additional TLBI doesn't have to match a specific earlier TLBI, the additional TLBI can be implemented in separate code, with no memory of the earlier TLBIs. The additional TLBI can also use a cheaper TLBI operation. 5. The existing workaround is applied to both Stage-1 and Stage-2 TLB invalidation, whereas for all relevant errata it is only necessary to apply a workaround for Stage-1 invalidation. Architecturally, TLBI operations which invalidate only Stage-2 information (e.g. IPAS2E1IS) are not required to invalidate TLB entries which combine information from Stage-1 and Stage-2 translation table entries, and consequently may not complete memory accesses translated by those combined entries. In these cases, completion of memory accesses is only guaranteed after subsequent invalidation of Stage-1 information (e.g. VMALLE1IS). Taking the above points into account, this patch reworks the workaround logic to reduce overhead: * New __tlbi_sync_s1ish() and __tlbi_sync_s1ish_hyp() functions are added and used in place of any dsb(ish) which is used to complete broadcast Stage-1 TLB maintenance. When the ARM64_WORKAROUND_REPEAT_TLBI workaround is enabled, these helpers will execute an additional TLBI;DSB sequence. For consistency, it might make sense to add __tlbi_sync_*() helpers for local and stage 2 maintenance. For now I've left those with open-coded dsb() to keep the diff small. * The duplication of TLBIs in __TLBI_0() and __TLBI_1() is removed. This is no longer needed as the necessary synchronization will happen in __tlbi_sync_s1ish() or __tlbi_sync_s1ish_hyp(). * The additional TLBI operation is chosen to have minimal impact: - __tlbi_sync_s1ish() uses "TLBI VALE1IS, XZR". This is only used at EL1 or at EL2 with {E2H,TGE}=={1,1}, where it will target an unused entry for the reserved ASID in the kernel's own translation regime, and have no adverse affect. - __tlbi_sync_s1ish_hyp() uses "TLBI VALE2IS, XZR". This is only used in hyp code, where it will target an unused entry in the hyp code's TTBR0 mapping, and should have no adverse effect. * As __TLBI_0() and __TLBI_1() no longer replace each TLBI with a TLBI;DSB;TLBI sequence, batching TLBIs is worthwhile, and there's no need for arch_tlbbatch_should_defer() to consider ARM64_WORKAROUND_REPEAT_TLBI. When building defconfig with GCC 15.1.0, compared to v6.19-rc1, this patch saves ~1KiB of text, makes the vmlinux ~42KiB smaller, and makes the resulting Image 64KiB smaller: | [mark@lakrids:~/src/linux]% size vmlinux-* | text data bss dec hex filename | 21179831 19660919 708216 41548966 279fca6 vmlinux-after | 21181075 19660903 708216 41550194 27a0172 vmlinux-before | [mark@lakrids:~/src/linux]% ls -l vmlinux-* | -rwxr-xr-x 1 mark mark 157771472 Feb 4 12:05 vmlinux-after | -rwxr-xr-x 1 mark mark 157815432 Feb 4 12:05 vmlinux-before | [mark@lakrids:~/src/linux]% ls -l Image-* | -rw-r--r-- 1 mark mark 41007616 Feb 4 12:05 Image-after | -rw-r--r-- 1 mark mark 41073152 Feb 4 12:05 Image-before Signed-off-by: Mark Rutland Cc: Catalin Marinas Cc: Marc Zyngier Cc: Oliver Upton Cc: Ryan Roberts Cc: Will Deacon Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 609624576b6fd10633b0b83d8edb136ccb38612a Author: Mark Rutland Date: Tue Apr 21 11:00:12 2026 +0100 arm64: tlb: Allow XZR argument to TLBI ops commit bfd9c931d19aa59fb8371d557774fa169b15db9a upstream. The TLBI instruction accepts XZR as a register argument, and for TLBI operations with a register argument, there is no functional difference between using XZR or another GPR which contains zeroes. Operations without a register argument are encoded as if XZR were used. Allow the __TLBI_1() macro to use XZR when a register argument is all zeroes. Today this only results in a trivial code saving in __do_compat_cache_op()'s workaround for Neoverse-N1 erratum #1542419. In subsequent patches this pattern will be used more generally. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland Cc: Catalin Marinas Cc: Marc Zyngier Cc: Oliver Upton Cc: Ryan Roberts Cc: Will Deacon Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 00ce8d6789dae72d042a4522264964c72891ca37 Author: Namjae Jeon Date: Mon Apr 20 12:38:54 2026 -0400 ksmbd: validate owner of durable handle on reconnect [ Upstream commit 49110a8ce654bbe56bef7c5e44cce31f4b102b8a ] Currently, ksmbd does not verify if the user attempting to reconnect to a durable handle is the same user who originally opened the file. This allows any authenticated user to hijack an orphaned durable handle by predicting or brute-forcing the persistent ID. According to MS-SMB2, the server MUST verify that the SecurityContext of the reconnect request matches the SecurityContext associated with the existing open. Add a durable_owner structure to ksmbd_file to store the original opener's UID, GID, and account name. and catpure the owner information when a file handle becomes orphaned. and implementing ksmbd_vfs_compare_durable_owner() to validate the identity of the requester during SMB2_CREATE (DHnC). Fixes: c8efcc786146 ("ksmbd: add support for durable handles v1/v2") Reported-by: Davide Ornaghi Reported-by: Navaneeth K Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3d6682726c2d3a46d31dae88b8166786b09b03ad Author: Namjae Jeon Date: Mon Apr 20 12:38:53 2026 -0400 ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger [ Upstream commit 235e32320a470fcd3998fb3774f2290a0eb302a1 ] When a durable file handle survives session disconnect (TCP close without SMB2_LOGOFF), session_fd_check() sets fp->conn = NULL to preserve the handle for later reconnection. However, it did not clean up the byte-range locks on fp->lock_list. Later, when the durable scavenger thread times out and calls __ksmbd_close_fd(NULL, fp), the lock cleanup loop did: spin_lock(&fp->conn->llist_lock); This caused a slab use-after-free because fp->conn was NULL and the original connection object had already been freed by ksmbd_tcp_disconnect(). The root cause is asymmetric cleanup: lock entries (smb_lock->clist) were left dangling on the freed conn->lock_list while fp->conn was nulled out. To fix this issue properly, we need to handle the lifetime of smb_lock->clist across three paths: - Safely skip clist deletion when list is empty and fp->conn is NULL. - Remove the lock from the old connection's lock_list in session_fd_check() - Re-add the lock to the new connection's lock_list in ksmbd_reopen_durable_fd(). Fixes: c8efcc786146 ("ksmbd: add support for durable handles v1/v2") Co-developed-by: munan Huang Signed-off-by: munan Huang Reviewed-by: ChenXiaoSong Signed-off-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: 49110a8ce654 ("ksmbd: validate owner of durable handle on reconnect") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 377bbec04e167559ee575ff9ff79bb868dc7a00d Author: Tamir Duberstein Date: Mon Apr 20 12:05:50 2026 -0400 scripts: generate_rust_analyzer.py: define scripts [ Upstream commit 36c619f6bd793493294becb10a02fea370b67a91 ] Add IDE support for host-side scripts written in Rust. This support has been missing since these scripts were initially added in commit 9a8ff24ce584 ("scripts: add `generate_rust_target.rs`"), thus add it. Change the existing instance of extension stripping to `pathlib.Path.stem` to maintain code consistency. Fixes: 9a8ff24ce584 ("scripts: add `generate_rust_target.rs`") Cc: stable@vger.kernel.org Reviewed-by: Daniel Almeida Reviewed-by: Fiona Behrens Reviewed-by: Trevor Gross Link: https://patch.msgid.link/20260122-rust-analyzer-scripts-v1-1-ff6ba278170e@kernel.org Signed-off-by: Tamir Duberstein [ changed `[std]` dep to `["std"]` and kept untyped `is_root_crate()` ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 07cbb1bd424370671814a862913c99a6e1441588 Author: Dudu Lu Date: Mon Apr 20 12:40:27 2026 +0800 crypto: krb5enc - fix async decrypt skipping hash verification commit 3bfbf5f0a99c991769ec562721285df7ab69240b upstream. krb5enc_dispatch_decrypt() sets req->base.complete as the skcipher callback, which is the caller's own completion handler. When the skcipher completes asynchronously, this signals "done" to the caller without executing krb5enc_dispatch_decrypt_hash(), completely bypassing the integrity verification (hash check). Compare with the encrypt path which correctly uses krb5enc_encrypt_done as an intermediate callback to chain into the hash computation on async completion. Fix by adding krb5enc_decrypt_done as an intermediate callback that chains into krb5enc_dispatch_decrypt_hash() upon async skcipher completion, matching the encrypt path's callback pattern. Also fix EBUSY/EINPROGRESS handling throughout: remove krb5enc_request_complete() which incorrectly swallowed EINPROGRESS notifications that must be passed up to callers waiting on backlogged requests, and add missing EBUSY checks in krb5enc_encrypt_ahash_done for the dispatch_encrypt return value. Fixes: d1775a177f7f ("crypto: Add 'krb5enc' hash and cipher AEAD algorithm") Signed-off-by: Dudu Lu Signed-off-by: Greg Kroah-Hartman Unset MAY_BACKLOG on the async completion path so the user won't see back-to-back EINPROGRESS notifications. Signed-off-by: Herbert Xu commit 41d151254caa74d6b34cd4c92a5bdc1b3680d5d9 Author: Wesley Atwell Date: Mon Mar 9 00:26:24 2026 -0600 crypto: krb5enc - fix sleepable flag handling in encrypt dispatch commit 2ef3bac16fb5e9eee4fb1d722578a79b751ea58a upstream. krb5enc_encrypt_ahash_done() continues encryption from an ahash completion callback by calling krb5enc_dispatch_encrypt(). That helper takes a flags argument for this continuation path, but it ignored that argument and reused aead_request_flags(req) when setting up the skcipher subrequest callback. This can incorrectly preserve CRYPTO_TFM_REQ_MAY_SLEEP when the encrypt step is started from callback context. Preserve the original request flags but clear CRYPTO_TFM_REQ_MAY_SLEEP for the callback continuation path, and use the caller-supplied flags when setting up the skcipher subrequest. Fixes: d1775a177f7f ("crypto: Add 'krb5enc' hash and cipher AEAD algorithm") Assisted-by: Codex:GPT-5 Signed-off-by: Wesley Atwell Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit b7cddf6c017510cd0c79980ea551e7bcdf0edc7e Author: Mikhail Gavrilov Date: Tue Mar 31 19:21:26 2026 +0500 drm/amdgpu: replace PASID IDR with XArray commit 3c863ff920b45fa7a9b7d4cb932f466488a87a58 upstream. Replace the PASID IDR + spinlock with XArray as noted in the TODO left by commit ea56aa262570 ("drm/amdgpu: fix the idr allocation flags"). The IDR conversion still has an IRQ safety issue: amdgpu_pasid_free() can be called from hardirq context via the fence signal path, but amdgpu_pasid_idr_lock is taken with plain spin_lock() in process context, creating a potential deadlock: CPU0 ---- spin_lock(&amdgpu_pasid_idr_lock) // process context, IRQs on spin_lock(&amdgpu_pasid_idr_lock) // deadlock The hardirq call chain is: sdma_v6_0_process_trap_irq -> amdgpu_fence_process -> dma_fence_signal -> drm_sched_job_done -> dma_fence_signal -> amdgpu_pasid_free_cb -> amdgpu_pasid_free Use XArray with XA_FLAGS_LOCK_IRQ (all xa operations use IRQ-safe locking internally) and XA_FLAGS_ALLOC1 (zero is not a valid PASID). Both xa_alloc_cyclic() and xa_erase() then handle locking consistently, fixing the IRQ safety issue and removing the need for an explicit spinlock. v8: squash in irq safe fix Reviewed-by: Christian König Suggested-by: Lijo Lazar Fixes: ea56aa262570 ("drm/amdgpu: fix the idr allocation flags") Fixes: 8f1de51f49be ("drm/amdgpu: prevent immediate PASID reuse case") Signed-off-by: Mikhail Gavrilov Signed-off-by: Alex Deucher Cc: Thomas Sowell Signed-off-by: Greg Kroah-Hartman commit e97593f32bd57c0ae7bd0a7ab9d183ad8149db81 Author: Daniel Golle Date: Tue Apr 21 16:11:30 2026 +0100 net: ethernet: mtk_eth_soc: initialize PPE per-tag-layer MTU registers commit 2dddb34dd0d07b01fa770eca89480a4da4f13153 upstream. The PPE enforces output frame size limits via per-tag-layer VLAN_MTU registers that the driver never initializes. The hardware defaults do not account for PPPoE overhead, causing the PPE to punt encapsulated frames back to the CPU instead of forwarding them. Initialize the registers at PPE start and on MTU changes using the maximum GMAC MTU. This is a conservative approximation -- the actual per-PPE requirement depends on egress path, but using the global maximum ensures the limits are never too small. Fixes: ba37b7caf1ed2 ("net: ethernet: mtk_eth_soc: add support for initializing the PPE") Signed-off-by: Daniel Golle Link: https://patch.msgid.link/ec995ab8ce8be423267a1cc093147a74d2eb9d82.1775789829.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c5cedee5d97382176573bbe21e1724e737a5eb64 Author: Minhong He Date: Mon Mar 16 15:33:01 2026 +0800 ipv6: add NULL checks for idev in SRv6 paths [ Upstream commit 06413793526251870e20402c39930804f14d59c0 ] __in6_dev_get() can return NULL when the device has no IPv6 configuration (e.g. MTU < IPV6_MIN_MTU or after NETDEV_UNREGISTER). Add NULL checks for idev returned by __in6_dev_get() in both seg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL pointer dereferences. Fixes: 1ababeba4a21 ("ipv6: implement dataplane support for rthdr type 4 (Segment Routing Header)") Fixes: bf355b8d2c30 ("ipv6: sr: add core files for SR HMAC support") Signed-off-by: Minhong He Reviewed-by: Andrea Mayer Link: https://patch.msgid.link/20260316073301.106643-1-heminhong@kylinos.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ecc0eb147806fb64a8f1a354b38a82f5de65a4ca Author: Herbert Xu Date: Wed Apr 15 07:39:06 2026 +0800 crypto: authencesn - Fix src offset when decrypting in-place commit 1f48ad3b19a9dfc947868edda0bb8e48e5b5a8fa upstream. The src SG list offset wasn't set properly when decrypting in-place, fix it. Reported-by: Wolfgang Walter Fixes: e02494114ebf ("crypto: authencesn - Do not place hiseq at end of dst for out-of-place decryption") Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 4e28c6d769e4a01b5a91e9dc9ba3be81e3c5e01c Author: Alexandre Frade Date: Wed Apr 22 18:27:13 2026 +0000 Linux 6.18.24-xanmod1 Signed-off-by: Alexandre Frade commit 89fc24d35ca7b9fafd890ff67cc768bfd5256cff Merge: 5cb6e2637329 c0d886e4af57 Author: Alexandre Frade Date: Wed Apr 22 18:25:57 2026 +0000 Merge tag 'v6.18.24' into 6.18 This is the 6.18.24 stable release commit c0d886e4af574740bcffafda40ae692918ca87f9 Author: Greg Kroah-Hartman Date: Wed Apr 22 13:22:34 2026 +0200 Linux 6.18.24 Link: https://lore.kernel.org/r/20260420153935.605963767@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Brett A C Sheffield Tested-by: Miguel Ojeda Tested-by: Wentao Guan Tested-by: Shuah Khan Tested-by: Pavel Machek (CIP) Tested-by: Barry K. Nathan Signed-off-by: Greg Kroah-Hartman commit ff628171d5f492c636473819ecc912c6f3fb19ce Author: Leon Romanovsky Date: Mon Mar 16 21:06:46 2026 +0200 dma-mapping: handle DMA_ATTR_CPU_CACHE_CLEAN in trace output commit 6f45b1604cf43945ef472ae4ef30354025307c19 upstream. Tracing prints decoded DMA attribute flags, but it does not yet include the recently added DMA_ATTR_CPU_CACHE_CLEAN. Add support for decoding and displaying this attribute in the trace output. Fixes: 61868dc55a11 ("dma-mapping: add DMA_ATTR_CPU_CACHE_CLEAN") Signed-off-by: Leon Romanovsky Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20260316-dma-debug-overlap-v3-2-1dde90a7f08b@nvidia.com Signed-off-by: Greg Kroah-Hartman commit c2d109c982e925d9e67e268604b3e9495541b912 Author: Leon Romanovsky Date: Mon Mar 16 21:06:45 2026 +0200 dma-debug: Allow multiple invocations of overlapping entries commit eca58535b154e6951327319afda94ac80eae7dc3 upstream. Repeated DMA mappings with DMA_ATTR_CPU_CACHE_CLEAN trigger the following splat. This prevents using the attribute in cases where a DMA region is shared and reused more than seven times. ------------[ cut here ]------------ DMA-API: exceeded 7 overlapping mappings of cacheline 0x000000000438c440 WARNING: kernel/dma/debug.c:467 at add_dma_entry+0x219/0x280, CPU#4: ibv_rc_pingpong/1644 Modules linked in: xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay mlx5_fwctl zram zsmalloc mlx5_ib fuse rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_core ib_core CPU: 4 UID: 2733 PID: 1644 Comm: ibv_rc_pingpong Not tainted 6.19.0+ #129 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:add_dma_entry+0x221/0x280 Code: c0 0f 84 f2 fe ff ff 83 e8 01 89 05 6d 99 11 01 e9 e4 fe ff ff 0f 8e 1f ff ff ff 48 8d 3d 07 ef 2d 01 be 07 00 00 00 48 89 e2 <67> 48 0f b9 3a e9 06 ff ff ff 48 c7 c7 98 05 2b 82 c6 05 72 92 28 RSP: 0018:ff1100010e657970 EFLAGS: 00010002 RAX: 0000000000000007 RBX: ff1100010234eb00 RCX: 0000000000000000 RDX: ff1100010e657970 RSI: 0000000000000007 RDI: ffffffff82678660 RBP: 000000000438c440 R08: 0000000000000228 R09: 0000000000000000 R10: 00000000000001be R11: 000000000000089d R12: 0000000000000800 R13: 00000000ffffffef R14: 0000000000000202 R15: ff1100010234eb00 FS: 00007fb15f3f6740(0000) GS:ff110008dcc19000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb15f32d3a0 CR3: 0000000116f59001 CR4: 0000000000373eb0 Call Trace: debug_dma_map_sg+0x1b4/0x390 __dma_map_sg_attrs+0x6d/0x1a0 dma_map_sgtable+0x19/0x30 ib_umem_get+0x284/0x3b0 [ib_uverbs] mlx5_ib_reg_user_mr+0x68/0x2a0 [mlx5_ib] ib_uverbs_reg_mr+0x17f/0x2a0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xc2/0x130 [ib_uverbs] ib_uverbs_cmd_verbs+0xa0b/0xae0 [ib_uverbs] ? ib_uverbs_handler_UVERBS_METHOD_QUERY_PORT_SPEED+0xe0/0xe0 [ib_uverbs] ? mmap_region+0x7a/0xb0 ? do_mmap+0x3b8/0x5c0 ib_uverbs_ioctl+0xa7/0x110 [ib_uverbs] __x64_sys_ioctl+0x14f/0x8b0 ? ksys_mmap_pgoff+0xc5/0x190 do_syscall_64+0x8c/0xbf0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7fb15f5e4eed Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00 RSP: 002b:00007ffe09a5c540 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffe09a5c5d0 RCX: 00007fb15f5e4eed RDX: 00007ffe09a5c5f0 RSI: 00000000c0181b01 RDI: 0000000000000003 RBP: 00007ffe09a5c590 R08: 0000000000000028 R09: 00007ffe09a5c794 R10: 0000000000000001 R11: 0000000000000246 R12: 00007ffe09a5c794 R13: 000000000000000c R14: 0000000025a49170 R15: 000000000000000c ---[ end trace 0000000000000000 ]--- Fixes: 61868dc55a11 ("dma-mapping: add DMA_ATTR_CPU_CACHE_CLEAN") Signed-off-by: Leon Romanovsky Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20260316-dma-debug-overlap-v3-1-1dde90a7f08b@nvidia.com Signed-off-by: Greg Kroah-Hartman commit 574501ede47ac439afd67ba9812bc66722d500ba Author: Jianhui Zhou Date: Tue Mar 10 19:05:26 2026 +0800 mm/userfaultfd: fix hugetlb fault mutex hash calculation commit 0217c7fb4de4a40cee667eb21901f3204effe5ac upstream. In mfill_atomic_hugetlb(), linear_page_index() is used to calculate the page index for hugetlb_fault_mutex_hash(). However, linear_page_index() returns the index in PAGE_SIZE units, while hugetlb_fault_mutex_hash() expects the index in huge page units. This mismatch means that different addresses within the same huge page can produce different hash values, leading to the use of different mutexes for the same huge page. This can cause races between faulting threads, which can corrupt the reservation map and trigger the BUG_ON in resv_map_release(). Fix this by introducing hugetlb_linear_page_index(), which returns the page index in huge page granularity, and using it in place of linear_page_index(). Link: https://lkml.kernel.org/r/20260310110526.335749-1-jianhuizzzzz@gmail.com Fixes: a08c7193e4f1 ("mm/filemap: remove hugetlb special casing in filemap.c") Signed-off-by: Jianhui Zhou Reported-by: syzbot+f525fd79634858f478e7@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f525fd79634858f478e7 Acked-by: SeongJae Park Reviewed-by: David Hildenbrand (Arm) Acked-by: Mike Rapoport (Microsoft) Cc: Jane Chu Cc: Andrea Arcangeli Cc: Hugh Dickins Cc: JonasZhou Cc: Muchun Song Cc: Oscar Salvador Cc: Peter Xu Cc: SeongJae Park Cc: Sidhartha Kumar Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 07e9e674b6146b1f6fc41b1f54b8968bf2802824 Author: Jeongjun Park Date: Sat Jan 10 23:58:29 2026 +0900 media: hackrf: fix to not free memory after the device is registered in hackrf_probe() commit 3b7da2b4d0fe014eff181ed37e3bf832eb8ed258 upstream. In hackrf driver, the following race condition occurs: ``` CPU0 CPU1 hackrf_probe() kzalloc(); // alloc hackrf_dev .... v4l2_device_register(); .... fd = sys_open("/path/to/dev"); // open hackrf fd .... v4l2_device_unregister(); .... kfree(); // free hackrf_dev .... sys_ioctl(fd, ...); v4l2_ioctl(); video_is_registered() // UAF!! .... sys_close(fd); v4l2_release() // UAF!! hackrf_video_release() kfree(); // DFB!! ``` When a V4L2 or video device is unregistered, the device node is removed so new open() calls are blocked. However, file descriptors that are already open-and any in-flight I/O-do not terminate immediately; they remain valid until the last reference is dropped and the driver's release() is invoked. Therefore, freeing device memory on the error path after hackrf_probe() has registered dev it will lead to a race to use-after-free vuln, since those already-open handles haven't been released yet. And since release() free memory too, race to use-after-free and double-free vuln occur. To prevent this, if device is registered from probe(), it should be modified to free memory only through release() rather than calling kfree() directly. Cc: Reported-by: syzbot+6ffd76b5405c006a46b7@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6ffd76b5405c006a46b7 Reported-by: syzbot+f1b20958f93d2d250727@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f1b20958f93d2d250727 Fixes: 8bc4a9ed8504 ("[media] hackrf: add support for transmitter") Signed-off-by: Jeongjun Park Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 6d75a9ec5bdb8cf8382eaf8f8fe831ba7d58a9d4 Author: Abd-Alrhman Masalkhi Date: Sat Feb 21 13:56:18 2026 +0100 media: vidtv: fix pass-by-value structs causing MSAN warnings commit 5f8e73bde67e931468bc2a1860d78d72f0c6ba41 upstream. vidtv_ts_null_write_into() and vidtv_ts_pcr_write_into() take their argument structs by value, causing MSAN to report uninit-value warnings. While only vidtv_ts_null_write_into() has triggered a report so far, both functions share the same issue. Fix by passing both structs by const pointer instead, avoiding the stack copy of the struct along with its MSAN shadow and origin metadata. The functions do not modify the structs, which is enforced by the const qualifier. Fixes: f90cf6079bf67 ("media: vidtv: add a bridge driver") Cc: stable@vger.kernel.org Reported-by: syzbot+96f901260a0b2d29cd1a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=96f901260a0b2d29cd1a Tested-by: syzbot+96f901260a0b2d29cd1a@syzkaller.appspotmail.com Suggested-by: Yihan Ding Signed-off-by: Abd-Alrhman Masalkhi Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit c36e206f302f1ddefed92d09ecbba070e1ae079e Author: Deepanshu Kartikey Date: Tue Mar 31 09:47:21 2026 +0900 nilfs2: fix NULL i_assoc_inode dereference in nilfs_mdt_save_to_shadow_map commit 4a4e0328edd9e9755843787d28f16dd4165f8b48 upstream. The DAT inode's btree node cache (i_assoc_inode) is initialized lazily during btree operations. However, nilfs_mdt_save_to_shadow_map() assumes i_assoc_inode is already initialized when copying dirty pages to the shadow map during GC. If NILFS_IOCTL_CLEAN_SEGMENTS is called immediately after mount before any btree operation has occurred on the DAT inode, i_assoc_inode is NULL leading to a general protection fault. Fix this by calling nilfs_attach_btree_node_cache() on the DAT inode in nilfs_dat_read() at mount time, ensuring i_assoc_inode is always initialized before any GC operation can use it. Reported-by: syzbot+4b4093b1f24ad789bf37@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=4b4093b1f24ad789bf37 Tested-by: syzbot+4b4093b1f24ad789bf37@syzkaller.appspotmail.com Fixes: e897be17a441 ("nilfs2: fix lockdep warnings in page operations for btree nodes") Signed-off-by: Deepanshu Kartikey Signed-off-by: Ryusuke Konishi Cc: stable@vger.kernel.org Signed-off-by: Viacheslav Dubeyko Signed-off-by: Greg Kroah-Hartman commit 09e9206008b887aa553733bd915d73131071a086 Author: Jeongjun Park Date: Sun Jan 11 00:17:53 2026 +0900 media: as102: fix to not free memory after the device is registered in as102_usb_probe() commit 8bd29dbe03fc5b0f039ab2395ff37b64236d2f0c upstream. In as102_usb driver, the following race condition occurs: ``` CPU0 CPU1 as102_usb_probe() kzalloc(); // alloc as102_dev_t .... usb_register_dev(); fd = sys_open("/path/to/dev"); // open as102 fd .... usb_deregister_dev(); .... kfree(); // free as102_dev_t .... sys_close(fd); as102_release() // UAF!! as102_usb_release() kfree(); // DFB!! ``` When a USB character device registered with usb_register_dev() is later unregistered (via usb_deregister_dev() or disconnect), the device node is removed so new open() calls fail. However, file descriptors that are already open do not go away immediately: they remain valid until the last reference is dropped and the driver's .release() is invoked. In as102, as102_usb_probe() calls usb_register_dev() and then, on an error path, does usb_deregister_dev() and frees as102_dev_t right away. If userspace raced a successful open() before the deregistration, that open FD will later hit as102_release() --> as102_usb_release() and access or free as102_dev_t again, occur a race to use-after-free and double-free vuln. The fix is to never kfree(as102_dev_t) directly once usb_register_dev() has succeeded. After deregistration, defer freeing memory to .release(). In other words, let release() perform the last kfree when the final open FD is closed. Cc: Reported-by: syzbot+47321e8fd5a4c84088db@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=47321e8fd5a4c84088db Fixes: cd19f7d3e39b ("[media] as102: fix leaks at failure paths in as102_usb_probe()") Signed-off-by: Jeongjun Park Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 9a9e69155b2091b8297afaf1533b8d68a3096841 Author: Shardul Bankar Date: Tue Apr 14 17:39:44 2026 +0200 wireguard: device: use exit_rtnl callback instead of manual rtnl_lock in pre_exit commit 60a25ef8dacb3566b1a8c4de00572a498e2a3bf9 upstream. wg_netns_pre_exit() manually acquires rtnl_lock() inside the pernet .pre_exit callback. This causes a hung task when another thread holds rtnl_mutex - the cleanup_net workqueue (or the setup_net failure rollback path) blocks indefinitely in wg_netns_pre_exit() waiting to acquire the lock. Convert to .exit_rtnl, introduced in commit 7a60d91c690b ("net: Add ->exit_rtnl() hook to struct pernet_operations."), where the framework already holds RTNL and batches all callbacks under a single rtnl_lock()/rtnl_unlock() pair, eliminating the contention window. The rcu_assign_pointer(wg->creating_net, NULL) is safe to move from .pre_exit to .exit_rtnl (which runs after synchronize_rcu()) because all RCU readers of creating_net either use maybe_get_net() - which returns NULL for a dying namespace with zero refcount - or access net->user_ns which remains valid throughout the entire ops_undo_list sequence. Reported-by: syzbot+f2fbf7478a35a94c8b7c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?id=cb64c22a492202ca929e18262fdb8cb89e635c70 Signed-off-by: Shardul Bankar [ Jason: added __net_exit and __read_mostly annotations that were missing. ] Fixes: 900575aa33a3 ("wireguard: device: avoid circular netns references") Cc: stable@vger.kernel.org Signed-off-by: Jason A. Donenfeld Link: https://patch.msgid.link/20260414153944.2742252-5-Jason@zx2c4.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2d6965581e164fa2ba3f7652ddae5535f6336576 Author: Mingzhe Zou Date: Sun Mar 22 21:41:02 2026 +0800 bcache: fix cached_dev.sb_bio use-after-free and crash commit fec114a98b8735ee89c75216c45a78e28be0f128 upstream. In our production environment, we have received multiple crash reports regarding libceph, which have caught our attention: ``` [6888366.280350] Call Trace: [6888366.280452] blk_update_request+0x14e/0x370 [6888366.280561] blk_mq_end_request+0x1a/0x130 [6888366.280671] rbd_img_handle_request+0x1a0/0x1b0 [rbd] [6888366.280792] rbd_obj_handle_request+0x32/0x40 [rbd] [6888366.280903] __complete_request+0x22/0x70 [libceph] [6888366.281032] osd_dispatch+0x15e/0xb40 [libceph] [6888366.281164] ? inet_recvmsg+0x5b/0xd0 [6888366.281272] ? ceph_tcp_recvmsg+0x6f/0xa0 [libceph] [6888366.281405] ceph_con_process_message+0x79/0x140 [libceph] [6888366.281534] ceph_con_v1_try_read+0x5d7/0xf30 [libceph] [6888366.281661] ceph_con_workfn+0x329/0x680 [libceph] ``` After analyzing the coredump file, we found that the address of dc->sb_bio has been freed. We know that cached_dev is only freed when it is stopped. Since sb_bio is a part of struct cached_dev, rather than an alloc every time. If the device is stopped while writing to the superblock, the released address will be accessed at endio. This patch hopes to wait for sb_write to complete in cached_dev_free. It should be noted that we analyzed the cause of the problem, then tell all details to the QWEN and adopted the modifications it made. Signed-off-by: Mingzhe Zou Fixes: cafe563591446 ("bcache: A block layer cache") Cc: stable@vger.kernel.org # 3.10+ Signed-off-by: Coly Li Link: https://patch.msgid.link/20260322134102.480107-1-colyli@fnnas.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit d21e8a2af4869b5890b34e081d5aeadc93e9cd5c Author: Berk Cem Goksel Date: Fri Apr 10 08:13:41 2026 +0300 ALSA: 6fire: fix use-after-free on disconnect commit b9c826916fdce6419b94eb0cd8810fdac18c2386 upstream. In usb6fire_chip_abort(), the chip struct is allocated as the card's private data (via snd_card_new with sizeof(struct sfire_chip)). When snd_card_free_when_closed() is called and no file handles are open, the card and embedded chip are freed synchronously. The subsequent chip->card = NULL write then hits freed slab memory. Call trace: usb6fire_chip_abort sound/usb/6fire/chip.c:59 [inline] usb6fire_chip_disconnect+0x348/0x358 sound/usb/6fire/chip.c:182 usb_unbind_interface+0x1a8/0x88c drivers/usb/core/driver.c:458 ... hub_event+0x1a04/0x4518 drivers/usb/core/hub.c:5953 Fix by moving the card lifecycle out of usb6fire_chip_abort() and into usb6fire_chip_disconnect(). The card pointer is saved in a local before any teardown, snd_card_disconnect() is called first to prevent new opens, URBs are aborted while chip is still valid, and snd_card_free_when_closed() is called last so chip is never accessed after the card may be freed. Fixes: a0810c3d6dd2 ("ALSA: 6fire: Release resources at card release") Cc: stable@vger.kernel.org Cc: Andrey Konovalov Signed-off-by: Berk Cem Goksel Link: https://patch.msgid.link/20260410051341.1069716-1-berkcgoksel@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9e1b798257f96d2e2a2639830eb71add545ce749 Author: Sanman Pradhan Date: Fri Apr 10 00:25:35 2026 +0000 hwmon: (powerz) Fix use-after-free on USB disconnect commit 08e57f5e1a9067d5fbf33993aa7f51d60b3d13a4 upstream. After powerz_disconnect() frees the URB and releases the mutex, a subsequent powerz_read() call can acquire the mutex and call powerz_read_data(), which dereferences the freed URB pointer. Fix by: - Setting priv->urb to NULL in powerz_disconnect() so that powerz_read_data() can detect the disconnected state. - Adding a !priv->urb check at the start of powerz_read_data() to return -ENODEV on a disconnected device. - Moving usb_set_intfdata() before hwmon registration so the disconnect handler can always find the priv pointer. Fixes: 4381a36abdf1c ("hwmon: add POWER-Z driver") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan Link: https://lore.kernel.org/r/20260410002521.422645-2-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 871b8ea8ef39a6c253594649f4339378fad3d0dd Author: Abhishek Kumar Date: Tue Mar 10 22:14:37 2026 +0530 media: em28xx: fix use-after-free in em28xx_v4l2_open() commit a66485a934c7187ae8e36517d40615fa2e961cff upstream. em28xx_v4l2_open() reads dev->v4l2 without holding dev->lock, creating a race with em28xx_v4l2_init()'s error path and em28xx_v4l2_fini(), both of which free the em28xx_v4l2 struct and set dev->v4l2 to NULL under dev->lock. This race leads to two issues: - use-after-free in v4l2_fh_init() when accessing vdev->ctrl_handler, since the video_device is embedded in the freed em28xx_v4l2 struct. - NULL pointer dereference in em28xx_resolution_set() when accessing v4l2->norm, since dev->v4l2 has been set to NULL. Fix this by moving the mutex_lock() before the dev->v4l2 read and adding a NULL check for dev->v4l2 under the lock. Reported-by: syzbot+c025d34b8eaa54c571b8@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c025d34b8eaa54c571b8 Fixes: 8139a4d583ab ("[media] em28xx: move v4l2 user counting fields from struct em28xx to struct v4l2") Cc: stable@vger.kernel.org Signed-off-by: Abhishek Kumar Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit f99353cd0e9f58bf17889049137b8d65fb44ebf1 Author: Fan Wu Date: Wed Mar 4 09:35:06 2026 +0000 media: mediatek: vcodec: fix use-after-free in encoder release path commit 76e35091ffc722ba39b303e48bc5d08abb59dd56 upstream. The fops_vcodec_release() function frees the context structure (ctx) without first cancelling any pending or running work in ctx->encode_work. This creates a race window where the workqueue handler (mtk_venc_worker) may still be accessing the context memory after it has been freed. Race condition: CPU 0 (release path) CPU 1 (workqueue) --------------------- ------------------ fops_vcodec_release() v4l2_m2m_ctx_release() v4l2_m2m_cancel_job() // waits for m2m job "done" mtk_venc_worker() v4l2_m2m_job_finish() // m2m job "done" // BUT worker still running! // post-job_finish access: other ctx dereferences // UAF if ctx already freed // returns (job "done") kfree(ctx) // ctx freed Root cause: The v4l2_m2m_ctx_release() only waits for the m2m job lifecycle (via TRANS_RUNNING flag), not the workqueue lifecycle. After v4l2_m2m_job_finish() is called, the m2m framework considers the job complete and v4l2_m2m_ctx_release() returns, but the worker function continues executing and may still access ctx. The work is queued during encode operations via: queue_work(ctx->dev->encode_workqueue, &ctx->encode_work) The worker function accesses ctx->m2m_ctx, ctx->dev, and other ctx fields even after calling v4l2_m2m_job_finish(). This vulnerability was confirmed with KASAN by running an instrumented test module that widens the post-job_finish race window. KASAN detected: BUG: KASAN: slab-use-after-free in mtk_venc_worker+0x159/0x180 Read of size 4 at addr ffff88800326e000 by task kworker/u8:0/12 Workqueue: mtk_vcodec_enc_wq mtk_venc_worker Allocated by task 47: __kasan_kmalloc+0x7f/0x90 fops_vcodec_open+0x85/0x1a0 Freed by task 47: __kasan_slab_free+0x43/0x70 kfree+0xee/0x3a0 fops_vcodec_release+0xb7/0x190 Fix this by calling cancel_work_sync(&ctx->encode_work) before kfree(ctx). This ensures the workqueue handler is both cancelled (if pending) and synchronized (waits for any running handler to complete) before the context is freed. Placement rationale: The fix is placed after v4l2_ctrl_handler_free() and before list_del_init(&ctx->list). At this point, all m2m operations are done (v4l2_m2m_ctx_release() has returned), and we need to ensure the workqueue is synchronized before removing ctx from the list and freeing it. Note: The open error path does NOT need cancel_work_sync() because INIT_WORK() only initializes the work structure - it does not schedule it. Work is only scheduled later during device_run() operations. Fixes: 0934d3759615 ("media: mediatek: vcodec: separate decoder and encoder") Cc: stable@vger.kernel.org Signed-off-by: Fan Wu Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 25f19e476ab15defe698504212899fdb9f7cd61b Author: Ruslan Valiyev Date: Sun Mar 1 21:07:35 2026 +0000 media: vidtv: fix nfeeds state corruption on start_streaming failure commit a0e5a598fe9a4612b852406b51153b881592aede upstream. syzbot reported a memory leak in vidtv_psi_service_desc_init [1]. When vidtv_start_streaming() fails inside vidtv_start_feed(), the nfeeds counter is left incremented even though no feed was actually started. This corrupts the driver state: subsequent start_feed calls see nfeeds > 1 and skip starting the mux, while stop_feed calls eventually try to stop a non-existent stream. This state corruption can also lead to memory leaks, since the mux and channel resources may be partially allocated during a failed start_streaming but never cleaned up, as the stop path finds dvb->streaming == false and returns early. Fix by decrementing nfeeds back when start_streaming fails, keeping the counter in sync with the actual number of active feeds. [1] BUG: memory leak unreferenced object 0xffff888145b50820 (size 32): comm "syz.0.17", pid 6068, jiffies 4294944486 backtrace (crc 90a0c7d4): vidtv_psi_service_desc_init+0x74/0x1b0 drivers/media/test-drivers/vidtv/vidtv_psi.c:288 vidtv_channel_s302m_init+0xb1/0x2a0 drivers/media/test-drivers/vidtv/vidtv_channel.c:83 vidtv_channels_init+0x1b/0x40 drivers/media/test-drivers/vidtv/vidtv_channel.c:524 vidtv_mux_init+0x516/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:518 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline] vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239 Fixes: f90cf6079bf67 ("media: vidtv: add a bridge driver") Cc: stable@vger.kernel.org Reported-by: syzbot+639ebc6ec75e96674741@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=639ebc6ec75e96674741 Signed-off-by: Ruslan Valiyev Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit ea3af09eb87d8f8708c66747fcf1a2762902e839 Author: Breno Leitao Date: Mon Apr 13 03:09:19 2026 -0700 mm: blk-cgroup: fix use-after-free in cgwb_release_workfn() commit 8f5857be99f1ed1fa80991c72449541f634626ee upstream. cgwb_release_workfn() calls css_put(wb->blkcg_css) and then later accesses wb->blkcg_css again via blkcg_unpin_online(). If css_put() drops the last reference, the blkcg can be freed asynchronously (css_free_rwork_fn -> blkcg_css_free -> kfree) before blkcg_unpin_online() dereferences the pointer to access blkcg->online_pin, resulting in a use-after-free: BUG: KASAN: slab-use-after-free in blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) Write of size 4 at addr ff11000117aa6160 by task kworker/71:1/531 Workqueue: cgwb_release cgwb_release_workfn Call Trace: blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) cgwb_release_workfn (mm/backing-dev.c:629) process_scheduled_works (kernel/workqueue.c:3278 kernel/workqueue.c:3385) Freed by task 1016: kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6246 mm/slub.c:6561) css_free_rwork_fn (kernel/cgroup/cgroup.c:5542) process_scheduled_works (kernel/workqueue.c:3302 kernel/workqueue.c:3385) ** Stack based on commit 66672af7a095 ("Add linux-next specific files for 20260410") I am seeing this crash sporadically in Meta fleet across multiple kernel versions. A full reproducer is available at: https://github.com/leitao/debug/blob/main/reproducers/repro_blkcg_uaf.sh (The race window is narrow. To make it easily reproducible, inject a msleep(100) between css_put() and blkcg_unpin_online() in cgwb_release_workfn(). With that delay and a KASAN-enabled kernel, the reproducer triggers the splat reliably in less than a second.) Fix this by moving blkcg_unpin_online() before css_put(), so the cgwb's CSS reference keeps the blkcg alive while blkcg_unpin_online() accesses it. Link: https://lore.kernel.org/20260413-blkcg-v1-1-35b72622d16c@debian.org Fixes: 59b57717fff8 ("blkcg: delay blkg destruction until after writeback has finished") Signed-off-by: Breno Leitao Reviewed-by: Dennis Zhou Reviewed-by: Shakeel Butt Cc: David Hildenbrand Cc: Jens Axboe Cc: Johannes Weiner Cc: Josef Bacik Cc: JP Kobryn Cc: Liam Howlett Cc: Lorenzo Stoakes (Oracle) Cc: Martin KaFai Lau Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Tejun Heo Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit f6204f7ff6aff62ce6242a76982c5ba3a9ded707 Author: Ritesh Harjani (IBM) Date: Tue Feb 24 18:53:16 2026 +0530 mm/kasan: fix double free for kasan pXds commit 51d8c78be0c27ddb91bc2c0263941d8b30a47d3b upstream. kasan_free_pxd() assumes the page table is always struct page aligned. But that's not always the case for all architectures. E.g. In case of powerpc with 64K pagesize, PUD table (of size 4096) comes from slab cache named pgtable-2^9. Hence instead of page_to_virt(pxd_page()) let's just directly pass the start of the pxd table which is passed as the 1st argument. This fixes the below double free kasan issue seen with PMEM: radix-mmu: Mapped 0x0000047d10000000-0x0000047f90000000 with 2.00 MiB pages ================================================================== BUG: KASAN: double-free in kasan_remove_zero_shadow+0x9c4/0xa20 Free of addr c0000003c38e0000 by task ndctl/2164 CPU: 34 UID: 0 PID: 2164 Comm: ndctl Not tainted 6.19.0-rc1-00048-gea1013c15392 #157 VOLUNTARY Hardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_012) hv:phyp pSeries Call Trace: dump_stack_lvl+0x88/0xc4 (unreliable) print_report+0x214/0x63c kasan_report_invalid_free+0xe4/0x110 check_slab_allocation+0x100/0x150 kmem_cache_free+0x128/0x6e0 kasan_remove_zero_shadow+0x9c4/0xa20 memunmap_pages+0x2b8/0x5c0 devm_action_release+0x54/0x70 release_nodes+0xc8/0x1a0 devres_release_all+0xe0/0x140 device_unbind_cleanup+0x30/0x120 device_release_driver_internal+0x3e4/0x450 unbind_store+0xfc/0x110 drv_attr_store+0x78/0xb0 sysfs_kf_write+0x114/0x140 kernfs_fop_write_iter+0x264/0x3f0 vfs_write+0x3bc/0x7d0 ksys_write+0xa4/0x190 system_call_exception+0x190/0x480 system_call_vectored_common+0x15c/0x2ec ---- interrupt: 3000 at 0x7fff93b3d3f4 NIP: 00007fff93b3d3f4 LR: 00007fff93b3d3f4 CTR: 0000000000000000 REGS: c0000003f1b07e80 TRAP: 3000 Not tainted (6.19.0-rc1-00048-gea1013c15392) MSR: 800000000280f033 CR: 48888208 XER: 00000000 <...> NIP [00007fff93b3d3f4] 0x7fff93b3d3f4 LR [00007fff93b3d3f4] 0x7fff93b3d3f4 ---- interrupt: 3000 The buggy address belongs to the object at c0000003c38e0000 which belongs to the cache pgtable-2^9 of size 4096 The buggy address is located 0 bytes inside of 4096-byte region [c0000003c38e0000, c0000003c38e1000) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x3c38c head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 memcg:c0000003bfd63e01 flags: 0x63ffff800000040(head|node=6|zone=0|lastcpupid=0x7ffff) page_type: f5(slab) raw: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 head: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 head: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 head: 063ffff800000002 c00c000000f0e301 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected [ 138.953636] [ T2164] Memory state around the buggy address: [ 138.953643] [ T2164] c0000003c38dff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953652] [ T2164] c0000003c38dff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953661] [ T2164] >c0000003c38e0000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953669] [ T2164] ^ [ 138.953675] [ T2164] c0000003c38e0080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953684] [ T2164] c0000003c38e0100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953692] [ T2164] ================================================================== [ 138.953701] [ T2164] Disabling lock debugging due to kernel taint Link: https://lkml.kernel.org/r/2f9135c7866c6e0d06e960993b8a5674a9ebc7ec.1771938394.git.ritesh.list@gmail.com Fixes: 0207df4fa1a8 ("kernel/memremap, kasan: make ZONE_DEVICE with work with KASAN") Signed-off-by: Ritesh Harjani (IBM) Reported-by: Venkat Rao Bagalkote Reviewed-by: Alexander Potapenko Cc: Andrey Konovalov Cc: Andrey Ryabinin Cc: Dmitry Vyukov Cc: "Ritesh Harjani (IBM)" Cc: Vincenzo Frascino Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 30383b7780ffa140bc124de5b66cae7c84133dbb Author: Srinivas Kandagatla Date: Thu Apr 2 08:11:06 2026 +0000 ASoC: qcom: q6apm: move component registration to unmanaged version commit 6ec1235fc941dac6c011b30ee01d9220ff87e0cd upstream. q6apm component registers dais dynamically from ASoC toplology, which are allocated using device managed version apis. Allocating both component and dynamic dais using managed version could lead to incorrect free ordering, dai will be freed while component still holding references to it. Fix this issue by moving component to unmanged version so that the dai pointers are only freeded after the component is removed. ================================================================== BUG: KASAN: slab-use-after-free in snd_soc_del_component_unlocked+0x3d4/0x400 [snd_soc_core] Read of size 8 at addr ffff00084493a6e8 by task kworker/u48:0/3426 Tainted: [W]=WARN Hardware name: LENOVO 21N2ZC5PUS/21N2ZC5PUS, BIOS N42ET57W (1.31 ) 08/08/2024 Workqueue: pdr_notifier_wq pdr_notifier_work [pdr_interface] Call trace: show_stack+0x28/0x7c (C) dump_stack_lvl+0x60/0x80 print_report+0x160/0x4b4 kasan_report+0xac/0xfc __asan_report_load8_noabort+0x20/0x34 snd_soc_del_component_unlocked+0x3d4/0x400 [snd_soc_core] snd_soc_unregister_component_by_driver+0x50/0x88 [snd_soc_core] devm_component_release+0x30/0x5c [snd_soc_core] devres_release_all+0x13c/0x210 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x350/0x468 device_release_driver+0x18/0x30 bus_remove_device+0x1a0/0x35c device_del+0x314/0x7f0 device_unregister+0x20/0xbc apr_remove_device+0x5c/0x7c [apr] device_for_each_child+0xd8/0x160 apr_pd_status+0x7c/0xa8 [apr] pdr_notifier_work+0x114/0x240 [pdr_interface] process_one_work+0x500/0xb70 worker_thread+0x630/0xfb0 kthread+0x370/0x6c0 ret_from_fork+0x10/0x20 Allocated by task 77: kasan_save_stack+0x40/0x68 kasan_save_track+0x20/0x40 kasan_save_alloc_info+0x44/0x58 __kasan_kmalloc+0xbc/0xdc __kmalloc_node_track_caller_noprof+0x1f4/0x620 devm_kmalloc+0x7c/0x1c8 snd_soc_register_dai+0x50/0x4f0 [snd_soc_core] soc_tplg_pcm_elems_load+0x55c/0x1eb8 [snd_soc_core] snd_soc_tplg_component_load+0x4f8/0xb60 [snd_soc_core] audioreach_tplg_init+0x124/0x1fc [snd_q6apm] q6apm_audio_probe+0x10/0x1c [snd_q6apm] snd_soc_component_probe+0x5c/0x118 [snd_soc_core] soc_probe_component+0x44c/0xaf0 [snd_soc_core] snd_soc_bind_card+0xad0/0x2370 [snd_soc_core] snd_soc_register_card+0x3b0/0x4c0 [snd_soc_core] devm_snd_soc_register_card+0x50/0xc8 [snd_soc_core] x1e80100_platform_probe+0x208/0x368 [snd_soc_x1e80100] platform_probe+0xc0/0x188 really_probe+0x188/0x804 __driver_probe_device+0x158/0x358 driver_probe_device+0x60/0x190 __device_attach_driver+0x16c/0x2a8 bus_for_each_drv+0x100/0x194 __device_attach+0x174/0x380 device_initial_probe+0x14/0x20 bus_probe_device+0x124/0x154 deferred_probe_work_func+0x140/0x220 process_one_work+0x500/0xb70 worker_thread+0x630/0xfb0 kthread+0x370/0x6c0 ret_from_fork+0x10/0x20 Freed by task 3426: kasan_save_stack+0x40/0x68 kasan_save_track+0x20/0x40 __kasan_save_free_info+0x4c/0x80 __kasan_slab_free+0x78/0xa0 kfree+0x100/0x4a4 devres_release_all+0x144/0x210 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x350/0x468 device_release_driver+0x18/0x30 bus_remove_device+0x1a0/0x35c device_del+0x314/0x7f0 device_unregister+0x20/0xbc apr_remove_device+0x5c/0x7c [apr] device_for_each_child+0xd8/0x160 apr_pd_status+0x7c/0xa8 [apr] pdr_notifier_work+0x114/0x240 [pdr_interface] process_one_work+0x500/0xb70 worker_thread+0x630/0xfb0 kthread+0x370/0x6c0 ret_from_fork+0x10/0x20 Fixes: 5477518b8a0e ("ASoC: qdsp6: audioreach: add q6apm support") Cc: Stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260402081118.348071-2-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 22d2ff69d487a32a8b88f9c970120fc2daa08a77 Author: Sean Christopherson Date: Tue Feb 24 17:20:36 2026 -0800 KVM: x86: Use scratch field in MMIO fragment to hold small write values commit 0b16e69d17d8c35c5c9d5918bf596c75a44655d3 upstream. When exiting to userspace to service an emulated MMIO write, copy the to-be-written value to a scratch field in the MMIO fragment if the size of the data payload is 8 bytes or less, i.e. can fit in a single chunk, instead of pointing the fragment directly at the source value. This fixes a class of use-after-free bugs that occur when the emulator initiates a write using an on-stack, local variable as the source, the write splits a page boundary, *and* both pages are MMIO pages. Because KVM's ABI only allows for physically contiguous MMIO requests, accesses that split MMIO pages are separated into two fragments, and are sent to userspace one at a time. When KVM attempts to complete userspace MMIO in response to KVM_RUN after the first fragment, KVM will detect the second fragment and generate a second userspace exit, and reference the on-stack variable. The issue is most visible if the second KVM_RUN is performed by a separate task, in which case the stack of the initiating task can show up as truly freed data. ================================================================== BUG: KASAN: use-after-free in complete_emulated_mmio+0x305/0x420 Read of size 1 at addr ffff888009c378d1 by task syz-executor417/984 CPU: 1 PID: 984 Comm: syz-executor417 Not tainted 5.10.0-182.0.0.95.h2627.eulerosv2r13.x86_64 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack+0xbe/0xfd print_address_description.constprop.0+0x19/0x170 __kasan_report.cold+0x6c/0x84 kasan_report+0x3a/0x50 check_memory_region+0xfd/0x1f0 memcpy+0x20/0x60 complete_emulated_mmio+0x305/0x420 kvm_arch_vcpu_ioctl_run+0x63f/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscall_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 RIP: 0033:0x42477d Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007faa8e6890e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000004d7338 RCX: 000000000042477d RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005 RBP: 00000000004d7330 R08: 00007fff28d546df R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004d733c R13: 0000000000000000 R14: 000000000040a200 R15: 00007fff28d54720 The buggy address belongs to the page: page:0000000029f6a428 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9c37 flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0000000 0000000000000000 ffffea0000270dc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888009c37780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff888009c37880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff888009c37900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== The bug can also be reproduced with a targeted KVM-Unit-Test by hacking KVM to fill a large on-stack variable in complete_emulated_mmio(), i.e. by overwrite the data value with garbage. Limit the use of the scratch fields to 8-byte or smaller accesses, and to just writes, as larger accesses and reads are not affected thanks to implementation details in the emulator, but add a sanity check to ensure those details don't change in the future. Specifically, KVM never uses on-stack variables for accesses larger that 8 bytes, e.g. uses an operand in the emulator context, and *all* reads are buffered through the mem_read cache. Note! Using the scratch field for reads is not only unnecessary, it's also extremely difficult to handle correctly. As above, KVM buffers all reads through the mem_read cache, and heavily relies on that behavior when re-emulating the instruction after a userspace MMIO read exit. If a read splits a page, the first page is NOT an MMIO page, and the second page IS an MMIO page, then the MMIO fragment needs to point at _just_ the second chunk of the destination, i.e. its position in the mem_read cache. Taking the "obvious" approach of copying the fragment value into the destination when re-emulating the instruction would clobber the first chunk of the destination, i.e. would clobber the data that was read from guest memory. Fixes: f78146b0f923 ("KVM: Fix page-crossing MMIO") Suggested-by: Yashu Zhang Reported-by: Yashu Zhang Closes: https://lore.kernel.org/all/369eaaa2b3c1425c85e8477066391bc7@huawei.com Cc: stable@vger.kernel.org Tested-by: Tom Lendacky Tested-by: Rick Edgecombe Link: https://patch.msgid.link/20260225012049.920665-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 576d365f31d9beea188a94eab72acecf0558542b Author: Linus Torvalds Date: Mon Mar 30 14:52:45 2026 -0700 x86-64/arm64/powerpc: clean up and rename __copy_from_user_flushcache commit 809b997a5ce945ab470f70c187048fe4f5df20bf upstream. This finishes the work on these odd functions that were only implemented by a handful of architectures. The 'flushcache' function was only used from the iterator code, and let's make it do the same thing that the nontemporal version does: remove the two underscores and add the user address checking. Yes, yes, the user address checking is also done at iovec import time, but we have long since walked away from the old double-underscore thing where we try to avoid address checking overhead at access time, and these functions shouldn't be so special and old-fashioned. The arm64 version already did the address check, in fact, so there it's just a matter of renaming it. For powerpc and x86-64 we now do the proper user access boilerplate. Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 03fd014cd9f3a3d173740ab9c5cbede82fd6322c Author: Linus Torvalds Date: Mon Mar 30 13:11:07 2026 -0700 x86: rename and clean up __copy_from_user_inatomic_nocache() commit 5de7bcaadf160c1716b20a263cf8f5b06f658959 upstream. Similarly to the previous commit, this renames the somewhat confusingly named function. But in this case, it was at least less confusing: the __copy_from_user_inatomic_nocache is indeed copying from user memory, and it is indeed ok to be used in an atomic context, so it will not warn about it. But the previous commit also removed the NTB mis-use of the __copy_from_user_inatomic_nocache() function, and as a result every call-site is now _actually_ doing a real user copy. That means that we can now do the proper user pointer verification too. End result: add proper address checking, remove the double underscores, and change the "nocache" to "nontemporal" to more accurately describe what this x86-only function actually does. It might be worth noting that only the target is non-temporal: the actual user accesses are normal memory accesses. Also worth noting is that non-x86 targets (and on older 32-bit x86 CPU's before XMM2 in the Pentium III) we end up just falling back on a regular user copy, so nothing can actually depend on the non-temporal semantics, but that has always been true. Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c6d4e0599e7e73abc04e2488dfeb7940c4039660 Author: Linus Torvalds Date: Mon Mar 30 10:39:09 2026 -0700 x86-64: rename misleadingly named '__copy_user_nocache()' function commit d187a86de793f84766ea40b9ade7ac60aabbb4fe upstream. This function was a masterclass in bad naming, for various historical reasons. It claimed to be a non-cached user copy. It is literally _neither_ of those things. It's a specialty memory copy routine that uses non-temporal stores for the destination (but not the source), and that does exception handling for both source and destination accesses. Also note that while it works for unaligned targets, any unaligned parts (whether at beginning or end) will not use non-temporal stores, since only words and quadwords can be non-temporal on x86. The exception handling means that it _can_ be used for user space accesses, but not on its own - it needs all the normal "start user space access" logic around it. But typically the user space access would be the source, not the non-temporal destination. That was the original intention of this, where the destination was some fragile persistent memory target that needed non-temporal stores in order to catch machine check exceptions synchronously and deal with them gracefully. Thus that non-descriptive name: one use case was to copy from user space into a non-cached kernel buffer. However, the existing users are a mix of that intended use-case, and a couple of random drivers that just did this as a performance tweak. Some of those random drivers then actively misused the user copying version (with STAC/CLAC and all) to do kernel copies without ever even caring about the exception handling, _just_ for the non-temporal destination. Rename it as a first small step to actually make it halfway sane, and change the prototype to be more normal: it doesn't take a user pointer unless the caller has done the proper conversion, and the argument size is the full size_t (it still won't actually copy more than 4GB in one go, but there's also no reason to silently truncate the size argument in the caller). Finally, use this now sanely named function in the NTB code, which mis-used a user copy version (with STAC/CLAC and all) of this interface despite it not actually being a user copy at all. Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 8e7666acfabbc7230f14cc6dd92291fe4faa5ce8 Author: Sasha Levin Date: Wed Mar 11 17:58:17 2026 -0400 checkpatch: add support for Assisted-by tag commit d1db4118489fffd2b2f612140b7acbb477880839 upstream. The Assisted-by tag was introduced in Documentation/process/coding-assistants.rst for attributing AI tool contributions to kernel patches. However, checkpatch.pl did not recognize this tag, causing two issues: WARNING: Non-standard signature: Assisted-by: ERROR: Unrecognized email address: 'AGENT_NAME:MODEL_VERSION' Fix this by: 1. Adding Assisted-by to the recognized $signature_tags list 2. Skipping email validation for Assisted-by lines since they use the AGENT_NAME:MODEL_VERSION format instead of an email address 3. Warning when the Assisted-by value doesn't match the expected format Link: https://lkml.kernel.org/r/20260311215818.518930-1-sashal@kernel.org Signed-off-by: Sasha Levin Reported-by: Bart Van Assche Acked-by: Joe Perches Cc: Andy Whitcroft Cc: Dwaipayan Ray Cc: Jonathan Corbet Cc: Lukas Bulwahn Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 0c1af902223b6fcedb60904ca0b551254686c7b9 Author: Joseph Qi Date: Mon Apr 13 11:19:58 2026 -0400 ocfs2: fix out-of-bounds write in ocfs2_write_end_inline [ Upstream commit 7bc5da4842bed3252d26e742213741a4d0ac1b14 ] KASAN reports a use-after-free write of 4086 bytes in ocfs2_write_end_inline, called from ocfs2_write_end_nolock during a copy_file_range splice fallback on a corrupted ocfs2 filesystem mounted on a loop device. The actual bug is an out-of-bounds write past the inode block buffer, not a true use-after-free. The write overflows into an adjacent freed page, which KASAN reports as UAF. The root cause is that ocfs2_try_to_write_inline_data trusts the on-disk id_count field to determine whether a write fits in inline data. On a corrupted filesystem, id_count can exceed the physical maximum inline data capacity, causing writes to overflow the inode block buffer. Call trace (crash path): vfs_copy_file_range (fs/read_write.c:1634) do_splice_direct splice_direct_to_actor iter_file_splice_write ocfs2_file_write_iter generic_perform_write ocfs2_write_end ocfs2_write_end_nolock (fs/ocfs2/aops.c:1949) ocfs2_write_end_inline (fs/ocfs2/aops.c:1915) memcpy_from_folio <-- KASAN: write OOB So add id_count upper bound check in ocfs2_validate_inode_block() to alongside the existing i_size check to fix it. Link: https://lkml.kernel.org/r/20260403063830.3662739-1-joseph.qi@linux.alibaba.com Signed-off-by: Joseph Qi Reported-by: syzbot+62c1793956716ea8b28a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=62c1793956716ea8b28a 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: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cd2d765aa7157f852999842af32148128c735d39 Author: Deepanshu Kartikey Date: Mon Apr 13 11:19:57 2026 -0400 ocfs2: validate inline data i_size during inode read [ Upstream commit 1524af3685b35feac76662cc551cbc37bd14775f ] When reading an inode from disk, ocfs2_validate_inode_block() performs various sanity checks but does not validate the size of inline data. If the filesystem is corrupted, an inode's i_size can exceed the actual inline data capacity (id_count). This causes ocfs2_dir_foreach_blk_id() to iterate beyond the inline data buffer, triggering a use-after-free when accessing directory entries from freed memory. In the syzbot report: - i_size was 1099511627576 bytes (~1TB) - Actual inline data capacity (id_count) is typically <256 bytes - A garbage rec_len (54648) caused ctx->pos to jump out of bounds - This triggered a UAF in ocfs2_check_dir_entry() Fix by adding a validation check in ocfs2_validate_inode_block() to ensure inodes with inline data have i_size <= id_count. This catches the corruption early during inode read and prevents all downstream code from operating on invalid data. Link: https://lkml.kernel.org/r/20251212052132.16750-1-kartikey406@gmail.com Signed-off-by: Deepanshu Kartikey Reported-by: syzbot+c897823f699449cc3eb4@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c897823f699449cc3eb4 Tested-by: syzbot+c897823f699449cc3eb4@syzkaller.appspotmail.com Link: https://lore.kernel.org/all/20251211115231.3560028-1-kartikey406@gmail.com/T/ [v1] Link: https://lore.kernel.org/all/20251212040400.6377-1-kartikey406@gmail.com/T/ [v2] 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 Stable-dep-of: 7bc5da4842be ("ocfs2: fix out-of-bounds write in ocfs2_write_end_inline") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit df030a9374a5fe2c83a75e829dbc02de4be9a78d Author: Dmitry Antipov Date: Mon Apr 13 11:19:56 2026 -0400 ocfs2: add inline inode consistency check to ocfs2_validate_inode_block() [ Upstream commit a2b1c419ff72ec62ff5831684e30cd1d4f0b09ee ] In 'ocfs2_validate_inode_block()', add an extra check whether an inode with inline data (i.e. self-contained) has no clusters, thus preventing an invalid inode from being passed to 'ocfs2_evict_inode()' and below. Link: https://lkml.kernel.org/r/20251023141650.417129-1-dmantipov@yandex.ru Signed-off-by: Dmitry Antipov Reported-by: syzbot+c16daba279a1161acfb0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c16daba279a1161acfb0 Reviewed-by: Joseph Qi Cc: 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 Stable-dep-of: 7bc5da4842be ("ocfs2: fix out-of-bounds write in ocfs2_write_end_inline") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0ed88ac9bc64120cdb3f0915a3dead673720ba08 Author: David Woodhouse Date: Mon Apr 13 09:01:25 2026 -0400 KVM: x86: Use __DECLARE_FLEX_ARRAY() for UAPI structures with VLAs [ Upstream commit 2619da73bb2f10d88f7e1087125c40144fdf0987 ] Commit 94dfc73e7cf4 ("treewide: uapi: Replace zero-length arrays with flexible-array members") broke the userspace API for C++. These structures ending in VLAs are typically a *header*, which can be followed by an arbitrary number of entries. Userspace typically creates a larger structure with some non-zero number of entries, for example in QEMU's kvm_arch_get_supported_msr_feature(): struct { struct kvm_msrs info; struct kvm_msr_entry entries[1]; } msr_data = {}; While that works in C, it fails in C++ with an error like: flexible array member 'kvm_msrs::entries' not at end of 'struct msr_data' Fix this by using __DECLARE_FLEX_ARRAY() for the VLA, which uses [0] for C++ compilation. Fixes: 94dfc73e7cf4 ("treewide: uapi: Replace zero-length arrays with flexible-array members") Cc: stable@vger.kernel.org Signed-off-by: David Woodhouse Link: https://patch.msgid.link/3abaf6aefd6e5efeff3b860ac38421d9dec908db.camel@infradead.org [sean: tag for stable@] Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit df61c2c99c7ff9ff79912afa085b28443d766762 Author: Sean Christopherson Date: Mon Apr 13 09:01:24 2026 -0400 KVM: Remove subtle "struct kvm_stats_desc" pseudo-overlay [ Upstream commit da142f3d373a6ddaca0119615a8db2175ddc4121 ] Remove KVM's internal pseudo-overlay of kvm_stats_desc, which subtly aliases the flexible name[] in the uAPI definition with a fixed-size array of the same name. The unusual embedded structure results in compiler warnings due to -Wflex-array-member-not-at-end, and also necessitates an extra level of dereferencing in KVM. To avoid the "overlay", define the uAPI structure to have a fixed-size name when building for the kernel. Opportunistically clean up the indentation for the stats macros, and replace spaces with tabs. No functional change intended. Reported-by: Gustavo A. R. Silva Closes: https://lore.kernel.org/all/aPfNKRpLfhmhYqfP@kspp Acked-by: Marc Zyngier Acked-by: Christian Borntraeger [..] Acked-by: Anup Patel Reviewed-by: Bibo Mao Acked-by: Gustavo A. R. Silva Link: https://patch.msgid.link/20251205232655.445294-1-seanjc@google.com Signed-off-by: Sean Christopherson Stable-dep-of: 2619da73bb2f ("KVM: x86: Use __DECLARE_FLEX_ARRAY() for UAPI structures with VLAs") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9309daac503430b1c24e74a176b54b25f4d6c876 Author: Paul Chaignon Date: Fri Feb 27 22:36:30 2026 +0100 selftests/bpf: Test refinement of single-value tnum commit e6ad477d1bf8829973cddd9accbafa9d1a6cd15a upstream. This patch introduces selftests to cover the new bounds refinement logic introduced in the previous patch. Without the previous patch, the first two tests fail because of the invariant violation they trigger. The last test fails because the R10 access is not detected as dead code. In addition, all three tests fail because of R0 having a non-constant value in the verifier logs. In addition, the last two cases are covering the negative cases: when we shouldn't refine the bounds because the u64 and tnum overlap in at least two values. Signed-off-by: Paul Chaignon Link: https://lore.kernel.org/r/90d880c8cf587b9f7dc715d8961cd1b8111d01a8.1772225741.git.paul.chaignon@gmail.com Signed-off-by: Alexei Starovoitov [shung-hsi.yu: test for backported upstream commit efc11a667878 ("bpf: Improve bounds when tnum has a single possible value")] Signed-off-by: Shung-Hsi Yu Signed-off-by: Greg Kroah-Hartman commit 28cc13ca20431b127d42d84ba10898d03e2c8267 Author: Sean Christopherson Date: Thu Mar 12 17:32:58 2026 -0700 KVM: SEV: Drop WARN on large size for KVM_MEMORY_ENCRYPT_REG_REGION commit 8acffeef5ef720c35e513e322ab08e32683f32f2 upstream. Drop the WARN in sev_pin_memory() on npages overflowing an int, as the WARN is comically trivially to trigger from userspace, e.g. by doing: struct kvm_enc_region range = { .addr = 0, .size = -1ul, }; __vm_ioctl(vm, KVM_MEMORY_ENCRYPT_REG_REGION, &range); Note, the checks in sev_mem_enc_register_region() that presumably exist to verify the incoming address+size are completely worthless, as both "addr" and "size" are u64s and SEV is 64-bit only, i.e. they _can't_ be greater than ULONG_MAX. That wart will be cleaned up in the near future. if (range->addr > ULONG_MAX || range->size > ULONG_MAX) return -EINVAL; Opportunistically add a comment to explain why the code calculates the number of pages the "hard" way, e.g. instead of just shifting @ulen. Fixes: 78824fabc72e ("KVM: SVM: fix svn_pin_memory()'s use of get_user_pages_fast()") Cc: stable@vger.kernel.org Reviewed-by: Liam Merwick Tested-by: Liam Merwick Link: https://patch.msgid.link/20260313003302.3136111-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 30fd9d8c82087742168db779929d8be0459b0716 Author: Sean Christopherson Date: Tue Mar 10 16:48:13 2026 -0700 KVM: SEV: Lock all vCPUs when synchronzing VMSAs for SNP launch finish commit cb923ee6a80f4e604e6242a4702b59251e61a380 upstream. Lock all vCPUs when synchronizing and encrypting VMSAs for SNP guests, as allowing userspace to manipulate and/or run a vCPU while its state is being synchronized would at best corrupt vCPU state, and at worst crash the host kernel. Opportunistically assert that vcpu->mutex is held when synchronizing its VMSA (the SEV-ES path already locks vCPUs). Fixes: ad27ce155566 ("KVM: SEV: Add KVM_SEV_SNP_LAUNCH_FINISH command") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260310234829.2608037-6-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 2c59132c4786a39d3138866ff576af5ea2b60cef Author: Sean Christopherson Date: Tue Mar 10 16:48:12 2026 -0700 KVM: SEV: Disallow LAUNCH_FINISH if vCPUs are actively being created commit 624bf3440d7214b62c22d698a0a294323f331d5d upstream. Reject LAUNCH_FINISH for SEV-ES and SNP VMs if KVM is actively creating one or more vCPUs, as KVM needs to process and encrypt each vCPU's VMSA. Letting userspace create vCPUs while LAUNCH_FINISH is in-progress is "fine", at least in the current code base, as kvm_for_each_vcpu() operates on online_vcpus, LAUNCH_FINISH (all SEV+ sub-ioctls) holds kvm->mutex, and fully onlining a vCPU in kvm_vm_ioctl_create_vcpu() is done under kvm->mutex. I.e. there's no difference between an in-progress vCPU and a vCPU that is created entirely after LAUNCH_FINISH. However, given that concurrent LAUNCH_FINISH and vCPU creation can't possibly work (for any reasonable definition of "work"), since userspace can't guarantee whether a particular vCPU will be encrypted or not, disallow the combination as a hardening measure, to reduce the probability of introducing bugs in the future, and to avoid having to reason about the safety of future changes related to LAUNCH_FINISH. Cc: Jethro Beekman Closes: https://lore.kernel.org/all/b31f7c6e-2807-4662-bcdd-eea2c1e132fa@fortanix.com Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260310234829.2608037-5-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 35a0963d361f98bba798fd15d229dcb166c04684 Author: Sean Christopherson Date: Tue Mar 10 16:48:11 2026 -0700 KVM: SEV: Protect *all* of sev_mem_enc_register_region() with kvm->lock commit b6408b6cec5df76a165575777800ef2aba12b109 upstream. Take and hold kvm->lock for before checking sev_guest() in sev_mem_enc_register_region(), as sev_guest() isn't stable unless kvm->lock is held (or KVM can guarantee KVM_SEV_INIT{2} has completed and can't rollack state). If KVM_SEV_INIT{2} fails, KVM can end up trying to add to a not-yet-initialized sev->regions_list, e.g. triggering a #GP Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 110 UID: 0 PID: 72717 Comm: syz.15.11462 Tainted: G U W O 6.16.0-smp-DEV #1 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024 RIP: 0010:sev_mem_enc_register_region+0x3f0/0x4f0 ../include/linux/list.h:83 Code: <41> 80 3c 04 00 74 08 4c 89 ff e8 f1 c7 a2 00 49 39 ed 0f 84 c6 00 RSP: 0018:ffff88838647fbb8 EFLAGS: 00010256 RAX: dffffc0000000000 RBX: 1ffff92015cf1e0b RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000001000 RDI: ffff888367870000 RBP: ffffc900ae78f050 R08: ffffea000d9e0007 R09: 1ffffd4001b3c000 R10: dffffc0000000000 R11: fffff94001b3c001 R12: 0000000000000000 R13: ffff8982ab0bde00 R14: ffffc900ae78f058 R15: 0000000000000000 FS: 00007f34e9dc66c0(0000) GS:ffff89ee64d33000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe180adef98 CR3: 000000047210e000 CR4: 0000000000350ef0 Call Trace: kvm_arch_vm_ioctl+0xa72/0x1240 ../arch/x86/kvm/x86.c:7371 kvm_vm_ioctl+0x649/0x990 ../virt/kvm/kvm_main.c:5363 __se_sys_ioctl+0x101/0x170 ../fs/ioctl.c:51 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x6f/0x1f0 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f34e9f7e9a9 Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f34e9dc6038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f34ea1a6080 RCX: 00007f34e9f7e9a9 RDX: 0000200000000280 RSI: 000000008010aebb RDI: 0000000000000007 RBP: 00007f34ea000d69 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f34ea1a6080 R15: 00007ffce77197a8 with a syzlang reproducer that looks like: syz_kvm_add_vcpu$x86(0x0, &(0x7f0000000040)={0x0, &(0x7f0000000180)=ANY=[], 0x70}) (async) syz_kvm_add_vcpu$x86(0x0, &(0x7f0000000080)={0x0, &(0x7f0000000180)=ANY=[@ANYBLOB="..."], 0x4f}) (async) r0 = openat$kvm(0xffffffffffffff9c, &(0x7f0000000200), 0x0, 0x0) r1 = ioctl$KVM_CREATE_VM(r0, 0xae01, 0x0) r2 = openat$kvm(0xffffffffffffff9c, &(0x7f0000000240), 0x0, 0x0) r3 = ioctl$KVM_CREATE_VM(r2, 0xae01, 0x0) ioctl$KVM_SET_CLOCK(r3, 0xc008aeba, &(0x7f0000000040)={0x1, 0x8, 0x0, 0x5625e9b0}) (async) ioctl$KVM_SET_PIT2(r3, 0x8010aebb, &(0x7f0000000280)={[...], 0x5}) (async) ioctl$KVM_SET_PIT2(r1, 0x4070aea0, 0x0) (async) r4 = ioctl$KVM_CREATE_VM(0xffffffffffffffff, 0xae01, 0x0) openat$kvm(0xffffffffffffff9c, 0x0, 0x0, 0x0) (async) ioctl$KVM_SET_USER_MEMORY_REGION(r4, 0x4020ae46, &(0x7f0000000400)={0x0, 0x0, 0x0, 0x2000, &(0x7f0000001000/0x2000)=nil}) (async) r5 = ioctl$KVM_CREATE_VCPU(r4, 0xae41, 0x2) close(r0) (async) openat$kvm(0xffffffffffffff9c, &(0x7f0000000000), 0x8000, 0x0) (async) ioctl$KVM_SET_GUEST_DEBUG(r5, 0x4048ae9b, &(0x7f0000000300)={0x4376ea830d46549b, 0x0, [0x46, 0x0, 0x0, 0x0, 0x0, 0x1000]}) (async) ioctl$KVM_RUN(r5, 0xae80, 0x0) Opportunistically use guard() to avoid having to define a new error label and goto usage. Fixes: 1e80fdc09d12 ("KVM: SVM: Pin guest memory when SEV is active") Cc: stable@vger.kernel.org Reported-by: Alexander Potapenko Tested-by: Alexander Potapenko Link: https://patch.msgid.link/20260310234829.2608037-4-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 692fdf05e55fa03960a1278afdc2478c12daea13 Author: Sean Christopherson Date: Tue Mar 10 16:48:10 2026 -0700 KVM: SEV: Reject attempts to sync VMSA of an already-launched/encrypted vCPU commit 9b9f7962e3e879d12da2bf47e02a24ec51690e3d upstream. Reject synchronizing vCPU state to its associated VMSA if the vCPU has already been launched, i.e. if the VMSA has already been encrypted. On a host with SNP enabled, accessing guest-private memory generates an RMP #PF and panics the host. BUG: unable to handle page fault for address: ff1276cbfdf36000 #PF: supervisor write access in kernel mode #PF: error_code(0x80000003) - RMP violation PGD 5a31801067 P4D 5a31802067 PUD 40ccfb5063 PMD 40e5954063 PTE 80000040fdf36163 SEV-SNP: PFN 0x40fdf36, RMP entry: [0x6010fffffffff001 - 0x000000000000001f] Oops: Oops: 0003 [#1] SMP NOPTI CPU: 33 UID: 0 PID: 996180 Comm: qemu-system-x86 Tainted: G OE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Dell Inc. PowerEdge R7625/0H1TJT, BIOS 1.5.8 07/21/2023 RIP: 0010:sev_es_sync_vmsa+0x54/0x4c0 [kvm_amd] Call Trace: snp_launch_update_vmsa+0x19d/0x290 [kvm_amd] snp_launch_finish+0xb6/0x380 [kvm_amd] sev_mem_enc_ioctl+0x14e/0x720 [kvm_amd] kvm_arch_vm_ioctl+0x837/0xcf0 [kvm] kvm_vm_ioctl+0x3fd/0xcc0 [kvm] __x64_sys_ioctl+0xa3/0x100 x64_sys_call+0xfe0/0x2350 do_syscall_64+0x81/0x10f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7ffff673287d Note, the KVM flaw has been present since commit ad73109ae7ec ("KVM: SVM: Provide support to launch and run an SEV-ES guest"), but has only been actively dangerous for the host since SNP support was added. With SEV-ES, KVM would "just" clobber guest state, which is totally fine from a host kernel perspective since userspace can clobber guest state any time before sev_launch_update_vmsa(). Fixes: ad27ce155566 ("KVM: SEV: Add KVM_SEV_SNP_LAUNCH_FINISH command") Reported-by: Jethro Beekman Closes: https://lore.kernel.org/all/d98692e2-d96b-4c36-8089-4bc1e5cc3d57@fortanix.com Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260310234829.2608037-3-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 5d57a1ee587c1ddf3ac630f9017d4cd76e6c4bf8 Author: Sean Christopherson Date: Tue Mar 10 16:48:09 2026 -0700 KVM: selftests: Remove duplicate LAUNCH_UPDATE_VMSA call in SEV-ES migrate test commit 25a642b6abc98bbbabbf2baef9fc498bbea6aee6 upstream. Drop the explicit KVM_SEV_LAUNCH_UPDATE_VMSA call when creating an SEV-ES VM in the SEV migration test, as sev_vm_create() automatically updates the VMSA pages for SEV-ES guests. The only reason the duplicate call doesn't cause visible problems is because the test doesn't actually try to run the vCPUs. That will change when KVM adds a check to prevent userspace from re-launching a VMSA (which corrupts the VMSA page due to KVM writing encrypted private memory). Fixes: 69f8e15ab61f ("KVM: selftests: Use the SEV library APIs in the intra-host migration test") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260310234829.2608037-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit cec9ead73ab154a7953f6ab8dd5127e0d6bbf95a Author: Koichiro Den Date: Thu Feb 26 17:41:38 2026 +0900 PCI: endpoint: pci-epf-vntb: Remove duplicate resource teardown commit 0da63230d3ec1ec5fcc443a2314233e95bfece54 upstream. epf_ntb_epc_destroy() duplicates the teardown that the caller is supposed to perform later. This leads to an oops when .allow_link fails or when .drop_link is performed. The following is an example oops of the former case: Unable to handle kernel paging request at virtual address dead000000000108 [...] [dead000000000108] address between user and kernel address ranges Internal error: Oops: 0000000096000044 [#1] SMP [...] Call trace: pci_epc_remove_epf+0x78/0xe0 (P) pci_primary_epc_epf_link+0x88/0xa8 configfs_symlink+0x1f4/0x5a0 vfs_symlink+0x134/0x1d8 do_symlinkat+0x88/0x138 __arm64_sys_symlinkat+0x74/0xe0 [...] Remove the helper, and drop pci_epc_put(). EPC device refcounting is tied to the configfs EPC group lifetime, and pci_epc_put() in the .drop_link path is sufficient. Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Reviewed-by: Frank Li Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260226084142.2226875-2-den@valinux.co.jp Signed-off-by: Greg Kroah-Hartman commit 9921cce25bfe4021f6e55ca995351eb967165297 Author: Koichiro Den Date: Thu Feb 26 17:41:40 2026 +0900 PCI: endpoint: pci-epf-vntb: Stop cmd_handler work in epf_ntb_epc_cleanup commit d799984233a50abd2667a7d17a9a710a3f10ebe2 upstream. Disable the delayed work before clearing BAR mappings and doorbells to avoid running the handler after resources have been torn down. Unable to handle kernel paging request at virtual address ffff800083f46004 [...] Internal error: Oops: 0000000096000007 [#1] SMP [...] Call trace: epf_ntb_cmd_handler+0x54/0x200 [pci_epf_vntb] (P) process_one_work+0x154/0x3b0 worker_thread+0x2c8/0x400 kthread+0x148/0x210 ret_from_fork+0x10/0x20 Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Reviewed-by: Frank Li Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260226084142.2226875-4-den@valinux.co.jp Signed-off-by: Greg Kroah-Hartman commit e384a850a3370d89a7a446cdeccd964bfba2a302 Author: ZhengYuan Huang Date: Wed Apr 1 17:23:03 2026 +0800 ocfs2: handle invalid dinode in ocfs2_group_extend commit 4a1c0ddc6e7bcf2e9db0eeaab9340dcfe97f448f upstream. [BUG] kernel BUG at fs/ocfs2/resize.c:308! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ocfs2_group_extend+0x10aa/0x1ae0 fs/ocfs2/resize.c:308 Code: 8b8520ff ffff83f8 860f8580 030000e8 5cc3c1fe Call Trace: ... ocfs2_ioctl+0x175/0x6e0 fs/ocfs2/ioctl.c:869 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583 x64_sys_call+0x1144/0x26a0 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x93/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... [CAUSE] ocfs2_group_extend() assumes that the global bitmap inode block returned from ocfs2_inode_lock() has already been validated and BUG_ONs when the signature is not a dinode. That assumption is too strong for crafted filesystems because the JBD2-managed buffer path can bypass structural validation and return an invalid dinode to the resize ioctl. [FIX] Validate the dinode explicitly in ocfs2_group_extend(). If the global bitmap buffer does not contain a valid dinode, report filesystem corruption with ocfs2_error() and fail the resize operation instead of crashing the kernel. Link: https://lkml.kernel.org/r/20260401092303.3709187-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 Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit d45ff441b416d4aa1af72b1db23d959601c04da2 Author: Tejas Bharambe Date: Fri Apr 10 01:38:16 2026 -0700 ocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRY commit 7de554cabf160e331e4442e2a9ad874ca9875921 upstream. filemap_fault() may drop the mmap_lock before returning VM_FAULT_RETRY, as documented in mm/filemap.c: "If our return value has VM_FAULT_RETRY set, it's because the mmap_lock may be dropped before doing I/O or by lock_folio_maybe_drop_mmap()." When this happens, a concurrent munmap() can call remove_vma() and free the vm_area_struct via RCU. The saved 'vma' pointer in ocfs2_fault() then becomes a dangling pointer, and the subsequent trace_ocfs2_fault() call dereferences it -- a use-after-free. Fix this by saving ip_blkno as a plain integer before calling filemap_fault(), and removing vma from the trace event. Since ip_blkno is copied by value before the lock can be dropped, it remains valid regardless of what happens to the vma or inode afterward. Link: https://lkml.kernel.org/r/20260410083816.34951-1-tejas.bharambe@outlook.com Fixes: 614a9e849ca6 ("ocfs2: Remove FILE_IO from masklog.") Signed-off-by: Tejas Bharambe Reported-by: syzbot+a49010a0e8fcdeea075f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a49010a0e8fcdeea075f Suggested-by: Joseph Qi 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 bc0fb5c7d54c78be43a536df0e20dee32adb27d3 Author: Joseph Qi Date: Fri Mar 6 11:22:11 2026 +0800 ocfs2: fix possible deadlock between unlink and dio_end_io_write commit b02da26a992db0c0e2559acbda0fc48d4a2fd337 upstream. ocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem, while in ocfs2_dio_end_io_write, it acquires these locks in reverse order. This creates an ABBA lock ordering violation on lock classes ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and ocfs2_file_ip_alloc_sem_key. Lock Chain #0 (orphan dir inode_lock -> ip_alloc_sem): ocfs2_unlink ocfs2_prepare_orphan_dir ocfs2_lookup_lock_orphan_dir inode_lock(orphan_dir_inode) <- lock A __ocfs2_prepare_orphan_dir ocfs2_prepare_dir_for_insert ocfs2_extend_dir ocfs2_expand_inline_dir down_write(&oi->ip_alloc_sem) <- Lock B Lock Chain #1 (ip_alloc_sem -> orphan dir inode_lock): ocfs2_dio_end_io_write down_write(&oi->ip_alloc_sem) <- Lock B ocfs2_del_inode_from_orphan() inode_lock(orphan_dir_inode) <- Lock A Deadlock Scenario: CPU0 (unlink) CPU1 (dio_end_io_write) ------ ------ inode_lock(orphan_dir_inode) down_write(ip_alloc_sem) down_write(ip_alloc_sem) inode_lock(orphan_dir_inode) Since ip_alloc_sem is to protect allocation changes, which is unrelated with operations in ocfs2_del_inode_from_orphan. So move ocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock. Link: https://lkml.kernel.org/r/20260306032211.1016452-1-joseph.qi@linux.alibaba.com Reported-by: syzbot+67b90111784a3eac8c04@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=67b90111784a3eac8c04 Fixes: a86a72a4a4e0 ("ocfs2: take ip_alloc_sem in ocfs2_dio_get_block & ocfs2_dio_end_io_write") Signed-off-by: Joseph Qi Reviewed-by: Heming Zhao Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Joseph Qi Cc: Changwei Ge Cc: Jun Piao Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 2dff11fb5098ae453651f8f77e94ad499c078022 Author: Ruslan Valiyev Date: Tue Mar 3 11:27:54 2026 +0000 media: vidtv: fix NULL pointer dereference in vidtv_channel_pmt_match_sections commit f8e1fc918a9fe67103bcda01d20d745f264d00a7 upstream. syzbot reported a general protection fault in vidtv_psi_desc_assign [1]. vidtv_psi_pmt_stream_init() can return NULL on memory allocation failure, but vidtv_channel_pmt_match_sections() does not check for this. When tail is NULL, the subsequent call to vidtv_psi_desc_assign(&tail->descriptor, desc) dereferences a NULL pointer offset, causing a general protection fault. Add a NULL check after vidtv_psi_pmt_stream_init(). On failure, clean up the already-allocated stream chain and return. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:vidtv_psi_desc_assign+0x24/0x90 drivers/media/test-drivers/vidtv/vidtv_psi.c:629 Call Trace: vidtv_channel_pmt_match_sections drivers/media/test-drivers/vidtv/vidtv_channel.c:349 [inline] vidtv_channel_si_init+0x1445/0x1a50 drivers/media/test-drivers/vidtv/vidtv_channel.c:479 vidtv_mux_init+0x526/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:519 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline] vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239 Fixes: f90cf6079bf67 ("media: vidtv: add a bridge driver") Cc: stable@vger.kernel.org Reported-by: syzbot+1f5bcc7c919ec578777a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1f5bcc7c919ec578777a Signed-off-by: Ruslan Valiyev Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 8140b21d19015227a28c255404462f2d3e6edc9a Author: Ryan Roberts Date: Mon Mar 30 17:17:03 2026 +0100 arm64: mm: Handle invalid large leaf mappings correctly commit 15bfba1ad77fad8e45a37aae54b3c813b33fe27c upstream. It has been possible for a long time to mark ptes in the linear map as invalid. This is done for secretmem, kfence, realm dma memory un/share, and others, by simply clearing the PTE_VALID bit. But until commit a166563e7ec37 ("arm64: mm: support large block mapping when rodata=full") large leaf mappings were never made invalid in this way. It turns out various parts of the code base are not equipped to handle invalid large leaf mappings (in the way they are currently encoded) and I've observed a kernel panic while booting a realm guest on a BBML2_NOABORT system as a result: [ 15.432706] software IO TLB: Memory encryption is active and system is using DMA bounce buffers [ 15.476896] Unable to handle kernel paging request at virtual address ffff000019600000 [ 15.513762] Mem abort info: [ 15.527245] ESR = 0x0000000096000046 [ 15.548553] EC = 0x25: DABT (current EL), IL = 32 bits [ 15.572146] SET = 0, FnV = 0 [ 15.592141] EA = 0, S1PTW = 0 [ 15.612694] FSC = 0x06: level 2 translation fault [ 15.640644] Data abort info: [ 15.661983] ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000 [ 15.694875] CM = 0, WnR = 1, TnD = 0, TagAccess = 0 [ 15.723740] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 15.755776] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000081f3f000 [ 15.800410] [ffff000019600000] pgd=0000000000000000, p4d=180000009ffff403, pud=180000009fffe403, pmd=00e8000199600704 [ 15.855046] Internal error: Oops: 0000000096000046 [#1] SMP [ 15.886394] Modules linked in: [ 15.900029] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc4-dirty #4 PREEMPT [ 15.935258] Hardware name: linux,dummy-virt (DT) [ 15.955612] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 15.986009] pc : __pi_memcpy_generic+0x128/0x22c [ 16.006163] lr : swiotlb_bounce+0xf4/0x158 [ 16.024145] sp : ffff80008000b8f0 [ 16.038896] x29: ffff80008000b8f0 x28: 0000000000000000 x27: 0000000000000000 [ 16.069953] x26: ffffb3976d261ba8 x25: 0000000000000000 x24: ffff000019600000 [ 16.100876] x23: 0000000000000001 x22: ffff0000043430d0 x21: 0000000000007ff0 [ 16.131946] x20: 0000000084570010 x19: 0000000000000000 x18: ffff00001ffe3fcc [ 16.163073] x17: 0000000000000000 x16: 00000000003fffff x15: 646e612065766974 [ 16.194131] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 16.225059] x11: 0000000000000000 x10: 0000000000000010 x9 : 0000000000000018 [ 16.256113] x8 : 0000000000000018 x7 : 0000000000000000 x6 : 0000000000000000 [ 16.287203] x5 : ffff000019607ff0 x4 : ffff000004578000 x3 : ffff000019600000 [ 16.318145] x2 : 0000000000007ff0 x1 : ffff000004570010 x0 : ffff000019600000 [ 16.349071] Call trace: [ 16.360143] __pi_memcpy_generic+0x128/0x22c (P) [ 16.380310] swiotlb_tbl_map_single+0x154/0x2b4 [ 16.400282] swiotlb_map+0x5c/0x228 [ 16.415984] dma_map_phys+0x244/0x2b8 [ 16.432199] dma_map_page_attrs+0x44/0x58 [ 16.449782] virtqueue_map_page_attrs+0x38/0x44 [ 16.469596] virtqueue_map_single_attrs+0xc0/0x130 [ 16.490509] virtnet_rq_alloc.isra.0+0xa4/0x1fc [ 16.510355] try_fill_recv+0x2a4/0x584 [ 16.526989] virtnet_open+0xd4/0x238 [ 16.542775] __dev_open+0x110/0x24c [ 16.558280] __dev_change_flags+0x194/0x20c [ 16.576879] netif_change_flags+0x24/0x6c [ 16.594489] dev_change_flags+0x48/0x7c [ 16.611462] ip_auto_config+0x258/0x1114 [ 16.628727] do_one_initcall+0x80/0x1c8 [ 16.645590] kernel_init_freeable+0x208/0x2f0 [ 16.664917] kernel_init+0x24/0x1e0 [ 16.680295] ret_from_fork+0x10/0x20 [ 16.696369] Code: 927cec03 cb0e0021 8b0e0042 a9411c26 (a900340c) [ 16.723106] ---[ end trace 0000000000000000 ]--- [ 16.752866] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 16.792556] Kernel Offset: 0x3396ea200000 from 0xffff800080000000 [ 16.818966] PHYS_OFFSET: 0xfff1000080000000 [ 16.837237] CPU features: 0x0000000,00060005,13e38581,957e772f [ 16.862904] Memory Limit: none [ 16.876526] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--- This panic occurs because the swiotlb memory was previously shared to the host (__set_memory_enc_dec()), which involves transitioning the (large) leaf mappings to invalid, sharing to the host, then marking the mappings valid again. But pageattr_p[mu]d_entry() would only update the entry if it is a section mapping, since otherwise it concluded it must be a table entry so shouldn't be modified. But p[mu]d_sect() only returns true if the entry is valid. So the result was that the large leaf entry was made invalid in the first pass then ignored in the second pass. It remains invalid until the above code tries to access it and blows up. The simple fix would be to update pageattr_pmd_entry() to use !pmd_table() instead of pmd_sect(). That would solve this problem. But the ptdump code also suffers from a similar issue. It checks pmd_leaf() and doesn't call into the arch-specific note_page() machinery if it returns false. As a result of this, ptdump wasn't even able to show the invalid large leaf mappings; it looked like they were valid which made this super fun to debug. the ptdump code is core-mm and pmd_table() is arm64-specific so we can't use the same trick to solve that. But we already support the concept of "present-invalid" for user space entries. And even better, pmd_leaf() will return true for a leaf mapping that is marked present-invalid. So let's just use that encoding for present-invalid kernel mappings too. Then we can use pmd_leaf() where we previously used pmd_sect() and everything is magically fixed. Additionally, from inspection kernel_page_present() was broken in a similar way, so I'm also updating that to use pmd_leaf(). The transitional page tables component was also similarly broken; it creates a copy of the kernel page tables, making RO leaf mappings RW in the process. It also makes invalid (but-not-none) pte mappings valid. But it was not doing this for large leaf mappings. This could have resulted in crashes at kexec- or hibernate-time. This code is fixed to flip "present-invalid" mappings back to "present-valid" at all levels. Finally, I have hardened split_pmd()/split_pud() so that if it is passed a "present-invalid" leaf, it will maintain that property in the split leaves, since I wasn't able to convince myself that it would only ever be called for "present-valid" leaves. Fixes: a166563e7ec3 ("arm64: mm: support large block mapping when rodata=full") Cc: stable@vger.kernel.org Signed-off-by: Ryan Roberts Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 755b40903eff563768d4d96fd4ef51ec48adde3b Author: Zhihao Cheng Date: Fri Jan 30 11:48:53 2026 +0800 dcache: Limit the minimal number of bucket to two commit f08fe8891c3eeb63b73f9f1f6d97aa629c821579 upstream. There is an OOB read problem on dentry_hashtable when user sets 'dhash_entries=1': BUG: unable to handle page fault for address: ffff888b30b774b0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP PTI RIP: 0010:__d_lookup+0x56/0x120 Call Trace: d_lookup.cold+0x16/0x5d lookup_dcache+0x27/0xf0 lookup_one_qstr_excl+0x2a/0x180 start_dirop+0x55/0xa0 simple_start_creating+0x8d/0xa0 debugfs_start_creating+0x8c/0x180 debugfs_create_dir+0x1d/0x1c0 pinctrl_init+0x6d/0x140 do_one_initcall+0x6d/0x3d0 kernel_init_freeable+0x39f/0x460 kernel_init+0x2a/0x260 There will be only one bucket in dentry_hashtable when dhash_entries is set as one, and d_hash_shift is calculated as 32 by dcache_init(). Then, following process will access more than one buckets(which memory region is not allocated) in dentry_hashtable: d_lookup b = d_hash(hash) dentry_hashtable + ((u32)hashlen >> d_hash_shift) // The C standard defines the behavior of right shift amounts // exceeding the bit width of the operand as undefined. The // result of '(u32)hashlen >> d_hash_shift' becomes 'hashlen', // so 'b' will point to an unallocated memory region. hlist_bl_for_each_entry_rcu(b) hlist_bl_first_rcu(head) h->first // read OOB! Fix it by limiting the minimal number of dentry_hashtable bucket to two, so that 'd_hash_shift' won't exceeds the bit width of type u32. Cc: stable@vger.kernel.org Signed-off-by: Zhihao Cheng Link: https://patch.msgid.link/20260130034853.215819-1-chengzhihao1@huawei.com Reviewed-by: Yang Erkun Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit 3fd0685d7fef68c2d8a04876bcf9eaa0724ad6a5 Author: Harin Lee Date: Mon Apr 6 16:48:57 2026 +0900 ALSA: ctxfi: Limit PTP to a single page commit e9418da50d9e5c496c22fe392e4ad74c038a94eb upstream. Commit 391e69143d0a increased CT_PTP_NUM from 1 to 4 to support 256 playback streams, but the additional pages are not used by the card correctly. The CT20K2 hardware already has multiple VMEM_PTPAL registers, but using them separately would require refactoring the entire virtual memory allocation logic. ct_vm_map() always uses PTEs in vm->ptp[0].area regardless of CT_PTP_NUM. On AMD64 systems, a single PTP covers 512 PTEs (2M). When aggregate memory allocations exceed this limit, ct_vm_map() tries to access beyond the allocated space and causes a page fault: BUG: unable to handle page fault for address: ffffd4ae8a10a000 Oops: Oops: 0002 [#1] SMP PTI RIP: 0010:ct_vm_map+0x17c/0x280 [snd_ctxfi] Call Trace: atc_pcm_playback_prepare+0x225/0x3b0 ct_pcm_playback_prepare+0x38/0x60 snd_pcm_do_prepare+0x2f/0x50 snd_pcm_action_single+0x36/0x90 snd_pcm_action_nonatomic+0xbf/0xd0 snd_pcm_ioctl+0x28/0x40 __x64_sys_ioctl+0x97/0xe0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e Revert CT_PTP_NUM to 1. The 256 SRC_RESOURCE_NUM and playback_count remain unchanged. Fixes: 391e69143d0a ("ALSA: ctxfi: Bump playback substreams to 256") Cc: stable@vger.kernel.org Signed-off-by: Harin Lee Link: https://patch.msgid.link/20260406074857.216034-1-me@harin.net Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit de5c3e67037f9f086b0eb2c8f5c5a1e82aba9a96 Author: SeongJae Park Date: Sun Mar 29 08:30:49 2026 -0700 Docs/admin-guide/mm/damon/reclaim: warn commit_inputs vs param updates race commit 0beba407d4585a15b0dc09f2064b5b3ddcb0e857 upstream. Patch series "Docs/admin-guide/mm/damon: warn commit_inputs vs other params race". Writing 'Y' to the commit_inputs parameter of DAMON_RECLAIM and DAMON_LRU_SORT, and writing other parameters before the commit_inputs request is completely processed can cause race conditions. While the consequence can be bad, the documentation is not clearly describing that. Add clear warnings. The issue was discovered [1,2] by sashiko. This patch (of 2): DAMON_RECLAIM handles commit_inputs request inside kdamond thread, reading the module parameters. If the user updates the module parameters while the kdamond thread is reading those, races can happen. To avoid this, the commit_inputs parameter shows whether it is still in the progress, assuming users wouldn't update parameters in the middle of the work. Some users might ignore that. Add a warning about the behavior. The issue was discovered in [1] by sashiko. Link: https://lore.kernel.org/20260329153052.46657-2-sj@kernel.org Link: https://lore.kernel.org/20260319161620.189392-3-objecting@objecting.org [1] Link: https://lore.kernel.org/20260319161620.189392-2-objecting@objecting.org [3] Fixes: 81a84182c343 ("Docs/admin-guide/mm/damon/reclaim: document 'commit_inputs' parameter") Signed-off-by: SeongJae Park Cc: # 5.19.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 4c971d577a9f2c3a9956dd0e3f5a950e05968c98 Author: Fabio Porcedda Date: Thu Apr 2 11:57:27 2026 +0200 USB: serial: option: add Telit Cinterion FN990A MBIM composition commit f8cc59ecc22841be5deb07b549c0c6a2657cd5f9 upstream. Add the following Telit Cinterion FN990A MBIM composition: 0x1074: MBIM + tty (AT/NMEA) + tty (AT) + tty (AT) + tty (diag) + DPL (Data Packet Logging) + adb T: Bus=01 Lev=01 Prnt=04 Port=06 Cnt=01 Dev#= 7 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1bc7 ProdID=1074 Rev=05.04 S: Manufacturer=Telit Wireless Solutions S: Product=FN990 S: SerialNumber=70628d0c C: #Ifs= 8 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 6 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none) E: Ad=8f(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 7 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms Cc: stable@vger.kernel.org Signed-off-by: Fabio Porcedda Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 1412ba36597a82e928f20047f41d6c6582dafe8a Author: Junrui Luo Date: Mon Mar 23 15:31:56 2026 +0800 staging: sm750fb: fix division by zero in ps_to_hz() commit 75a1621e4f91310673c9acbcbb25c2a7ff821cd3 upstream. ps_to_hz() is called from hw_sm750_crtc_set_mode() without validating that pixclock is non-zero. A zero pixclock passed via FBIOPUT_VSCREENINFO causes a division by zero. Fix by rejecting zero pixclock in lynxfb_ops_check_var(), consistent with other framebuffer drivers. Fixes: 81dee67e215b ("staging: sm750fb: add sm750 to staging") Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Link: https://patch.msgid.link/SYBPR01MB7881AFBFCE28CCF528B35D0CAF4BA@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Greg Kroah-Hartman commit 89a9c1bc7d797120bcc290864e0cb10a440a677f Author: Johan Hovold Date: Fri Mar 6 09:51:44 2026 +0100 wifi: rtw88: fix device leak on probe failure commit bbb15e71156cd9f5e1869eee7207a06ea8e96c39 upstream. Driver core holds a reference to the USB interface and its parent USB device while the interface is bound to a driver and there is no need to take additional references unless the structures are needed after disconnect. This driver takes a reference to the USB device during probe but does not to release it on all probe errors (e.g. when descriptor parsing fails). Drop the redundant device reference to fix the leak, reduce cargo culting, make it easier to spot drivers where an extra reference is needed, and reduce the risk of further memory leaks. Fixes: a82dfd33d123 ("wifi: rtw88: Add common USB chip support") Reported-by: Greg Kroah-Hartman Link: https://lore.kernel.org/netdev/2026022319-turbofan-darkened-206d@gregkh/ Cc: stable@vger.kernel.org # 6.2 Cc: Sascha Hauer Signed-off-by: Johan Hovold Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260306085144.12064-19-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 9c401606e2d01afc9dec8cd33f0b47c30befd00e Author: Tamir Duberstein Date: Tue Jan 27 11:35:43 2026 -0500 scripts: generate_rust_analyzer.py: avoid FD leak commit 9b4744d8eda2824041064a5639ccbb079850914d upstream. Use `pathlib.Path.read_text()` to avoid leaking file descriptors. Fixes: 8c4555ccc55c ("scripts: add `generate_rust_analyzer.py`") Cc: stable@vger.kernel.org Reviewed-by: Daniel Almeida Reviewed-by: Fiona Behrens Reviewed-by: Trevor Gross Link: https://patch.msgid.link/20260127-rust-analyzer-fd-leak-v2-1-1bb55b9b6822@kernel.org Signed-off-by: Tamir Duberstein Signed-off-by: Greg Kroah-Hartman commit 6de048d78f3029744778b7a2891745f3ca7c209a Author: Greg Kroah-Hartman Date: Thu Apr 9 15:23:46 2026 +0200 fbdev: udlfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO commit a31e4518bec70333a0a98f2946a12b53b45fe5b9 upstream. Much like commit 19f953e74356 ("fbdev: fb_pm2fb: Avoid potential divide by zero error"), we also need to prevent that same crash from happening in the udlfb driver as it uses pixclock directly when dividing, which will crash. Cc: Bernie Thompson Cc: Helge Deller Fixes: 59277b679f8b ("Staging: udlfb: add dynamic modeset support") Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 5d02df1b130bfd83307a2cdd96a2b9c9013e85f0 Author: Xu Yang Date: Mon Mar 16 17:50:42 2026 +0800 usb: port: add delay after usb_hub_set_port_power() commit b84cc80610a8ce036deb987f056ce3196ead7f1e upstream. When a port is disabled, an attached device will be disconnected. This causes a port-status-change event, which will race with hub autosuspend (if the disabled port was the only connected port on its hub), causing an immediate resume and a second autosuspend. Both of these can be avoided by adding a short delay after the call to usb_hub_set_port_power(). Below log shows what is happening: $ echo 1 > usb1-port1/disable [ 37.958239] usb 1-1: USB disconnect, device number 2 [ 37.964101] usb 1-1: unregistering device [ 37.970070] hub 1-0:1.0: hub_suspend [ 37.971305] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0002 [ 37.974412] usb usb1: bus auto-suspend, wakeup 1 [ 37.988175] usb usb1: suspend raced with wakeup event <--- [ 37.993947] usb usb1: usb auto-resume [ 37.998401] hub 1-0:1.0: hub_resume [ 38.105688] usb usb1-port1: status 0000, change 0000, 12 Mb/s [ 38.112399] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000 [ 38.118645] hub 1-0:1.0: hub_suspend [ 38.122963] usb usb1: bus auto-suspend, wakeup 1 [ 38.200368] usb usb1: usb wakeup-resume [ 38.204982] usb usb1: usb auto-resume [ 38.209376] hub 1-0:1.0: hub_resume [ 38.213676] usb usb1-port1: status 0101 change 0001 [ 38.321552] hub 1-0:1.0: state 7 ports 1 chg 0002 evt 0000 [ 38.327978] usb usb1-port1: status 0101, change 0000, 12 Mb/s [ 38.457429] usb 1-1: new high-speed USB device number 3 using ci_hdrc Then, port change bit will be fixed to the final state and usb_clear_port_feature() can correctly clear it after this period. This will also avoid usb runtime suspend routine to run because usb_autopm_put_interface() not run yet. Fixes: f061f43d7418 ("usb: hub: port: add sysfs entry to switch port power") Cc: stable@kernel.org Signed-off-by: Xu Yang Link: https://patch.msgid.link/20260316095042.1559882-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman commit eb6ef6185f2054a341ec70d7e2165f5381744215 Author: Michael Zimmermann Date: Fri Mar 27 20:22:09 2026 +0100 usb: gadget: f_hid: don't call cdev_init while cdev in use commit 81ebd43cc0d6d106ce7b6ccbf7b5e40ca7f5503d upstream. When calling unbind, then bind again, cdev_init reinitialized the cdev, even though there may still be references to it. That's the case when the /dev/hidg* device is still opened. This obviously unsafe behavior like oopes. This fixes this by using cdev_alloc to put the cdev on the heap. That way, we can simply allocate a new one in hidg_bind. Closes: https://lore.kernel.org/linux-usb/CAN9vWDKZn0Ts5JyV2_xcAmbnBEi0znMLg_USMFrShRryXrgWGQ@mail.gmail.com/T/#m2cb0dba3633b67b2a679c98499508267d1508881 Cc: stable Signed-off-by: Michael Zimmermann Link: https://patch.msgid.link/20260327192209.59945-1-sigmaepsilon92@gmail.com Signed-off-by: Greg Kroah-Hartman commit 5d29d7ff8679e5a525f22da467ba33c042e8029b Author: Dave Carey Date: Thu Apr 2 14:29:50 2026 -0400 USB: cdc-acm: Add quirks for Yoga Book 9 14IAH10 INGENIC touchscreen commit f58752ebcb35e156c85cd1a82d6579c7af3b9023 upstream. The Lenovo Yoga Book 9 14IAH10 (83KJ) has a composite USB device (17EF:6161) that controls both touchscreens via a CDC ACM interface. Interface 0 is a standard CDC ACM control interface, but interface 1 (the data interface) incorrectly declares vendor-specific class (0xFF) instead of USB_CLASS_CDC_DATA. cdc-acm rejects the device at probe with -EINVAL, leaving interface 0 unbound and EP 0x82 never polled. With no consumer polling EP 0x82, the firmware's watchdog fires every ~20 seconds and resets the USB bus, producing a continuous disconnect/ reconnect loop that prevents the touchscreens from ever initialising. Add two new quirk flags: VENDOR_CLASS_DATA_IFACE: Bypasses the bInterfaceClass check in acm_probe() that would otherwise reject the vendor-class data interface with -EINVAL. ALWAYS_POLL_CTRL: Submits the notification URB at probe() rather than waiting for a TTY open. This keeps EP 0x82 polled at all times, permanently suppressing the firmware watchdog. The URB is resubmitted after port_shutdown() and on system resume. SET_CONTROL_LINE_STATE (DTR|RTS) is sent at probe and after port_shutdown() to complete firmware handshake. Note: the firmware performs exactly 4 USB connect/disconnect cycles (~19 s each) on every cold boot before stabilising. This is a fixed firmware property; touch is available ~75-80 s after power-on. Signed-off-by: Dave Carey Cc: stable Tested-by: Dave Carey Acked-by: Oliver Neukum Link: https://patch.msgid.link/20260402182950.389016-1-carvsdriver@gmail.com Signed-off-by: Greg Kroah-Hartman commit 63dc7cdb1f4e756f0b9f11b0d09d9d2ac4891436 Author: Daniel Brát Date: Thu Apr 2 19:24:33 2026 +0200 usb: storage: Expand range of matched versions for VL817 quirks entry commit 609865ab3d5d803556f628e221ecd3d06aed9f30 upstream. Expands range of matched bcdDevice values for the VL817 quirk entry. This is based on experience with Axagon EE35-GTR rev1 3.5" HDD enclosure, which reports its bcdDevice as 0x0843, but presumably other vendors using this IC in their products may set it to any other value. Signed-off-by: Daniel Brát Cc: stable Link: https://patch.msgid.link/20260402172433.5227-1-danek.brat@gmail.com Signed-off-by: Greg Kroah-Hartman commit 9aef3f9791900b2d4043868882e65766bcbbfc63 Author: Alexey Charkov Date: Tue Mar 17 20:30:15 2026 +0400 usb: typec: fusb302: Switch to threaded IRQ handler commit 6b9db53197094f38a18797495df2e3c758ec51dc upstream. FUSB302 fails to probe with -EINVAL if its interrupt line is connected via an I2C GPIO expander, such as TI TCA6416. Switch the interrupt handler to a threaded one, which also works behind such GPIO expanders. Cc: stable Fixes: 309b6341d557 ("usb: typec: fusb302: Revert incorrect threaded irq fix") Signed-off-by: Alexey Charkov Reviewed-by: Hans de Goede Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260317-fusb302-irq-v2-1-dbabd5c5c961@flipper.net Signed-off-by: Greg Kroah-Hartman commit 906f16a836de13fe61f49cdce2f66f2dbd14caf4 Author: Nathan Rebello Date: Thu Apr 2 04:52:59 2026 -0400 usbip: validate number_of_packets in usbip_pack_ret_submit() commit 2ab833a16a825373aad2ba7d54b572b277e95b71 upstream. When a USB/IP client receives a RET_SUBMIT response, usbip_pack_ret_submit() unconditionally overwrites urb->number_of_packets from the network PDU. This value is subsequently used as the loop bound in usbip_recv_iso() and usbip_pad_iso() to iterate over urb->iso_frame_desc[], a flexible array whose size was fixed at URB allocation time based on the *original* number_of_packets from the CMD_SUBMIT. A malicious USB/IP server can set number_of_packets in the response to a value larger than what was originally submitted, causing a heap out-of-bounds write when usbip_recv_iso() writes to urb->iso_frame_desc[i] beyond the allocated region. KASAN confirmed this with kernel 7.0.0-rc5: BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640 Write of size 4 at addr ffff888106351d40 by task vhci_rx/69 The buggy address is located 0 bytes to the right of allocated 320-byte region [ffff888106351c00, ffff888106351d40) The server side (stub_rx.c) and gadget side (vudc_rx.c) already validate number_of_packets in the CMD_SUBMIT path since commits c6688ef9f297 ("usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input") and b78d830f0049 ("usbip: fix vudc_rx: harden CMD_SUBMIT path to handle malicious input"). The server side validates against USBIP_MAX_ISO_PACKETS because no URB exists yet at that point. On the client side we have the original URB, so we can use the tighter bound: the response must not exceed the original number_of_packets. This mirrors the existing validation of actual_length against transfer_buffer_length in usbip_recv_xbuff(), which checks the response value against the original allocation size. Kelvin Mbogo's series ("usb: usbip: fix integer overflow in usbip_recv_iso()", v2) hardens the receive-side functions themselves; this patch complements that work by catching the bad value at its source -- in usbip_pack_ret_submit() before the overwrite -- and using the tighter per-URB allocation bound rather than the global USBIP_MAX_ISO_PACKETS limit. Fix this by checking rpdu->number_of_packets against urb->number_of_packets in usbip_pack_ret_submit() before the overwrite. On violation, clamp to zero so that usbip_recv_iso() and usbip_pad_iso() safely return early. Fixes: 1325f85fa49f ("staging: usbip: bugfix add number of packets for isochronous frames") Cc: stable Acked-by: Shuah Khan Signed-off-by: Nathan Rebello Link: https://patch.msgid.link/20260402085259.234-1-nathan.c.rebello@gmail.com Signed-off-by: Greg Kroah-Hartman commit 6968c91fab05b8fc4d6700e0cf34472bb422df25 Author: Stefan Metzmacher Date: Fri Apr 10 12:48:54 2026 +0200 smb: server: avoid double-free in smb_direct_free_sendmsg after smb_direct_flush_send_list() commit 84ff995ae826aa6bbcc6c7b9ea569ff67c021d72 upstream. smb_direct_flush_send_list() already calls smb_direct_free_sendmsg(), so we should not call it again after post_sendmsg() moved it to the batch list. Reported-by: Ruikai Peng Closes: https://lore.kernel.org/linux-cifs/CAFD3drNOSJ05y3A+jNXSDxW-2w09KHQ0DivhxQ_pcc7immVVOQ@mail.gmail.com/ Fixes: 34abd408c8ba ("smb: server: make use of smbdirect_socket.send_io.bcredits") Cc: stable@kernel.org Cc: Steve French Cc: Tom Talpey Cc: Ruikai Peng Cc: Sergey Senozhatsky Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Cc: security@kernel.org Signed-off-by: Stefan Metzmacher Acked-by: Namjae Jeon Acked-by: Paulo Alcantara (Red Hat) Tested-by: Ruikai Peng Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit a9940dcbe5cb92482c04efc7341039ddf7dbf607 Author: Stefan Metzmacher Date: Fri Apr 10 12:48:54 2026 +0200 smb: client: avoid double-free in smbd_free_send_io() after smbd_send_batch_flush() commit 27b7c3e916218b5eb2ee350211140e961bfc49be upstream. smbd_send_batch_flush() already calls smbd_free_send_io(), so we should not call it again after smbd_post_send() moved it to the batch list. Reported-by: Ruikai Peng Closes: https://lore.kernel.org/linux-cifs/CAFD3drNOSJ05y3A+jNXSDxW-2w09KHQ0DivhxQ_pcc7immVVOQ@mail.gmail.com/ Fixes: 21538121efe6 ("smb: client: make use of smbdirect_socket.send_io.bcredits") Cc: stable@kernel.org Cc: Steve French Cc: Tom Talpey Cc: Long Li Cc: Ruikai Peng Cc: Sergey Senozhatsky Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Cc: security@kernel.org Acked-by: Paulo Alcantara (Red Hat) Acked-by: Namjae Jeon Signed-off-by: Stefan Metzmacher Tested-by: Ruikai Peng Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit dd53414e301beb915fe672dc4c4a51bafb917604 Author: Greg Kroah-Hartman Date: Mon Apr 6 15:46:48 2026 +0200 ksmbd: fix mechToken leak when SPNEGO decode fails after token alloc commit ad0057fb91218914d6c98268718ceb9d59b388e1 upstream. The kernel ASN.1 BER decoder calls action callbacks incrementally as it walks the input. When ksmbd_decode_negTokenInit() reaches the mechToken [2] OCTET STRING element, ksmbd_neg_token_alloc() allocates conn->mechToken immediately via kmemdup_nul(). If a later element in the same blob is malformed, then the decoder will return nonzero after the allocation is already live. This could happen if mechListMIC [3] overrunse the enclosing SEQUENCE. decode_negotiation_token() then sets conn->use_spnego = false because both the negTokenInit and negTokenTarg grammars failed. The cleanup at the bottom of smb2_sess_setup() is gated on use_spnego: if (conn->use_spnego && conn->mechToken) { kfree(conn->mechToken); conn->mechToken = NULL; } so the kfree is skipped, causing the mechToken to never be freed. This codepath is reachable pre-authentication, so untrusted clients can cause slow memory leaks on a server without even being properly authenticated. Fix this up by not checking check for use_spnego, as it's not required, so the memory will always be properly freed. At the same time, always free the memory in ksmbd_conn_free() incase some other failure path forgot to free it. Cc: Namjae Jeon Cc: Steve French Cc: Sergey Senozhatsky Cc: Tom Talpey Cc: linux-cifs@vger.kernel.org Cc: Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit d2454f4a002d08560a60f214f392e6491cf11560 Author: Greg Kroah-Hartman Date: Mon Apr 6 15:46:47 2026 +0200 ksmbd: require 3 sub-authorities before reading sub_auth[2] commit 53370cf9090777774e07fd9a8ebce67c6cc333ab upstream. parse_dacl() compares each ACE SID against sid_unix_NFS_mode and on match reads sid.sub_auth[2] as the file mode. If sid_unix_NFS_mode is the prefix S-1-5-88-3 with num_subauth = 2 then compare_sids() compares only min(num_subauth, 2) sub-authorities so a client SID with num_subauth = 2 and sub_auth = {88, 3} will match. If num_subauth = 2 and the ACE is placed at the very end of the security descriptor, sub_auth[2] will be 4 bytes past end_of_acl. The out-of-band bytes will then be masked to the low 9 bits and applied as the file's POSIX mode, probably not something that is good to have happen. Fix this up by forcing the SID to actually carry a third sub-authority before reading it at all. Cc: Namjae Jeon Cc: Steve French Cc: Sergey Senozhatsky Cc: Tom Talpey Cc: linux-cifs@vger.kernel.org Cc: Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 3363a770b193f555f29d76ddf4ced3305c0ccf6d Author: Greg Kroah-Hartman Date: Mon Apr 6 15:46:46 2026 +0200 ksmbd: validate EaNameLength in smb2_get_ea() commit 66751841212c2cc196577453c37f7774ff363f02 upstream. smb2_get_ea() reads ea_req->EaNameLength from the client request and passes it directly to strncmp() as the comparison length without verifying that the length of the name really is the size of the input buffer received. Fix this up by properly checking the size of the name based on the value received and the overall size of the request, to prevent a later strncmp() call to use the length as a "trusted" size of the buffer. Without this check, uninitialized heap values might be slowly leaked to the client. Cc: Namjae Jeon Cc: Steve French Cc: Sergey Senozhatsky Cc: Tom Talpey Cc: linux-cifs@vger.kernel.org Cc: Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit e0dd90d14cbbf318157ea8e3fb62ee68a28655ed Author: Greg Kroah-Hartman Date: Mon Apr 6 15:49:38 2026 +0200 smb: client: fix OOB reads parsing symlink error response commit 3df690bba28edec865cf7190be10708ad0ddd67e upstream. When a CREATE returns STATUS_STOPPED_ON_SYMLINK, smb2_check_message() returns success without any length validation, leaving the symlink parsers as the only defense against an untrusted server. symlink_data() walks SMB 3.1.1 error contexts with the loop test "p < end", but reads p->ErrorId at offset 4 and p->ErrorDataLength at offset 0. When the server-controlled ErrorDataLength advances p to within 1-7 bytes of end, the next iteration will read past it. When the matching context is found, sym->SymLinkErrorTag is read at offset 4 from p->ErrorContextData with no check that the symlink header itself fits. smb2_parse_symlink_response() then bounds-checks the substitute name using SMB2_SYMLINK_STRUCT_SIZE as the offset of PathBuffer from iov_base. That value is computed as sizeof(smb2_err_rsp) + sizeof(smb2_symlink_err_rsp), which is correct only when ErrorContextCount == 0. With at least one error context the symlink data sits 8 bytes deeper, and each skipped non-matching context shifts it further by 8 + ALIGN(ErrorDataLength, 8). The check is too short, allowing the substitute name read to run past iov_len. The out-of-bound heap bytes are UTF-16-decoded into the symlink target and returned to userspace via readlink(2). Fix this all up by making the loops test require the full context header to fit, rejecting sym if its header runs past end, and bound the substitute name against the actual position of sym->PathBuffer rather than a fixed offset. Because sub_offs and sub_len are 16bits, the pointer math will not overflow here with the new greater-than. Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Cc: stable Reviewed-by: Paulo Alcantara (Red Hat) Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit b2b76d09a64c538c57006180103fc1841e8cfa66 Author: Greg Kroah-Hartman Date: Mon Apr 6 15:49:37 2026 +0200 smb: client: fix off-by-8 bounds check in check_wsl_eas() commit 3d8b9d06bd3ac4c6846f5498800b0f5f8062e53b upstream. The bounds check uses (u8 *)ea + nlen + 1 + vlen as the end of the EA name and value, but ea_data sits at offset sizeof(struct smb2_file_full_ea_info) = 8 from ea, not at offset 0. The strncmp() later reads ea->ea_data[0..nlen-1] and the value bytes follow at ea_data[nlen+1..nlen+vlen], so the actual end is ea->ea_data + nlen + 1 + vlen. Isn't pointer math fun? The earlier check (u8 *)ea > end - sizeof(*ea) only guarantees the 8-byte header is in bounds, but since the last EA is placed within 8 bytes of the end of the response, the name and value bytes are read past the end of iov. Fix this mess all up by using ea->ea_data as the base for the bounds check. An "untrusted" server can use this to leak up to 8 bytes of kernel heap into the EA name comparison and influence which WSL xattr the data is interpreted as. Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Cc: stable Assisted-by: gregkh_clanker_t1000 Reviewed-by: Paulo Alcantara (Red Hat) Signed-off-by: Greg Kroah-Hartman Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 44216e3dd4455b798899b50eedb0ec3831dff8e0 Author: Greg Kroah-Hartman Date: Mon Apr 6 17:09:48 2026 +0200 usb: gadget: renesas_usb3: validate endpoint index in standard request handlers commit f880aac8a57ebd92abfa685d45424b2998ac1059 upstream. The GET_STATUS and SET/CLEAR_FEATURE handlers extract the endpoint number from the host-supplied wIndex without any sort of validation. Fix this up by validating the number of endpoints actually match up with the number the device has before attempting to dereference a pointer based on this math. This is just like what was done in commit ee0d382feb44 ("usb: gadget: aspeed_udc: validate endpoint index for ast udc") for the aspeed driver. Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller") Cc: stable Assisted-by: gregkh_clanker_t1000 Link: https://patch.msgid.link/2026040647-sincerity-untidy-b104@gregkh Signed-off-by: Greg Kroah-Hartman commit 4e476c25bfcab0535ba7c76a903ae77ca8747711 Author: Greg Kroah-Hartman Date: Tue Apr 7 10:55:05 2026 +0200 usb: gadget: f_phonet: fix skb frags[] overflow in pn_rx_complete() commit c088d5dd2fffb4de1fb8e7f57751c8b82942180a upstream. A broken/bored/mean USB host can overflow the skb_shared_info->frags[] array on a Linux gadget exposing a Phonet function by sending an unbounded sequence of full-page OUT transfers. pn_rx_complete() finalizes the skb only when req->actual < req->length, where req->length is set to PAGE_SIZE by the gadget. If the host always sends exactly PAGE_SIZE bytes per transfer, fp->rx.skb will never be reset and each completion will add another fragment via skb_add_rx_frag(). Once nr_frags exceeds MAX_SKB_FRAGS (default 17), subsequent frag stores overwrite memory adjacent to the shinfo on the heap. Drop the skb and account a length error when the frag limit is reached, matching the fix applied in t7xx by commit f0813bcd2d9d ("net: wwan: t7xx: fix potential skb->frags overflow in RX path"). Cc: stable Assisted-by: gregkh_clanker_t1000 Link: https://patch.msgid.link/2026040705-fruit-unloved-0701@gregkh Signed-off-by: Greg Kroah-Hartman commit 6762f8a95772265dd0c2ffe7f400493f3115b135 Author: Greg Kroah-Hartman Date: Tue Apr 7 11:02:54 2026 +0200 usb: gadget: f_ncm: validate minimum block_len in ncm_unwrap_ntb() commit 8f993d30b95dc9557a8a96ceca11abed674c8acb upstream. The block_len read from the host-supplied NTB header is checked against ntb_max but has no lower bound. When block_len is smaller than opts->ndp_size, the bounds check of: ndp_index > (block_len - opts->ndp_size) will underflow producing a huge unsigned value that ndp_index can never exceed, defeating the check entirely. The same underflow occurs in the datagram index checks against block_len - opts->dpe_size. With those checks neutered, a malicious USB host can choose ndp_index and datagram offsets that point past the actual transfer, and the skb_put_data() copies adjacent kernel memory into the network skb. Fix this by rejecting block lengths that cannot hold at least the NTB header plus one NDP. This will make block_len - opts->ndp_size and block_len - opts->dpe_size both well-defined. Commit 8d2b1a1ec9f5 ("CDC-NCM: avoid overflow in sanity checking") fixed a related class of issues on the host side of NCM. Fixes: 2b74b0a04d3e ("USB: gadget: f_ncm: add bounds checks to ncm_unwrap_ntb()") Cc: stable Assisted-by: gregkh_clanker_t1000 Link: https://patch.msgid.link/2026040753-baffle-handheld-624d@gregkh Signed-off-by: Greg Kroah-Hartman commit fc386daa6846551a88d338ba9864fc2812cd9030 Author: Greg Kroah-Hartman Date: Thu Apr 9 15:23:14 2026 +0200 fbdev: tdfxfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO commit 8f98b81fe011e1879e6a7b1247e69e06a5e17af2 upstream. Much like commit 19f953e74356 ("fbdev: fb_pm2fb: Avoid potential divide by zero error"), we also need to prevent that same crash from happening in the udlfb driver as it uses pixclock directly when dividing, which will crash. Cc: Helge Deller Assisted-by: gregkh_clanker_t1000 Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 67cfd14074cdafab5de3f7cfc0952c1a9b653e5d Author: Greg Kroah-Hartman Date: Thu Apr 9 16:05:54 2026 +0200 ALSA: fireworks: bound device-supplied status before string array lookup commit 07704bbf36f57e4379e4cadf96410dab14621e3b upstream. The status field in an EFW response is a 32-bit value supplied by the firewire device. efr_status_names[] has 17 entries so a status value outside that range goes off into the weeds when looking at the %s value. Even worse, the status could return EFR_STATUS_INCOMPLETE which is 0x80000000, and is obviously not in that array of potential strings. Fix this up by properly bounding the index against the array size and printing "unknown" if it's not recognized. Cc: Clemens Ladisch Cc: Takashi Sakamoto Cc: Jaroslav Kysela Cc: Takashi Iwai Fixes: bde8a8f23bbe ("ALSA: fireworks: Add transaction and some commands") Cc: stable Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Reviewed-by: Takashi Sakamoto Link: https://patch.msgid.link/2026040953-astute-camera-1aa1@gregkh Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 09b145c1f1331c40dc955c0024d636f25417cddb Author: Greg Kroah-Hartman Date: Thu Apr 9 16:01:56 2026 +0200 ALSA: usx2y: us144mkii: fix NULL deref on missing interface 0 commit 48bd344e1040b9f2eb512be73c13f5db83efc191 upstream. A malicious USB device with the TASCAM US-144MKII device id can have a configuration containing bInterfaceNumber=1 but no interface 0. USB configuration descriptors are not required to assign interface numbers sequentially, so usb_ifnum_to_if(dev, 0) returns will NULL, which will then be dereferenced directly. Fix this up by checking the return value properly. Cc: Jaroslav Kysela Cc: Takashi Iwai Fixes: dee1bcf28a3d ("ALSA: usb-audio: Add initial driver for TASCAM US-144MKII") Cc: stable Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2026040955-fall-gaining-e338@gregkh Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 0185e0494a561edfc482507f9de89c2ad798b33d Author: Greg Kroah-Hartman Date: Mon Feb 23 16:53:39 2026 +0100 drm/vc4: platform_get_irq_byname() returns an int commit e597a809a2b97e927060ba182f58eb3e6101bc70 upstream. platform_get_irq_byname() will return a negative value if an error happens, so it should be checked and not just passed directly into devm_request_threaded_irq() hoping all will be ok. Cc: Maxime Ripard Cc: Dave Stevenson Cc: Maíra Canal Cc: Raspberry Pi Kernel Maintenance Cc: Maarten Lankhorst Cc: Thomas Zimmermann Cc: David Airlie Cc: Simona Vetter Cc: stable Assisted-by: gkh_clanker_2000 Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2026022339-cornflake-t-shirt-2471@gregkh Signed-off-by: Maíra Canal Signed-off-by: Greg Kroah-Hartman commit 5a59bf70c38ee1eb4be03bab830bbc3a6f0bd1f1 Author: Greg Kroah-Hartman Date: Thu Apr 9 17:18:14 2026 +0200 NFC: digital: Bounds check NFC-A cascade depth in SDD response handler commit 46ce8be2ced389bccd84bcc04a12cf2f4d0c22d1 upstream. The NFC-A anti-collision cascade in digital_in_recv_sdd_res() appends 3 or 4 bytes to target->nfcid1 on each round, but the number of cascade rounds is controlled entirely by the peer device. The peer sets the cascade tag in the SDD_RES (deciding 3 vs 4 bytes) and the cascade-incomplete bit in the SEL_RES (deciding whether another round follows). ISO 14443-3 limits NFC-A to three cascade levels and target->nfcid1 is sized accordingly (NFC_NFCID1_MAXSIZE = 10), but nothing in the driver actually enforces this. This means a malicious peer can keep the cascade running, writing past the heap-allocated nfc_target with each round. Fix this by rejecting the response when the accumulated UID would exceed the buffer. Commit e329e71013c9 ("NFC: nci: Bounds check struct nfc_target arrays") fixed similar missing checks against the same field on the NCI path. Cc: Simon Horman Cc: Kees Cook Cc: Thierry Escande Cc: Samuel Ortiz Fixes: 2c66daecc409 ("NFC Digital: Add NFC-A technology support") Cc: stable Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2026040913-figure-seducing-bd3f@gregkh Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c183d5775129a0a7495bd61a6e57ec230dcf01e5 Author: Greg Kroah-Hartman Date: Sat Apr 11 13:01:35 2026 +0200 net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete() commit 600dc40554dc5ad1e6f3af51f700228033f43ea7 upstream. A malicious USB device claiming to be a CDC Phonet modem can overflow the skb_shared_info->frags[] array by sending an unbounded sequence of full-page bulk transfers. Drop the skb and increment the length error when the frag limit is reached. This matches the same fix that commit f0813bcd2d9d ("net: wwan: t7xx: fix potential skb->frags overflow in RX path") did for the t7xx driver. Cc: Andrew Lunn Cc: "David S. Miller" Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Paolo Abeni Cc: stable Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2026041134-dreamboat-buddhism-d1ec@gregkh Fixes: 87cf65601e17 ("USB host CDC Phonet network interface driver") Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 8a8333237f1f5caab8d4c3d2c2e7578c4263a97f Author: Greg Kroah-Hartman Date: Mon Apr 6 16:04:10 2026 +0200 HID: core: clamp report_size in s32ton() to avoid undefined shift commit 69c02ffde6ed4d535fa4e693a9e572729cad3d0d upstream. s32ton() shifts by n-1 where n is the field's report_size, a value that comes directly from a HID device. The HID parser bounds report_size only to <= 256, so a broken HID device can supply a report descriptor with a wide field that triggers shift exponents up to 256 on a 32-bit type when an output report is built via hid_output_field() or hid_set_field(). Commit ec61b41918587 ("HID: core: fix shift-out-of-bounds in hid_report_raw_event") added the same n > 32 clamp to the function snto32(), but s32ton() was never given the same fix as I guess syzbot hadn't figured out how to fuzz a device the same way. Fix this up by just clamping the max value of n, just like snto32() does. Cc: stable Cc: Jiri Kosina Cc: Benjamin Tissoires Cc: linux-input@vger.kernel.org Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 0091dfa542a362c178a7e9393097138a57d327d1 Author: Greg Kroah-Hartman Date: Mon Apr 6 16:03:25 2026 +0200 HID: alps: fix NULL pointer dereference in alps_raw_event() commit 1badfc4319224820d5d890f8eab6aa52e4e83339 upstream. Commit ecfa6f34492c ("HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them") attempted to fix up the HID drivers that had missed the previous fix that was done in 2ff5baa9b527 ("HID: appleir: Fix potential NULL dereference at raw event handle"), but the alps driver was missed. Fix this up by properly checking in the hid-alps driver that it had been claimed correctly before attempting to process the raw event. Fixes: 73196ebe134d ("HID: alps: add support for Alps T4 Touchpad device") Cc: stable Cc: Jiri Kosina Cc: Benjamin Tissoires Cc: Masaki Ota Cc: linux-input@vger.kernel.org Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit b487a7754d874230299d5a9c2710ec4df8b2ed8a Author: Lin YuChen Date: Sat Mar 21 01:25:02 2026 +0800 staging: rtl8723bs: initialize le_tmp64 in rtw_BIP_verify() commit 8c964b82a4e97ec7f25e17b803ee196009b38a57 upstream. Initialize le_tmp64 to zero in rtw_BIP_verify() to prevent using uninitialized data. Smatch warns that only 6 bytes are copied to this 8-byte (u64) variable, leaving the last two bytes uninitialized: drivers/staging/rtl8723bs/core/rtw_security.c:1308 rtw_BIP_verify() warn: not copying enough bytes for '&le_tmp64' (8 vs 6 bytes) Initializing the variable at the start of the function fixes this warning and ensures predictable behavior. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable Reported-by: Dan Carpenter Closes: https://lore.kernel.org/linux-staging/abvwIQh0CHTp4wNJ@stanley.mountain/ Signed-off-by: Lin YuChen Reviewed-by: Dan Carpenter Link: https://patch.msgid.link/20260320172502.167332-1-starpt.official@gmail.com Signed-off-by: Greg Kroah-Hartman commit 377fae22a137b6b89f3f32399a58c52cf2325416 Author: Greg Kroah-Hartman Date: Mon Feb 23 18:05:15 2026 +0100 i2c: s3c24xx: check the size of the SMBUS message before using it commit c0128c7157d639a931353ea344fb44aad6d6e17a upstream. The first byte of an i2c SMBUS message is the size, and it should be verified to ensure that it is in the range of 0..I2C_SMBUS_BLOCK_MAX before processing it. This is the same logic that was added in commit a6e04f05ce0b ("i2c: tegra: check msg length in SMBUS block read") to the i2c tegra driver. Cc: Krzysztof Kozlowski Cc: Alim Akhtar Cc: Andi Shyti Cc: stable Assisted-by: gkh_clanker_2000 Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/2026022314-rely-scrubbed-4839@gregkh Signed-off-by: Greg Kroah-Hartman commit 1a0f2de81f7fbdc538fc72d7d74609b79bc83cc0 Author: Samuel Page Date: Wed Apr 8 15:30:13 2026 +0100 can: raw: fix ro->uniq use-after-free in raw_rcv() commit a535a9217ca3f2fccedaafb2fddb4c48f27d36dc upstream. raw_release() unregisters raw CAN receive filters via can_rx_unregister(), but receiver deletion is deferred with call_rcu(). This leaves a window where raw_rcv() may still be running in an RCU read-side critical section after raw_release() frees ro->uniq, leading to a use-after-free of the percpu uniq storage. Move free_percpu(ro->uniq) out of raw_release() and into a raw-specific socket destructor. can_rx_unregister() takes an extra reference to the socket and only drops it from the RCU callback, so freeing uniq from sk_destruct ensures the percpu area is not released until the relevant callbacks have drained. Fixes: 514ac99c64b2 ("can: fix multiple delivery of a single CAN frame for overlapping CAN filters") Cc: stable@vger.kernel.org # v4.1+ Assisted-by: Bynario AI Signed-off-by: Samuel Page Link: https://patch.msgid.link/26ec626d-cae7-4418-9782-7198864d070c@bynar.io Acked-by: Oliver Hartkopp [mkl: applied manually] Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 8977fad2b3c6eefd414131168d597c5d1d5e1abf Author: Junxi Qian Date: Wed Apr 8 16:10:06 2026 +0800 nfc: llcp: add missing return after LLCP_CLOSED checks commit 2b5dd4632966c39da6ba74dbc8689b309065e82c upstream. In nfc_llcp_recv_hdlc() and nfc_llcp_recv_disc(), when the socket state is LLCP_CLOSED, the code correctly calls release_sock() and nfc_llcp_sock_put() but fails to return. Execution falls through to the remainder of the function, which calls release_sock() and nfc_llcp_sock_put() again. This results in a double release_sock() and a refcount underflow via double nfc_llcp_sock_put(), leading to a use-after-free. Add the missing return statements after the LLCP_CLOSED branches in both functions to prevent the fall-through. Fixes: d646960f7986 ("NFC: Initial LLCP support") Signed-off-by: Junxi Qian Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260408081006.3723-1-qjx1298677004@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 67c53c1978cef3c504237275e39c857e2f6af56e Author: Florian Westphal Date: Tue Mar 10 00:28:29 2026 +0100 netfilter: conntrack: add missing netlink policy validations [ Upstream commit f900e1d77ee0ef87bfb5ab3fe60f0b3d8ad5ba05 ] Hyunwoo Kim reports out-of-bounds access in sctp and ctnetlink. These attributes are used by the kernel without any validation. Extend the netlink policies accordingly. Quoting the reporter: nlattr_to_sctp() assigns the user-supplied CTA_PROTOINFO_SCTP_STATE value directly to ct->proto.sctp.state without checking that it is within the valid range. [..] and: ... with exp->dir = 100, the access at ct->master->tuplehash[100] reads 5600 bytes past the start of a 320-byte nf_conn object, causing a slab-out-of-bounds read confirmed by UBSAN. Fixes: 076a0ca02644 ("netfilter: ctnetlink: add NAT support for expectations") Fixes: a258860e01b8 ("netfilter: ctnetlink: add full support for SCTP to ctnetlink") Reported-by: Hyunwoo Kim Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 78cea133daf721698876e56135049a96d39d610a Author: Herbert Xu Date: Sun Apr 12 13:32:21 2026 +0800 crypto: algif_aead - Fix minimum RX size check for decryption [ Upstream commit 3d14bd48e3a77091cbce637a12c2ae31b4a1687c ] The check for the minimum receive buffer size did not take the tag size into account during decryption. Fix this by adding the required extra length. Reported-by: syzbot+aa11561819dc42ebbc7c@syzkaller.appspotmail.com Reported-by: Daniel Pouzzner Fixes: d887c52d6ae4 ("crypto: algif_aead - overhaul memory management") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit dea5fcf085f977b6c2de1b2d4ec4767b6c840d1f Author: Herbert Xu Date: Sat Apr 4 08:29:58 2026 +0800 crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl [ Upstream commit 31d00156e50ecad37f2cb6cbf04aaa9a260505ef ] When page reassignment was added to af_alg_pull_tsgl the original loop wasn't updated so it may try to reassign one more page than necessary. Add the check to the reassignment so that this does not happen. Also update the comment which still refers to the obsolete offset argument. Reported-by: syzbot+d23888375c2737c17ba5@syzkaller.appspotmail.com Fixes: e870456d8e7c ("crypto: algif_skcipher - overhaul memory management") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 66dfc9179b78a8d20889063ebcd86a911f0d16b7 Author: Peter Zijlstra Date: Sat Apr 4 12:22:44 2026 +0200 sched/deadline: Use revised wakeup rule for dl_server [ Upstream commit 14a857056466be9d3d907a94e92a704ac1be149b ] John noted that commit 115135422562 ("sched/deadline: Fix 'stuck' dl_server") unfixed the issue from commit a3a70caf7906 ("sched/deadline: Fix dl_server behaviour"). The issue in commit 115135422562 was for wakeups of the server after the deadline; in which case you *have* to start a new period. The case for a3a70caf7906 is wakeups before the deadline. Now, because the server is effectively running a least-laxity policy, it means that any wakeup during the runnable phase means dl_entity_overflow() will be true. This means we need to adjust the runtime to allow it to still run until the existing deadline expires. Use the revised wakeup rule for dl_defer entities. Fixes: 115135422562 ("sched/deadline: Fix 'stuck' dl_server") Reported-by: John Stultz Signed-off-by: Peter Zijlstra (Intel) Acked-by: Juri Lelli Tested-by: John Stultz Link: https://patch.msgid.link/20260404102244.GB22575@noisy.programming.kicks-ass.net Signed-off-by: Sasha Levin commit f34feda8e0c9535fee3f8870ce8bab53c2798f71 Author: Zide Chen Date: Fri Mar 13 10:40:48 2026 -0700 perf/x86/intel/uncore: Skip discovery table for offline dies [ Upstream commit 7b568e9eba2fad89a696f22f0413d44cf4a1f892 ] This warning can be triggered if NUMA is disabled and the system boots with fewer CPUs than the number of CPUs in die 0. WARNING: CPU: 9 PID: 7257 at uncore.c:1157 uncore_pci_pmu_register+0x136/0x160 [intel_uncore] Currently, the discovery table continues to be parsed even if all CPUs in the associated die are offline. This can lead to an array overflow at "pmu->boxes[die] = box" in uncore_pci_pmu_register(), which may trigger the warning above or cause other issues. Fixes: edae1f06c2cd ("perf/x86/intel/uncore: Parse uncore discovery tables") Reported-by: Steve Wahl Signed-off-by: Zide Chen Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dapeng Mi Tested-by: Steve Wahl Link: https://patch.msgid.link/20260313174050.171704-3-zide.chen@intel.com Signed-off-by: Sasha Levin commit 07c6f6ffe29009426f0bd4d3cfbb6308b8ea8453 Author: Douya Le Date: Thu Apr 2 23:34:55 2026 +0800 crypto: af_alg - limit RX SG extraction by receive buffer budget [ Upstream commit 8eceab19eba9dcbfd2a0daec72e1bf48aa100170 ] Make af_alg_get_rsgl() limit each RX scatterlist extraction to the remaining receive buffer budget. af_alg_get_rsgl() currently uses af_alg_readable() only as a gate before extracting data into the RX scatterlist. Limit each extraction to the remaining af_alg_rcvbuf(sk) budget so that receive-side accounting matches the amount of data attached to the request. If skcipher cannot obtain enough RX space for at least one chunk while more data remains to be processed, reject the recvmsg call instead of rounding the request length down to zero. Fixes: e870456d8e7c8d57c059ea479b5aadbb55ff4c3a ("crypto: algif_skcipher - overhaul memory management") Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Signed-off-by: Douya Le Signed-off-by: Ren Wei Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 7af379af9d34db1f94361968f741f91a65be5861 Author: Samasth Norway Ananda Date: Tue Apr 7 14:02:47 2026 -0700 gpio: tegra: fix irq_release_resources calling enable instead of disable [ Upstream commit 1561d96f5f55c1bca9ff047ace5813f4f244eea6 ] tegra_gpio_irq_release_resources() erroneously calls tegra_gpio_enable() instead of tegra_gpio_disable(). When IRQ resources are released, the GPIO configuration bit (CNF) should be cleared to deconfigure the pin as a GPIO. Leaving it enabled wastes power and can cause unexpected behavior if the pin is later reused for an alternate function via pinctrl. Fixes: 66fecef5bde0 ("gpio: tegra: Convert to gpio_irq_chip") Signed-off-by: Samasth Norway Ananda Link: https://patch.msgid.link/20260407210247.1737938-1-samasth.norway.ananda@oracle.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 86534c97abd6365a9a021fd767a2023e63c44469 Author: Alice Mikityanska Date: Fri Apr 3 20:49:49 2026 +0300 l2tp: Drop large packets with UDP encap [ Upstream commit ebe560ea5f54134279356703e73b7f867c89db13 ] syzbot reported a WARN on my patch series [1]. The actual issue is an overflow of 16-bit UDP length field, and it exists in the upstream code. My series added a debug WARN with an overflow check that exposed the issue, that's why syzbot tripped on my patches, rather than on upstream code. syzbot's repro: r0 = socket$pppl2tp(0x18, 0x1, 0x1) r1 = socket$inet6_udp(0xa, 0x2, 0x0) connect$inet6(r1, &(0x7f00000000c0)={0xa, 0x0, 0x0, @loopback, 0xfffffffc}, 0x1c) connect$pppl2tp(r0, &(0x7f0000000240)=@pppol2tpin6={0x18, 0x1, {0x0, r1, 0x4, 0x0, 0x0, 0x0, {0xa, 0x4e22, 0xffff, @ipv4={'\x00', '\xff\xff', @empty}}}}, 0x32) writev(r0, &(0x7f0000000080)=[{&(0x7f0000000000)="ee", 0x34000}], 0x1) It basically sends an oversized (0x34000 bytes) PPPoL2TP packet with UDP encapsulation, and l2tp_xmit_core doesn't check for overflows when it assigns the UDP length field. The value gets trimmed to 16 bites. Add an overflow check that drops oversized packets and avoids sending packets with trimmed UDP length to the wire. syzbot's stack trace (with my patch applied): len >= 65536u WARNING: ./include/linux/udp.h:38 at udp_set_len_short include/linux/udp.h:38 [inline], CPU#1: syz.0.17/5957 WARNING: ./include/linux/udp.h:38 at l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline], CPU#1: syz.0.17/5957 WARNING: ./include/linux/udp.h:38 at l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327, CPU#1: syz.0.17/5957 Modules linked in: CPU: 1 UID: 0 PID: 5957 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:udp_set_len_short include/linux/udp.h:38 [inline] RIP: 0010:l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline] RIP: 0010:l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327 Code: 0f 0b 90 e9 21 f9 ff ff e8 e9 05 ec f6 90 0f 0b 90 e9 8d f9 ff ff e8 db 05 ec f6 90 0f 0b 90 e9 cc f9 ff ff e8 cd 05 ec f6 90 <0f> 0b 90 e9 de fa ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 0f 8c 4f RSP: 0018:ffffc90003d67878 EFLAGS: 00010293 RAX: ffffffff8ad985e3 RBX: ffff8881a6400090 RCX: ffff8881697f0000 RDX: 0000000000000000 RSI: 0000000000034010 RDI: 000000000000ffff RBP: dffffc0000000000 R08: 0000000000000003 R09: 0000000000000004 R10: dffffc0000000000 R11: fffff520007acf00 R12: ffff8881baf20900 R13: 0000000000034010 R14: ffff8881a640008e R15: ffff8881760f7000 FS: 000055557e81f500(0000) GS:ffff8882a9467000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000033000 CR3: 00000001612f4000 CR4: 00000000000006f0 Call Trace: pppol2tp_sendmsg+0x40a/0x5f0 net/l2tp/l2tp_ppp.c:302 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] sock_write_iter+0x503/0x550 net/socket.c:1195 do_iter_readv_writev+0x619/0x8c0 fs/read_write.c:-1 vfs_writev+0x33c/0x990 fs/read_write.c:1059 do_writev+0x154/0x2e0 fs/read_write.c:1105 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f636479c629 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:00007ffffd4241c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 RAX: ffffffffffffffda RBX: 00007f6364a15fa0 RCX: 00007f636479c629 RDX: 0000000000000001 RSI: 0000200000000080 RDI: 0000000000000003 RBP: 00007f6364832b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6364a15fac R14: 00007f6364a15fa0 R15: 00007f6364a15fa0 [1]: https://lore.kernel.org/all/20260226201600.222044-1-alice.kernel@fastmail.im/ Fixes: 3557baabf280 ("[L2TP]: PPP over L2TP driver core") Reported-by: syzbot+ci3edea60a44225dec@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/69a1dfba.050a0220.3a55be.0026.GAE@google.com/ Signed-off-by: Alice Mikityanska Link: https://patch.msgid.link/20260403174949.843941-1-alice.kernel@fastmail.im Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 2d2dc166d55148cfcf8ae67b415f8d6d110e6fca Author: Alexander Koskovich Date: Fri Apr 3 18:43:48 2026 +0200 net: ipa: fix event ring index not programmed for IPA v5.0+ [ Upstream commit 56007972c0b1e783ca714d6f1f4d6e66e531d21f ] For IPA v5.0+, the event ring index field moved from CH_C_CNTXT_0 to CH_C_CNTXT_1. The v5.0 register definition intended to define this field in the CH_C_CNTXT_1 fmask array but used the old identifier of ERINDEX instead of CH_ERINDEX. Without a valid event ring, GSI channels could never signal transfer completions. This caused gsi_channel_trans_quiesce() to block forever in wait_for_completion(). At least for IPA v5.2 this resolves an issue seen where runtime suspend, system suspend, and remoteproc stop all hanged forever. It also meant the IPA data path was completely non functional. Fixes: faf0678ec8a0 ("net: ipa: add IPA v5.0 GSI register definitions") Signed-off-by: Alexander Koskovich Signed-off-by: Luca Weiss Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260403-milos-ipa-v1-2-01e9e4e03d3e@fairphone.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit bafc45ea30d297002750396d5f10e3018bf2cd60 Author: Alexander Koskovich Date: Fri Apr 3 18:43:47 2026 +0200 net: ipa: fix GENERIC_CMD register field masks for IPA v5.0+ [ Upstream commit 9709b56d908acc120fe8b4ae250b3c9d749ea832 ] Fix the field masks to match the hardware layout documented in downstream GSI (GSI_V3_0_EE_n_GSI_EE_GENERIC_CMD_*). Notably this fixes a WARN I was seeing when I tried to send "stop" to the MPSS remoteproc while IPA was up. Fixes: faf0678ec8a0 ("net: ipa: add IPA v5.0 GSI register definitions") Signed-off-by: Alexander Koskovich Signed-off-by: Luca Weiss Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260403-milos-ipa-v1-1-01e9e4e03d3e@fairphone.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit a31b3ee4dba022b7691a33b04fdc0c27ac0f4504 Author: Li RongQing Date: Mon Apr 6 22:27:30 2026 -0400 devlink: Fix incorrect skb socket family dumping [ Upstream commit 0006c6f1091bbeea88b8a88a6548b9fb2f803c74 ] The devlink_fmsg_dump_skb function was incorrectly using the socket type (sk->sk_type) instead of the socket family (sk->sk_family) when filling the "family" field in the fast message dump. This patch fixes this to properly display the socket family. Fixes: 3dbfde7f6bc7b8 ("devlink: add devlink_fmsg_dump_skb() function") Signed-off-by: Li RongQing Link: https://patch.msgid.link/20260407022730.2393-1-lirongqing@baidu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 900a4e0910e98b8caef117d5df00471fa438dcf9 Author: Jiexun Wang Date: Tue Apr 7 16:00:14 2026 +0800 af_unix: read UNIX_DIAG_VFS data under unix_state_lock [ Upstream commit 39897df386376912d561d4946499379effa1e7ef ] Exact UNIX diag lookups hold a reference to the socket, but not to u->path. Meanwhile, unix_release_sock() clears u->path under unix_state_lock() and drops the path reference after unlocking. Read the inode and device numbers for UNIX_DIAG_VFS while holding unix_state_lock(), then emit the netlink attribute after dropping the lock. This keeps the VFS data stable while the reply is being built. Fixes: 5f7b0569460b ("unix_diag: Unix inode info NLA") Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Tested-by: Ren Wei Signed-off-by: Jiexun Wang Signed-off-by: Ren Wei Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260407080015.1744197-1-n05ec@lzu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8eff73e58e1f8fe991522acb863164319a7f7dd3 Author: Fabio Baltieri Date: Sun Apr 5 23:20:13 2026 +0100 net: txgbe: leave space for null terminators on property_entry [ Upstream commit 5a37d228799b0ec2c277459c83c814a59d310bc3 ] Lists of struct property_entry are supposed to be terminated with an empty property, this driver currently seems to be allocating exactly the amount of entry used. Change the struct definition to leave an extra element for all property_entry. Fixes: c3e382ad6d15 ("net: txgbe: Add software nodes to support phylink") Signed-off-by: Fabio Baltieri Tested-by: Jiawen Wu Link: https://patch.msgid.link/20260405222013.5347-1-fabio.baltieri@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6d1d9ed9b409e0662241e3d245d574a18f643494 Author: Justin Iurman Date: Sat Apr 4 15:41:37 2026 +0200 net: ioam6: fix OOB and missing lock [ Upstream commit b30b1675aa2bcf0491fd3830b051df4e08a7c8ca ] When trace->type.bit6 is set: if (trace->type.bit6) { ... queue = skb_get_tx_queue(dev, skb); qdisc = rcu_dereference(queue->qdisc); This code can lead to an out-of-bounds access of the dev->_tx[] array when is_input is true. In such a case, the packet is on the RX path and skb->queue_mapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues. Add a check to avoid this situation since skb_get_tx_queue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature. While at it, add missing lock around qdisc_qstats_qlen_backlog(). The function __ioam6_fill_trace_data() is called from both softirq and process contexts, hence the use of spin_lock_bh() here. Fixes: b63c5478e9cb ("ipv6: ioam: Support for Queue depth data field") Reported-by: Jakub Kicinski Closes: https://lore.kernel.org/netdev/20260403214418.2233266-2-kuba@kernel.org/ Signed-off-by: Justin Iurman Link: https://patch.msgid.link/20260404134137.24553-1-justin.iurman@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 607b86397622191feab4f07a6fbbf0585325e3ec Author: Felix Gu Date: Sun Apr 5 14:51:52 2026 +0800 net: mdio: realtek-rtl9300: use scoped device_for_each_child_node loop [ Upstream commit c09ea768bdb975e828f8e17293c397c3d14ad85d ] Switch to device_for_each_child_node_scoped() to auto-release fwnode references on early exit. Fixes: 24e31e474769 ("net: mdio: Add RTL9300 MDIO driver") Signed-off-by: Felix Gu Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260405-rtl9300-v1-1-08e4499cf944@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8c3984a0872c159d032d5dd67fb8703e02b2db1f Author: Syed Saba Kareem Date: Wed Apr 8 19:00:06 2026 +0530 ASoC: amd: acp: update DMI quirk and add ACP DMIC for Lenovo platforms [ Upstream commit 6b6f7263d626886a96fce6352f94dfab7a24c339 ] Replace DMI_EXACT_MATCH with DMI_MATCH for Lenovo SKU entries (21YW, 21YX) so the quirk applies to all variants of these models, not just exact SKU matches. Add ASOC_SDW_ACP_DMIC flag alongside ASOC_SDW_CODEC_SPKR in driver_data for these Lenovo platform entries, as these platforms use ACP PDM DMIC instead of SoundWire DMIC for digital microphone support. Fixes: 3acf517e1ae0 ("ASoC: amd: amd_sdw: add machine driver quirk for Lenovo models") Tested-by: Mark Pearson Reviewed-by: Mark Pearson Signed-off-by: Syed Saba Kareem Reviewed-by: Vijendar Mukunda Link: https://patch.msgid.link/20260408133029.1368317-1-syed.sabakareem@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c877bc8058a972418f99c022bf12c68a7325b22f Author: Maciej Strozek Date: Wed Apr 8 10:38:31 2026 +0100 ASoC: SDCA: Fix overwritten var within for loop [ Upstream commit 23e0cbe55736de222ed975863cf06baf29bee5fe ] mask variable should not be overwritten within the for loop or it will skip certain bits. Change to using BIT() macro. Fixes: b9ab3b618241 ("ASoC: SDCA: Add some initial IRQ handlers") Signed-off-by: Maciej Strozek Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20260408093835.2881486-2-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 41e3652a178cb0eecd48e0e6e27fbb73a004046a Author: Florian Westphal Date: Tue Apr 7 17:00:01 2026 +0200 netfilter: nfnetlink_queue: make hash table per queue [ Upstream commit 936206e3f6ff411581e615e930263d6f8b78df9d ] Sharing a global hash table among all queues is tempting, but it can cause crash: BUG: KASAN: slab-use-after-free in nfqnl_recv_verdict+0x11ac/0x15e0 [nfnetlink_queue] [..] nfqnl_recv_verdict+0x11ac/0x15e0 [nfnetlink_queue] nfnetlink_rcv_msg+0x46a/0x930 kmem_cache_alloc_node_noprof+0x11e/0x450 struct nf_queue_entry is freed via kfree, but parallel cpu can still encounter such an nf_queue_entry when walking the list. Alternative fix is to free the nf_queue_entry via kfree_rcu() instead, but as we have to alloc/free for each skb this will cause more mem pressure. Cc: Scott Mitchell Fixes: e19079adcd26 ("netfilter: nfnetlink_queue: optimize verdict lookup with hash table") Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 06e054ace8b8c39750df764669a645b7d3224e2f Author: Scott Mitchell Date: Sat Jan 17 09:32:30 2026 -0800 netfilter: nfnetlink_queue: nfqnl_instance GFP_ATOMIC -> GFP_KERNEL_ACCOUNT allocation [ Upstream commit a4400a5b343d1bc4aa8f685608515413238e7ee2 ] Currently, instance_create() uses GFP_ATOMIC because it's called while holding instances_lock spinlock. This makes allocation more likely to fail under memory pressure. Refactor nfqnl_recv_config() to drop RCU lock after instance_lookup() and peer_portid verification. A socket cannot simultaneously send a message and close, so the queue owned by the sending socket cannot be destroyed while processing its CONFIG message. This allows instance_create() to allocate with GFP_KERNEL_ACCOUNT before taking the spinlock. Suggested-by: Florian Westphal Signed-off-by: Scott Mitchell Signed-off-by: Florian Westphal Stable-dep-of: 936206e3f6ff ("netfilter: nfnetlink_queue: make hash table per queue") Signed-off-by: Sasha Levin commit 807d6ee15804df6f01a35c910f09612e858739a6 Author: Zhengchuan Liang Date: Sat Apr 4 17:39:47 2026 +0800 netfilter: ip6t_eui64: reject invalid MAC header for all packets [ Upstream commit fdce0b3590f724540795b874b4c8850c90e6b0a8 ] `eui64_mt6()` derives a modified EUI-64 from the Ethernet source address and compares it with the low 64 bits of the IPv6 source address. The existing guard only rejects an invalid MAC header when `par->fragoff != 0`. For packets with `par->fragoff == 0`, `eui64_mt6()` can still reach `eth_hdr(skb)` even when the MAC header is not valid. Fix this by removing the `par->fragoff != 0` condition so that packets with an invalid MAC header are rejected before accessing `eth_hdr(skb)`. Fixes: 1da177e4c3f41 ("Linux-2.6.12-rc2") Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Tested-by: Ren Wei Signed-off-by: Zhengchuan Liang Signed-off-by: Ren Wei Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 8368ce8eb01f0b91111d814703696e780d0ef12f Author: Ren Wei Date: Fri Apr 3 23:52:52 2026 +0800 netfilter: xt_multiport: validate range encoding in checkentry [ Upstream commit ff64c5bfef12461df8450e0f50bb693b5269c720 ] ports_match_v1() treats any non-zero pflags entry as the start of a port range and unconditionally consumes the next ports[] element as the range end. The checkentry path currently validates protocol, flags and count, but it does not validate the range encoding itself. As a result, malformed rules can mark the last slot as a range start or place two range starts back to back, leaving ports_match_v1() to step past the last valid ports[] element while interpreting the rule. Reject malformed multiport v1 rules in checkentry by validating that each range start has a following element and that the following element is not itself marked as another range start. Fixes: a89ecb6a2ef7 ("[NETFILTER]: x_tables: unify IPv4/IPv6 multiport match") Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Tested-by: Yuhang Zheng Signed-off-by: Ren Wei Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit d552bcfca323d175664d7444989b04f55666978a Author: Xiang Mei Date: Wed Apr 1 14:20:57 2026 -0700 netfilter: nfnetlink_log: initialize nfgenmsg in NLMSG_DONE terminator [ Upstream commit 1f3083aec8836213da441270cdb1ab612dd82cf4 ] When batching multiple NFLOG messages (inst->qlen > 1), __nfulnl_send() appends an NLMSG_DONE terminator with sizeof(struct nfgenmsg) payload via nlmsg_put(), but never initializes the nfgenmsg bytes. The nlmsg_put() helper only zeroes alignment padding after the payload, not the payload itself, so four bytes of stale kernel heap data are leaked to userspace in the NLMSG_DONE message body. Use nfnl_msg_put() to build the NLMSG_DONE terminator, which initializes the nfgenmsg payload via nfnl_fill_hdr(), consistent with how __build_packet_message() already constructs NFULNL_MSG_PACKET headers. Fixes: 29c5d4afba51 ("[NETFILTER]: nfnetlink_log: fix sending of multipart messages") Reported-by: Weiming Shi Signed-off-by: Xiang Mei Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit a32dabacee111cea083ddd57a03635672e1bff29 Author: Weiming Shi Date: Wed Apr 1 15:58:01 2026 +0800 ipvs: fix NULL deref in ip_vs_add_service error path [ Upstream commit 9a91797e61d286805ae10a92cc48959c30800556 ] When ip_vs_bind_scheduler() succeeds in ip_vs_add_service(), the local variable sched is set to NULL. If ip_vs_start_estimator() subsequently fails, the out_err cleanup calls ip_vs_unbind_scheduler(svc, sched) with sched == NULL. ip_vs_unbind_scheduler() passes the cur_sched NULL check (because svc->scheduler was set by the successful bind) but then dereferences the NULL sched parameter at sched->done_service, causing a kernel panic at offset 0x30 from NULL. Oops: general protection fault, [..] [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] RIP: 0010:ip_vs_unbind_scheduler (net/netfilter/ipvs/ip_vs_sched.c:69) Call Trace: ip_vs_add_service.isra.0 (net/netfilter/ipvs/ip_vs_ctl.c:1500) do_ip_vs_set_ctl (net/netfilter/ipvs/ip_vs_ctl.c:2809) nf_setsockopt (net/netfilter/nf_sockopt.c:102) [..] Fix by simply not clearing the local sched variable after a successful bind. ip_vs_unbind_scheduler() already detects whether a scheduler is installed via svc->scheduler, and keeping sched non-NULL ensures the error path passes the correct pointer to both ip_vs_unbind_scheduler() and ip_vs_scheduler_put(). While the bug is older, the problem popups in more recent kernels (6.2), when the new error path is taken after the ip_vs_start_estimator() call. Fixes: 705dd3444081 ("ipvs: use kthreads for stats estimation") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Acked-by: Simon Horman Acked-by: Julian Anastasov Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 585fe11fedb81f16ef370bfc2f62eaa206878c14 Author: Daniel Golle Date: Sun Apr 5 22:29:19 2026 +0100 selftests: net: bridge_vlan_mcast: wait for h1 before querier check [ Upstream commit efaa71faf212324ecbf6d5339e9717fe53254f58 ] The querier-interval test adds h1 (currently a slave of the VRF created by simple_if_init) to a temporary bridge br1 acting as an outside IGMP querier. The kernel VRF driver (drivers/net/vrf.c) calls cycle_netdev() on every slave add and remove, toggling the interface admin-down then up. Phylink takes the PHY down during the admin-down half of that cycle. Since h1 and swp1 are cable-connected, swp1 also loses its link may need several seconds to re-negotiate. Use setup_wait_dev $h1 0 which waits for h1 to return to UP state, so the test can rely on the link being back up at this point. Fixes: 4d8610ee8bd77 ("selftests: net: bridge: add vlan mcast_querier_interval tests") Signed-off-by: Daniel Golle Reviewed-by: Alexander Sverdlin Link: https://patch.msgid.link/c830f130860fd2efae08bfb9e5b25fd028e58ce5.1775424423.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8083b7da229b369a92e7d3fab5694d73eb7d59c0 Author: Vinay Belgaumkar Date: Tue Mar 31 18:27:10 2026 -0700 drm/xe: Fix bug in idledly unit conversion [ Upstream commit 7596459f3c93d8d45a1bf12d4d7526b50c15baa2 ] We only need to convert to picosecond units before writing to RING_IDLEDLY. Fixes: 7c53ff050ba8 ("drm/xe: Apply Wa_16023105232") Cc: Tangudu Tilak Tirumalesh Acked-by: Tangudu Tilak Tirumalesh Signed-off-by: Vinay Belgaumkar Link: https://patch.msgid.link/20260401012710.4165547-1-vinay.belgaumkar@intel.com (cherry picked from commit 13743bd628bc9d9a0e2fe53488b2891aedf7cc74) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit a4532ec7b8855924f509045ccfeb9995c72de8d9 Author: Cezary Rojewski Date: Tue Apr 7 10:54:58 2026 +0200 ASoC: Intel: avs: Fix memory leak in avs_register_i2s_test_boards() [ Upstream commit c5408d818316061d6063c11a4f47f1ba25a3a708 ] Caller is responsible for freeing array allocated with parse_int_array(). Found out by Coverity. Fixes: 7d859189de13 ("ASoC: Intel: avs: Allow to specify custom configurations with i2s_test") Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20260407085459.400628-1-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f779a6b6cdb6e12baa0663063ac59ab2a8f20c0c Author: Greg Kroah-Hartman Date: Mon Apr 6 17:33:03 2026 +0200 xfrm_user: fix info leak in build_mapping() [ Upstream commit 1beb76b2053b68c491b78370794b8ff63c8f8c02 ] struct xfrm_usersa_id has a one-byte padding hole after the proto field, which ends up never getting set to zero before copying out to userspace. Fix that up by zeroing out the whole structure before setting individual variables. Fixes: 3a2dfbe8acb1 ("xfrm: Notify changes in UDP encapsulation via netlink") Cc: Steffen Klassert Cc: Herbert Xu Cc: "David S. Miller" Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Paolo Abeni Cc: Simon Horman Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 836ee1b0426ea3db31531e9581cc32f513d24e32 Author: Kotlyarov Mihail Date: Sat Apr 4 12:05:20 2026 +0300 xfrm: fix refcount leak in xfrm_migrate_policy_find [ Upstream commit 83317cce60a032c49480dcdabe146435bd689d03 ] syzkaller reported a memory leak in xfrm_policy_alloc: BUG: memory leak unreferenced object 0xffff888114d79000 (size 1024): comm "syz.1.17", pid 931 ... xfrm_policy_alloc+0xb3/0x4b0 net/xfrm/xfrm_policy.c:432 The root cause is a double call to xfrm_pol_hold_rcu() in xfrm_migrate_policy_find(). The lookup function already returns a policy with held reference, making the second call redundant. Remove the redundant xfrm_pol_hold_rcu() call to fix the refcount imbalance and prevent the memory leak. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 563d5ca93e88 ("xfrm: switch migrate to xfrm_policy_lookup_bytype") Signed-off-by: Kotlyarov Mihail Reviewed-by: Florian Westphal Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 3733fce2871c9bca9dd18a1a23b1432ea215a094 Author: Steffen Klassert Date: Thu Apr 2 13:31:04 2026 +0200 xfrm: Wait for RCU readers during policy netns exit [ Upstream commit 069daad4f2ae9c5c108131995529d5f02392c446 ] xfrm_policy_fini() frees the policy_bydst hash tables after flushing the policy work items and deleting all policies, but it does not wait for concurrent RCU readers to leave their read-side critical sections first. The policy_bydst tables are published via rcu_assign_pointer() and are looked up through rcu_dereference_check(), so netns teardown must also wait for an RCU grace period before freeing the table memory. Fix this by adding synchronize_rcu() before freeing the policy hash tables. Fixes: e1e551bc5630 ("xfrm: policy: prepare policy_bydst hash for rcu lookups") Signed-off-by: Steffen Klassert Reviewed-by: Florian Westphal Signed-off-by: Sasha Levin commit 25e1e91a8da819924df0b16e3812d7b24c8ce133 Author: Maciej Fijalkowski Date: Thu Apr 2 17:49:54 2026 +0200 xsk: validate MTU against usable frame size on bind [ Upstream commit 36ee60b569ba0dfb6f961333b90d19ab5b323fa9 ] AF_XDP bind currently accepts zero-copy pool configurations without verifying that the device MTU fits into the usable frame space provided by the UMEM chunk. This becomes a problem since we started to respect tailroom which is subtracted from chunk_size (among with headroom). 2k chunk size might not provide enough space for standard 1500 MTU, so let us catch such settings at bind time. Furthermore, validate whether underlying HW will be able to satisfy configured MTU wrt XSK's frame size multiplied by supported Rx buffer chain length (that is exposed via net_device::xdp_zc_max_segs). Fixes: 24ea50127ecf ("xsk: support mbuf on ZC RX") Reviewed-by: Björn Töpel Signed-off-by: Maciej Fijalkowski Link: https://patch.msgid.link/20260402154958.562179-5-maciej.fijalkowski@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4947e2ae9c5737d9cdfbe5d32006b4a62435d67e Author: Maciej Fijalkowski Date: Thu Apr 2 17:49:53 2026 +0200 xsk: fix XDP_UMEM_SG_FLAG issues [ Upstream commit 93e84fe45b752d17a5a46b306ed78f0133bbc719 ] Currently xp_assign_dev_shared() is missing XDP_USE_SG being propagated to flags so set it in order to preserve mtu check that is supposed to be done only when no multi-buffer setup is in picture. Also, this flag has the same value as XDP_UMEM_TX_SW_CSUM so we could get unexpected SG setups for software Tx checksums. Since csum flag is UAPI, modify value of XDP_UMEM_SG_FLAG. Fixes: d609f3d228a8 ("xsk: add multi-buffer support for sockets sharing umem") Reviewed-by: Björn Töpel Signed-off-by: Maciej Fijalkowski Link: https://patch.msgid.link/20260402154958.562179-4-maciej.fijalkowski@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 29a68f4baaf9a312794570a58b66365a2cf19ab1 Author: Maciej Fijalkowski Date: Thu Apr 2 17:49:52 2026 +0200 xsk: respect tailroom for ZC setups [ Upstream commit 1ee1605138fc94cc8f8f273321dd2471c64977f9 ] Multi-buffer XDP stores information about frags in skb_shared_info that sits at the tailroom of a packet. The storage space is reserved via xdp_data_hard_end(): ((xdp)->data_hard_start + (xdp)->frame_sz - \ SKB_DATA_ALIGN(sizeof(struct skb_shared_info))) and then we refer to it via macro below: static inline struct skb_shared_info * xdp_get_shared_info_from_buff(const struct xdp_buff *xdp) { return (struct skb_shared_info *)xdp_data_hard_end(xdp); } Currently we do not respect this tailroom space in multi-buffer AF_XDP ZC scenario. To address this, introduce xsk_pool_get_tailroom() and use it within xsk_pool_get_rx_frame_size() which is used in ZC drivers to configure length of HW Rx buffer. Typically drivers on Rx Hw buffers side work on 128 byte alignment so let us align the value returned by xsk_pool_get_rx_frame_size() in order to avoid addressing this on driver's side. This addresses the fact that idpf uses mentioned function *before* pool->dev being set so we were at risk that after subtracting tailroom we would not provide 128-byte aligned value to HW. Since xsk_pool_get_rx_frame_size() is actively used in xsk_rcv_check() and __xsk_rcv(), add a variant of this routine that will not include 128 byte alignment and therefore old behavior is preserved. Reviewed-by: Björn Töpel Acked-by: Stanislav Fomichev Fixes: 24ea50127ecf ("xsk: support mbuf on ZC RX") Signed-off-by: Maciej Fijalkowski Link: https://patch.msgid.link/20260402154958.562179-3-maciej.fijalkowski@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9ea6ba4f3195dcba6e8b3e7b2e748593b7cafb12 Author: Maciej Fijalkowski Date: Thu Apr 2 17:49:51 2026 +0200 xsk: tighten UMEM headroom validation to account for tailroom and min frame [ Upstream commit a315e022a72d95ef5f1d4e58e903cb492b0ad931 ] The current headroom validation in xdp_umem_reg() could leave us with insufficient space dedicated to even receive minimum-sized ethernet frame. Furthermore if multi-buffer would come to play then skb_shared_info stored at the end of XSK frame would be corrupted. HW typically works with 128-aligned sizes so let us provide this value as bare minimum. Multi-buffer setting is known later in the configuration process so besides accounting for 128 bytes, let us also take care of tailroom space upfront. Reviewed-by: Björn Töpel Acked-by: Stanislav Fomichev Fixes: 99e3a236dd43 ("xsk: Add missing check on user supplied headroom size") Signed-off-by: Maciej Fijalkowski Link: https://patch.msgid.link/20260402154958.562179-2-maciej.fijalkowski@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 70b85c17734466164b95f93ad8cbacff127d2b9c Author: Agalakov Daniil Date: Wed Mar 18 15:05:05 2026 +0300 e1000: check return value of e1000_read_eeprom [ Upstream commit d3baa34a470771399c1495bc04b1e26ac15d598e ] [Why] e1000_set_eeprom() performs a read-modify-write operation when the write range is not word-aligned. This requires reading the first and last words of the range from the EEPROM to preserve the unmodified bytes. However, the code does not check the return value of e1000_read_eeprom(). If the read fails, the operation continues using uninitialized data from eeprom_buff. This results in corrupted data being written back to the EEPROM for the boundary words. Add the missing error checks and abort the operation if reading fails. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Co-developed-by: Iskhakov Daniil Signed-off-by: Iskhakov Daniil Signed-off-by: Agalakov Daniil Reviewed-by: Aleksandr Loktionov Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 4db7b61ec1d1b2b67c0881b62fc4f9583bc21484 Author: Michal Schmidt Date: Fri Mar 13 09:22:29 2026 +0100 ixgbevf: add missing negotiate_features op to Hyper-V ops table [ Upstream commit 4821d563cd7f251ae728be1a6d04af82a294a5b9 ] Commit a7075f501bd3 ("ixgbevf: fix mailbox API compatibility by negotiating supported features") added the .negotiate_features callback to ixgbe_mac_operations and populated it in ixgbevf_mac_ops, but forgot to add it to ixgbevf_hv_mac_ops. This leaves the function pointer NULL on Hyper-V VMs. During probe, ixgbevf_negotiate_api() calls ixgbevf_set_features(), which unconditionally dereferences hw->mac.ops.negotiate_features(). On Hyper-V this results in a NULL pointer dereference: BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine [...] Workqueue: events work_for_cpu_fn RIP: 0010:0x0 [...] Call Trace: ixgbevf_negotiate_api+0x66/0x160 [ixgbevf] ixgbevf_sw_init+0xe4/0x1f0 [ixgbevf] ixgbevf_probe+0x20f/0x4a0 [ixgbevf] local_pci_probe+0x50/0xa0 work_for_cpu_fn+0x1a/0x30 [...] Add ixgbevf_hv_negotiate_features_vf() that returns -EOPNOTSUPP and wire it into ixgbevf_hv_mac_ops. The caller already handles -EOPNOTSUPP gracefully. Fixes: a7075f501bd3 ("ixgbevf: fix mailbox API compatibility by negotiating supported features") Reported-by: Xiaoqiang Xiong Closes: https://issues.redhat.com/browse/RHEL-155455 Assisted-by: Claude:claude-4.6-opus-high Cursor Tested-by: Xiaoqiang Xiong Signed-off-by: Michal Schmidt Reviewed-by: Aleksandr Loktionov Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 4da3465a7f00b61f5506ecbde08162ff18d4f578 Author: Aleksandr Loktionov Date: Wed Mar 4 09:42:32 2026 +0100 ixgbe: stop re-reading flash on every get_drvinfo for e610 [ Upstream commit d8ae40dc20cbd7bb6e6b36a928e2db2296060ad2 ] ixgbe_get_drvinfo() calls ixgbe_refresh_fw_version() on every ethtool query for e610 adapters. That ends up in ixgbe_discover_flash_size(), which bisects the full 16 MB NVM space issuing one ACI command per step (~20 ms each, ~24 steps total = ~500 ms). Profiling on an idle E610-XAT2 system with telegraf scraping ethtool stats every 10 seconds: kretprobe:ixgbe_get_drvinfo took 527603 us kretprobe:ixgbe_get_drvinfo took 523978 us kretprobe:ixgbe_get_drvinfo took 552975 us kretprobe:ice_get_drvinfo took 3 us kretprobe:igb_get_drvinfo took 2 us kretprobe:i40e_get_drvinfo took 5 us The half-second stall happens under the RTNL lock, causing visible latency on ip-link and friends. The FW version can only change after an EMPR reset. All flash data is already populated at probe time and the cached adapter->eeprom_id is what get_drvinfo should be returning. The only place that needs to trigger a re-read is ixgbe_devlink_reload_empr_finish(), right after the EMPR completes and new firmware is running. Additionally, refresh the FW version in ixgbe_reinit_locked() so that any PF that undergoes a reinit after an EMPR (e.g. triggered by another PF's devlink reload) also picks up the new version in adapter->eeprom_id. ixgbe_devlink_info_get() keeps its refresh call for explicit "devlink dev info" queries, which is fine given those are user-initiated. Fixes: c9e563cae19e ("ixgbe: add support for devlink reload") Co-developed-by: Jedrzej Jagielski Signed-off-by: Jedrzej Jagielski 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 e19675b384e9dcaca1bd5e4a67b8ad136eccfbe8 Author: Kohei Enju Date: Sun Feb 1 14:14:00 2026 +0000 ice: ptp: don't WARN when controlling PF is unavailable [ Upstream commit bb3f21edc7056cdf44a7f7bd7ba65af40741838c ] In VFIO passthrough setups, it is possible to pass through only a PF which doesn't own the source timer. In that case the PTP controlling PF (adapter->ctrl_pf) is never initialized in the VM, so ice_get_ctrl_ptp() returns NULL and triggers WARN_ON() in ice_ptp_setup_pf(). Since this is an expected behavior in that configuration, replace WARN_ON() with an informational message and return -EOPNOTSUPP. Fixes: e800654e85b5 ("ice: Use ice_adapter for PTP shared data instead of auxdev") Signed-off-by: Kohei Enju Reviewed-by: Aleksandr Loktionov Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 7dad8bf14346c76d3644a22c00372d1664ba1c15 Author: Pengpeng Hou Date: Thu Apr 2 00:03:15 2026 +0800 tracing/probe: reject non-closed empty immediate strings [ Upstream commit 4346be6577aaa04586167402ae87bbdbe32484a4 ] parse_probe_arg() accepts quoted immediate strings and passes the body after the opening quote to __parse_imm_string(). That helper currently computes strlen(str) and immediately dereferences str[len - 1], which underflows when the body is empty and not closed with double-quotation. Reject empty non-closed immediate strings before checking for the closing quote. Link: https://lore.kernel.org/all/20260401160315.88518-1-pengpeng@iscas.ac.cn/ Fixes: a42e3c4de964 ("tracing/probe: Add immediate string parameter support") Signed-off-by: Pengpeng Hou Reviewed-by: Steven Rostedt (Google) Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin commit 9550d1d9f7163dd868aa12806f16e15d801399f0 Author: Jon Hunter Date: Wed Apr 1 11:29:40 2026 +0100 dt-bindings: net: Fix Tegra234 MGBE PTP clock [ Upstream commit fb22b1fc5bca3c0aad95388933497ceb30f1fb26 ] The PTP clock for the Tegra234 MGBE device is incorrectly named 'ptp-ref' and should be 'ptp_ref'. This is causing the following warning to be observed on Tegra234 platforms that use this device: ERR KERN tegra-mgbe 6800000.ethernet eth0: Invalid PTP clock rate WARNING KERN tegra-mgbe 6800000.ethernet eth0: PTP init failed Although this constitutes an ABI breakage in the binding for this device, PTP support has clearly never worked and so fix this now so we can correct the device-tree for this device. Note that the MGBE driver still supports the legacy 'ptp-ref' clock name and so older/existing device-trees will still work, but given that this is not the correct name, there is no point to advertise this in the binding. Fixes: 189c2e5c7669 ("dt-bindings: net: Add Tegra234 MGBE") Signed-off-by: Jon Hunter Reviewed-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20260401102941.17466-3-jonathanh@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b6b9c17ef8ae186ef9c9ff82857f89138cc882bb Author: Jon Hunter Date: Wed Apr 1 11:29:39 2026 +0100 net: stmmac: Fix PTP ref clock for Tegra234 [ Upstream commit 1345e9f4e3f3bc7d8a0a2138ae29e205a857a555 ] Since commit 030ce919e114 ("net: stmmac: make sure that ptp_rate is not 0 before configuring timestamping") was added the following error is observed on Tegra234: ERR KERN tegra-mgbe 6800000.ethernet eth0: Invalid PTP clock rate WARNING KERN tegra-mgbe 6800000.ethernet eth0: PTP init failed It turns out that the Tegra234 device-tree binding defines the PTP ref clock name as 'ptp-ref' and not 'ptp_ref' and the above commit now exposes this and that the PTP clock is not configured correctly. In order to update device-tree to use the correct 'ptp_ref' name, update the Tegra MGBE driver to use 'ptp_ref' by default and fallback to using 'ptp-ref' if this clock name is present. Fixes: d8ca113724e7 ("net: stmmac: tegra: Add MGBE support") Signed-off-by: Jon Hunter Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260401102941.17466-2-jonathanh@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6d931680a9851481c3243689488eafed08eeff71 Author: Pengpeng Hou Date: Thu Apr 2 12:21:48 2026 +0800 nfc: s3fwrn5: allocate rx skb before consuming bytes [ Upstream commit 5c14a19d5b1645cce1cb1252833d70b23635b632 ] s3fwrn82_uart_read() reports the number of accepted bytes to the serdev core. The current code consumes bytes into recv_skb and may already deliver a complete frame before allocating a fresh receive buffer. If that alloc_skb() fails, the callback returns 0 even though it has already consumed bytes, and it leaves recv_skb as NULL for the next receive callback. That breaks the receive_buf() accounting contract and can also lead to a NULL dereference on the next skb_put_u8(). Allocate the receive skb lazily before consuming the next byte instead. If allocation fails, return the number of bytes already accepted. Fixes: 3f52c2cb7e3a ("nfc: s3fwrn5: Support a UART interface") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260402042148.65236-1-pengpeng@iscas.ac.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4d90f9a271a633fff6c924b82b6a2b1fa6788d12 Author: Chris J Arges Date: Thu Apr 2 17:23:16 2026 -0500 net: increase IP_TUNNEL_RECURSION_LIMIT to 5 [ Upstream commit 77facb35227c421467cdb49268de433168c2dcef ] In configurations with multiple tunnel layers and MPLS lwtunnel routing, a single tunnel hop can increment the counter beyond this limit. This causes packets to be dropped with the "Dead loop on virtual device" message even when a routing loop doesn't exist. Increase IP_TUNNEL_RECURSION_LIMIT from 4 to 5 to handle this use-case. Fixes: 6f1a9140ecda ("net: add xmit recursion limit to tunnel xmit functions") Link: https://lore.kernel.org/netdev/88deb91b-ef1b-403c-8eeb-0f971f27e34f@redhat.com/ Signed-off-by: Chris J Arges Link: https://patch.msgid.link/20260402222401.3408368-1-carges@cloudflare.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f91b3ed9e7fa82a70511b5f6901c88379acf2964 Author: Yiqi Sun Date: Thu Apr 2 15:04:19 2026 +0800 ipv4: icmp: fix null-ptr-deref in icmp_build_probe() [ Upstream commit fde29fd9349327acc50d19a0b5f3d5a6c964dfd8 ] ipv6_stub->ipv6_dev_find() may return ERR_PTR(-EAFNOSUPPORT) when the IPv6 stack is not active (CONFIG_IPV6=m and not loaded), and passing this error pointer to dev_hold() will cause a kernel crash with null-ptr-deref. Instead, silently discard the request. RFC 8335 does not appear to define a specific response for the case where an IPv6 interface identifier is syntactically valid but the implementation cannot perform the lookup at runtime, and silently dropping the request may safer than misreporting "No Such Interface". Fixes: d329ea5bd884 ("icmp: add response to RFC 8335 PROBE messages") Signed-off-by: Yiqi Sun Link: https://patch.msgid.link/20260402070419.2291578-1-sunyiqixm@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 40bd39e383a0478fd5c221f393df05fd9d70cfbc Author: Fernando Fernandez Mancera Date: Thu Apr 2 09:26:13 2026 +0200 ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop() [ Upstream commit 14cf0cd35361f4e94824bf8a42f72713d7702a73 ] When querying a nexthop object via RTM_GETNEXTHOP, the kernel currently allocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for single nexthops and small Equal-Cost Multi-Path groups, this fixed allocation fails for large nexthop groups like 512 nexthops. This results in the following warning splat: WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#20: rep/4608 [...] RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395) [...] Call Trace: rtnetlink_rcv_msg (net/core/rtnetlink.c:6989) netlink_rcv_skb (net/netlink/af_netlink.c:2550) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) ____sys_sendmsg (net/socket.c:721 net/socket.c:736 net/socket.c:2585) ___sys_sendmsg (net/socket.c:2641) __sys_sendmsg (net/socket.c:2671) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Fix this by allocating the size dynamically using nh_nlmsg_size() and using nlmsg_new(), this is consistent with nexthop_notify() behavior. In addition, adjust nh_nlmsg_size_grp() so it calculates the size needed based on flags passed. While at it, also add the size of NHA_FDB for nexthop group size calculation as it was missing too. This cannot be reproduced via iproute2 as the group size is currently limited and the command fails as follows: addattr_l ERROR: message exceeded bound of 1048 Fixes: 430a049190de ("nexthop: Add support for nexthop groups") Reported-by: Yiming Qian Closes: https://lore.kernel.org/netdev/CAL_bE8Li2h4KO+AQFXW4S6Yb_u5X4oSKnkywW+LPFjuErhqELA@mail.gmail.com/ Signed-off-by: Fernando Fernandez Mancera Reviewed-by: Eric Dumazet Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260402072613.25262-2-fmancera@suse.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 69aa3c713980d98dc2a6ebd2a872836df9c37e64 Author: Fernando Fernandez Mancera Date: Thu Apr 2 09:26:12 2026 +0200 ipv4: nexthop: avoid duplicate NHA_HW_STATS_ENABLE on nexthop group dump [ Upstream commit 06aaf04ca815f7a1f17762fd847b7bc14b8833fb ] Currently NHA_HW_STATS_ENABLE is included twice everytime a dump of nexthop group is performed with NHA_OP_FLAG_DUMP_STATS. As all the stats querying were moved to nla_put_nh_group_stats(), leave only that instance of the attribute querying. Fixes: 5072ae00aea4 ("net: nexthop: Expose nexthop group HW stats to user space") Signed-off-by: Fernando Fernandez Mancera Reviewed-by: Eric Dumazet Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260402072613.25262-1-fmancera@suse.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0975b64ffb34560042090a5986c3a02e6c80f36f Author: Nikolaos Gkarlis Date: Thu Apr 2 20:14:32 2026 +0200 rtnetlink: add missing netlink_ns_capable() check for peer netns [ Upstream commit 7b735ef81286007794a227ce2539419479c02a5f ] rtnl_newlink() lacks a CAP_NET_ADMIN capability check on the peer network namespace when creating paired devices (veth, vxcan, netkit). This allows an unprivileged user with a user namespace to create interfaces in arbitrary network namespaces, including init_net. Add a netlink_ns_capable() check for CAP_NET_ADMIN in the peer namespace before allowing device creation to proceed. Fixes: 81adee47dfb6 ("net: Support specifying the network namespace upon device creation.") Signed-off-by: Nikolaos Gkarlis Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260402181432.4126920-1-nickgarlis@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fb612d436ff0317659e45a91c25fd7d9516f5b1b Author: Zijing Yin Date: Thu Apr 2 07:01:53 2026 -0700 bridge: guard local VLAN-0 FDB helpers against NULL vlan group [ Upstream commit 1979645e1842cb7017525a61a0e0e0beb924d02a ] When CONFIG_BRIDGE_VLAN_FILTERING is not set, br_vlan_group() and nbp_vlan_group() return NULL (br_private.h stub definitions). The BR_BOOLOPT_FDB_LOCAL_VLAN_0 toggle code is compiled unconditionally and reaches br_fdb_delete_locals_per_vlan_port() and br_fdb_insert_locals_per_vlan_port(), where the NULL vlan group pointer is dereferenced via list_for_each_entry(v, &vg->vlan_list, vlist). The observed crash is in the delete path, triggered when creating a bridge with IFLA_BR_MULTI_BOOLOPT containing BR_BOOLOPT_FDB_LOCAL_VLAN_0 via RTM_NEWLINK. The insert helper has the same bug pattern. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000056: 0000 [#1] KASAN NOPTI KASAN: null-ptr-deref in range [0x00000000000002b0-0x00000000000002b7] RIP: 0010:br_fdb_delete_locals_per_vlan+0x2b9/0x310 Call Trace: br_fdb_toggle_local_vlan_0+0x452/0x4c0 br_toggle_fdb_local_vlan_0+0x31/0x80 net/bridge/br.c:276 br_boolopt_toggle net/bridge/br.c:313 br_boolopt_multi_toggle net/bridge/br.c:364 br_changelink net/bridge/br_netlink.c:1542 br_dev_newlink net/bridge/br_netlink.c:1575 Add NULL checks for the vlan group pointer in both helpers, returning early when there are no VLANs to iterate. This matches the existing pattern used by other bridge FDB functions such as br_fdb_add() and br_fdb_delete(). Fixes: 21446c06b441 ("net: bridge: Introduce UAPI for BR_BOOLOPT_FDB_LOCAL_VLAN_0") Signed-off-by: Zijing Yin Reviewed-by: Ido Schimmel Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260402140153.3925663-1-yzjaurora@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4198aab6f000b4febb18ea820fea20634dd789c7 Author: Eric Dumazet Date: Thu Apr 2 10:17:32 2026 +0000 ipv6: ioam: fix potential NULL dereferences in __ioam6_fill_trace_data() [ Upstream commit 4e65a8b8daa18d63255ec58964dd192c7fdd9f8b ] We need to check __in6_dev_get() for possible NULL value, as suggested by Yiming Qian. Also add skb_dst_dev_rcu() instead of skb_dst_dev(), and two missing READ_ONCE(). Note that @dev can't be NULL. Fixes: 9ee11f0fff20 ("ipv6: ioam: Data plane support for Pre-allocated Trace") Reported-by: Yiming Qian Signed-off-by: Eric Dumazet Reviewed-by: Justin Iurman Link: https://patch.msgid.link/20260402101732.1188059-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4429b761874fb9c7767d12d98913a467ef2654f1 Author: Lorenzo Bianconi Date: Thu Apr 2 14:57:10 2026 +0200 net: airoha: Fix memory leak in airoha_qdma_rx_process() [ Upstream commit 285fa6b1e03cff78ead0383e1b259c44b95faf90 ] If an error occurs on the subsequents buffers belonging to the non-linear part of the skb (e.g. due to an error in the payload length reported by the NIC or if we consumed all the available fragments for the skb), the page_pool fragment will not be linked to the skb so it will not return to the pool in the airoha_qdma_rx_process() error path. Fix the memory leak partially reverting commit 'd6d2b0e1538d ("net: airoha: Fix page recycling in airoha_qdma_rx_process()")' and always running page_pool_put_full_page routine in the airoha_qdma_rx_process() error path. Fixes: d6d2b0e1538d ("net: airoha: Fix page recycling in airoha_qdma_rx_process()") Signed-off-by: Lorenzo Bianconi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260402-airoha_qdma_rx_process-mem-leak-fix-v1-1-b5706f402d3c@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 63851f60781aa89258c8f0952cd13940aab0888e Author: Eric Dumazet Date: Thu Apr 2 10:35:19 2026 +0000 net: lapbether: handle NETDEV_PRE_TYPE_CHANGE [ Upstream commit b120e4432f9f56c7103133d6a11245e617695adb ] lapbeth_data_transmit() expects the underlying device type to be ARPHRD_ETHER. Returning NOTIFY_BAD from lapbeth_device_event() makes sure bonding driver can not break this expectation. Fixes: 872254dd6b1f ("net/bonding: Enable bonding to enslave non ARPHRD_ETHER") Reported-by: syzbot+d8c285748fa7292580a9@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/69cd22a1.050a0220.70c3a.0002.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Cc: Martin Schiller Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260402103519.1201565-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ec4930979b3f7bbeb7af5744599fc6603a4dba62 Author: Ruide Cao Date: Thu Apr 2 22:46:20 2026 +0800 net: sched: act_csum: validate nested VLAN headers [ Upstream commit c842743d073bdd683606cb414eb0ca84465dd834 ] tcf_csum_act() walks nested VLAN headers directly from skb->data when an skb still carries in-payload VLAN tags. The current code reads vlan->h_vlan_encapsulated_proto and then pulls VLAN_HLEN bytes without first ensuring that the full VLAN header is present in the linear area. If only part of an inner VLAN header is linearized, accessing h_vlan_encapsulated_proto reads past the linear area, and the following skb_pull(VLAN_HLEN) may violate skb invariants. Fix this by requiring pskb_may_pull(skb, VLAN_HLEN) before accessing and pulling each nested VLAN header. If the header still is not fully available, drop the packet through the existing error path. Fixes: 2ecba2d1e45b ("net: sched: act_csum: Fix csum calc for tagged packets") Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Tested-by: Ren Wei Signed-off-by: Ruide Cao Signed-off-by: Ren Wei Reviewed-by: Simon Horman Link: https://patch.msgid.link/22df2fcb49f410203eafa5d97963dd36089f4ecf.1774892775.git.caoruide123@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7e8083f5eeedab0f460063b9c2c14c9a4e71a427 Author: Nicholas Carlini Date: Tue Mar 31 15:25:32 2026 +0200 eventpoll: defer struct eventpoll free to RCU grace period [ Upstream commit 07712db80857d5d09ae08f3df85a708ecfc3b61f ] In certain situations, ep_free() in eventpoll.c will kfree the epi->ep eventpoll struct while it still being used by another concurrent thread. Defer the kfree() to an RCU callback to prevent UAF. Fixes: f2e467a48287 ("eventpoll: Fix semi-unbounded recursion") Signed-off-by: Nicholas Carlini Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 0cf8ea9d677b638e650014f28ed588dbabac2cc7 Author: Maíra Canal Date: Mon Mar 30 14:51:46 2026 -0300 drm/vc4: Protect madv read in vc4_gem_object_mmap() with madv_lock [ Upstream commit 338c56050d8e892604da97f67bfa8cc4015a955f ] The mmap callback reads bo->madv without holding madv_lock, racing with concurrent DRM_IOCTL_VC4_GEM_MADVISE calls that modify the field under the same lock. Add the missing locking to prevent the data race. Fixes: b9f19259b84d ("drm/vc4: Add the DRM_IOCTL_VC4_GEM_MADVISE ioctl") Reviewed-by: Melissa Wen Link: https://patch.msgid.link/20260330-vc4-misc-fixes-v1-4-92defc940a29@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Sasha Levin commit e352e9adc9f6df54d63150ff832f71c04e30744b Author: Maíra Canal Date: Mon Mar 30 14:51:45 2026 -0300 drm/vc4: Fix a memory leak in hang state error path [ Upstream commit 9525d169e5fd481538cf8c663cc5839e54f2e481 ] When vc4_save_hang_state() encounters an early return condition, it returns without freeing the previously allocated `kernel_state`, leaking memory. Add the missing kfree() calls by consolidating the early return paths into a single place. Fixes: 214613656b51 ("drm/vc4: Add an interface for capturing the GPU state after a hang.") Reviewed-by: Melissa Wen Link: https://patch.msgid.link/20260330-vc4-misc-fixes-v1-3-92defc940a29@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Sasha Levin commit 421cea4f71f7cf65abaae878562ee4aa2b684628 Author: Maíra Canal Date: Mon Mar 30 14:51:44 2026 -0300 drm/vc4: Fix memory leak of BO array in hang state [ Upstream commit f4dfd6847b3e5d24e336bca6057485116d17aea4 ] The hang state's BO array is allocated separately with kzalloc() in vc4_save_hang_state() but never freed in vc4_free_hang_state(). Add the missing kfree() for the BO array before freeing the hang state struct. Fixes: 214613656b51 ("drm/vc4: Add an interface for capturing the GPU state after a hang.") Reviewed-by: Melissa Wen Link: https://patch.msgid.link/20260330-vc4-misc-fixes-v1-2-92defc940a29@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Sasha Levin commit ce12a1af6779cee2f97c42631b4a15becbeea926 Author: Maíra Canal Date: Mon Mar 30 14:51:43 2026 -0300 drm/vc4: Release runtime PM reference after binding V3D [ Upstream commit aaefbdde9abdc43699e110679c0e10972a5e1c59 ] The vc4_v3d_bind() function acquires a runtime PM reference via pm_runtime_resume_and_get() to access V3D registers during setup. However, this reference is never released after a successful bind. This prevents the device from ever runtime suspending, since the reference count never reaches zero. Release the runtime PM reference by adding pm_runtime_put_autosuspend() after autosuspend is configured, allowing the device to runtime suspend after the delay. Fixes: 266cff37d7fc ("drm/vc4: v3d: Rework the runtime_pm setup") Reviewed-by: Melissa Wen Link: https://patch.msgid.link/20260330-vc4-misc-fixes-v1-1-92defc940a29@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Sasha Levin commit 9a945edeabb5ef5dc8aff51c7483b1d223dc9e43 Author: Mikhail Gavrilov Date: Fri Mar 27 17:41:56 2026 +0500 dma-debug: suppress cacheline overlap warning when arch has no DMA alignment requirement [ Upstream commit 3d48c9fd78dd0b1809669ec49c4d0997b8127512 ] When CONFIG_DMA_API_DEBUG is enabled, the DMA debug infrastructure tracks active mappings per cacheline and warns if two different DMA mappings share the same cacheline ("cacheline tracking EEXIST, overlapping mappings aren't supported"). On x86_64, ARCH_KMALLOC_MINALIGN defaults to 8, so small kmalloc allocations (e.g. the 8-byte hub->buffer and hub->status in the USB hub driver) frequently land in the same 64-byte cacheline. When both are DMA-mapped, this triggers a false positive warning. This has been reported repeatedly since v5.14 (when the EEXIST check was added) across various USB host controllers and devices including xhci_hcd with USB hubs, USB audio devices, and USB ethernet adapters. The cacheline overlap is only a real concern on architectures that require DMA buffer alignment to cacheline boundaries (i.e. where ARCH_DMA_MINALIGN >= L1_CACHE_BYTES). On architectures like x86_64 where dma_get_cache_alignment() returns 1, the hardware is cache-coherent and overlapping cacheline mappings are harmless. Suppress the EEXIST warning when dma_get_cache_alignment() is less than L1_CACHE_BYTES, indicating the architecture does not require cacheline-aligned DMA buffers. Verified with a kernel module reproducer that performs two kmalloc(8) allocations back-to-back and DMA-maps both: Before: allocations share a cacheline, EEXIST fires within ~50 pairs After: same cacheline pair found, but no warning emitted Fixes: 2b4bbc6231d7 ("dma-debug: report -EEXIST errors in add_dma_entry") Link: https://bugzilla.kernel.org/show_bug.cgi?id=215740 Suggested-by: Harry Yoo Tested-by: Mikhail Gavrilov Signed-off-by: Mikhail Gavrilov Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20260327124156.24820-1-mikhail.v.gavrilov@gmail.com Signed-off-by: Sasha Levin commit ad187e0506ab4cda2958831367d6861d4cd97391 Author: Michael S. Tsirkin Date: Mon Dec 29 14:38:31 2025 -0500 dma-debug: track cache clean flag in entries [ Upstream commit d5d846513128c1a3bc2f2d371f6e903177dea443 ] If a driver is buggy and has 2 overlapping mappings but only sets cache clean flag on the 1st one of them, we warn. But if it only does it for the 2nd one, we don't. Fix by tracking cache clean flag in the entry. Message-ID: <0ffb3513d18614539c108b4548cdfbc64274a7d1.1767601130.git.mst@redhat.com> Reviewed-by: Petr Tesarik Signed-off-by: Michael S. Tsirkin Stable-dep-of: 3d48c9fd78dd ("dma-debug: suppress cacheline overlap warning when arch has no DMA alignment requirement") Signed-off-by: Sasha Levin commit 4e8a1b9701689a345e6a64d6a0e4ae9c1cce07d6 Author: Michael S. Tsirkin Date: Mon Dec 29 07:28:43 2025 -0500 dma-mapping: add DMA_ATTR_CPU_CACHE_CLEAN [ Upstream commit 61868dc55a119a5e4b912d458fc2c48ba80a35fe ] When multiple small DMA_FROM_DEVICE or DMA_BIDIRECTIONAL buffers share a cacheline, and DMA_API_DEBUG is enabled, we get this warning: cacheline tracking EEXIST, overlapping mappings aren't supported. This is because when one of the mappings is removed, while another one is active, CPU might write into the buffer. Add an attribute for the driver to promise not to do this, making the overlapping safe, and suppressing the warning. Message-ID: <2d5d091f9d84b68ea96abd545b365dd1d00bbf48.1767601130.git.mst@redhat.com> Reviewed-by: Petr Tesarik Acked-by: Marek Szyprowski Signed-off-by: Michael S. Tsirkin Stable-dep-of: 3d48c9fd78dd ("dma-debug: suppress cacheline overlap warning when arch has no DMA alignment requirement") Signed-off-by: Sasha Levin commit e62e322ea20be78e346e4b49f9a6b9f03313af4c Author: Keenan Dong Date: Thu Mar 26 20:36:39 2026 +0800 xfrm: account XFRMA_IF_ID in aevent size calculation [ Upstream commit 7081d46d32312f1a31f0e0e99c6835a394037599 ] xfrm_get_ae() allocates the reply skb with xfrm_aevent_msgsize(), then build_aevent() appends attributes including XFRMA_IF_ID when x->if_id is set. xfrm_aevent_msgsize() does not include space for XFRMA_IF_ID. For states with if_id, build_aevent() can fail with -EMSGSIZE and hit BUG_ON(err < 0) in xfrm_get_ae(), turning a malformed netlink interaction into a kernel panic. Account XFRMA_IF_ID in the size calculation unconditionally and replace the BUG_ON with normal error unwinding. Fixes: 7e6526404ade ("xfrm: Add a new lookup key to match xfrm interfaces.") Reported-by: Keenan Dong Signed-off-by: Keenan Dong Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 73e3e4dac1028ec4ca18acd90bbe3fd1d3b2d5ff Author: Maximilian Pezzullo Date: Wed Mar 4 09:25:22 2026 +0100 HID: amd_sfh: don't log error when device discovery fails with -EOPNOTSUPP [ Upstream commit 743677a8cb30b09f16a7f167f497c2c927891b5a ] When sensor discovery fails on systems without AMD SFH sensors, the code already emits a warning via dev_warn() in amd_sfh_hid_client_init(). The subsequent dev_err() in sfh_init_work() for the same -EOPNOTSUPP return value is redundant and causes unnecessary alarm. Suppress the dev_err() for -EOPNOTSUPP to avoid confusing users who have no AMD SFH sensors. Fixes: 2105e8e00da4 ("HID: amd_sfh: Improve boot time when SFH is available") Reported-by: Casey Croy Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221099 Signed-off-by: Maximilian Pezzullo Acked-by: Basavaraj Natikar Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 0d364d863c7028ce0b413292fd253a397fbd81e9 Author: Long Li Date: Mon Mar 16 14:07:42 2026 -0700 PCI: hv: Set default NUMA node to 0 for devices without affinity info [ Upstream commit 7b3b1e5a87b2f5e35c52b5386d7c327be869454f ] When hv_pci_assign_numa_node() processes a device that does not have HV_PCI_DEVICE_FLAG_NUMA_AFFINITY set or has an out-of-range virtual_numa_node, the device NUMA node is left unset. On x86_64, the uninitialized default happens to be 0, but on ARM64 it is NUMA_NO_NODE (-1). Tests show that when no NUMA information is available from the Hyper-V host, devices perform best when assigned to node 0. With NUMA_NO_NODE the kernel may spread work across NUMA nodes, which degrades performance on Hyper-V, particularly for high-throughput devices like MANA. Always set the device NUMA node to 0 before the conditional NUMA affinity check, so that devices get a performant default when the host provides no NUMA information, and behavior is consistent on both x86_64 and ARM64. Fixes: 999dd956d838 ("PCI: hv: Add support for protocol 1.3 and support PCI_BUS_RELATIONS2") Signed-off-by: Long Li Reviewed-by: Michael Kelley Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit e4093997420fd662cd3b651fcec7add20ec2839d Author: Mihai Sain Date: Mon Feb 9 11:07:35 2026 +0200 ARM: dts: microchip: sam9x7: fix gpio-lines count for pioB [ Upstream commit 907150bbe566e23714a25d7bcb910f236c3c44c0 ] The pioB controller on the SAM9X7 SoC actually supports 27 GPIO lines. The previous value of 26 was incorrect, leading to the last pin being unavailable for use by the GPIO subsystem. Update the #gpio-lines property to reflect the correct hardware specification. Fixes: 41af45af8bc3 ("ARM: dts: at91: sam9x7: add device tree for SoC") Signed-off-by: Mihai Sain Link: https://lore.kernel.org/r/20260209090735.2016-1-mihai.sain@microchip.com Signed-off-by: Claudiu Beznea Signed-off-by: Sasha Levin commit edde62571f7602d83243ca51729ce42d22ea04d2 Author: Loic Poulain Date: Mon Mar 2 15:26:03 2026 +0100 arm64: dts: qcom: monaco: Reserve full Gunyah metadata region [ Upstream commit 85d98669fa7f1d3041d962515e45ee6e392db6f8 ] We observe spurious "Synchronous External Abort" exceptions (ESR=0x96000010) and kernel crashes on Monaco-based platforms. These faults are caused by the kernel inadvertently accessing hypervisor-owned memory that is not properly marked as reserved. >From boot log, The Qualcomm hypervisor reports the memory range at 0x91a80000 of size 0x80000 (512 KiB) as hypervisor-owned: qhee_hyp_assign_remove_memory: 0x91a80000/0x80000 -> ret 0 However, the EFI memory map provided by firmware only reserves the subrange 0x91a40000–0x91a87fff (288 KiB). The remaining portion (0x91a88000–0x91afffff) is incorrectly reported as conventional memory (from efi debug): efi: 0x000091a40000-0x000091a87fff [Reserved...] efi: 0x000091a88000-0x0000938fffff [Conventional...] As a result, the allocator may hand out PFNs inside the hypervisor owned region, causing fatal aborts when the kernel accesses those addresses. Add a reserved-memory carveout for the Gunyah hypervisor metadata at 0x91a80000 (512 KiB) and mark it as no-map so Linux does not map or allocate from this area. For the record: Hyp version: gunyah-e78adb36e debug (2025-11-17 05:38:05 UTC) UEFI Ver: 6.0.260122.BOOT.MXF.1.0.c1-00449-KODIAKLA-1 Fixes: 7be190e4bdd2 ("arm64: dts: qcom: add QCS8300 platform") Signed-off-by: Loic Poulain Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260302142603.1113355-1-loic.poulain@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d0deac48e57afa0fb698b52e31cda06f34680520 Author: Artem Bityutskiy Date: Wed Mar 11 11:00:33 2026 +0200 tools/power turbostat: Fix --show/--hide for individual cpuidle counters [ Upstream commit b6398bc2ef3a78f1be37ba01ae0a5eedaee47803 ] Problem: individual swidle counter names (C1, C1+, C1-, etc.) cannot be selected via --show/--hide due to two bugs in probe_cpuidle_counts(): 1. The function returns immediately when BIC_cpuidle is not enabled, without checking deferred_add_index. 2. The deferred name check runs against name_buf before the trailing newline is stripped, so is_deferred_add("C1\n") never matches "C1". Fix: 1. Relax the early return to pass through when deferred names are queued. 2. Strip the trailing newline from name_buf before performing deferred name checks. 3. Check each suffixed variant (C1+, C1, C1-) individually so that e.g. "--show C1+" enables only the requested metric. In addition, introduce a helper function to avoid repeating the condition (readability cleanup). Fixes: ec4acd3166d8 ("tools/power turbostat: disable "cpuidle" invocation counters, by default") Signed-off-by: Artem Bityutskiy Signed-off-by: Len Brown Signed-off-by: Sasha Levin commit fbc581977db22fd0fb975c98a4963ca8737d5367 Author: Serhii Pievniev Date: Wed Feb 25 18:16:03 2026 -0500 tools/power/turbostat: Fix microcode patch level output for AMD/Hygon [ Upstream commit a444083286434ec1fd127c5da11a3091e6013008 ] turbostat always used the same logic to read the microcode patch level, which is correct for Intel but not for AMD/Hygon. While Intel stores the patch level in the upper 32 bits of MSR, AMD stores it in the lower 32 bits, which causes turbostat to report the microcode version as 0x0 on AMD/Hygon. Fix by shifting right by 32 for non-AMD/Hygon, preserving the existing behavior for Intel and unknown vendors. Fixes: 3e4048466c39 ("tools/power turbostat: Add --no-msr option") Signed-off-by: Serhii Pievniev Signed-off-by: Len Brown Signed-off-by: Sasha Levin commit 7d75145672cf2ec7c5417e3243af72c48314f7bb Author: Mukesh Ojha Date: Thu Jan 29 20:53:20 2026 +0530 soc: qcom: pd-mapper: Fix element length in servreg_loc_pfr_req_ei [ Upstream commit 641f6fda143b879da1515f821ee475073678cf2a ] It looks element length declared in servreg_loc_pfr_req_ei for reason not matching servreg_loc_pfr_req's reason field due which we could observe decoding error on PD crash. qmi_decode_string_elem: String len 81 >= Max Len 65 Fix this by matching with servreg_loc_pfr_req's reason field. Fixes: 1ebcde047c54 ("soc: qcom: add pd-mapper implementation") Signed-off-by: Mukesh Ojha Reviewed-by: Dmitry Baryshkov Tested-by: Nikita Travkin Link: https://lore.kernel.org/r/20260129152320.3658053-2-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 52632daf642552040d5bae96021e512e99afb17e Author: Loic Poulain Date: Mon Feb 2 16:56:11 2026 +0100 arm64: dts: qcom: monaco: Fix UART10 pinconf [ Upstream commit 5b2a16ab0dbd090dc545c05ee79a077cc7a9c1e0 ] UART10 RTS and TX pins were incorrectly mapped to gpio84 and gpio85. Correct them to gpio85 (RTS) and gpio86 (TX) to match the hardware I/O mapping. Fixes: 467284a3097f ("arm64: dts: qcom: qcs8300: Add QUPv3 configuration") Signed-off-by: Loic Poulain Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260202155611.1568-1-loic.poulain@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 95894966bce909b98d5a4b30ce42e8b6e6d60ddd Author: Markus Niebel Date: Mon Feb 9 16:50:14 2026 +0100 arm64: dts: imx93-tqma9352: improve eMMC pad configuration [ Upstream commit b6c94c71f349479b76fcc0ef0dc7147f3f326dff ] Use DSE x4 an PullUp for CMD an DAT, DSE x4 and PullDown for CLK to improve stability and detection at low temperatures under -25°C. Fixes: 0b5fdfaa8e45 ("arm64: dts: freescale: imx93-tqma9352: set SION for cmd and data pad of USDHC") Signed-off-by: Markus Niebel Signed-off-by: Alexander Stein Reviewed-by: Frank Li Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit b3b725b902b34e0b2ce62ea3f781755845a4ea1d Author: Markus Niebel Date: Mon Feb 9 16:50:13 2026 +0100 arm64: dts: imx91-tqma9131: improve eMMC pad configuration [ Upstream commit 44db7bc66eb38e85bb32777c5fd3a4e7baa84147 ] Use DSE x4 an PullUp for CMD an DAT, DSE x4 and PullDown for CLK to improve stability and detection at low temperatures under -25°C. Fixes: e71db39f0c7c ("arm64: dts: freescale: add initial device tree for TQMa91xx/MBa91xxCA") Signed-off-by: Markus Niebel Signed-off-by: Alexander Stein Reviewed-by: Frank Li Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 737a4ee014e1590edfde7c5987d18dc80faa8f0f Author: Luke Wang Date: Tue Feb 3 19:23:08 2026 +0800 arm64: dts: imx93-9x9-qsb: change usdhc tuning step for eMMC and SD [ Upstream commit 08903184553def7ba1ad6ba4fa8afe1ba2ee0a21 ] During system resume, the following errors occurred: [ 430.638625] mmc1: error -84 writing Cache Enable bit [ 430.643618] mmc1: error -84 doing runtime resume For eMMC and SD, there are two tuning pass windows and the gap between those two windows may only have one cell. If tuning step > 1, the gap may just be skipped and host assumes those two windows as a continuous windows. This will cause a wrong delay cell near the gap to be selected. Set the tuning step to 1 to avoid selecting the wrong delay cell. For SDIO, the gap is sufficiently large, so the default tuning step does not cause this issue. Fixes: 0565d20cd8c2 ("arm64: dts: freescale: Support i.MX93 9x9 Quick Start Board") Signed-off-by: Luke Wang Reviewed-by: Frank Li Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit d0fcd48589188769e83b5ff81dd16488257e6a9a Author: Sebastian Krzyszkowiak Date: Wed Jan 28 00:28:28 2026 +0100 arm64: dts: imx8mq: Set the correct gpu_ahb clock frequency [ Upstream commit 1f99b5d93d99ca17d50b386a674d0ce1f20932d8 ] According to i.MX 8M Quad Reference Manual, GPU_AHB_CLK_ROOT's maximum frequency is 400MHz. Fixes: 45d2c84eb3a2 ("arm64: dts: imx8mq: add GPU node") Reviewed-by: Frank Li Signed-off-by: Sebastian Krzyszkowiak Reviewed-by: Peng Fan Reviewed-by: Fabio Estevam Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit ecbc5e9277da2bab087527180fd08d59213a7fe7 Author: Ravi Hothi Date: Fri Feb 20 14:32:20 2026 +0530 arm64: dts: qcom: qcm6490-idp: Fix WCD9370 reset GPIO polarity [ Upstream commit b7df21c59739cceb7b866c6c5e8a6ba03875ab71 ] The WCD9370 audio codec reset line on QCM6490 IDP should be active-low, but the device tree described it as active-high. As a result, the codec is kept in reset and fails to reset the SoundWire, leading to timeouts and ASoC card probe failure (-ETIMEDOUT). Fix the reset GPIO polarity to GPIO_ACTIVE_LOW so the codec can properly initialize. Fixes: aa04c298619f ("arm64: dts: qcom: qcm6490-idp: Add WSA8830 speakers and WCD9370 headset codec") Signed-off-by: Ravi Hothi Reviewed-by: Krzysztof Kozlowski Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260220090220.2992193-1-ravi.hothi@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 878ccc18d94c31381f8e3b00b6f1de8863af8884 Author: Daniel J Blueman Date: Fri Feb 20 20:44:58 2026 +0800 arm64: dts: qcom: hamoa/x1: fix idle exit latency [ Upstream commit 3ecea84d2b90bbf934d5ca75514fa902fd71e03f ] Designs based on the Qualcomm X1 Hamoa reference platform report: driver: Idle state 1 target residency too low This is because the declared X1 idle entry plus exit latency of 680us exceeds the declared minimum 600us residency time: entry-latency-us = <180>; exit-latency-us = <500>; min-residency-us = <600>; Fix this to be 320us so the sum of the entry and exit latencies matches the downstream 500us exit latency, as directed by Maulik. Tested on a Lenovo Yoga Slim 7x with Qualcomm X1E-80-100. Fixes: 2e65616ef07f ("arm64: dts: qcom: x1e80100: Update C4/C5 residency/exit numbers") Signed-off-by: Daniel J Blueman Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260220124626.8611-1-daniel@quora.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c448aad9a779fe30fde030a8d882ce56fae7fa9d Author: Potin Lai Date: Thu Jan 22 16:37:56 2026 +0800 soc: aspeed: socinfo: Mask table entries for accurate SoC ID matching [ Upstream commit 7ec1bd3d9be671d04325b9e06149b8813f6a4836 ] The siliconid_to_name() function currently masks the input silicon ID with 0xff00ffff, but compares it against unmasked table entries. This causes matching to fail if the table entries contain non-zero values in the bits covered by the mask (bits 16-23). Update the logic to apply the 0xff00ffff mask to the table entries during comparison. This ensures that only the relevant model and revision bits are considered, providing a consistent match across different manufacturing batches. [arj: Add Fixes: tag, fix 'soninfo' typo, clarify function reference] Fixes: e0218dca5787 ("soc: aspeed: Add soc info driver") Signed-off-by: Potin Lai Link: https://patch.msgid.link/20260122-soc_aspeed_name_fix-v1-1-33a847f2581c@gmail.com Signed-off-by: Andrew Jeffery Signed-off-by: Sasha Levin commit d2c7153fe0caeaeb338b227fe335f9d174080107 Author: Tomasz Merta Date: Wed Apr 8 10:40:56 2026 +0200 ASoC: stm32_sai: fix incorrect BCLK polarity for DSP_A/B, LEFT_J [ Upstream commit 0669631dbccd41cf3ca7aa70213fcd8bb41c4b38 ] The STM32 SAI driver do not set the clock strobing bit (CKSTR) for DSP_A, DSP_B and LEFT_J formats, causing data to be sampled on the wrong BCLK edge when SND_SOC_DAIFMT_NB_NF is used. Per ALSA convention, NB_NF requires sampling on the rising BCLK edge. The STM32MP25 SAI reference manual states that CKSTR=1 is required for signals received by the SAI to be sampled on the SCK rising edge. Without setting CKSTR=1, the SAI samples on the falling edge, violating the NB_NF convention. For comparison, the NXP FSL SAI driver correctly sets FSL_SAI_CR2_BCP for DSP_A, DSP_B and LEFT_J, consistent with its I2S handling. This patch adds SAI_XCR1_CKSTR for DSP_A, DSP_B and LEFT_J in stm32_sai_set_dai_fmt which was verified empirically with a cs47l35 codec. RIGHT_J (LSB) is not investigated and addressed by this patch. Note: the STM32 I2S driver (stm32_i2s_set_dai_fmt) may have the same issue for DSP_A mode, as I2S_CGFR_CKPOL is not set. This has not been verified and is left for a separate investigation. Signed-off-by: Tomasz Merta Link: https://patch.msgid.link/20260408084056.20588-1-tommerta@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c64cebcc5c4f223dbcbe7dcdf74908fc092a0aa4 Author: Linus Torvalds Date: Wed Apr 8 13:18:57 2026 -0700 x86: shadow stacks: proper error handling for mmap lock [ Upstream commit 52f657e34d7b21b47434d9d8b26fa7f6778b63a0 ] 김영민 reports that shstk_pop_sigframe() doesn't check for errors from mmap_read_lock_killable(), which is a silly oversight, and also shows that we haven't marked those functions with "__must_check", which would have immediately caught it. So let's fix both issues. Reported-by: 김영민 Acked-by: Oleg Nesterov Acked-by: Dave Hansen Acked-by: Rick Edgecombe Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 0a59c12ce50a768e84982b65cce9c33459ef72d0 Author: John Pavlick Date: Mon Apr 6 13:23:33 2026 +0000 net: sfp: add quirks for Hisense and HSGQ GPON ONT SFP modules [ Upstream commit 95aca8602ef70ffd3d971675751c81826e124f90 ] Several GPON ONT SFP sticks based on Realtek RTL960x report 1000BASE-LX at 1300MBd in their EEPROM but can operate at 2500base-X. On hosts capable of 2500base-X (e.g. Banana Pi R3 / MT7986), the kernel negotiates only 1G because it trusts the incorrect EEPROM data. Add quirks for: - Hisense-Leox LXT-010S-H - Hisense ZNID-GPON-2311NA - HSGQ HSGQ-XPON-Stick Each quirk advertises 2500base-X and ignores TX_FAULT during the module's ~40s Linux boot time. Tested on Banana Pi R3 (MT7986) with OpenWrt 25.12.1, confirmed 2.5Gbps link and full throughput with flow offloading. Reviewed-by: Russell King (Oracle) Suggested-by: Marcin Nita Signed-off-by: John Pavlick Link: https://patch.msgid.link/20260406132321.72563-1-jspavlick@posteo.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1ae1e1caa428844e481231f6dbe9b4f475f1d52d Author: Pengpeng Hou Date: Mon Mar 23 15:45:51 2026 +0800 wifi: brcmfmac: validate bsscfg indices in IF events [ Upstream commit 304950a467d83678bd0b0f46331882e2ac23b12d ] brcmf_fweh_handle_if_event() validates the firmware-provided interface index before it touches drvr->iflist[], but it still uses the raw bsscfgidx field as an array index without a matching range check. Reject IF events whose bsscfg index does not fit in drvr->iflist[] before indexing the interface array. Signed-off-by: Pengpeng Hou Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260323074551.93530-1-pengpeng@iscas.ac.cn [add missing wifi prefix] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit f5a5d0e8704ecd23e1eca59aebffc7512196a218 Author: Arthur Husband Date: Mon Apr 6 15:23:35 2026 -0700 ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585 [ Upstream commit 105c42566a550e2d05fc14f763216a8765ee5d0e ] The JMicron JMB585 (and JMB582) SATA controllers advertise 64-bit DMA support via the S64A bit in the AHCI CAP register, but their 64-bit DMA implementation is defective. Under sustained I/O, DMA transfers targeting addresses above 4GB silently corrupt data -- writes land at incorrect memory addresses with no errors logged. The failure pattern is similar to the ASMedia ASM1061 (commit 20730e9b2778 ("ahci: add 43-bit DMA address quirk for ASMedia ASM1061 controllers")), which also falsely advertised full 64-bit DMA support. However, the JMB585 requires a stricter 32-bit DMA mask rather than 43-bit, as corruption occurs with any address above 4GB. On the Minisforum N5 Pro specifically, the combination of the JMB585's broken 64-bit DMA with the AMD Family 1Ah (Strix Point) IOMMU causes silent data corruption that is only detectable via checksumming filesystems (BTRFS/ZFS scrub). The corruption occurs when 32-bit IOVA space is exhausted and the kernel transparently switches to 64-bit DMA addresses. Add device-specific PCI ID entries for the JMB582 (0x0582) and JMB585 (0x0585) before the generic JMicron class match, using a new board type that combines AHCI_HFLAG_IGN_IRQ_IF_ERR (preserving existing behavior) with AHCI_HFLAG_32BIT_ONLY to force 32-bit DMA masks. Signed-off-by: Arthur Husband Reviewed-by: Damien Le Moal Signed-off-by: Niklas Cassel Signed-off-by: Sasha Levin commit 36bb2d0b915014bbdc5044982b31b57b78045b93 Author: Benoît Sevens Date: Mon Mar 23 16:11:07 2026 +0000 HID: roccat: fix use-after-free in roccat_report_event [ Upstream commit d802d848308b35220f21a8025352f0c0aba15c12 ] roccat_report_event() iterates over the device->readers list without holding the readers_lock. This allows a concurrent roccat_release() to remove and free a reader while it's still being accessed, leading to a use-after-free. Protect the readers list traversal with the readers_lock mutex. Signed-off-by: Benoît Sevens Reviewed-by: Silvan Jegen Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 0fa5713ac7a19412cef73dd6a989794bb0d94ea9 Author: songxiebing Date: Sun Apr 5 09:26:51 2026 +0800 ALSA: hda/realtek: Add quirk for Lenovo Yoga Pro 7 14IAH10 [ Upstream commit f0541edb2e7333f320642c7b491a67912c1f65db ] The bass speakers are not working, and add the following entry in /etc/modprobe.d/snd.conf: options snd-sof-intel-hda-generic hda_model=alc287-yoga9-bass-spk-pin Fixes the bass speakers. So add the quick ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN here. Reported-by: Fernando Garcia Corona Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221317 Signed-off-by: songxiebing Link: https://patch.msgid.link/20260405012651.133838-1-songxiebing@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 42032a75da03900951a92c87fcf581b0e44a171d Author: leo vriska Date: Wed Mar 4 13:36:59 2026 -0500 HID: quirks: add HID_QUIRK_ALWAYS_POLL for 8BitDo Pro 3 [ Upstream commit 532743944324a873bbaf8620fcabcd0e69e30c36 ] According to a mailing list report [1], this controller's predecessor has the same issue. However, it uses the xpad driver instead of HID, so this quirk wouldn't apply. [1]: https://lore.kernel.org/linux-input/unufo3$det$1@ciao.gmane.io/ Signed-off-by: leo vriska Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit c2854af5774b04a36c87bc580e8f082521868c43 Author: Even Xu Date: Tue Mar 17 13:56:29 2026 +0800 HID: Intel-thc-hid: Intel-quickspi: Add NVL Device IDs [ Upstream commit 48e91af0cbe942d50ef6257d850accdca1d01378 ] Add Nova Lake THC QuickSPI device IDs to support list. Signed-off-by: Even Xu Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 0f2e312626c7a3a342527862165be1bd2aef5ab6 Author: Mario Limonciello Date: Tue Mar 24 16:16:41 2026 -0500 platform/x86/amd: pmc: Add Thinkpad L14 Gen3 to quirk_s2idle_bug [ Upstream commit 1a9452c428a6b76f0b797bae21daa454fccef1a2 ] This platform is a similar vintage of platforms that had a BIOS bug leading to a 10s delay at resume from s0i3. Add a quirk for it. Reported-by: Imrane Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221273 Tested-by: Imrane Signed-off-by: Mario Limonciello Link: https://patch.msgid.link/20260324211647.357924-1-mario.limonciello@amd.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 91f915d574168f0ac624e70c50ec23ef1dd8452c Author: Andy Shevchenko Date: Wed Mar 11 18:14:04 2026 +0100 pinctrl: intel: Fix the revision for new features (1kOhm PD, HW debouncer) [ Upstream commit a4337a24d13e9e3b98a113e71d6b80dc5ed5f8c4 ] The 1kOhm pull down and hardware debouncer are features of the revision 0.92 of the Chassis specification. Fix that in the code accordingly. Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit b98ecc1c60ad73d2c794d466f941585ed8d21153 Author: Alexander Savenko Date: Tue Mar 31 11:29:28 2026 +0300 ALSA: hda/realtek: Add quirk for Lenovo Yoga Pro 7 14IMH9 [ Upstream commit 217d5bc9f96272316ac5a3215c7cc32a5127bbf3 ] The Lenovo Yoga Pro 7 14IMH9 (DMI: 83E2) shares PCI SSID 17aa:3847 with the Legion 7 16ACHG6, but has a different codec subsystem ID (17aa:38cf). The existing SND_PCI_QUIRK for 17aa:3847 applies ALC287_FIXUP_LEGION_16ACHG6, which attempts to initialize an external I2C amplifier (CLSA0100) that is not present on the Yoga Pro 7 14IMH9. As a result, pin 0x17 (bass speakers) is connected to DAC 0x06 which has no volume control, making hardware volume adjustment completely non-functional. Audio is either silent or at maximum volume regardless of the slider position. Add a HDA_CODEC_QUIRK entry using the codec subsystem ID (17aa:38cf) to correctly identify the Yoga Pro 7 14IMH9 and apply ALC287_FIXUP_YOGA9_14IMH9_BASS_SPK_PIN, which redirects pin 0x17 to DAC 0x02 and restores proper volume control. The existing Legion entry is preserved unchanged. This follows the same pattern used for 17aa:386e, where Legion Y9000X and Yoga Pro 7 14ARP8 share a PCI SSID but are distinguished via HDA_CODEC_QUIRK. Link: https://github.com/nomad4tech/lenovo-yoga-pro-7-linux Tested-by: Alexander Savenko Signed-off-by: Alexander Savenko Link: https://patch.msgid.link/20260331082929.44890-1-alex.sav4387@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 1d788e6a415038746d40dd1da684c7fd843ba2f4 Author: Gilson Marquato Júnior Date: Mon Mar 30 02:43:48 2026 +0100 ASoC: amd: yc: Add DMI entry for HP Laptop 15-fc0xxx [ Upstream commit 8ec017cf31299c4b6287ebe27afe81c986aeef88 ] The HP Laptop 15-fc0xxx (subsystem ID 0x103c8dc9) has an internal DMIC connected to the AMD ACP6x audio coprocessor. Add a DMI quirk entry so the internal microphone is properly detected on this model. Tested on HP Laptop 15-fc0237ns with Fedora 43 (kernel 6.19.9). Signed-off-by: Gilson Marquato Júnior Link: https://patch.msgid.link/20260330-hp-15-fc0xxx-dmic-v2-v1-1-6dd6f53a1917@hotmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 86f9c23e0814cfdffda9eedf0c591c51ba209010 Author: Fredric Cover Date: Mon Mar 30 13:11:27 2026 -0700 fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath [ Upstream commit 78ec5bf2f589ec7fd8f169394bfeca541b077317 ] When cifs_sanitize_prepath is called with an empty string or a string containing only delimiters (e.g., "/"), the current logic attempts to check *(cursor2 - 1) before cursor2 has advanced. This results in an out-of-bounds read. This patch adds an early exit check after stripping prepended delimiters. If no path content remains, the function returns NULL. The bug was identified via manual audit and verified using a standalone test case compiled with AddressSanitizer, which triggered a SEGV on affected inputs. Signed-off-by: Fredric Cover Reviewed-by: Henrique Carvalho <[2]henrique.carvalho@suse.com> Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 647fb0dc3818733024fc96c1df1ec3af806b0256 Author: Donet Tom Date: Mon Mar 23 09:58:39 2026 +0530 drm/amdkfd: Fix queue preemption/eviction failures by aligning control stack size to GPU page size [ Upstream commit 78746a474e92fc7aaed12219bec7c78ae1bd6156 ] The control stack size is calculated based on the number of CUs and waves, and is then aligned to PAGE_SIZE. When the resulting control stack size is aligned to 64 KB, GPU hangs and queue preemption failures are observed while running RCCL unit tests on systems with more than two GPUs. amdgpu 0048:0f:00.0: amdgpu: Queue preemption failed for queue with doorbell_id: 80030008 amdgpu 0048:0f:00.0: amdgpu: Failed to evict process queues amdgpu 0048:0f:00.0: amdgpu: GPU reset begin!. Source: 4 amdgpu 0048:0f:00.0: amdgpu: Queue preemption failed for queue with doorbell_id: 80030008 amdgpu 0048:0f:00.0: amdgpu: Failed to evict process queues amdgpu 0048:0f:00.0: amdgpu: Failed to restore process queues This issue is observed on both 4 KB and 64 KB system page-size configurations. This patch fixes the issue by aligning the control stack size to AMDGPU_GPU_PAGE_SIZE instead of PAGE_SIZE, so the control stack size will not be 64 KB on systems with a 64 KB page size and queue preemption works correctly. Additionally, In the current code, wg_data_size is aligned to PAGE_SIZE, which can waste memory if the system page size is large. In this patch, wg_data_size is aligned to AMDGPU_GPU_PAGE_SIZE. The cwsr_size, calculated from wg_data_size and the control stack size, is aligned to PAGE_SIZE. Reviewed-by: Felix Kuehling Signed-off-by: Donet Tom Signed-off-by: Alex Deucher (cherry picked from commit a3e14436304392fbada359edd0f1d1659850c9b7) Signed-off-by: Sasha Levin commit fceb2a46912154495ce0f6d8b63aa7d61c0446f9 Author: songxiebing Date: Tue Mar 31 11:36:50 2026 +0800 ALSA: hda/realtek: Add quirk for Lenovo Yoga Slim 7 14AKP10 [ Upstream commit e6c888202297eca21860b669edb74fc600e679d9 ] The Pin Complex 0x17 (bass/woofer speakers) is incorrectly reported as unconnected in the BIOS (pin default 0x411111f0 = N/A). This causes the kernel to configure speaker_outs=0, meaning only the tweeters (pin 0x14) are used. The result is very low, tinny audio with no bass. The existing quirk ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN (already present in patch_realtek.c for SSID 0x17aa3801) fixes the issue completely. Reported-by: Garcicasti Link: https://bugzilla.kernel.org/show_bug.cgi?id=221298 Signed-off-by: songxiebing Link: https://patch.msgid.link/20260331033650.285601-1-songxiebing@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 66b315279b88754b0fda4b4a5c327af23c4fcb65 Author: Phil Willoughby Date: Sat Mar 28 08:07:34 2026 +0000 ALSA: usb-audio: Fix quirk flags for NeuralDSP Quad Cortex [ Upstream commit bc5b4e5ae1a67700a618328217b6a3bd0f296e97 ] The NeuralDSP Quad Cortex does not support DSD playback. We need this product-specific entry with zero quirks because otherwise it falls through to the vendor-specific entry which marks it as supporting DSD playback. Cc: Yue Wang Cc: Jaroslav Kysela Cc: Takashi Iwai Signed-off-by: Phil Willoughby Link: https://patch.msgid.link/20260328080921.3310-1-willerz@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit f664b56d8fc3f52ada3cd48950b39d70620924c8 Author: Takashi Iwai Date: Mon Mar 30 18:22:20 2026 +0200 ALSA: hda/realtek: Add quirk for Samsung Book2 Pro 360 (NP950QED) [ Upstream commit ea31be8a2c8c99eac198f3b7f2dc770111f2b182 ] There is another Book2 Pro model (NP950QED) that seems equipped with the same speaker module as the non-360 model, which requires ALC298_FIXUP_SAMSUNG_AMP_V2_2_AMPS quirk. Reported-by: Throw Link: https://patch.msgid.link/20260330162249.147665-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit a9d32e6c8a55404e2b5c147866fb19cf3fa2547c Author: Kuninori Morimoto Date: Fri Mar 27 02:43:54 2026 +0000 ASoC: soc-core: call missing INIT_LIST_HEAD() for card_aux_list [ Upstream commit b9eff9732cb0f86a68c9d1592a98ceab47c01e95 ] Component has "card_aux_list" which is added/deled in bind/unbind aux dev function (A), and used in for_each_card_auxs() loop (B). static void soc_unbind_aux_dev(...) { ... for_each_card_auxs_safe(...) { ... (A) list_del(&component->card_aux_list); } ^^^^^^^^^^^^^ } static int soc_bind_aux_dev(...) { ... for_each_card_pre_auxs(...) { ... (A) list_add(&component->card_aux_list, ...); } ^^^^^^^^^^^^^ ... } #define for_each_card_auxs(card, component) \ (B) list_for_each_entry(component, ..., card_aux_list) ^^^^^^^^^^^^^ But it has been used without calling INIT_LIST_HEAD(). > git grep card_aux_list sound/soc sound/soc/soc-core.c: list_del(&component->card_aux_list); sound/soc/soc-core.c: list_add(&component->card_aux_list, ...); call missing INIT_LIST_HEAD() for it. Signed-off-by: Kuninori Morimoto Link: https://patch.msgid.link/87341mxa8l.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8d7465be5163a923ee5d7459719ef5a021c1584a Author: Pengpeng Hou Date: Mon Mar 23 16:08:45 2026 +0800 wifi: wl1251: validate packet IDs before indexing tx_frames [ Upstream commit 0fd56fad9c56356e7fa7a7c52e7ecbf807a44eb0 ] wl1251_tx_packet_cb() uses the firmware completion ID directly to index the fixed 16-entry wl->tx_frames[] array. The ID is a raw u8 from the completion block, and the callback does not currently verify that it fits the array before dereferencing it. Reject completion IDs that fall outside wl->tx_frames[] and keep the existing NULL check in the same guard. This keeps the fix local to the trust boundary and avoids touching the rest of the completion flow. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260323080845.40033-1-pengpeng@iscas.ac.cn Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 21a1acf6b16a3678f4d5ba3fabf03098adb8b8eb Author: Dustin L. Howett Date: Fri Mar 27 10:54:40 2026 -0500 ALSA: hda/realtek: add quirk for Framework F111:000F [ Upstream commit bac1e57adf08c9ee33e95fb09cd032f330294e70 ] Similar to commit 7b509910b3ad ("ALSA hda/realtek: Add quirk for Framework F111:000C") and previous quirks for Framework systems with Realtek codecs. 000F is another new platform with an ALC285 which needs the same quirk. Signed-off-by: Dustin L. Howett Link: https://patch.msgid.link/20260327-framework-alsa-000f-v1-1-74013aba1c00@howett.net Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 07de44424bb7f17ef9357e8535df96d9e97c40cb Author: Florian Westphal Date: Wed Mar 25 14:10:55 2026 +0100 netfilter: nft_set_pipapo_avx2: don't return non-matching entry on expiry [ Upstream commit d3c0037ffe1273fa1961e779ff6906234d6cf53c ] New test case fails unexpectedly when avx2 matching functions are used. The test first loads a ranomly generated pipapo set with 'ipv4 . port' key, i.e. nft -f foo. This works. Then, it reloads the set after a flush: (echo flush set t s; cat foo) | nft -f - This is expected to work, because its the same set after all and it was already loaded once. But with avx2, this fails: nft reports a clashing element. The reported clash is of following form: We successfully re-inserted a . b c . d Then we try to insert a . d avx2 finds the already existing a . d, which (due to 'flush set') is marked as invalid in the new generation. It skips the element and moves to next. Due to incorrect masking, the skip-step finds the next matching element *only considering the first field*, i.e. we return the already reinserted "a . b", even though the last field is different and the entry should not have been matched. No such error is reported for the generic c implementation (no avx2) or when the last field has to use the 'nft_pipapo_avx2_lookup_slow' fallback. Bisection points to 7711f4bb4b36 ("netfilter: nft_set_pipapo: fix range overlap detection") but that fix merely uncovers this bug. Before this commit, the wrong element is returned, but erronously reported as a full, identical duplicate. The root-cause is too early return in the avx2 match functions. When we process the last field, we should continue to process data until the entire input size has been consumed to make sure no stale bits remain in the map. Link: https://lore.kernel.org/netfilter-devel/20260321152506.037f68c0@elisabeth/ Signed-off-by: Florian Westphal Reviewed-by: Stefano Brivio Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 7556bd5cd8ef35f5a6e520914a346487a887d295 Author: Kshamendra Kumar Mishra Date: Mon Mar 23 22:07:50 2026 +0530 ALSA: hda/realtek: add HP Laptop 15-fd0xxx mute LED quirk [ Upstream commit faceb5cf5d7a08f4a40335d22d833bb75f05d99e ] HP Laptop 15-fd0xxx with ALC236 codec does not handle the toggling of the mute LED. This patch adds a quirk entry for subsystem ID 0x8dd7 using ALC236_FIXUP_HP_MUTE_LED_COEFBIT2 fixup, enabling correct mute LED behavior. Signed-off-by: Kshamendra Kumar Mishra Link: https://patch.msgid.link/DHAB51ISUM96.2K9SZIABIDEQ0@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 6a9f2683c66dc54d3598589684c0b3c5cb2862ad Author: Donet Tom Date: Mon Mar 23 09:58:36 2026 +0530 drm/amdgpu: Handle GPU page faults correctly on non-4K page systems [ Upstream commit 4e9597f22a3cb8600c72fc266eaac57981d834c8 ] During a GPU page fault, the driver restores the SVM range and then maps it into the GPU page tables. The current implementation passes a GPU-page-size (4K-based) PFN to svm_range_restore_pages() to restore the range. SVM ranges are tracked using system-page-size PFNs. On systems where the system page size is larger than 4K, using GPU-page-size PFNs to restore the range causes two problems: Range lookup fails: Because the restore function receives PFNs in GPU (4K) units, the SVM range lookup does not find the existing range. This will result in a duplicate SVM range being created. VMA lookup failure: The restore function also tries to locate the VMA for the faulting address. It converts the GPU-page-size PFN into an address using the system page size, which results in an incorrect address on non-4K page-size systems. As a result, the VMA lookup fails with the message: "address 0xxxx VMA is removed". This patch passes the system-page-size PFN to svm_range_restore_pages() so that the SVM range is restored correctly on non-4K page systems. Acked-by: Christian König Signed-off-by: Donet Tom Signed-off-by: Alex Deucher (cherry picked from commit 074fe395fb13247b057f60004c7ebcca9f38ef46) Signed-off-by: Sasha Levin commit f338ced0473849c9f6ed0b77ca99f1aab5826787 Author: Pablo Neira Ayuso Date: Wed Mar 25 14:11:04 2026 +0100 netfilter: ctnetlink: ensure safe access to master conntrack [ Upstream commit bffcaad9afdfe45d7fc777397d3b83c1e3ebffe5 ] Holding reference on the expectation is not sufficient, the master conntrack object can just go away, making exp->master invalid. To access exp->master safely: - Grab the nf_conntrack_expect_lock, this gets serialized with clean_from_lists() which also holds this lock when the master conntrack goes away. - Hold reference on master conntrack via nf_conntrack_find_get(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths. This patch goes for extending the nf_conntrack_expect_lock section to address this issue for simplicity, in the cases that are described below this is just slightly extending the lock section. The add expectation command already holds a reference to the master conntrack from ctnetlink_create_expect(). However, the delete expectation command needs to grab the spinlock before looking up for the expectation. Expand the existing spinlock section to address this to cover the expectation lookup. Note that, the nf_ct_expect_iterate_net() calls already grabs the spinlock while iterating over the expectation table, which is correct. The get expectation command needs to grab the spinlock to ensure master conntrack does not go away. This also expands the existing spinlock section to cover the expectation lookup too. I needed to move the netlink skb allocation out of the spinlock to keep it GFP_KERNEL. For the expectation events, the IPEXP_DESTROY event is already delivered under the spinlock, just move the delivery of IPEXP_NEW under the spinlock too because the master conntrack event cache is reached through exp->master. While at it, add lockdep notations to help identify what codepaths need to grab the spinlock. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 8db3663d3c3e282313826a642494904b432213ba Author: César Montoya Date: Sat Mar 21 10:36:03 2026 -0500 ALSA: hda/realtek: Add mute LED quirk for HP Pavilion 15-eg0xxx [ Upstream commit 2f388b4e8fdd6b0f27cafd281658daacfd85807e ] The HP Pavilion 15-eg0xxx with subsystem ID 0x103c87cb uses a Realtek ALC287 codec with a mute LED wired to GPIO pin 4 (mask 0x10). The existing ALC287_FIXUP_HP_GPIO_LED fixup already handles this correctly, but the subsystem ID was missing from the quirk table. GPIO pin confirmed via manual hda-verb testing: hda-verb SET_GPIO_MASK 0x10 hda-verb SET_GPIO_DIRECTION 0x10 hda-verb SET_GPIO_DATA 0x10 Signed-off-by: César Montoya Link: https://patch.msgid.link/20260321153603.12771-1-sprit152009@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 2e4adfaec97ee053ad1bdfb5036845e66f7e0d8a Author: Goldwyn Rodrigues Date: Fri Mar 13 14:11:39 2026 -0400 btrfs: tracepoints: get correct superblock from dentry in event btrfs_sync_file() [ Upstream commit a85b46db143fda5869e7d8df8f258ccef5fa1719 ] If overlay is used on top of btrfs, dentry->d_sb translates to overlay's super block and fsid assignment will lead to a crash. Use file_inode(file)->i_sb to always get btrfs_sb. Reviewed-by: Boris Burkov Signed-off-by: Goldwyn Rodrigues Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit d4ff92dd98ad19f18b0d4a3ef1899ad9d3a32289 Author: Krishna Chomal Date: Fri Feb 27 21:11:06 2026 +0530 platform/x86: hp-wmi: Add support for Omen 16-wf1xxx (8C76) [ Upstream commit 84d29bfd1929d08f092851162a3d055a2134d043 ] The HP Omen 16-wf1xxx (board ID: 8C76) has the same WMI interface as other Victus S boards, but requires quirks for correctly switching thermal profile (similar to board 8C78). Add the DMI board name to victus_s_thermal_profile_boards[] table and map it to omen_v1_thermal_params. Testing on board 8C76 confirmed that platform profile is registered successfully and fan RPMs are readable and controllable. Tested-by: WJ Enderlava Reported-by: WJ Enderlava Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221149 Signed-off-by: Krishna Chomal Link: https://patch.msgid.link/20260227154106.226809-1-krishna.chomal108@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit fddb157536e67a055597f00a8b4922d5f5ed0826 Author: Filipe Manana Date: Tue Feb 17 14:46:50 2026 +0000 btrfs: fix zero size inode with non-zero size after log replay [ Upstream commit 5254d4181add9dfaa5e3519edd71cc8f752b2f85 ] When logging that an inode exists, as part of logging a new name or logging new dir entries for a directory, we always set the generation of the logged inode item to 0. This is to signal during log replay (in overwrite_item()), that we should not set the i_size since we only logged that an inode exists, so the i_size of the inode in the subvolume tree must be preserved (as when we log new names or that an inode exists, we don't log extents). This works fine except when we have already logged an inode in full mode or it's the first time we are logging an inode created in a past transaction, that inode has a new i_size of 0 and then we log a new name for the inode (due to a new hardlink or a rename), in which case we log an i_size of 0 for the inode and a generation of 0, which causes the log replay code to not update the inode's i_size to 0 (in overwrite_item()). An example scenario: mkdir /mnt/dir xfs_io -f -c "pwrite 0 64K" /mnt/dir/foo sync xfs_io -c "truncate 0" -c "fsync" /mnt/dir/foo ln /mnt/dir/foo /mnt/dir/bar xfs_io -c "fsync" /mnt/dir After log replay the file remains with a size of 64K. This is because when we first log the inode, when we fsync file foo, we log its current i_size of 0, and then when we create a hard link we log again the inode in exists mode (LOG_INODE_EXISTS) but we set a generation of 0 for the inode item we add to the log tree, so during log replay overwrite_item() sees that the generation is 0 and i_size is 0 so we skip updating the inode's i_size from 64K to 0. Fix this by making sure at fill_inode_item() we always log the real generation of the inode if it was logged in the current transaction with the i_size we logged before. Also if an inode created in a previous transaction is logged in exists mode only, make sure we log the i_size stored in the inode item located from the commit root, so that if we log multiple times that the inode exists we get the correct i_size. A test case for fstests will follow soon. Reported-by: Vyacheslav Kovalevsky Link: https://lore.kernel.org/linux-btrfs/af8c15fa-4e41-4bb2-885c-0bc4e97532a6@gmail.com/ Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit c66a0e9a19c077e6ae617478b214f23be8eab033 Author: Matthew Schwartz Date: Thu Mar 12 14:22:46 2026 -0700 platform/x86: asus-nb-wmi: add DMI quirk for ASUS ROG Flow Z13-KJP GZ302EAC [ Upstream commit 0198d2743207d67f995cd6df89e267e1b9f5e1f1 ] The ASUS ROG Flow Z13-KJP GZ302EAC model uses sys_vendor name ASUS rather than ASUSTeK COMPUTER INC., but it needs the same folio quirk as the other ROG Flow Z13. To keep things simple, just match on sys_vendor ASUS since it covers both. Signed-off-by: Matthew Schwartz Reviewed-by: Mario Limonciello (AMD) Reviewed-by: Denis Benato Link: https://patch.msgid.link/20260312212246.1608080-1-matthew.schwartz@linux.dev Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit c2be593c7ec2baeeadf74ec957461a31e8d50fde Author: Frank Zhang Date: Tue Mar 17 18:25:27 2026 +0800 ALSA:usb:qcom: add AUXILIARY_BUS to Kconfig dependencies [ Upstream commit b8bee48e38f2ddbdba5e58bc54ef54bb7d8d341b ] The build can fail with: ERROR: modpost: "__auxiliary_driver_register" [sound/usb/qcom/snd-usb-audio-qmi.ko] undefined! ERROR: modpost: "auxiliary_driver_unregister" [sound/usb/qcom/snd-usb-audio-qmi.ko] undefined! Select AUXILIARY_BUS when SND_USB_AUDIO_QMI is enabled. Signed-off-by: Frank Zhang Link: https://patch.msgid.link/20260317102527.556248-1-rmxpzlb@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 5486d20a08186bfe6b324b330f4893d4692008d4 Author: Hasun Park Date: Fri Mar 20 01:33:21 2026 +0900 ASoC: amd: acp: add ASUS HN7306EA quirk for legacy SDW machine [ Upstream commit 2594196f4e3bd70782e7cf1e22e3e398cdb74f78 ] Add a DMI quirk entry for ASUS HN7306EA in the ACP SoundWire legacy machine driver. Set driver_data to ASOC_SDW_ACP_DMIC for this board so the platform-specific DMIC quirk path is selected. Signed-off-by: Hasun Park Link: https://patch.msgid.link/20260319163321.30326-1-hasunpark@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c306ac170bc3d6ddb7985b612659396977322993 Author: Wenyuan Li <2063309626@qq.com> Date: Mon Mar 16 00:00:22 2026 +0800 can: mcp251x: add error handling for power enable in open and resume [ Upstream commit 7a57354756c7df223abe2c33774235ad70cb4231 ] Add missing error handling for mcp251x_power_enable() calls in both mcp251x_open() and mcp251x_can_resume() functions. In mcp251x_open(), if power enable fails, jump to error path to close candev without attempting to disable power again. In mcp251x_can_resume(), properly check return values of power enable calls for both power and transceiver regulators. If any fails, return the error code to the PM framework and log the failure. This ensures the driver properly handles power control failures and maintains correct device state. Signed-off-by: Wenyuan Li <2063309626@qq.com> Link: https://patch.msgid.link/tencent_F3EFC5D7738AC548857B91657715E2D3AA06@qq.com [mkl: fix patch description] [mkl: mcp251x_can_resume(): replace goto by return] Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 55024322915539098f7a7dd318351c7a003ff041 Author: Cássio Gabriel Date: Thu Mar 19 21:45:26 2026 -0300 ASoC: SOF: topology: reject invalid vendor array size in token parser [ Upstream commit 215e5fe75881a7e2425df04aeeed47a903d5cd5d ] sof_parse_token_sets() accepts array->size values that can be invalid for a vendor tuple array header. In particular, a zero size does not advance the parser state and can lead to non-progress parsing on malformed topology data. Validate array->size against the minimum header size and reject values smaller than sizeof(*array) before parsing. This preserves behavior for valid topologies and hardens malformed-input handling. Signed-off-by: Cássio Gabriel Acked-by: Peter Ujfalusi Link: https://patch.msgid.link/20260319-sof-topology-array-size-fix-v1-1-f9191b16b1b7@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 36d706d033462701f87067fac48c69bce44382f9 Author: Zhang Heng Date: Mon Mar 16 16:02:18 2026 +0800 ASoC: amd: yc: Add DMI quirk for Thin A15 B7VF [ Upstream commit 1f182ec9d7084db7dfdb2372d453c28f0e5c3f0a ] Add a DMI quirk for the Thin A15 B7VF fixing the issue where the internal microphone was not detected. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220833 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260316080218.2931304-1-zhangheng@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a7a1cdb4a64ca74eb95cc46648fccb8cd3f9af27 Author: Cen Zhang Date: Sun Mar 15 20:07:26 2026 +0800 Bluetooth: hci_sync: annotate data-races around hdev->req_status [ Upstream commit b6807cfc195ef99e1ac37b2e1e60df40295daa8c ] __hci_cmd_sync_sk() sets hdev->req_status under hdev->req_lock: hdev->req_status = HCI_REQ_PEND; However, several other functions read or write hdev->req_status without holding any lock: - hci_send_cmd_sync() reads req_status in hci_cmd_work (workqueue) - hci_cmd_sync_complete() reads/writes from HCI event completion - hci_cmd_sync_cancel() / hci_cmd_sync_cancel_sync() read/write - hci_abort_conn() reads in connection abort path Since __hci_cmd_sync_sk() runs on hdev->req_workqueue while hci_send_cmd_sync() runs on hdev->workqueue, these are different workqueues that can execute concurrently on different CPUs. The plain C accesses constitute a data race. Add READ_ONCE()/WRITE_ONCE() annotations on all concurrent accesses to hdev->req_status to prevent potential compiler optimizations that could affect correctness (e.g., load fusing in the wait_event condition or store reordering). Signed-off-by: Cen Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 02ce2a77acc81a90d8607d7a51aca2a2868aad2d Author: Arnd Bergmann Date: Wed Mar 18 13:40:07 2026 +0100 ALSA: asihpi: avoid write overflow check warning [ Upstream commit 591721223be9e28f83489a59289579493b8e3d83 ] clang-22 rightfully warns that the memcpy() in adapter_prepare() copies between different structures, crossing the boundary of nested structures inside it: In file included from sound/pci/asihpi/hpimsgx.c:13: In file included from include/linux/string.h:386: include/linux/fortify-string.h:569:4: error: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror,-Wattribute-warning] 569 | __write_overflow_field(p_size_field, size); The two structures seem to refer to the same layout, despite the separate definitions, so the code is in fact correct. Avoid the warning by copying the two inner structures separately. I see the same pattern happens in other functions in the same file, so there is a chance that this may come back in the future, but this instance is the only one that I saw in practice, hitting it multiple times per day in randconfig build. Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20260318124016.3488566-1-arnd@kernel.org Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 222f4fd0fe065ebdccc72f7589a874a8d58db475 Author: Arnd Bergmann Date: Mon Feb 2 10:47:51 2026 +0100 media: rkvdec: reduce stack usage in rkvdec_init_v4l2_vp9_count_tbl() [ Upstream commit c03b7dec3c4ddc97872fa12bfca75bae9cb46510 ] The deeply nested loop in rkvdec_init_v4l2_vp9_count_tbl() needs a lot of registers, so when the clang register allocator runs out, it ends up spilling countless temporaries to the stack: drivers/media/platform/rockchip/rkvdec/rkvdec-vp9.c:966:12: error: stack frame size (1472) exceeds limit (1280) in 'rkvdec_vp9_start' [-Werror,-Wframe-larger-than] Marking this function as noinline_for_stack keeps it out of rkvdec_vp9_start(), giving the compiler more room for optimization. The resulting code is good enough that both the total stack usage and the loop get enough better to stay under the warning limit, though it's still slow, and would need a larger rework if this function ends up being called in a fast path. Signed-off-by: Arnd Bergmann Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit fc40821d94b9ba396cf00cfe4f052f75e7fcc1fb Author: Matthew Schwartz Date: Fri Mar 13 10:25:03 2026 -0700 ALSA: hda/realtek: Add quirk for ASUS ROG Flow Z13-KJP GZ302EAC [ Upstream commit 59f68dc1d8df3142cb58fd2568966a9bb7b0ed8a ] Fixes lack of audio output on the ASUS ROG Flow Z13-KJP GZ302EAC model, similar to the ASUS ROG Flow Z13 GZ302EA. Signed-off-by: Matthew Schwartz Link: https://patch.msgid.link/20260313172503.285846-1-matthew.schwartz@linux.dev Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit e656ef8698e288058bccf6fc8058f6cc765aa08e Author: Zhang Heng Date: Fri Mar 13 16:06:24 2026 +0800 ALSA: hda/realtek: add quirk for Lenovo Yoga 7 2-in-1 16AKP10 [ Upstream commit 7bae956cac0433c4d41aac9f1d04e42694e0b706 ] This machine is equipped with ALC287 and requires the quirk ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN to fix the issue where the bass speakers are not configured and the speaker volume cannot be controlled. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221210 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260313080624.1395362-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b395549928e5e50efc4646b87c38e1c554dd0482 Author: Andrii Kovalchuk Date: Sun Mar 15 01:08:51 2026 +0000 ALSA: hda/realtek: Add HP ENVY Laptop 13-ba0xxx quirk [ Upstream commit 793b008cd39516385791a1d1d223d817e947a471 ] Add a PCI quirk for HP ENVY Laptop 13-ba0xxx (PCI device ID 0x8756) to enable proper mute LED and mic mute behavior using the ALC245_FIXUP_HP_X360_MUTE_LEDS fixup. Signed-off-by: Andrii Kovalchuk Link: https://patch.msgid.link/u0s-uRVegF9BN0t-4JnOUwsIAR-mVc4U4FJfJHdEHX7ro_laErHD9y35NebWybcN16gVaVHPJo1ap3AoJ1a2gqJImPvThgeNt_SYVY1KaDw=@proton.me Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 4b59719db211a30ea642be319bff91e5dba84be0 Author: Vee Satayamas Date: Sun Mar 15 21:25:12 2026 +0700 ASoC: amd: yc: Add DMI quirk for ASUS EXPERTBOOK BM1403CDA [ Upstream commit f200b2f9a810c440c6750b56fc647b73337749a1 ] Add a DMI quirk for the Asus Expertbook BM1403CDA to resolve the issue of the internal microphone not being detected. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221236 Signed-off-by: Vee Satayamas Reviewed-by: Zhang Heng Link: https://patch.msgid.link/20260315142511.66029-2-vsatayamas@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0f22c32141acdcda266b26cab2b830baf870f3e0 Author: Jacob Moroni Date: Fri Feb 27 15:27:43 2026 +0000 RDMA/irdma: Fix double free related to rereg_user_mr [ Upstream commit 29a3edd7004bb635d299fb9bc6f0ea4ef13ed5a2 ] If IB_MR_REREG_TRANS is set during rereg_user_mr, the umem will be released and a new one will be allocated in irdma_rereg_mr_trans. If any step of irdma_rereg_mr_trans fails after the new umem is allocated, it releases the umem, but does not set iwmr->region to NULL. The problem is that this failure is propagated to the user, who will then call ibv_dereg_mr (as they should). Then, the dereg_mr path will see a non-NULL umem and attempt to call ib_umem_release again. Fix this by setting iwmr->region to NULL after ib_umem_release. Fixed: 5ac388db27c4 ("RDMA/irdma: Add support to re-register a memory region") Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20260227152743.1183388-1-jmoroni@google.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 0aa0c509aa69431945ab7cdd10fee92d7072df28 Author: Vinicius Costa Gomes Date: Wed Jan 21 10:34:27 2026 -0800 dmaengine: idxd: Fix lockdep warnings when calling idxd_device_config() [ Upstream commit caf91cdf2de8b7134749d32cd4ae5520b108abb7 ] Move the check for IDXD_FLAG_CONFIGURABLE and the locking to "inside" idxd_device_config(), as this is common to all callers, and the one that wasn't holding the lock was an error (that was causing the lockdep warning). Suggested-by: Dave Jiang Reviewed-by: Dave Jiang Signed-off-by: Vinicius Costa Gomes Link: https://patch.msgid.link/20260121-idxd-fix-flr-on-kernel-queues-v3-v3-1-7ed70658a9d1@intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 5cb6e26373291118e41e008a98808981a6d2dbeb Author: Alexandre Frade Date: Sat Apr 18 19:37:02 2026 +0000 Linux 6.18.23-xanmod1 Signed-off-by: Alexandre Frade commit 8a13a70b56401b10b1b160e8f60939ed6c9975b9 Merge: 1d9cd8c1c15f 47a33eea6d51 Author: Alexandre Frade Date: Sat Apr 18 19:35:17 2026 +0000 Merge tag 'v6.18.23' into 6.18 This is the 6.18.23 stable release commit 47a33eea6d5145d53e42315381ef28286c2218fb Author: Greg Kroah-Hartman Date: Sat Apr 18 10:45:02 2026 +0200 Linux 6.18.23 Link: https://lore.kernel.org/r/20260413155731.019638460@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Florian Fainelli Tested-by: Wentao Guan Tested-by: Jon Hunter Tested-by: Pavel Machek (CIP) Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Barry K. Nathan Tested-by: Shung-Hsi Yu Tested-by: Mark Brown Tested-by: Dileep Malepu Signed-off-by: Greg Kroah-Hartman commit ad17f07e95e6e8505e2153e5b391f0d27eacce25 Author: Borislav Petkov (AMD) Date: Tue Apr 7 11:40:03 2026 +0200 x86/CPU: Fix FPDSS on Zen1 commit e55d98e7756135f32150b9b8f75d580d0d4b2dd3 upstream. Zen1's hardware divider can leave, under certain circumstances, partial results from previous operations. Those results can be leaked by another, attacker thread. Fix that with a chicken bit. Signed-off-by: Borislav Petkov (AMD) Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2d64618ea846d8d033477311f805ca487d6a6696 Author: Jiayuan Chen Date: Fri Apr 3 09:45:12 2026 +0800 net: skb: fix cross-cache free of KFENCE-allocated skb head commit 0f42e3f4fe2a58394e37241d02d9ca6ab7b7d516 upstream. SKB_SMALL_HEAD_CACHE_SIZE is intentionally set to a non-power-of-2 value (e.g. 704 on x86_64) to avoid collisions with generic kmalloc bucket sizes. This ensures that skb_kfree_head() can reliably use skb_end_offset to distinguish skb heads allocated from skb_small_head_cache vs. generic kmalloc caches. However, when KFENCE is enabled, kfence_ksize() returns the exact requested allocation size instead of the slab bucket size. If a caller (e.g. bpf_test_init) allocates skb head data via kzalloc() and the requested size happens to equal SKB_SMALL_HEAD_CACHE_SIZE, then slab_build_skb() -> ksize() returns that exact value. After subtracting skb_shared_info overhead, skb_end_offset ends up matching SKB_SMALL_HEAD_HEADROOM, causing skb_kfree_head() to incorrectly free the object to skb_small_head_cache instead of back to the original kmalloc cache, resulting in a slab cross-cache free: kmem_cache_free(skbuff_small_head): Wrong slab cache. Expected skbuff_small_head but got kmalloc-1k Fix this by always calling kfree(head) in skb_kfree_head(). This keeps the free path generic and avoids allocator-specific misclassification for KFENCE objects. Fixes: bf9f1baa279f ("net: add dedicated kmem_cache for typical/small skb->head") Reported-by: Antonius Closes: https://lore.kernel.org/netdev/CAK8a0jxC5L5N7hq-DT2_NhUyjBxrPocoiDazzsBk4TGgT1r4-A@mail.gmail.com/ Signed-off-by: Jiayuan Chen Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260403014517.142550-1-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit db297c78ce537c9ac96f0eda9b25ad72c8caefa9 Author: Pengpeng Hou Date: Wed Apr 8 13:12:49 2026 +0100 rxrpc: proc: size address buffers for %pISpc output commit a44ce6aa2efb61fe44f2cfab72bb01544bbca272 upstream. The AF_RXRPC procfs helpers format local and remote socket addresses into fixed 50-byte stack buffers with "%pISpc". That is too small for the longest current-tree IPv6-with-port form the formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a dotted-quad tail not only for v4mapped addresses, but also for ISATAP addresses via ipv6_addr_is_isatap(). As a result, a case such as [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535 is possible with the current formatter. That is 50 visible characters, so 51 bytes including the trailing NUL, which does not fit in the existing char[50] buffers used by net/rxrpc/proc.c. Size the buffers from the formatter's maximum textual form and switch the call sites to scnprintf(). Changes since v1: - correct the changelog to cite the actual maximum current-tree case explicitly - frame the proof around the ISATAP formatting path instead of the earlier mapped-v4 example Fixes: 75b54cb57ca3 ("rxrpc: Add IPv6 support") Signed-off-by: Pengpeng Hou Signed-off-by: David Howells cc: Marc Dionne cc: Anderson Nascimento cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260408121252.2249051-22-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d0035e634dae83237ab7f5681eb52b2f65d0ceb8 Author: Wang Jie Date: Wed Apr 8 13:12:48 2026 +0100 rxrpc: only handle RESPONSE during service challenge commit c43ffdcfdbb5567b1f143556df8a04b4eeea041c upstream. Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test. Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Signed-off-by: Jie Wang Signed-off-by: Yang Yang 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/20260408121252.2249051-21-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 794586789800b16dcbe235452494f4223ac80413 Author: David Howells Date: Wed Apr 8 13:12:47 2026 +0100 rxrpc: Fix buffer overread in rxgk_do_verify_authenticator() commit f564af387c8c28238f8ebc13314c589d7ba8475d upstream. Fix rxgk_do_verify_authenticator() to check the buffer size before checking the nonce. Fixes: 9d1d2b59341f ("rxrpc: rxgk: Implement the yfs-rxgk security class (GSSAPI)") Closes: https://sashiko.dev/#/patchset/20260401105614.1696001-10-dhowells@redhat.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/20260408121252.2249051-20-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4b5e8365515f4409de7d3b92a439154ee4f90f6d Author: David Howells Date: Wed Apr 8 13:12:46 2026 +0100 rxrpc: Fix leak of rxgk context in rxgk_verify_response() commit 7e1876caa8363056f58a21d3b31b82c2daf7e608 upstream. Fix rxgk_verify_response() to clean up the rxgk context it creates. Fixes: 9d1d2b59341f ("rxrpc: rxgk: Implement the yfs-rxgk security class (GSSAPI)") Closes: https://sashiko.dev/#/patchset/20260401105614.1696001-10-dhowells@redhat.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/20260408121252.2249051-19-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1f864d9daaf622aeaa774404fd51e7d6a435b046 Author: David Howells Date: Wed Apr 8 13:12:45 2026 +0100 rxrpc: Fix integer overflow in rxgk_verify_response() commit 699e52180f4231c257821c037ed5c99d5eb0edb8 upstream. In rxgk_verify_response(), there's a potential integer overflow due to rounding up token_len before checking it, thereby allowing the length check to be bypassed. Fix this by checking the unrounded value against len too (len is limited as the response must fit in a single UDP packet). Fixes: 9d1d2b59341f ("rxrpc: rxgk: Implement the yfs-rxgk security class (GSSAPI)") Closes: https://sashiko.dev/#/patchset/20260401105614.1696001-10-dhowells@redhat.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/20260408121252.2249051-18-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit bf4d6e4a6856eedeb7f66eb91224115bfff4e2cb Author: David Howells Date: Wed Apr 8 13:12:44 2026 +0100 rxrpc: Fix missing error checks for rxkad encryption/decryption failure commit f93af41b9f5f798823d0d0fb8765c2a936d76270 upstream. Add error checking for failure of crypto_skcipher_en/decrypt() to various rxkad function as the crypto functions can fail with ENOMEM at least. Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Closes: https://sashiko.dev/#/patchset/20260401105614.1696001-10-dhowells@redhat.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/20260408121252.2249051-17-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 03d1c51decaeb8700746ef79c50f4ebb6f1d8139 Author: David Howells Date: Wed Apr 8 13:12:43 2026 +0100 rxrpc: Fix key/keyring checks in setsockopt(RXRPC_SECURITY_KEY/KEYRING) commit 2afd86ccbb2082a3c4258aea8c07e5bb6267bc2f upstream. An AF_RXRPC socket can be both client and server at the same time. When sending new calls (ie. it's acting as a client), it uses rx->key to set the security, and when accepting incoming calls (ie. it's acting as a server), it uses rx->securities. setsockopt(RXRPC_SECURITY_KEY) sets rx->key to point to an rxrpc-type key and setsockopt(RXRPC_SECURITY_KEYRING) sets rx->securities to point to a keyring of rxrpc_s-type keys. Now, it should be possible to use both rx->key and rx->securities on the same socket - but for userspace AF_RXRPC sockets rxrpc_setsockopt() prevents that. Fix this by: (1) Remove the incorrect check rxrpc_setsockopt(RXRPC_SECURITY_KEYRING) makes on rx->key. (2) Move the check that rxrpc_setsockopt(RXRPC_SECURITY_KEY) makes on rx->key down into rxrpc_request_key(). (3) Remove rxrpc_request_key()'s check on rx->securities. This (in combination with a previous patch) pushes the checks down into the functions that set those pointers and removes the cross-checks that prevent both key and keyring being set. Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Closes: https://sashiko.dev/#/patchset/20260401105614.1696001-10-dhowells@redhat.com Signed-off-by: David Howells cc: Marc Dionne cc: Anderson Nascimento cc: Luxiao Xu cc: Yuan Tan cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260408121252.2249051-16-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8ee931c3cd97f1c42b4fbf057f04b9dae45dfb7a Author: Luxiao Xu Date: Wed Apr 8 13:12:42 2026 +0100 rxrpc: fix reference count leak in rxrpc_server_keyring() commit f125846ee79fcae537a964ce66494e96fa54a6de upstream. This patch fixes a reference count leak in rxrpc_server_keyring() by checking if rx->securities is already set. Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Tested-by: Ren Wei Signed-off-by: Luxiao Xu Signed-off-by: Ren Wei 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/20260408121252.2249051-15-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit beee051f259acd286fed64c32c2b31e6f5097eb5 Author: Keenan Dong Date: Wed Apr 8 13:12:41 2026 +0100 rxrpc: fix oversized RESPONSE authenticator length check commit a2567217ade970ecc458144b6be469bc015b23e5 upstream. rxgk_verify_response() decodes auth_len from the packet and is supposed to verify that it fits in the remaining bytes. The existing check is inverted, so oversized RESPONSE authenticators are accepted and passed to rxgk_decrypt_skb(), which can later reach skb_to_sgvec() with an impossible length and hit BUG_ON(len). Decoded from the original latest-net reproduction logs with scripts/decode_stacktrace.sh: RIP: __skb_to_sgvec() [net/core/skbuff.c:5285 (discriminator 1)] Call Trace: skb_to_sgvec() [net/core/skbuff.c:5305] rxgk_decrypt_skb() [net/rxrpc/rxgk_common.h:81] rxgk_verify_response() [net/rxrpc/rxgk.c:1268] rxrpc_process_connection() [net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364 net/rxrpc/conn_event.c:386] process_one_work() [kernel/workqueue.c:3281] worker_thread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] ret_from_fork() [arch/x86/kernel/process.c:164] Reject authenticator lengths that exceed the remaining packet payload. Fixes: 9d1d2b59341f ("rxrpc: rxgk: Implement the yfs-rxgk security class (GSSAPI)") Signed-off-by: Keenan Dong Signed-off-by: David Howells cc: Marc Dionne cc: Simon Horman cc: Willy Tarreau cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260408121252.2249051-14-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7875f3d9777bd4e9892c4db830571ab8ac2044c0 Author: Keenan Dong Date: Wed Apr 8 13:12:40 2026 +0100 rxrpc: fix RESPONSE authenticator parser OOB read commit 3e3138007887504ee9206d0bfb5acb062c600025 upstream. rxgk_verify_authenticator() copies auth_len bytes into a temporary buffer and then passes p + auth_len as the parser limit to rxgk_do_verify_authenticator(). Since p is a __be32 *, that inflates the parser end pointer by a factor of four and lets malformed RESPONSE authenticators read past the kmalloc() buffer. Decoded from the original latest-net reproduction logs with scripts/decode_stacktrace.sh: BUG: KASAN: slab-out-of-bounds in rxgk_verify_response() Call Trace: dump_stack_lvl() [lib/dump_stack.c:123] print_report() [mm/kasan/report.c:379 mm/kasan/report.c:482] kasan_report() [mm/kasan/report.c:597] rxgk_verify_response() [net/rxrpc/rxgk.c:1103 net/rxrpc/rxgk.c:1167 net/rxrpc/rxgk.c:1274] rxrpc_process_connection() [net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364 net/rxrpc/conn_event.c:386] process_one_work() [kernel/workqueue.c:3281] worker_thread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] ret_from_fork() [arch/x86/kernel/process.c:164] Allocated by task 54: rxgk_verify_response() [include/linux/slab.h:954 net/rxrpc/rxgk.c:1155 net/rxrpc/rxgk.c:1274] rxrpc_process_connection() [net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364 net/rxrpc/conn_event.c:386] Convert the byte count to __be32 units before constructing the parser limit. Fixes: 9d1d2b59341f ("rxrpc: rxgk: Implement the yfs-rxgk security class (GSSAPI)") Signed-off-by: Keenan Dong Signed-off-by: David Howells cc: Marc Dionne cc: Simon Horman cc: Willy Tarreau cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260408121252.2249051-13-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 22f6258e7b31dba9bf88dce4e3ee7f0f20072e60 Author: Yuqi Xu Date: Wed Apr 8 13:12:39 2026 +0100 rxrpc: reject undecryptable rxkad response tickets commit fe4447cd95623b1cfacc15f280aab73a6d7340b2 upstream. rxkad_decrypt_ticket() decrypts the RXKAD response ticket and then parses the buffer as plaintext without checking whether crypto_skcipher_decrypt() succeeded. A malformed RESPONSE can therefore use a non-block-aligned ticket length, make the decrypt operation fail, and still drive the ticket parser with attacker-controlled bytes. Check the decrypt result and abort the connection with RXKADBADTICKET when ticket decryption fails. Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Tested-by: Ren Wei Signed-off-by: Yuqi Xu Signed-off-by: Ren Wei 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/20260408121252.2249051-12-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8299ca146489664e3c0c90a3b8900d8335b1ede4 Author: Douya Le Date: Wed Apr 8 13:12:38 2026 +0100 rxrpc: Only put the call ref if one was acquired commit 6331f1b24a3e85465f6454e003a3e6c22005a5c5 upstream. rxrpc_input_packet_on_conn() can process a to-client packet after the current client call on the channel has already been torn down. In that case chan->call is NULL, rxrpc_try_get_call() returns NULL and there is no reference to drop. The client-side implicit-end error path does not account for that and unconditionally calls rxrpc_put_call(). This turns a protocol error path into a kernel crash instead of rejecting the packet. Only drop the call reference if one was actually acquired. Keep the existing protocol error handling unchanged. Fixes: 5e6ef4f1017c ("rxrpc: Make the I/O thread take over the call and local processor work") Reported-by: Yifan Wu Reported-by: Juefei Pu Signed-off-by: Douya Le Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Signed-off-by: Ao Zhou 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/20260408121252.2249051-11-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8b353f5f138573b50dd50bdaf1d822c77b0c4cfe Author: Marc Dionne Date: Wed Apr 8 13:12:37 2026 +0100 rxrpc: Fix to request an ack if window is limited commit 0cd3e3f3f2ec1a45aa559e2c0f3d57fac5eb3c25 upstream. Peers may only send immediate acks for every 2 UDP packets received. When sending a jumbogram, it is important to check that there is sufficient window space to send another same sized jumbogram following the current one, and request an ack if there isn't. Failure to do so may cause the call to stall waiting for an ack until the resend timer fires. Where jumbograms are in use this causes a very significant drop in performance. Fixes: fe24a5494390 ("rxrpc: Send jumbo DATA packets") Signed-off-by: Marc Dionne Signed-off-by: David Howells cc: Jeffrey Altman cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260408121252.2249051-10-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2e6ef713b1598f6acd7f302fa6b12b6731c89914 Author: Anderson Nascimento Date: Wed Apr 8 13:12:36 2026 +0100 rxrpc: Fix key reference count leak from call->key commit d666540d217e8d420544ebdfbadeedd623562733 upstream. When creating a client call in rxrpc_alloc_client_call(), the code obtains a reference to the key. This is never cleaned up and gets leaked when the call is destroyed. Fix this by freeing call->key in rxrpc_destroy_call(). Before the patch, it shows the key reference counter elevated: $ cat /proc/keys | grep afs@54321 1bffe9cd I--Q--i 8053480 4169w 3b010000 1000 1000 rxrpc afs@54321: ka $ After the patch, the invalidated key is removed when the code exits: $ cat /proc/keys | grep afs@54321 $ Fixes: f3441d4125fc ("rxrpc: Copy client call parameters into rxrpc_call earlier") Signed-off-by: Anderson Nascimento Co-developed-by: David Howells Signed-off-by: David Howells Reviewed-by: Jeffrey Altman cc: Marc Dionne cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260408121252.2249051-9-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 86303a1da93f6ecdd0792330a71c71e20aeef718 Author: Alok Tiwari Date: Wed Apr 8 13:12:35 2026 +0100 rxrpc: Fix rack timer warning to report unexpected mode commit 65b3ffe0972ed023acc3981a0f7e1ae5d0208bd3 upstream. rxrpc_rack_timer_expired() clears call->rack_timer_mode to OFF before the switch. The default case warning therefore always prints OFF and doesn't identify the unexpected timer mode. Log the saved mode value instead so the warning reports the actual unexpected rack timer mode. Fixes: 7c482665931b ("rxrpc: Implement RACK/TLP to deal with transmission stalls [RFC8985]") Signed-off-by: Alok Tiwari Signed-off-by: David Howells Reviewed-by: Simon Horman Reviewed-by: Jeffrey Altman cc: Marc Dionne cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260408121252.2249051-8-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9132b1a7bf83b4a8042fffbc99d075b727a16742 Author: Alok Tiwari Date: Wed Apr 8 13:12:34 2026 +0100 rxrpc: Fix use of wrong skb when comparing queued RESP challenge serial commit b33f5741bb187db8ff32e8f5b96def77cc94dfca upstream. In rxrpc_post_response(), the code should be comparing the challenge serial number from the cached response before deciding to switch to a newer response, but looks at the newer packet private data instead, rendering the comparison always false. Fix this by switching to look at the older packet. Fix further[1] to substitute the new packet in place of the old one if newer and also to release whichever we don't use. Fixes: 5800b1cf3fd8 ("rxrpc: Allow CHALLENGEs to the passed to the app for a RESPONSE") Signed-off-by: Alok Tiwari Signed-off-by: David Howells Reviewed-by: Jeffrey Altman cc: Marc Dionne cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://sashiko.dev/#/patchset/20260319150150.4189381-1-dhowells%40redhat.com [1] Link: https://patch.msgid.link/20260408121252.2249051-7-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3e04596cba8a86cbff9c3f4bf0a524a3a488773c Author: Oleh Konko Date: Wed Apr 8 13:12:33 2026 +0100 rxrpc: Fix RxGK token loading to check bounds commit d179a868dd755b0cfcf7582e00943d702b9943b8 upstream. rxrpc_preparse_xdr_yfs_rxgk() reads the raw key length and ticket length from the XDR token as u32 values and passes each through round_up(x, 4) before using the rounded value for validation and allocation. When the raw length is >= 0xfffffffd, round_up() wraps to 0, so the bounds check and kzalloc both use 0 while the subsequent memcpy still copies the original ~4 GiB value, producing a heap buffer overflow reachable from an unprivileged add_key() call. Fix this by: (1) Rejecting raw key lengths above AFSTOKEN_GK_KEY_MAX and raw ticket lengths above AFSTOKEN_GK_TOKEN_MAX before rounding, consistent with the caps that the RxKAD path already enforces via AFSTOKEN_RK_TIX_MAX. (2) Sizing the flexible-array allocation from the validated raw key length via struct_size_t() instead of the rounded value. (3) Caching the raw lengths so that the later field assignments and memcpy calls do not re-read from the token, eliminating a class of TOCTOU re-parse. The control path (valid token with lengths within bounds) is unaffected. Fixes: 0ca100ff4df6 ("rxrpc: Add YFS RxGK (GSSAPI) security class") Signed-off-by: Oleh Konko Signed-off-by: David Howells Reviewed-by: Jeffrey Altman cc: Marc Dionne cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260408121252.2249051-6-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3be718f659683ad89fad6f1eb66bee99727cae64 Author: David Howells Date: Wed Apr 8 13:12:32 2026 +0100 rxrpc: Fix call removal to use RCU safe deletion commit 146d4ab94cf129ee06cd467cb5c71368a6b5bad6 upstream. Fix rxrpc call removal from the rxnet->calls list to use list_del_rcu() rather than list_del_init() to prevent stuffing up reading /proc/net/rxrpc/calls from potentially getting into an infinite loop. This, however, means that list_empty() no longer works on an entry that's been deleted from the list, making it harder to detect prior deletion. Fix this by: Firstly, make rxrpc_destroy_all_calls() only dump the first ten calls that are unexpectedly still on the list. Limiting the number of steps means there's no need to call cond_resched() or to remove calls from the list here, thereby eliminating the need for rxrpc_put_call() to check for that. rxrpc_put_call() can then be fixed to unconditionally delete the call from the list as it is the only place that the deletion occurs. Fixes: 2baec2c3f854 ("rxrpc: Support network namespacing") Closes: https://sashiko.dev/#/patchset/20260319150150.4189381-1-dhowells%40redhat.com Signed-off-by: David Howells cc: Marc Dionne cc: Jeffrey Altman cc: Linus Torvalds cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260408121252.2249051-5-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3bb18ed3b2f6a9659c5cf05809dbde3225944cba Author: David Howells Date: Wed Apr 8 13:12:31 2026 +0100 rxrpc: Fix anonymous key handling commit 6a59d84b4fc2f27f7b40e348506cc686712e260b upstream. In rxrpc_new_client_call_for_sendmsg(), a key with no payload is meant to be substituted for a NULL key pointer, but the variable this is done with is subsequently not used. Fix this by using "key" rather than "rx->key" when filling in the connection parameters. Note that this only affects direct use of AF_RXRPC; the kAFS filesystem doesn't use sendmsg() directly and so bypasses the issue. Further, AF_RXRPC passes a NULL key in if no key is set, so using an anonymous key in that manner works. Since this hasn't been noticed to this point, it might be better just to remove the "key" variable and the code that sets it - and, arguably, rxrpc_init_client_call_security() would be a better place to handle it. Fixes: 19ffa01c9c45 ("rxrpc: Use structs to hold connection params and protocol info") Closes: https://sashiko.dev/#/patchset/20260319150150.4189381-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/20260408121252.2249051-4-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d5f76f812d2c0ea6dd651b0586be49e85ecca085 Author: David Howells Date: Wed Apr 8 13:12:30 2026 +0100 rxrpc: Fix key parsing memleak commit b555912b9b21075e8298015f888ffe3ff60b1a97 upstream. In rxrpc_preparse_xdr_yfs_rxgk(), the memory attached to token->rxgk can be leaked in a few error paths after it's allocated. Fix this by freeing it in the "reject_token:" case. Fixes: 0ca100ff4df6 ("rxrpc: Add YFS RxGK (GSSAPI) security class") Closes: https://sashiko.dev/#/patchset/20260319150150.4189381-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/20260408121252.2249051-3-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 862cb78fb2c984af7ed94aea90bbc115d8ebd815 Author: David Howells Date: Wed Apr 8 13:12:29 2026 +0100 rxrpc: Fix key quota calculation for multitoken keys commit bdbfead6d38979475df0c2f4bad2b19394fe9bdc upstream. In the rxrpc key preparsing, every token extracted sets the proposed quota value, but for multitoken keys, this will overwrite the previous proposed quota, losing it. Fix this by adding to the proposed quota instead. Fixes: 8a7a3eb4ddbe ("KEYS: RxRPC: Use key preparsing") Closes: https://sashiko.dev/#/patchset/20260319150150.4189381-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/20260408121252.2249051-2-dhowells@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 92a673019943770930e2a8bfd52e1aad47a1fc1f Author: David Carlier Date: Sun Apr 5 06:52:41 2026 +0100 net: lan966x: fix use-after-free and leak in lan966x_fdma_reload() commit 59c3d55a946cacdb4181600723c20ac4f4c20c84 upstream. When lan966x_fdma_reload() fails to allocate new RX buffers, the restore path restarts DMA using old descriptors whose pages were already freed via lan966x_fdma_rx_free_pages(). Since page_pool_put_full_page() can release pages back to the buddy allocator, the hardware may DMA into memory now owned by other kernel subsystems. Additionally, on the restore path, the newly created page pool (if allocation partially succeeded) is overwritten without being destroyed, leaking it. Fix both issues by deferring the release of old pages until after the new allocation succeeds. Save the old page array before the allocation so old pages can be freed on the success path. On the failure path, the old descriptors, pages and page pool are all still valid, making the restore safe. Also ensure the restore path re-enables NAPI and wakes the netdev, matching the success path. Fixes: 89ba464fcf54 ("net: lan966x: refactor buffer reload function") Cc: stable@vger.kernel.org Signed-off-by: David Carlier Link: https://patch.msgid.link/20260405055241.35767-4-devnexen@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 22e1ee9f22b5c3bb702bb6d4167d770002a85b2b Author: David Carlier Date: Sun Apr 5 06:52:40 2026 +0100 net: lan966x: fix page pool leak in error paths commit 076344a6ad9d1308faaed1402fdcfdda68b604ab upstream. lan966x_fdma_rx_alloc() creates a page pool but does not destroy it if the subsequent fdma_alloc_coherent() call fails, leaking the pool. Similarly, lan966x_fdma_init() frees the coherent DMA memory when lan966x_fdma_tx_alloc() fails but does not destroy the page pool that was successfully created by lan966x_fdma_rx_alloc(), leaking it. Add the missing page_pool_destroy() calls in both error paths. Fixes: 11871aba1974 ("net: lan96x: Use page_pool API") Cc: stable@vger.kernel.org Signed-off-by: David Carlier Link: https://patch.msgid.link/20260405055241.35767-3-devnexen@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit b5dcb41ba891b55157006cac79825c78a32b409e Author: David Carlier Date: Sun Apr 5 06:52:39 2026 +0100 net: lan966x: fix page_pool error handling in lan966x_fdma_rx_alloc_page_pool() commit 3fd0da4fd8851a7e62d009b7db6c4a05b092bc19 upstream. page_pool_create() can return an ERR_PTR on failure. The return value is used unconditionally in the loop that follows, passing the error pointer through xdp_rxq_info_reg_mem_model() into page_pool_use_xdp_mem(), which dereferences it, causing a kernel oops. Add an IS_ERR check after page_pool_create() to return early on failure. Fixes: 11871aba1974 ("net: lan96x: Use page_pool API") Cc: stable@vger.kernel.org Signed-off-by: David Carlier Link: https://patch.msgid.link/20260405055241.35767-2-devnexen@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 214ceaa8a3a24e2d9bcc343e3f20f4244124b9ec Author: Emil Tantilov Date: Thu Mar 19 14:13:35 2026 -0700 idpf: set the payload size before calling the async handler commit 8e2a2420e267a515f6db56a6e9570b5cacd92919 upstream. Set the payload size before forwarding the reply to the async handler. Without this, xn->reply_sz will be 0 and idpf_mac_filter_async_handler() will never get past the size check. Fixes: 34c21fa894a1 ("idpf: implement virtchnl transaction manager") Cc: stable@vger.kernel.org Signed-off-by: Emil Tantilov Reviewed-by: Aleksandr Loktionov Reviewed-by: Li Li Acked-by: Sebastian Andrzej Siewior Tested-by: Samuel Salin Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit d6e9bef3313a3bff4d964a0408a8ec7e8d0b6c3f Author: Emil Tantilov Date: Thu Mar 19 14:13:34 2026 -0700 idpf: improve locking around idpf_vc_xn_push_free() commit d086fae65006368618104ba4c57779440eab2217 upstream. Protect the set_bit() operation for the free_xn bitmask in idpf_vc_xn_push_free(), to make the locking consistent with rest of the code and avoid potential races in that logic. Fixes: 34c21fa894a1 ("idpf: implement virtchnl transaction manager") Cc: stable@vger.kernel.org Reported-by: Ray Zhang Signed-off-by: Emil Tantilov Reviewed-by: Aleksandr Loktionov Acked-by: Sebastian Andrzej Siewior Tested-by: Samuel Salin Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit e02c974fc331f04b5ba2007d4bc6862df8a43148 Author: Emil Tantilov Date: Thu Mar 19 14:13:33 2026 -0700 idpf: fix PREEMPT_RT raw/bh spinlock nesting for async VC handling commit 591478118293c1bd628de330a99eb1eb2ef8d76b upstream. Switch from using the completion's raw spinlock to a local lock in the idpf_vc_xn struct. The conversion is safe because complete/_all() are called outside the lock and there is no reason to share the completion lock in the current logic. This avoids invalid wait context reported by the kernel due to the async handler taking BH spinlock: [ 805.726977] ============================= [ 805.726991] [ BUG: Invalid wait context ] [ 805.727006] 7.0.0-rc2-net-devq-031026+ #28 Tainted: G S OE [ 805.727026] ----------------------------- [ 805.727038] kworker/u261:0/572 is trying to lock: [ 805.727051] ff190da6a8dbb6a0 (&vport_config->mac_filter_list_lock){+...}-{3:3}, at: idpf_mac_filter_async_handler+0xe9/0x260 [idpf] [ 805.727099] other info that might help us debug this: [ 805.727111] context-{5:5} [ 805.727119] 3 locks held by kworker/u261:0/572: [ 805.727132] #0: ff190da6db3e6148 ((wq_completion)idpf-0000:83:00.0-mbx){+.+.}-{0:0}, at: process_one_work+0x4b5/0x730 [ 805.727163] #1: ff3c6f0a6131fe50 ((work_completion)(&(&adapter->mbx_task)->work)){+.+.}-{0:0}, at: process_one_work+0x1e5/0x730 [ 805.727191] #2: ff190da765190020 (&x->wait#34){+.+.}-{2:2}, at: idpf_recv_mb_msg+0xc8/0x710 [idpf] [ 805.727218] stack backtrace: ... [ 805.727238] Workqueue: idpf-0000:83:00.0-mbx idpf_mbx_task [idpf] [ 805.727247] Call Trace: [ 805.727249] [ 805.727251] dump_stack_lvl+0x77/0xb0 [ 805.727259] __lock_acquire+0xb3b/0x2290 [ 805.727268] ? __irq_work_queue_local+0x59/0x130 [ 805.727275] lock_acquire+0xc6/0x2f0 [ 805.727277] ? idpf_mac_filter_async_handler+0xe9/0x260 [idpf] [ 805.727284] ? _printk+0x5b/0x80 [ 805.727290] _raw_spin_lock_bh+0x38/0x50 [ 805.727298] ? idpf_mac_filter_async_handler+0xe9/0x260 [idpf] [ 805.727303] idpf_mac_filter_async_handler+0xe9/0x260 [idpf] [ 805.727310] idpf_recv_mb_msg+0x1c8/0x710 [idpf] [ 805.727317] process_one_work+0x226/0x730 [ 805.727322] worker_thread+0x19e/0x340 [ 805.727325] ? __pfx_worker_thread+0x10/0x10 [ 805.727328] kthread+0xf4/0x130 [ 805.727333] ? __pfx_kthread+0x10/0x10 [ 805.727336] ret_from_fork+0x32c/0x410 [ 805.727345] ? __pfx_kthread+0x10/0x10 [ 805.727347] ret_from_fork_asm+0x1a/0x30 [ 805.727354] Fixes: 34c21fa894a1 ("idpf: implement virtchnl transaction manager") Cc: stable@vger.kernel.org Suggested-by: Sebastian Andrzej Siewior Reported-by: Ray Zhang Signed-off-by: Emil Tantilov Reviewed-by: Aleksandr Loktionov Acked-by: Sebastian Andrzej Siewior Tested-by: Samuel Salin Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit 576543bedd616254032d4ebe54a90076f9e31740 Author: Baolin Wang Date: Tue Mar 17 17:29:55 2026 +0800 mm: filemap: fix nr_pages calculation overflow in filemap_map_pages() commit f58df566524ebcdfa394329c64f47e3c9257516e upstream. When running stress-ng on my Arm64 machine with v7.0-rc3 kernel, I encountered some very strange crash issues showing up as "Bad page state": " [ 734.496287] BUG: Bad page state in process stress-ng-env pfn:415735fb [ 734.496427] page: refcount:0 mapcount:1 mapping:0000000000000000 index:0x4cf316 pfn:0x415735fb [ 734.496434] flags: 0x57fffe000000800(owner_2|node=1|zone=2|lastcpupid=0x3ffff) [ 734.496439] raw: 057fffe000000800 0000000000000000 dead000000000122 0000000000000000 [ 734.496440] raw: 00000000004cf316 0000000000000000 0000000000000000 0000000000000000 [ 734.496442] page dumped because: nonzero mapcount " After analyzing this page’s state, it is hard to understand why the mapcount is not 0 while the refcount is 0, since this page is not where the issue first occurred. By enabling the CONFIG_DEBUG_VM config, I can reproduce the crash as well and captured the first warning where the issue appears: " [ 734.469226] page: refcount:33 mapcount:0 mapping:00000000bef2d187 index:0x81a0 pfn:0x415735c0 [ 734.469304] head: order:5 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 734.469315] memcg:ffff000807a8ec00 [ 734.469320] aops:ext4_da_aops ino:100b6f dentry name(?):"stress-ng-mmaptorture-9397-0-2736200540" [ 734.469335] flags: 0x57fffe400000069(locked|uptodate|lru|head|node=1|zone=2|lastcpupid=0x3ffff) ...... [ 734.469364] page dumped because: VM_WARN_ON_FOLIO((_Generic((page + nr_pages - 1), const struct page *: (const struct folio *)_compound_head(page + nr_pages - 1), struct page *: (struct folio *)_compound_head(page + nr_pages - 1))) != folio) [ 734.469390] ------------[ cut here ]------------ [ 734.469393] WARNING: ./include/linux/rmap.h:351 at folio_add_file_rmap_ptes+0x3b8/0x468, CPU#90: stress-ng-mlock/9430 [ 734.469551] folio_add_file_rmap_ptes+0x3b8/0x468 (P) [ 734.469555] set_pte_range+0xd8/0x2f8 [ 734.469566] filemap_map_folio_range+0x190/0x400 [ 734.469579] filemap_map_pages+0x348/0x638 [ 734.469583] do_fault_around+0x140/0x198 ...... [ 734.469640] el0t_64_sync+0x184/0x188 " The code that triggers the warning is: "VM_WARN_ON_FOLIO(page_folio(page + nr_pages - 1) != folio, folio)", which indicates that set_pte_range() tried to map beyond the large folio’s size. By adding more debug information, I found that 'nr_pages' had overflowed in filemap_map_pages(), causing set_pte_range() to establish mappings for a range exceeding the folio size, potentially corrupting fields of pages that do not belong to this folio (e.g., page->_mapcount). After above analysis, I think the possible race is as follows: CPU 0 CPU 1 filemap_map_pages() ext4_setattr() //get and lock folio with old inode->i_size next_uptodate_folio() ....... //shrink the inode->i_size i_size_write(inode, attr->ia_size); //calculate the end_pgoff with the new inode->i_size file_end = DIV_ROUND_UP(i_size_read(mapping->host), PAGE_SIZE) - 1; end_pgoff = min(end_pgoff, file_end); ...... //nr_pages can be overflowed, cause xas.xa_index > end_pgoff end = folio_next_index(folio) - 1; nr_pages = min(end, end_pgoff) - xas.xa_index + 1; ...... //map large folio filemap_map_folio_range() ...... //truncate folios truncate_pagecache(inode, inode->i_size); To fix this issue, move the 'end_pgoff' calculation before next_uptodate_folio(), so the retrieved folio stays consistent with the file end to avoid 'nr_pages' calculation overflow. After this patch, the crash issue is gone. Link: https://lkml.kernel.org/r/1cf1ac59018fc647a87b0dad605d4056a71c14e4.1773739704.git.baolin.wang@linux.alibaba.com Fixes: 743a2753a02e ("filemap: cap PTE range to be created to allowed zero fill in folio_map_range()") Signed-off-by: Baolin Wang Reported-by: Yuanhe Shu Tested-by: Yuanhe Shu Acked-by: Kiryl Shutsemau (Meta) Acked-by: David Hildenbrand (Arm) Cc: Christian Brauner Cc: Daniel Gomez Cc: "Darrick J. Wong" Cc: Dave Chinner Cc: David Howells Cc: Hannes Reinecke Cc: Lorenzo Stoakes (Oracle) Cc: Luis Chamberalin Cc: Matthew Wilcox (Oracle) Cc: Pankaj Raghav Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 6fca757c20396dc2e604dcc61922264e9e3dc803 Author: Tyllis Xu Date: Tue Mar 31 23:47:07 2026 -0500 net: stmmac: fix integer underflow in chain mode commit 51f4e090b9f87b40c21b6daadb5c06e6c0a07b67 upstream. The jumbo_frm() chain-mode implementation unconditionally computes len = nopaged_len - bmax; where nopaged_len = skb_headlen(skb) (linear bytes only) and bmax is BUF_SIZE_8KiB or BUF_SIZE_2KiB. However, the caller stmmac_xmit() decides to invoke jumbo_frm() based on skb->len (total length including page fragments): is_jumbo = stmmac_is_jumbo_frm(priv, skb->len, enh_desc); When a packet has a small linear portion (nopaged_len <= bmax) but a large total length due to page fragments (skb->len > bmax), the subtraction wraps as an unsigned integer, producing a huge len value (~0xFFFFxxxx). This causes the while (len != 0) loop to execute hundreds of thousands of iterations, passing skb->data + bmax * i pointers far beyond the skb buffer to dma_map_single(). On IOMMU-less SoCs (the typical deployment for stmmac), this maps arbitrary kernel memory to the DMA engine, constituting a kernel memory disclosure and potential memory corruption from hardware. Fix this by introducing a buf_len local variable clamped to min(nopaged_len, bmax). Computing len = nopaged_len - buf_len is then always safe: it is zero when the linear portion fits within a single descriptor, causing the while (len != 0) loop to be skipped naturally, and the fragment loop in stmmac_xmit() handles page fragments afterward. Fixes: 286a83721720 ("stmmac: add CHAINED descriptor mode support (V4)") Cc: stable@vger.kernel.org Signed-off-by: Tyllis Xu Link: https://patch.msgid.link/20260401044708.1386919-1-LivelyCarpet87@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9fdece45f6e097eaea0e721057ad7ee5c01fc2b2 Author: Pengpeng Hou Date: Thu Apr 2 15:12:07 2026 +0800 net: qualcomm: qca_uart: report the consumed byte on RX skb allocation failure commit b76254c55dc8f23edc089027dd3f8792554c69fb upstream. qca_tty_receive() consumes each input byte before checking whether a completed frame needs a fresh receive skb. When the current byte completes a frame, the driver delivers that frame and then allocates a new skb for the next one. If that allocation fails, the current code returns i even though data[i] has already been consumed and may already have completed the delivered frame. Since serdev interprets the return value as the number of accepted bytes, this under-reports progress by one byte and can replay the final byte of the completed frame into a fresh parser state on the next call. Return i + 1 in that failure path so the accepted-byte count matches the actual receive-state progress. Fixes: dfc768fbe618 ("net: qualcomm: add QCA7000 UART driver") Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou Reviewed-by: Stefan Wahren Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260402071207.4036-1-pengpeng@iscas.ac.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ea7468f61be033f4e18b95f2912010ed1d175d75 Author: Johan Hovold Date: Fri Mar 27 11:52:06 2026 +0100 mmc: vub300: fix use-after-free on disconnect commit 8f4d20a710225ec7a565f6a0459862d3b1f32330 upstream. The vub300 driver maintains an explicit reference count for the controller and its driver data and the last reference can in theory be dropped after the driver has been unbound. This specifically means that the controller allocation must not be device managed as that can lead to use-after-free. Note that the lifetime is currently also incorrectly tied the parent USB device rather than interface, which can lead to memory leaks if the driver is unbound without its device being physically disconnected (e.g. on probe deferral). Fix both issues by reverting to non-managed allocation of the controller. Fixes: dcfdd698dc52 ("mmc: vub300: Use devm_mmc_alloc_host() helper") Cc: stable@vger.kernel.org # 6.17+ Cc: Binbin Zhou Signed-off-by: Johan Hovold Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit c83a282615d8f7ba28cebddd54600b419d562d82 Author: Johan Hovold Date: Fri Mar 27 11:52:05 2026 +0100 mmc: vub300: fix NULL-deref on disconnect commit dff34ef879c5e73298443956a8b391311ba78d57 upstream. Make sure to deregister the controller before dropping the reference to the driver data on disconnect to avoid NULL-pointer dereferences or use-after-free. Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver") Cc: stable@vger.kernel.org # 3.0+ Signed-off-by: Johan Hovold Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 447f8870b484f6596d7a7130e72bd0a3f1e037bb Author: SeongJae Park Date: Thu Apr 2 06:44:17 2026 -0700 mm/damon/stat: deallocate damon_call() failure leaking damon_ctx commit 4c04c6b47c361612b1d70cec8f7a60b1482d1400 upstream. damon_stat_start() always allocates the module's damon_ctx object (damon_stat_context). Meanwhile, if damon_call() in the function fails, the damon_ctx object is not deallocated. Hence, if the damon_call() is failed, and the user writes Y to “enabled” again, the previously allocated damon_ctx object is leaked. This cannot simply be fixed by deallocating the damon_ctx object when damon_call() fails. That's because damon_call() failure doesn't guarantee the kdamond main function, which accesses the damon_ctx object, is completely finished. In other words, if damon_stat_start() deallocates the damon_ctx object after damon_call() failure, the not-yet-terminated kdamond could access the freed memory (use-after-free). Fix the leak while avoiding the use-after-free by keeping returning damon_stat_start() without deallocating the damon_ctx object after damon_call() failure, but deallocating it when the function is invoked again and the kdamond is completely terminated. If the kdamond is not yet terminated, simply return -EAGAIN, as the kdamond will soon be terminated. The issue was discovered [1] by sashiko. Link: https://lkml.kernel.org/r/20260402134418.74121-1-sj@kernel.org Link: https://lore.kernel.org/20260401012428.86694-1-sj@kernel.org [1] Fixes: 405f61996d9d ("mm/damon/stat: use damon_call() repeat mode instead of damon_callback") Signed-off-by: SeongJae Park Cc: # 6.17.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b9dadf026a9fb681ed32a0646adc10ab485bf3b1 Author: SeongJae Park Date: Thu Mar 26 17:32:22 2026 -0700 mm/damon/sysfs: dealloc repeat_call_control if damon_call() fails commit 0199390a6b92fc21860e1b858abf525c7e73b956 upstream. damon_call() for repeat_call_control of DAMON_SYSFS could fail if somehow the kdamond is stopped before the damon_call(). It could happen, for example, when te damon context was made for monitroing of a virtual address processes, and the process is terminated immediately, before the damon_call() invocation. In the case, the dyanmically allocated repeat_call_control is not deallocated and leaked. Fix the leak by deallocating the repeat_call_control under the damon_call() failure. This issue is discovered by sashiko [1]. Link: https://lkml.kernel.org/r/20260327003224.55752-1-sj@kernel.org Link: https://lore.kernel.org/20260320020630.962-1-sj@kernel.org [1] Fixes: 04a06b139ec0 ("mm/damon/sysfs: use dynamically allocated repeat mode damon_call_control") Signed-off-by: SeongJae Park Cc: [6.17+] Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 49c00ae87230708cc4b39e718fab05013593b8ed Author: Hao Li Date: Mon Mar 30 11:57:49 2026 +0800 mm/memory_hotplug: maintain N_NORMAL_MEMORY during hotplug commit 2ecbe06abf9bfb2261cd6464a6bc3a3615625402 upstream. N_NORMAL_MEMORY is initialized from zone population at boot, but memory hotplug currently only updates N_MEMORY. As a result, a node that gains normal memory via hotplug can remain invisible to users iterating over N_NORMAL_MEMORY, while a node that loses its last normal memory can stay incorrectly marked as such. The most visible effect is that /sys/devices/system/node/has_normal_memory does not report a node even after that node has gained normal memory via hotplug. Also, list_lru-based shrinkers can undercount objects on such a node and may skip reclaim on that node entirely, which can lead to a higher memory footprint than expected. Restore N_NORMAL_MEMORY maintenance directly in online_pages() and offline_pages(). Set the bit when a node that currently lacks normal memory onlines pages into a zone <= ZONE_NORMAL, and clear it when offlining removes the last present pages from zones <= ZONE_NORMAL. This restores the intended semantics without bringing back the old status_change_nid_normal notifier plumbing which was removed in 8d2882a8edb8. Current users that benefit include list_lru, zswap, nfsd filecache, hugetlb_cgroup, and has_normal_memory sysfs reporting. Link: https://lkml.kernel.org/r/20260330035941.518186-1-hao.li@linux.dev Fixes: 8d2882a8edb8 ("mm,memory_hotplug: remove status_change_nid_normal and update documentation") Signed-off-by: Hao Li Reviewed-by: Harry Yoo (Oracle) Acked-by: Vlastimil Babka (SUSE) Reviewed-by: Joshua Hahn Acked-by: David Hildenbrand (Arm) Cc: Oscar Salvador Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 4700471775746058c962ded6e659bf908fd76e13 Author: Alex Dvoretsky Date: Thu Mar 12 14:52:55 2026 +0100 igb: remove napi_synchronize() in igb_down() commit b1e067240379f950a0022208e0685f3465c211cb upstream. When an AF_XDP zero-copy application terminates abruptly (e.g., kill -9), the XSK buffer pool is destroyed but NAPI polling continues. igb_clean_rx_irq_zc() repeatedly returns the full budget, preventing napi_complete_done() from clearing NAPI_STATE_SCHED. igb_down() calls napi_synchronize() before napi_disable() for each queue vector. napi_synchronize() spins waiting for NAPI_STATE_SCHED to clear, which never happens. igb_down() blocks indefinitely, the TX watchdog fires, and the TX queue remains permanently stalled. napi_disable() already handles this correctly: it sets NAPI_STATE_DISABLE. After a full-budget poll, __napi_poll() checks napi_disable_pending(). If set, it forces completion and clears NAPI_STATE_SCHED, breaking the loop that napi_synchronize() cannot. napi_synchronize() was added in commit 41f149a285da ("igb: Fix possible panic caused by Rx traffic arrival while interface is down"). napi_disable() provides stronger guarantees: it prevents further scheduling and waits for any active poll to exit. Other Intel drivers (ixgbe, ice, i40e) use napi_disable() without a preceding napi_synchronize() in their down paths. Remove redundant napi_synchronize() call and reorder napi_disable() before igb_set_queue_napi() so the queue-to-NAPI mapping is only cleared after polling has fully stopped. Fixes: 2c6196013f84 ("igb: Add AF_XDP zero-copy Rx support") Cc: stable@vger.kernel.org Suggested-by: Maciej Fijalkowski Reviewed-by: Aleksandr Loktionov Signed-off-by: Alex Dvoretsky Reviewed-by: Maciej Fijalkowski Tested-by: Patryk Holda Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit e44919669f07b8f113ad49a248b44ca4f119bc94 Author: Jacky Bai Date: Fri Mar 20 16:43:46 2026 +0800 pmdomain: imx8mp-blk-ctrl: Keep the NOC_HDCP clock enabled commit e91d5f94acf68618ea3ad9c92ac28614e791ae7d upstream. Keep the NOC_HDCP clock always enabled to fix the potential hang caused by the NoC ADB400 port power down handshake. Fixes: 77b0ddb42add ("soc: imx: add i.MX8MP HDMI blk ctrl HDCP/HRV_MWR") Signed-off-by: Jacky Bai Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 82e8174d1d0e5a6be49d33aedfa83327097f20b9 Author: Michael Guralnik Date: Fri Apr 3 12:17:56 2026 +0300 net/mlx5: Update the list of the PCI supported devices commit a9d4f4f6e65e0bf9bbddedecc84d67249991979c upstream. Add the upcoming ConnectX-10 NVLink-C2C device ID to the table of supported PCI device IDs. Cc: stable@vger.kernel.org Signed-off-by: Michael Guralnik Reviewed-by: Patrisious Haddad Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260403091756.139583-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit de9aa7e89b98157d2650f25691e40711b8404151 Author: Jouni Högander Date: Fri Mar 27 13:45:53 2026 +0200 drm/i915/psr: Do not use pipe_src as borders for SU area commit 75519f5df2a9b23f7bf305e12dc9a6e3e65c24b7 upstream. This far using crtc_state->pipe_src as borders for Selective Update area haven't caused visible problems as drm_rect_width(crtc_state->pipe_src) == crtc_state->hw.adjusted_mode.crtc_hdisplay and drm_rect_height(crtc_state->pipe_src) == crtc_state->hw.adjusted_mode.crtc_vdisplay when pipe scaling is not used. On the other hand using pipe scaling is forcing full frame updates and all the Selective Update area calculations are skipped. Now this improper usage of crtc_state->pipe_src is causing following warnings: <4> [7771.978166] xe 0000:00:02.0: [drm] drm_WARN_ON_ONCE(su_lines % vdsc_cfg->slice_height) after WARN_ON_ONCE was added by commit: "drm/i915/dsc: Add helper for writing DSC Selective Update ET parameters" These warnings are seen when DSC and pipe scaling are enabled simultaneously. This is because on full frame update SU area is improperly set as pipe_src which is not aligned with DSC slice height. Fix these by creating local rectangle using crtc_state->hw.adjusted_mode.crtc_hdisplay and crtc_state->hw.adjusted_mode.crtc_vdisplay. Use this local rectangle as borders for SU area. Fixes: d6774b8c3c58 ("drm/i915: Ensure damage clip area is within pipe area") Cc: # v6.0+ Signed-off-by: Jouni Högander Reviewed-by: Mika Kahola Link: https://patch.msgid.link/20260327114553.195285-1-jouni.hogander@intel.com (cherry picked from commit da0cdc1c329dd2ff09c41fbbe9fbd9c92c5d2c6e) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 2af8b200cae3fdd0e917ecc2753b28bb40c876c1 Author: Sebastian Brzezinka Date: Wed Apr 1 12:10:07 2026 +0200 drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeat commit 4c71fd099513bfa8acab529b626e1f0097b76061 upstream. A use-after-free / refcount underflow is possible when the heartbeat worker and intel_engine_park_heartbeat() race to release the same engine->heartbeat.systole request. The heartbeat worker reads engine->heartbeat.systole and calls i915_request_put() on it when the request is complete, but clears the pointer in a separate, non-atomic step. Concurrently, a request retirement on another CPU can drop the engine wakeref to zero, triggering __engine_park() -> intel_engine_park_heartbeat(). If the heartbeat timer is pending at that point, cancel_delayed_work() returns true and intel_engine_park_heartbeat() reads the stale non-NULL systole pointer and calls i915_request_put() on it again, causing a refcount underflow: ``` <4> [487.221889] Workqueue: i915-unordered engine_retire [i915] <4> [487.222640] RIP: 0010:refcount_warn_saturate+0x68/0xb0 ... <4> [487.222707] Call Trace: <4> [487.222711] <4> [487.222716] intel_engine_park_heartbeat.part.0+0x6f/0x80 [i915] <4> [487.223115] intel_engine_park_heartbeat+0x25/0x40 [i915] <4> [487.223566] __engine_park+0xb9/0x650 [i915] <4> [487.223973] ____intel_wakeref_put_last+0x2e/0xb0 [i915] <4> [487.224408] __intel_wakeref_put_last+0x72/0x90 [i915] <4> [487.224797] intel_context_exit_engine+0x7c/0x80 [i915] <4> [487.225238] intel_context_exit+0xf1/0x1b0 [i915] <4> [487.225695] i915_request_retire.part.0+0x1b9/0x530 [i915] <4> [487.226178] i915_request_retire+0x1c/0x40 [i915] <4> [487.226625] engine_retire+0x122/0x180 [i915] <4> [487.227037] process_one_work+0x239/0x760 <4> [487.227060] worker_thread+0x200/0x3f0 <4> [487.227068] ? __pfx_worker_thread+0x10/0x10 <4> [487.227075] kthread+0x10d/0x150 <4> [487.227083] ? __pfx_kthread+0x10/0x10 <4> [487.227092] ret_from_fork+0x3d4/0x480 <4> [487.227099] ? __pfx_kthread+0x10/0x10 <4> [487.227107] ret_from_fork_asm+0x1a/0x30 <4> [487.227141] ``` Fix this by replacing the non-atomic pointer read + separate clear with xchg() in both racing paths. xchg() is a single indivisible hardware instruction that atomically reads the old pointer and writes NULL. This guarantees only one of the two concurrent callers obtains the non-NULL pointer and performs the put, the other gets NULL and skips it. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15880 Fixes: 058179e72e09 ("drm/i915/gt: Replace hangcheck by heartbeats") Cc: # v5.5+ Signed-off-by: Sebastian Brzezinka Reviewed-by: Krzysztof Karas Reviewed-by: Andi Shyti Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/d4c1c14255688dd07cc8044973c4f032a8d1559e.1775038106.git.sebastian.brzezinka@intel.com (cherry picked from commit 13238dc0ee4f9ab8dafa2cca7295736191ae2f42) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 4dee4c0688443aaf5bbec74aa203c851d1d53c35 Author: Haoze Xie Date: Mon Apr 6 21:17:28 2026 +0800 batman-adv: hold claim backbone gateways by reference commit 82d8701b2c930d0e96b0dbc9115a218d791cb0d2 upstream. batadv_bla_add_claim() can replace claim->backbone_gw and drop the old gateway's last reference while readers still follow the pointer. The netlink claim dump path dereferences claim->backbone_gw->orig and takes claim->backbone_gw->crc_lock without pinning the underlying backbone gateway. batadv_bla_check_claim() still has the same naked pointer access pattern. Reuse batadv_bla_claim_get_backbone_gw() in both readers so they operate on a stable gateway reference until the read-side work is complete. This keeps the dump and claim-check paths aligned with the lifetime rules introduced for the other BLA claim readers. Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code") Fixes: 04f3f5bf1883 ("batman-adv: add B.A.T.M.A.N. Dump BLA claims via netlink") Cc: stable@vger.kernel.org Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Signed-off-by: Haoze Xie Signed-off-by: Ao Zhou Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Greg Kroah-Hartman commit 60f462cd2716d86bd2174f9d5e035c9278f30480 Author: David Carlier Date: Wed Apr 1 22:12:18 2026 +0100 net: altera-tse: fix skb leak on DMA mapping error in tse_start_xmit() commit 6dede3967619b5944003227a5d09fdc21ed57d10 upstream. When dma_map_single() fails in tse_start_xmit(), the function returns NETDEV_TX_OK without freeing the skb. Since NETDEV_TX_OK tells the stack the packet was consumed, the skb is never freed, leaking memory on every DMA mapping failure. Add dev_kfree_skb_any() before returning to properly free the skb. Fixes: bbd2190ce96d ("Altera TSE: Add main and header file for Altera Ethernet Driver") Cc: stable@vger.kernel.org Signed-off-by: David Carlier Link: https://patch.msgid.link/20260401211218.279185-1-devnexen@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5d70eb25b41e9b010828cd12818b06a0c3b04412 Author: Muhammad Alifa Ramdhan Date: Fri Apr 3 09:36:17 2026 +0800 net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption commit a9b8b18364fffce4c451e6f6fd218fa4ab646705 upstream. The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 ("net: tls: handle backlogging of crypto requests"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration. Fixes: 859054147318 ("net: tls: handle backlogging of crypto requests") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Alifa Ramdhan Reviewed-by: Sabrina Dubroca Link: https://patch.msgid.link/20260403013617.2838875-1-ramdhan@starlabs.sg Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 87ce8ae511962e105bcb3534944208c6a9471ed9 Author: Borislav Petkov (AMD) Date: Tue Mar 31 14:16:23 2026 +0200 EDAC/mc: Fix error path ordering in edac_mc_alloc() commit 51520e03e70d6c73e33ee7cbe0319767d05764fe upstream. When the mci->pvt_info allocation in edac_mc_alloc() fails, the error path will call put_device() which will end up calling the device's release function. However, the init ordering is wrong such that device_initialize() happens *after* the failed allocation and thus the device itself and the release function pointer are not initialized yet when they're called: MCE: In-kernel MCE decoding enabled. ------------[ cut here ]------------ kobject: '(null)': is not initialized, yet kobject_put() is being called. WARNING: lib/kobject.c:734 at kobject_put, CPU#22: systemd-udevd CPU: 22 UID: 0 PID: 538 Comm: systemd-udevd Not tainted 7.0.0-rc1+ #2 PREEMPT(full) RIP: 0010:kobject_put Call Trace: edac_mc_alloc+0xbe/0xe0 [edac_core] amd64_edac_init+0x7a4/0xff0 [amd64_edac] ? __pfx_amd64_edac_init+0x10/0x10 [amd64_edac] do_one_initcall ... Reorder the calling sequence so that the device is initialized and thus the release function pointer is properly set before it can be used. This was found by Claude while reviewing another EDAC patch. Fixes: 0bbb265f7089 ("EDAC/mc: Get rid of silly one-shot struct allocation in edac_mc_alloc()") Reported-by: Claude Code:claude-opus-4.5 Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Qiuxu Zhuo Cc: stable@kernel.org Link: https://patch.msgid.link/20260331121623.4871-1-bp@kernel.org Signed-off-by: Greg Kroah-Hartman commit 206121294b9cf27f0589857f80d64f87e496ffb2 Author: Lukas Wunner Date: Tue Apr 7 12:58:18 2026 +0200 X.509: Fix out-of-bounds access when parsing extensions commit d702c3408213bb12bd570bb97204d8340d141c51 upstream. Leo reports an out-of-bounds access when parsing a certificate with empty Basic Constraints or Key Usage extension because the first byte of the extension is read before checking its length. Fix it. The bug can be triggered by an unprivileged user by submitting a specially crafted certificate to the kernel through the keyrings(7) API. Leo has demonstrated this with a proof-of-concept program responsibly disclosed off-list. Fixes: 30eae2b037af ("KEYS: X.509: Parse Basic Constraints for CA") Fixes: 567671281a75 ("KEYS: X.509: Parse Key Usage") Reported-by: Leo Lin # off-list Signed-off-by: Lukas Wunner Reviewed-by: Ignat Korchagin Cc: stable@vger.kernel.org # v6.4+ Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit de6c1dc3c7d01a152607e6fcecee4d5288283f10 Author: Ruide Cao Date: Thu Apr 2 23:12:31 2026 +0800 batman-adv: reject oversized global TT response buffers commit 3a359bf5c61d52e7f09754108309d637532164a6 upstream. batadv_tt_prepare_tvlv_global_data() builds the allocation length for a global TT response in 16-bit temporaries. When a remote originator advertises a large enough global TT, the TT payload length plus the VLAN header offset can exceed 65535 and wrap before kmalloc(). The full-table response path still uses the original TT payload length when it fills tt_change, so the wrapped allocation is too small and batadv_tt_prepare_tvlv_global_data() writes past the end of the heap object before the later packet-size check runs. Fix this by rejecting TT responses whose TVLV value length cannot fit in the 16-bit TVLV payload length field. Fixes: 7ea7b4a14275 ("batman-adv: make the TT CRC logic VLAN specific") Cc: stable@vger.kernel.org Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Tested-by: Ren Wei Signed-off-by: Ruide Cao Signed-off-by: Ren Wei Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Greg Kroah-Hartman commit 21ae2cda66a55c759607bbf1d23cbaa42019d2de Author: Pengpeng Hou Date: Sun Apr 5 08:40:00 2026 +0800 nfc: pn533: allocate rx skb before consuming bytes commit c71ba669b570c7b3f86ec875be222ea11dacb352 upstream. pn532_receive_buf() reports the number of accepted bytes to the serdev core. The current code consumes bytes into recv_skb and may already hand a complete frame to pn533_recv_frame() before allocating a fresh receive buffer. If that alloc_skb() fails, the callback returns 0 even though it has already consumed bytes, and it leaves recv_skb as NULL for the next receive callback. That breaks the receive_buf() accounting contract and can also lead to a NULL dereference on the next skb_put_u8(). Allocate the receive skb lazily before consuming the next byte instead. If allocation fails, return the number of bytes already accepted. Fixes: c656aa4c27b1 ("nfc: pn533: add UART phy driver") Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260405094003.3-pn533-v2-pengpeng@iscas.ac.cn Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 083c5a417dee0a60e793809e5be2387a0cfdbaf6 Author: Shawn Guo Date: Fri Feb 27 15:22:10 2026 +0800 arm64: dts: hisilicon: hi3798cv200: Add missing dma-ranges commit 1af997cad473d505248df6d9577183bb91f69670 upstream. Reboot starts failing on Poplar since commit 8424ecdde7df ("arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges"), which effectively changes zone_dma_bits from 30 to 32 for arm64 platforms that do not properly define dma-ranges in device tree. It's unclear how Poplar reboot gets broken by this change exactly, but a dma-ranges limiting zone_dma to the first 1 GB fixes the regression. Fixes: 2f20182ed670 ("arm64: dts: hisilicon: add dts files for hi3798cv200-poplar board") Cc: stable@vger.kernel.org Signed-off-by: Shawn Guo Signed-off-by: Wei Xu Signed-off-by: Greg Kroah-Hartman commit f0a0a6a8c1cc20353d018a6220701074f0dea24e Author: Shawn Guo Date: Fri Feb 27 15:19:58 2026 +0800 arm64: dts: hisilicon: poplar: Correct PCIe reset GPIO polarity commit c1f2b0f2b5e37b2c27540a175aea2755a3799433 upstream. The PCIe reset GPIO on Poplar is actually active low. The active high worked before because kernel driver didn't respect the setting from DT. This is changed since commit 1d26a55fbeb9 ("PCI: histb: Switch to using gpiod API"), and thus PCIe on Poplar got brken since then. Fix the problem by correcting the polarity. Fixes: 32fa01761bd9 ("arm64: dts: hi3798cv200: enable PCIe support for poplar board") Cc: stable@vger.kernel.org Signed-off-by: Shawn Guo Signed-off-by: Wei Xu Signed-off-by: Greg Kroah-Hartman commit c82a3c9d9fb30ef0956391a605235c0e27120b66 Author: Marek Vasut Date: Tue Mar 24 15:33:28 2026 +0100 arm64: dts: renesas: sparrow-hawk: Reserve first 128 MiB of DRAM commit ed8444006df9863ffa682e315352c44a49d9f4cb upstream. Mark the first 128 MiB of DRAM as reserved. The first 128 MiB of DRAM may optionally be used by TFA and other firmware for its own purposes, and in such case, Linux must not use this memory. On this platform, U-Boot runs in EL3 and starts TFA BL31 and Linux from a single combined fitImage. U-Boot has full access to all memory in the 0x40000000..0xbfffffff range, as well memory in the memory banks in the 64-bit address ranges, and therefore U-Boot patches this full complete view of platform memory layout into the DT that is passed to the next stage. The next stage is TFA BL31 and then the Linux kernel. The TFA BL31 does not modify the DT passed from U-Boot to TFA BL31 and then to Linux with any new reserved-memory {} node to reserve memory areas used by the TFA BL31 to prevent the next stage from using those areas, which lets Linux to use all of the available DRAM as described in the DT that was passed in by U-Boot, including the areas that are newly utilized by TFA BL31. In case of high DRAM utilization, for example in case of four instances of "memtester 3900M" running in parallel, unless the memory used by TFA BL31 is properly reserved, Linux may use and corrupt the memory used by TFA BL31, which would often lead to system becoming unresponsive. Until TFA BL31 can properly fill its own reserved-memory node into the DT, and to assure older versions of TFA BL31 do not cause problems, add explicitly reserved-memory {} node which prevents Linux from using the first 128 MiB of DRAM. Note that TFA BL31 can be adjusted to use different memory areas, this newly added reserved-memory {} node follows longer-term practice on the R-Car SoCs where the first 128 MiB of DRAM is reserved for firmware use. In case user does modify TFA BL31 to use different memory ranges, they must either use a future version of TFA BL31 which properly patches a reserved-memory {} node into the DT, or they must adjust the address ranges of this reserved-memory {} node accordingly. Fixes: a719915e76f2 ("arm64: dts: renesas: r8a779g3: Add Retronix R-Car V4H Sparrow Hawk board support") Cc: stable@vger.kernel.org Signed-off-by: Marek Vasut Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260324143342.17872-1-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman commit a4115c2abab3677d5ed81ea7738ead89fb6ccd9f Author: Sebastian Krzyszkowiak Date: Sat Feb 21 19:15:19 2026 +0100 arm64: dts: imx8mq-librem5: Bump BUCK1 suspend voltage up to 0.85V commit 511f76bf1dce5acf8907b65a7d1bc8f7e7c0d637 upstream. The minimal voltage of VDD_SOC sourced from BUCK1 is 0.81V, which is the currently set value. However, BD71837 only guarantees accuracy of ±0.01V, and this still doesn't factor other reasons for actual voltage to slightly drop in, resulting in the possibility of running out of the operational range. Bump the voltage up to 0.85V, which should give enough headroom. Cc: stable@vger.kernel.org Fixes: 8f0216b006e5 ("arm64: dts: Add a device tree for the Librem 5 phone") Signed-off-by: Sebastian Krzyszkowiak Signed-off-by: Frank Li Signed-off-by: Greg Kroah-Hartman commit 3b31b15230b01f77d52760add62c4c6b7f7a8504 Author: Sebastian Krzyszkowiak Date: Sat Feb 21 19:15:18 2026 +0100 Revert "arm64: dts: imx8mq-librem5: Set the DVS voltages lower" commit 4cd46ea0eb4504f7f4fea92cb4601c5c9a3e545e upstream. This reverts commit c24a9b698fb02cd0723fa8375abab07f94b97b10. It's been found that there's a significant per-unit variance in accepted supply voltages and the current set still makes some units unstable. Revert back to nominal values. Cc: stable@vger.kernel.org Fixes: c24a9b698fb0 ("arm64: dts: imx8mq-librem5: Set the DVS voltages lower") Signed-off-by: Sebastian Krzyszkowiak Signed-off-by: Frank Li Signed-off-by: Greg Kroah-Hartman commit aee881c21b576159c7a814f39604308895affcaa Author: Heiko Stuebner Date: Tue Feb 10 13:01:42 2026 +0100 Revert "arm64: dts: rockchip: Further describe the WiFi for the Pinebook Pro" commit 29d1f56c4f3001b7f547123e0a307c009ac717f8 upstream. This reverts commit 6d54d935062e2d4a7d3f779ceb9eeff108d0535d. It seems there are different variants of the Wifi chipset in use on the Pinebook Pro. And according to the reported regression - see Closes below, the reverted change causes issues with one Wifi chipset. The original commit message indicates a "further description" only and does not indicate this would fix an actual problem, so a revert should not cause further problems. Fixes: 6d54d935062e ("arm64: dts: rockchip: Further describe the WiFi for the Pinebook Pro") Cc: Jan Palus Cc: Peter Robinson Cc: Thorsten Leemhuis Cc: stable@vger.kernel.org Closes: https://lore.kernel.org/r/aUKOlj-RvTYlrpiS@rock.grzadka/ Tested-by: Jan Palus Reviewed-by: Dragan Simic Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260210120142.698512-1-heiko@sntech.de Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman commit fecceacbaf48219519c50d692d05de00e4689b7b Author: Srinivas Pandruvada Date: Wed Mar 25 12:29:09 2026 -0700 platform/x86/intel-uncore-freq: Handle autonomous UFS status bit commit 4ab604b3f3aa8dcccc7505f5d310016682a99d5f upstream. When the AUTONOMOUS_UFS_DISABLED bit is set in the header, the ELC (Efficiency Latency Control) feature is non-functional. Hence, return error for read or write to ELC attributes. Fixes: bb516dc79c4a ("platform/x86/intel-uncore-freq: Add support for efficiency latency control") Signed-off-by: Srinivas Pandruvada Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260325192909.3417322-1-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit c4e1eff4606c7bf8c3289051f63f08ca65653ae2 Author: Srinivas Pandruvada Date: Wed Mar 25 12:26:38 2026 -0700 platform/x86: ISST: Reset core count to 0 commit e1415b9418eb22b4a7a1ef4b4aec9dd0a49e3fa7 upstream. Based on feature revision, number of buckets can be less than the TRL_MAX_BUCKETS. In that case core counts in the remaining buckets can be set to some invalid values. Hence reset core count to 0 for all buckets before assigning correct values. Fixes: 885d1c2a30b7 ("platform/x86: ISST: Support SST-TF revision 2") Signed-off-by: Srinivas Pandruvada Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260325192638.3417281-1-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit b27fa888e4a426a3bcf6f6ab24701d888d9bf5aa Author: Thomas Fourier Date: Wed Feb 18 14:07:37 2026 +0100 wifi: brcmsmac: Fix dma_free_coherent() size commit 12cd7632757a54ce586e36040210b1a738a0fc53 upstream. dma_alloc_consistent() may change the size to align it. The new size is saved in alloced. Change the free size to match the allocation size. Fixes: 5b435de0d786 ("net: wireless: add brcm80211 drivers") Cc: Signed-off-by: Thomas Fourier Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260218130741.46566-3-fourier.thomas@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 1b6f13f626665cac67ba5a012765427680518711 Author: Oleh Konko Date: Thu Apr 2 09:48:57 2026 +0000 tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG commit 48a5fe38772b6f039522469ee6131a67838221a8 upstream. The GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements bc_ackers on every inbound group ACK, even when the same member has already acknowledged the current broadcast round. Because bc_ackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to 65535. Once wrapped, tipc_group_bc_cong() keeps reporting congestion and later group broadcasts on the affected socket stay blocked until the group is recreated. Fix this by ignoring duplicate or stale ACKs before touching bc_acked or bc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and prevents the underflow path. Fixes: 2f487712b893 ("tipc: guarantee that group broadcast doesn't bypass group unicast") Cc: stable@vger.kernel.org Signed-off-by: Oleh Konko Reviewed-by: Tung Nguyen Reviewed-by: Simon Horman Link: https://patch.msgid.link/41a4833f368641218e444fdcff822039.security@1seal.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0f451b43c88bf2b9c038b414be580efee42e031b Author: Qi Tang Date: Thu Apr 2 19:44:01 2026 +0800 xfrm: hold dev ref until after transport_finish NF_HOOK commit 1c428b03840094410c5fb6a5db30640486bbbfcb upstream. After async crypto completes, xfrm_input_resume() calls dev_put() immediately on re-entry before the skb reaches transport_finish. The skb->dev pointer is then used inside NF_HOOK and its okfn, which can race with device teardown. Remove the dev_put from the async resumption entry and instead drop the reference after the NF_HOOK call in transport_finish, using a saved device pointer since NF_HOOK may consume the skb. This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip the okfn. For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set. Suggested-by: Florian Westphal Fixes: acf568ee859f ("xfrm: Reinject transport-mode packets through tasklet") Cc: stable@vger.kernel.org Signed-off-by: Qi Tang Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit b1dfd6b27df35ef4f87825aa5f607378d23ff0f2 Author: Yasuaki Torimaru Date: Thu Mar 26 14:58:00 2026 +0900 xfrm: clear trailing padding in build_polexpire() commit 71a98248c63c535eaa4d4c22f099b68d902006d0 upstream. build_expire() clears the trailing padding bytes of struct xfrm_user_expire after setting the hard field via memset_after(), but the analogous function build_polexpire() does not do this for struct xfrm_user_polexpire. The padding bytes after the __u8 hard field are left uninitialized from the heap allocation, and are then sent to userspace via netlink multicast to XFRMNLGRP_EXPIRE listeners, leaking kernel heap memory contents. Add the missing memset_after() call, matching build_expire(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Yasuaki Torimaru Reviewed-by: Simon Horman Reviewed-by: Breno Leitao Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 688c1b491c35d43fac013d5aa5490ae4c04a76a3 Author: Nathan Chancellor Date: Wed Mar 25 18:20:30 2026 -0700 modpost: Declare extra_warn with unused attribute commit deb4605671cfae3b2803cfbbf4739e7245248398 upstream. A recent strengthening of -Wunused-but-set-variable (enabled with -Wall) in clang under a new subwarning, -Wunused-but-set-global, points out an unused static global variable in scripts/mod/modpost.c: scripts/mod/modpost.c:59:13: error: variable 'extra_warn' set but not used [-Werror,-Wunused-but-set-global] 59 | static bool extra_warn; | ^ This variable has been unused since commit 6c6c1fc09de3 ("modpost: require a MODULE_DESCRIPTION()") but that is expected, as there are currently no extra warnings at W=1 right now. Declare the variable with the unused attribute to make it clear to the compiler that this variable may be unused. Cc: stable@vger.kernel.org Fixes: 6c6c1fc09de3 ("modpost: require a MODULE_DESCRIPTION()") Link: https://patch.msgid.link/20260325-modpost-extra_warn-unused-but-set-global-v1-1-2e84003b7e81@kernel.org Reviewed-by: Nicolas Schier Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit 0133aa1a28af222d124f7c289ac9abdcea5220ac Author: Matthew Brost Date: Tue Mar 31 18:07:39 2026 -0700 workqueue: Add pool_workqueue to pending_pwqs list when unplugging multiple inactive works commit 703ccb63ae9f7444d6ff876d024e17f628103c69 upstream. In unplug_oldest_pwq(), the first inactive work item on the pool_workqueue is activated correctly. However, if multiple inactive works exist on the same pool_workqueue, subsequent works fail to activate because wq_node_nr_active.pending_pwqs is empty — the list insertion is skipped when the pool_workqueue is plugged. Fix this by checking for additional inactive works in unplug_oldest_pwq() and updating wq_node_nr_active.pending_pwqs accordingly. Fixes: 4c065dbce1e8 ("workqueue: Enable unbound cpumask update on ordered workqueues") Cc: stable@vger.kernel.org Cc: Carlos Santa Cc: Ryan Neph Cc: Lai Jiangshan Cc: Waiman Long Cc: linux-kernel@vger.kernel.org Signed-off-by: Matthew Brost Signed-off-by: Tejun Heo Acked-by: Waiman Long Signed-off-by: Greg Kroah-Hartman commit fbdb43f6bb2a15ed382d6eb0ef82c8b07b0d47bb Author: Michal Wilczynski Date: Thu Apr 3 15:10:51 2025 +0200 firmware: thead: Fix buffer overflow and use standard endian macros commit 88c4bd90725557796c15878b7cb70066e9e6b5ab upstream. Addresses two issues in the TH1520 AON firmware protocol driver: 1. Fix a potential buffer overflow where the code used unsafe pointer arithmetic to access the 'mode' field through the 'resource' pointer with an offset. This was flagged by Smatch static checker as: "buffer overflow 'data' 2 <= 3" 2. Replace custom RPC_SET_BE* and RPC_GET_BE* macros with standard kernel endianness conversion macros (cpu_to_be16, etc.) for better portability and maintainability. The functionality was re-tested with the GPU power-up sequence, confirming the GPU powers up correctly and the driver probes successfully. [ 12.702370] powervr ffef400000.gpu: [drm] loaded firmware powervr/rogue_36.52.104.182_v1.fw [ 12.711043] powervr ffef400000.gpu: [drm] FW version v1.0 (build 6645434 OS) [ 12.719787] [drm] Initialized powervr 1.0.0 for ffef400000.gpu on minor 0 Fixes: e4b3cbd840e5 ("firmware: thead: Add AON firmware protocol driver") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/all/17a0ccce-060b-4b9d-a3c4-8d5d5823b1c9@stanley.mountain/ Signed-off-by: Michal Wilczynski Reviewed-by: Dan Carpenter Acked-by: Drew Fustini Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit b42aca3660dc2627a29a38131597ca610dc451f9 Author: Tuan Do Date: Fri Apr 3 00:33:17 2026 -0700 netfilter: nft_ct: fix use-after-free in timeout object destroy commit f8dca15a1b190787bbd03285304b569631160eda upstream. nft_ct_timeout_obj_destroy() frees the timeout object with kfree() immediately after nf_ct_untimeout(), without waiting for an RCU grace period. Concurrent packet processing on other CPUs may still hold RCU-protected references to the timeout object obtained via rcu_dereference() in nf_ct_timeout_data(). Add an rcu_head to struct nf_ct_timeout and use kfree_rcu() to defer freeing until after an RCU grace period, matching the approach already used in nfnetlink_cttimeout.c. KASAN report: BUG: KASAN: slab-use-after-free in nf_conntrack_tcp_packet+0x1381/0x29d0 Read of size 4 at addr ffff8881035fe19c by task exploit/80 Call Trace: nf_conntrack_tcp_packet+0x1381/0x29d0 nf_conntrack_in+0x612/0x8b0 nf_hook_slow+0x70/0x100 __ip_local_out+0x1b2/0x210 tcp_sendmsg_locked+0x722/0x1580 __sys_sendto+0x2d8/0x320 Allocated by task 75: nft_ct_timeout_obj_init+0xf6/0x290 nft_obj_init+0x107/0x1b0 nf_tables_newobj+0x680/0x9c0 nfnetlink_rcv_batch+0xc29/0xe00 Freed by task 26: nft_obj_destroy+0x3f/0xa0 nf_tables_trans_destroy_work+0x51c/0x5c0 process_one_work+0x2c4/0x5a0 Fixes: 7e0b2b57f01d ("netfilter: nft_ct: add ct timeout support") Cc: stable@vger.kernel.org Signed-off-by: Tuan Do Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit 2802ba3981f15ed8e89fe86544aad2f43acd17b7 Author: Anthony Pighin Date: Tue Mar 31 14:26:32 2026 -0400 i2c: imx: zero-initialize dma_slave_config for eDMA commit 39ed7d89b973329cc5c764b65ba6302b17b1907e upstream. commit 66d88e16f204 ("dmaengine: fsl-edma: read/write multiple registers in cyclic transactions") causes fsl_edma_fill_tcd() to read dst_port_window_size and src_port_window_size when building transfer control descriptors. Initialize the structure so unset fields are explicitly zero. Fixes: 66d88e16f204 ("dmaengine: fsl-edma: read/write multiple registers in cyclic transactions") Signed-off-by: Anthony Pighin Cc: # v6.14+ Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260331182632.888110-1-anthony.pighin@nokia.com Signed-off-by: Greg Kroah-Hartman commit 72cf49ad50c16270b52bc512d9c2df5743922968 Author: Kuniyuki Iwashima Date: Wed Mar 11 05:40:40 2026 +0000 af_unix: Give up GC if MSG_PEEK intervened. [ Upstream commit e5b31d988a41549037b8d8721a3c3cae893d8670 ] Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro. This is the exact same issue previously fixed by commit cbcf01128d0a ("af_unix: fix garbage collect vs MSG_PEEK"). After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue. The problem is that MSG_PEEK bumps a file refcount without interacting with GC. Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B. The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B. GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2 close(sk-B) -> sk-B's file refcount : 2 -> 1 unix_vertex_dead(sk-B) -> true Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds. However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation. At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former. Finally, GC incorrectly concludes that both sk-A and sk-B are dead. One option is to restore the locking dance in unix_peek_fds(), but we can resolve this more elegantly thanks to the new algorithm. The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK with the dead SCC detection. When the issue occurs, close() and GC touch the same file refcount. If GC sees the refcount being decremented by close(), it can just give up garbage-collecting the SCC. Therefore, we only need to signal the race during MSG_PEEK with a proper memory barrier to make it visible to the GC. Let's use seqcount_t to notify GC when MSG_PEEK occurs and let it defer the SCC to the next run. This way no locking is needed on the MSG_PEEK side, and we can avoid imposing a penalty on every MSG_PEEK unnecessarily. Note that we can retry within unix_scc_dead() if MSG_PEEK is detected, but we do not do so to avoid hung task splat from abusive MSG_PEEK calls. Fixes: 118f457da9ed ("af_unix: Remove lock dance in unix_peek_fds().") Reported-by: Igor Ushakov Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260311054043.1231316-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 33120558237c7e13db3c39f09fd712431e455005 Author: Kuniyuki Iwashima Date: Sat Nov 15 02:08:33 2025 +0000 af_unix: Simplify GC state. [ Upstream commit 6b6f3c71fe568aa8ed3e16e9135d88a5f4fd3e84 ] GC manages its state by two variables, unix_graph_maybe_cyclic and unix_graph_grouped, both of which are set to false in the initial state. When an AF_UNIX socket is passed to an in-flight AF_UNIX socket, unix_update_graph() sets unix_graph_maybe_cyclic to true and unix_graph_grouped to false, making the next GC invocation call unix_walk_scc() to group SCCs. Once unix_walk_scc() finishes, sockets in the same SCC are linked via vertex->scc_entry. Then, unix_graph_grouped is set to true so that the following GC invocations can skip Tarjan's algorithm and simply iterate through the list in unix_walk_scc_fast(). In addition, if we know there is at least one cyclic reference, we set unix_graph_maybe_cyclic to true so that we do not skip GC. So the state transitions as follows: (unix_graph_maybe_cyclic, unix_graph_grouped) = (false, false) -> (true, false) -> (true, true) or (false, true) ^.______________/________________/ There is no transition to the initial state where both variables are false. If we consider the initial state as grouped, we can see that the GC actually has a tristate. Let's consolidate two variables into one enum. Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20251115020935.2643121-3-kuniyu@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: e5b31d988a41 ("af_unix: Give up GC if MSG_PEEK intervened.") Signed-off-by: Sasha Levin commit 1e211179f1d9273b6cfd0b30d6983dc1d626736b Author: Kuniyuki Iwashima Date: Sat Nov 15 02:08:32 2025 +0000 af_unix: Count cyclic SCC. [ Upstream commit 58b47c713711b8afbf68e3158d4d5acdead00e9b ] __unix_walk_scc() and unix_walk_scc_fast() call unix_scc_cyclic() for each SCC to check if it forms a cyclic reference, so that we can skip GC at the following invocations in case all SCCs do not have any cycles. If we count the number of cyclic SCCs in __unix_walk_scc(), we can simplify unix_walk_scc_fast() because the number of cyclic SCCs only changes when it garbage-collects a SCC. So, let's count cyclic SCC in __unix_walk_scc() and decrement it in unix_walk_scc_fast() when performing garbage collection. Note that we will use this counter in a later patch to check if a cycle existed in the previous GC run. Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20251115020935.2643121-2-kuniyu@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: e5b31d988a41 ("af_unix: Give up GC if MSG_PEEK intervened.") Signed-off-by: Sasha Levin commit 450e6a685d0cad95b15f8af152057bd0bf79f50b Author: robbieko Date: Wed Mar 25 18:18:15 2026 +0800 btrfs: fix incorrect return value after changing leaf in lookup_extent_data_ref() [ Upstream commit 316fb1b3169efb081d2db910cbbfef445afa03b9 ] After commit 1618aa3c2e01 ("btrfs: simplify return variables in lookup_extent_data_ref()"), the err and ret variables were merged into a single ret variable. However, when btrfs_next_leaf() returns 0 (success), ret is overwritten from -ENOENT to 0. If the first key in the next leaf does not match (different objectid or type), the function returns 0 instead of -ENOENT, making the caller believe the lookup succeeded when it did not. This can lead to operations on the wrong extent tree item, potentially causing extent tree corruption. Fix this by returning -ENOENT directly when the key does not match, instead of relying on the ret variable. Fixes: 1618aa3c2e01 ("btrfs: simplify return variables in lookup_extent_data_ref()") CC: stable@vger.kernel.org # 6.12+ Reviewed-by: Filipe Manana Signed-off-by: robbieko Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 2124a61e6e2b0359ad27d782e23abb699b2f26e0 Author: Filipe Manana Date: Tue Jan 20 19:52:10 2026 +0000 btrfs: remove pointless out labels from extent-tree.c [ Upstream commit ea8f9210050136bdd14f5e32b04cd01c8bd5c0ca ] Some functions (lookup_extent_data_ref(), __btrfs_mod_ref() and btrfs_free_tree_block()) have an 'out' label that does nothing but return, making it pointless. Simplify this by removing the label and returning instead of gotos plus setting the 'ret' variable. Reviewed-by: Johannes Thumshirn Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Stable-dep-of: 316fb1b3169e ("btrfs: fix incorrect return value after changing leaf in lookup_extent_data_ref()") Signed-off-by: Sasha Levin commit d8b281165a86041bb40e055eb79f735826d0df1b Author: Maciej W. Rozycki Date: Fri Apr 10 01:50:00 2026 +0100 MIPS: mm: Rewrite TLB uniquification for the hidden bit feature commit 540760b77b8fc49d39d1b2b76196e5ec57711a32 upstream. Before the introduction of the EHINV feature, which lets software mark TLB entries invalid, certain older implementations of the MIPS ISA were equipped with an analogous bit, as a vendor extension, which however is hidden from software and only ever set at reset, and then any software write clears it, making the intended TLB entry valid. This feature makes it unsafe to read a TLB entry with TLBR, modify the page mask, and write the entry back with TLBWI, because this operation will implicitly clear the hidden bit and this may create a duplicate entry, as with the presence of the hidden bit there is no guarantee all the entries across the TLB are unique each. Usually the firmware has already uniquified TLB entries before handing control over, in which case we only need to guarantee at bootstrap no clash will happen with the VPN2 values chosen in local_flush_tlb_all(). However with systems such as Mikrotik RB532 we get handed the TLB as at reset, with the hidden bit set across the entries and possibly duplicate entries present. This then causes a machine check exception when page sizes are reset in r4k_tlb_uniquify() and prevents the system from booting. Rewrite the algorithm used in r4k_tlb_uniquify() then such as to avoid the reuse of ASID/VPN values across the TLB. Get rid of global entries first as they may be blocking the entire address space, e.g. 16 256MiB pages will exhaust the whole address space of a 32-bit CPU and a single big page can exhaust the 32-bit compatibility space on a 64-bit CPU. Details of the algorithm chosen are given across the code itself. Fixes: 9f048fa48740 ("MIPS: mm: Prevent a TLB shutdown on initial uniquification") Signed-off-by: Maciej W. Rozycki Cc: stable@vger.kernel.org # v6.18+ Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit ccc6a2241a49f68d8656ab1e10df377acfe2c5b4 Author: Maciej W. Rozycki Date: Fri Apr 10 01:49:59 2026 +0100 MIPS: mm: Suppress TLB uniquification on EHINV hardware commit 74283cfe216392c7b776ebf6045b5b15ed9dffcd upstream. Hardware that supports the EHINV feature, mandatory for R6 ISA and FTLB implementation, lets software mark TLB entries invalid, which eliminates the need to ensure no duplicate matching entries are ever created. This feature is already used by local_flush_tlb_all(), via the UNIQUE_ENTRYHI macro, making the preceding call to r4k_tlb_uniquify() superfluous. The next change will also modify uniquification code such that it'll become incompatible with the FTLB and MMID features, as well as MIPSr6 CPUs that do not implement 4KiB pages. Therefore prevent r4k_tlb_uniquify() from being used on EHINV hardware, as denoted by `cpu_has_tlbinv'. Signed-off-by: Maciej W. Rozycki Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 6c600fc0e99180c7a1b91c93e359009be8b4cfc2 Author: Maciej W. Rozycki Date: Fri Apr 10 01:49:58 2026 +0100 MIPS: Always record SEGBITS in cpu_data.vmbits commit 8374c2cb83b95b3c92f129fd56527225c20a058c upstream. With a 32-bit kernel running on 64-bit MIPS hardware the hardcoded value of `cpu_vmbits' only records the size of compatibility useg and does not reflect the size of native xuseg or the complete range of values allowed in the VPN2 field of TLB entries. An upcoming change will need the actual VPN2 value range permitted even in 32-bit kernel configurations, so always include the `vmbits' member in `struct cpuinfo_mips' and probe for SEGBITS when running on 64-bit hardware and resorting to the currently hardcoded value of 31 on 32-bit processors. No functional change for users of `cpu_vmbits'. Signed-off-by: Maciej W. Rozycki Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 6c098142b37015610ad9de403e670b5956f7eb13 Author: Dmitry Torokhov Date: Tue Apr 7 22:16:27 2026 -0700 Input: uinput - take event lock when submitting FF request "event" commit ff14dafde15c11403fac61367a34fea08926e9ee upstream. To avoid racing with FF playback events and corrupting device's event queue take event_lock spinlock when calling uinput_dev_event() when submitting a FF upload or erase "event". Tested-by: Mikhail Gavrilov Link: https://patch.msgid.link/adXkf6MWzlB8LA_s@google.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 1e09dfbb4f5d20ee111f92325a00f85778a5f328 Author: Mikhail Gavrilov Date: Tue Apr 7 12:50:31 2026 +0500 Input: uinput - fix circular locking dependency with ff-core commit 4cda78d6f8bf2b700529f2fbccb994c3e826d7c2 upstream. A lockdep circular locking dependency warning can be triggered reproducibly when using a force-feedback gamepad with uinput (for example, playing ELDEN RING under Wine with a Flydigi Vader 5 controller): ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex The cycle is caused by four lock acquisition paths: 1. ff upload: input_ff_upload() holds ff->mutex and calls uinput_dev_upload_effect() -> uinput_request_submit() -> uinput_request_send(), which acquires udev->mutex. 2. device create: uinput_ioctl_handler() holds udev->mutex and calls uinput_create_device() -> input_register_device(), which acquires input_mutex. 3. device register: input_register_device() holds input_mutex and calls kbd_connect() -> input_register_handle(), which acquires dev->mutex. 4. evdev release: evdev_release() calls input_flush_device() under dev->mutex, which calls input_ff_flush() acquiring ff->mutex. Fix this by introducing a new state_lock spinlock to protect udev->state and udev->dev access in uinput_request_send() instead of acquiring udev->mutex. The function only needs to atomically check device state and queue an input event into the ring buffer via uinput_dev_event() -- both operations are safe under a spinlock (ktime_get_ts64() and wake_up_interruptible() do not sleep). This breaks the ff->mutex -> udev->mutex link since a spinlock is a leaf in the lock ordering and cannot form cycles with mutexes. To keep state transitions visible to uinput_request_send(), protect writes to udev->state in uinput_create_device() and uinput_destroy_device() with the same state_lock spinlock. Additionally, move init_completion(&request->done) from uinput_request_send() to uinput_request_submit() before uinput_request_reserve_slot(). Once the slot is allocated, uinput_flush_requests() may call complete() on it at any time from the destroy path, so the completion must be initialised before the request becomes visible. Lock ordering after the fix: ff->mutex -> state_lock (spinlock, leaf) udev->mutex -> state_lock (spinlock, leaf) udev->mutex -> input_mutex -> dev->mutex -> ff->mutex (no back-edge) Fixes: ff462551235d ("Input: uinput - switch to the new FF interface") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/CABXGCsMoxag+kEwHhb7KqhuyxfmGGd0P=tHZyb1uKE0pLr8Hkg@mail.gmail.com/ Signed-off-by: Mikhail Gavrilov Link: https://patch.msgid.link/20260407075031.38351-1-mikhail.v.gavrilov@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit fb56de5d99218de49d5d43ef3a99e062ecd0f9a1 Author: Andrea Mayer Date: Sat Apr 4 02:44:04 2026 +0200 seg6: separate dst_cache for input and output paths in seg6 lwtunnel commit c3812651b522fe8437ebb7063b75ddb95b571643 upstream. The seg6 lwtunnel uses a single dst_cache per encap route, shared between seg6_input_core() and seg6_output_core(). These two paths can perform the post-encap SID lookup in different routing contexts (e.g., ip rules matching on the ingress interface, or VRF table separation). Whichever path runs first populates the cache, and the other reuses it blindly, bypassing its own lookup. Fix this by splitting the cache into cache_input and cache_output, so each path maintains its own cached dst independently. Fixes: 6c8702c60b88 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels") Cc: stable@vger.kernel.org Signed-off-by: Andrea Mayer Reviewed-by: Nicolas Dichtel Reviewed-by: Justin Iurman Link: https://patch.msgid.link/20260404004405.4057-2-andrea.mayer@uniroma2.it Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 15fa9ead4d5e6b6b9c794e84144146c917f2cb62 Author: Jiayuan Chen Date: Mon Apr 6 11:15:10 2026 +0800 mptcp: fix slab-use-after-free in __inet_lookup_established commit 9b55b253907e7431210483519c5ad711a37dafa1 upstream. The ehash table lookups are lockless and rely on SLAB_TYPESAFE_BY_RCU to guarantee socket memory stability during RCU read-side critical sections. Both tcp_prot and tcpv6_prot have their slab caches created with this flag via proto_register(). However, MPTCP's mptcp_subflow_init() copies tcpv6_prot into tcpv6_prot_override during inet_init() (fs_initcall, level 5), before inet6_init() (module_init/device_initcall, level 6) has called proto_register(&tcpv6_prot). At that point, tcpv6_prot.slab is still NULL, so tcpv6_prot_override.slab remains NULL permanently. This causes MPTCP v6 subflow child sockets to be allocated via kmalloc (falling into kmalloc-4k) instead of the TCPv6 slab cache. The kmalloc-4k cache lacks SLAB_TYPESAFE_BY_RCU, so when these sockets are freed without SOCK_RCU_FREE (which is cleared for child sockets by design), the memory can be immediately reused. Concurrent ehash lookups under rcu_read_lock can then access freed memory, triggering a slab-use-after-free in __inet_lookup_established. Fix this by splitting the IPv6-specific initialization out of mptcp_subflow_init() into a new mptcp_subflow_v6_init(), called from mptcp_proto_v6_init() before protocol registration. This ensures tcpv6_prot_override.slab correctly inherits the SLAB_TYPESAFE_BY_RCU slab cache. Fixes: b19bc2945b40 ("mptcp: implement delegated actions") Cc: stable@vger.kernel.org Signed-off-by: Jiayuan Chen Reviewed-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260406031512.189159-1-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 96a95b6d9e6dca5d338e58991e02e9c1efdaf2fe Author: Matthieu Baerts (NGI0) Date: Tue Apr 7 10:41:41 2026 +0200 Revert "mptcp: add needs_id for netlink appending addr" commit 8e2760eaab778494fc1fa257031e0e1799647f46 upstream. This commit was originally adding the ability to add MPTCP endpoints with ID 0 by accident. The in-kernel PM, handling MPTCP endpoints at the net namespace level, is not supposed to handle endpoints with such ID, because this ID 0 is reserved to the initial subflow, as mentioned in the MPTCPv1 protocol [1], a per-connection setting. Note that 'ip mptcp endpoint add id 0' stops early with an error, but other tools might still request the in-kernel PM to create MPTCP endpoints with this restricted ID 0. In other words, it was wrong to call the mptcp_pm_has_addr_attr_id helper to check whether the address ID attribute is set: if it was set to 0, a new MPTCP endpoint would be created with ID 0, which is not expected, and might cause various issues later. Fixes: 584f38942626 ("mptcp: add needs_id for netlink appending addr") Cc: stable@vger.kernel.org Link: https://datatracker.ietf.org/doc/html/rfc8684#section-3.2-9 [1] Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260407-net-mptcp-revert-pm-needs-id-v2-1-7a25cbc324f8@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 130c991e6aad032f8c1449afa97dcdde91e722fb Author: Takashi Iwai Date: Tue Apr 7 14:33:17 2026 +0200 Revert "ALSA: hda/realtek: Add quirk for Gigabyte Technology to fix headphone" commit 8508e9118649f13f7b857e9e10147b241db615d7 upstream. This reverts commit 56fbbe096a89ff4b52af78a21a4afd9d94bdcc80. It caused regressions on other Gigabyte models, and looking at the bugzilla entry again, the suggested change appears rather dubious, as incorrectly setting the front mic pin as the headphone. Fixes: 56fbbe096a89 ("ALSA: hda/realtek: Add quirk for Gigabyte Technology to fix headphone") Cc: Reported-by: Marcin Krycki Reported-by: Theodoros Orfanidis Closes: https://lore.kernel.org/CAEfRphPU_ABuVFzaHhspxgp2WAqi7kKNGo4yOOt0zeVFPSj8+Q@mail.gmail.com Link: https://patch.msgid.link/20260407123333.171130-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a8c26800e0220e1550af012f5a20e50f5c78864d Author: Greg Kroah-Hartman Date: Mon Mar 30 11:14:13 2026 +0200 net: rfkill: prevent unlimited numbers of rfkill events from being created commit ea245d78dec594372e27d8c79616baf49e98a4a1 upstream. Userspace can create an unlimited number of rfkill events if the system is so configured, while not consuming them from the rfkill file descriptor, causing a potential out of memory situation. Prevent this from bounding the number of pending rfkill events at a "large" number (i.e. 1000) to prevent abuses like this. Cc: Johannes Berg Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Cc: stable Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2026033013-disfigure-scroll-e25e@gregkh Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 6c55714c931051cd7f4839c19ce0867179fd22fe Author: Greg Kroah-Hartman Date: Mon Apr 6 17:34:22 2026 +0200 xfrm_user: fix info leak in build_report() commit d10119968d0e1f2b669604baf2a8b5fdb72fa6b4 upstream. struct xfrm_user_report is a __u8 proto field followed by a struct xfrm_selector which means there is three "empty" bytes of padding, but the padding is never zeroed before copying to userspace. Fix that up by zeroing the structure before setting individual member variables. Cc: stable Cc: Steffen Klassert Cc: Herbert Xu Cc: "David S. Miller" Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Paolo Abeni Cc: Simon Horman Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit e360d15fcb1e819eef49e3d4434d8050542eed16 Author: Johan Hovold Date: Fri Mar 27 12:32:19 2026 +0100 wifi: rt2x00usb: fix devres lifetime commit 25369b22223d1c56e42a0cd4ac9137349d5a898e upstream. USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the USB anchor lifetime so that it is released on driver unbind. Fixes: 8b4c0009313f ("rt2x00usb: Use usb anchor to manage URB") Cc: stable@vger.kernel.org # 4.7 Cc: Vishal Thanki Signed-off-by: Johan Hovold Acked-by: Stanislaw Gruszka Reviewed-by: Greg Kroah-Hartman Link: https://patch.msgid.link/20260327113219.1313748-1-johan@kernel.org Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit f4786c34216a702d108e53fc890bd21e547aabc9 Author: Nathan Rebello Date: Tue Apr 7 02:39:58 2026 -0400 usb: typec: ucsi: skip connector validation before init commit 5a1140404cbf7ba40137dfb1fb96893aa9a67d68 upstream. Notifications can arrive before ucsi_init() has populated ucsi->cap.num_connectors via GET_CAPABILITY. At that point num_connectors is still 0, causing all valid connector numbers to be incorrectly rejected as bogus. Skip the bounds check when num_connectors is 0 (not yet initialized). Pre-init notifications are already handled safely by the early-event guard in ucsi_connector_change(). Reported-by: Takashi Iwai Fixes: d2d8c17ac01a ("usb: typec: ucsi: validate connector number in ucsi_notify_common()") Cc: stable@vger.kernel.org Signed-off-by: Nathan Rebello Tested-by: Takashi Iwai Link: https://patch.msgid.link/20260407063958.863-1-nathan.c.rebello@gmail.com Signed-off-by: Greg Kroah-Hartman commit 6e9f8d2b955712d2a232a2d9a9d88be348fa940f Author: Alexandre Frade Date: Sat Apr 11 17:36:26 2026 +0000 Linux 6.18.22-rt-xanmod1 Signed-off-by: Alexandre Frade commit 34d3dc0d2e5abdd3cef2bc45dc6f07c7ed379634 Author: Alexandre Frade Date: Sat Apr 11 17:26:36 2026 +0000 XANMOD: .gitlab-ci: Change registry image to trixie Signed-off-by: Alexandre Frade commit d0b0ca7f80ac11d4b2067fb062a8be146c5137a5 Merge: 40bc25e65151 1d9cd8c1c15f Author: Alexandre Frade Date: Sat Apr 11 17:22:09 2026 +0000 Merge branch '6.18' into 6.18-rt commit 1d9cd8c1c15f1e3b1681287186af7e4d4ed3045a Author: Alexandre Frade Date: Sat Apr 11 17:17:25 2026 +0000 Linux 6.18.22-xanmod1 Signed-off-by: Alexandre Frade commit 1cfd3a296c3ce2962edad6194c2d86d5d517f010 Merge: eb894ca03fcd f2b09e8b594c Author: Alexandre Frade Date: Sat Apr 11 16:53:54 2026 +0000 Merge tag 'v6.18.22' into 6.18 This is the 6.18.22 stable release commit f2b09e8b594ce61b8ff508ea1fb594b3b24ec6d3 Author: Greg Kroah-Hartman Date: Sat Apr 11 14:26:52 2026 +0200 Linux 6.18.22 Link: https://lore.kernel.org/r/20260408175933.836769063@linuxfoundation.org Tested-by: Dileep Malepu Tested-by: Shung-Hsi Yu Tested-by: Pavel Machek (CIP) Tested-by: Ron Economos Tested-by: Wentao Guan Tested-by: Jon Hunter Tested-by: Shuah Khan Link: https://lore.kernel.org/r/20260409092720.599045151@linuxfoundation.org Tested-by: Miguel Ojeda Tested-by: Jon Hunter Tested-by: Peter Schneider Tested-by: Florian Fainelli Tested-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5e7b2cc8fae9ec2a5bc53311191d2faaff75a4b5 Author: Andrea Righi Date: Wed Apr 8 08:47:41 2026 -0400 sched_ext: Fix stale direct dispatch state in ddsp_dsq_id [ Upstream commit 7e0ffb72de8aa3b25989c2d980e81b829c577010 ] @p->scx.ddsp_dsq_id can be left set (non-SCX_DSQ_INVALID) triggering a spurious warning in mark_direct_dispatch() when the next wakeup's ops.select_cpu() calls scx_bpf_dsq_insert(), such as: WARNING: kernel/sched/ext.c:1273 at scx_dsq_insert_commit+0xcd/0x140 The root cause is that ddsp_dsq_id was only cleared in dispatch_enqueue(), which is not reached in all paths that consume or cancel a direct dispatch verdict. Fix it by clearing it at the right places: - direct_dispatch(): cache the direct dispatch state in local variables and clear it before dispatch_enqueue() on the synchronous path. For the deferred path, the direct dispatch state must remain set until process_ddsp_deferred_locals() consumes them. - process_ddsp_deferred_locals(): cache the dispatch state in local variables and clear it before calling dispatch_to_local_dsq(), which may migrate the task to another rq. - do_enqueue_task(): clear the dispatch state on the enqueue path (local/global/bypass fallbacks), where the direct dispatch verdict is ignored. - dequeue_task_scx(): clear the dispatch state after dispatch_dequeue() to handle both the deferred dispatch cancellation and the holding_cpu race, covering all cases where a pending direct dispatch is cancelled. - scx_disable_task(): clear the direct dispatch state when transitioning a task out of the current scheduler. Waking tasks may have had the direct dispatch state set by the outgoing scheduler's ops.select_cpu() and then been queued on a wake_list via ttwu_queue_wakelist(), when SCX_OPS_ALLOW_QUEUED_WAKEUP is set. Such tasks are not on the runqueue and are not iterated by scx_bypass(), so their direct dispatch state won't be cleared. Without this clear, any subsequent SCX scheduler that tries to direct dispatch the task will trigger the WARN_ON_ONCE() in mark_direct_dispatch(). Fixes: 5b26f7b920f7 ("sched_ext: Allow SCX_DSQ_LOCAL_ON for direct dispatches") Cc: stable@vger.kernel.org # v6.12+ Cc: Daniel Hodges Cc: Patrick Somaru Signed-off-by: Andrea Righi Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d5776a31c16579935855c631bce09eb07dc7da23 Author: Tejun Heo Date: Wed Apr 8 08:47:40 2026 -0400 sched_ext: Refactor do_enqueue_task() local and global DSQ paths [ Upstream commit 3546119f18647d7ddbba579737d8a222b430cb1c ] The local and global DSQ enqueue paths in do_enqueue_task() share the same slice refill logic. Factor out the common code into a shared enqueue label. This makes adding new enqueue cases easier. No functional changes. Reviewed-by: Andrea Righi Reviewed-by: Emil Tsalapatis Signed-off-by: Tejun Heo Stable-dep-of: 7e0ffb72de8a ("sched_ext: Fix stale direct dispatch state in ddsp_dsq_id") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9e36ceb5ca431e10de249a42d8ebcd67ea7dfa26 Author: David Hildenbrand (Arm) Date: Wed Apr 1 12:45:26 2026 -0400 mm/memory: fix PMD/PUD checks in follow_pfnmap_start() [ Upstream commit ffef67b93aa352b34e6aeba3d52c19a63885409a ] follow_pfnmap_start() suffers from two problems: (1) We are not re-fetching the pmd/pud after taking the PTL Therefore, we are not properly stabilizing what the lock actually protects. If there is concurrent zapping, we would indicate to the caller that we found an entry, however, that entry might already have been invalidated, or contain a different PFN after taking the lock. Properly use pmdp_get() / pudp_get() after taking the lock. (2) pmd_leaf() / pud_leaf() are not well defined on non-present entries pmd_leaf()/pud_leaf() could wrongly trigger on non-present entries. There is no real guarantee that pmd_leaf()/pud_leaf() returns something reasonable on non-present entries. Most architectures indeed either perform a present check or make it work by smart use of flags. However, for example loongarch checks the _PAGE_HUGE flag in pmd_leaf(), and always sets the _PAGE_HUGE flag in __swp_entry_to_pmd(). Whereby pmd_trans_huge() explicitly checks pmd_present(), pmd_leaf() does not do that. Let's check pmd_present()/pud_present() before assuming "the is a present PMD leaf" when spotting pmd_leaf()/pud_leaf(), like other page table handling code that traverses user page tables does. Given that non-present PMD entries are likely rare in VM_IO|VM_PFNMAP, (1) is likely more relevant than (2). It is questionable how often (1) would actually trigger, but let's CC stable to be sure. This was found by code inspection. Link: https://lkml.kernel.org/r/20260323-follow_pfnmap_fix-v1-1-5b0ec10872b3@kernel.org Fixes: 6da8e9634bb7 ("mm: new follow_pfnmap API") Signed-off-by: David Hildenbrand (Arm) Acked-by: Mike Rapoport (Microsoft) Reviewed-by: Lorenzo Stoakes (Oracle) Cc: Liam Howlett Cc: Michal Hocko Cc: Peter Xu Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cef18bb87a6c261e146e1b23fc88757860fe9d81 Author: Anshuman Khandual Date: Wed Apr 1 12:45:25 2026 -0400 mm: replace READ_ONCE() with standard page table accessors [ Upstream commit c0efdb373c3aaacb32db59cadb0710cac13e44ae ] Replace all READ_ONCE() with a standard page table accessors i.e pxdp_get() that defaults into READ_ONCE() in cases where platform does not override. Link: https://lkml.kernel.org/r/20251007063100.2396936-1-anshuman.khandual@arm.com Signed-off-by: Anshuman Khandual Acked-by: David Hildenbrand Reviewed-by: Lance Yang Reviewed-by: Wei Yang Reviewed-by: Dev Jain Signed-off-by: Andrew Morton Stable-dep-of: ffef67b93aa3 ("mm/memory: fix PMD/PUD checks in follow_pfnmap_start()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a836054ea81014117ec6b73529a21626a9e1f829 Author: Josef Bacik Date: Tue Mar 31 10:43:24 2026 -0400 scsi: target: tcm_loop: Drain commands in target_reset handler [ Upstream commit 1333eee56cdf3f0cf67c6ab4114c2c9e0a952026 ] tcm_loop_target_reset() violates the SCSI EH contract: it returns SUCCESS without draining any in-flight commands. The SCSI EH documentation (scsi_eh.rst) requires that when a reset handler returns SUCCESS the driver has made lower layers "forget about timed out scmds" and is ready for new commands. Every other SCSI LLD (virtio_scsi, mpt3sas, ipr, scsi_debug, mpi3mr) enforces this by draining or completing outstanding commands before returning SUCCESS. Because tcm_loop_target_reset() doesn't drain, the SCSI EH reuses in-flight scsi_cmnd structures for recovery commands (e.g. TUR) while the target core still has async completion work queued for the old se_cmd. The memset in queuecommand zeroes se_lun and lun_ref_active, causing transport_lun_remove_cmd() to skip its percpu_ref_put(). The leaked LUN reference prevents transport_clear_lun_ref() from completing, hanging configfs LUN unlink forever in D-state: INFO: task rm:264 blocked for more than 122 seconds. rm D 0 264 258 0x00004000 Call Trace: __schedule+0x3d0/0x8e0 schedule+0x36/0xf0 transport_clear_lun_ref+0x78/0x90 [target_core_mod] core_tpg_remove_lun+0x28/0xb0 [target_core_mod] target_fabric_port_unlink+0x50/0x60 [target_core_mod] configfs_unlink+0x156/0x1f0 [configfs] vfs_unlink+0x109/0x290 do_unlinkat+0x1d5/0x2d0 Fix this by making tcm_loop_target_reset() actually drain commands: 1. Issue TMR_LUN_RESET via tcm_loop_issue_tmr() to drain all commands that the target core knows about (those not yet CMD_T_COMPLETE). 2. Use blk_mq_tagset_busy_iter() to iterate all started requests and flush_work() on each se_cmd — this drains any deferred completion work for commands that already had CMD_T_COMPLETE set before the TMR (which the TMR skips via __target_check_io_state()). This is the same pattern used by mpi3mr, scsi_debug, and libsas to drain outstanding commands during reset. Fixes: e0eb5d38b732 ("scsi: target: tcm_loop: Use block cmd allocator for se_cmds") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Josef Bacik Link: https://patch.msgid.link/27011aa34c8f6b1b94d2e3cf5655b6d037f53428.1773706803.git.josef@toxicpanda.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ce54802fe6bb78eb0feffc66fed6a45d41ffc3ab Author: Thinh Nguyen Date: Tue Mar 31 11:29:10 2026 -0400 scsi: target: file: Use kzalloc_flex for aio_cmd [ Upstream commit 01f784fc9d0ab2a6dac45ee443620e517cb2a19b ] The target_core_file doesn't initialize the aio_cmd->iocb for the ki_write_stream. When a write command fd_execute_rw_aio() is executed, we may get a bogus ki_write_stream value, causing unintended write failure status when checking iocb->ki_write_stream > max_write_streams in the block device. Let's just use kzalloc_flex when allocating the aio_cmd and let ki_write_stream=0 to fix this issue. Fixes: 732f25a2895a ("fs: add a write stream field to the kiocb") Fixes: c27683da6406 ("block: expose write streams for block device nodes") Cc: stable@vger.kernel.org Signed-off-by: Thinh Nguyen Link: https://patch.msgid.link/f1a2f81c62f043e31f80bb92d5f29893400c8ee2.1773450782.git.Thinh.Nguyen@synopsys.com Signed-off-by: Martin K. Petersen [ changed kmalloc() to kzalloc() ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a98b78116a27e2a57b696b569b2cb431c95cf9b6 Author: Willem de Bruijn Date: Tue Mar 31 12:30:43 2026 -0400 net: correctly handle tunneled traffic on IPV6_CSUM GSO fallback [ Upstream commit c4336a07eb6b2526dc2b62928b5104b41a7f81f5 ] NETIF_F_IPV6_CSUM only advertises support for checksum offload of packets without IPv6 extension headers. Packets with extension headers must fall back onto software checksumming. Since TSO depends on checksum offload, those must revert to GSO. The below commit introduces that fallback. It always checks network header length. For tunneled packets, the inner header length must be checked instead. Extend the check accordingly. A special case is tunneled packets without inner IP protocol. Such as RFC 6951 SCTP in UDP. Those are not standard IPv6 followed by transport header either, so also must revert to the software GSO path. Cc: stable@vger.kernel.org Fixes: 864e3396976e ("net: gso: Forbid IPv6 TSO with extensions on devices with only IPV6_CSUM") Reported-by: Tangxin Xie Closes: https://lore.kernel.org/netdev/0414e7e2-9a1c-4d7c-a99d-b9039cf68f40@yeah.net/ Suggested-by: Paolo Abeni Signed-off-by: Willem de Bruijn Link: https://patch.msgid.link/20260320190148.2409107-1-willemdebruijn.kernel@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5f4061f8225d18695e5afe9bbf1cb7bd673d7872 Author: Guangshuo Li Date: Tue Mar 31 12:30:38 2026 -0400 net: mana: fix use-after-free in add_adev() error path [ Upstream commit c4ea7d8907cf72b259bf70bd8c2e791e1c4ff70f ] If auxiliary_device_add() fails, add_adev() jumps to add_fail and calls auxiliary_device_uninit(adev). The auxiliary device has its release callback set to adev_release(), which frees the containing struct mana_adev. Since adev is embedded in struct mana_adev, the subsequent fall-through to init_fail and access to adev->id may result in a use-after-free. Fix this by saving the allocated auxiliary device id in a local variable before calling auxiliary_device_add(), and use that saved id in the cleanup path after auxiliary_device_uninit(). Fixes: a69839d4327d ("net: mana: Add support for auxiliary device") Cc: stable@vger.kernel.org Reviewed-by: Long Li Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260323165730.945365-1-lgs201920130244@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 24ce568f7553a55404cddf8f0fca2a7c0ea9451c Author: Alex Deucher Date: Tue Mar 31 20:19:34 2026 -0400 drm/amd/display: Fix DCE LVDS handling [ Upstream commit 90d239cc53723c1a3f89ce08eac17bf3a9e9f2d4 ] LVDS does not use an HPD pin so it may be invalid. Handle this case correctly in link encoder creation. Fixes: 7c8fb3b8e9ba ("drm/amd/display: Add hpd_source index check for DCE60/80/100/110/112/120 link encoders") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5012 Cc: Srinivasan Shanmugam Cc: Roman Li Reviewed-by: Roman Li Reviewed-by: Srinivasan Shanmugam Signed-off-by: Alex Deucher (cherry picked from commit 3b5620f7ee688177fcf65cf61588c5435bce1872) Cc: stable@vger.kernel.org [ removed unrelated VGA connector block absent from stable and split combined null/bounds check into separate guard and ternary ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ba9be472a438ea348f0fffaaebf541960ee643db Author: Yang Wang Date: Wed Apr 1 12:31:35 2026 -0400 drm/amd/pm: disable OD_FAN_CURVE if temp or pwm range invalid for smu v13 [ Upstream commit 3e6dd28a11083e83e11a284d99fcc9eb748c321c ] Forcibly disable the OD_FAN_CURVE feature when temperature or PWM range is invalid, otherwise PMFW will reject this configuration on smu v13.0.x example: $ sudo cat /sys/bus/pci/devices//gpu_od/fan_ctrl/fan_curve OD_FAN_CURVE: 0: 0C 0% 1: 0C 0% 2: 0C 0% 3: 0C 0% 4: 0C 0% OD_RANGE: FAN_CURVE(hotspot temp): 0C 0C FAN_CURVE(fan speed): 0% 0% $ echo "0 50 40" | sudo tee fan_curve kernel log: [ 756.442527] amdgpu 0000:03:00.0: amdgpu: Fan curve temp setting(50) must be within [0, 0]! [ 777.345800] amdgpu 0000:03:00.0: amdgpu: Fan curve temp setting(50) must be within [0, 0]! Closes: https://github.com/ROCm/amdgpu/issues/208 Signed-off-by: Yang Wang Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 470891606c5a97b1d0d937e0aa67a3bed9fcb056) Cc: stable@vger.kernel.org [ adapted forward declaration placement to existing FEATURE_MASK macro ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5bbadf60b121065ffb267ec92018607b9c1c7524 Author: Alexander Popov Date: Wed Mar 25 01:46:02 2026 +0300 wifi: virt_wifi: remove SET_NETDEV_DEV to avoid use-after-free commit 789b06f9f39cdc7e895bdab2c034e39c41c8f8d6 upstream. Currently we execute `SET_NETDEV_DEV(dev, &priv->lowerdev->dev)` for the virt_wifi net devices. However, unregistering a virt_wifi device in netdev_run_todo() can happen together with the device referenced by SET_NETDEV_DEV(). It can result in use-after-free during the ethtool operations performed on a virt_wifi device that is currently being unregistered. Such a net device can have the `dev.parent` field pointing to the freed memory, but ethnl_ops_begin() calls `pm_runtime_get_sync(dev->dev.parent)`. Let's remove SET_NETDEV_DEV for virt_wifi to avoid bugs like this: ================================================================== BUG: KASAN: slab-use-after-free in __pm_runtime_resume+0xe2/0xf0 Read of size 2 at addr ffff88810cfc46f8 by task pm/606 Call Trace: dump_stack_lvl+0x4d/0x70 print_report+0x170/0x4f3 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 kasan_report+0xda/0x110 ? __pm_runtime_resume+0xe2/0xf0 ? __pm_runtime_resume+0xe2/0xf0 __pm_runtime_resume+0xe2/0xf0 ethnl_ops_begin+0x49/0x270 ethnl_set_features+0x23c/0xab0 ? __pfx_ethnl_set_features+0x10/0x10 ? kvm_sched_clock_read+0x11/0x20 ? local_clock_noinstr+0xf/0xf0 ? local_clock+0x10/0x30 ? kasan_save_track+0x25/0x60 ? __kasan_kmalloc+0x7f/0x90 ? genl_family_rcv_msg_attrs_parse.isra.0+0x150/0x2c0 genl_family_rcv_msg_doit+0x1e7/0x2c0 ? __pfx_genl_family_rcv_msg_doit+0x10/0x10 ? __pfx_cred_has_capability.isra.0+0x10/0x10 ? stack_trace_save+0x8e/0xc0 genl_rcv_msg+0x411/0x660 ? __pfx_genl_rcv_msg+0x10/0x10 ? __pfx_ethnl_set_features+0x10/0x10 netlink_rcv_skb+0x121/0x380 ? __pfx_genl_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? __pfx_down_read+0x10/0x10 genl_rcv+0x23/0x30 netlink_unicast+0x60f/0x830 ? __pfx_netlink_unicast+0x10/0x10 ? __pfx___alloc_skb+0x10/0x10 netlink_sendmsg+0x6ea/0xbc0 ? __pfx_netlink_sendmsg+0x10/0x10 ? __futex_queue+0x10b/0x1f0 ____sys_sendmsg+0x7a2/0x950 ? copy_msghdr_from_user+0x26b/0x430 ? __pfx_____sys_sendmsg+0x10/0x10 ? __pfx_copy_msghdr_from_user+0x10/0x10 ___sys_sendmsg+0xf8/0x180 ? __pfx____sys_sendmsg+0x10/0x10 ? __pfx_futex_wait+0x10/0x10 ? fdget+0x2e4/0x4a0 __sys_sendmsg+0x11f/0x1c0 ? __pfx___sys_sendmsg+0x10/0x10 do_syscall_64+0xe2/0x570 ? exc_page_fault+0x66/0xb0 entry_SYSCALL_64_after_hwframe+0x77/0x7f This fix may be combined with another one in the ethtool subsystem: https://lore.kernel.org/all/20260322075917.254874-1-alex.popov@linux.com/T/#u Fixes: d43c65b05b848e0b ("ethtool: runtime-resume netdev parent in ethnl_ops_begin") Cc: stable@vger.kernel.org Signed-off-by: Alexander Popov Acked-by: Greg Kroah-Hartman Reviewed-by: Breno Leitao Link: https://patch.msgid.link/20260324224607.374327-1-alex.popov@linux.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit e367143b520ae735e986bcbeeefca00af534f1a0 Author: Petr Mladek Date: Fri Nov 28 14:59:20 2025 +0100 kallsyms: prevent module removal when printing module name and buildid commit 3b07086444f80c844351255fd94c2cb0a7224df2 upstream. kallsyms_lookup_buildid() copies the symbol name into the given buffer so that it can be safely read anytime later. But it just copies pointers to mod->name and mod->build_id which might get reused after the related struct module gets removed. The lifetime of struct module is synchronized using RCU. Take the rcu read lock for the entire __sprint_symbol(). Link: https://lkml.kernel.org/r/20251128135920.217303-8-pmladek@suse.com Signed-off-by: Petr Mladek Reviewed-by: Aaron Tomlin Cc: Alexei Starovoitov Cc: Daniel Borkman Cc: Daniel Gomez Cc: John Fastabend Cc: Kees Cook Cc: Luis Chamberalin Cc: Marc Rutland Cc: "Masami Hiramatsu (Google)" Cc: Petr Pavlu Cc: Sami Tolvanen Cc: Steven Rostedt (Google) Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 10bbeed03e1db38a7378dff508b019161c172494 Author: Petr Mladek Date: Fri Nov 28 14:59:17 2025 +0100 kallsyms: cleanup code for appending the module buildid commit 8e81dac4cd5477731169b92cff7c24f8f6635950 upstream. Put the code for appending the optional "buildid" into a helper function, It makes __sprint_symbol() better readable. Also print a warning when the "modname" is set and the "buildid" isn't. It might catch a situation when some lookup function in kallsyms_lookup_buildid() does not handle the "buildid". Use pr_*_once() to avoid an infinite recursion when the function is called from printk(). The recursion is rather theoretical but better be on the safe side. Link: https://lkml.kernel.org/r/20251128135920.217303-5-pmladek@suse.com Signed-off-by: Petr Mladek Cc: Aaron Tomlin Cc: Alexei Starovoitov Cc: Daniel Borkman Cc: Daniel Gomez Cc: John Fastabend Cc: Kees Cook Cc: Luis Chamberalin Cc: Marc Rutland Cc: "Masami Hiramatsu (Google)" Cc: Petr Pavlu Cc: Sami Tolvanen Cc: Steven Rostedt (Google) Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit c1d72e846cb4ecbe6643965e7d67ad1c2ff816fd Author: Petr Mladek Date: Fri Nov 28 14:59:15 2025 +0100 kallsyms: clean up modname and modbuildid initialization in kallsyms_lookup_buildid() commit fda024fb64769e9d6b3916d013c78d6b189129f8 upstream. The @modname and @modbuildid optional return parameters are set only when the symbol is in a module. Always initialize them so that they do not need to be cleared when the module is not in a module. It simplifies the logic and makes the code even slightly more safe. Note that bpf_address_lookup() function will get updated in a separate patch. Link: https://lkml.kernel.org/r/20251128135920.217303-3-pmladek@suse.com Signed-off-by: Petr Mladek Cc: Aaron Tomlin Cc: Alexei Starovoitov Cc: Daniel Borkman Cc: Daniel Gomez Cc: John Fastabend Cc: Kees Cook Cc: Luis Chamberalin Cc: Marc Rutland Cc: "Masami Hiramatsu (Google)" Cc: Petr Pavlu Cc: Sami Tolvanen Cc: Steven Rostedt (Google) Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit ab5f05ae96fcd97b706359a74d0b7383fc2607c6 Author: Petr Mladek Date: Fri Nov 28 14:59:14 2025 +0100 kallsyms: clean up @namebuf initialization in kallsyms_lookup_buildid() commit 426295ef18c5d5f0b7f75ac89d09022fcfafd25c upstream. Patch series "kallsyms: Prevent invalid access when showing module buildid", v3. We have seen nested crashes in __sprint_symbol(), see below. They seem to be caused by an invalid pointer to "buildid". This patchset cleans up kallsyms code related to module buildid and fixes this invalid access when printing backtraces. I made an audit of __sprint_symbol() and found several situations when the buildid might be wrong: + bpf_address_lookup() does not set @modbuildid + ftrace_mod_address_lookup() does not set @modbuildid + __sprint_symbol() does not take rcu_read_lock and the related struct module might get removed before mod->build_id is printed. This patchset solves these problems: + 1st, 2nd patches are preparatory + 3rd, 4th, 6th patches fix the above problems + 5th patch cleans up a suspicious initialization code. This is the backtrace, we have seen. But it is not really important. The problems fixed by the patchset are obvious: crash64> bt [62/2029] PID: 136151 TASK: ffff9f6c981d4000 CPU: 367 COMMAND: "btrfs" #0 [ffffbdb687635c28] machine_kexec at ffffffffb4c845b3 #1 [ffffbdb687635c80] __crash_kexec at ffffffffb4d86a6a #2 [ffffbdb687635d08] hex_string at ffffffffb51b3b61 #3 [ffffbdb687635d40] crash_kexec at ffffffffb4d87964 #4 [ffffbdb687635d50] oops_end at ffffffffb4c41fc8 #5 [ffffbdb687635d70] do_trap at ffffffffb4c3e49a #6 [ffffbdb687635db8] do_error_trap at ffffffffb4c3e6a4 #7 [ffffbdb687635df8] exc_stack_segment at ffffffffb5666b33 #8 [ffffbdb687635e20] asm_exc_stack_segment at ffffffffb5800cf9 ... This patch (of 7) The function kallsyms_lookup_buildid() initializes the given @namebuf by clearing the first and the last byte. It is not clear why. The 1st byte makes sense because some callers ignore the return code and expect that the buffer contains a valid string, for example: - function_stat_show() - kallsyms_lookup() - kallsyms_lookup_buildid() The initialization of the last byte does not make much sense because it can later be overwritten. Fortunately, it seems that all called functions behave correctly: - kallsyms_expand_symbol() explicitly adds the trailing '\0' at the end of the function. - All *__address_lookup() functions either use the safe strscpy() or they do not touch the buffer at all. Document the reason for clearing the first byte. And remove the useless initialization of the last byte. Link: https://lkml.kernel.org/r/20251128135920.217303-2-pmladek@suse.com Signed-off-by: Petr Mladek Reviewed-by: Aaron Tomlin Cc: Alexei Starovoitov Cc: Daniel Borkman Cc: John Fastabend Cc: Kees Cook Cc: Luis Chamberalin Cc: Marc Rutland Cc: "Masami Hiramatsu (Google)" Cc: Petr Pavlu Cc: Sami Tolvanen Cc: Steven Rostedt Cc: Daniel Gomez Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 8e5eb1d6e6a3d7bbea9c92132d0cda5793176426 Author: Taegu Ha Date: Thu Apr 2 04:13:11 2026 +0900 usb: gadget: f_uac1_legacy: validate control request size commit 6e0e34d85cd46ceb37d16054e97a373a32770f6c upstream. f_audio_complete() copies req->length bytes into a 4-byte stack variable: u32 data = 0; memcpy(&data, req->buf, req->length); req->length is derived from the host-controlled USB request path, which can lead to a stack out-of-bounds write. Validate req->actual against the expected payload size for the supported control selectors and decode only the expected amount of data. This avoids copying a host-influenced length into a fixed-size stack object. Signed-off-by: Taegu Ha Cc: stable Link: https://patch.msgid.link/20260401191311.3604898-1-hataegu0826@gmail.com Signed-off-by: Greg Kroah-Hartman commit 5d1bb391ceeebb28327703dd07af8c6324af298f Author: Michael Zimmermann Date: Tue Mar 31 20:48:44 2026 +0200 usb: gadget: f_hid: move list and spinlock inits from bind to alloc commit 4e0a88254ad59f6c53a34bf5fa241884ec09e8b2 upstream. There was an issue when you did the following: - setup and bind an hid gadget - open /dev/hidg0 - use the resulting fd in EPOLL_CTL_ADD - unbind the UDC - bind the UDC - use the fd in EPOLL_CTL_DEL When CONFIG_DEBUG_LIST was enabled, a list_del corruption was reported within remove_wait_queue (via ep_remove_wait_queue). After some debugging I found out that the queues, which f_hid registers via poll_wait were the problem. These were initialized using init_waitqueue_head inside hidg_bind. So effectively, the bind function re-initialized the queues while there were still items in them. The solution is to move the initialization from hidg_bind to hidg_alloc to extend their lifetimes to the lifetime of the function instance. Additionally, I found many other possibly problematic init calls in the bind function, which I moved as well. Signed-off-by: Michael Zimmermann Cc: stable Link: https://patch.msgid.link/20260331184844.2388761-1-sigmaepsilon92@gmail.com Signed-off-by: Greg Kroah-Hartman commit 18ada801899f2b13ef0ceff42427ad980a41e619 Author: Kuen-Han Tsai Date: Fri Mar 20 16:54:50 2026 +0800 usb: gadget: f_rndis: Fix net_device lifecycle with device_move commit e367599529dc42578545a7f85fde517b35b3cda7 upstream. The net_device is allocated during function instance creation and registered during the bind phase with the gadget device as its sysfs parent. When the function unbinds, the parent device is destroyed, but the net_device survives, resulting in dangling sysfs symlinks: console:/ # ls -l /sys/class/net/usb0 lrwxrwxrwx ... /sys/class/net/usb0 -> /sys/devices/platform/.../gadget.0/net/usb0 console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0 ls: .../gadget.0/net/usb0: No such file or directory Use device_move() to reparent the net_device between the gadget device tree and /sys/devices/virtual across bind and unbind cycles. During the final unbind, calling device_move(NULL) moves the net_device to the virtual device tree before the gadget device is destroyed. On rebinding, device_move() reparents the device back under the new gadget, ensuring proper sysfs topology and power management ordering. To maintain compatibility with legacy composite drivers (e.g., multi.c), the borrowed_net flag is used to indicate whether the network device is shared and pre-registered during the legacy driver's bind phase. Fixes: f466c6353819 ("usb: gadget: f_rndis: convert to new function interface with backward compatibility") Cc: stable@vger.kernel.org Signed-off-by: Kuen-Han Tsai Link: https://patch.msgid.link/20260320-usb-net-lifecycle-v1-7-4886b578161b@google.com Signed-off-by: Greg Kroah-Hartman commit 9cbc4f109bb216623894d8819fb930210ed34b21 Author: Kuen-Han Tsai Date: Fri Mar 20 16:54:49 2026 +0800 usb: gadget: f_subset: Fix net_device lifecycle with device_move commit 06524cd1c9011bee141a87e43ab878641ed3652b upstream. The net_device is allocated during function instance creation and registered during the bind phase with the gadget device as its sysfs parent. When the function unbinds, the parent device is destroyed, but the net_device survives, resulting in dangling sysfs symlinks: console:/ # ls -l /sys/class/net/usb0 lrwxrwxrwx ... /sys/class/net/usb0 -> /sys/devices/platform/.../gadget.0/net/usb0 console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0 ls: .../gadget.0/net/usb0: No such file or directory Use device_move() to reparent the net_device between the gadget device tree and /sys/devices/virtual across bind and unbind cycles. During the final unbind, calling device_move(NULL) moves the net_device to the virtual device tree before the gadget device is destroyed. On rebinding, device_move() reparents the device back under the new gadget, ensuring proper sysfs topology and power management ordering. To maintain compatibility with legacy composite drivers (e.g., multi.c), the bound flag is used to indicate whether the network device is shared and pre-registered during the legacy driver's bind phase. Fixes: 8cedba7c73af ("usb: gadget: f_subset: convert to new function interface with backward compatibility") Cc: stable@vger.kernel.org Signed-off-by: Kuen-Han Tsai Link: https://patch.msgid.link/20260320-usb-net-lifecycle-v1-6-4886b578161b@google.com Signed-off-by: Greg Kroah-Hartman commit 4ccdccff8febc5456aff684627f9a4c5c83b9346 Author: Kuen-Han Tsai Date: Fri Mar 20 16:54:48 2026 +0800 usb: gadget: f_eem: Fix net_device lifecycle with device_move commit d9270c9a8118c1535409db926ac1e2545dc97b81 upstream. The net_device is allocated during function instance creation and registered during the bind phase with the gadget device as its sysfs parent. When the function unbinds, the parent device is destroyed, but the net_device survives, resulting in dangling sysfs symlinks: console:/ # ls -l /sys/class/net/usb0 lrwxrwxrwx ... /sys/class/net/usb0 -> /sys/devices/platform/.../gadget.0/net/usb0 console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0 ls: .../gadget.0/net/usb0: No such file or directory Use device_move() to reparent the net_device between the gadget device tree and /sys/devices/virtual across bind and unbind cycles. During the final unbind, calling device_move(NULL) moves the net_device to the virtual device tree before the gadget device is destroyed. On rebinding, device_move() reparents the device back under the new gadget, ensuring proper sysfs topology and power management ordering. To maintain compatibility with legacy composite drivers (e.g., multi.c), the bound flag is used to indicate whether the network device is shared and pre-registered during the legacy driver's bind phase. Fixes: b29002a15794 ("usb: gadget: f_eem: convert to new function interface with backward compatibility") Cc: stable@vger.kernel.org Signed-off-by: Kuen-Han Tsai Link: https://patch.msgid.link/20260320-usb-net-lifecycle-v1-5-4886b578161b@google.com Signed-off-by: Greg Kroah-Hartman commit 4e34f3f491fd731809b57ddb5329ec763bd39553 Author: Kuen-Han Tsai Date: Fri Mar 20 16:54:47 2026 +0800 usb: gadget: f_ecm: Fix net_device lifecycle with device_move commit b2cc4fae67a51f60d81d6af2678696accb07c656 upstream. The net_device is allocated during function instance creation and registered during the bind phase with the gadget device as its sysfs parent. When the function unbinds, the parent device is destroyed, but the net_device survives, resulting in dangling sysfs symlinks: console:/ # ls -l /sys/class/net/usb0 lrwxrwxrwx ... /sys/class/net/usb0 -> /sys/devices/platform/.../gadget.0/net/usb0 console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0 ls: .../gadget.0/net/usb0: No such file or directory Use device_move() to reparent the net_device between the gadget device tree and /sys/devices/virtual across bind and unbind cycles. During the final unbind, calling device_move(NULL) moves the net_device to the virtual device tree before the gadget device is destroyed. On rebinding, device_move() reparents the device back under the new gadget, ensuring proper sysfs topology and power management ordering. To maintain compatibility with legacy composite drivers (e.g., multi.c), the bound flag is used to indicate whether the network device is shared and pre-registered during the legacy driver's bind phase. Fixes: fee562a6450b ("usb: gadget: f_ecm: convert to new function interface with backward compatibility") Cc: stable@vger.kernel.org Signed-off-by: Kuen-Han Tsai Link: https://patch.msgid.link/20260320-usb-net-lifecycle-v1-4-4886b578161b@google.com Signed-off-by: Greg Kroah-Hartman commit 446f1842cda929c40d4697722bfdcfb334bc9692 Author: Kuen-Han Tsai Date: Fri Mar 20 16:54:45 2026 +0800 usb: gadget: f_rndis: Protect RNDIS options with mutex commit 8d8c68b1fc06ece60cf43e1306ff0f4ac121547e upstream. The class/subclass/protocol options are suspectible to race conditions as they can be accessed concurrently through configfs. Use existing mutex to protect these options. This issue was identified during code inspection. Fixes: 73517cf49bd4 ("usb: gadget: add RNDIS configfs options for class/subclass/protocol") Cc: stable@vger.kernel.org Signed-off-by: Kuen-Han Tsai Link: https://patch.msgid.link/20260320-usb-net-lifecycle-v1-2-4886b578161b@google.com Signed-off-by: Greg Kroah-Hartman commit 3d436670b47415da042452618fb5d8e317ab095f Author: Kuen-Han Tsai Date: Fri Mar 20 16:54:44 2026 +0800 usb: gadget: f_subset: Fix unbalanced refcnt in geth_free commit caa27923aacd8a5869207842f2ab1657c6c0c7bc upstream. geth_alloc() increments the reference count, but geth_free() fails to decrement it. This prevents the configuration of attributes via configfs after unlinking the function. Decrement the reference count in geth_free() to ensure proper cleanup. Fixes: 02832e56f88a ("usb: gadget: f_subset: add configfs support") Cc: stable@vger.kernel.org Signed-off-by: Kuen-Han Tsai Link: https://patch.msgid.link/20260320-usb-net-lifecycle-v1-1-4886b578161b@google.com Signed-off-by: Greg Kroah-Hartman commit 1aa9356881ee4ed414bf72d0c56d915492cb5345 Author: Jimmy Hu Date: Fri Mar 20 14:54:27 2026 +0800 usb: gadget: uvc: fix NULL pointer dereference during unbind race commit eba2936bbe6b752a31725a9eb5c674ecbf21ee7d upstream. Commit b81ac4395bbe ("usb: gadget: uvc: allow for application to cleanly shutdown") introduced two stages of synchronization waits totaling 1500ms in uvc_function_unbind() to prevent several types of kernel panics. However, this timing-based approach is insufficient during power management (PM) transitions. When the PM subsystem starts freezing user space processes, the wait_event_interruptible_timeout() is aborted early, which allows the unbind thread to proceed and nullify the gadget pointer (cdev->gadget = NULL): [ 814.123447][ T947] configfs-gadget.g1 gadget.0: uvc: uvc_function_unbind() [ 814.178583][ T3173] PM: suspend entry (deep) [ 814.192487][ T3173] Freezing user space processes [ 814.197668][ T947] configfs-gadget.g1 gadget.0: uvc: uvc_function_unbind no clean disconnect, wait for release When the PM subsystem resumes or aborts the suspend and tasks are restarted, the V4L2 release path is executed and attempts to access the already nullified gadget pointer, triggering a kernel panic: [ 814.292597][ C0] PM: pm_system_irq_wakeup: 479 triggered dhdpcie_host_wake [ 814.386727][ T3173] Restarting tasks ... [ 814.403522][ T4558] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030 [ 814.404021][ T4558] pc : usb_gadget_deactivate+0x14/0xf4 [ 814.404031][ T4558] lr : usb_function_deactivate+0x54/0x94 [ 814.404078][ T4558] Call trace: [ 814.404080][ T4558] usb_gadget_deactivate+0x14/0xf4 [ 814.404083][ T4558] usb_function_deactivate+0x54/0x94 [ 814.404087][ T4558] uvc_function_disconnect+0x1c/0x5c [ 814.404092][ T4558] uvc_v4l2_release+0x44/0xac [ 814.404095][ T4558] v4l2_release+0xcc/0x130 Address the race condition and NULL pointer dereference by: 1. State Synchronization (flag + mutex) Introduce a 'func_unbound' flag in struct uvc_device. This allows uvc_function_disconnect() to safely skip accessing the nullified cdev->gadget pointer. As suggested by Alan Stern, this flag is protected by a new mutex (uvc->lock) to ensure proper memory ordering and prevent instruction reordering or speculative loads. This mutex is also used to protect 'func_connected' for consistent state management. 2. Explicit Synchronization (completion) Use a completion to synchronize uvc_function_unbind() with the uvc_vdev_release() callback. This prevents Use-After-Free (UAF) by ensuring struct uvc_device is freed after all video device resources are released. Fixes: b81ac4395bbe ("usb: gadget: uvc: allow for application to cleanly shutdown") Cc: stable Suggested-by: Alan Stern Signed-off-by: Jimmy Hu Link: https://patch.msgid.link/20260320065427.1374555-1-hhhuuu@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit a36e5e800b9c93e3e1ffa42f34d38b36775dbcee Author: Kuen-Han Tsai Date: Mon Mar 16 15:49:09 2026 +0800 usb: gadget: u_ether: Fix NULL pointer deref in eth_get_drvinfo commit e002e92e88e12457373ed096b18716d97e7bbb20 upstream. Commit ec35c1969650 ("usb: gadget: f_ncm: Fix net_device lifecycle with device_move") reparents the gadget device to /sys/devices/virtual during unbind, clearing the gadget pointer. If the userspace tool queries on the surviving interface during this detached window, this leads to a NULL pointer dereference. Unable to handle kernel NULL pointer dereference Call trace: eth_get_drvinfo+0x50/0x90 ethtool_get_drvinfo+0x5c/0x1f0 __dev_ethtool+0xaec/0x1fe0 dev_ethtool+0x134/0x2e0 dev_ioctl+0x338/0x560 Add a NULL check for dev->gadget in eth_get_drvinfo(). When detached, skip copying the fw_version and bus_info strings, which is natively handled by ethtool_get_drvinfo for empty strings. Suggested-by: Val Packett Reported-by: Val Packett Closes: https://lore.kernel.org/linux-usb/10890524-cf83-4a71-b879-93e2b2cc1fcc@packett.cool/ Fixes: ec35c1969650 ("usb: gadget: f_ncm: Fix net_device lifecycle with device_move") Cc: stable Signed-off-by: Kuen-Han Tsai Link: https://patch.msgid.link/20260316-eth-null-deref-v1-1-07005f33be85@google.com Signed-off-by: Greg Kroah-Hartman commit 6ad77458637b78ec655e3da5f112c862e6690a9d Author: Kuen-Han Tsai Date: Wed Mar 11 17:12:15 2026 +0800 usb: gadget: u_ether: Fix race between gether_disconnect and eth_stop commit e1eabb072c75681f78312c484ccfffb7430f206e upstream. A race condition between gether_disconnect() and eth_stop() leads to a NULL pointer dereference. Specifically, if eth_stop() is triggered concurrently while gether_disconnect() is tearing down the endpoints, eth_stop() attempts to access the cleared endpoint descriptor, causing the following NPE: Unable to handle kernel NULL pointer dereference Call trace: __dwc3_gadget_ep_enable+0x60/0x788 dwc3_gadget_ep_enable+0x70/0xe4 usb_ep_enable+0x60/0x15c eth_stop+0xb8/0x108 Because eth_stop() crashes while holding the dev->lock, the thread running gether_disconnect() fails to acquire the same lock and spins forever, resulting in a hardlockup: Core - Debugging Information for Hardlockup core(7) Call trace: queued_spin_lock_slowpath+0x94/0x488 _raw_spin_lock+0x64/0x6c gether_disconnect+0x19c/0x1e8 ncm_set_alt+0x68/0x1a0 composite_setup+0x6a0/0xc50 The root cause is that the clearing of dev->port_usb in gether_disconnect() is delayed until the end of the function. Move the clearing of dev->port_usb to the very beginning of gether_disconnect() while holding dev->lock. This cuts off the link immediately, ensuring eth_stop() will see dev->port_usb as NULL and safely bail out. Fixes: 2b3d942c4878 ("usb ethernet gadget: split out network core") Cc: stable Signed-off-by: Kuen-Han Tsai Link: https://patch.msgid.link/20260311-gether-disconnect-npe-v1-1-454966adf7c7@google.com Signed-off-by: Greg Kroah-Hartman commit 63dc317dfcd3faffd082c2bf3080f9ad070273da Author: Zilin Guan Date: Thu Jan 22 03:26:44 2026 +0000 ice: Fix memory leak in ice_set_ringparam() [ Upstream commit fe868b499d16f55bbeea89992edb98043c9de416 ] In ice_set_ringparam, tx_rings and xdp_rings are allocated before rx_rings. If the allocation of rx_rings fails, the code jumps to the done label leaking both tx_rings and xdp_rings. Furthermore, if the setup of an individual Rx ring fails during the loop, the code jumps to the free_tx label which releases tx_rings but leaks xdp_rings. Fix this by introducing a free_xdp label and updating the error paths to ensure both xdp_rings and tx_rings are properly freed if rx_rings allocation or setup fails. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: fcea6f3da546 ("ice: Add stats and ethtool support") Fixes: efc2214b6047 ("ice: Add support for XDP") Signed-off-by: Zilin Guan Reviewed-by: Paul Menzel Reviewed-by: Aleksandr Loktionov Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 7d581e2534693910872ee1553a27be47f487a7f7 Author: Aditya Garg Date: Tue Apr 7 16:38:01 2026 +0530 HID: appletb-kbd: add .resume method in PM commit 1965445e13c09b79932ca8154977b4408cb9610c upstream. Upon resuming from suspend, the Touch Bar driver was missing a resume method in order to restore the original mode the Touch Bar was on before suspending. It is the same as the reset_resume method. Cc: stable@vger.kernel.org Signed-off-by: Aditya Garg Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit f4e608fe12b7ac6a4a57176ab0296bb5a110a078 Author: Nathan Rebello Date: Fri Mar 13 18:24:53 2026 -0400 usb: typec: ucsi: validate connector number in ucsi_notify_common() commit d2d8c17ac01a1b1f638ea5d340a884ccc5015186 upstream. The connector number extracted from CCI via UCSI_CCI_CONNECTOR() is a 7-bit field (0-127) that is used to index into the connector array in ucsi_connector_change(). However, the array is only allocated for the number of connectors reported by the device (typically 2-4 entries). A malicious or malfunctioning device could report an out-of-range connector number in the CCI, causing an out-of-bounds array access in ucsi_connector_change(). Add a bounds check in ucsi_notify_common(), the central point where CCI is parsed after arriving from hardware, so that bogus connector numbers are rejected before they propagate further. Fixes: bdc62f2bae8f ("usb: typec: ucsi: Simplified registration and I/O API") Cc: stable Reviewed-by: Heikki Krogerus Signed-off-by: Nathan Rebello Link: https://patch.msgid.link/20260313222453.123-1-nathan.c.rebello@gmail.com Signed-off-by: Greg Kroah-Hartman commit cc300853b9ebab5afc9e70a485ac6cc0b914caf2 Author: Sebastian Urban Date: Sun Mar 15 16:10:45 2026 +0100 usb: gadget: dummy_hcd: fix premature URB completion when ZLP follows partial transfer commit f50200dd44125e445a6164e88c217472fa79cdbc upstream. When a gadget request is only partially transferred in transfer() because the per-frame bandwidth budget is exhausted, the loop advances to the next queued request. If that next request is a zero-length packet (ZLP), len evaluates to zero and the code takes the unlikely(len == 0) path, which sets is_short = 1. This bypasses the bandwidth guard ("limit < ep->ep.maxpacket && limit < len") that lives in the else branch and would otherwise break out of the loop for non-zero requests. The is_short path then completes the URB before all data from the first request has been transferred. Reproducer (bulk IN, high speed): Device side (FunctionFS with Linux AIO): 1. Queue a 65024-byte write via io_submit (127 * 512, i.e. a multiple of the HS bulk max packet size). 2. Immediately queue a zero-length write (ZLP) via io_submit. Host side: 3. Submit a 65536-byte bulk IN URB. Expected: URB completes with actual_length = 65024. Actual: URB completes with actual_length = 53248, losing 11776 bytes that leak into subsequent URBs. At high speed the per-frame budget is 53248 bytes (512 * 13 * 8). The 65024-byte request exhausts this budget after 53248 bytes, leaving the request incomplete (req->req.actual < req->req.length). Neither the request nor the URB is finished, and rescan is 0, so the loop advances to the ZLP. For the ZLP, dev_len = 0, so len = min(12288, 0) = 0, taking the unlikely(len == 0) path and setting is_short = 1. The is_short handler then sets *status = 0, completing the URB with only 53248 of the expected 65024 bytes. Fix this by breaking out of the loop when the current request has remaining data (req->req.actual < req->req.length). The request resumes on the next timer tick, preserving correct data ordering. Signed-off-by: Sebastian Urban Cc: stable Reviewed-by: Alan Stern Link: https://patch.msgid.link/20260315151045.1155850-1-surban@surban.net Signed-off-by: Greg Kroah-Hartman commit 5687a09776069bd915560021c9728ca528440128 Author: Alan Stern Date: Sun Mar 15 14:31:00 2026 -0400 USB: dummy-hcd: Fix interrupt synchronization error commit 2ca9e46f8f1f5a297eb0ac83f79d35d5b3a02541 upstream. This fixes an error in synchronization in the dummy-hcd driver. The error has a somewhat involved history. The synchronization mechanism was introduced by commit 7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous synchronization change"), which added an emulated "interrupts enabled" flag together with code emulating synchronize_irq() (it waits until all current handler callbacks have returned). But the emulated interrupt-disable occurred too late, after the driver containing the handler callback routines had been told that it was unbound and no more callbacks would occur. Commit 4a5d797a9f9c ("usb: gadget: dummy_hcd: fix gpf in gadget_setup") tried to fix this by moving the synchronize_irq() emulation code from dummy_stop() to dummy_pullup(), which runs before the unbind callback. There still were races, though, because the emulated interrupt-disable still occurred too late. It couldn't be moved to dummy_pullup(), because that routine can be called for reasons other than an impending unbind. Therefore commits 7dc0c55e9f30 ("USB: UDC core: Add udc_async_callbacks gadget op") and 04145a03db9d ("USB: UDC: Implement udc_async_callbacks in dummy-hcd") added an API allowing the UDC core to tell dummy-hcd exactly when emulated interrupts and their callbacks should be disabled. That brings us to the current state of things, which is still wrong because the emulated synchronize_irq() occurs before the emulated interrupt-disable! That's no good, beause it means that more emulated interrupts can occur after the synchronize_irq() emulation has run, leading to the possibility that a callback handler may be running when the gadget driver is unbound. To fix this, we have to move the synchronize_irq() emulation code yet again, to the dummy_udc_async_callbacks() routine, which takes care of enabling and disabling emulated interrupt requests. The synchronization will now run immediately after emulated interrupts are disabled, which is where it belongs. Signed-off-by: Alan Stern Fixes: 04145a03db9d ("USB: UDC: Implement udc_async_callbacks in dummy-hcd") Cc: stable Link: https://patch.msgid.link/c7bc93fe-4241-4d04-bd56-27c12ba35c97@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman commit efbd9441f1e769a7aae1813d497cec09cbdff031 Author: Alan Stern Date: Sun Mar 15 14:30:43 2026 -0400 USB: dummy-hcd: Fix locking/synchronization error commit 616a63ff495df12863692ab3f9f7b84e3fa7a66d upstream. Syzbot testing was able to provoke an addressing exception and crash in the usb_gadget_udc_reset() routine in drivers/usb/gadgets/udc/core.c, resulting from the fact that the routine was called with a second ("driver") argument of NULL. The bad caller was set_link_state() in dummy_hcd.c, and the problem arose because of a race between a USB reset and driver unbind. These sorts of races were not supposed to be possible; commit 7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous synchronization change"), along with a few followup commits, was written specifically to prevent them. As it turns out, there are (at least) two errors remaining in the code. Another patch will address the second error; this one is concerned with the first. The error responsible for the syzbot crash occurred because the stop_activity() routine will sometimes drop and then re-acquire the dum->lock spinlock. A call to stop_activity() occurs in set_link_state() when handling an emulated USB reset, after the test of dum->ints_enabled and before the increment of dum->callback_usage. This allowed another thread (doing a driver unbind) to sneak in and grab the spinlock, and then clear dum->ints_enabled and dum->driver. Normally this other thread would have to wait for dum->callback_usage to go down to 0 before it would clear dum->driver, but in this case it didn't have to wait since dum->callback_usage had not yet been incremented. The fix is to increment dum->callback_usage _before_ calling stop_activity() instead of after. Then the thread doing the unbind will not clear dum->driver until after the call to usb_gadget_udc_reset() safely returns and dum->callback_usage has been decremented again. Signed-off-by: Alan Stern Reported-by: syzbot+19bed92c97bee999e5db@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/68fc7c9c.050a0220.346f24.023c.GAE@google.com/ Tested-by: syzbot+19bed92c97bee999e5db@syzkaller.appspotmail.com Fixes: 7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous synchronization change") Cc: stable Link: https://patch.msgid.link/46135f42-fdbe-46b5-aac0-6ca70492af15@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman commit cd9c6fcd1cf13048dce053dedb7dcb0bc8fbb9f8 Author: Konrad Dybcio Date: Mon Mar 9 10:39:49 2026 +0100 thunderbolt: Fix property read in nhi_wake_supported() commit 73a505dc48144ec72e25874e2b2a72487b02d3bc upstream. device_property_read_foo() returns 0 on success and only then modifies 'val'. Currently, val is left uninitialized if the aforementioned function returns non-zero, making nhi_wake_supported() return true almost always (random != 0) if the property is not present in device firmware. Invert the check to make it make sense. Fixes: 3cdb9446a117 ("thunderbolt: Add support for Intel Ice Lake") Cc: stable@vger.kernel.org Signed-off-by: Konrad Dybcio Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 15f0c2d9eebc1a5cbdb4a515e2aa5ed119fbc6ee Author: Andrei Kuchynski Date: Tue Mar 24 10:30:12 2026 +0000 usb: typec: thunderbolt: Set enter_vdo during initialization commit 3b8ae9817686efb3ea789ca9d4efdff2ce9c1c04 upstream. In the current implementation, if a cable's alternate mode enter operation is not supported, the tbt->plug[TYPEC_PLUG_SOP_P] pointer is cleared by the time tbt_enter_mode() is called. This prevents the driver from identifying the cable's VDO. As a result, the Thunderbolt connection falls back to the default TBT_CABLE_USB3_PASSIVE speed, even if the cable supports higher speeds. To ensure the correct VDO value is used during mode entry, calculate and store the enter_vdo earlier during the initialization phase in tbt_ready(). Cc: stable Fixes: 100e25738659 ("usb: typec: Add driver for Thunderbolt 3 Alternate Mode") Tested-by: Madhu M Signed-off-by: Andrei Kuchynski Reviewed-by: Heikki Krogerus Reviewed-by: Benson Leung Link: https://patch.msgid.link/20260324103012.1417616-1-akuchynski@chromium.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit acea446ba4f42bece77ca7e940510b231fd03a98 Author: Xingjing Deng Date: Sat Jan 31 14:55:39 2026 +0800 misc: fastrpc: check qcom_scm_assign_mem() return in rpmsg_probe commit 6a502776f4a4f80fb839b22f12aeaf0267fca344 upstream. In the SDSP probe path, qcom_scm_assign_mem() is used to assign the reserved memory to the configured VMIDs, but its return value was not checked. Fail the probe if the SCM call fails to avoid continuing with an unexpected/incorrect memory permission configuration. This issue was found by an in-house analysis workflow that extracts AST-based information and runs static checks, with LLM assistance for triage, and was confirmed by manual code review. No hardware testing was performed. Fixes: c3c0363bc72d4 ("misc: fastrpc: support complete DMA pool access to the DSP") Cc: stable@vger.kernel.org # 6.11-rc1 Signed-off-by: Xingjing Deng Reviewed-by: Dmitry Baryshkov Link: https://patch.msgid.link/20260131065539.2124047-1-xjdeng@buaa.edu.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 3a164f640953cc982804746e772d379171aff5c6 Author: Xingjing Deng Date: Fri Jan 30 07:41:40 2026 +0800 misc: fastrpc: possible double-free of cctx->remote_heap commit ba2c83167b215da30fa2aae56b140198cf8d8408 upstream. fastrpc_init_create_static_process() may free cctx->remote_heap on the err_map path but does not clear the pointer. Later, fastrpc_rpmsg_remove() frees cctx->remote_heap again if it is non-NULL, which can lead to a double-free if the INIT_CREATE_STATIC ioctl hits the error path and the rpmsg device is subsequently removed/unbound. Clear cctx->remote_heap after freeing it in the error path to prevent the later cleanup from freeing it again. This issue was found by an in-house analysis workflow that extracts AST-based information and runs static checks, with LLM assistance for triage, and was confirmed by manual code review. No hardware testing was performed. Fixes: 0871561055e66 ("misc: fastrpc: Add support for audiopd") Cc: stable@vger.kernel.org # 6.2+ Signed-off-by: Xingjing Deng Reviewed-by: Dmitry Baryshkov Link: https://patch.msgid.link/20260129234140.410983-1-xjdeng@buaa.edu.cn Signed-off-by: Greg Kroah-Hartman commit c4c7219e93319bba9ba0765dee597784c78f63c5 Author: Rafael J. Wysocki Date: Wed Apr 1 16:33:53 2026 +0200 thermal: core: Fix thermal zone device registration error path commit 9e07e3b81807edd356e1f794cffa00a428eff443 upstream. If thermal_zone_device_register_with_trips() fails after registering a thermal zone device, it needs to wait for the tz->removal completion like thermal_zone_device_unregister(), in case user space has managed to take a reference to the thermal zone device's kobject, in which case thermal_release() may not be called by the error path itself and tz may be freed prematurely. Add the missing wait_for_completion() call to the thermal zone device registration error path. Fixes: 04e6ccfc93c5 ("thermal: core: Fix NULL pointer dereference in zone registration error path") Signed-off-by: Rafael J. Wysocki Cc: All applicable Reviewed-by: Lukasz Luba Tested-by: Lukasz Luba Link: https://patch.msgid.link/2849815.mvXUDI8C0e@rafael.j.wysocki Signed-off-by: Greg Kroah-Hartman commit 2dbe93f344f10b432b95a23304006be805c097a1 Author: Rafael J. Wysocki Date: Fri Mar 27 10:49:52 2026 +0100 thermal: core: Address thermal zone removal races with resume commit 45b859b0728267a6199ee5002d62e6c6f3e8c89d upstream. Since thermal_zone_pm_complete() and thermal_zone_device_resume() re-initialize the poll_queue delayed work for the given thermal zone, the cancel_delayed_work_sync() in thermal_zone_device_unregister() may miss some already running work items and the thermal zone may be freed prematurely [1]. There are two failing scenarios that both start with running thermal_pm_notify_complete() right before invoking thermal_zone_device_unregister() for one of the thermal zones. In the first scenario, there is a work item already running for the given thermal zone when thermal_pm_notify_complete() calls thermal_zone_pm_complete() for that thermal zone and it continues to run when thermal_zone_device_unregister() starts. Since the poll_queue delayed work has been re-initialized by thermal_pm_notify_complete(), the running work item will be missed by the cancel_delayed_work_sync() in thermal_zone_device_unregister() and if it continues to run past the freeing of the thermal zone object, a use-after-free will occur. In the second scenario, thermal_zone_device_resume() queued up by thermal_pm_notify_complete() runs right after the thermal_zone_exit() called by thermal_zone_device_unregister() has returned. The poll_queue delayed work is re-initialized by it before cancel_delayed_work_sync() is called by thermal_zone_device_unregister(), so it may continue to run after the freeing of the thermal zone object, which also leads to a use-after-free. Address the first failing scenario by ensuring that no thermal work items will be running when thermal_pm_notify_complete() is called. For this purpose, first move the cancel_delayed_work() call from thermal_zone_pm_complete() to thermal_zone_pm_prepare() to prevent new work from entering the workqueue going forward. Next, switch over to using a dedicated workqueue for thermal events and update the code in thermal_pm_notify() to flush that workqueue after thermal_pm_notify_prepare() has returned which will take care of all leftover thermal work already on the workqueue (that leftover work would do nothing useful anyway because all of the thermal zones have been flagged as suspended). The second failing scenario is addressed by adding a tz->state check to thermal_zone_device_resume() to prevent it from re-initializing the poll_queue delayed work if the thermal zone is going away. Note that the above changes will also facilitate relocating the suspend and resume of thermal zones closer to the suspend and resume of devices, respectively. Fixes: 5a5efdaffda5 ("thermal: core: Resume thermal zones asynchronously") Reported-by: syzbot+3b3852c6031d0f30dfaf@syzkaller.appspotmail.com Closes: https://syzbot.org/bug?extid=3b3852c6031d0f30dfaf Reported-by: Mauricio Faria de Oliveira Closes: https://lore.kernel.org/linux-pm/20260324-thermal-core-uaf-init_delayed_work-v1-1-6611ae76a8a1@igalia.com/ [1] Signed-off-by: Rafael J. Wysocki Reviewed-by: Mauricio Faria de Oliveira Tested-by: Mauricio Faria de Oliveira Reviewed-by: Lukasz Luba Cc: All applicable Link: https://patch.msgid.link/6267615.lOV4Wx5bFT@rafael.j.wysocki Signed-off-by: Greg Kroah-Hartman commit f0cf9c7b7c281956cc0dec163132cd96f76e1d60 Author: Tzung-Bi Shih Date: Thu Feb 5 09:28:40 2026 +0000 gpio: Fix resource leaks on errors in gpiochip_add_data_with_key() commit 16fdabe143fce2cbf89139677728e17e21b46c28 upstream. Since commit aab5c6f20023 ("gpio: set device type for GPIO chips"), `gdev->dev.release` is unset. As a result, the reference count to `gdev->dev` isn't dropped on the error handling paths. Drop the reference on errors. Also reorder the instructions to make the error handling simpler. Now gpiochip_add_data_with_key() roughly looks like: >>> Some memory allocation. Go to ERR ZONE 1 on errors. >>> device_initialize(). gpiodev_release() takes over the responsibility for freeing the resources of `gdev->dev`. The subsequent error handling paths shouldn't go through ERR ZONE 1 again which leads to double free. >>> Some initialization mainly on `gdev`. >>> The rest of initialization. Go to ERR ZONE 2 on errors. >>> Chip registration success and exit. >>> ERR ZONE 2. gpio_device_put() and exit. >>> ERR ZONE 1. Cc: stable@vger.kernel.org Fixes: aab5c6f20023 ("gpio: set device type for GPIO chips") Reviewed-by: Linus Walleij Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260205092840.2574840-1-tzungbi@kernel.org Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 70b6e2e015030ec8c132112a918a19c44041910a Author: Shenwei Wang Date: Tue Mar 24 14:21:29 2026 -0500 gpio: mxc: map Both Edge pad wakeup to Rising Edge commit c720fb57d56274213d027b3c5ab99080cf62a306 upstream. Suspend may fail on i.MX8QM when Falling Edge is used as a pad wakeup trigger due to a hardware bug in the detection logic. Since the hardware does not support Both Edge wakeup, remap requests for Both Edge to Rising Edge by default to avoid hitting this issue. A warning is emitted when Falling Edge is selected on i.MX8QM. Fixes: f60c9eac54af ("gpio: mxc: enable pad wakeup on i.MX8x platforms") cc: stable@vger.kernel.org Reviewed-by: Peng Fan Signed-off-by: Shenwei Wang Link: https://patch.msgid.link/20260324192129.2797237-1-shenwei.wang@nxp.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 72c43eb2e334febe93018cfb68ae828f55c6e49e Author: Changwoo Min Date: Thu Apr 2 11:31:50 2026 +0900 sched_ext: Fix is_bpf_migration_disabled() false negative on non-PREEMPT_RCU commit 0c4a59df370bea245695c00aaae6ae75747139bd upstream. Since commit 8e4f0b1ebcf2 ("bpf: use rcu_read_lock_dont_migrate() for trampoline.c"), the BPF prolog (__bpf_prog_enter) calls migrate_disable() only when CONFIG_PREEMPT_RCU is enabled, via rcu_read_lock_dont_migrate(). Without CONFIG_PREEMPT_RCU, the prolog never touches migration_disabled, so migration_disabled == 1 always means the task is truly migration-disabled regardless of whether it is the current task. The old unconditional p == current check was a false negative in this case, potentially allowing a migration-disabled task to be dispatched to a remote CPU and triggering scx_error in task_can_run_on_remote_rq(). Only apply the p == current disambiguation when CONFIG_PREEMPT_RCU is enabled, where the ambiguity with the BPF prolog still exists. Fixes: 8e4f0b1ebcf2 ("bpf: use rcu_read_lock_dont_migrate() for trampoline.c") Cc: stable@vger.kernel.org # v6.18+ Link: https://lore.kernel.org/lkml/20250821090609.42508-8-dongml2@chinatelecom.cn/ Signed-off-by: Changwoo Min Reviewed-by: Andrea Righi Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit d2703b4f8fb7cc6f0dfdb2dc2359cc46189e7357 Author: Guangshuo Li Date: Wed Apr 1 10:45:35 2026 +0800 cpufreq: governor: fix double free in cpufreq_dbs_governor_init() error path commit 6dcf9d0064ce2f3e3dfe5755f98b93abe6a98e1e upstream. When kobject_init_and_add() fails, cpufreq_dbs_governor_init() calls kobject_put(&dbs_data->attr_set.kobj). The kobject release callback cpufreq_dbs_data_release() calls gov->exit(dbs_data) and kfree(dbs_data), but the current error path then calls gov->exit(dbs_data) and kfree(dbs_data) again, causing a double free. Keep the direct kfree(dbs_data) for the gov->init() failure path, but after kobject_init_and_add() has been called, let kobject_put() handle the cleanup through cpufreq_dbs_data_release(). Fixes: 4ebe36c94aed ("cpufreq: Fix kobject memleak") Signed-off-by: Guangshuo Li Reviewed-by: Zhongqiu Han Acked-by: Viresh Kumar Cc: All applicable Link: https://patch.msgid.link/20260401024535.1395801-1-lgs201920130244@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 65a5847e1a6c9f9962f5991a467b5c7981a15c35 Author: Srujana Challa Date: Thu Mar 26 19:53:44 2026 +0530 virtio_net: clamp rss_max_key_size to NETDEV_RSS_KEY_LEN commit b4e5f04c58a29c499faa85d12952ca9a4faf1cb9 upstream. rss_max_key_size in the virtio spec is the maximum key size supported by the device, not a mandatory size the driver must use. Also the value 40 is a spec minimum, not a spec maximum. The current code rejects RSS and can fail probe when the device reports a larger rss_max_key_size than the driver buffer limit. Instead, clamp the effective key length to min(device rss_max_key_size, NETDEV_RSS_KEY_LEN) and keep RSS enabled. This keeps probe working on devices that advertise larger maximum key sizes while respecting the netdev RSS key buffer size limit. Fixes: 3f7d9c1964fc ("virtio_net: Add hash_key_length check") Cc: stable@vger.kernel.org Signed-off-by: Srujana Challa Acked-by: Michael S. Tsirkin Link: https://patch.msgid.link/20260326142344.1171317-1-schalla@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5dff799c677152dde963c3917bacd9127b03e145 Author: Sven Eckelmann (Plasma Cloud) Date: Tue Mar 24 09:36:01 2026 +0100 net: ethernet: mtk_ppe: avoid NULL deref when gmac0 is disabled commit 976ff48c2ac6e6b25b01428c9d7997bcd0fb2949 upstream. If the gmac0 is disabled, the precheck for a valid ingress device will cause a NULL pointer deref and crash the system. This happens because eth->netdev[0] will be NULL but the code will directly try to access netdev_ops. Instead of just checking for the first net_device, it must be checked if any of the mtk_eth net_devices is matching the netdev_ops of the ingress device. Cc: stable@vger.kernel.org Fixes: 73cfd947dbdb ("net: ethernet: mtk_eth_soc: ppe: prevent ppe update for non-mtk devices") Signed-off-by: Sven Eckelmann (Plasma Cloud) Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260324-wed-crash-gmac0-disabled-v1-1-3bc388aee565@simonwunderlich.de Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8351d18989c8642fc53e2e12d94e42314a39b078 Author: Yufan Chen Date: Sun Mar 29 00:32:57 2026 +0800 net: ftgmac100: fix ring allocation unwind on open failure commit c0fd0fe745f5e8c568d898cd1513d0083e46204a upstream. ftgmac100_alloc_rings() allocates rx_skbs, tx_skbs, rxdes, txdes, and rx_scratch in stages. On intermediate failures it returned -ENOMEM directly, leaking resources allocated earlier in the function. Rework the failure path to use staged local unwind labels and free allocated resources in reverse order before returning -ENOMEM. This matches common netdev allocation cleanup style. Fixes: d72e01a0430f ("ftgmac100: Use a scratch buffer for failed RX allocations") Cc: stable@vger.kernel.org Signed-off-by: Yufan Chen Link: https://patch.msgid.link/20260328163257.60836-1-yufan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit eddfce70a6f3107d1679b0c2fcbeb96b593bd679 Author: Yang Yang Date: Thu Mar 26 03:44:41 2026 +0000 vxlan: validate ND option lengths in vxlan_na_create commit afa9a05e6c4971bd5586f1b304e14d61fb3d9385 upstream. vxlan_na_create() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload. Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address. Fixes: 4b29dba9c085 ("vxlan: fix nonfunctional neigh_reduce()") Cc: stable@vger.kernel.org Reported-by: Yifan Wu Reported-by: Juefei Pu Tested-by: Ao Zhou Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Signed-off-by: Yang Yang Reviewed-by: Ido Schimmel Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260326034441.2037420-4-n05ec@lzu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3aea268b6d5cde3b087df9eeecc3bc620aa09513 Author: Eric Biggers Date: Mon Mar 16 13:21:19 2026 -0700 crypto: tegra - Add missing CRYPTO_ALG_ASYNC commit 4b56770d345524fc2acc143a2b85539cf7d74bc1 upstream. The tegra crypto driver failed to set the CRYPTO_ALG_ASYNC on its asynchronous algorithms, causing the crypto API to select them for users that request only synchronous algorithms. This causes crashes (at least). Fix this by adding the flag like what the other drivers do. Also remove the unnecessary CRYPTO_ALG_TYPE_* flags, since those just get ignored and overridden by the registration function anyway. Reported-by: Zorro Lang Closes: https://lore.kernel.org/r/20260314080937.pghb4aa7d4je3mhh@dell-per750-06-vm-08.rhts.eng.pek2.redhat.com Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver") Cc: stable@vger.kernel.org Cc: Akhil R Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 6562290225c197e2e193a53de2a517815288dcd1 Author: Cosmin Tanislav Date: Fri Jan 30 14:23:53 2026 +0200 counter: rz-mtu3-cnt: do not use struct rz_mtu3_channel's dev member commit 2932095c114b98cbb40ccf34fc00d613cb17cead upstream. The counter driver can use HW channels 1 and 2, while the PWM driver can use HW channels 0, 1, 2, 3, 4, 6, 7. The dev member is assigned both by the counter driver and the PWM driver for channels 1 and 2, to their own struct device instance, overwriting the previous value. The sub-drivers race to assign their own struct device pointer to the same struct rz_mtu3_channel's dev member. The dev member of struct rz_mtu3_channel is used by the counter sub-driver for runtime PM. Depending on the probe order of the counter and PWM sub-drivers, the dev member may point to the wrong struct device instance, causing the counter sub-driver to do runtime PM actions on the wrong device. To fix this, use the parent pointer of the counter, which is assigned during probe to the correct struct device, not the struct device pointer inside the shared struct rz_mtu3_channel. Cc: stable@vger.kernel.org Fixes: 0be8907359df ("counter: Add Renesas RZ/G2L MTU3a counter driver") Signed-off-by: Cosmin Tanislav Link: https://lore.kernel.org/r/20260130122353.2263273-6-cosmin-gabriel.tanislav.xa@renesas.com Signed-off-by: William Breathitt Gray Signed-off-by: Greg Kroah-Hartman commit e07237df8538b0ae98dce112e4f6db093d767f80 Author: Cosmin Tanislav Date: Fri Jan 30 14:23:52 2026 +0200 counter: rz-mtu3-cnt: prevent counter from being toggled multiple times commit 67c3f99bed6f422ba343d2b70a2eeeccdfd91bef upstream. Runtime PM counter is incremented / decremented each time the sysfs enable file is written to. If user writes 0 to the sysfs enable file multiple times, runtime PM usage count underflows, generating the following message. rz-mtu3-counter rz-mtu3-counter.0: Runtime PM usage count underflow! At the same time, hardware registers end up being accessed with clocks off in rz_mtu3_terminate_counter() to disable an already disabled channel. If user writes 1 to the sysfs enable file multiple times, runtime PM usage count will be incremented each time, requiring the same number of 0 writes to get it back to 0. If user writes 0 to the sysfs enable file while PWM is in progress, PWM is stopped without counter being the owner of the underlying MTU3 channel. Check against the cached count_is_enabled value and exit if the user is trying to set the same enable value. Cc: stable@vger.kernel.org Fixes: 0be8907359df ("counter: Add Renesas RZ/G2L MTU3a counter driver") Signed-off-by: Cosmin Tanislav Link: https://lore.kernel.org/r/20260130122353.2263273-5-cosmin-gabriel.tanislav.xa@renesas.com Signed-off-by: William Breathitt Gray Signed-off-by: Greg Kroah-Hartman commit bbb6c37c7a483c912ff0221ee92eaa9ca687b045 Author: Nicolas Pitre Date: Fri Mar 27 23:09:47 2026 -0400 vt: resize saved unicode buffer on alt screen exit after resize commit 3ddbea7542ae529c1a88ef9a8b1ce169126211f6 upstream. Instead of discarding the saved unicode buffer when the console was resized while in the alternate screen, resize it to the current dimensions using vc_uniscr_copy_area() to preserve its content. This properly restores the unicode screen on alt screen exit rather than lazily rebuilding it from a lossy reverse glyph translation. On allocation failure the stale buffer is freed and vc_uni_lines is set to NULL so it gets lazily rebuilt via vc_uniscr_check() when next needed. Fixes: 40014493cece ("vt: discard stale unicode buffer on alt screen exit after resize") Cc: stable Signed-off-by: Nicolas Pitre Link: https://patch.msgid.link/3nsr334n-079q-125n-7807-n4nq818758ns@syhkavp.arg Signed-off-by: Greg Kroah-Hartman commit 891d790fdb5c96c6e1d2841e06ee6c360f2d1288 Author: Liav Mordouch Date: Fri Mar 27 20:02:04 2026 +0300 vt: discard stale unicode buffer on alt screen exit after resize commit 40014493cece72a0be5672cd86763e53fb3ec613 upstream. When enter_alt_screen() saves vc_uni_lines into vc_saved_uni_lines and sets vc_uni_lines to NULL, a subsequent console resize via vc_do_resize() skips reallocating the unicode buffer because vc_uni_lines is NULL. However, vc_saved_uni_lines still points to the old buffer allocated for the original dimensions. When leave_alt_screen() later restores vc_saved_uni_lines, the buffer dimensions no longer match vc_rows/vc_cols. Any operation that iterates over the unicode buffer using the current dimensions (e.g. csi_J clearing the screen) will access memory out of bounds, causing a kernel oops: BUG: unable to handle page fault for address: 0x0000002000000020 RIP: 0010:csi_J+0x133/0x2d0 The faulting address 0x0000002000000020 is two adjacent u32 space characters (0x20) interpreted as a pointer, read from the row data area past the end of the 25-entry pointer array in a buffer allocated for 80x25 but accessed with 240x67 dimensions. Fix this by checking whether the console dimensions changed while in the alternate screen. If they did, free the stale saved buffer instead of restoring it. The unicode screen will be lazily rebuilt via vc_uniscr_check() when next needed. Fixes: 5eb608319bb5 ("vt: save/restore unicode screen buffer for alternate screen") Cc: stable Tested-by: Liav Mordouch Signed-off-by: Liav Mordouch Reviewed-by: Nicolas Pitre Link: https://patch.msgid.link/20260327170204.29706-1-liavmordouch@gmail.com Signed-off-by: Greg Kroah-Hartman commit 554d005d5161108cd3ee8108ed990f5a8dca2d8c Author: Dave Penkler Date: Mon Feb 2 10:47:55 2026 +0100 gpib: Fix fluke driver s390 compile issue commit 579af7204d762587f9cce0d6236a710a771f1f6f upstream. The following errors were reported for a s390 randconfig build of the fluke gpib driver: >> drivers/gpib/eastwood/fluke_gpib.c:1002:23: error: call to undeclared function 'ioremap'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 1002 | nec_priv->mmiobase = ioremap(e_priv->gpib_iomem_res->start, | ^ >> drivers/gpib/eastwood/fluke_gpib.c:1002:21: error: incompatible integer to pointer conversion assigning to 'void *' from 'int' [-Wint-conversion] 1002 | nec_priv->mmiobase = ioremap(e_priv->gpib_iomem_res->start, | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1003 | resource_size(e_priv->gpib_iomem_res)); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpib/eastwood/fluke_gpib.c:1036:33: error: incompatible integer to pointer conversion assigning to 'void *' from 'int' [-Wint-conversion] 1036 | e_priv->write_transfer_counter = ioremap(e_priv->write_transfer_counter_res->start, | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1037 | resource_size(e_priv->write_transfer_counter_res)); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Add HAS_IOMEM dependency to Kconfig for fluke driver option Suggested-by: Arnd Bergmann Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202601221748.AFAqHieJ-lkp@intel.com/ Fixes: baf8855c9160 ("staging: gpib: fix address space mixup") Cc: stable Signed-off-by: Dave Penkler Link: https://patch.msgid.link/20260202094755.4259-1-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman commit 68ca0eea0af02bed36c5e2c13e9fa1647c31a7d4 Author: Yifan Wu Date: Mon Mar 30 14:39:24 2026 -0700 netfilter: ipset: drop logically empty buckets in mtype_del commit 9862ef9ab0a116c6dca98842aab7de13a252ae02 upstream. mtype_del() counts empty slots below n->pos in k, but it only drops the bucket when both n->pos and k are zero. This misses buckets whose live entries have all been removed while n->pos still points past deleted slots. Treat a bucket as empty when all positions below n->pos are unused and release it directly instead of shrinking it further. Fixes: 8af1c6fbd923 ("netfilter: ipset: Fix forceadd evaluation path") Cc: stable@vger.kernel.org Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Yifan Wu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Reviewed-by: Phil Sutter Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 784ed4abded1ca4b525fa4cade8b02f8c5d2a087 Author: Ivan Vera Date: Fri Mar 27 13:16:45 2026 +0000 nvmem: zynqmp_nvmem: Fix buffer size in DMA and memcpy commit f9b88613ff402aa6fe8fd020573cb95867ae947e upstream. Buffer size used in dma allocation and memcpy is wrong. It can lead to undersized DMA buffer access and possible memory corruption. use correct buffer size in dma_alloc_coherent and memcpy. Fixes: 737c0c8d07b5 ("nvmem: zynqmp_nvmem: Add support to access efuse") Cc: stable@vger.kernel.org Signed-off-by: Ivan Vera Signed-off-by: Harish Ediga Signed-off-by: Harsh Jain Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260327131645.3025781-3-srini@kernel.org Signed-off-by: Greg Kroah-Hartman commit 0c94b84b6ef5113b83bbb758fad304e47c65bd52 Author: Christian Eggers Date: Fri Mar 27 13:16:44 2026 +0000 nvmem: imx: assign nvmem_cell_info::raw_len commit 48b5163c957548f5854f14c90bfdedc33afbea3c upstream. Avoid getting error messages at startup like the following on i.MX6ULL: nvmem imx-ocotp0: cell mac-addr raw len 6 unaligned to nvmem word size 4 nvmem imx-ocotp0: cell mac-addr raw len 6 unaligned to nvmem word size 4 This shouldn't cause any functional change as this alignment would otherwise be done in nvmem_cell_info_to_nvmem_cell_entry_nodup(). Cc: stable@vger.kernel.org Fixes: 13bcd440f2ff ("nvmem: core: verify cell's raw_len") Signed-off-by: Christian Eggers Signed-off-by: Fabio Estevam Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260327131645.3025781-2-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 5a8f2e95f9a191ff387b0e184d3e45e06b3a84f9 Author: Thomas Richter Date: Fri Mar 6 13:50:31 2026 +0100 s390/cpum_sf: Cap sampling rate to prevent lsctl exception commit 57ad0d4a00f5d3e80f33ba2da8d560c73d83dc22 upstream. commit fcc43a7e294f ("s390/configs: Set HZ=1000") changed the interrupt frequency of the system. On machines with heavy load and many perf event overflows, this might lead to an exception. Dmesg displays these entries: [112.242542] cpum_sf: Loading sampling controls failed: op 1 err -22 One line per CPU online. The root cause is the CPU Measurement sampling facility overflow adjustment. Whenever an overflow (too much samples per tick) occurs, the sampling rate is adjusted and increased. This was done without observing the maximum sampling rate limit. When the current sampling interval is higher than the maximum sampling rate limit, the lsctl instruction raises an exception. The error messages is the result of such an exception. Observe the upper limit when the new sampling rate is recalculated. Cc: stable@vger.kernel.org Fixes: 39d4a501a9ef ("s390/cpum_sf: Adjust sampling interval to avoid hitting sample limits") Signed-off-by: Thomas Richter Reviewed-by: Sumanth Korikkar Reviewed-by: Hendrik Brueckner Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 586222c37d4027dbf60a604fbe820184fee7c1c9 Author: Harald Freudenberger Date: Thu Mar 19 09:06:52 2026 +0100 s390/zcrypt: Fix memory leak with CCA cards used as accelerator commit c8d46f17c2fc7d25c18e60c008928aecab26184d upstream. Tests showed that there is a memory leak if CCA cards are used as accelerator for clear key RSA requests (ME and CRT). With the last rework for the memory allocation the AP messages are allocated by ap_init_apmsg() but for some reason on two places (ME and CRT) the older allocation was still in place. So the first allocation simple was never freed. Fixes: 57db62a130ce ("s390/ap/zcrypt: Rework AP message buffer allocation") Reported-by: Yi Zhang Closes: https://lore.kernel.org/linux-s390/CAHj4cs9H67Uz0iVaRQv447p7JFPRPy3TKAT4=Y6_e=wSHCZM5w@mail.gmail.com/ Reported-by: Nadja Hariz Cc: stable@vger.kernel.org Reviewed-by: Ingo Franzki Reviewed-by: Holger Dengler Acked-by: Heiko Carstens Signed-off-by: Harald Freudenberger Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit a11f022db7d857d4bbaf140c2517833e1c9d65b4 Author: Emanuele Ghidoli Date: Fri Mar 13 14:52:31 2026 +0100 spi: cadence-qspi: Fix exec_mem_op error handling commit 59e1be1278f064d7172b00473b7e0c453cb1ec52 upstream. cqspi_exec_mem_op() increments the runtime PM usage counter before all refcount checks are performed. If one of these checks fails, the function returns without dropping the PM reference. Move the pm_runtime_resume_and_get() call after the refcount checks so that runtime PM is only acquired when the operation can proceed and drop the inflight_ops refcount if the PM resume fails. Cc: stable@vger.kernel.org Fixes: 7446284023e8 ("spi: cadence-quadspi: Implement refcount to handle unbind during busy") Signed-off-by: Emanuele Ghidoli Link: https://patch.msgid.link/20260313135236.46642-1-ghidoliemanuele@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit f5526abe978fdde35e76f97c7e5d667262389d6a Author: Xu Yang Date: Mon Mar 30 14:35:18 2026 +0800 dt-bindings: connector: add pd-disable dependency commit 269c26464dcf8b54b0dd9c333721c30ee44ae297 upstream. When Power Delivery is not supported, the source is unable to obtain the current capability from the Source PDO. As a result, typec-power-opmode needs to be added to advertise such capability. Acked-by: Conor Dooley Cc: stable Signed-off-by: Xu Yang Link: https://patch.msgid.link/20260330063518.719345-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman commit d266498da90d34a76ee07a6072a651e431bf661d Author: Conor Dooley Date: Tue Mar 3 11:24:06 2026 +0000 firmware: microchip: fail auto-update probe if no flash found commit c7596f9001e2b83293e3658e4e1addde69bb335d upstream. There's no point letting the driver probe if there is no flash, as trying to do a firmware upload will fail. Move the code that attempts to get the flash from firmware upload to probe, and let it emit a message to users stating why auto-update is not supported. The code currently could have a problem if there's a flash in devicetree, but the system controller driver fails to get a pointer to it from the mtd subsystem, which will cause mpfs_sys_controller_get_flash() to return an error. Check for errors and null, instead of just null, in the new clause. CC: stable@vger.kernel.org Fixes: ec5b0f1193ad4 ("firmware: microchip: add PolarFire SoC Auto Update support") Signed-off-by: Conor Dooley Signed-off-by: Greg Kroah-Hartman commit eae19cab44204537f79146f15a51811b13227c38 Author: Ian Abbott Date: Thu Feb 5 13:39:49 2026 +0000 comedi: me4000: Fix potential overrun of firmware buffer commit 3fb43a7a5b44713f892c58ead2e5f3a1bc9f4ee7 upstream. `me4000_xilinx_download()` loads the firmware that was requested by `request_firmware()`. It is possible for it to overrun the source buffer because it blindly trusts the file format. It reads a data stream length from the first 4 bytes into variable `file_length` and reads the data stream contents of length `file_length` from offset 16 onwards. Add a test to ensure that the supplied firmware is long enough to contain the header and the data stream. On failure, log an error and return `-EINVAL`. Note: The firmware loading was totally broken before commit ac584af59945 ("staging: comedi: me4000: fix firmware downloading"), but that is the most sensible target for this fix. Fixes: ac584af59945 ("staging: comedi: me4000: fix firmware downloading") Cc: stable Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260205133949.71722-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman commit a47ae40339c1048f519df33ff8840731720f57cb Author: Ian Abbott Date: Thu Feb 5 14:01:30 2026 +0000 comedi: me_daq: Fix potential overrun of firmware buffer commit cc797d4821c754c701d9714b58bea947e31dbbe0 upstream. `me2600_xilinx_download()` loads the firmware that was requested by `request_firmware()`. It is possible for it to overrun the source buffer because it blindly trusts the file format. It reads a data stream length from the first 4 bytes into variable `file_length` and reads the data stream contents of length `file_length` from offset 16 onwards. Although it checks that the supplied firmware is at least 16 bytes long, it does not check that it is long enough to contain the data stream. Add a test to ensure that the supplied firmware is long enough to contain the header and the data stream. On failure, log an error and return `-EINVAL`. Fixes: 85acac61096f9 ("Staging: comedi: add me_daq driver") Cc: stable Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260205140130.76697-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman commit 43c68a2c7cc35b7c2a83c285cb4ad3d472b8caa2 Author: Ian Abbott Date: Wed Jan 28 15:00:10 2026 +0000 comedi: ni_atmio16d: Fix invalid clean-up after failed attach commit 101ab946b79ad83b36d5cfd47de587492a80acf0 upstream. If the driver's COMEDI "attach" handler function (`atmio16d_attach()`) returns an error, the COMEDI core will call the driver's "detach" handler function (`atmio16d_detach()`) to clean up. This calls `reset_atmio16d()` unconditionally, but depending on where the error occurred in the attach handler, the device may not have been sufficiently initialized to call `reset_atmio16d()`. It uses `dev->iobase` as the I/O port base address and `dev->private` as the pointer to the COMEDI device's private data structure. `dev->iobase` may still be set to its initial value of 0, which would result in undesired writes to low I/O port addresses. `dev->private` may still be `NULL`, which would result in null pointer dereferences. Fix `atmio16d_detach()` by checking that `dev->private` is valid (non-null) before calling `reset_atmio16d()`. This implies that `dev->iobase` was set correctly since that is set up before `dev->private`. Fixes: 2323b276308a ("Staging: comedi: add ni_at_atmio16d driver") Cc: stable Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260128150011.5006-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman commit b89c026227712c367950bbae055a5b31073d3b30 Author: Ian Abbott Date: Wed Feb 25 13:24:27 2026 +0000 comedi: Reinit dev->spinlock between attachments to low-level drivers commit 4b9a9a6d71e3e252032f959fb3895a33acb5865c upstream. `struct comedi_device` is the main controlling structure for a COMEDI device created by the COMEDI subsystem. It contains a member `spinlock` containing a spin-lock that is initialized by the COMEDI subsystem, but is reserved for use by a low-level driver attached to the COMEDI device (at least since commit 25436dc9d84f ("Staging: comedi: remove RT code")). Some COMEDI devices (those created on initialization of the COMEDI subsystem when the "comedi.comedi_num_legacy_minors" parameter is non-zero) can be attached to different low-level drivers over their lifetime using the `COMEDI_DEVCONFIG` ioctl command. This can result in inconsistent lock states being reported when there is a mismatch in the spin-lock locking levels used by each low-level driver to which the COMEDI device has been attached. Fix it by reinitializing `dev->spinlock` before calling the low-level driver's `attach` function pointer if `CONFIG_LOCKDEP` is enabled. Reported-by: syzbot+cc9f7f4a7df09f53c4a4@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=cc9f7f4a7df09f53c4a4 Fixes: ed9eccbe8970 ("Staging: add comedi core") Cc: stable Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260225132427.86578-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman commit 34c8b3a91bdfbe4573650b4cd750ef639101fdc5 Author: Deepanshu Kartikey Date: Mon Mar 9 16:18:59 2026 +0530 comedi: dt2815: add hardware detection to prevent crash commit 93853512f565e625df2397f0d8050d6aafd7c3ad upstream. The dt2815 driver crashes when attached to I/O ports without actual hardware present. This occurs because syzkaller or users can attach the driver to arbitrary I/O addresses via COMEDI_DEVCONFIG ioctl. When no hardware exists at the specified port, inb() operations return 0xff (floating bus), but outb() operations can trigger page faults due to undefined behavior, especially under race conditions: BUG: unable to handle page fault for address: 000000007fffff90 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page RIP: 0010:dt2815_attach+0x6e0/0x1110 Add hardware detection by reading the status register before attempting any write operations. If the read returns 0xff, assume no hardware is present and fail the attach with -ENODEV. This prevents crashes from outb() operations on non-existent hardware. Reported-by: syzbot+72f94b474d6e50b71ffc@syzkaller.appspotmail.com Cc: stable Closes: https://syzkaller.appspot.com/bug?extid=72f94b474d6e50b71ffc Tested-by: syzbot+72f94b474d6e50b71ffc@syzkaller.appspotmail.com Reviewed-by: Ian Abbott Signed-off-by: Deepanshu Kartikey Link: [https://lore.kernel.org/all/20260126070458.10974-1-kartikey406@gmail.com/T/] Link: [https://lore.kernel.org/all/20260126070458.10974-1-kartikey406@gmail.com/T/ Link: https://patch.msgid.link/20260309104859.503529-1-kartikey406@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit e92f5ee730653aa387ffb6041983a51d19a27aed Author: Oliver Neukum Date: Tue Mar 17 09:41:10 2026 +0100 cdc-acm: new quirk for EPSON HMD commit f97e96c303d689708f7f713d8f3afcc31f1237e9 upstream. This device has a union descriptor that is just garbage and needs a custom descriptor. In principle this could be done with a (conditionally activated) heuristic. That would match more devices without a need for defining a new quirk. However, this always carries the risk that the heuristics does the wrong thing and leads to more breakage. Defining the quirk and telling it exactly what to do is the safe and conservative approach. Signed-off-by: Oliver Neukum Cc: stable Link: https://patch.msgid.link/20260317084139.1461008-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit 837392a38445729c22e03d3abcf33f07763efd85 Author: Yang Yang Date: Thu Mar 26 03:44:40 2026 +0000 bridge: br_nd_send: validate ND option lengths commit 850837965af15707fd3142c1cf3c5bfaf022299b upstream. br_nd_send() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload. Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address. Fixes: ed842faeb2bd ("bridge: suppress nd pkts on BR_NEIGH_SUPPRESS ports") Cc: stable@vger.kernel.org Reported-by: Yifan Wu Reported-by: Juefei Pu Tested-by: Ao Zhou Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Signed-off-by: Yang Yang Reviewed-by: Ido Schimmel Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260326034441.2037420-3-n05ec@lzu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5da684c24e8b480753b9ab5ca3ab2d575b298bd9 Author: Srinivas Kandagatla Date: Tue Apr 7 16:32:05 2026 +0800 ASoC: qcom: sc7280: make use of common helpers commit 8fdb030fe283c84fd8d378c97ad0f32d6cdec6ce upstream. sc7280 machine driver can make use of common sdw functions to do most of the soundwire related operations. Remove such redundant code from sc7280 driver. [This is a partial backport containing only the sound/soc/qcom/sdw.c changes which add LPASS CDC DMA DAI IDs to qcom_snd_is_sdw_dai(). The sc7280.c refactoring changes are omitted as they depend on intermediate patches not present in 6.18.y. The sdw.c change fixes a NULL pointer dereference for lpass-cpu based SoundWire links.] Fixes: bcba17279327 ("ASoC: qcom: sdw: fix memory leak for sdw_stream_runtime") Cc: stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla Tested-by: Steev Klimaszewski # Thinkpad X13s Link: https://patch.msgid.link/20251022143349.1081513-5-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Xilin Wu Signed-off-by: Sasha Levin commit f43f77499ec8de0af0b54d812c5d37f0120aeec1 Author: Jens Axboe Date: Tue Mar 31 07:07:47 2026 -0600 io_uring: protect remaining lockless ctx->rings accesses with RCU Commit 61a11cf4812726aceaee17c96432e1c08f6ed6cb upstream. Commit 96189080265e addressed one case of ctx->rings being potentially accessed while a resize is happening on the ring, but there are still a few others that need handling. Add a helper for retrieving the rings associated with an io_uring context, and add some sanity checking to that to catch bad uses. ->rings_rcu is always valid, as long as it's used within RCU read lock. Any use of ->rings_rcu or ->rings inside either ->uring_lock or ->completion_lock is sane as well. Do the minimum fix for the current kernel, but set it up such that this basic infra can be extended for later kernels to make this harder to mess up in the future. Thanks to Junxi Qian for finding and debugging this issue. Cc: stable@vger.kernel.org Fixes: 79cfe9e59c2a ("io_uring/register: add IORING_REGISTER_RESIZE_RINGS") Reviewed-by: Junxi Qian Tested-by: Junxi Qian Link: https://lore.kernel.org/io-uring/20260330172348.89416-1-qjx1298677004@gmail.com/ Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 09f78265a93d496f84598e5cf7e5d655953c2ad0 Author: Guan-Yu Lin Date: Wed Apr 1 12:32:17 2026 +0000 usb: core: use dedicated spinlock for offload state commit bd3d245b0fef571f93504904df62b8865b1c0d34 upstream. Replace the coarse USB device lock with a dedicated offload_lock spinlock to reduce contention during offload operations. Use offload_pm_locked to synchronize with PM transitions and replace the legacy offload_at_suspend flag. Optimize usb_offload_get/put by switching from auto-resume/suspend to pm_runtime_get_if_active(). This ensures offload state is only modified when the device is already active, avoiding unnecessary power transitions. Cc: stable Fixes: ef82a4803aab ("xhci: sideband: add api to trace sideband usage") Signed-off-by: Guan-Yu Lin Tested-by: Hailong Liu Acked-by: Mathias Nyman Link: https://patch.msgid.link/20260401123238.3790062-2-guanyulin@google.com Signed-off-by: Greg Kroah-Hartman commit 5a85599ca4d2584d89dc69f4fc49303b75a42338 Author: Yongchao Wu Date: Wed Apr 1 08:10:00 2026 +0800 usb: cdns3: gadget: fix state inconsistency on gadget init failure commit c32f8748d70c8fc77676ad92ed76cede17bf2c48 upstream. When cdns3_gadget_start() fails, the DRD hardware is left in gadget mode while software state remains INACTIVE, creating hardware/software state inconsistency. When switching to host mode via sysfs: echo host > /sys/class/usb_role/13180000.usb-role-switch/role The role state is not set to CDNS_ROLE_STATE_ACTIVE due to the error, so cdns_role_stop() skips cleanup because state is still INACTIVE. This violates the DRD controller design specification (Figure22), which requires returning to idle state before switching roles. This leads to a synchronous external abort in xhci_gen_setup() when setting up the host controller: [ 516.440698] configfs-gadget 13180000.usb: failed to start g1: -19 [ 516.442035] cdns-usb3 13180000.usb: Failed to add gadget [ 516.443278] cdns-usb3 13180000.usb: set role 2 has failed ... [ 1301.375722] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller [ 1301.377716] Internal error: synchronous external abort: 96000010 [#1] PREEMPT SMP [ 1301.382485] pc : xhci_gen_setup+0xa4/0x408 [ 1301.393391] backtrace: ... xhci_gen_setup+0xa4/0x408 <-- CRASH xhci_plat_setup+0x44/0x58 usb_add_hcd+0x284/0x678 ... cdns_role_set+0x9c/0xbc <-- Role switch Fix by calling cdns_drd_gadget_off() in the error path to properly clean up the DRD gadget state. Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") Cc: stable Signed-off-by: Yongchao Wu Acked-by: Peter Chen Link: https://patch.msgid.link/20260401001000.5761-1-yongchao.wu@autochips.com Signed-off-by: Greg Kroah-Hartman commit 390536cc6af4ca5566bc3bf1f8b704700380cd2c Author: Yongchao Wu Date: Tue Mar 31 08:04:07 2026 +0800 usb: cdns3: gadget: fix NULL pointer dereference in ep_queue commit 7f6f127b9bc34bed35f56faf7ecb1561d6b39000 upstream. When the gadget endpoint is disabled or not yet configured, the ep->desc pointer can be NULL. This leads to a NULL pointer dereference when __cdns3_gadget_ep_queue() is called, causing a kernel crash. Add a check to return -ESHUTDOWN if ep->desc is NULL, which is the standard return code for unconfigured endpoints. This prevents potential crashes when ep_queue is called on endpoints that are not ready. Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") Cc: stable Signed-off-by: Yongchao Wu Acked-by: Peter Chen Link: https://patch.msgid.link/20260331000407.613298-1-yongchao.wu@autochips.com Signed-off-by: Greg Kroah-Hartman commit 701903fcac4a40c0e802afbe230a781313bc2ad9 Author: Gabor Juhos Date: Mon Mar 30 17:02:42 2026 +0200 usb: core: phy: avoid double use of 'usb3-phy' commit 0179c6da0793ae03607002c284b53b6d584172d0 upstream. Commit 53a2d95df836 ("usb: core: add phy notify connect and disconnect") causes double use of the 'usb3-phy' in certain cases. Since that commit, if a generic PHY named 'usb3-phy' is specified in the device tree, that is getting added to the 'phy_roothub' list of the secondary HCD by the usb_phy_roothub_alloc_usb3_phy() function. However, that PHY is getting added also to the primary HCD's 'phy_roothub' list by usb_phy_roothub_alloc() if there is no generic PHY specified with 'usb2-phy' name. This causes that the usb_add_hcd() function executes each phy operations twice on the 'usb3-phy'. Once when the primary HCD is added, then once again when the secondary HCD is added. The issue affects the Marvell Armada 3700 platform at least, where a custom name is used for the USB2 PHY: $ git grep 'phy-names.*usb3' arch/arm64/boot/dts/marvell/armada-37xx.dtsi | tr '\t' ' ' arch/arm64/boot/dts/marvell/armada-37xx.dtsi: phy-names = "usb3-phy", "usb2-utmi-otg-phy"; Extend the usb_phy_roothub_alloc_usb3_phy() function to skip adding the 'usb3-phy' to the 'phy_roothub' list of the secondary HCD when 'usb2-phy' is not specified in the device tree to avoid the double use. Fixes: 53a2d95df836 ("usb: core: add phy notify connect and disconnect") Cc: stable Signed-off-by: Gabor Juhos Link: https://patch.msgid.link/20260330-usb-avoid-usb3-phy-double-use-v1-1-d2113aecb535@gmail.com Signed-off-by: Greg Kroah-Hartman commit 61937f686290494998236c680ce0836b8dd63a3f Author: Juno Choi Date: Tue Mar 24 10:49:10 2026 +0900 usb: dwc2: gadget: Fix spin_lock/unlock mismatch in dwc2_hsotg_udc_stop() commit 9bb4b5ed7f8c4f95cc556bdf042b0ba2fa13557a upstream. dwc2_gadget_exit_clock_gating() internally calls call_gadget() macro, which expects hsotg->lock to be held since it does spin_unlock/spin_lock around the gadget driver callback invocation. However, dwc2_hsotg_udc_stop() calls dwc2_gadget_exit_clock_gating() without holding the lock. This leads to: - spin_unlock on a lock that is not held (undefined behavior) - The lock remaining held after dwc2_gadget_exit_clock_gating() returns, causing a deadlock when spin_lock_irqsave() is called later in the same function. Fix this by acquiring hsotg->lock before calling dwc2_gadget_exit_clock_gating() and releasing it afterwards, which satisfies the locking requirement of the call_gadget() macro. Fixes: af076a41f8a2 ("usb: dwc2: also exit clock_gating when stopping udc while suspended") Cc: stable Signed-off-by: Juno Choi Link: https://patch.msgid.link/20260324014910.2798425-1-juno.choi@lge.com Signed-off-by: Greg Kroah-Hartman commit 6288b46e5ac6817327b4e7803a219be022016769 Author: Justin Chen Date: Wed Mar 18 11:57:07 2026 -0700 usb: ehci-brcm: fix sleep during atomic commit 679b771ea05ad0f8eeae83e14a91b8f4f39510c4 upstream. echi_brcm_wait_for_sof() gets called after disabling interrupts in ehci_brcm_hub_control(). Use the atomic version of poll_timeout to fix the warning. Fixes: 9df231511bd6 ("usb: ehci: Add new EHCI driver for Broadcom STB SoC's") Cc: stable Signed-off-by: Justin Chen Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260318185707.2588431-1-justin.chen@broadcom.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 34af2da733f4e413524e4532bfd0a24a9facd689 Author: Guan-Yu Lin Date: Wed Apr 1 12:32:18 2026 +0000 usb: host: xhci-sideband: delegate offload_usage tracking to class drivers commit 5abbe6ecc6203355c770bf232ade88e29c960049 upstream. Remove usb_offload_get() and usb_offload_put() from the xHCI sideband interrupter creation and removal paths. The responsibility of manipulating offload_usage now lies entirely with the USB class drivers. They have the precise context of when an offload data stream actually starts and stops, ensuring a much more accurate representation of offload activity for power management. Cc: stable Fixes: ef82a4803aab ("xhci: sideband: add api to trace sideband usage") Signed-off-by: Guan-Yu Lin Tested-by: Hailong Liu Tested-by: hailong.liu@oppo.com Acked-by: Mathias Nyman Link: https://patch.msgid.link/20260401123238.3790062-3-guanyulin@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 65ff09f48b0e72e4049096a989723406aabcf091 Author: Felix Gu Date: Tue Mar 31 20:05:08 2026 +0800 usb: misc: usbio: Fix URB memory leak on submit failure commit 33cfe0709b6bf1a7f1a16d5e8d65d003a71b6a21 upstream. When usb_submit_urb() fails in usbio_probe(), the previously allocated URB is never freed, causing a memory leak. Fix this by jumping to err_free_urb label to properly release the URB on the error path. Fixes: 121a0f839dbb ("usb: misc: Add Intel USBIO bridge driver") Cc: stable Signed-off-by: Felix Gu Reviewed-by: Oliver Neukum Reviewed-by: Hans de Goede Link: https://patch.msgid.link/20260331-usbio-v2-1-d8c48dad9463@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 977b632db51d231dec0bc571089a5c2402674139 Author: Heitor Alves de Siqueira Date: Thu Mar 12 09:27:28 2026 -0300 usb: usbtmc: Flush anchored URBs in usbtmc_release commit 8a768552f7a8276fb9e01d49773d2094ace7c8f1 upstream. When calling usbtmc_release, pending anchored URBs must be flushed or killed to prevent use-after-free errors (e.g. in the HCD giveback path). Call usbtmc_draw_down() to allow anchored URBs to be completed. Fixes: 4f3c8d6eddc2 ("usb: usbtmc: Support Read Status Byte with SRQ per file") Reported-by: syzbot+9a3c54f52bd1edbd975f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9a3c54f52bd1edbd975f Cc: stable Signed-off-by: Heitor Alves de Siqueira Link: https://patch.msgid.link/20260312-usbtmc-flush-release-v1-1-5755e9f4336f@igalia.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 38c28fe25611099230f0965c925499bfcf46a795 Author: Guangshuo Li Date: Wed Apr 1 10:51:42 2026 +0800 usb: ulpi: fix double free in ulpi_register_interface() error path commit 01af542392b5d41fd659d487015a71f627accce3 upstream. When device_register() fails, ulpi_register() calls put_device() on ulpi->dev. The device release callback ulpi_dev_release() drops the OF node reference and frees ulpi, but the current error path in ulpi_register_interface() then calls kfree(ulpi) again, causing a double free. Let put_device() handle the cleanup through ulpi_dev_release() and avoid freeing ulpi again in ulpi_register_interface(). Fixes: 289fcff4bcdb1 ("usb: add bus type for USB ULPI") Cc: stable Signed-off-by: Guangshuo Li Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260401025142.1398996-1-lgs201920130244@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 882bdb01ff12cdf9580c26b0cee7e6c412c32abd Author: Miao Li Date: Thu Mar 19 13:39:27 2026 +0800 usb: quirks: add DELAY_INIT quirk for another Silicon Motion flash drive commit dd36014ec6042f424ef51b923e607772f7502ee7 upstream. Another Silicon Motion flash drive also randomly work incorrectly (lsusb does not list the device) on Huawei hisi platforms during 500 reboot cycles, and the DELAY_INIT quirk fixes this issue. Signed-off-by: Miao Li Cc: stable Link: https://patch.msgid.link/20260319053927.264840-1-limiao870622@163.com Signed-off-by: Greg Kroah-Hartman commit 21f942879f86108b300a23683e67483f8c358fc7 Author: Johan Hovold Date: Tue Mar 10 11:51:27 2026 +0100 gpib: lpvo_usb: fix memory leak on disconnect commit 5cefb52c1af6f69ea719e42788f6ec6a087eb74c upstream. The driver iterates over the registered USB interfaces during GPIB attach and takes a reference to their USB devices until a match is found. These references are never released which leads to a memory leak when devices are disconnected. Fix the leak by dropping the unnecessary references. Fixes: fce79512a96a ("staging: gpib: Add LPVO DIY USB GPIB driver") Cc: stable # 6.13 Cc: Dave Penkler Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260310105127.17538-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit ffacfe07177d37cbf6548a4c40f0e7cb96f024f0 Author: Alexander Usyskin Date: Mon Mar 30 11:38:30 2026 +0300 mei: me: reduce the scope on unexpected reset commit 8c27b1bce059a11a8d3c8682984e13866f0714af upstream. After commit 2cedb296988c ("mei: me: trigger link reset if hw ready is unexpected") some devices started to show long resume times (5-7 seconds). This happens as mei falsely detects unready hardware, starts parallel link reset flow and triggers link reset timeouts in the resume callback. Address it by performing detection of unready hardware only when driver is in the MEI_DEV_ENABLED state instead of blacklisting states as done in the original patch. This eliminates active waitqueue check as in MEI_DEV_ENABLED state there will be no active waitqueue. Reviewed-by: Rafael J. Wysocki (Intel) Reported-by: Todd Brandt Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221023 Tested-by: Todd Brandt Fixes: 2cedb296988c ("mei: me: trigger link reset if hw ready is unexpected") Cc: stable Signed-off-by: Alexander Usyskin Link: https://patch.msgid.link/20260330083830.536056-1-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit fefd0bceac15faf2fbaf423c1d6e81412658ed5f Author: Ethan Tidmore Date: Tue Feb 24 16:48:18 2026 -0600 iio: gyro: mpu3050: Fix out-of-sequence free_irq() commit d14116f6529fa085b1a1b1f224dc9604e4d2a29c upstream. The triggered buffer is initialized before the IRQ is requested. The removal path currently calls iio_triggered_buffer_cleanup() before free_irq(). This violates the expected LIFO. Place free_irq() in the correct location relative to iio_triggered_buffer_cleanup(). Fixes: 3904b28efb2c7 ("iio: gyro: Add driver for the MPU-3050 gyroscope") Suggested-by: Jonathan Cameron Reviewed-by: Linus Walleij Signed-off-by: Ethan Tidmore Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit cc3de12a5612ee25df7fb549cb7b3e4cc8bfaf9c Author: Ethan Tidmore Date: Tue Feb 24 16:48:17 2026 -0600 iio: gyro: mpu3050: Move iio_device_register() to correct location commit 4c05799449108fb0e0a6bd30e65fffc71e60db4d upstream. iio_device_register() should be at the end of the probe function to prevent race conditions. Place iio_device_register() at the end of the probe function and place iio_device_unregister() accordingly. Fixes: 3904b28efb2c7 ("iio: gyro: Add driver for the MPU-3050 gyroscope") Suggested-by: Jonathan Cameron Reviewed-by: Linus Walleij Signed-off-by: Ethan Tidmore Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 3a8e68d65a443de05061818823037931674740e0 Author: Ethan Tidmore Date: Tue Feb 24 16:48:16 2026 -0600 iio: gyro: mpu3050: Fix irq resource leak commit 4216db1043a3be72ef9c2b7b9f393d7fa72496e6 upstream. The interrupt handler is setup but only a few lines down if iio_trigger_register() fails the function returns without properly releasing the handler. Add cleanup goto to resolve resource leak. Detected by Smatch: drivers/iio/gyro/mpu3050-core.c:1128 mpu3050_trigger_probe() warn: 'irq' from request_threaded_irq() not released on lines: 1124. Fixes: 3904b28efb2c7 ("iio: gyro: Add driver for the MPU-3050 gyroscope") Reviewed-by: Linus Walleij Signed-off-by: Ethan Tidmore Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit ac1233397f4cfe55d71f6aa459b42c256c951531 Author: Ethan Tidmore Date: Tue Feb 24 16:48:15 2026 -0600 iio: gyro: mpu3050: Fix incorrect free_irq() variable commit edb11a1aef4011a4b7b22cc3c3396c6fe371f4a6 upstream. The handler for the IRQ part of this driver is mpu3050->trig but, in the teardown free_irq() is called with handler mpu3050. Use correct IRQ handler when calling free_irq(). Fixes: 3904b28efb2c7 ("iio: gyro: Add driver for the MPU-3050 gyroscope") Reviewed-by: Linus Walleij Signed-off-by: Ethan Tidmore Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 7f14b52a81f9403ae7f3fe870f95644946d964f4 Author: Francesco Lavra Date: Wed Feb 25 11:06:00 2026 +0100 iio: imu: st_lsm6dsx: Set FIFO ODR for accelerometer and gyroscope only commit 630748afa7030b272b7bee5df857e7bcf132ed51 upstream. The st_lsm6dsx_set_fifo_odr() function, which is called when enabling and disabling the hardware FIFO, checks the contents of the hw->settings->batch array at index sensor->id, and then sets the current ODR value in sensor registers that depend on whether the register address is set in the above array element. This logic is valid for internal sensors only, i.e. the accelerometer and gyroscope; however, since commit c91c1c844ebd ("iio: imu: st_lsm6dsx: add i2c embedded controller support"), this function is called also when configuring the hardware FIFO for external sensors (i.e. sensors accessed through the sensor hub functionality), which can result in unrelated device registers being written. Add a check to the beginning of st_lsm6dsx_set_fifo_odr() so that it does not touch any registers unless it is called for internal sensors. Fixes: c91c1c844ebd ("iio: imu: st_lsm6dsx: add i2c embedded controller support") Signed-off-by: Francesco Lavra Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit d6e078c63409483a731324bbd1c26d365b4940a6 Author: Josh Poimboeuf Date: Mon Mar 9 20:45:45 2026 -0700 iio: imu: bmi160: Remove potential undefined behavior in bmi160_config_pin() commit c05a87d9ec3bf8727a5d746ce855003c6f2f8bb4 upstream. If 'pin' is not one of its expected values, the value of 'int_out_ctrl_shift' is undefined. With UBSAN enabled, this causes Clang to generate undefined behavior, resulting in the following warning: drivers/iio/imu/bmi160/bmi160_core.o: warning: objtool: bmi160_setup_irq() falls through to next function __cfi_bmi160_core_runtime_resume() Prevent the UB and improve error handling by returning an error if 'pin' has an unexpected value. While at it, simplify the code a bit by moving the 'pin_name' assignment to the first switch statement. Fixes: 895bf81e6bbf ("iio:bmi160: add drdy interrupt support") Reported-by: Arnd Bergmann Closes: https://lore.kernel.org/a426d669-58bb-4be1-9eaa-6f3d83109e2d@app.fastmail.com Signed-off-by: Josh Poimboeuf Reviewed-by: Nuno Sá Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 04d8f0a785dc0a859902a87d1adb1d98a3c4ae14 Author: Aldo Conte Date: Wed Mar 25 12:32:16 2026 +0100 iio: light: veml6070: fix veml6070_read() return value commit d0b224cf9ab12e86a4d1ca55c760dfaa5c19cbe7 upstream. veml6070_read() computes the sensor value in ret but returns 0 instead of the actual result. This causes veml6070_read_raw() to always report 0. Return the computed value instead of 0. Running make W=1 returns no errors. I was unable to test the patch because I do not have the hardware. Found by code inspection. Fixes: fc38525135dd ("iio: light: veml6070: use guard to handle mutex") Signed-off-by: Aldo Conte Reviewed-by: Nuno Sá Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 0ad74c370e8de8ab7a72d07159df851c891ccdf0 Author: David Lechner Date: Sat Mar 14 17:18:10 2026 -0500 iio: light: vcnl4035: fix scan buffer on big-endian commit fdc7aa54a5d44c05880a4aad7cfb41aacfd16d7b upstream. Rework vcnl4035_trigger_consumer_handler() so that we are not passing what should be a u16 value as an int * to regmap_read(). This won't work on bit endian systems. Instead, add a new unsigned int variable to pass to regmap_read(). Then copy that value into the buffer struct. The buffer array is replaced with a struct since there is only one value being read. This allows us to use the correct u16 data type and has a side-effect of simplifying the alignment specification. Also fix the endianness of the scan format from little-endian to CPU endianness. Since we are using regmap to read the value, it will be CPU-endian. Fixes: 55707294c4eb ("iio: light: Add support for vishay vcnl4035") Signed-off-by: David Lechner Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit b0e1fec0a0d07c506e1c6d5ec52c23f3834970cd Author: Antoniu Miclaus Date: Fri Feb 27 14:20:46 2026 +0200 iio: imu: adis16550: fix swapped gyro/accel filter functions commit ea7e2e43d768102e2601dbbda42041c78d7a99f9 upstream. The low-pass filter handlers for IIO_ANGL_VEL and IIO_ACCEL call each other's filter functions in both read_raw and write_raw. Swap them so each channel type uses its correct filter accessor. Fixes: bac4368fab62 ("iio: imu: adis16550: add adis16550 support") Signed-off-by: Antoniu Miclaus Acked-by: Robert Budai Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 2ed3d9bc86b66edc547e0638f1ec90685faf409c Author: Antoniu Miclaus Date: Thu Mar 12 13:20:24 2026 +0200 iio: dac: ad5770r: fix error return in ad5770r_read_raw() commit c354521708175d776d896f8bdae44b18711eccb6 upstream. Return the error code from regmap_bulk_read() instead of 0 so that I/O failures are properly propagated. Fixes: cbbb819837f6 ("iio: dac: ad5770r: Add AD5770R support") Signed-off-by: Antoniu Miclaus Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit d7161e8b6211a13da89797df8e23388e9cfbd214 Author: Antoniu Miclaus Date: Thu Mar 12 13:20:23 2026 +0200 iio: accel: adxl313: add missing error check in predisable commit 9d3fa23d5d55a137fd4396d3d4799102587a7f2b upstream. Check the return value of the FIFO bypass regmap_write() before proceeding to disable interrupts. Fixes: ff8093fa6ba4 ("iio: accel: adxl313: add buffered FIFO watermark with interrupt handling") Signed-off-by: Antoniu Miclaus Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit b6d6f6e2e329fb4b8ac017832058e61a49ee7dec Author: Antoniu Miclaus Date: Fri Feb 27 14:43:05 2026 +0200 iio: accel: adxl380: fix FIFO watermark bit 8 always written as 0 commit bd66aa1c8b8cabf459064a46d3430a5ec5138418 upstream. FIELD_PREP(BIT(0), fifo_samples & BIT(8)) produces either 0 or 256, and since FIELD_PREP masks to bit 0, 256 & 1 evaluates to 0. Use !! to convert the result to a proper 0-or-1 value. Fixes: df36de13677a ("iio: accel: add ADXL380 driver") Signed-off-by: Antoniu Miclaus Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 6c4591e71668142f47bc32772427a86438749651 Author: Valek Andrej Date: Fri Mar 13 10:24:13 2026 +0100 iio: accel: fix ADXL355 temperature signature value commit 4f51e6c0baae80e52bd013092e82a55678be31fc upstream. Temperature was wrongly represented as 12-bit signed, confirmed by checking the datasheet. Even if the temperature is negative, the value in the register stays unsigned. Fixes: 12ed27863ea3 iio: accel: Add driver support for ADXL355 Signed-off-by: Valek Andrej Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 85981790ea35d29cbccae482d469c8f044db88d5 Author: Billy Tsai Date: Tue Mar 3 10:38:26 2026 +0800 iio: adc: aspeed: clear reference voltage bits before configuring vref commit 7cf2f6ed8e7a3bf481ef70b6b4a2edb8abfa5c57 upstream. Ensures the reference voltage bits are cleared in the ADC engine control register before configuring the voltage reference. This avoids potential misconfigurations caused by residual bits. Fixes: 1b5ceb55fec2 ("iio: adc: aspeed: Support ast2600 adc.") Signed-off-by: Billy Tsai Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 5f482fd456bc543e58e40a6748f23fd03b43fc66 Author: Antoniu Miclaus Date: Fri Feb 27 15:33:30 2026 +0200 iio: adc: ade9000: move mutex init before IRQ registration commit 0206dd36418c104c0b3dea4ed7047e21eccb30b0 upstream. Move devm_mutex_init() before ade9000_request_irq() calls so that st->lock is initialized before any handler that depends on it can run. Fixes: 81de7b4619fc ("iio: adc: add ade9000 support") Signed-off-by: Antoniu Miclaus Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 87180f65f90da98a3ea125faafe4f418b8d63d37 Author: Giorgi Tchankvetadze Date: Thu Feb 26 18:07:02 2026 +0400 iio: adc: ade9000: fix wrong register in CALIBBIAS case for active power commit 86133fb1ec36b2f5cec29d71fbae84877c3a1358 upstream. The switch statement in ade9000_write_raw() attempts to match chan->address against ADE9000_REG_AWATTOS (0x00F) to dispatch the calibration offset write for active power channels. However, chan->address is set via ADE9000_ADDR_ADJUST(ADE9000_REG_AWATT, num), so after masking the phase bits, tmp holds ADE9000_REG_AWATT (0x210), which never matches 0x00F. As a result, writing IIO_CHAN_INFO_CALIBBIAS for IIO_POWER always falls through to the default case and returns -EINVAL, making active power offset calibration silently broken. Fix this by matching against ADE9000_REG_AWATT instead, which is the actual base address stored in chan->address for watt channels. Reference:ADE9000 datasheet (Rev. B), AWATTOS is the offset correction register at 0x00F (p. 44), while AWATT is the total active power register at 0x210 (p. 48). Fixes: 81de7b4619fc ("iio: adc: add ade9000 support") Signed-off-by: Giorgi Tchankvetadze Reviewed-by: Antoniu Miclaus Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 3707af316f86d319f72f1ac29e812e15832231d8 Author: Giorgi Tchankvetadze Date: Tue Feb 24 17:23:55 2026 +0400 iio: adc: ade9000: fix wrong return type in streaming push commit 57b207e38d414a27fda9fff638a0d3e7ef16b917 upstream. The else branch of ade9000_iio_push_streaming() incorrectly returns IRQ_HANDLED on regmap_write failure. This function returns int (0 on success, negative errno on failure), so IRQ_HANDLED (1) would be misinterpreted as a non-error by callers. Return ret instead, consistent with every other error path in the function. Fixes: 81de7b4619fc ("iio: adc: add ade9000 support") Signed-off-by: Giorgi Tchankvetadze Reviewed-by: Antoniu Miclaus Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 25e04a8291f4201fd5501bb1e4884e61896db692 Author: Dmitry Torokhov Date: Thu Mar 5 11:21:53 2026 -0800 iio: adc: ti-ads7950: do not clobber gpio state in ti_ads7950_get() commit d20bbae6e5d408a8a7c2a4344d76dd1ac557a149 upstream. GPIO state was inadvertently overwritten by the result of spi_sync(), resulting in ti_ads7950_get() only returning 0 as GPIO state (or error). Fix this by introducing a separate variable to hold the state. Fixes: c97dce792dc8 ("iio: adc: ti-ads7950: add GPIO support") Reported-by: David Lechner Signed-off-by: Dmitry Torokhov Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 6afa581aed0f1e7d77d8ae9e65b7836a1583470e Author: Dmitry Torokhov Date: Thu Mar 5 11:21:52 2026 -0800 iio: adc: ti-ads7950: normalize return value of gpio_get commit e2fa075d5ce1963e7cb7b0ac708ba567e5af66db upstream. The GPIO get callback is expected to return 0 or 1 (or a negative error code). Ensure that the value returned by ti_ads7950_get() for output pins is normalized to the [0, 1] range. Fixes: 86ef402d805d ("gpiolib: sanitize the return value of gpio_chip::get()") Reviewed-by: Andy Shevchenko Reviewed-by: Bartosz Golaszewski Reviewed-by: Linus Walleij Signed-off-by: Dmitry Torokhov Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit d0a6b8d186dab99cbfb43191d0651b3b8e991270 Author: Zoltan Illes Date: Fri Apr 3 22:03:42 2026 -0700 Input: xpad - add support for Razer Wolverine V3 Pro commit e2b0ae529db4766584e77647cefe3ec15c3d842e upstream. Add device IDs for the Razer Wolverine V3 Pro controller in both wired (0x0a57) and wireless 2.4 GHz dongle (0x0a59) modes. The controller uses the Xbox 360 protocol (vendor-specific class, subclass 93, protocol 1) on interface 0 with an identical 20-byte input report layout, so no additional processing is needed. Signed-off-by: Zoltan Illes Link: https://patch.msgid.link/20260329220031.1325509-1-137647604+ZlordHUN@users.noreply.github.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 86620132e9c4cde336a7ce9ddaf142875b245fb5 Author: Shengyu Qu Date: Fri Apr 3 22:07:28 2026 -0700 Input: xpad - add support for BETOP BTP-KP50B/C controller's wireless mode commit 0d9363a764d9d601a05591f9695cea8b429e9be3 upstream. BETOP's BTP-KP50B and BTP-KP50C controller's wireless dongles are both working as standard Xbox 360 controllers. Add USB device IDs for them to xpad driver. Signed-off-by: Shengyu Qu Link: https://patch.msgid.link/TY4PR01MB14432B4B298EA186E5F86C46B9855A@TY4PR01MB14432.jpnprd01.prod.outlook.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 00f0cc75356b0b8d3798990603d1364886701167 Author: Liam Mitchell Date: Wed Feb 18 14:21:35 2026 -0800 Input: bcm5974 - recover from failed mode switch commit fc1e8a6f129d87c64ac8e58b50d9dfa66217cfda upstream. Mode switches sent before control response are ignored. This results in an unresponsive trackpad and "bcm5974: bad trackpad package, length: 8" repeated in logs. On receiving unknown 8-byte packets, assume that mode switch was ignored and schedule an asynchronous mode reset. The reset will switch the device to normal mode, wait, then switch back to wellspring mode. Signed-off-by: Liam Mitchell Link: https://lore.kernel.org/linux-input/CAOQ1CL4+DP1TuLAGNsz5GdFBTHvnTg=5q=Dr2Z1OQc6RXydSYA@mail.gmail.com/ Acked-by: Henrik Rydberg Link: https://patch.msgid.link/20260213-bcm5974-reset-v2-1-1837851336b0@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit beba26c55f4e411b0163b08840d98ee45497844f Author: Christoffer Sandberg Date: Mon Feb 23 15:20:45 2026 +0100 Input: i8042 - add TUXEDO InfinityBook Max 16 Gen10 AMD to i8042 quirk table commit 5839419cffc7788a356428d321e3ec18055c0286 upstream. The device occasionally wakes up from suspend with missing input on the internal keyboard and the following suspend attempt results in an instant wake-up. The quirks fix both issues for this device. Signed-off-by: Christoffer Sandberg Signed-off-by: Werner Sembach Link: https://patch.msgid.link/20260223142054.50310-1-wse@tuxedocomputers.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 33e646804070c8939c1509b11a79a7a2671e4b04 Author: Bart Van Assche Date: Mon Feb 23 15:05:15 2026 -0800 Input: synaptics-rmi4 - fix a locking bug in an error path commit 7adaaee5edd35a423ae199c41b86bd1ed60ed483 upstream. Lock f54->data_mutex when entering the function statement since jumping to the 'error' label when checking report_size fails causes that mutex to be unlocked. This bug has been detected by the Clang thread-safety checker. Fixes: 3a762dbd5347 ("[media] Input: synaptics-rmi4 - add support for F54 diagnostics") Signed-off-by: Bart Van Assche Link: https://patch.msgid.link/20260223215118.2154194-16-bvanassche@acm.org Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 8ea8dc0d62e3a3731fd494fa392f5e120bdd0dd8 Author: JP Hein Date: Mon Mar 30 17:38:04 2026 -0700 USB: core: add NO_LPM quirk for Razer Kiyo Pro webcam commit 8b7a42ecdcdeb55580d9345412f7f8fc5aca3f6c upstream. The Razer Kiyo Pro (1532:0e05) is a USB 3.0 UVC webcam whose firmware does not handle USB Link Power Management transitions reliably. When LPM is active, the device can enter a state where it fails to respond to control transfers, producing EPIPE (-32) errors on UVC probe control SET_CUR requests. In the worst case, the stalled endpoint triggers an xHCI stop-endpoint command that times out, causing the host controller to be declared dead and every USB device on the bus to be disconnected. This has been reported as Ubuntu Launchpad Bug #2061177. The failure mode is: 1. UVC probe control SET_CUR returns -32 (EPIPE) 2. xHCI host not responding to stop endpoint command 3. xHCI host controller not responding, assume dead 4. All USB devices on the affected xHCI controller disconnect Disabling LPM prevents the firmware from entering the problematic low- power states that precede the stall. This is the same approach used for other webcams with similar firmware issues (e.g., Logitech HD Webcam C270). Cc: stable Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2061177 Signed-off-by: JP Hein Link: https://patch.msgid.link/20260331003806.212565-2-jp@jphein.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 42e4fbeb853a6899ac4c618bd0da485c3c596312 Author: Wanquan Zhong Date: Mon Mar 16 19:55:12 2026 +0800 USB: serial: option: add support for Rolling Wireless RW135R-GL commit 01e8d0f742222f1e68f48180d5480097adf7ae9f upstream. Add VID/PID 33f8:1003 for the Rolling Wireless RW135R-GL M.2 module, which is used in laptop debug cards with MBIM interface for Linux/Chrome OS. The device supports mbim, pipe functionalities. Here are the outputs of usb-devices: T: Bus=04 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 P: Vendor=33f8 ProdID=1003 Rev=05.15 S: Manufacturer=Rolling Wireless S.a.r.l. S: Product=Rolling RW135R-GL Module S: SerialNumber=12345678 C: #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=896mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms Signed-off-by: Wanquan Zhong Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 70fd81b9c4bf35fc4d562439d47bdfaef6deb930 Author: Frej Drejhammar Date: Sun Feb 22 18:00:42 2026 +0100 USB: serial: io_edgeport: add support for Blackbox IC135A commit 0e01c3416eb863ee7f156a9d7e7421ec0a9f68a0 upstream. The Blackbox 724-746-5500 USB Director USB-RS-232 HUB, part number IC135A, is a rebadged Edgeport/4 with its own USB device id. Signed-off-by: Frej Drejhammar Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 2b8ae82d85d75347984297ed60d5005622992f6b Author: Alex Deucher Date: Tue Mar 17 16:34:41 2026 -0400 drm/amdgpu/pm: drop SMU driver if version not matched messages commit a3ffaa5b397f4df9d6ac16b10583e9df8e6fa471 upstream. It just leads to user confusion. Cc: Yang Wang Cc: Lijo Lazar Reviewed-by: Yang Wang Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher (cherry picked from commit e471627d56272a791972f25e467348b611c31713) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 77c918eaa4c916751769242567407f61c6af142a Author: Donet Tom Date: Thu Mar 26 17:51:28 2026 +0530 drm/amdgpu: Change AMDGPU_VA_RESERVED_TRAP_SIZE to 64KB commit 4487571ef17a30d274600b3bd6965f497a881299 upstream. Currently, AMDGPU_VA_RESERVED_TRAP_SIZE is hardcoded to 8KB, while KFD_CWSR_TBA_TMA_SIZE is defined as 2 * PAGE_SIZE. On systems with 4K pages, both values match (8KB), so allocation and reserved space are consistent. However, on 64K page-size systems, KFD_CWSR_TBA_TMA_SIZE becomes 128KB, while the reserved trap area remains 8KB. This mismatch causes the kernel to crash when running rocminfo or rccl unit tests. Kernel attempted to read user page (2) - exploit attempt? (uid: 1001) BUG: Kernel NULL pointer dereference on read at 0x00000002 Faulting instruction address: 0xc0000000002c8a64 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries CPU: 34 UID: 1001 PID: 9379 Comm: rocminfo Tainted: G E 6.19.0-rc4-amdgpu-00320-gf23176405700 #56 VOLUNTARY Tainted: [E]=UNSIGNED_MODULE Hardware name: IBM,9105-42A POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.30 (ML1060_896) hv:phyp pSeries NIP: c0000000002c8a64 LR: c00000000125dbc8 CTR: c00000000125e730 REGS: c0000001e0957580 TRAP: 0300 Tainted: G E MSR: 8000000000009033 CR: 24008268 XER: 00000036 CFAR: c00000000125dbc4 DAR: 0000000000000002 DSISR: 40000000 IRQMASK: 1 GPR00: c00000000125d908 c0000001e0957820 c0000000016e8100 c00000013d814540 GPR04: 0000000000000002 c00000013d814550 0000000000000045 0000000000000000 GPR08: c00000013444d000 c00000013d814538 c00000013d814538 0000000084002268 GPR12: c00000000125e730 c000007e2ffd5f00 ffffffffffffffff 0000000000020000 GPR16: 0000000000000000 0000000000000002 c00000015f653000 0000000000000000 GPR20: c000000138662400 c00000013d814540 0000000000000000 c00000013d814500 GPR24: 0000000000000000 0000000000000002 c0000001e0957888 c0000001e0957878 GPR28: c00000013d814548 0000000000000000 c00000013d814540 c0000001e0957888 NIP [c0000000002c8a64] __mutex_add_waiter+0x24/0xc0 LR [c00000000125dbc8] __mutex_lock.constprop.0+0x318/0xd00 Call Trace: 0xc0000001e0957890 (unreliable) __mutex_lock.constprop.0+0x58/0xd00 amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x6fc/0xb60 [amdgpu] kfd_process_alloc_gpuvm+0x54/0x1f0 [amdgpu] kfd_process_device_init_cwsr_dgpu+0xa4/0x1a0 [amdgpu] kfd_process_device_init_vm+0xd8/0x2e0 [amdgpu] kfd_ioctl_acquire_vm+0xd0/0x130 [amdgpu] kfd_ioctl+0x514/0x670 [amdgpu] sys_ioctl+0x134/0x180 system_call_exception+0x114/0x300 system_call_vectored_common+0x15c/0x2ec This patch changes AMDGPU_VA_RESERVED_TRAP_SIZE to 64 KB and KFD_CWSR_TBA_TMA_SIZE to the AMD GPU page size. This means we reserve 64 KB for the trap in the address space, but only allocate 8 KB within it. With this approach, the allocation size never exceeds the reserved area. Fixes: 34a1de0f7935 ("drm/amdkfd: Relocate TBA/TMA to opposite side of VM hole") Reviewed-by: Christian König Suggested-by: Felix Kuehling Suggested-by: Christian König Signed-off-by: Donet Tom Signed-off-by: Alex Deucher (cherry picked from commit 31b8de5e55666f26ea7ece5f412b83eab3f56dbb) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 3543005a42d7e8e12b21897ef6798541bf7cbcd3 Author: Junrui Luo Date: Tue Mar 24 17:39:02 2026 +0800 drm/amdgpu: validate doorbell_offset in user queue creation commit a018d1819f158991b7308e4f74609c6c029b670c upstream. amdgpu_userq_get_doorbell_index() passes the user-provided doorbell_offset to amdgpu_doorbell_index_on_bar() without bounds checking. An arbitrarily large doorbell_offset can cause the calculated doorbell index to fall outside the allocated doorbell BO, potentially corrupting kernel doorbell space. Validate that doorbell_offset falls within the doorbell BO before computing the BAR index, using u64 arithmetic to prevent overflow. Fixes: f09c1e6077ab ("drm/amdgpu: generate doorbell index for userqueue") Reported-by: Yuhao Jiang Signed-off-by: Junrui Luo Signed-off-by: Alex Deucher (cherry picked from commit de1ef4ffd70e1d15f0bf584fd22b1f28cbd5e2ec) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 1e130cf9cd172c684ff471d9cd8bccf06db64d88 Author: Lijo Lazar Date: Fri Mar 27 14:29:17 2026 +0530 drm/amdgpu: Fix wait after reset sequence in S4 commit daf470b8882b6f7f53cbfe9ec2b93a1b21528cdc upstream. For a mode-1 reset done at the end of S4 on PSPv11 dGPUs, only check if TOS is unloaded. Fixes: 32f73741d6ee ("drm/amdgpu: Wait for bootloader after PSPv11 reset") Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/4853 Signed-off-by: Lijo Lazar Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 2fb4883b884a437d760bd7bdf7695a7e5a60bba3) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit d0fd0bea847526dbe3d862c01e98a1617538565d Author: Ville Syrjälä Date: Wed Mar 25 15:58:45 2026 +0200 drm/i915/dp: Use crtc_state->enhanced_framing properly on ivb/hsw CPU eDP commit 9c9a57e4e337f94e23ddf69263fd0685c91155fb upstream. Looks like I missed the drm_dp_enhanced_frame_cap() in the ivb/hsw CPU eDP code when I introduced crtc_state->enhanced_framing. Fix it up so that the state we program to the hardware is guaranteed to match what we computed earlier. Cc: stable@vger.kernel.org Fixes: 3072a24c778a ("drm/i915: Introduce crtc_state->enhanced_framing") Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20260325135849.12603-3-ville.syrjala@linux.intel.com Reviewed-by: Michał Grzelak (cherry picked from commit 799fe8dc2af52f35c78c4ac97f8e34994dfd8760) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 86e926b108880c0109b8635e459450447156aeb7 Author: Ville Syrjälä Date: Thu Mar 26 13:18:10 2026 +0200 drm/i915/dsi: Don't do DSC horizontal timing adjustments in command mode commit 4dfce79e098915d8e5fc2b9e1d980bc3251dd32c upstream. Stop adjusting the horizontal timing values based on the compression ratio in command mode. Bspec seems to be telling us to do this only in video mode, and this is also how the Windows driver does things. This should also fix a div-by-zero on some machines because the adjusted htotal ends up being so small that we end up with line_time_us==0 when trying to determine the vtotal value in command mode. Note that this doesn't actually make the display on the Huawei Matebook E work, but at least the kernel no longer explodes when the driver loads. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12045 Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20260326111814.9800-2-ville.syrjala@linux.intel.com Fixes: 53693f02d80e ("drm/i915/dsi: account for DSC in horizontal timings") Reviewed-by: Jani Nikula (cherry picked from commit 0b475e91ecc2313207196c6d7fd5c53e1a878525) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit df4979eef358c28ea27a0901ee9627e3df80fdd1 Author: Thomas Zimmermann Date: Fri Mar 27 14:32:53 2026 +0100 drm/ast: dp501: Fix initialization of SCU2C commit 2f42c1a6161646cbd29b443459fd635d29eda634 upstream. Ast's DP501 initialization reads the register SCU2C at offset 0x1202c and tries to set it to source data from VGA. But writes the update to offset 0x0, with unknown results. Write the result to SCU instead. The bug only happens in ast_init_analog(). There's similar code in ast_init_dvo(), which works correctly. Signed-off-by: Thomas Zimmermann Fixes: 83c6620bae3f ("drm/ast: initial DP501 support (v0.2)") Reviewed-by: Jocelyn Falempe Cc: Dave Airlie Cc: Thomas Zimmermann Cc: Jocelyn Falempe Cc: dri-devel@lists.freedesktop.org Cc: # v3.16+ Link: https://patch.msgid.link/20260327133532.79696-2-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit 5a17678b74197d24611ea2e5414924f4850c83af Author: Felix Gu Date: Tue Mar 3 00:00:04 2026 +0800 iio: adc: ti-ads1119: Replace IRQF_ONESHOT with IRQF_NO_THREAD commit 36f6d4db3c5cb0f58fb02b1f54f9e86522d2f918 upstream. As there is no threaded handler, replace devm_request_threaded_irq() with devm_request_irq(), and as the handler calls iio_trigger_poll() which may not be called from a threaded handler replace IRQF_ONESHOT with IRQF_NO_THREAD. Since commit aef30c8d569c ("genirq: Warn about using IRQF_ONESHOT without a threaded handler"), the IRQ core checks IRQF_ONESHOT flag in IRQ request and gives a warning if there is no threaded handler. Fixes: a9306887eba4 ("iio: adc: ti-ads1119: Add driver") Signed-off-by: Felix Gu Reviewed-by: David Lechner Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 30e2275b3469f9cdd5810b471cbfa9398a584348 Author: Felix Gu Date: Tue Mar 3 21:47:33 2026 +0800 iio: adc: ti-ads1119: Reinit completion before wait_for_completion_timeout() commit 2f168094177f8553a36046afce139001801ca917 upstream. The completion is not reinit before wait_for_completion_timeout(), so wait_for_completion_timeout() will return immediately after the first successful completion. Fixes: a9306887eba4 ("iio: adc: ti-ads1119: Add driver") Signed-off-by: Felix Gu Reviewed-by: Francesco Dolcini Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 64bc0219e4d8ef339ef3cf683c62515012998dad Author: Felix Gu Date: Sat Feb 28 01:48:19 2026 +0800 iio: adc: ti-ads1119: Fix unbalanced pm reference count in ds1119_single_conversion() commit 48a5c36577ebe0144f8ede70e59b59ea18b75089 upstream. In ads1119_single_conversion(), if pm_runtime_resume_and_get() fails, the code jumps to the pdown label, which calls pm_runtime_put_autosuspend(). Since pm_runtime_resume_and_get() automatically decrements the usage counter on failure, the subsequent call to pm_runtime_put_autosuspend() causes an unbalanced reference counter. Fixes: a9306887eba4 ("iio: adc: ti-ads1119: Add driver") Signed-off-by: Felix Gu Reviewed-by: João Paulo Gonçalves Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 014c6d27878d3883f7bb065610768fd021de1a96 Author: David Lechner Date: Sat Mar 14 18:13:32 2026 -0500 iio: adc: ti-adc161s626: use DMA-safe memory for spi_read() commit 768461517a28d80fe81ea4d5d03a90cd184ea6ad upstream. Add a DMA-safe buffer and use it for spi_read() instead of a stack memory. All SPI buffers must be DMA-safe. Since we only need up to 3 bytes, we just use a u8[] instead of __be16 and __be32 and change the conversion functions appropriately. Fixes: 4d671b71beef ("iio: adc: ti-adc161s626: add support for TI 1-channel differential ADCs") Signed-off-by: David Lechner Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 054ea2f12beb4278ef832b784ded2edafd9d5da1 Author: David Lechner Date: Sat Mar 14 18:13:31 2026 -0500 iio: adc: ti-adc161s626: fix buffer read on big-endian commit 24869650dff34a6fc8fd1cc91b2058a72f9abc95 upstream. Rework ti_adc_trigger_handler() to properly handle data on big-endian architectures. The scan data format is 16-bit CPU-endian, so we can't cast it to a int * on big-endian and expect it to work. Instead, we introduce a local int variable to read the data into, and then copy it to the buffer. Since the buffer isn't passed to any SPI functions, we don't need it to be DMA-safe. So we can drop it from the driver data struct and just use stack memory for the scan data. Since there is only one data value (plus timestamp), we don't need an array and can just declare a struct with the correct data type instead. Also fix alignment of iio_get_time_ns() to ( while we are touching this. Fixes: 4d671b71beef ("iio: adc: ti-adc161s626: add support for TI 1-channel differential ADCs") Signed-off-by: David Lechner Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit d9bf25ef3d30f359a91cb02266ebb03c58d85268 Author: David Lechner Date: Sat Mar 7 19:44:09 2026 -0600 iio: orientation: hid-sensor-rotation: add timestamp hack to not break userspace commit 79a86a6cc3669416a21fef32d0767d39ba84b3aa upstream. Add a hack to push two timestamps in the hid-sensor-rotation scan data to avoid breaking userspace applications that depend on the timestamp being at the incorrect location in the scan data due to unintentional misalignment in older kernels. When this driver was written, the timestamp was in the correct location because of the way iio_compute_scan_bytes() was implemented at the time. (Samples were 24 bytes each.) Then commit 883f61653069 ("iio: buffer: align the size of scan bytes to size of the largest element") changed the computed scan_bytes to be a different size (32 bytes), which caused iio_push_to_buffers_with_timestamp() to place the timestamp at an incorrect offset. There have been long periods of time (6 years each) where the timestamp was in either location, so to not break either case, we open-code the timestamps to be pushed to both locations in the scan data. Reported-by: Jonathan Cameron Closes: https://lore.kernel.org/linux-iio/20260215162351.79f40b32@jic23-huawei/ Fixes: 883f61653069 ("iio: buffer: align the size of scan bytes to size of the largest element") Signed-off-by: David Lechner Reviewed-by: Nuno Sá Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 7d14b49de8fcccbead88349b3560313b2e936f63 Author: David Lechner Date: Sat Feb 28 14:02:23 2026 -0600 iio: orientation: hid-sensor-rotation: fix quaternion alignment commit 50d4cc74b8a720a9682a9c94f7e62a5de6b2ed3a upstream. Restore the alignment of sampled_vals to 16 bytes by using IIO_DECLARE_QUATERNION(). This field contains a quaternion value which has scan_type.repeat = 4 and storagebits = 32. So the alignment must be 16 bytes to match the assumptions of iio_storage_bytes_for_si() and also to not break userspace. Reported-by: Lixu Zhang Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221077 Fixes: b31a74075cb4 ("iio: orientation: hid-sensor-rotation: remove unnecessary alignment") Tested-by: Lixu Zhang Signed-off-by: David Lechner Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 2b655a9176442d2a9a8b6b45df4a657cb225223b Author: David Lechner Date: Sat Feb 28 14:02:22 2026 -0600 iio: add IIO_DECLARE_QUATERNION() macro commit 56bd57e7b161f75535df91b229b0b2c64c6e5581 upstream. Add a new IIO_DECLARE_QUATERNION() macro that is used to declare the field in an IIO buffer struct that contains a quaternion vector. Quaternions are currently the only IIO data type that uses the .repeat feature of struct iio_scan_type. This has an implicit rule that the element in the buffer must be aligned to the entire size of the repeated element. This macro will make that requirement explicit. Since this is the only user, we just call the macro IIO_DECLARE_QUATERNION() instead of something more generic. Signed-off-by: David Lechner Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit cae26eff1b56d78bed7873cf3e60a2b1bdd4da6c Author: Adam Crosser Date: Tue Mar 17 19:25:28 2026 +0700 gpib: fix use-after-free in IO ioctl handlers commit d1857f8296dceb75d00ab857fc3c61bc00c7f5c6 upstream. The IBRD, IBWRT, IBCMD, and IBWAIT ioctl handlers use a gpib_descriptor pointer after board->big_gpib_mutex has been released. A concurrent IBCLOSEDEV ioctl can free the descriptor via close_dev_ioctl() during this window, causing a use-after-free. The IO handlers (read_ioctl, write_ioctl, command_ioctl) explicitly release big_gpib_mutex before calling their handler. wait_ioctl() is called with big_gpib_mutex held, but ibwait() releases it internally when wait_mask is non-zero. In all four cases, the descriptor pointer obtained from handle_to_descriptor() becomes unprotected. Fix this by introducing a kernel-only descriptor_busy reference count in struct gpib_descriptor. Each handler atomically increments descriptor_busy under file_priv->descriptors_mutex before releasing the lock, and decrements it when done. close_dev_ioctl() checks descriptor_busy under the same lock and rejects the close with -EBUSY if the count is non-zero. A reference count rather than a simple flag is necessary because multiple handlers can operate on the same descriptor concurrently (e.g. IBRD and IBWAIT on the same handle from different threads). A separate counter is needed because io_in_progress can be cleared from unprivileged userspace via the IBWAIT ioctl (through general_ibstatus() with set_mask containing CMPL), which would allow an attacker to bypass a check based solely on io_in_progress. The new descriptor_busy counter is only modified by the kernel IO paths. The lock ordering is consistent (big_gpib_mutex -> descriptors_mutex) and the handlers only hold descriptors_mutex briefly during the lookup, so there is no deadlock risk and no impact on IO throughput. Signed-off-by: Adam Crosser Cc: stable Reviewed-by: Dave Penkler Tested-by: Dave Penkler Signed-off-by: Greg Kroah-Hartman commit 115a4c8df909fdc6ede3ec363028db43783095ba Author: Prike Liang Date: Mon Mar 23 16:07:02 2026 +0800 drm/amdgpu: fix the idr allocation flags commit 62f553d60a801384336f5867967c26ddf3b17038 upstream. Fix the IDR allocation flags by using atomic GFP flags in non‑sleepable contexts to avoid the __might_sleep() complaint. 268.290239] [drm] Initialized amdgpu 3.64.0 for 0000:03:00.0 on minor 0 [ 268.294900] BUG: sleeping function called from invalid context at ./include/linux/sched/mm.h:323 [ 268.295355] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1744, name: modprobe [ 268.295705] preempt_count: 1, expected: 0 [ 268.295886] RCU nest depth: 0, expected: 0 [ 268.296072] 2 locks held by modprobe/1744: [ 268.296077] #0: ffff8c3a44abd1b8 (&dev->mutex){....}-{4:4}, at: __driver_attach+0xe4/0x210 [ 268.296100] #1: ffffffffc1a6ea78 (amdgpu_pasid_idr_lock){+.+.}-{3:3}, at: amdgpu_pasid_alloc+0x26/0xe0 [amdgpu] [ 268.296494] CPU: 12 UID: 0 PID: 1744 Comm: modprobe Tainted: G U OE 6.19.0-custom #16 PREEMPT(voluntary) [ 268.296498] Tainted: [U]=USER, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [ 268.296499] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021 [ 268.296501] Call Trace: Fixes: 8f1de51f49be ("drm/amdgpu: prevent immediate PASID reuse case") Tested-by: Borislav Petkov (AMD) Signed-off-by: Prike Liang Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit ea56aa2625708eaf96f310032391ff37746310ef) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 1e3e98596c2769721ade0418434852fb3af4849a Author: Aleksandr Nogikh Date: Wed Mar 25 16:48:24 2026 +0100 x86/kexec: Disable KCOV instrumentation after load_segments() commit 917e3ad3321e75ca0223d5ccf26ceda116aa51e1 upstream. The load_segments() function changes segment registers, invalidating GS base (which KCOV relies on for per-cpu data). When CONFIG_KCOV is enabled, any subsequent instrumented C code call (e.g. native_gdt_invalidate()) begins crashing the kernel in an endless loop. To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented kernel: $ kexec -l /boot/otherKernel $ kexec -e The real-world context for this problem is enabling crash dump collection in syzkaller. For this, the tool loads a panic kernel before fuzzing and then calls makedumpfile after the panic. This workflow requires both CONFIG_KEXEC and CONFIG_KCOV to be enabled simultaneously. Adding safeguards directly to the KCOV fast-path (__sanitizer_cov_trace_pc()) is also undesirable as it would introduce an extra performance overhead. Disabling instrumentation for the individual functions would be too fragile, so disable KCOV instrumentation for the entire machine_kexec_64.c and physaddr.c. If coverage-guided fuzzing ever needs these components in the future, other approaches should be considered. The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not supported there. [ bp: Space out comment for better readability. ] Fixes: 0d345996e4cb ("x86/kernel: increase kcov coverage under arch/x86/kernel folder") Signed-off-by: Aleksandr Nogikh Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Dmitry Vyukov Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260325154825.551191-1-nogikh@google.com Signed-off-by: Greg Kroah-Hartman commit 16062d6830a7fde8009969aa980a4555d76e546b Author: Stefan Wiehler Date: Tue Mar 10 11:40:24 2026 +0100 mips: mm: Allocate tlb_vpn array atomically commit 01cc50ea5167bb14117257ec084637abe9e5f691 upstream. Found by DEBUG_ATOMIC_SLEEP: BUG: sleeping function called from invalid context at /include/linux/sched/mm.h:306 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1 preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 no locks held by swapper/1/0. irq event stamp: 0 hardirqs last enabled at (0): [<0000000000000000>] 0x0 hardirqs last disabled at (0): [] copy_process+0x75c/0x1b68 softirqs last enabled at (0): [] copy_process+0x75c/0x1b68 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.119-d79e757675ec-fct #1 Stack : 800000000290bad8 0000000000000000 0000000000000008 800000000290bae8 800000000290bae8 800000000290bc78 0000000000000000 0000000000000000 ffffffff80c80000 0000000000000001 ffffffff80d8dee8 ffffffff810d09c0 784bb2a7ec10647d 0000000000000010 ffffffff80a6fd60 8000000001d8a9c0 0000000000000000 0000000000000000 ffffffff80d90000 0000000000000000 ffffffff80c9e0e8 0000000007ffffff 0000000000000cc0 0000000000000400 ffffffffffffffff 0000000000000001 0000000000000002 ffffffffc0149ed8 fffffffffffffffe 8000000002908000 800000000290bae0 ffffffff80a81b74 ffffffff80129fb0 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 ffffffff80129fd0 0000000000000000 ... Call Trace: [] show_stack+0x60/0x158 [] dump_stack_lvl+0x88/0xbc [] __might_resched+0x268/0x288 [] __kmem_cache_alloc_node+0x2e0/0x330 [] __kmalloc+0x58/0xd0 [] r4k_tlb_uniquify+0x7c/0x428 [] tlb_init+0x7c/0x110 [] per_cpu_trap_init+0x16c/0x1d0 [] start_secondary+0x28/0x128 Fixes: 231ac951faba ("MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow") Signed-off-by: Stefan Wiehler Cc: stable@vger.kernel.org Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 243d55bd3f08cb15eee9d63f4716d4d4cdd760f5 Author: Sanman Pradhan Date: Thu Mar 26 22:45:23 2026 +0000 hwmon: (occ) Fix division by zero in occ_show_power_1() commit 39e2a5bf970402a8530a319cf06122e216ba57b8 upstream. In occ_show_power_1() case 1, the accumulator is divided by update_tag without checking for zero. If no samples have been collected yet (e.g. during early boot when the sensor block is included but hasn't been updated), update_tag is zero, causing a kernel divide-by-zero crash. The 2019 fix in commit 211186cae14d ("hwmon: (occ) Fix division by zero issue") only addressed occ_get_powr_avg() used by occ_show_power_2() and occ_show_power_a0(). This separate code path in occ_show_power_1() was missed. Fix this by reusing the existing occ_get_powr_avg() helper, which already handles the zero-sample case and uses mul_u64_u32_div() to multiply before dividing for better precision. Move the helper above occ_show_power_1() so it is visible at the call site. Fixes: c10e753d43eb ("hwmon (occ): Add sensor types and versions") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan Link: https://lore.kernel.org/r/20260326224510.294619-2-sanman.pradhan@hpe.com [groeck: Fix alignment problems reported by checkpatch] Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 1010390094fa27614dd0966261c9edd0a54bc50a Author: Maciej W. Rozycki Date: Mon Mar 30 02:54:09 2026 +0100 MIPS: Fix the GCC version check for `__multi3' workaround commit ec8bf18814915460d9c617b556bf024efef26613 upstream. It was only GCC 10 that fixed a MIPS64r6 code generation issue with a `__multi3' libcall inefficiently produced to perform 64-bit widening multiplication while suitable machine instructions exist to do such a calculation. The fix went in with GCC commit 48b2123f6336 ("re PR target/82981 (unnecessary __multi3 call for mips64r6 linux kernel)"). Adjust our code accordingly, removing build failures such as: mips64-linux-ld: lib/math/div64.o: in function `mul_u64_add_u64_div_u64': div64.c:(.text+0x84): undefined reference to `__multi3' with the GCC versions affected. Fixes: ebabcf17bcd7 ("MIPS: Implement __multi3 for GCC7 MIPS64r6 builds") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202601140146.hMLODc6v-lkp@intel.com/ Signed-off-by: Maciej W. Rozycki Cc: stable@vger.kernel.org # v4.15+ Reviewed-by: David Laight Signed-off-by: Greg Kroah-Hartman commit 247e1e7e25c8f9172eed5c5911d2595c3355a9bc Author: Maciej W. Rozycki Date: Fri Mar 27 11:38:06 2026 +0000 MIPS: SiByte: Bring back cache initialisation commit d62cf1511743526f530a4c169424e50c757f5a5e upstream. Bring back cache initialisation for Broadcom SiByte SB1 cores, which has been removed causing the kernel to hang at bootstrap right after: Dentry cache hash table entries: 524288 (order: 8, 4194304 bytes, linear) Inode-cache hash table entries: 262144 (order: 7, 2097152 bytes, linear) The cause of the problem is R4k cache handlers are also used by Broadcom SiByte SB1 cores, however with a different cache error exception handler and therefore not using CPU_R4K_CACHE_TLB: obj-$(CONFIG_CPU_R4K_CACHE_TLB) += c-r4k.o cex-gen.o tlb-r4k.o obj-$(CONFIG_CPU_SB1) += c-r4k.o cerr-sb1.o cex-sb1.o tlb-r4k.o (from arch/mips/mm/Makefile). Fixes: bbe4f634f48c ("mips: fix r3k_cache_init build regression") Signed-off-by: Maciej W. Rozycki Cc: stable@vger.kernel.org # v6.8+ Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 075ea208c648cc2bcd616295b711d3637c61de45 Author: Asim Viladi Oglu Manizada Date: Wed Mar 25 09:14:22 2026 +0900 ksmbd: fix OOB write in QUERY_INFO for compound requests commit fda9522ed6afaec45cabc198d8492270c394c7bc upstream. When a compound request such as READ + QUERY_INFO(Security) is received, and the first command (READ) consumes most of the response buffer, ksmbd could write beyond the allocated buffer while building a security descriptor. The root cause was that smb2_get_info_sec() checked buffer space using ppntsd_size from xattr, while build_sec_desc() often synthesized a significantly larger descriptor from POSIX ACLs. This patch introduces smb_acl_sec_desc_scratch_len() to accurately compute the final descriptor size beforehand, performs proper buffer checking with smb2_calc_max_out_buf_len(), and uses exact-sized allocation + iov pinning. Cc: stable@vger.kernel.org Fixes: e2b76ab8b5c9 ("ksmbd: add support for read compound") Signed-off-by: Asim Viladi Oglu Manizada Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit aba0aea354015794e8312dd7efe726967e58aefe Author: hkbinbin Date: Tue Mar 31 05:39:16 2026 +0000 Bluetooth: hci_sync: fix stack buffer overflow in hci_le_big_create_sync commit bc39a094730ce062fa034a529c93147c096cb488 upstream. hci_le_big_create_sync() uses DEFINE_FLEX to allocate a struct hci_cp_le_big_create_sync on the stack with room for 0x11 (17) BIS entries. However, conn->num_bis can hold up to HCI_MAX_ISO_BIS (31) entries — validated against ISO_MAX_NUM_BIS (0x1f) in the caller hci_conn_big_create_sync(). When conn->num_bis is between 18 and 31, the memcpy that copies conn->bis into cp->bis writes up to 14 bytes past the stack buffer, corrupting adjacent stack memory. This is trivially reproducible: binding an ISO socket with bc_num_bis = ISO_MAX_NUM_BIS (31) and calling listen() will eventually trigger hci_le_big_create_sync() from the HCI command sync worker, causing a KASAN-detectable stack-out-of-bounds write: BUG: KASAN: stack-out-of-bounds in hci_le_big_create_sync+0x256/0x3b0 Write of size 31 at addr ffffc90000487b48 by task kworker/u9:0/71 Fix this by changing the DEFINE_FLEX count from the incorrect 0x11 to HCI_MAX_ISO_BIS, which matches the maximum number of BIS entries that conn->bis can actually carry. Fixes: 42ecf1947135 ("Bluetooth: ISO: Do not emit LE BIG Create Sync if previous is pending") Cc: stable@vger.kernel.org Signed-off-by: hkbinbin Reviewed-by: Paul Menzel Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit fa14e0e19820b1bbdb42185c9c4efa950bcffef9 Author: Oleh Konko Date: Tue Mar 31 11:52:12 2026 +0000 Bluetooth: SMP: force responder MITM requirements before building the pairing response commit d05111bfe37bfd8bd4d2dfe6675d6bdeef43f7c7 upstream. smp_cmd_pairing_req() currently builds the pairing response from the initiator auth_req before enforcing the local BT_SECURITY_HIGH requirement. If the initiator omits SMP_AUTH_MITM, the response can also omit it even though the local side still requires MITM. tk_request() then sees an auth value without SMP_AUTH_MITM and may select JUST_CFM, making method selection inconsistent with the pairing policy the responder already enforces. When the local side requires HIGH security, first verify that MITM can be achieved from the IO capabilities and then force SMP_AUTH_MITM in the response in both rsp.auth_req and auth. This keeps the responder auth bits and later method selection aligned. Fixes: 2b64d153a0cc ("Bluetooth: Add MITM mechanism to LE-SMP") Cc: stable@vger.kernel.org Suggested-by: Luiz Augusto von Dentz Signed-off-by: Oleh Konko Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 061ee71ac6b03c9f8432fe49538c3682bfcf4cf3 Author: Oleh Konko Date: Tue Mar 31 11:52:13 2026 +0000 Bluetooth: SMP: derive legacy responder STK authentication from MITM state commit 20756fec2f0108cb88e815941f1ffff88dc286fe upstream. The legacy responder path in smp_random() currently labels the stored STK as authenticated whenever pending_sec_level is BT_SECURITY_HIGH. That reflects what the local service requested, not what the pairing flow actually achieved. For Just Works/Confirm legacy pairing, SMP_FLAG_MITM_AUTH stays clear and the resulting STK should remain unauthenticated even if the local side requested HIGH security. Use the established MITM state when storing the responder STK so the key metadata matches the pairing result. This also keeps the legacy path aligned with the Secure Connections code, which already treats JUST_WORKS/JUST_CFM as unauthenticated. Fixes: fff3490f4781 ("Bluetooth: Fix setting correct authentication information for SMP STK") Cc: stable@vger.kernel.org Signed-off-by: Oleh Konko Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit c314b405dcc4d8b9041124f928f81715d6328bec Author: Junxi Qian Date: Sun Mar 29 23:39:09 2026 +0800 io_uring/net: fix slab-out-of-bounds read in io_bundle_nbufs() commit b948f9d5d3057b01188e36664e7c7604d1c8ecb5 upstream. sqe->len is __u32 but gets stored into sr->len which is int. When userspace passes sqe->len values exceeding INT_MAX (e.g. 0xFFFFFFFF), sr->len overflows to a negative value. This negative value propagates through the bundle recv/send path: 1. io_recv(): sel.val = sr->len (ssize_t gets -1) 2. io_recv_buf_select(): arg.max_len = sel->val (size_t gets 0xFFFFFFFFFFFFFFFF) 3. io_ring_buffers_peek(): buf->len is not clamped because max_len is astronomically large 4. iov[].iov_len = 0xFFFFFFFF flows into io_bundle_nbufs() 5. io_bundle_nbufs(): min_t(int, 0xFFFFFFFF, ret) yields -1, causing ret to increase instead of decrease, creating an infinite loop that reads past the allocated iov[] array This results in a slab-out-of-bounds read in io_bundle_nbufs() from the kmalloc-64 slab, as nbufs increments past the allocated iovec entries. BUG: KASAN: slab-out-of-bounds in io_bundle_nbufs+0x128/0x160 Read of size 8 at addr ffff888100ae05c8 by task exp/145 Call Trace: io_bundle_nbufs+0x128/0x160 io_recv_finish+0x117/0xe20 io_recv+0x2db/0x1160 Fix this by rejecting negative sr->len values early in both io_sendmsg_prep() and io_recvmsg_prep(). Since sqe->len is __u32, any value > INT_MAX indicates overflow and is not a valid length. Fixes: a05d1f625c7a ("io_uring/net: support bundles for send") Cc: stable@vger.kernel.org Signed-off-by: Junxi Qian Link: https://patch.msgid.link/20260329153909.279046-1-qjx1298677004@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 2e8194b4fdee791f7fa0d8a872a95143946b10d4 Author: Sourav Nayak Date: Fri Mar 27 19:58:05 2026 +0530 ALSA: hda/realtek: add quirk for HP Victus 15-fb0xxx commit 1fbf85dbf02c96c318e056fb5b8fc614758fee3c upstream. This adds a mute led quirck for HP Victus 15-fb0xxx (103c:8a3d) model - As it used 0x8(full bright)/0x7f(little dim) for mute led on and other values as 0ff (0x0, 0x4, ...) - So, use ALC245_FIXUP_HP_MUTE_LED_V2_COEFBIT insted for safer approach Cc: Signed-off-by: Sourav Nayak Link: https://patch.msgid.link/20260327142805.17139-1-nonameblank007@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 682b5fd115689885178af43f77ac642943774c97 Author: Zhang Heng Date: Mon Mar 30 15:53:34 2026 +0800 ALSA: hda/realtek: Add quirk for ASUS ROG Strix SCAR 15 commit f1af71d568e55536d9297bfa7907ad497108cf30 upstream. ASUS ROG Strix SCAR 15, like the Strix G15, requires the ALC285_FIXUP_ASUS_G533Z_PINS quirk to work properly. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221247 Cc: Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260330075334.50962-2-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 57698f184e1afbe054b3cd30e2c43a67c11d7f5e Author: Takashi Iwai Date: Sun Mar 29 11:12:37 2026 +0200 ALSA: ctxfi: Fix missing SPDIFI1 index handling commit b045ab3dff97edae6d538eeff900a34c098761f8 upstream. SPDIF1 DAIO type isn't properly handled in daio_device_index() for hw20k2, and it returned -EINVAL, which ended up with the out-of-bounds array access. Follow the hw20k1 pattern and return the proper index for this type, too. Reported-and-tested-by: Karsten Hohmeier Closes: https://lore.kernel.org/20260315155004.15633-1-linux@hohmatik.de Cc: Link: https://patch.msgid.link/20260329091240.420194-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3afa2e67f3523a980a2f90fd63c22322ac2b9ce0 Author: Berk Cem Goksel Date: Sun Mar 29 16:38:25 2026 +0300 ALSA: caiaq: fix stack out-of-bounds read in init_card commit 45424e871abf2a152e247a9cff78359f18dd95c0 upstream. The loop creates a whitespace-stripped copy of the card shortname where `len < sizeof(card->id)` is used for the bounds check. Since sizeof(card->id) is 16 and the local id buffer is also 16 bytes, writing 16 non-space characters fills the entire buffer, overwriting the terminating nullbyte. When this non-null-terminated string is later passed to snd_card_set_id() -> copy_valid_id_string(), the function scans forward with `while (*nid && ...)` and reads past the end of the stack buffer, reading the contents of the stack. A USB device with a product name containing many non-ASCII, non-space characters (e.g. multibyte UTF-8) will reliably trigger this as follows: BUG: KASAN: stack-out-of-bounds in copy_valid_id_string sound/core/init.c:696 [inline] BUG: KASAN: stack-out-of-bounds in snd_card_set_id_no_lock+0x698/0x74c sound/core/init.c:718 The off-by-one has been present since commit bafeee5b1f8d ("ALSA: snd_usb_caiaq: give better shortname") from June 2009 (v2.6.31-rc1), which first introduced this whitespace-stripping loop. The original code never accounted for the null terminator when bounding the copy. Fix this by changing the loop bound to `sizeof(card->id) - 1`, ensuring at least one byte remains as the null terminator. Fixes: bafeee5b1f8d ("ALSA: snd_usb_caiaq: give better shortname") Cc: stable@vger.kernel.org Cc: Andrey Konovalov Reported-by: Berk Cem Goksel Signed-off-by: Berk Cem Goksel Link: https://patch.msgid.link/20260329133825.581585-1-berkcgoksel@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1933249263c3a98df79992f61a566476e4163bcc Author: Eric Biggers Date: Wed Mar 25 20:29:20 2026 -0700 lib/crypto: chacha: Zeroize permuted_state before it leaves scope commit e5046823f8fa3677341b541a25af2fcb99a5b1e0 upstream. Since the ChaCha permutation is invertible, the local variable 'permuted_state' is sufficient to compute the original 'state', and thus the key, even after the permutation has been done. While the kernel is quite inconsistent about zeroizing secrets on the stack (and some prominent userspace crypto libraries don't bother at all since it's not guaranteed to work anyway), the kernel does try to do it as a best practice, especially in cases involving the RNG. Thus, explicitly zeroize 'permuted_state' before it goes out of scope. Fixes: c08d0e647305 ("crypto: chacha20 - Add a generic ChaCha20 stream cipher implementation") Cc: stable@vger.kernel.org Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260326032920.39408-1-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit b49bf41b4114842addf1f609c1a30c2f5e8925b8 Author: Cheng-Yang Chou Date: Sat Mar 21 18:54:58 2026 +0800 sched_ext: Fix inconsistent NUMA node lookup in scx_select_cpu_dfl() commit db08b1940f4beb25460b4a4e9da3446454f2e8fe upstream. In the WAKE_SYNC path of scx_select_cpu_dfl(), waker_node was computed with cpu_to_node(), while node (for prev_cpu) was computed with scx_cpu_node_if_enabled(). When scx_builtin_idle_per_node is disabled, idle_cpumask(waker_node) is called with a real node ID even though per-node idle tracking is disabled, resulting in undefined behavior. Fix by using scx_cpu_node_if_enabled() for waker_node as well, ensuring both variables are computed consistently. Fixes: 48849271e6611 ("sched_ext: idle: Per-node idle cpumasks") Cc: stable@vger.kernel.org # v6.15+ Signed-off-by: Cheng-Yang Chou Reviewed-by: Andrea Righi Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 10c13c111d0d7f8e101c742feff264fc98e3f9f7 Author: Srinivasan Shanmugam Date: Sat Mar 21 17:25:14 2026 +0530 drm/amd/display: Fix NULL pointer dereference in dcn401_init_hw() commit e927b36ae18b66b49219eaa9f46edc7b4fdbb25e upstream. dcn401_init_hw() assumes that update_bw_bounding_box() is valid when entering the update path. However, the existing condition: ((!fams2_enable && update_bw_bounding_box) || freq_changed) does not guarantee this, as the freq_changed branch can evaluate to true independently of the callback pointer. This can result in calling update_bw_bounding_box() when it is NULL. Fix this by separating the update condition from the pointer checks and ensuring the callback, dc->clk_mgr, and bw_params are validated before use. Fixes the below: ../dc/hwss/dcn401/dcn401_hwseq.c:367 dcn401_init_hw() error: we previously assumed 'dc->res_pool->funcs->update_bw_bounding_box' could be null (see line 362) Fixes: ca0fb243c3bb ("drm/amd/display: Underflow Seen on DCN401 eGPU") Cc: Daniel Sa Cc: Alvin Lee Cc: Roman Li Cc: Alex Hung Cc: Tom Chung Cc: Dan Carpenter Cc: Aurabindo Pillai Signed-off-by: Srinivasan Shanmugam Reviewed-by: Alex Hung Signed-off-by: Alex Deucher (cherry picked from commit 86117c5ab42f21562fedb0a64bffea3ee5fcd477) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ce47541f5c4088efaf2b79c203ffdcdfff9596cf Author: Ernestas Kulik Date: Tue Mar 24 13:07:16 2026 +0200 USB: serial: option: add MeiG Smart SRM825WN commit e8d0ed37bd51da52da6225d278e330c2f18a6198 upstream. Add support for the SDX62-based MeiG Smart SRM825WN module. If#= 0: RNDIS If#= 1: RNDIS If#= 2: Diag If#= 3: AT If#= 4: AT If#= 5: NMEA T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 19 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2dee ProdID=4d38 Rev= 5.04 S: Manufacturer=MEIG S: Product=LTE-A Module S: SerialNumber=da47a175 C:* #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=500mA A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=03 I:* If#= 0 Alt= 0 #EPs= 1 Cls=e0(wlcon) Sub=01 Prot=03 Driver=rndis_host E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=32ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=88(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Ernestas Kulik Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit dd90880eb5ec5442b37eb2b95688f4a63f4883e3 Author: Alexey Velichayshiy Date: Sat Feb 7 18:03:22 2026 +0300 wifi: iwlwifi: mvm: fix potential out-of-bounds read in iwl_mvm_nd_match_info_handler() commit 744fabc338e87b95c4d1ff7c95bc8c0f834c6d99 upstream. The memcpy function assumes the dynamic array notif->matches is at least as large as the number of bytes to copy. Otherwise, results->matches may contain unwanted data. To guarantee safety, extend the validation in one of the checks to ensure sufficient packet length. Found by Linux Verification Center (linuxtesting.org) with SVACE. Cc: stable@vger.kernel.org Fixes: 5ac54afd4d97 ("wifi: iwlwifi: mvm: Add handling for scan offload match info notification") Signed-off-by: Alexey Velichayshiy Link: https://patch.msgid.link/20260207150335.1013646-1-a.velichayshiy@ispras.ru Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit d8388614de613c28eeb659c10115060a83739924 Author: Yasuaki Torimaru Date: Tue Mar 24 19:06:24 2026 +0900 wifi: wilc1000: fix u8 overflow in SSID scan buffer size calculation commit d049e56b1739101d1c4d81deedb269c52a8dbba0 upstream. The variable valuesize is declared as u8 but accumulates the total length of all SSIDs to scan. Each SSID contributes up to 33 bytes (IEEE80211_MAX_SSID_LEN + 1), and with WILC_MAX_NUM_PROBED_SSID (10) SSIDs the total can reach 330, which wraps around to 74 when stored in a u8. This causes kmalloc to allocate only 75 bytes while the subsequent memcpy writes up to 331 bytes into the buffer, resulting in a 256-byte heap buffer overflow. Widen valuesize from u8 to u32 to accommodate the full range. Fixes: c5c77ba18ea6 ("staging: wilc1000: Add SDIO/SPI 802.11 driver") Cc: stable@vger.kernel.org Signed-off-by: Yasuaki Torimaru Link: https://patch.msgid.link/20260324100624.983458-1-yasuakitorimaru@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 20e2418b98369e9b1977e043661b85ee1037b675 Author: Alice Ryhl Date: Sat Mar 14 11:19:51 2026 +0000 rust_binder: use AssertSync for BINDER_VM_OPS commit ec327abae5edd1d5b60ea9f920212970133171d2 upstream. When declaring an immutable global variable in Rust, the compiler checks that it looks thread safe, because it is generally safe to access said global variable. When using C bindings types for these globals, we don't really want this check, because it is conservative and assumes pointers are not thread safe. In the case of BINDER_VM_OPS, this is a challenge when combined with the patch 'userfaultfd: introduce vm_uffd_ops' [1], which introduces a pointer field to vm_operations_struct. It previously only held function pointers, which are considered thread safe. Rust Binder should not be assuming that vm_operations_struct contains no pointer fields, so to fix this, use AssertSync (which Rust Binder has already declared for another similar global of type struct file_operations with the same problem). This ensures that even if another commit adds a pointer field to vm_operations_struct, this does not cause problems. Fixes: 8ef2c15aeae0 ("rust_binder: check ownership before using vma") Cc: stable Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202603121235.tpnRxFKO-lkp@intel.com/ Link: https://lore.kernel.org/r/20260306171815.3160826-8-rppt@kernel.org [1] Signed-off-by: Alice Ryhl Reviewed-by: Gary Guo Link: https://patch.msgid.link/20260314111951.4139029-1-aliceryhl@google.com Signed-off-by: Greg Kroah-Hartman commit f0e441be08a2eab10b2d06fccfa267ee599dd6b3 Author: Greg Kroah-Hartman Date: Tue Mar 24 17:42:51 2026 +0100 drm/ioc32: stop speculation on the drm_compat_ioctl path commit f8995c2df519f382525ca4bc90553ad2ec611067 upstream. The drm compat ioctl path takes a user controlled pointer, and then dereferences it into a table of function pointers, the signature method of spectre problems. Fix this up by calling array_index_nospec() on the index to the function pointer list. Fixes: 505b5240329b ("drm/ioctl: Fix Spectre v1 vulnerabilities") Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Simona Vetter Cc: stable Assisted-by: gkh_clanker_2000 Signed-off-by: Greg Kroah-Hartman Acked-by: Thomas Zimmermann Acked-by: Maxime Ripard Reviewed-by: Simona Vetter Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/2026032451-playing-rummage-8fa2@gregkh Signed-off-by: Greg Kroah-Hartman commit 1200f4240c07d4b507eebb3a7577ba1712fd3b7b Author: Sunil V L Date: Tue Mar 3 11:46:05 2026 +0530 ACPI: RIMT: Add dependency between iommu and devices [ Upstream commit 9156585280f161fc1c3552cf1860559edb2bb7e3 ] EPROBE_DEFER ensures IOMMU devices are probed before the devices that depend on them. During shutdown, however, the IOMMU may be removed first, leading to issues. To avoid this, a device link is added which enforces the correct removal order. Fixes: 8f7729552582 ("ACPI: RISC-V: Add support for RIMT") Signed-off-by: Sunil V L Link: https://patch.msgid.link/20260303061605.722949-1-sunilvl@oss.qualcomm.com Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit 50392cdfe95e0cd40b03ed95b50d3d53be3fa624 Author: Zishun Yi Date: Mon Mar 23 00:00:22 2026 +0800 riscv: Reset pmm when PR_TAGGED_ADDR_ENABLE is not set [ Upstream commit 3033b2b1e3949274f33a140e2a97571b5a307298 ] In set_tagged_addr_ctrl(), when PR_TAGGED_ADDR_ENABLE is not set, pmlen is correctly set to 0, but it forgets to reset pmm. This results in the CPU pmm state not corresponding to the software pmlen state. Fix this by resetting pmm along with pmlen. Fixes: 2e1743085887 ("riscv: Add support for the tagged address ABI") Signed-off-by: Zishun Yi Reviewed-by: Samuel Holland Link: https://patch.msgid.link/20260322160022.21908-1-vulab@iscas.ac.cn Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit e1425ff578c4a4b83654402071de4413af71e2ad Author: Paul Walmsley Date: Mon Mar 23 17:43:47 2026 -0600 riscv: kgdb: fix several debug register assignment bugs [ Upstream commit 834911eb8eef2501485d819b4eabebadc25c3497 ] Fix several bugs in the RISC-V kgdb implementation: - The element of dbg_reg_def[] that is supposed to pertain to the S1 register embeds instead the struct pt_regs offset of the A1 register. Fix this to use the S1 register offset in struct pt_regs. - The sleeping_thread_to_gdb_regs() function copies the value of the S10 register into the gdb_regs[] array element meant for the S9 register, and copies the value of the S11 register into the array element meant for the S10 register. It also neglects to copy the value of the S11 register. Fix all of these issues. Fixes: fe89bd2be8667 ("riscv: Add KGDB support") Cc: Vincent Chen Link: https://patch.msgid.link/fde376f8-bcfd-bfe4-e467-07d8f7608d05@kernel.org Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit e435a30ca6fe14c9611b1fc731c98a6d28410247 Author: Ian Rogers Date: Thu Mar 12 12:43:05 2026 -0700 perf/x86: Fix potential bad container_of in intel_pmu_hw_config [ Upstream commit dbde07f06226438cd2cf1179745fa1bec5d8914a ] Auto counter reload may have a group of events with software events present within it. The software event PMU isn't the x86_hybrid_pmu and a container_of operation in intel_pmu_set_acr_caused_constr (via the hybrid helper) could cause out of bound memory reads. Avoid this by guarding the call to intel_pmu_set_acr_caused_constr with an is_x86_event check. Fixes: ec980e4facef ("perf/x86/intel: Support auto counter reload") Signed-off-by: Ian Rogers Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Thomas Falcon Link: https://patch.msgid.link/20260312194305.1834035-1-irogers@google.com Signed-off-by: Sasha Levin commit 87573883c30f1a8555ff720836bb6ea231058539 Author: Peter Zijlstra Date: Wed Apr 1 15:20:20 2026 +0200 sched/fair: Fix zero_vruntime tracking fix [ Upstream commit 1319ea57529e131822bab56bf417c8edc2db9ae8 ] John reported that stress-ng-yield could make his machine unhappy and managed to bisect it to commit b3d99f43c72b ("sched/fair: Fix zero_vruntime tracking"). The combination of yield and that commit was specific enough to hypothesize the following scenario: Suppose we have 2 runnable tasks, both doing yield. Then one will be eligible and one will not be, because the average position must be in between these two entities. Therefore, the runnable task will be eligible, and be promoted a full slice (all the tasks do is yield after all). This causes it to jump over the other task and now the other task is eligible and current is no longer. So we schedule. Since we are runnable, there is no {de,en}queue. All we have is the __{en,de}queue_entity() from {put_prev,set_next}_task(). But per the fingered commit, those two no longer move zero_vruntime. All that moves zero_vruntime are tick and full {de,en}queue. This means, that if the two tasks playing leapfrog can reach the critical speed to reach the overflow point inside one tick's worth of time, we're up a creek. Additionally, when multiple cgroups are involved, there is no guarantee the tick will in fact hit every cgroup in a timely manner. Statistically speaking it will, but that same statistics does not rule out the possibility of one cgroup not getting a tick for a significant amount of time -- however unlikely. Therefore, just like with the yield() case, force an update at the end of every slice. This ensures the update is never more than a single slice behind and the whole thing is within 2 lag bounds as per the comment on entity_key(). Fixes: b3d99f43c72b ("sched/fair: Fix zero_vruntime tracking") Reported-by: John Stultz Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Vincent Guittot Tested-by: K Prateek Nayak Tested-by: John Stultz Link: https://patch.msgid.link/20260401132355.081530332@infradead.org Signed-off-by: Sasha Levin commit a99f94e4f28a3c289bd397d521de1187b6320158 Author: Shiji Yang Date: Tue Feb 24 10:22:50 2026 +0800 mips: ralink: update CPU clock index [ Upstream commit 43985a62bab9d35e5e9af41118ce2f44c01b97d2 ] Update CPU clock index to match the clock driver changes. Fixes: d34db686a3d7 ("clk: ralink: mtmips: fix clocks probe order in oldest ralink SoCs") Signed-off-by: Mieczyslaw Nalewaj Signed-off-by: Shiji Yang Reviewed-by: Sergio Paracuellos Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit d6fbc5750f382b23da83e2bd385ac67f3bef9942 Author: Corey Hickey Date: Tue Mar 31 14:49:06 2026 -0700 hwmon: (asus-ec-sensors) Fix T_Sensor for PRIME X670E-PRO WIFI [ Upstream commit cffff6df669a438ecac506dadd49a53d4475a796 ] On the Asus PRIME X670E-PRO WIFI, the driver reports a constant value of zero for T_Sensor. On this board, the register for T_Sensor is at a different address, as found by experimentation and confirmed by comparison to an independent temperature reading. * sensor disconnected: -62.0°C * ambient temperature: +22.0°C * held between fingers: +30.0°C Introduce SENSOR_TEMP_T_SENSOR_ALT1 to support the PRIME X670E-PRO WIFI without causing a regression for other 600-series boards Fixes: e0444758dd1b ("hwmon: (asus-ec-sensors) add PRIME X670E-PRO WIFI") Signed-off-by: Corey Hickey Link: https://lore.kernel.org/r/20260331215414.368785-1-bugfood-ml@fatooh.org [groeck: Fixed typo, updated Fixes: reference] Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit d16f8716c927fe18aa2b8056d7530cfd4a37c903 Author: Chen Ni Date: Wed Mar 11 14:46:52 2026 +0800 drm/sysfb: Fix efidrm error handling and memory type mismatch [ Upstream commit 5e77923a3eb39cce91bf08ed7670f816bf86d4af ] Fix incorrect error checking and memory type confusion in efidrm_device_create(). devm_memremap() returns error pointers, not NULL, and returns system memory while devm_ioremap() returns I/O memory. The code incorrectly passes system memory to iosys_map_set_vaddr_iomem(). Restructure to handle each memory type separately. Use devm_ioremap*() with ERR_PTR(-ENXIO) for WC/UC, and devm_memremap() with ERR_CAST() for WT/WB. Fixes: 32ae90c66fb6 ("drm/sysfb: Add efidrm for EFI displays") Signed-off-by: Chen Ni Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260311064652.2903449-1-nichen@iscas.ac.cn Signed-off-by: Sasha Levin commit 6205de166dfb258209e23c5d2b5c7d35c145e833 Author: Sanman Pradhan Date: Thu Mar 26 22:45:29 2026 +0000 hwmon: (occ) Fix missing newline in occ_show_extended() [ Upstream commit 09773978879ecf71a7990fe9a28ce4eb92bce645 ] In occ_show_extended() case 0, when the EXTN_FLAG_SENSOR_ID flag is set, the sysfs_emit format string "%u" is missing the trailing newline that the sysfs ABI expects. The else branch correctly uses "%4phN\n", and all other show functions in this file include the trailing newline. Add the missing "\n" for consistency and correct sysfs output. Fixes: c10e753d43eb ("hwmon (occ): Add sensor types and versions") Signed-off-by: Sanman Pradhan Link: https://lore.kernel.org/r/20260326224510.294619-3-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit ee4c064e37d4d0ddc5a7580933dbe79a2c6acafc Author: Felix Gu Date: Sun Mar 22 22:28:45 2026 +0800 spi: amlogic: spifc-a4: unregister ECC engine on probe failure and remove() callback [ Upstream commit b0dc7e7c56573e7a52080f25f3179a45f3dd7e6f ] aml_sfc_probe() registers the on-host NAND ECC engine, but teardown was missing from both probe unwind and remove-time cleanup. Add a devm cleanup action after successful registration so nand_ecc_unregister_on_host_hw_engine() runs automatically on probe failures and during device removal. Fixes: 4670db6f32e9 ("spi: amlogic: add driver for Amlogic SPI Flash Controller") Signed-off-by: Felix Gu Link: https://patch.msgid.link/20260322-spifc-a4-v1-1-2dc5ebcbe0a9@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fdbfa1bf2c759c892429aa506b9b0a562d208533 Author: Sanman Pradhan Date: Mon Mar 30 15:56:40 2026 +0000 hwmon: (tps53679) Fix device ID comparison and printing in tps53676_identify() [ Upstream commit ca34ee6d0307a0b4e52c870dfc1bb8a3c3eb956e ] tps53676_identify() uses strncmp() to compare the device ID buffer against a byte sequence containing embedded non-printable bytes (\x53\x67\x60). strncmp() is semantically wrong for binary data comparison; use memcmp() instead. Additionally, the buffer from i2c_smbus_read_block_data() is not NUL-terminated, so printing it with "%s" in the error path is undefined behavior and may read past the buffer. Use "%*ph" to hex-dump the actual bytes returned. Per the datasheet, the expected device ID is the 6-byte sequence 54 49 53 67 60 00 ("TI\x53\x67\x60\x00"), so compare all 6 bytes including the trailing NUL. Fixes: cb3d37b59012 ("hwmon: (pmbus/tps53679) Add support for TI TPS53676") Signed-off-by: Sanman Pradhan Link: https://lore.kernel.org/r/20260330155618.77403-1-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 9e962e68a9d26135af67c423767c0983d9ad94c3 Author: Daniele Ceraolo Spurio Date: Tue Mar 24 08:37:22 2026 -0700 drm/xe/pxp: Clear restart flag in pxp_start after jumping back [ Upstream commit 76903b2057c8677c2c006e87fede15f496555dc0 ] If we don't clear the flag we'll keep jumping back at the beginning of the function once we reach the end. Fixes: ccd3c6820a90 ("drm/xe/pxp: Decouple queue addition from PXP start") Signed-off-by: Daniele Ceraolo Spurio Cc: Julia Filipchuk Reviewed-by: Julia Filipchuk Link: https://patch.msgid.link/20260324153718.3155504-9-daniele.ceraolospurio@intel.com (cherry picked from commit 0850ec7bb2459602351639dccf7a68a03c9d1ee0) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 5633454e28d306e27ba70a107b23052da7b322c2 Author: Daniele Ceraolo Spurio Date: Tue Mar 24 08:37:21 2026 -0700 drm/xe/pxp: Remove incorrect handling of impossible state during suspend [ Upstream commit 4fed244954c2dc9aafa333d08f66b14345225e03 ] The default case of the PXP suspend switch is incorrectly exiting without releasing the lock. However, this case is impossible to hit because we're switching on an enum and all the valid enum values have their own cases. Therefore, we can just get rid of the default case and rely on the compiler to warn us if a new enum value is added and we forget to add it to the switch. Fixes: 51462211f4a9 ("drm/xe/pxp: add PXP PM support") Signed-off-by: Daniele Ceraolo Spurio Cc: Alan Previn Teres Alexis Cc: Julia Filipchuk Reviewed-by: Julia Filipchuk Link: https://patch.msgid.link/20260324153718.3155504-8-daniele.ceraolospurio@intel.com (cherry picked from commit f1b5a77fc9b6a90cd9a5e3db9d4c73ae1edfcfac) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit ec4530967192064b3df3e44e93f71b83b1a549b0 Author: Daniele Ceraolo Spurio Date: Tue Mar 24 08:37:20 2026 -0700 drm/xe/pxp: Clean up termination status on failure [ Upstream commit e2628e670bb0923fcdc00828bfcd67b26a7df020 ] If the PXP HW termination fails during PXP start, the normal completion code won't be called, so the termination will remain uncomplete. To avoid unnecessary waits, mark the termination as completed from the error path. Note that we already do this if the termination fails when handling a termination irq from the HW. Fixes: f8caa80154c4 ("drm/xe/pxp: Add PXP queue tracking and session start") Signed-off-by: Daniele Ceraolo Spurio Cc: Alan Previn Teres Alexis Cc: Julia Filipchuk Reviewed-by: Julia Filipchuk Link: https://patch.msgid.link/20260324153718.3155504-7-daniele.ceraolospurio@intel.com (cherry picked from commit 5d9e708d2a69ab1f64a17aec810cd7c70c5b9fab) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit e8298e0cc68de7fb33926f2f473eeee19a3e9df9 Author: Felix Gu Date: Sun Mar 29 00:07:06 2026 +0800 spi: stm32-ospi: Fix reset control leak on probe error [ Upstream commit 5a570c8d6e55689253f6fcc4a198c56cca7e39d6 ] When spi_register_controller() fails after reset_control_acquire() succeeds, the reset control is never released. This causes a resource leak in the error path. Add the missing reset_control_release() call in the error path. Fixes: cf2c3eceb757 ("spi: stm32-ospi: Make usage of reset_control_acquire/release() API") Signed-off-by: Felix Gu Reviewed-by: Patrice Chotard Link: https://patch.msgid.link/20260329-stm32-ospi-v1-1-142122466412@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b4ec54c974c6ea68b309989dcc3d3511068f45f3 Author: Felix Gu Date: Sun Mar 29 19:14:05 2026 +0800 spi: stm32-ospi: Fix resource leak in remove() callback [ Upstream commit 73cd1f97946ae3796544448ff12c07f399bb2881 ] The remove() callback returned early if pm_runtime_resume_and_get() failed, skipping the cleanup of spi controller and other resources. Remove the early return so cleanup completes regardless of PM resume result. Fixes: 79b8a705e26c ("spi: stm32: Add OSPI driver") Signed-off-by: Felix Gu Reviewed-by: Patrice Chotard Link: https://patch.msgid.link/20260329-ospi-v1-1-cc8cf1c82c4a@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3a8b66a84f0580061c342a12889a037845b0a9c4 Author: Jamie Gibbons Date: Thu Mar 26 17:02:34 2026 +0000 dt-bindings: gpio: fix microchip #interrupt-cells [ Upstream commit 6b5ef8c88854b343b733b574ea8754c9dab61f41 ] The GPIO controller on PolarFire SoC supports more than one type of interrupt and needs two interrupt cells. Fixes: 735806d8a68e9 ("dt-bindings: gpio: add bindings for microchip mpfs gpio") Signed-off-by: Jamie Gibbons Signed-off-by: Conor Dooley Link: https://patch.msgid.link/20260326-wise-gumdrop-49217723a72a@spud Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit dfe3a785ae7fce28dab809944a9eb47eca971328 Author: Sanman Pradhan Date: Sun Mar 29 17:09:53 2026 +0000 hwmon: (ltc4286) Add missing MODULE_IMPORT_NS("PMBUS") [ Upstream commit a9d2fbd3ad0e6ac588386e699beeccfe7516755f ] ltc4286.c uses PMBus core symbols exported in the PMBUS namespace, such as pmbus_do_probe(), but does not declare MODULE_IMPORT_NS("PMBUS"). Add the missing namespace import to avoid modpost warnings. Fixes: 0c459759ca97 ("hwmon: (pmbus) Add ltc4286 driver") Signed-off-by: Sanman Pradhan Link: https://lore.kernel.org/r/20260329170925.34581-5-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 13b0cb9963652f132ba21840c30e45132535d937 Author: Sanman Pradhan Date: Sun Mar 29 17:09:48 2026 +0000 hwmon: (pxe1610) Check return value of page-select write in probe [ Upstream commit ccf70c41e562b29d1c05d1bbf53391785e09c6fb ] pxe1610_probe() writes PMBUS_PAGE to select page 0 but does not check the return value. If the write fails, subsequent register reads operate on an indeterminate page, leading to silent misconfiguration. Check the return value and propagate the error using dev_err_probe(), which also handles -EPROBE_DEFER correctly without log spam. Fixes: 344757bac526 ("hwmon: (pmbus) Add Infineon PXE1610 VR driver") Signed-off-by: Sanman Pradhan Link: https://lore.kernel.org/r/20260329170925.34581-4-sanman.pradhan@hpe.com [groeck: Fix "Fixes" SHA] Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 79b7e588399bb55f4c10bea6ca41b6c3b944d2bb Author: Sanman Pradhan Date: Sun Mar 29 17:09:40 2026 +0000 hwmon: (tps53679) Fix array access with zero-length block read [ Upstream commit 0e211f6aaa6a00fd0ee0c1eea5498f168c6725e6 ] i2c_smbus_read_block_data() can return 0, indicating a zero-length read. When this happens, tps53679_identify_chip() accesses buf[ret - 1] which is buf[-1], reading one byte before the buffer on the stack. Fix by changing the check from "ret < 0" to "ret <= 0", treating a zero-length read as an error (-EIO), which prevents the out-of-bounds array access. Also fix a typo in the adjacent comment: "if present" instead of duplicate "if". Fixes: 75ca1e5875fe ("hwmon: (pmbus/tps53679) Add support for TPS53685") Signed-off-by: Sanman Pradhan Link: https://lore.kernel.org/r/20260329170925.34581-2-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 040a1e7e0e2f01851fec1dd2d96906f8636a9f75 Author: Qi Tang Date: Mon Mar 30 00:49:36 2026 +0800 io_uring/rsrc: reject zero-length fixed buffer import [ Upstream commit 111a12b422a8cfa93deabaef26fec48237163214 ] validate_fixed_range() admits buf_addr at the exact end of the registered region when len is zero, because the check uses strict greater-than (buf_end > imu->ubuf + imu->len). io_import_fixed() then computes offset == imu->len, which causes the bvec skip logic to advance past the last bio_vec entry and read bv_offset from out-of-bounds slab memory. Return early from io_import_fixed() when len is zero. A zero-length import has no data to transfer and should not walk the bvec array at all. BUG: KASAN: slab-out-of-bounds in io_import_reg_buf+0x697/0x7f0 Read of size 4 at addr ffff888002bcc254 by task poc/103 Call Trace: io_import_reg_buf+0x697/0x7f0 io_write_fixed+0xd9/0x250 __io_issue_sqe+0xad/0x710 io_issue_sqe+0x7d/0x1100 io_submit_sqes+0x86a/0x23c0 __do_sys_io_uring_enter+0xa98/0x1590 Allocated by task 103: The buggy address is located 12 bytes to the right of allocated 584-byte region [ffff888002bcc000, ffff888002bcc248) Fixes: 8622b20f23ed ("io_uring: add validate_fixed_range() for validate fixed buffer") Signed-off-by: Qi Tang Link: https://patch.msgid.link/20260329164936.240871-1-tpluszz77@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f403094d9075d7c565a3d81002b781c325cb3c07 Author: Youssef Samir Date: Thu Feb 5 13:34:14 2026 +0100 accel/qaic: Handle DBC deactivation if the owner went away [ Upstream commit 2feec5ae5df785658924ab6bd91280dc3926507c ] When a DBC is released, the device sends a QAIC_TRANS_DEACTIVATE_FROM_DEV transaction to the host over the QAIC_CONTROL MHI channel. QAIC handles this by calling decode_deactivate() to release the resources allocated for that DBC. Since that handling is done in the qaic_manage_ioctl() context, if the user goes away before receiving and handling the deactivation, the host will be out-of-sync with the DBCs available for use, and the DBC resources will not be freed unless the device is removed. If another user loads and requests to activate a network, then the device assigns the same DBC to that network, QAIC will "indefinitely" wait for dbc->in_use = false, leading the user process to hang. As a solution to this, handle QAIC_TRANS_DEACTIVATE_FROM_DEV transactions that are received after the user has gone away. Fixes: 129776ac2e38 ("accel/qaic: Add control path") Signed-off-by: Youssef Samir Reviewed-by: Lizhi Hou Reviewed-by: Jeff Hugo Signed-off-by: Jeff Hugo Link: https://patch.msgid.link/20260205123415.3870898-1-youssef.abdulrahman@oss.qualcomm.com Signed-off-by: Sasha Levin commit 33b54c7793cf7a347b7d643efc175f933778cf8d Author: Barnabás Pőcze Date: Tue Mar 10 20:44:03 2026 +0000 gpiolib: clear requested flag if line is invalid [ Upstream commit 6df6ea4b3d1567dbe6442f308735c23b63007c7f ] If `gpiochip_line_is_valid()` fails, then `-EINVAL` is returned, but `desc->flags` will have `GPIOD_FLAG_REQUESTED` set, which will result in subsequent calls misleadingly returning `-EBUSY`. Fix that by clearing the flag in case of failure. Fixes: a501624864f3 ("gpio: Respect valid_mask when requesting GPIOs") Signed-off-by: Barnabás Pőcze Reviewed-by: Matti Vaittinen Link: https://patch.msgid.link/20260310204359.1202451-1-pobrn@protonmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 606f88c162b274be03b6c8e9785dc3f1229f482b Author: Bartosz Golaszewski Date: Thu Oct 16 11:09:25 2025 +0200 gpio: rename gpio_chip_hwgpio() to gpiod_hwgpio() [ Upstream commit df900536e85819f6168783d5f6b3908d47811fdd ] This function takes a GPIO descriptor as first argument. Make its naming consistent with the rest of the GPIO codebase and use the gpiod_ prefix. Reviewed-by: Linus Walleij Reviewed-by: Andrew Jeffery Link: https://lore.kernel.org/r/20251016-aspeed-gpiolib-include-v1-1-31201c06d124@linaro.org Signed-off-by: Bartosz Golaszewski Stable-dep-of: 6df6ea4b3d15 ("gpiolib: clear requested flag if line is invalid") Signed-off-by: Sasha Levin commit 9e5495d216bff04c91fd22448c2e0fc6b3b81486 Author: David Lechner Date: Sat Feb 14 16:33:54 2026 -0600 iio: imu: bno055: fix BNO055_SCAN_CH_COUNT off by one [ Upstream commit 773ef9f95385bae52dcb7fd129fefba3a71a04db ] Fix an off-by-one error in the BNO055_SCAN_CH_COUNT macro. The count is derived by taking the difference of the last and first register addresses, dividing by the size of each channel (2 bytes). It needs to also add 1 to account for the fact that the count is inclusive of both the first and last channels. Thanks to the aligned_s64 timestamp field, there was already extra padding in the buffer, so there were no runtime issues caused by this bug. Fixes: 4aefe1c2bd0c ("iio: imu: add Bosch Sensortec BNO055 core driver") Signed-off-by: David Lechner Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 89c3a4ba60309cc6333a8f3940a1866fc21a9000 Author: Maarten Lankhorst Date: Thu Mar 26 08:07:29 2026 +0100 Revert "drm: Fix use-after-free on framebuffers and property blobs when calling drm_dev_unplug" commit 45ebe43ea00d6b9f5b3e0db9c35b8ca2a96b7e70 upstream. This reverts commit 6bee098b91417654703e17eb5c1822c6dfd0c01d. Den 2026-03-25 kl. 22:11, skrev Simona Vetter: > On Wed, Mar 25, 2026 at 10:26:40AM -0700, Guenter Roeck wrote: >> Hi, >> >> On Fri, Mar 13, 2026 at 04:17:27PM +0100, Maarten Lankhorst wrote: >>> When trying to do a rather aggressive test of igt's "xe_module_load >>> --r reload" with a full desktop environment and game running I noticed >>> a few OOPSes when dereferencing freed pointers, related to >>> framebuffers and property blobs after the compositor exits. >>> >>> Solve this by guarding the freeing in drm_file with drm_dev_enter/exit, >>> and immediately put the references from struct drm_file objects during >>> drm_dev_unplug(). >>> >> >> With this patch in v6.18.20, I get the warning backtraces below. >> The backtraces are gone with the patch reverted. > > Yeah, this needs to be reverted, reasoning below. Maarten, can you please > take care of that and feed the revert through the usual channels? I don't > think it's critical enough that we need to fast-track this into drm.git > directly. > > Quoting the patch here again: > >> drivers/gpu/drm/drm_file.c | 5 ++++- >> drivers/gpu/drm/drm_mode_config.c | 9 ++++++--- >> 2 files changed, 10 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c >> index ec820686b3021..f52141f842a1f 100644 >> --- a/drivers/gpu/drm/drm_file.c >> +++ b/drivers/gpu/drm/drm_file.c >> @@ -233,6 +233,7 @@ static void drm_events_release(struct drm_file *file_priv) >> void drm_file_free(struct drm_file *file) >> { >> struct drm_device *dev; >> + int idx; >> >> if (!file) >> return; >> @@ -249,9 +250,11 @@ void drm_file_free(struct drm_file *file) >> >> drm_events_release(file); >> >> - if (drm_core_check_feature(dev, DRIVER_MODESET)) { >> + if (drm_core_check_feature(dev, DRIVER_MODESET) && >> + drm_dev_enter(dev, &idx)) { > > This is misplaced for two reasons: > > - Even if we'd want to guarantee that we hold a drm_dev_enter/exit > reference during framebuffer teardown, we'd need to do this > _consistently over all callsites. Not ad-hoc in just one place that a > testcase hits. This also means kerneldoc updates of the relevant hooks > and at least a bunch of acks from other driver people to document the > consensus. > > - More importantly, this is driver responsibilities in general unless we > have extremely good reasons to the contrary. Which means this must be > placed in xe. > >> drm_fb_release(file); >> drm_property_destroy_user_blobs(dev, file); >> + drm_dev_exit(idx); >> } >> >> if (drm_core_check_feature(dev, DRIVER_SYNCOBJ)) >> diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c >> index 84ae8a23a3678..e349418978f79 100644 >> --- a/drivers/gpu/drm/drm_mode_config.c >> +++ b/drivers/gpu/drm/drm_mode_config.c >> @@ -583,10 +583,13 @@ void drm_mode_config_cleanup(struct drm_device *dev) >> */ >> WARN_ON(!list_empty(&dev->mode_config.fb_list)); >> list_for_each_entry_safe(fb, fbt, &dev->mode_config.fb_list, head) { >> - struct drm_printer p = drm_dbg_printer(dev, DRM_UT_KMS, "[leaked fb]"); >> + if (list_empty(&fb->filp_head) || drm_framebuffer_read_refcount(fb) > 1) { >> + struct drm_printer p = drm_dbg_printer(dev, DRM_UT_KMS, "[leaked fb]"); > > This is also wrong: > > - Firstly, it's a completely independent bug, we do not smash two bugfixes > into one patch. > > - Secondly, it's again a driver bug: drm_mode_cleanup must be called when > the last drm_device reference disappears (hence the existence of > drmm_mode_config_init), not when the driver gets unbound. The fact that > this shows up in a callchain from a devres cleanup means the intel > driver gets this wrong (like almost everyone else because historically > we didn't know better). > > If we don't follow this rule, then we get races with this code here > running concurrently with drm_file fb cleanups, which just does not > work. Review pointed that out, but then shrugged it off with a confused > explanation: > > https://lore.kernel.org/all/e61e64c796ccfb17ae673331a3df4b877bf42d82.camel@linux.intel.com/ > > Yes this also means a lot of the other drm_device teardown that drivers > do happens way too early. There is a massive can of worms here of a > magnitude that most likely is much, much bigger than what you can > backport to stable kernels. Hotunplug is _hard_. Back to the drawing board, and fixing it in the intel display driver instead. Cc: Thomas Hellström Fixes: 6bee098b9141 ("drm: Fix use-after-free on framebuffers and property blobs when calling drm_dev_unplug") Reported-by: Guenter Roeck Tested-by: Guenter Roeck Acked-by: Simona Vetter Signed-off-by: Maarten Lankhorst Link: https://patch.msgid.link/20260326082217.39941-2-dev@lankhorst.se Signed-off-by: Greg Kroah-Hartman commit dc9a060d76c12b23c5f378ee115d5e5d03d8bbf3 Author: Varun R Mallya Date: Thu Apr 2 00:41:25 2026 +0530 bpf: Reject sleepable kprobe_multi programs at attach time [ Upstream commit eb7024bfcc5f68ed11ed9dd4891a3073c15f04a8 ] kprobe.multi programs run in atomic/RCU context and cannot sleep. However, bpf_kprobe_multi_link_attach() did not validate whether the program being attached had the sleepable flag set, allowing sleepable helpers such as bpf_copy_from_user() to be invoked from a non-sleepable context. This causes a "sleeping function called from invalid context" splat: BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:169 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1787, name: sudo preempt_count: 1, expected: 0 RCU nest depth: 2, expected: 0 Fix this by rejecting sleepable programs early in bpf_kprobe_multi_link_attach(), before any further processing. Fixes: 0dcac2725406 ("bpf: Add multi kprobe link") Signed-off-by: Varun R Mallya Acked-by: Kumar Kartikeya Dwivedi Acked-by: Leon Hwang Acked-by: Jiri Olsa Link: https://lore.kernel.org/r/20260401191126.440683-1-varunrmallya@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 63276547debc4d8a73eefb2c5273b2a905c961b0 Author: Qi Tang Date: Thu Apr 2 17:29:22 2026 +0800 bpf: reject direct access to nullable PTR_TO_BUF pointers [ Upstream commit b0db1accbc7395657c2b79db59fa9fae0d6656f3 ] check_mem_access() matches PTR_TO_BUF via base_type() which strips PTR_MAYBE_NULL, allowing direct dereference without a null check. Map iterator ctx->key and ctx->value are PTR_TO_BUF | PTR_MAYBE_NULL. On stop callbacks these are NULL, causing a kernel NULL dereference. Add a type_may_be_null() guard to the PTR_TO_BUF branch, matching the existing PTR_TO_BTF_ID pattern. Fixes: 20b2aff4bc15 ("bpf: Introduce MEM_RDONLY flag") Signed-off-by: Qi Tang Acked-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260402092923.38357-2-tpluszz77@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 7c15dabcbc9e3727d7e033b7f3aa62f366d21d65 Author: Dimitri Daskalakis Date: Wed Apr 1 09:28:48 2026 -0700 eth: fbnic: Increase FBNIC_QUEUE_SIZE_MIN to 64 [ Upstream commit ec7067e661193403a7a00980bda8612db5954142 ] On systems with 64K pages, RX queues will be wedged if users set the descriptor count to the current minimum (16). Fbnic fragments large pages into 4K chunks, and scales down the ring size accordingly. With 64K pages and 16 descriptors, the ring size mask is 0 and will never be filled. 32 descriptors is another special case that wedges the RX rings. Internally, the rings track pages for the head/tail pointers, not page fragments. So with 32 descriptors, there's only 1 usable page as one ring slot is kept empty to disambiguate between an empty/full ring. As a result, the head pointer never advances and the HW stalls after consuming 16 page fragments. Fixes: 0cb4c0a13723 ("eth: fbnic: Implement Rx queue alloc/start/stop/free") Signed-off-by: Dimitri Daskalakis Link: https://patch.msgid.link/20260401162848.2335350-1-dimitri.daskalakis1@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9ed81d692758dfb9471d7799b24bfa7a08224c31 Author: Eric Dumazet Date: Wed Apr 1 15:47:21 2026 +0000 ipv6: avoid overflows in ip6_datagram_send_ctl() [ Upstream commit 4e453375561fc60820e6b9d8ebeb6b3ee177d42e ] Yiming Qian reported : I believe I found a locally triggerable kernel bug in the IPv6 sendmsg ancillary-data path that can panic the kernel via `skb_under_panic()` (local DoS). The core issue is a mismatch between: - a 16-bit length accumulator (`struct ipv6_txoptions::opt_flen`, type `__u16`) and - a pointer to the *last* provided destination-options header (`opt->dst1opt`) when multiple `IPV6_DSTOPTS` control messages (cmsgs) are provided. - `include/net/ipv6.h`: - `struct ipv6_txoptions::opt_flen` is `__u16` (wrap possible). (lines 291-307, especially 298) - `net/ipv6/datagram.c:ip6_datagram_send_ctl()`: - Accepts repeated `IPV6_DSTOPTS` and accumulates into `opt_flen` without rejecting duplicates. (lines 909-933) - `net/ipv6/ip6_output.c:__ip6_append_data()`: - Uses `opt->opt_flen + opt->opt_nflen` to compute header sizes/headroom decisions. (lines 1448-1466, especially 1463-1465) - `net/ipv6/ip6_output.c:__ip6_make_skb()`: - Calls `ipv6_push_frag_opts()` if `opt->opt_flen` is non-zero. (lines 1930-1934) - `net/ipv6/exthdrs.c:ipv6_push_frag_opts()` / `ipv6_push_exthdr()`: - Push size comes from `ipv6_optlen(opt->dst1opt)` (based on the pointed-to header). (lines 1179-1185 and 1206-1211) 1. `opt_flen` is a 16-bit accumulator: - `include/net/ipv6.h:298` defines `__u16 opt_flen; /* after fragment hdr */`. 2. `ip6_datagram_send_ctl()` accepts *repeated* `IPV6_DSTOPTS` cmsgs and increments `opt_flen` each time: - In `net/ipv6/datagram.c:909-933`, for `IPV6_DSTOPTS`: - It computes `len = ((hdr->hdrlen + 1) << 3);` - It checks `CAP_NET_RAW` using `ns_capable(net->user_ns, CAP_NET_RAW)`. (line 922) - Then it does: - `opt->opt_flen += len;` (line 927) - `opt->dst1opt = hdr;` (line 928) There is no duplicate rejection here (unlike the legacy `IPV6_2292DSTOPTS` path which rejects duplicates at `net/ipv6/datagram.c:901-904`). If enough large `IPV6_DSTOPTS` cmsgs are provided, `opt_flen` wraps while `dst1opt` still points to a large (2048-byte) destination-options header. In the attached PoC (`poc.c`): - 32 cmsgs with `hdrlen=255` => `len = (255+1)*8 = 2048` - 1 cmsg with `hdrlen=0` => `len = 8` - Total increment: `32*2048 + 8 = 65544`, so `(__u16)opt_flen == 8` - The last cmsg is 2048 bytes, so `dst1opt` points to a 2048-byte header. 3. The transmit path sizes headers using the wrapped `opt_flen`: - In `net/ipv6/ip6_output.c:1463-1465`: - `headersize = sizeof(struct ipv6hdr) + (opt ? opt->opt_flen + opt->opt_nflen : 0) + ...;` With wrapped `opt_flen`, `headersize`/headroom decisions underestimate what will be pushed later. 4. When building the final skb, the actual push length comes from `dst1opt` and is not limited by wrapped `opt_flen`: - In `net/ipv6/ip6_output.c:1930-1934`: - `if (opt->opt_flen) proto = ipv6_push_frag_opts(skb, opt, proto);` - In `net/ipv6/exthdrs.c:1206-1211`, `ipv6_push_frag_opts()` pushes `dst1opt` via `ipv6_push_exthdr()`. - In `net/ipv6/exthdrs.c:1179-1184`, `ipv6_push_exthdr()` does: - `skb_push(skb, ipv6_optlen(opt));` - `memcpy(h, opt, ipv6_optlen(opt));` With insufficient headroom, `skb_push()` underflows and triggers `skb_under_panic()` -> `BUG()`: - `net/core/skbuff.c:2669-2675` (`skb_push()` calls `skb_under_panic()`) - `net/core/skbuff.c:207-214` (`skb_panic()` ends in `BUG()`) - The `IPV6_DSTOPTS` cmsg path requires `CAP_NET_RAW` in the target netns user namespace (`ns_capable(net->user_ns, CAP_NET_RAW)`). - Root (or any task with `CAP_NET_RAW`) can trigger this without user namespaces. - An unprivileged `uid=1000` user can trigger this if unprivileged user namespaces are enabled and it can create a userns+netns to obtain namespaced `CAP_NET_RAW` (the attached PoC does this). - Local denial of service: kernel BUG/panic (system crash). - Reproducible with a small userspace PoC. This patch does not reject duplicated options, as this might break some user applications. Instead, it makes sure to adjust opt_flen and opt_nflen to correctly reflect the size of the current option headers, preventing the overflows and the potential for panics. This applies to IPV6_DSTOPTS, IPV6_HOPOPTS, and IPV6_RTHDR. Specifically: When a new IPV6_DSTOPTS is processed, the length of the old opt->dst1opt is subtracted from opt->opt_flen before adding the new length. When a new IPV6_HOPOPTS is processed, the length of the old opt->dst0opt is subtracted from opt->opt_nflen. When a new Routing Header (IPV6_RTHDR or IPV6_2292RTHDR) is processed, the length of the old opt->srcrt is subtracted from opt->opt_nflen. In the special case within IPV6_2292RTHDR handling where dst1opt is moved to dst0opt, the length of the old opt->dst0opt is subtracted from opt->opt_nflen before the new one is added. Fixes: 333fad5364d6 ("[IPV6]: Support several new sockopt / ancillary data in Advanced API (RFC3542).") Reported-by: Yiming Qian Closes: https://lore.kernel.org/netdev/CAL_bE8JNzawgr5OX5m+3jnQDHry2XxhQT5=jThW1zDPtUikRYA@mail.gmail.com/ Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260401154721.3740056-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1fe371a34e801d065a6c5264db135b5b3d582a05 Author: Luka Gejak Date: Wed Apr 1 11:22:43 2026 +0200 net: hsr: fix VLAN add unwind on slave errors [ Upstream commit 2e3514e63bfb0e972b1f19668547a455d0129e88 ] When vlan_vid_add() fails for a secondary slave, the error path calls vlan_vid_del() on the failing port instead of the peer slave that had already succeeded. This results in asymmetric VLAN state across the HSR pair. Fix this by switching to a centralized unwind path that removes the VID from any slave device that was already programmed. Fixes: 1a8a63a5305e ("net: hsr: Add VLAN CTAG filter support") Signed-off-by: Luka Gejak Link: https://patch.msgid.link/20260401092243.52121-3-luka.gejak@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a208c3e1232997e9317887294c20008dfcb75449 Author: Xiang Mei Date: Mon Mar 30 22:02:16 2026 -0700 net/sched: cls_flow: fix NULL pointer dereference on shared blocks [ Upstream commit 1a280dd4bd1d616a01d6ffe0de284c907b555504 ] flow_change() calls tcf_block_q() and dereferences q->handle to derive a default baseclass. Shared blocks leave block->q NULL, causing a NULL deref when a flow filter without a fully qualified baseclass is created on a shared block. Check tcf_block_shared() before accessing block->q and return -EINVAL for shared blocks. This avoids the null-deref shown below: ======================================================================= KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:flow_change (net/sched/cls_flow.c:508) Call Trace: tc_new_tfilter (net/sched/cls_api.c:2432) rtnetlink_rcv_msg (net/core/rtnetlink.c:6980) [...] ======================================================================= Fixes: 1abf272022cf ("net: sched: tcindex, fw, flow: use tcf_block_q helper to get struct Qdisc") Reported-by: Weiming Shi Signed-off-by: Xiang Mei Acked-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260331050217.504278-2-xmei5@asu.edu Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 3cb055df9e8625ce699a259d8178d67b37f2b160 Author: Xiang Mei Date: Mon Mar 30 22:02:15 2026 -0700 net/sched: cls_fw: fix NULL pointer dereference on shared blocks [ Upstream commit faeea8bbf6e958bf3c00cb08263109661975987c ] The old-method path in fw_classify() calls tcf_block_q() and dereferences q->handle. Shared blocks leave block->q NULL, causing a NULL deref when an empty cls_fw filter is attached to a shared block and a packet with a nonzero major skb mark is classified. Reject the configuration in fw_change() when the old method (no TCA_OPTIONS) is used on a shared block, since fw_classify()'s old-method path needs block->q which is NULL for shared blocks. The fixed null-ptr-deref calling stack: KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:fw_classify (net/sched/cls_fw.c:81) Call Trace: tcf_classify (./include/net/tc_wrapper.h:197 net/sched/cls_api.c:1764 net/sched/cls_api.c:1860) tc_run (net/core/dev.c:4401) __dev_queue_xmit (net/core/dev.c:4535 net/core/dev.c:4790) Fixes: 1abf272022cf ("net: sched: tcindex, fw, flow: use tcf_block_q helper to get struct Qdisc") Reported-by: Weiming Shi Signed-off-by: Xiang Mei Acked-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260331050217.504278-1-xmei5@asu.edu Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 8c92969c197b91c134be27dc3afb64ab468853a9 Author: Martin Schiller Date: Tue Mar 31 09:43:18 2026 +0200 net/x25: Fix overflow when accumulating packets [ Upstream commit a1822cb524e89b4cd2cf0b82e484a2335496a6d9 ] Add a check to ensure that `x25_sock.fraglen` does not overflow. The `fraglen` also needs to be resetted when purging `fragment_queue` in `x25_clear_queues()`. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Suggested-by: Yiming Qian Signed-off-by: Martin Schiller Link: https://patch.msgid.link/20260331-x25_fraglen-v4-2-3e69f18464b4@dev.tdt.de Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit fa1dbc93530b34fab0da9862426fe9c918c74dc0 Author: Martin Schiller Date: Tue Mar 31 09:43:17 2026 +0200 net/x25: Fix potential double free of skb [ Upstream commit d10a26aa4d072320530e6968ef945c8c575edf61 ] When alloc_skb fails in x25_queue_rx_frame it calls kfree_skb(skb) at line 48 and returns 1 (error). This error propagates back through the call chain: x25_queue_rx_frame returns 1 | v x25_state3_machine receives the return value 1 and takes the else branch at line 278, setting queued=0 and returning 0 | v x25_process_rx_frame returns queued=0 | v x25_backlog_rcv at line 452 sees queued=0 and calls kfree_skb(skb) again This would free the same skb twice. Looking at x25_backlog_rcv: net/x25/x25_in.c:x25_backlog_rcv() { ... queued = x25_process_rx_frame(sk, skb); ... if (!queued) kfree_skb(skb); } Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Martin Schiller Link: https://patch.msgid.link/20260331-x25_fraglen-v4-1-3e69f18464b4@dev.tdt.de Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 311efb3cfc9263074ecc26ef96a324b83fa47bae Author: Pavan Chebbi Date: Mon Mar 30 23:51:38 2026 -0700 bnxt_en: Restore default stat ctxs for ULP when resource is available [ Upstream commit 071dbfa304e85a6b04a593e950d18fa170997288 ] During resource reservation, if the L2 driver does not have enough MSIX vectors to provide to the RoCE driver, it sets the stat ctxs for ULP also to 0 so that we don't have to reserve it unnecessarily. However, subsequently the user may reduce L2 rings thereby freeing up some resources that the L2 driver can now earmark for RoCE. In this case, the driver should restore the default ULP stat ctxs to make sure that all RoCE resources are ready for use. The RoCE driver may fail to initialize in this scenario without this fix. Fixes: d630624ebd70 ("bnxt_en: Utilize ulp client resources if RoCE is not registered") Reviewed-by: Kalesh AP Signed-off-by: Pavan Chebbi Signed-off-by: Michael Chan Link: https://patch.msgid.link/20260331065138.948205-4-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e27153b2bd6e6699b544ac4dfa35d167bed5e642 Author: Saeed Mahameed Date: Mon Mar 30 22:40:15 2026 +0300 net/mlx5: Fix switchdev mode rollback in case of failure [ Upstream commit 403186400a1a6166efe7031edc549c15fee4723f ] If for some internal reason switchdev mode fails, we rollback to legacy mode, before this patch, rollback will unregister the uplink netdev and leave it unregistered causing the below kernel bug. To fix this, we need to avoid netdev unregister by setting the proper rollback flag 'MLX5_PRIV_FLAGS_SWITCH_LEGACY' to indicate legacy mode. devlink (431) used greatest stack depth: 11048 bytes left mlx5_core 0000:00:03.0: E-Switch: Disable: mode(LEGACY), nvfs(0), \ necvfs(0), active vports(0) mlx5_core 0000:00:03.0: E-Switch: Supported tc chains and prios offload mlx5_core 0000:00:03.0: Loading uplink representor for vport 65535 mlx5_core 0000:00:03.0: mlx5_cmd_out_err:816:(pid 456): \ QUERY_HCA_CAP(0x100) op_mod(0x0) failed, \ status bad parameter(0x3), syndrome (0x3a3846), err(-22) mlx5_core 0000:00:03.0 enp0s3np0 (unregistered): Unloading uplink \ representor for vport 65535 ------------[ cut here ]------------ kernel BUG at net/core/dev.c:12070! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 456 Comm: devlink Not tainted 6.16.0-rc3+ \ #9 PREEMPT(voluntary) RIP: 0010:unregister_netdevice_many_notify+0x123/0xae0 ... Call Trace: [ 90.923094] unregister_netdevice_queue+0xad/0xf0 [ 90.923323] unregister_netdev+0x1c/0x40 [ 90.923522] mlx5e_vport_rep_unload+0x61/0xc6 [ 90.923736] esw_offloads_enable+0x8e6/0x920 [ 90.923947] mlx5_eswitch_enable_locked+0x349/0x430 [ 90.924182] ? is_mp_supported+0x57/0xb0 [ 90.924376] mlx5_devlink_eswitch_mode_set+0x167/0x350 [ 90.924628] devlink_nl_eswitch_set_doit+0x6f/0xf0 [ 90.924862] genl_family_rcv_msg_doit+0xe8/0x140 [ 90.925088] genl_rcv_msg+0x18b/0x290 [ 90.925269] ? __pfx_devlink_nl_pre_doit+0x10/0x10 [ 90.925506] ? __pfx_devlink_nl_eswitch_set_doit+0x10/0x10 [ 90.925766] ? __pfx_devlink_nl_post_doit+0x10/0x10 [ 90.926001] ? __pfx_genl_rcv_msg+0x10/0x10 [ 90.926206] netlink_rcv_skb+0x52/0x100 [ 90.926393] genl_rcv+0x28/0x40 [ 90.926557] netlink_unicast+0x27d/0x3d0 [ 90.926749] netlink_sendmsg+0x1f7/0x430 [ 90.926942] __sys_sendto+0x213/0x220 [ 90.927127] ? __sys_recvmsg+0x6a/0xd0 [ 90.927312] __x64_sys_sendto+0x24/0x30 [ 90.927504] do_syscall_64+0x50/0x1c0 [ 90.927687] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 90.927929] RIP: 0033:0x7f7d0363e047 Fixes: 2a4f56fbcc47 ("net/mlx5e: Keep netdev when leave switchdev for devlink set legacy only") Signed-off-by: Saeed Mahameed Reviewed-by: Jianbo Liu Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260330194015.53585-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 276b3efb2b48793506ef6ce270214570e0e0838c Author: Saeed Mahameed Date: Mon Mar 30 22:40:14 2026 +0300 net/mlx5: Avoid "No data available" when FW version queries fail [ Upstream commit 10dc35f6a443d488f219d1a1e3fb8f8dac422070 ] Avoid printing the misleading "kernel answers: No data available" devlink output when querying firmware or pending firmware version fails (e.g. MLX5 fw state errors / flash failures). FW can fail on loading the pending flash image and get its version due to various reasons, examples: mlxfw: Firmware flash failed: key not applicable, err (7) mlx5_fw_image_pending: can't read pending fw version while fw state is 1 and the resulting: $ devlink dev info kernel answers: No data available Instead, just report 0 or 0xfff.. versions in case of failure to indicate a problem, and let other information be shown. after the fix: $ devlink dev info pci/0000:00:06.0: driver mlx5_core serial_number xxx... board.serial_number MT2225300179 versions: fixed: fw.psid MT_0000000436 running: fw.version 22.41.0188 fw 22.41.0188 stored: fw.version 255.255.65535 fw 255.255.65535 Fixes: 9c86b07e3069 ("net/mlx5: Added fw version query command") Signed-off-by: Saeed Mahameed Reviewed-by: Moshe Shemesh Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260330194015.53585-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c53cf44588a93000f71817a6bb87a66353c48dee Author: Shay Drory Date: Mon Mar 30 22:40:13 2026 +0300 net/mlx5: lag: Check for LAG device before creating debugfs [ Upstream commit bf16bca6653679d8a514d6c1c5a2c67065033f14 ] __mlx5_lag_dev_add_mdev() may return 0 (success) even when an error occurs that is handled gracefully. Consequently, the initialization flow proceeds to call mlx5_ldev_add_debugfs() even when there is no valid LAG context. mlx5_ldev_add_debugfs() blindly created the debugfs directory and attributes. This exposed interfaces (like the members file) that rely on a valid ldev pointer, leading to potential NULL pointer dereferences if accessed when ldev is NULL. Add a check to verify that mlx5_lag_dev(dev) returns a valid pointer before attempting to create the debugfs entries. Fixes: 7f46a0b7327a ("net/mlx5: Lag, add debugfs to query hardware lag state") Signed-off-by: Shay Drory Reviewed-by: Mark Bloch Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260330194015.53585-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5392a5174df4f5a2fad2f00e8c617394d0efe031 Author: Fedor Pchelkin Date: Mon Mar 30 21:45:41 2026 +0300 net: macb: properly unregister fixed rate clocks [ Upstream commit f0f367a4f459cc8118aadc43c6bba53c60d93f8d ] The additional resources allocated with clk_register_fixed_rate() need to be released with clk_unregister_fixed_rate(), otherwise they are lost. Fixes: 83a77e9ec415 ("net: macb: Added PCI wrapper for Platform Driver.") Signed-off-by: Fedor Pchelkin Link: https://patch.msgid.link/20260330184542.626619-2-pchelkin@ispras.ru Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 16ab4c0e2b15df5d33bfcb9ea8e4441b85dd4a57 Author: Fedor Pchelkin Date: Mon Mar 30 21:45:40 2026 +0300 net: macb: fix clk handling on PCI glue driver removal [ Upstream commit ce8fe5287b87e24e225c342f3b0ec04f0b3680fe ] platform_device_unregister() may still want to use the registered clks during runtime resume callback. Note that there is a commit d82d5303c4c5 ("net: macb: fix use after free on rmmod") that addressed the similar problem of clk vs platform device unregistration but just moved the bug to another place. Save the pointers to clks into local variables for reuse after platform device is unregistered. BUG: KASAN: use-after-free in clk_prepare+0x5a/0x60 Read of size 8 at addr ffff888104f85e00 by task modprobe/597 CPU: 2 PID: 597 Comm: modprobe Not tainted 6.1.164+ #114 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x8d/0xba print_report+0x17f/0x496 kasan_report+0xd9/0x180 clk_prepare+0x5a/0x60 macb_runtime_resume+0x13d/0x410 [macb] pm_generic_runtime_resume+0x97/0xd0 __rpm_callback+0xc8/0x4d0 rpm_callback+0xf6/0x230 rpm_resume+0xeeb/0x1a70 __pm_runtime_resume+0xb4/0x170 bus_remove_device+0x2e3/0x4b0 device_del+0x5b3/0xdc0 platform_device_del+0x4e/0x280 platform_device_unregister+0x11/0x50 pci_device_remove+0xae/0x210 device_remove+0xcb/0x180 device_release_driver_internal+0x529/0x770 driver_detach+0xd4/0x1a0 bus_remove_driver+0x135/0x260 driver_unregister+0x72/0xb0 pci_unregister_driver+0x26/0x220 __do_sys_delete_module+0x32e/0x550 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 519: kasan_save_stack+0x2c/0x50 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x8e/0x90 __clk_register+0x458/0x2890 clk_hw_register+0x1a/0x60 __clk_hw_register_fixed_rate+0x255/0x410 clk_register_fixed_rate+0x3c/0xa0 macb_probe+0x1d8/0x42e [macb_pci] local_pci_probe+0xd7/0x190 pci_device_probe+0x252/0x600 really_probe+0x255/0x7f0 __driver_probe_device+0x1ee/0x330 driver_probe_device+0x4c/0x1f0 __driver_attach+0x1df/0x4e0 bus_for_each_dev+0x15d/0x1f0 bus_add_driver+0x486/0x5e0 driver_register+0x23a/0x3d0 do_one_initcall+0xfd/0x4d0 do_init_module+0x18b/0x5a0 load_module+0x5663/0x7950 __do_sys_finit_module+0x101/0x180 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 597: kasan_save_stack+0x2c/0x50 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x50 __kasan_slab_free+0x106/0x180 __kmem_cache_free+0xbc/0x320 clk_unregister+0x6de/0x8d0 macb_remove+0x73/0xc0 [macb_pci] pci_device_remove+0xae/0x210 device_remove+0xcb/0x180 device_release_driver_internal+0x529/0x770 driver_detach+0xd4/0x1a0 bus_remove_driver+0x135/0x260 driver_unregister+0x72/0xb0 pci_unregister_driver+0x26/0x220 __do_sys_delete_module+0x32e/0x550 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Fixes: d82d5303c4c5 ("net: macb: fix use after free on rmmod") Signed-off-by: Fedor Pchelkin Link: https://patch.msgid.link/20260330184542.626619-1-pchelkin@ispras.ru Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3a2999704ac36cfb4041fed3652d26a3373e8d12 Author: Yucheng Lu Date: Tue Mar 31 16:00:21 2026 +0800 net/sched: sch_netem: fix out-of-bounds access in packet corruption [ Upstream commit d64cb81dcbd54927515a7f65e5e24affdc73c14b ] In netem_enqueue(), the packet corruption logic uses get_random_u32_below(skb_headlen(skb)) to select an index for modifying skb->data. When an AF_PACKET TX_RING sends fully non-linear packets over an IPIP tunnel, skb_headlen(skb) evaluates to 0. Passing 0 to get_random_u32_below() takes the variable-ceil slow path which returns an unconstrained 32-bit random integer. Using this unconstrained value as an offset into skb->data results in an out-of-bounds memory access. Fix this by verifying skb_headlen(skb) is non-zero before attempting to corrupt the linear data area. Fully non-linear packets will silently bypass the corruption logic. Fixes: c865e5d99e25 ("[PKT_SCHED] netem: packet corruption option") Reported-by: Yifan Wu Reported-by: Juefei Pu Signed-off-by: Yuan Tan Signed-off-by: Xin Liu Signed-off-by: Yuhang Zheng Signed-off-by: Yucheng Lu Reviewed-by: Stephen Hemminger Link: https://patch.msgid.link/45435c0935df877853a81e6d06205ac738ec65fa.1774941614.git.kanolyc@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 18861f87a043e78b1f901cae4237e755ed7ef095 Author: Kuniyuki Iwashima Date: Wed Apr 1 00:54:15 2026 +0000 bpf: sockmap: Fix use-after-free of sk->sk_socket in sk_psock_verdict_data_ready(). [ Upstream commit ad8391d37f334ee73ba91926f8b4e4cf6d31ea04 ] syzbot reported use-after-free of AF_UNIX socket's sk->sk_socket in sk_psock_verdict_data_ready(). [0] In unix_stream_sendmsg(), the peer socket's ->sk_data_ready() is called after dropping its unix_state_lock(). Although the sender socket holds the peer's refcount, it does not prevent the peer's sock_orphan(), and the peer's sk_socket might be freed after one RCU grace period. Let's fetch the peer's sk->sk_socket and sk->sk_socket->ops under RCU in sk_psock_verdict_data_ready(). [0]: BUG: KASAN: slab-use-after-free in sk_psock_verdict_data_ready+0xec/0x590 net/core/skmsg.c:1278 Read of size 8 at addr ffff8880594da860 by task syz.4.1842/11013 CPU: 1 UID: 0 PID: 11013 Comm: syz.4.1842 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/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_psock_verdict_data_ready+0xec/0x590 net/core/skmsg.c:1278 unix_stream_sendmsg+0x8a3/0xe80 net/unix/af_unix.c:2482 sock_sendmsg_nosec net/socket.c:721 [inline] __sock_sendmsg net/socket.c:736 [inline] ____sys_sendmsg+0x972/0x9f0 net/socket.c:2585 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2639 __sys_sendmsg net/socket.c:2671 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2674 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7facf899c819 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:00007facf9827028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007facf8c15fa0 RCX: 00007facf899c819 RDX: 0000000000000000 RSI: 0000200000000500 RDI: 0000000000000004 RBP: 00007facf8a32c91 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007facf8c16038 R14: 00007facf8c15fa0 R15: 00007ffd41b01c78 Allocated by task 11013: kasan_save_stack mm/kasan/common.c:57 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:78 unpoison_slab_object mm/kasan/common.c:340 [inline] __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366 kasan_slab_alloc include/linux/kasan.h:253 [inline] slab_post_alloc_hook mm/slub.c:4538 [inline] slab_alloc_node mm/slub.c:4866 [inline] kmem_cache_alloc_lru_noprof+0x2b8/0x640 mm/slub.c:4885 sock_alloc_inode+0x28/0xc0 net/socket.c:316 alloc_inode+0x6a/0x1b0 fs/inode.c:347 new_inode_pseudo include/linux/fs.h:3003 [inline] sock_alloc net/socket.c:631 [inline] __sock_create+0x12d/0x9d0 net/socket.c:1562 sock_create net/socket.c:1656 [inline] __sys_socketpair+0x1c4/0x560 net/socket.c:1803 __do_sys_socketpair net/socket.c:1856 [inline] __se_sys_socketpair net/socket.c:1853 [inline] __x64_sys_socketpair+0x9b/0xb0 net/socket.c:1853 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 15: 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:2685 [inline] slab_free mm/slub.c:6165 [inline] kmem_cache_free+0x187/0x630 mm/slub.c:6295 rcu_do_batch kernel/rcu/tree.c:2617 [inline] rcu_core+0x7cd/0x1070 kernel/rcu/tree.c:2869 handle_softirqs+0x22a/0x870 kernel/softirq.c:622 run_ksoftirqd+0x36/0x60 kernel/softirq.c:1063 smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c:160 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Fixes: c63829182c37 ("af_unix: Implement ->psock_update_sk_prot()") Closes: https://lore.kernel.org/bpf/69cc6b9f.a70a0220.128fd0.004b.GAE@google.com/ Reported-by: syzbot+2184232f07e3677fbaef@syzkaller.appspotmail.com Signed-off-by: Kuniyuki Iwashima Signed-off-by: Martin KaFai Lau Reviewed-by: Jiayuan Chen Link: https://patch.msgid.link/20260401005418.2452999-1-kuniyu@google.com Signed-off-by: Sasha Levin commit 23e07c340c445f0ebff7757ba15434cb447eb662 Author: Weiming Shi Date: Tue Mar 31 00:32:38 2026 +0800 rds: ib: reject FRMR registration before IB connection is established [ Upstream commit a54ecccfae62c5c85259ae5ea5d9c20009519049 ] rds_ib_get_mr() extracts the rds_ib_connection from conn->c_transport_data and passes it to rds_ib_reg_frmr() for FRWR memory registration. On a fresh outgoing connection, ic is allocated in rds_ib_conn_alloc() with i_cm_id = NULL because the connection worker has not yet called rds_ib_conn_path_connect() to create the rdma_cm_id. When sendmsg() with RDS_CMSG_RDMA_MAP is called on such a connection, the sendmsg path parses the control message before any connection establishment, allowing rds_ib_post_reg_frmr() to dereference ic->i_cm_id->qp and crash the kernel. The existing guard in rds_ib_reg_frmr() only checks for !ic (added in commit 9e630bcb7701), which does not catch this case since ic is allocated early and is always non-NULL once the connection object exists. KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rds_ib_post_reg_frmr+0x50e/0x920 Call Trace: rds_ib_post_reg_frmr (net/rds/ib_frmr.c:167) rds_ib_map_frmr (net/rds/ib_frmr.c:252) rds_ib_reg_frmr (net/rds/ib_frmr.c:430) rds_ib_get_mr (net/rds/ib_rdma.c:615) __rds_rdma_map (net/rds/rdma.c:295) rds_cmsg_rdma_map (net/rds/rdma.c:860) rds_sendmsg (net/rds/send.c:1363) ____sys_sendmsg do_syscall_64 Add a check in rds_ib_get_mr() that verifies ic, i_cm_id, and qp are all non-NULL before proceeding with FRMR registration, mirroring the guard already present in rds_ib_post_inv(). Return -ENODEV when the connection is not ready, which the existing error handling in rds_cmsg_send() converts to -EAGAIN for userspace retry and triggers rds_conn_connect_if_down() to start the connection worker. Fixes: 1659185fb4d0 ("RDS: IB: Support Fastreg MR (FRMR) memory registration mode") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Reviewed-by: Allison Henderson Link: https://patch.msgid.link/20260330163237.2752440-2-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit edb5898cfa91afe7e8f83eda18d93034c953d632 Author: Keenan Dong Date: Wed Apr 1 22:25:26 2026 +0800 Bluetooth: MGMT: validate mesh send advertising payload length [ Upstream commit bda93eec78cdbfe5cda00785cefebd443e56b88b ] mesh_send() currently bounds MGMT_OP_MESH_SEND by total command length, but it never verifies that the bytes supplied for the flexible adv_data[] array actually match the embedded adv_data_len field. MGMT_MESH_SEND_SIZE only covers the fixed header, so a truncated command can still pass the existing 20..50 byte range check and later drive the async mesh send path past the end of the queued command buffer. Keep rejecting zero-length and oversized advertising payloads, but validate adv_data_len explicitly and require the command length to exactly match the flexible array size before queueing the request. Fixes: b338d91703fa ("Bluetooth: Implement support for Mesh") Reported-by: Keenan Dong Signed-off-by: Keenan Dong Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 1d0bdbfe3e91c11f0a704c52443a9446a10d699c Author: Pauli Virtanen Date: Sun Mar 29 16:43:02 2026 +0300 Bluetooth: hci_event: fix potential UAF in hci_le_remote_conn_param_req_evt [ Upstream commit b255531b27da336571411248c2a72a350662bd09 ] hci_conn lookup and field access must be covered by hdev lock in hci_le_remote_conn_param_req_evt, otherwise it's possible it is freed concurrently. Extend the hci_dev_lock critical section to cover all conn usage. Fixes: 95118dd4edfec ("Bluetooth: hci_event: Use of a function table to handle LE subevents") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 7d568fede8eac91161a60b710aa920abe9b0fb9f Author: Pauli Virtanen Date: Sun Mar 29 16:43:01 2026 +0300 Bluetooth: hci_conn: fix potential UAF in set_cig_params_sync [ Upstream commit a2639a7f0f5bf7d73f337f8f077c19415c62ed2c ] hci_conn lookup and field access must be covered by hdev lock in set_cig_params_sync, otherwise it's possible it is freed concurrently. Take hdev lock to prevent hci_conn from being deleted or modified concurrently. Just RCU lock is not suitable here, as we also want to avoid "tearing" in the configuration. Fixes: a091289218202 ("Bluetooth: hci_conn: Fix hci_le_set_cig_params") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 50fb64defa72a3fecd0af1ca7c6b47b5c5c2b257 Author: Keenan Dong Date: Sat Mar 28 16:46:47 2026 +0800 Bluetooth: MGMT: validate LTK enc_size on load [ Upstream commit b8dbe9648d69059cfe3a28917bfbf7e61efd7f15 ] Load Long Term Keys stores the user-provided enc_size and later uses it to size fixed-size stack operations when replying to LE LTK requests. An enc_size larger than the 16-byte key buffer can therefore overflow the reply stack buffer. Reject oversized enc_size values while validating the management LTK record so invalid keys never reach the stored key state. Fixes: 346af67b8d11 ("Bluetooth: Add MGMT handlers for dealing with SMP LTK's") Reported-by: Keenan Dong Signed-off-by: Keenan Dong Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 3ec3a1588876cf5bc1883f1664acfe719d86f3bb Author: Jonathan Rissanen Date: Fri Mar 27 11:47:21 2026 +0100 Bluetooth: hci_h4: Fix race during initialization [ Upstream commit 0ffac654e95c1bdfe2d4edf28fb18d6ba1f103e6 ] Commit 5df5dafc171b ("Bluetooth: hci_uart: Fix another race during initialization") fixed a race for hci commands sent during initialization. However, there is still a race that happens if an hci event from one of these commands is received before HCI_UART_REGISTERED has been set at the end of hci_uart_register_dev(). The event will be ignored which causes the command to fail with a timeout in the log: "Bluetooth: hci0: command 0x1003 tx timeout" This is because the hci event receive path (hci_uart_tty_receive -> h4_recv) requires HCI_UART_REGISTERED to be set in h4_recv(), while the hci command transmit path (hci_uart_send_frame -> h4_enqueue) only requires HCI_UART_PROTO_INIT to be set in hci_uart_send_frame(). The check for HCI_UART_REGISTERED was originally added in commit c2578202919a ("Bluetooth: Fix H4 crash from incoming UART packets") to fix a crash caused by hu->hdev being null dereferenced. That can no longer happen: once HCI_UART_PROTO_INIT is set in hci_uart_register_dev() all pointers (hu, hu->priv and hu->hdev) are valid, and hci_uart_tty_receive() already calls h4_recv() on HCI_UART_PROTO_INIT or HCI_UART_PROTO_READY. Remove the check for HCI_UART_REGISTERED in h4_recv() to fix the race condition. Fixes: 5df5dafc171b ("Bluetooth: hci_uart: Fix another race during initialization") Signed-off-by: Jonathan Rissanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 98c8d3bfdaa657d8f472dbbebd7ea8cd816d8a8d Author: Cen Zhang Date: Thu Mar 26 23:16:45 2026 +0800 Bluetooth: SCO: fix race conditions in sco_sock_connect() [ Upstream commit 8a5b0135d4a5d9683203a3d9a12a711ccec5936b ] sco_sock_connect() checks sk_state and sk_type without holding the socket lock. Two concurrent connect() syscalls on the same socket can both pass the check and enter sco_connect(), leading to use-after-free. The buggy scenario involves three participants and was confirmed with additional logging instrumentation: Thread A (connect): HCI disconnect: Thread B (connect): sco_sock_connect(sk) sco_sock_connect(sk) sk_state==BT_OPEN sk_state==BT_OPEN (pass, no lock) (pass, no lock) sco_connect(sk): sco_connect(sk): hci_dev_lock hci_dev_lock hci_connect_sco <- blocked -> hcon1 sco_conn_add->conn1 lock_sock(sk) sco_chan_add: conn1->sk = sk sk->conn = conn1 sk_state=BT_CONNECT release_sock hci_dev_unlock hci_dev_lock sco_conn_del: lock_sock(sk) sco_chan_del: sk->conn=NULL conn1->sk=NULL sk_state= BT_CLOSED SOCK_ZAPPED release_sock hci_dev_unlock (unblocked) hci_connect_sco -> hcon2 sco_conn_add -> conn2 lock_sock(sk) sco_chan_add: sk->conn=conn2 sk_state= BT_CONNECT // zombie sk! release_sock hci_dev_unlock Thread B revives a BT_CLOSED + SOCK_ZAPPED socket back to BT_CONNECT. Subsequent cleanup triggers double sock_put() and use-after-free. Meanwhile conn1 is leaked as it was orphaned when sco_conn_del() cleared the association. Fix this by: - Moving lock_sock() before the sk_state/sk_type checks in sco_sock_connect() to serialize concurrent connect attempts - Fixing the sk_type != SOCK_SEQPACKET check to actually return the error instead of just assigning it - Adding a state re-check in sco_connect() after lock_sock() to catch state changes during the window between the locks - Adding sco_pi(sk)->conn check in sco_chan_add() to prevent double-attach of a socket to multiple connections - Adding hci_conn_drop() on sco_chan_add failure to prevent HCI connection leaks Fixes: 9a8ec9e8ebb5 ("Bluetooth: SCO: Fix possible circular locking dependency on sco_connect_cfm") Signed-off-by: Cen Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit d4d1a4eed6f6cc7a60eb9c20bd7458080941a8c3 Author: Pauli Virtanen Date: Wed Mar 25 21:07:46 2026 +0200 Bluetooth: hci_sync: call destroy in hci_cmd_sync_run if immediate [ Upstream commit a834a0b66ec6fb743377201a0f4229bb2503f4ce ] hci_cmd_sync_run() may run the work immediately if called from existing sync work (otherwise it queues a new sync work). In this case it fails to call the destroy() function. On immediate run, make it behave same way as if item was queued successfully: call destroy, and return 0. The only callsite is hci_abort_conn() via hci_cmd_sync_run_once(), and this changes its return value. However, its return value is not used except as the return value for hci_disconnect(), and nothing uses the return value of hci_disconnect(). Hence there should be no behavior change anywhere. Fixes: c898f6d7b093b ("Bluetooth: hci_sync: Introduce hci_cmd_sync_run/hci_cmd_sync_run_once") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 42a47f4b1b7695026ab9bc1bb35d4622b0835c95 Author: Pablo Neira Ayuso Date: Tue Mar 31 23:08:02 2026 +0200 netfilter: nf_tables: reject immediate NF_QUEUE verdict [ Upstream commit da107398cbd4bbdb6bffecb2ce86d5c9384f4cec ] nft_queue is always used from userspace nftables to deliver the NF_QUEUE verdict. Immediately emitting an NF_QUEUE verdict is never used by the userspace nft tools, so reject immediate NF_QUEUE verdicts. The arp family does not provide queue support, but such an immediate verdict is still reachable. Globally reject NF_QUEUE immediate verdicts to address this issue. Fixes: f342de4e2f33 ("netfilter: nf_tables: reject QUEUE/DROP verdict parameters") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit dc3e27dd7d76e21106b8f9bbdc31f5da74a89014 Author: Pablo Neira Ayuso Date: Tue Mar 31 16:41:25 2026 +0200 netfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARP [ Upstream commit 3d5d488f11776738deab9da336038add95d342d1 ] Weiming Shi says: xt_match and xt_target structs registered with NFPROTO_UNSPEC can be loaded by any protocol family through nft_compat. When such a match/target sets .hooks to restrict which hooks it may run on, the bitmask uses NF_INET_* constants. This is only correct for families whose hook layout matches NF_INET_*: IPv4, IPv6, INET, and bridge all share the same five hooks (PRE_ROUTING ... POST_ROUTING). ARP only has three hooks (IN=0, OUT=1, FORWARD=2) with different semantics. Because NF_ARP_OUT == 1 == NF_INET_LOCAL_IN, the .hooks validation silently passes for the wrong reasons, allowing matches to run on ARP chains where the hook assumptions (e.g. state->in being set on input hooks) do not hold. This leads to NULL pointer dereferences; xt_devgroup is one concrete example: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000044: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227] RIP: 0010:devgroup_mt+0xff/0x350 Call Trace: nft_match_eval (net/netfilter/nft_compat.c:407) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_arp (net/netfilter/nft_chain_filter.c:61) nf_hook_slow (net/netfilter/core.c:623) arp_xmit (net/ipv4/arp.c:666) Kernel panic - not syncing: Fatal exception in interrupt Fix it by restricting arptables to NFPROTO_ARP extensions only. Note that arptables-legacy only supports: - arpt_CLASSIFY - arpt_mangle - arpt_MARK that provide explicit NFPROTO_ARP match/target declarations. Fixes: 9291747f118d ("netfilter: xtables: add device group match") Reported-by: Xiang Mei Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 187b6ec5229ea93cb04c4f6d3b52efc80f513d0d Author: Pablo Neira Ayuso Date: Mon Mar 30 11:26:22 2026 +0200 netfilter: ctnetlink: ignore explicit helper on new expectations [ Upstream commit 917b61fa2042f11e2af4c428e43f08199586633a ] Use the existing master conntrack helper, anything else is not really supported and it just makes validation more complicated, so just ignore what helper userspace suggests for this expectation. This was uncovered when validating CTA_EXPECT_CLASS via different helper provided by userspace than the existing master conntrack helper: BUG: KASAN: slab-out-of-bounds in nf_ct_expect_related_report+0x2479/0x27c0 Read of size 4 at addr ffff8880043fe408 by task poc/102 Call Trace: nf_ct_expect_related_report+0x2479/0x27c0 ctnetlink_create_expect+0x22b/0x3b0 ctnetlink_new_expect+0x4bd/0x5c0 nfnetlink_rcv_msg+0x67a/0x950 netlink_rcv_skb+0x120/0x350 Allowing to read kernel memory bytes off the expectation boundary. CTA_EXPECT_HELP_NAME is still used to offer the helper name to userspace via netlink dump. Fixes: bd0779370588 ("netfilter: nfnetlink_queue: allow to attach expectations to conntracks") Reported-by: Qi Tang Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit a0684ccc1ddd2eb0b8ee37839b26e7ac24dddbff Author: Pablo Neira Ayuso Date: Wed Mar 25 22:39:55 2026 +0100 netfilter: nf_conntrack_expect: store netns and zone in expectation [ Upstream commit 02a3231b6d82efe750da6554ebf280e4a6f78756 ] __nf_ct_expect_find() and nf_ct_expect_find_get() are called under rcu_read_lock() but they dereference the master conntrack via exp->master. Since the expectation does not hold a reference on the master conntrack, this could be dying conntrack or different recycled conntrack than the real master due to SLAB_TYPESAFE_RCU. Store the netns, the master_tuple and the zone in struct nf_conntrack_expect as a safety measure. This patch is required by the follow up fix not to dump expectations that do not belong to this netns. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Stable-dep-of: 917b61fa2042 ("netfilter: ctnetlink: ignore explicit helper on new expectations") Signed-off-by: Sasha Levin commit b53294bff19e56ada2f230ceb8b1ffde61cc3817 Author: Pablo Neira Ayuso Date: Wed Mar 25 14:11:03 2026 +0100 netfilter: nf_conntrack_expect: use expect->helper [ Upstream commit f01794106042ee27e54af6fdf5b319a2fe3df94d ] Use expect->helper in ctnetlink and /proc to dump the helper name. Using nfct_help() without holding a reference to the master conntrack is unsafe. Use exp->master->helper in ctnetlink path if userspace does not provide an explicit helper when creating an expectation to retain the existing behaviour. The ctnetlink expectation path holds the reference on the master conntrack and nf_conntrack_expect lock and the nfnetlink glue path refers to the master ct that is attached to the skb. Reported-by: Hyunwoo Kim Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Stable-dep-of: 917b61fa2042 ("netfilter: ctnetlink: ignore explicit helper on new expectations") Signed-off-by: Sasha Levin commit 54cb3500e8af5fb0c34e639ab51145f4c2a1f9ef Author: Pablo Neira Ayuso Date: Wed Mar 25 14:11:02 2026 +0100 netfilter: nf_conntrack_expect: honor expectation helper field [ Upstream commit 9c42bc9db90a154bc61ae337a070465f3393485a ] The expectation helper field is mostly unused. As a result, the netfilter codebase relies on accessing the helper through exp->master. Always set on the expectation helper field so it can be used to reach the helper. nf_ct_expect_init() is called from packet path where the skb owns the ct object, therefore accessing exp->master for the newly created expectation is safe. This saves a lot of updates in all callsites to pass the ct object as parameter to nf_ct_expect_init(). This is a preparation patches for follow up fixes. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Stable-dep-of: 917b61fa2042 ("netfilter: ctnetlink: ignore explicit helper on new expectations") Signed-off-by: Sasha Levin commit 929f7a9a7aad9404a5867216c3f8738232355b38 Author: Qi Tang Date: Tue Mar 31 14:17:12 2026 +0800 netfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absent [ Upstream commit 35177c6877134a21315f37d57a5577846225623e ] ctnetlink_alloc_expect() allocates expectations from a non-zeroing slab cache via nf_ct_expect_alloc(). When CTA_EXPECT_NAT is not present in the netlink message, saved_addr and saved_proto are never initialized. Stale data from a previous slab occupant can then be dumped to userspace by ctnetlink_exp_dump_expect(), which checks these fields to decide whether to emit CTA_EXPECT_NAT. The safe sibling nf_ct_expect_init(), used by the packet path, explicitly zeroes these fields. Zero saved_addr, saved_proto and dir in the else branch, guarded by IS_ENABLED(CONFIG_NF_NAT) since these fields only exist when NAT is enabled. Confirmed by priming the expect slab with NAT-bearing expectations, freeing them, creating a new expectation without CTA_EXPECT_NAT, and observing that the ctnetlink dump emits a spurious CTA_EXPECT_NAT containing stale data from the prior allocation. Fixes: 076a0ca02644 ("netfilter: ctnetlink: add NAT support for expectations") Reported-by: kernel test robot Signed-off-by: Qi Tang Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 620f3d14c1ef51d425060a3056ad8dbae8f998a3 Author: Qi Tang Date: Mon Mar 30 00:50:36 2026 +0800 netfilter: nf_conntrack_helper: pass helper to expect cleanup [ Upstream commit a242a9ae58aa46ff7dae51ce64150a93957abe65 ] nf_conntrack_helper_unregister() calls nf_ct_expect_iterate_destroy() to remove expectations belonging to the helper being unregistered. However, it passes NULL instead of the helper pointer as the data argument, so expect_iter_me() never matches any expectation and all of them survive the cleanup. After unregister returns, nfnl_cthelper_del() frees the helper object immediately. Subsequent expectation dumps or packet-driven init_conntrack() calls then dereference the freed exp->helper, causing a use-after-free. Pass the actual helper pointer so expectations referencing it are properly destroyed before the helper object is freed. BUG: KASAN: slab-use-after-free in string+0x38f/0x430 Read of size 1 at addr ffff888003b14d20 by task poc/103 Call Trace: string+0x38f/0x430 vsnprintf+0x3cc/0x1170 seq_printf+0x17a/0x240 exp_seq_show+0x2e5/0x560 seq_read_iter+0x419/0x1280 proc_reg_read+0x1ac/0x270 vfs_read+0x179/0x930 ksys_read+0xef/0x1c0 Freed by task 103: The buggy address is located 32 bytes inside of freed 192-byte region [ffff888003b14d00, ffff888003b14dc0) Fixes: ac7b84839003 ("netfilter: expect: add and use nf_ct_expect_iterate helpers") Signed-off-by: Qi Tang Reviewed-by: Phil Sutter Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit a54bbbcd3c62894b679c49fce39aea8e55346d0f Author: Florian Westphal Date: Mon Mar 30 14:16:34 2026 +0200 netfilter: ipset: use nla_strcmp for IPSET_ATTR_NAME attr [ Upstream commit b7e8590987aa94c9dc51518fad0e58cb887b1db5 ] IPSET_ATTR_NAME and IPSET_ATTR_NAMEREF are of NLA_STRING type, they cannot be treated like a c-string. They either have to be switched to NLA_NUL_STRING, or the compare operations need to use the nla functions. Fixes: f830837f0eed ("netfilter: ipset: list:set set type support") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit f419bdc205894750f4d3ec042bc87a1b9cde1351 Author: Florian Westphal Date: Tue Mar 31 23:13:36 2026 +0200 netfilter: x_tables: ensure names are nul-terminated [ Upstream commit a958a4f90ddd7de0800b33ca9d7b886b7d40f74e ] Reject names that lack a \0 character before feeding them to functions that expect c-strings. Fixes tag is the most recent commit that needs this change. Fixes: c38c4597e4bf ("netfilter: implement xt_cgroup cgroup2 path match") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 88a8f56e6276f616baad4274c6b8e4683e26e520 Author: Florian Westphal Date: Thu Mar 26 16:17:24 2026 +0100 netfilter: nfnetlink_log: account for netlink header size [ Upstream commit 6d52a4a0520a6696bdde51caa11f2d6821cd0c01 ] This is a followup to an old bug fix: NLMSG_DONE needs to account for the netlink header size, not just the attribute size. This can result in a WARN splat + drop of the netlink message, but other than this there are no ill effects. Fixes: 9dfa1dfe4d5e ("netfilter: nf_log: account for size of NLMSG_DONE attribute") Reported-by: Yiming Qian Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 504c9456699dcf4d15195ef34a0fa94a80bfc877 Author: Pablo Neira Ayuso Date: Thu Mar 26 00:17:09 2026 +0100 netfilter: flowtable: strictly check for maximum number of actions [ Upstream commit 76522fcdbc3a02b568f5d957f7e66fc194abb893 ] The maximum number of flowtable hardware offload actions in IPv6 is: * ethernet mangling (4 payload actions, 2 for each ethernet address) * SNAT (4 payload actions) * DNAT (4 payload actions) * Double VLAN (4 vlan actions, 2 for popping vlan, and 2 for pushing) for QinQ. * Redirect (1 action) Which makes 17, while the maximum is 16. But act_ct supports for tunnels actions too. Note that payload action operates at 32-bit word level, so mangling an IPv6 address takes 4 payload actions. Update flow_action_entry_next() calls to check for the maximum number of supported actions. While at it, rise the maximum number of actions per flow from 16 to 24 so this works fine with IPv6 setups. Fixes: c29f74e0df7a ("netfilter: nf_flow_table: hardware offload support") Reported-by: Hyunwoo Kim Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 908dd5faf8169b3b034448390a5a652166202d0f Author: Geoffrey D. Bennett Date: Wed Apr 1 16:01:27 2026 +1030 ALSA: usb-audio: Exclude Scarlett 2i2 1st Gen (8016) from SKIP_IFACE_SETUP [ Upstream commit a0dafdbd1049a8ea661a1a471be1b840bd8aed13 ] Same issue as the other 1st Gen Scarletts: QUIRK_FLAG_SKIP_IFACE_SETUP causes distorted audio on this revision of the Scarlett 2i2 1st Gen (1235:8016). Fixes: 38c322068a26 ("ALSA: usb-audio: Add QUIRK_FLAG_SKIP_IFACE_SETUP") Reported-by: lukas-reineke [https://github.com/geoffreybennett/linux-fcp/issues/54] Signed-off-by: Geoffrey D. Bennett Link: https://patch.msgid.link/acytr8aEUba4VXmZ@m.b4.vu Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 87a8287e7624433d3708c6771a851d45e7ae02ae Author: Michal Piekos Date: Sat Mar 28 09:55:51 2026 +0100 net: stmmac: skip VLAN restore when VLAN hash ops are missing [ Upstream commit 48b3cd69265f346f64b93064723492da46206e9b ] stmmac_vlan_restore() unconditionally calls stmmac_vlan_update() when NETIF_F_VLAN_FEATURES is set. On platforms where priv->hw->vlan (or ->update_vlan_hash) is not provided, stmmac_update_vlan_hash() returns -EINVAL via stmmac_do_void_callback(), resulting in a spurious "Failed to restore VLANs" error even when no VLAN filtering is in use. Remove not needed comment. Remove not used return value from stmmac_vlan_restore(). Tested on Orange Pi Zero 3. Fixes: bd7ad51253a7 ("net: stmmac: Fix VLAN HW state restore") Signed-off-by: Michal Piekos Link: https://patch.msgid.link/20260328-vlan-restore-error-v4-1-f88624c530dc@mmpsystems.pl Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 58b58b9ba89c43914eea90c18928e51852d10c24 Author: Li Xiasong Date: Mon Mar 30 20:03:35 2026 +0800 mptcp: fix soft lockup in mptcp_recvmsg() [ Upstream commit 5dd8025a49c268ab6b94d978532af3ad341132a7 ] syzbot reported a soft lockup in mptcp_recvmsg() [0]. When receiving data with MSG_PEEK | MSG_WAITALL flags, the skb is not removed from the sk_receive_queue. This causes sk_wait_data() to always find available data and never perform actual waiting, leading to a soft lockup. Fix this by adding a 'last' parameter to track the last peeked skb. This allows sk_wait_data() to make informed waiting decisions and prevent infinite loops when MSG_PEEK is used. [0]: watchdog: BUG: soft lockup - CPU#2 stuck for 156s! [server:1963] Modules linked in: CPU: 2 UID: 0 PID: 1963 Comm: server Not tainted 6.19.0-rc8 #61 PREEMPT(none) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:sk_wait_data+0x15/0x190 Code: 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 41 56 41 55 41 54 49 89 f4 55 48 89 d5 53 48 89 fb <48> 83 ec 30 65 48 8b 05 17 a4 6b 01 48 89 44 24 28 31 c0 65 48 8b RSP: 0018:ffffc90000603ca0 EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffff888102bf0800 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffc90000603d18 RDI: ffff888102bf0800 RBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000101 R10: 0000000000000000 R11: 0000000000000075 R12: ffffc90000603d18 R13: ffff888102bf0800 R14: ffff888102bf0800 R15: 0000000000000000 FS: 00007f6e38b8c4c0(0000) GS:ffff8881b877e000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055aa7bff1680 CR3: 0000000105cbe000 CR4: 00000000000006f0 Call Trace: mptcp_recvmsg+0x547/0x8c0 net/mptcp/protocol.c:2329 inet_recvmsg+0x11f/0x130 net/ipv4/af_inet.c:891 sock_recvmsg+0x94/0xc0 net/socket.c:1100 __sys_recvfrom+0xb2/0x130 net/socket.c:2256 __x64_sys_recvfrom+0x1f/0x30 net/socket.c:2267 do_syscall_64+0x59/0x2d0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:131 RIP: 0033:0x7f6e386a4a1d Code: 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8d 05 f1 de 2c 00 41 89 ca 8b 00 85 c0 75 20 45 31 c9 45 31 c0 b8 2d 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 6b f3 c3 66 0f 1f 84 00 00 00 00 00 41 56 41 RSP: 002b:00007ffc3c4bb078 EFLAGS: 00000246 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 000000000000861e RCX: 00007f6e386a4a1d RDX: 00000000000003ff RSI: 00007ffc3c4bb150 RDI: 0000000000000004 RBP: 00007ffc3c4bb570 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000103 R11: 0000000000000246 R12: 00005605dbc00be0 R13: 00007ffc3c4bb650 R14: 0000000000000000 R15: 0000000000000000 Fixes: 8e04ce45a8db ("mptcp: fix MSG_PEEK stream corruption") Signed-off-by: Li Xiasong Reviewed-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260330120335.659027-1-lixiasong1@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8d38f222795d30f710ed9b27227911a078e5aea8 Author: Geliang Tang Date: Fri Jan 30 20:24:24 2026 +0100 mptcp: add eat_recv_skb helper [ Upstream commit 436510df0cafb1bc36f12e92e0e76599be28d8f4 ] This patch extracts the free skb related code in __mptcp_recvmsg_mskq() into a new helper mptcp_eat_recv_skb(). This new helper will be used in the next patch. Signed-off-by: Geliang Tang Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260130-net-next-mptcp-splice-v2-1-31332ba70d7f@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: 5dd8025a49c2 ("mptcp: fix soft lockup in mptcp_recvmsg()") Signed-off-by: Sasha Levin commit 414726b69921fe6355ae453f5b35e68dd078342a Author: Zhengchuan Liang Date: Mon Mar 30 16:46:24 2026 +0800 net: ipv6: flowlabel: defer exclusive option free until RCU teardown [ Upstream commit 9ca562bb8e66978b53028fa32b1a190708e6a091 ] `ip6fl_seq_show()` walks the global flowlabel hash under the seq-file RCU read-side lock and prints `fl->opt->opt_nflen` when an option block is present. Exclusive flowlabels currently free `fl->opt` as soon as `fl->users` drops to zero in `fl_release()`. However, the surrounding `struct ip6_flowlabel` remains visible in the global hash table until later garbage collection removes it and `fl_free_rcu()` finally tears it down. A concurrent `/proc/net/ip6_flowlabel` reader can therefore race that early `kfree()` and dereference freed option state, triggering a crash in `ip6fl_seq_show()`. Fix this by keeping `fl->opt` alive until `fl_free_rcu()`. That matches the lifetime already required for the enclosing flowlabel while readers can still reach it under RCU. Fixes: d3aedd5ebd4b ("ipv6 flowlabel: Convert hash list to RCU.") Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Tested-by: Ren Wei Signed-off-by: Zhengchuan Liang Signed-off-by: Ren Wei Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/07351f0ec47bcee289576f39f9354f4a64add6e4.1774855883.git.zcliangcn@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8aebe18069394f4a79d2d82080a0f806da449996 Author: Alexei Starovoitov Date: Tue Mar 31 13:42:28 2026 -0700 bpf: Fix regsafe() for pointers to packet [ Upstream commit a8502a79e832b861e99218cbd2d8f4312d62e225 ] In case rold->reg->range == BEYOND_PKT_END && rcur->reg->range == N regsafe() may return true which may lead to current state with valid packet range not being explored. Fix the bug. Fixes: 6d94e741a8ff ("bpf: Support for pointers beyond pkt_end.") Signed-off-by: Alexei Starovoitov Signed-off-by: Andrii Nakryiko Reviewed-by: Daniel Borkmann Reviewed-by: Amery Hung Acked-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/20260331204228.26726-1-alexei.starovoitov@gmail.com Signed-off-by: Sasha Levin commit 917303fda0f1b65d986de4660964f14ce0337209 Author: Julian Braha Date: Wed Mar 25 00:15:21 2026 +0000 ASoC: Intel: boards: fix unmet dependency on PINCTRL [ Upstream commit e920c36f2073d533bdf19ba6ab690432c8173b63 ] This reverts commit c073f0757663 ("ASoC: Intel: sof_sdw: select PINCTRL_CS42L43 and SPI_CS42L43") Currently, SND_SOC_INTEL_SOUNDWIRE_SOF_MACH selects PINCTRL_CS42L43 without also selecting or depending on PINCTRL, despite PINCTRL_CS42L43 depending on PINCTRL. See the following Kbuild warning: WARNING: unmet direct dependencies detected for PINCTRL_CS42L43 Depends on [n]: PINCTRL [=n] && MFD_CS42L43 [=m] Selected by [m]: - SND_SOC_INTEL_SOUNDWIRE_SOF_MACH [=m] && SOUND [=y] && SND [=m] && SND_SOC [=m] && SND_SOC_INTEL_MACH [=y] && (SND_SOC_SOF_INTEL_COMMON [=m] || !SND_SOC_SOF_INTEL_COMMON [=m]) && SND_SOC_SOF_INTEL_SOUNDWIRE [=m] && I2C [=y] && SPI_MASTER [=y] && ACPI [=y] && (MFD_INTEL_LPSS [=n] || COMPILE_TEST [=y]) && (SND_SOC_INTEL_USER_FRIENDLY_LONG_NAMES [=n] || COMPILE_TEST [=y]) && SOUNDWIRE [=m] In response to v1 of this patch [1], Arnd pointed out that there is no compile-time dependency sof_sdw and the PINCTRL_CS42L43 driver. After testing, I can confirm that the kernel compiled with SND_SOC_INTEL_SOUNDWIRE_SOF_MACH enabled and PINCTRL_CS42L43 disabled. This unmet dependency was detected by kconfirm, a static analysis tool for Kconfig. Link: https://lore.kernel.org/all/b8aecc71-1fed-4f52-9f6c-263fbe56d493@app.fastmail.com/ [1] Fixes: c073f0757663 ("ASoC: Intel: sof_sdw: select PINCTRL_CS42L43 and SPI_CS42L43") Signed-off-by: Julian Braha Acked-by: Arnd Bergmann Link: https://patch.msgid.link/20260325001522.1727678-1-julianbraha@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2a0323a913109b52bfc9f5ea7b92a1b249e07d3e Author: Suraj Gupta Date: Fri Mar 27 13:02:38 2026 +0530 net: xilinx: axienet: Fix BQL accounting for multi-BD TX packets [ Upstream commit d1978d03e86785872871bff9c2623174b10740de ] When a TX packet spans multiple buffer descriptors (scatter-gather), axienet_free_tx_chain sums the per-BD actual length from descriptor status into a caller-provided accumulator. That sum is reset on each NAPI poll. If the BDs for a single packet complete across different polls, the earlier bytes are lost and never credited to BQL. This causes BQL to think bytes are permanently in-flight, eventually stalling the TX queue. The SKB pointer is stored only on the last BD of a packet. When that BD completes, use skb->len for the byte count instead of summing per-BD status lengths. This matches netdev_sent_queue(), which debits skb->len, and naturally survives across polls because no partial packet contributes to the accumulator. Fixes: c900e49d58eb ("net: xilinx: axienet: Implement BQL") Signed-off-by: Suraj Gupta Reviewed-by: Sean Anderson Link: https://patch.msgid.link/20260327073238.134948-3-suraj.gupta2@amd.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f3cf32dc1ebbd8172c057e4fc2bba5209135847c Author: Suraj Gupta Date: Fri Mar 27 13:02:37 2026 +0530 net: xilinx: axienet: Correct BD length masks to match AXIDMA IP spec [ Upstream commit 393e0b4f178ec7fce1141dacc3304e3607a92ee9 ] The XAXIDMA_BD_CTRL_LENGTH_MASK and XAXIDMA_BD_STS_ACTUAL_LEN_MASK macros were defined as 0x007FFFFF (23 bits), but the AXI DMA IP product guide (PG021) specifies the buffer length field as bits 25:0 (26 bits). Update both masks to match the IP documentation. In practice this had no functional impact, since Ethernet frames are far smaller than 2^23 bytes and the extra bits were always zero, but the masks should still reflect the hardware specification. Fixes: 8a3b7a252dca ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver") Signed-off-by: Suraj Gupta Reviewed-by: Sean Anderson Link: https://patch.msgid.link/20260327073238.134948-2-suraj.gupta2@amd.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ad2f60de5045bfb5d20ea468a97c8760c6a3a4f8 Author: Pengpeng Hou Date: Thu Mar 26 22:20:33 2026 +0800 NFC: pn533: bound the UART receive buffer [ Upstream commit 30fe3f5f6494f827d812ff179f295a8e532709d6 ] pn532_receive_buf() appends every incoming byte to dev->recv_skb and only resets the buffer after pn532_uart_rx_is_frame() recognizes a complete frame. A continuous stream of bytes without a valid PN532 frame header therefore keeps growing the skb until skb_put_u8() hits the tail limit. Drop the accumulated partial frame once the fixed receive buffer is full so malformed UART traffic cannot grow the skb past PN532_UART_SKB_BUFF_LEN. Fixes: c656aa4c27b1 ("nfc: pn533: add UART phy driver") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260326142033.82297-1-pengpeng@iscas.ac.cn Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit d4cc7e4c80b1634c7b1497574a2fdb18df6c026c Author: Xiang Mei Date: Thu Mar 26 00:55:53 2026 -0700 net: bonding: fix use-after-free in bond_xmit_broadcast() [ Upstream commit 2884bf72fb8f03409e423397319205de48adca16 ] bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is "last" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the "last" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Fixes: 4e5bd03ae346 ("net: bonding: fix bond_xmit_broadcast return value error bug") Reported-by: Weiming Shi Signed-off-by: Xiang Mei Link: https://patch.msgid.link/20260326075553.3960562-1-xmei5@asu.edu Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 153d5520c3f9fd62e71c7e7f9e34b59cf411e555 Author: Herbert Xu Date: Fri Mar 27 15:04:17 2026 +0900 crypto: authencesn - Do not place hiseq at end of dst for out-of-place decryption [ Upstream commit e02494114ebf7c8b42777c6cd6982f113bfdbec7 ] When decrypting data that is not in-place (src != dst), there is no need to save the high-order sequence bits in dst as it could simply be re-copied from the source. However, the data to be hashed need to be rearranged accordingly. Reported-by: Taeyang Lee <0wn@theori.io> Fixes: 104880a6b470 ("crypto: authencesn - Convert to new AEAD interface") Signed-off-by: Herbert Xu Thanks, Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit fafe0fa2995a0f7073c1c358d7d3145bcc9aedd8 Author: Herbert Xu Date: Thu Mar 26 15:30:20 2026 +0900 crypto: algif_aead - Revert to operating out-of-place [ Upstream commit a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5 ] This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly. Fixes: 72548b093ee3 ("crypto: algif_aead - copy AAD from src to dst") Reported-by: Taeyang Lee <0wn@theori.io> Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit c8d53b70166d1dc463ef42adb7293e1a770822c7 Author: Pengpeng Hou Date: Sun Mar 29 07:43:56 2026 +0800 bnxt_en: set backing store type from query type [ Upstream commit 4ee937107d52f9e5c350e4b5e629760e328b3d9f ] bnxt_hwrm_func_backing_store_qcaps_v2() stores resp->type from the firmware response in ctxm->type and later uses that value to index fixed backing-store metadata arrays such as ctx_arr[] and bnxt_bstore_to_trace[]. ctxm->type is fixed by the current backing-store query type and matches the array index of ctx->ctx_arr. Set ctxm->type from the current loop variable instead of depending on resp->type. Also update the loop to advance type from next_valid_type in the for statement, which keeps the control flow simpler for non-valid and unchanged entries. Fixes: 6a4d0774f02d ("bnxt_en: Add support for new backing store query firmware API") Signed-off-by: Pengpeng Hou Reviewed-by: Michael Chan Tested-by: Michael Chan Link: https://patch.msgid.link/20260328234357.43669-1-pengpeng@iscas.ac.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 906997ea3766c24fbbf9cc4bf17c047315bbd138 Author: Yochai Eisenrich Date: Sun Mar 29 00:14:36 2026 +0300 net: sched: cls_api: fix tc_chain_fill_node to initialize tcm_info to zero to prevent an info-leak [ Upstream commit e6e3eb5ee89ac4c163d46429391c889a1bb5e404 ] When building netlink messages, tc_chain_fill_node() never initializes the tcm_info field of struct tcmsg. Since the allocation is not zeroed, kernel heap memory is leaked to userspace through this 4-byte field. The fix simply zeroes tcm_info alongside the other fields that are already initialized. Fixes: 32a4f5ecd738 ("net: sched: introduce chain object to uapi") Signed-off-by: Yochai Eisenrich Acked-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260328211436.1010152-1-echelonh@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cc91202fc20a44aab4c206f12a2bfe05da936051 Author: Guoyu Su Date: Fri Mar 27 23:35:07 2026 +0800 net: use skb_header_pointer() for TCPv4 GSO frag_off check [ Upstream commit ddc748a391dd8642ba6b2e4fe22e7f2ddf84b7f0 ] Syzbot reported a KMSAN uninit-value warning in gso_features_check() called from netif_skb_features() [1]. gso_features_check() reads iph->frag_off to decide whether to clear mangleid_features. Accessing the IPv4 header via ip_hdr()/inner_ip_hdr() can rely on skb header offsets that are not always safe for direct dereference on packets injected from PF_PACKET paths. Use skb_header_pointer() for the TCPv4 frag_off check so the header read is robust whether data is already linear or needs copying. [1] https://syzkaller.appspot.com/bug?extid=1543a7d954d9c6d00407 Link: https://lore.kernel.org/netdev/willemdebruijn.kernel.1a9f35039caab@gmail.com/ Fixes: cbc53e08a793 ("GSO: Add GSO type for fixed IPv4 ID") Reported-by: syzbot+1543a7d954d9c6d00407@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1543a7d954d9c6d00407 Tested-by: syzbot+1543a7d954d9c6d00407@syzkaller.appspotmail.com Signed-off-by: Guoyu Su Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260327153507.39742-1-yss2813483011xxl@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 846cd4a5ffdce06a202409685c7bc4c42a6e913c Author: Paolo Abeni Date: Wed Jan 21 17:11:27 2026 +0100 net: introduce mangleid_features [ Upstream commit 31c5a71d982b57df75858974634c2f0a338f2fc6 ] Some/most devices implementing gso_partial need to disable the GSO partial features when the IP ID can't be mangled; to that extend each of them implements something alike the following[1]: if (skb->encapsulation && !(features & NETIF_F_TSO_MANGLEID)) features &= ~NETIF_F_TSO; in the ndo_features_check() op, which leads to a bit of duplicate code. Later patch in the series will implement GSO partial support for virtual devices, and the current status quo will require more duplicate code and a new indirect call in the TX path for them. Introduce the mangleid_features mask, allowing the core to disable NIC features based on/requiring MANGLEID, without any further intervention from the driver. The same functionality could be alternatively implemented adding a single boolean flag to the struct net_device, but would require an additional checks in ndo_features_check(). Also note that [1] is incorrect if the NIC additionally implements NETIF_F_GSO_UDP_L4, mangleid_features transparently handle even such a case. Signed-off-by: Paolo Abeni Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/5a7cdaeea40b0a29b88e525b6c942d73ed3b8ce7.1769011015.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski Stable-dep-of: ddc748a391dd ("net: use skb_header_pointer() for TCPv4 GSO frag_off check") Signed-off-by: Sasha Levin commit ae585d9ac863f07cbf329ab066b214ce312f5fab Author: Lorenzo Bianconi Date: Fri Mar 27 10:48:21 2026 +0100 net: airoha: Add missing cleanup bits in airoha_qdma_cleanup_rx_queue() [ Upstream commit 514aac3599879a7ed48b7dc19e31145beb6958ac ] In order to properly cleanup hw rx QDMA queues and bring the device to the initial state, reset rx DMA queue head/tail index. Moreover, reset queued DMA descriptor fields. Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC") Tested-by: Madhur Agrawal Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260327-airoha_qdma_cleanup_rx_queue-fix-v1-1-369d6ab1511a@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3cd4efb5df72843dfac892d0b3c7a4a8bd926b65 Author: Paolo Abeni Date: Fri Mar 27 10:52:57 2026 +0100 ipv6: prevent possible UaF in addrconf_permanent_addr() [ Upstream commit fd63f185979b047fb22a0dfc6bd94d0cab6a6a70 ] The mentioned helper try to warn the user about an exceptional condition, but the message is delivered too late, accessing the ipv6 after its possible deletion. Reorder the statement to avoid the possible UaF; while at it, place the warning outside the idev->lock as it needs no protection. Reported-by: Jakub Kicinski Closes: https://sashiko.dev/#/patchset/8c8bfe2e1a324e501f0e15fef404a77443fd8caf.1774365668.git.pabeni%40redhat.com Fixes: f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional") Signed-off-by: Paolo Abeni Link: https://patch.msgid.link/ef973c3a8cb4f8f1787ed469f3e5391b9fe95aa0.1774601542.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2321b0d47a11a9479e1856fa50c934dcb7718c2c Author: Jihed Chaibi Date: Tue Mar 24 22:09:09 2026 +0100 ASoC: ep93xx: Fix unchecked clk_prepare_enable() and add rollback on failure [ Upstream commit 622363757b2286dd2c2984b0d80255cbb35a0495 ] ep93xx_i2s_enable() calls clk_prepare_enable() on three clocks in sequence (mclk, sclk, lrclk) without checking the return value of any of them. If an intermediate enable fails, the clocks that were already enabled are never rolled back, leaking them until the next disable cycle — which may never come if the stream never started cleanly. Change ep93xx_i2s_enable() from void to int. Add error checking after each clk_prepare_enable() call and unwind already-enabled clocks on failure. Propagate the error through ep93xx_i2s_startup() and ep93xx_i2s_resume(), both of which already return int. Signed-off-by: Jihed Chaibi Fixes: f4ff6b56bc8a ("ASoC: cirrus: i2s: Prepare clock before using it") Link: https://patch.msgid.link/20260324210909.45494-1-jihed.chaibi.dev@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 19f90e0061b690586bb5decdcc09d38652277e00 Author: Dag Smedberg Date: Sun Mar 29 19:04:20 2026 +0200 ALSA: usb-audio: Exclude Scarlett Solo 1st Gen from SKIP_IFACE_SETUP [ Upstream commit f025ac8c698ac7d29eb3b5025bcdaf7ad675785d ] Same issue that the Scarlett 2i2 1st Gen had: QUIRK_FLAG_SKIP_IFACE_SETUP causes distorted audio on the Scarlett Solo 1st Gen (1235:801c). Fixes: 38c322068a26 ("ALSA: usb-audio: Add QUIRK_FLAG_SKIP_IFACE_SETUP") Reported-by: Dag Smedberg Tested-by: Dag Smedberg Signed-off-by: Dag Smedberg Link: https://patch.msgid.link/20260329170420.4122-1-dag@dsmedberg.se Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 15db5c44f79c498dde31c7930f3b458ca62dde92 Author: Wei Fang Date: Thu Mar 26 15:52:33 2026 +0800 net: enetc: do not allow VF to configure the RSS key [ Upstream commit a142d139168cce8d5776245b5494c7f7f5d7fb7d ] VFs do not have privilege to configure the RSS key because the registers are owned by the PF. Currently, if VF attempts to configure the RSS key, enetc_set_rxfh() simply skips the configuration and does not generate a warning, which may mislead users into thinking the feature is supported. To improve this situation, add a check to reject RSS key configuration on VFs. Fixes: d382563f541b ("enetc: Add RFS and RSS support") Signed-off-by: Wei Fang Reviewed-by: Clark Wang Reviewed-by: Claudiu Manoil Link: https://patch.msgid.link/20260326075233.3628047-3-wei.fang@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 85b4fb46a898948657b54319bb8022522e49b8aa Author: Wei Fang Date: Thu Mar 26 15:52:32 2026 +0800 net: enetc: check whether the RSS algorithm is Toeplitz [ Upstream commit d389954a6cae7bf76b7b082ac3511d177b77ef2d ] Both ENETC v1 and v4 only provide Toeplitz RSS support. This patch adds a validation check to reject attempts to configure other RSS algorithms, avoiding misleading configuration options for users. Fixes: d382563f541b ("enetc: Add RFS and RSS support") Signed-off-by: Wei Fang Reviewed-by: Clark Wang Reviewed-by: Claudiu Manoil Link: https://patch.msgid.link/20260326075233.3628047-2-wei.fang@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3b4df3d43ae42d6d3749f3f9b00ada27dc816b66 Author: Marek Behún Date: Thu Mar 26 13:20:38 2026 +0100 net: sfp: Fix Ubiquiti U-Fiber Instant SFP module on mvneta [ Upstream commit eeee5a710f26ce57807024ef330fe5a850eaecd8 ] In commit 8110633db49d7de2 ("net: sfp-bus: allow SFP quirks to override Autoneg and pause bits") we moved the setting of Autoneg and pause bits before the call to SFP quirk when parsing SFP module support. Since the quirk for Ubiquiti U-Fiber Instant SFP module zeroes the support bits and sets 1000baseX_Full only, the above mentioned commit changed the overall computed support from 1000baseX_Full, Autoneg, Pause, Asym_Pause to just 1000baseX_Full. This broke the SFP module for mvneta, which requires Autoneg for 1000baseX since commit c762b7fac1b249a9 ("net: mvneta: deny disabling autoneg for 802.3z modes"). Fix this by setting back the Autoneg, Pause and Asym_Pause bits in the quirk. Fixes: 8110633db49d7de2 ("net: sfp-bus: allow SFP quirks to override Autoneg and pause bits") Signed-off-by: Marek Behún Reviewed-by: Russell King (Oracle) Link: https://patch.msgid.link/20260326122038.2489589-1-kabel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 17c1b9807b8a67d676b6dcf749ee932ebaa7f568 Author: Xiang Mei Date: Thu Mar 26 13:43:09 2026 -0700 net/sched: sch_hfsc: fix divide-by-zero in rtsc_min() [ Upstream commit 4576100b8cd03118267513cafacde164b498b322 ] m2sm() converts a u32 slope to a u64 scaled value. For large inputs (e.g. m1=4000000000), the result can reach 2^32. rtsc_min() stores the difference of two such u64 values in a u32 variable `dsm` and uses it as a divisor. When the difference is exactly 2^32 the truncation yields zero, causing a divide-by-zero oops in the concave-curve intersection path: Oops: divide error: 0000 RIP: 0010:rtsc_min (net/sched/sch_hfsc.c:601) Call Trace: init_ed (net/sched/sch_hfsc.c:629) hfsc_enqueue (net/sched/sch_hfsc.c:1569) [...] Widen `dsm` to u64 and replace do_div() with div64_u64() so the full difference is preserved. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Weiming Shi Signed-off-by: Xiang Mei Acked-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260326204310.1549327-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9c55e41c73af5c4511070933b1bd25248521270c Author: Yang Yang Date: Thu Mar 26 03:44:39 2026 +0000 bridge: br_nd_send: linearize skb before parsing ND options [ Upstream commit a01aee7cafc575bb82f5529e8734e7052f9b16ea ] br_nd_send() parses neighbour discovery options from ns->opt[] and assumes that these options are in the linear part of request. Its callers only guarantee that the ICMPv6 header and target address are available, so the option area can still be non-linear. Parsing ns->opt[] in that case can access data past the linear buffer. Linearize request before option parsing and derive ns from the linear network header. Fixes: ed842faeb2bd ("bridge: suppress nd pkts on BR_NEIGH_SUPPRESS ports") Reported-by: Yifan Wu Reported-by: Juefei Pu Tested-by: Ao Zhou Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Signed-off-by: Yang Yang Reviewed-by: Ido Schimmel Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260326034441.2037420-2-n05ec@lzu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 117f9453dd7cd8f81156d7f745ebbbde8794dfaf Author: Dimitri Daskalakis Date: Tue Mar 24 12:51:22 2026 -0700 eth: fbnic: Account for page fragments when updating BDQ tail [ Upstream commit b38c55320bf85a84a4f04803c57b261fc87e9b4b ] FBNIC supports fixed size buffers of 4K. When PAGE_SIZE > 4K, we fragment the page across multiple descriptors (FBNIC_BD_FRAG_COUNT). When refilling the BDQ, the correct number of entries are populated, but tail was only incremented by one. So on a system with 64K pages, HW would get one descriptor refilled for every 16 we populate. Additionally, we program the ring size in the HW when enabling the BDQ. This was not accounting for page fragments, so on systems with 64K pages, the HW used 1/16th of the ring. Fixes: 0cb4c0a13723 ("eth: fbnic: Implement Rx queue alloc/start/stop/free") Signed-off-by: Dimitri Daskalakis Link: https://patch.msgid.link/20260324195123.3486219-2-dimitri.daskalakis1@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 590f622669b97eaf7b57a1de7b0a6e68c5d8b2c3 Author: Eric Dumazet Date: Thu Mar 26 15:51:38 2026 +0000 ip6_tunnel: clear skb2->cb[] in ip4ip6_err() [ Upstream commit 2edfa31769a4add828a7e604b21cb82aaaa05925 ] Oskar Kjos reported the following problem. ip4ip6_err() calls icmp_send() on a cloned skb whose cb[] was written by the IPv6 receive path as struct inet6_skb_parm. icmp_send() passes IPCB(skb2) to __ip_options_echo(), which interprets that cb[] region as struct inet_skb_parm (IPv4). The layouts differ: inet6_skb_parm.nhoff at offset 14 overlaps inet_skb_parm.opt.rr, producing a non-zero rr value. __ip_options_echo() then reads optlen from attacker-controlled packet data at sptr[rr+1] and copies that many bytes into dopt->__data, a fixed 40-byte stack buffer (IP_OPTIONS_DATA_FIXED_SIZE). To fix this we clear skb2->cb[], as suggested by Oskar Kjos. Also add minimal IPv4 header validation (version == 4, ihl >= 5). Fixes: c4d3efafcc93 ("[IPV6] IP6TUNNEL: Add support to IPv4 over IPv6 tunnel.") Reported-by: Oskar Kjos Signed-off-by: Eric Dumazet Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260326155138.2429480-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a2edbb6393972a02114b6003953a5cef3104fada Author: Eric Dumazet Date: Thu Mar 26 20:26:08 2026 +0000 ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach() [ Upstream commit 86ab3e55673a7a49a841838776f1ab18d23a67b5 ] Sashiko AI-review observed: In ip6_err_gen_icmpv6_unreach(), the skb is an outer IPv4 ICMP error packet where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2 and passed to icmp6_send(), it uses IP6CB(skb2). IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm. The cipso offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm at offset 18. If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside icmp6_send(), mip6_addr_swap() is called and uses ipv6_find_tlv(skb, opt->dsthao, IPV6_TLV_HAO). This would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a fake TLV without checking if the remaining packet length can hold the full 18-byte struct ipv6_destopt_hao. Could mip6_addr_swap() then perform a 16-byte swap that extends past the end of the packet data into skb_shared_info? Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and ip6ip6_err() to prevent this? This patch implements the first suggestion. I am not sure if ip6ip6_err() needs to be changed. A separate patch would be better anyway. Fixes: ca15a078bd90 ("sit: generate icmpv6 error when receiving icmpv4 error") Reported-by: Ido Schimmel Closes: https://sashiko.dev/#/patchset/20260326155138.2429480-1-edumazet%40google.com Signed-off-by: Eric Dumazet Cc: Oskar Kjos Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260326202608.2976021-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7e55845bd8971e9ea60965caec60294748f4fe1d Author: Thomas Bogendoerfer Date: Wed Mar 25 12:20:53 2026 +0100 tg3: Fix race for querying speed/duplex [ Upstream commit bb417456c7814d1493d98b7dd9c040bf3ce3b4ed ] When driver signals carrier up via netif_carrier_on() its internal link_up state isn't updated immediately. This leads to inconsistent speed/duplex in /proc/net/bonding/bondX where the speed and duplex is shown as unknown while ethtool shows correct values. Fix this by using netif_carrier_ok() for link checking in get_ksettings function. Fixes: 84421b99cedc ("tg3: Update link_up flag for phylib devices") Signed-off-by: Thomas Bogendoerfer Reviewed-by: Pavan Chebbi Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 184d2e9db27c0f76226b5cad16fe29510a5d2280 Author: Pengpeng Hou Date: Wed Mar 25 15:41:52 2026 +0800 net/ipv6: ioam6: prevent schema length wraparound in trace fill [ Upstream commit 5e67ba9bb531e1ec6599a82a065dea9040b9ce50 ] ioam6_fill_trace_data() stores the schema contribution to the trace length in a u8. With bit 22 enabled and the largest schema payload, sclen becomes 1 + 1020 / 4, wraps from 256 to 0, and bypasses the remaining-space check. __ioam6_fill_trace_data() then positions the write cursor without reserving the schema area but still copies the 4-byte schema header and the full schema payload, overrunning the trace buffer. Keep sclen in an unsigned int so the remaining-space check and the write cursor calculation both see the full schema length. Fixes: 8c6f6fa67726 ("ipv6: ioam: IOAM Generic Netlink API") Signed-off-by: Pengpeng Hou Reviewed-by: Justin Iurman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b485eef3d97b7aae55ce669b6de555ec81f3d21c Author: Yochai Eisenrich Date: Wed Mar 25 00:49:25 2026 +0200 net: ipv6: ndisc: fix ndisc_ra_useropt to initialize nduseropt_padX fields to zero to prevent an info-leak [ Upstream commit ae05340ccaa9d347fe85415609e075545bec589f ] When processing Router Advertisements with user options the kernel builds an RTM_NEWNDUSEROPT netlink message. The nduseroptmsg struct has three padding fields that are never zeroed and can leak kernel data The fix is simple, just zeroes the padding fields. Fixes: 31910575a9de ("[IPv6]: Export userland ND options through netlink (RDNSS support)") Signed-off-by: Yochai Eisenrich Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260324224925.2437775-1-echelonh@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f2664bc4f0f356f17c2094587a2b3665e3867e44 Author: Jiayuan Chen Date: Tue Mar 24 16:06:44 2026 +0800 net: qrtr: replace qrtr_tx_flow radix_tree with xarray to fix memory leak [ Upstream commit 2428083101f6883f979cceffa76cd8440751ffe6 ] __radix_tree_create() allocates and links intermediate nodes into the tree one by one. If a subsequent allocation fails, the already-linked nodes remain in the tree with no corresponding leaf entry. These orphaned internal nodes are never reclaimed because radix_tree_for_each_slot() only visits slots containing leaf values. The radix_tree API is deprecated in favor of xarray. As suggested by Matthew Wilcox, migrate qrtr_tx_flow from radix_tree to xarray instead of fixing the radix_tree itself [1]. xarray properly handles cleanup of internal nodes — xa_destroy() frees all internal xarray nodes when the qrtr_node is released, preventing the leak. [1] https://lore.kernel.org/all/20260225071623.41275-1-jiayuan.chen@linux.dev/T/ Reported-by: syzbot+006987d1be3586e13555@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/000000000000bfba3a060bf4ffcf@google.com/T/ Fixes: 5fdeb0d372ab ("net: qrtr: Implement outgoing flow control") Signed-off-by: Jiayuan Chen Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260324080645.290197-1-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 77c5f0a105d04f65c42179b83090c3b5c3493cbe Author: Wei Fang Date: Tue Mar 24 14:21:19 2026 +0800 net: enetc: reset PIR and CIR if they are not equal when initializing TX ring [ Upstream commit 0239fd701d33475a39428daa3dc627407cd417a6 ] Currently the driver does not reset the producer index register (PIR) and consumer index register (CIR) when initializing a TX BD ring. The driver only reads the PIR and CIR and initializes the software indexes. If the TX BD ring is reinitialized when it still contains unsent frames, its PIR and CIR will not be equal after the reinitialization. However, the BDs between CIR and PIR have been freed and become invalid and this can lead to a hardware malfunction, causing the TX BD ring will not work properly. For ENETC v4, it supports software to set the PIR and CIR, so the driver can reset these two registers if they are not equal when reinitializing the TX BD ring. Therefore, add this solution for ENETC v4. Note that this patch does not work for ENETC v1 because it does not support software to set the PIR and CIR. Fixes: 99100d0d9922 ("net: enetc: add preliminary support for i.MX95 ENETC PF") Signed-off-by: Wei Fang Reviewed-by: Claudiu Manoil Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260324062121.2745033-2-wei.fang@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 98bef6f424a37596cf5624446907987a10a51104 Author: Buday Csaba Date: Tue Mar 24 14:32:30 2026 +0100 net: fec: fix the PTP periodic output sysfs interface [ Upstream commit e8e44c98f789dee45cfd24ffb9d4936e0606d7c6 ] When the PPS channel configuration was implemented, the channel index for the periodic outputs was configured as the hardware channel number. The sysfs interface uses a logical channel index, and rejects numbers greater than `n_per_out` (see period_store() in ptp_sysfs.c). That property was left at 1, since the driver implements channel selection, not simultaneous operation of multiple PTP hardware timer channels. A second check in fec_ptp_enable() returns -EOPNOTSUPP when the two channel numbers disagree, making channels 1..3 unusable from sysfs. Fix by removing this redundant check in the FEC PTP driver. Fixes: 566c2d83887f ("net: fec: make PPS channel configurable") Signed-off-by: Buday Csaba Link: https://patch.msgid.link/8ec2afe88423c2231f9cf8044d212ce57846670e.1774359059.git.buday.csaba@prolan.hu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 53219f87bd220e489928caa6ffa793cea3946931 Author: Qingfang Deng Date: Tue Mar 24 22:08:56 2026 +0800 netdevsim: fix build if SKB_EXTENSIONS=n [ Upstream commit 57a04a13aac1f247d171c3f3aef93efc69e6979e ] __skb_ext_put() is not declared if SKB_EXTENSIONS is not enabled, which causes a build error: drivers/net/netdevsim/netdev.c: In function 'nsim_forward_skb': drivers/net/netdevsim/netdev.c:114:25: error: implicit declaration of function '__skb_ext_put'; did you mean 'skb_ext_put'? [-Werror=implicit-function-declaration] 114 | __skb_ext_put(psp_ext); | ^~~~~~~~~~~~~ | skb_ext_put cc1: some warnings being treated as errors Add a stub to fix the build. Fixes: 7d9351435ebb ("netdevsim: drop PSP ext ref on forward failure") Signed-off-by: Qingfang Deng Link: https://patch.msgid.link/20260324140857.783-1-dqfext@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7267e4c75f9f1916d19b6f473a6094d29102d6e7 Author: Dipayaan Roy Date: Tue Mar 24 11:14:28 2026 -0700 net: mana: Fix RX skb truesize accounting [ Upstream commit f73896b4197ed53cf0894657c899265ef7c86b7a ] MANA passes rxq->alloc_size to napi_build_skb() for all RX buffers. It is correct for fragment-backed RX buffers, where alloc_size matches the actual backing allocation used for each packet buffer. However, in the non-fragment RX path mana allocates a full page, or a higher-order page, per RX buffer. In that case alloc_size only reflects the usable packet area and not the actual backing memory. This causes napi_build_skb() to underestimate the skb backing allocation in the single-buffer RX path, so skb->truesize is derived from a value smaller than the real RX buffer allocation. Fix this by updating alloc_size in the non-fragment RX path to the actual backing allocation size before it is passed to napi_build_skb(). Fixes: 730ff06d3f5c ("net: mana: Use page pool fragments for RX buffers instead of full pages to improve memory efficiency.") Signed-off-by: Dipayaan Roy Reviewed-by: Haiyang Zhang Link: https://patch.msgid.link/acLUhLpLum6qrD/N@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 00cbdec17c15d024a1c5002c7365df7624a18a75 Author: Norbert Szetei Date: Wed Mar 25 18:26:13 2026 +0100 crypto: af-alg - fix NULL pointer dereference in scatterwalk [ Upstream commit 62397b493e14107ae82d8b80938f293d95425bcb ] The AF_ALG interface fails to unmark the end of a Scatter/Gather List (SGL) when chaining a new af_alg_tsgl structure. If a sendmsg() fills an SGL exactly to MAX_SGL_ENTS, the last entry is marked as the end. A subsequent sendmsg() allocates a new SGL and chains it, but fails to clear the end marker on the previous SGL's last data entry. This causes the crypto scatterwalk to hit a premature end, returning NULL on sg_next() and leading to a kernel panic during dereference. Fix this by explicitly unmarking the end of the previous SGL when performing sg_chain() in af_alg_alloc_tsgl(). Fixes: 8ff590903d5f ("crypto: algif_skcipher - User-space interface for skcipher operations") Signed-off-by: Norbert Szetei Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 83622e52431ebf8317dc36003ab5a1a311b19da2 Author: Mikulas Patocka Date: Wed Mar 25 16:31:38 2026 +0100 crypto: deflate - fix spurious -ENOSPC [ Upstream commit 6d89f743e57cb34e233a8217b394c7ee09abf225 ] The code in deflate_decompress_one may erroneously return -ENOSPC even if it didn't run out of output space. The error happens under this condition: - Suppose that there are two input pages, the compressed data fits into the first page and the zlib checksum is placed in the second page. - The code iterates over the first page, decompresses the data and fully fills the destination buffer, zlib_inflate returns Z_OK becuse zlib hasn't seen the checksum yet. - The outer do-while loop is iterated again, acomp_walk_next_src sets the input parameters to the second page containing the checksum. - We go into the inner do-while loop, execute "dcur = acomp_walk_next_dst(&walk);". "dcur" is zero, so we break out of the loop and return -ENOSPC, despite the fact that the decompressed data fit into the destination buffer. In order to fix this bug, this commit changes the logic when to report the -ENOSPC error. We report the error if the destination buffer is empty *and* if zlib_inflate didn't make any progress consuming the input buffer. If zlib_inflate consumes the trailing checksum, we see that it made progress and we will not return -ENOSPC. Fixes: 08cabc7d3c86 ("crypto: deflate - Convert to acomp") Signed-off-by: Mikulas Patocka Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit aa545df011338df13f0833fc1fabcb15c0521959 Author: Horia Geantă Date: Tue Mar 17 12:25:14 2026 +0200 crypto: caam - fix overflow on long hmac keys [ Upstream commit 80688afb9c35b3934ce2d6be9973758915e2e0ef ] When a key longer than block size is supplied, it is copied and then hashed into the real key. The memory allocated for the copy needs to be rounded to DMA cache alignment, as otherwise the hashed key may corrupt neighbouring memory. The copying is performed using kmemdup, however this leads to an overflow: reading more bytes (aligned_len - keylen) from the keylen source buffer. Fix this by replacing kmemdup with kmalloc, followed by memcpy. Fixes: 199354d7fb6e ("crypto: caam - Remove GFP_DMA and add DMA alignment padding") Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 68feed135a0c7243a9275ae7e6a18260f755f52b Author: Horia Geantă Date: Tue Mar 17 12:25:13 2026 +0200 crypto: caam - fix DMA corruption on long hmac keys [ Upstream commit 5ddfdcbe10dc5f97afc4e46ca22be2be717e8caf ] When a key longer than block size is supplied, it is copied and then hashed into the real key. The memory allocated for the copy needs to be rounded to DMA cache alignment, as otherwise the hashed key may corrupt neighbouring memory. The rounding was performed, but never actually used for the allocation. Fix this by replacing kmemdup with kmalloc for a larger buffer, followed by memcpy. Fixes: 199354d7fb6e ("crypto: caam - Remove GFP_DMA and add DMA alignment padding") Reported-by: Paul Bunyan Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 91478edb8cbc2744c75d0844f87f7da499c7a3b6 Author: Reshma Immaculate Rajkumar Date: Thu Mar 19 12:26:08 2026 +0530 wifi: ath11k: Pass the correct value of each TID during a stop AMPDU session [ Upstream commit e225b36f83d7926c1f2035923bb0359d851fdb73 ] During ongoing traffic, a request to stop an AMPDU session for one TID could incorrectly affect other active sessions. This can happen because an incorrect TID reference would be passed when updating the BA session state, causing the wrong session to be stopped. As a result, the affected session would be reduced to a minimal BA size, leading to a noticeable throughput degradation. Fix this issue by passing the correct argument from ath11k_dp_rx_ampdu_stop() to ath11k_peer_rx_tid_reo_update() during a stop AMPDU session. Instead of passing peer->tx_tid, which is the base address of the array, corresponding to TID 0; pass the value of &peer->rx_tid[params->tid], where the different TID numbers are accounted for. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.9.0.1-02146-QCAHKSWPL_SILICONZ-1 Fixes: d5c65159f2895 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Reshma Immaculate Rajkumar Reviewed-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20260319065608.2408179-1-reshma.rajkumar@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 52dc79062f2398666fa10759f40516fc5482a331 Author: Johannes Berg Date: Tue Mar 24 11:33:26 2026 +0200 wifi: iwlwifi: mld: correctly set wifi generation data [ Upstream commit 687a95d204e72e52f2e6bc7a994cc82f76b2678f ] In each MAC context, the firmware expects the wifi generation data, i.e. whether or not HE/EHT (and in the future UHR) is enabled on that MAC. However, this is currently handled wrong in two ways: - EHT is only enabled when the interface is also an MLD, but we currently allow (despite the spec) connecting with EHT but without MLO. - when HE or EHT are used by TDLS peers, the firmware needs to have them enabled regardless of the AP Fix this by iterating setting up the data depending on the interface type: - for AP, just set it according to the BSS configuration - for monitor, set it according to HW capabilities - otherwise, particularly for client, iterate all stations and then their links on the interface in question and set according to their capabilities, this handles the AP and TDLS peers. Re-calculate this whenever a TDLS station is marked associated or removed so that it's kept updated, for the AP it's already updated on assoc/disassoc. Fixes: d1e879ec600f ("wifi: iwlwifi: add iwlmld sub-driver") Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260319110722.404713b22177.Ic972b5e557d011a5438f8f97c1e793cc829e2ea9@changeid Link: https://patch.msgid.link/20260324093333.2953495-1-miriam.rachel.korenblit@intel.com Signed-off-by: Sasha Levin commit 2f84d5e9c1c57e4515df4ac88a7216535e062ebf Author: Emmanuel Grumbach Date: Sun Oct 19 11:45:13 2025 +0300 wifi: iwlwifi: disable EHT if the device doesn't allow it [ Upstream commit 7ed47d42943fba8ced505f62d4358f63963bb968 ] We have a few devices that don't allow EHT. Make sure we reflect this towards mac80211 so that we won't try to enable it. Signed-off-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20251019114304.71121f4e5557.I49e2329d4121f9e52d0889156d0c3e8778e27d88@changeid Stable-dep-of: 687a95d204e7 ("wifi: iwlwifi: mld: correctly set wifi generation data") Signed-off-by: Sasha Levin commit 9d713f4f8bb0eacf7d1491604d7ca770e3b9c998 Author: Johannes Berg Date: Mon Sep 15 11:34:27 2025 +0300 wifi: iwlwifi: cfg: add new device names [ Upstream commit 30d47d8fe781469ebd4e38240999767f139effb2 ] Add a couple of device names so that these new devices will be shown correctly. Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250915113137.1cbc0251532f.I6183a6a08a7998e598042a50c7d7a6b82f9fa58e@changeid Stable-dep-of: 687a95d204e7 ("wifi: iwlwifi: mld: correctly set wifi generation data") Signed-off-by: Sasha Levin commit c0b3fa5e0eaecd38e6a9f8f78e86f468fbde719a Author: Emmanuel Grumbach Date: Tue Mar 24 11:33:25 2026 +0200 wifi: iwlwifi: mvm: don't send a 6E related command when not supported [ Upstream commit 323156c3541e23da7e582008a7ac30cd51b60acd ] MCC_ALLOWED_AP_TYPE_CMD is related to 6E support. Do not send it if the device doesn't support 6E. Apparently, the firmware is mistakenly advertising support for this command even on AX201 which does not support 6E and then the firmware crashes. Fixes: 0d2fc8821a7d ("wifi: iwlwifi: nvm: parse the VLP/AFC bit from regulatory") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220804 Signed-off-by: Emmanuel Grumbach Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260324113316.e171f0163f2a.I0c444d1f82d1773054e7ffc391ad49697d58f44e@changeid Signed-off-by: Sasha Levin commit 624af5c3baa2d790939d7f813e0ccd6a3b2d5d20 Author: Pagadala Yesu Anjaneyulu Date: Tue Mar 24 11:33:24 2026 +0200 wifi: iwlwifi: mld: Fix MLO scan timing [ Upstream commit ec66ec6a5a8f53e7c70085749e8d68f4431c630f ] Calculate MLO scan start time based on actual scan start notification from firmware instead of recording time when scan command is sent. Currently, MLO scan start time was captured immediately after sending the scan command to firmware. However, the actual scan start time may differ due to the FW being busy with a previous scan. In that case, the link selection code will think that the MLO scan is too old, and will warn. To fix it, Implement start scan notification handling to capture the precise moment when firmware begins the scan operation. Fixes: 9324731b9985 ("wifi: iwlwifi: mld: avoid selecting bad links") Signed-off-by: Pagadala Yesu Anjaneyulu Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260324113316.4c56b8bac533.I6e656d8cc30bb82c96aabadedd62bd67f4c46bf9@changeid Signed-off-by: Sasha Levin commit ee555d539975ed658ed074157b93b28e32effc21 Author: Johannes Berg Date: Mon Sep 15 11:34:29 2025 +0300 wifi: iwlwifi: fix remaining kernel-doc warnings [ Upstream commit 58a4ebe3168813a04bef08f7858a63b199e866e1 ] Fix the remaining kernel-doc warnings across the driver. Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250915113137.f94b6d4ef142.I91007eed4cf37125ca7a012f2021615b4fa9eb66@changeid Stable-dep-of: ec66ec6a5a8f ("wifi: iwlwifi: mld: Fix MLO scan timing") Signed-off-by: Sasha Levin commit fdbc00b8b2eecd84ddcb879677c2f0d3bcae66aa Author: Frank Li Date: Mon Mar 2 16:59:55 2026 -0500 dt-bindings: auxdisplay: ht16k33: Use unevaluatedProperties to fix common property warning [ Upstream commit 398c0c8bbc8f5a9d2f43863275a427a9d3720b6f ] Change additionalProperties to unevaluatedProperties because it refs to /schemas/input/matrix-keymap.yaml. Fix below CHECK_DTBS warnings: arch/arm/boot/dts/nxp/imx/imx6dl-victgo.dtb: keypad@70 (holtek,ht16k33): 'keypad,num-columns', 'keypad,num-rows' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/auxdisplay/holtek,ht16k33.yaml# Fixes: f12b457c6b25c ("dt-bindings: auxdisplay: ht16k33: Convert to json-schema") Acked-by: Rob Herring (Arm) Signed-off-by: Frank Li Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit 4d47b812f92506ecbcc28e20dfe9dbc109a58fe6 Author: Praveen Talari Date: Fri Mar 13 21:49:01 2026 +0530 spi: geni-qcom: Check DMA interrupts early in ISR [ Upstream commit 8c89a077ca796a2fe248c584e9d7e66cff0388c8 ] The current interrupt handler only checks the GENI main IRQ status (m_irq) before deciding to return IRQ_NONE. This can lead to spurious IRQ_NONE returns when DMA interrupts are pending but m_irq is zero. Move the DMA TX/RX status register reads to the beginning of the ISR, right after reading m_irq. Update the early return condition to check all three status registers (m_irq, dma_tx_status, dma_rx_status) before returning IRQ_NONE. Signed-off-by: Praveen Talari Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260313-spi-geni-qcom-fix-dma-irq-handling-v1-1-0bd122589e02@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f4e35576da4398687e5d9b4c6a63a037f04bd2df Author: Paulo Alcantara Date: Wed Mar 18 21:43:51 2026 -0300 smb: client: fix generic/694 due to wrong ->i_blocks [ Upstream commit 23b5df09c27aec13962b30d32a4167ebdd043f8e ] When updating ->i_size, make sure to always update ->i_blocks as well until we query new allocation size from the server. generic/694 was failing because smb3_simple_falloc() was missing the update of ->i_blocks after calling cifs_setsize(). So, fix this by updating ->i_blocks directly in cifs_setsize(), so all places that call it doesn't need to worry about updating ->i_blocks later. Reported-by: Shyam Prasad N Closes: https://lore.kernel.org/r/CANT5p=rqgRwaADB=b_PhJkqXjtfq3SFv41SSTXSVEHnuh871pA@mail.gmail.com Signed-off-by: Paulo Alcantara (Red Hat) Cc: David Howells Cc: linux-cifs@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 850de3d87f4720b71ccdcd44f4aa57e46b53a3f3 Author: ZhengYuan Huang Date: Thu Mar 12 08:14:43 2026 +0800 btrfs: reject root items with drop_progress and zero drop_level [ Upstream commit b17b79ff896305fd74980a5f72afec370ee88ca4 ] [BUG] When recovering relocation at mount time, merge_reloc_root() and btrfs_drop_snapshot() both use BUG_ON(level == 0) to guard against an impossible state: a non-zero drop_progress combined with a zero drop_level in a root_item, which can be triggered: ------------[ cut here ]------------ kernel BUG at fs/btrfs/relocation.c:1545! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 283 ... Tainted: 6.18.0+ #16 PREEMPT(voluntary) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Ubuntu 24.04 PC v2, BIOS 1.16.3-debian-1.16.3-2 RIP: 0010:merge_reloc_root+0x1266/0x1650 fs/btrfs/relocation.c:1545 Code: ffff0000 00004589 d7e9acfa ffffe8a1 79bafebe 02000000 Call Trace: merge_reloc_roots+0x295/0x890 fs/btrfs/relocation.c:1861 btrfs_recover_relocation+0xd6e/0x11d0 fs/btrfs/relocation.c:4195 btrfs_start_pre_rw_mount+0xa4d/0x1810 fs/btrfs/disk-io.c:3130 open_ctree+0x5824/0x5fe0 fs/btrfs/disk-io.c:3640 btrfs_fill_super fs/btrfs/super.c:987 [inline] btrfs_get_tree_super fs/btrfs/super.c:1951 [inline] btrfs_get_tree_subvol fs/btrfs/super.c:2094 [inline] btrfs_get_tree+0x111c/0x2190 fs/btrfs/super.c:2128 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 ... RIP: 0033:0x7f969c9a8fde Code: 0f1f4000 48c7c2b0 fffffff7 d8648902 b8ffffff ffc3660f ---[ end trace 0000000000000000 ]--- The bug is reproducible on 7.0.0-rc2-next-20260310 with our dynamic metadata fuzzing tool that corrupts btrfs metadata at runtime. [CAUSE] A non-zero drop_progress.objectid means an interrupted btrfs_drop_snapshot() left a resume point on disk, and in that case drop_level must be greater than 0 because the checkpoint is only saved at internal node levels. Although this invariant is enforced when the kernel writes the root item, it is not validated when the root item is read back from disk. That allows on-disk corruption to provide an invalid state with drop_progress.objectid != 0 and drop_level == 0. When relocation recovery later processes such a root item, merge_reloc_root() reads drop_level and hits BUG_ON(level == 0). The same invalid metadata can also trigger the corresponding BUG_ON() in btrfs_drop_snapshot(). [FIX] Fix this by validating the root_item invariant in tree-checker when reading root items from disk: if drop_progress.objectid is non-zero, drop_level must also be non-zero. Reject such malformed metadata with -EUCLEAN before it reaches merge_reloc_root() or btrfs_drop_snapshot() and triggers the BUG_ON. After the fix, the same corruption is correctly rejected by tree-checker and the BUG_ON is no longer triggered. Reviewed-by: Qu Wenruo Signed-off-by: ZhengYuan Huang Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 86d7c80e1cfff3e92269feef1e50ea0d73104be7 Author: Mikko Perttunen Date: Tue Mar 3 13:32:11 2026 +0900 i2c: tegra: Don't mark devices with pins as IRQ safe [ Upstream commit ec69c9e88315c4be70c283f18c2ff130da6320b5 ] I2C devices with associated pinctrl states (DPAUX I2C controllers) will change pinctrl state during runtime PM. This requires taking a mutex, so these devices cannot be marked as IRQ safe. Add PINCTRL as dependency to avoid build errors. Signed-off-by: Mikko Perttunen Reported-by: Russell King Link: https://lore.kernel.org/all/E1vsNBv-00000009nfA-27ZK@rmk-PC.armlinux.org.uk/ Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit cf930a651eef6f8d915bf0ccd60c2045974f870c Author: Filipe Manana Date: Fri Feb 13 16:08:53 2026 +0000 btrfs: reserve enough transaction items for qgroup ioctls [ Upstream commit f9a4e3015db1aeafbef407650eb8555445ca943e ] Currently our qgroup ioctls don't reserve any space, they just do a transaction join, which does not reserve any space, neither for the quota tree updates nor for the delayed refs generated when updating the quota tree. The quota root uses the global block reserve, which is fine most of the time since we don't expect a lot of updates to the quota root, or to be too close to -ENOSPC such that other critical metadata updates need to resort to the global reserve. However this is not optimal, as not reserving proper space may result in a transaction abort due to not reserving space for delayed refs and then abusing the use of the global block reserve. For example, the following reproducer (which is unlikely to model any real world use case, but just to illustrate the problem), triggers such a transaction abort due to -ENOSPC when running delayed refs: $ cat test.sh #!/bin/bash DEV=/dev/nullb0 MNT=/mnt/nullb0 umount $DEV &> /dev/null # Limit device to 1G so that it's much faster to reproduce the issue. mkfs.btrfs -f -b 1G $DEV mount -o commit=600 $DEV $MNT fallocate -l 800M $MNT/filler btrfs quota enable $MNT for ((i = 1; i <= 400000; i++)); do btrfs qgroup create 1/$i $MNT done umount $MNT When running this, we can see in dmesg/syslog that a transaction abort happened: [436.490] BTRFS error (device nullb0): failed to run delayed ref for logical 30408704 num_bytes 16384 type 176 action 1 ref_mod 1: -28 [436.493] ------------[ cut here ]------------ [436.494] BTRFS: Transaction aborted (error -28) [436.495] WARNING: fs/btrfs/extent-tree.c:2247 at btrfs_run_delayed_refs+0xd9/0x110 [btrfs], CPU#4: umount/2495372 [436.497] Modules linked in: btrfs loop (...) [436.508] CPU: 4 UID: 0 PID: 2495372 Comm: umount Tainted: G W 6.19.0-rc8-btrfs-next-225+ #1 PREEMPT(full) [436.510] Tainted: [W]=WARN [436.511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [436.513] RIP: 0010:btrfs_run_delayed_refs+0xdf/0x110 [btrfs] [436.514] Code: 0f 82 ea (...) [436.518] RSP: 0018:ffffd511850b7d78 EFLAGS: 00010292 [436.519] RAX: 00000000ffffffe4 RBX: ffff8f120dad37e0 RCX: 0000000002040001 [436.520] RDX: 0000000000000002 RSI: 00000000ffffffe4 RDI: ffffffffc090fd80 [436.522] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffffc04d1867 [436.523] R10: ffff8f18dc1fffa8 R11: 0000000000000003 R12: ffff8f173aa89400 [436.524] R13: 0000000000000000 R14: ffff8f173aa89400 R15: 0000000000000000 [436.526] FS: 00007fe59045d840(0000) GS:ffff8f192e22e000(0000) knlGS:0000000000000000 [436.527] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [436.528] CR2: 00007fe5905ff2b0 CR3: 000000060710a002 CR4: 0000000000370ef0 [436.530] Call Trace: [436.530] [436.530] btrfs_commit_transaction+0x73/0xc00 [btrfs] [436.531] ? btrfs_attach_transaction_barrier+0x1e/0x70 [btrfs] [436.532] sync_filesystem+0x7a/0x90 [436.533] generic_shutdown_super+0x28/0x180 [436.533] kill_anon_super+0x12/0x40 [436.534] btrfs_kill_super+0x12/0x20 [btrfs] [436.534] deactivate_locked_super+0x2f/0xb0 [436.534] cleanup_mnt+0xea/0x180 [436.535] task_work_run+0x58/0xa0 [436.535] exit_to_user_mode_loop+0xed/0x480 [436.536] ? __x64_sys_umount+0x68/0x80 [436.536] do_syscall_64+0x2a5/0xf20 [436.537] entry_SYSCALL_64_after_hwframe+0x76/0x7e [436.537] RIP: 0033:0x7fe5906b6217 [436.538] Code: 0d 00 f7 (...) [436.540] RSP: 002b:00007ffcd87a61f8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 [436.541] RAX: 0000000000000000 RBX: 00005618b9ecadc8 RCX: 00007fe5906b6217 [436.541] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00005618b9ecb100 [436.542] RBP: 0000000000000000 R08: 00007ffcd87a4fe0 R09: 00000000ffffffff [436.544] R10: 0000000000000103 R11: 0000000000000246 R12: 00007fe59081626c [436.544] R13: 00005618b9ecb100 R14: 0000000000000000 R15: 00005618b9ecacc0 [436.545] [436.545] ---[ end trace 0000000000000000 ]--- Fix this by changing the qgroup ioctls to use start transaction instead of joining so that proper space is reserved for the delayed refs generated for the updates to the quota root. This way we don't get any transaction abort. Reviewed-by: Boris Burkov Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 7f66fdbc077faed3b52519228d21d81979e92249 Author: Lee Jones Date: Fri Feb 27 16:30:25 2026 +0000 HID: multitouch: Check to ensure report responses match the request [ Upstream commit e716edafedad4952fe3a4a273d2e039a84e8681a ] It is possible for a malicious (or clumsy) device to respond to a specific report's feature request using a completely different report ID. This can cause confusion in the HID core resulting in nasty side-effects such as OOB writes. Add a check to ensure that the report ID in the response, matches the one that was requested. If it doesn't, omit reporting the raw event and return early. Signed-off-by: Lee Jones Signed-off-by: Benjamin Tissoires Signed-off-by: Sasha Levin commit 8f71034649738fdeb6859b8d6cddf132024fac06 Author: Lee Jones Date: Mon Mar 9 14:59:29 2026 +0000 HID: core: Mitigate potential OOB by removing bogus memset() [ Upstream commit 0a3fe972a7cb1404f693d6f1711f32bc1d244b1c ] The memset() in hid_report_raw_event() has the good intention of clearing out bogus data by zeroing the area from the end of the incoming data string to the assumed end of the buffer. However, as we have previously seen, doing so can easily result in OOB reads and writes in the subsequent thread of execution. The current suggestion from one of the HID maintainers is to remove the memset() and simply return if the incoming event buffer size is not large enough to fill the associated report. Suggested-by Benjamin Tissoires Signed-off-by: Lee Jones [bentiss: changed the return value] Signed-off-by: Benjamin Tissoires Signed-off-by: Sasha Levin commit b846fb0a73e99174f08238e083e284c0463a2102 Author: Lee Jones Date: Fri Feb 27 10:09:38 2026 +0000 HID: logitech-hidpp: Prevent use-after-free on force feedback initialisation failure [ Upstream commit f7a4c78bfeb320299c1b641500fe7761eadbd101 ] Presently, if the force feedback initialisation fails when probing the Logitech G920 Driving Force Racing Wheel for Xbox One, an error number will be returned and propagated before the userspace infrastructure (sysfs and /dev/input) has been torn down. If userspace ignores the errors and continues to use its references to these dangling entities, a UAF will promptly follow. We have 2 options; continue to return the error, but ensure that all of the infrastructure is torn down accordingly or continue to treat this condition as a warning by emitting the message but returning success. It is thought that the original author's intention was to emit the warning but keep the device functional, less the force feedback feature, so let's go with that. Signed-off-by: Lee Jones Reviewed-by: Günther Noack Signed-off-by: Benjamin Tissoires Signed-off-by: Sasha Levin commit 34b12ab75ae25cd001ebed2ae007f6a893ed89de Author: Josh Poimboeuf Date: Mon Mar 9 09:03:05 2026 -0700 objtool: Fix Clang jump table detection [ Upstream commit 4e5019216402ad0b4a84cff457b662d26803f103 ] With Clang, there can be a conditional forward jump between the load of the jump table address and the indirect branch. Fixes the following warning: vmlinux.o: warning: objtool: ___bpf_prog_run+0x1c5: sibling call from callable instruction with modified stack frame Reported-by: Arnd Bergmann Closes: https://lore.kernel.org/a426d669-58bb-4be1-9eaa-6f3d83109e2d@app.fastmail.com Link: https://patch.msgid.link/7d8600caed08901b6679767488acd639f6df9688.1773071992.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit 7e0576dcf245d63de7d2b1c215f1b76d5714fe19 Author: Paul SAGE Date: Sun Mar 15 03:24:30 2026 +0530 tg3: replace placeholder MAC address with device property [ Upstream commit e4c00ba7274b613e3ab19e27eb009f0ec2e28379 ] On some systems (e.g. iMac 20,1 with BCM57766), the tg3 driver reads a default placeholder mac address (00:10:18:00:00:00) from the mailbox. The correct value on those systems are stored in the 'local-mac-address' property. This patch, detect the default value and tries to retrieve the correct address from the device_get_mac_address function instead. The patch has been tested on two different systems: - iMac 20,1 (BCM57766) model which use the local-mac-address property - iMac 13,2 (BCM57766) model which can use the mailbox, NVRAM or MAC control registers Tested-by: Rishon Jonathan R Co-developed-by: Vincent MORVAN Signed-off-by: Vincent MORVAN Signed-off-by: Paul SAGE Signed-off-by: Atharva Tiwari Reviewed-by: Michael Chan Link: https://patch.msgid.link/20260314215432.3589-1-atharvatiwarilinuxdev@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8b3484011a83edcc610cc82f2fb09ea14125fa04 Author: Johannes Thumshirn Date: Tue Mar 3 11:53:46 2026 +0100 btrfs: don't take device_list_mutex when querying zone info [ Upstream commit 77603ab10429fe713a03345553ca8dbbfb1d91c6 ] Shin'ichiro reported sporadic hangs when running generic/013 in our CI system. When enabling lockdep, there is a lockdep splat when calling btrfs_get_dev_zone_info_all_devices() in the mount path that can be triggered by i.e. generic/013: ====================================================== WARNING: possible circular locking dependency detected 7.0.0-rc1+ #355 Not tainted ------------------------------------------------------ mount/1043 is trying to acquire lock: ffff8881020b5470 (&vblk->vdev_mutex){+.+.}-{4:4}, at: virtblk_report_zones+0xda/0x430 but task is already holding lock: ffff888102a738e0 (&fs_devs->device_list_mutex){+.+.}-{4:4}, at: btrfs_get_dev_zone_info_all_devices+0x45/0x90 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 (&fs_devs->device_list_mutex){+.+.}-{4:4}: __mutex_lock+0xa3/0x1360 btrfs_create_pending_block_groups+0x1f4/0x9d0 __btrfs_end_transaction+0x3e/0x2e0 btrfs_zoned_reserve_data_reloc_bg+0x2f8/0x390 open_ctree+0x1934/0x23db btrfs_get_tree.cold+0x105/0x26c vfs_get_tree+0x28/0xb0 __do_sys_fsconfig+0x324/0x680 do_syscall_64+0x92/0x4f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #3 (btrfs_trans_num_extwriters){++++}-{0:0}: join_transaction+0xc2/0x5c0 start_transaction+0x17c/0xbc0 btrfs_zoned_reserve_data_reloc_bg+0x2b4/0x390 open_ctree+0x1934/0x23db btrfs_get_tree.cold+0x105/0x26c vfs_get_tree+0x28/0xb0 __do_sys_fsconfig+0x324/0x680 do_syscall_64+0x92/0x4f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #2 (btrfs_trans_num_writers){++++}-{0:0}: lock_release+0x163/0x4b0 __btrfs_end_transaction+0x1c7/0x2e0 btrfs_dirty_inode+0x6f/0xd0 touch_atime+0xe5/0x2c0 btrfs_file_mmap_prepare+0x65/0x90 __mmap_region+0x4b9/0xf00 mmap_region+0xf7/0x120 do_mmap+0x43d/0x610 vm_mmap_pgoff+0xd6/0x190 ksys_mmap_pgoff+0x7e/0xc0 do_syscall_64+0x92/0x4f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&mm->mmap_lock){++++}-{4:4}: __might_fault+0x68/0xa0 _copy_to_user+0x22/0x70 blkdev_copy_zone_to_user+0x22/0x40 virtblk_report_zones+0x282/0x430 blkdev_report_zones_ioctl+0xfd/0x130 blkdev_ioctl+0x20f/0x2c0 __x64_sys_ioctl+0x86/0xd0 do_syscall_64+0x92/0x4f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (&vblk->vdev_mutex){+.+.}-{4:4}: __lock_acquire+0x1522/0x2680 lock_acquire+0xd5/0x2f0 __mutex_lock+0xa3/0x1360 virtblk_report_zones+0xda/0x430 blkdev_report_zones_cached+0x162/0x190 btrfs_get_dev_zones+0xdc/0x2e0 btrfs_get_dev_zone_info+0x219/0xe80 btrfs_get_dev_zone_info_all_devices+0x62/0x90 open_ctree+0x1200/0x23db btrfs_get_tree.cold+0x105/0x26c vfs_get_tree+0x28/0xb0 __do_sys_fsconfig+0x324/0x680 do_syscall_64+0x92/0x4f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Chain exists of: &vblk->vdev_mutex --> btrfs_trans_num_extwriters --> &fs_devs->device_list_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&fs_devs->device_list_mutex); lock(btrfs_trans_num_extwriters); lock(&fs_devs->device_list_mutex); lock(&vblk->vdev_mutex); *** DEADLOCK *** 3 locks held by mount/1043: #0: ffff88811063e878 (&fc->uapi_mutex){+.+.}-{4:4}, at: __do_sys_fsconfig+0x2ae/0x680 #1: ffff88810cb9f0e8 (&type->s_umount_key#31/1){+.+.}-{4:4}, at: alloc_super+0xc0/0x3e0 #2: ffff888102a738e0 (&fs_devs->device_list_mutex){+.+.}-{4:4}, at: btrfs_get_dev_zone_info_all_devices+0x45/0x90 stack backtrace: CPU: 2 UID: 0 PID: 1043 Comm: mount Not tainted 7.0.0-rc1+ #355 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-9.fc43 06/10/2025 Call Trace: dump_stack_lvl+0x5b/0x80 print_circular_bug.cold+0x18d/0x1d8 check_noncircular+0x10d/0x130 __lock_acquire+0x1522/0x2680 ? vmap_small_pages_range_noflush+0x3ef/0x820 lock_acquire+0xd5/0x2f0 ? virtblk_report_zones+0xda/0x430 ? lock_is_held_type+0xcd/0x130 __mutex_lock+0xa3/0x1360 ? virtblk_report_zones+0xda/0x430 ? virtblk_report_zones+0xda/0x430 ? __pfx_copy_zone_info_cb+0x10/0x10 ? virtblk_report_zones+0xda/0x430 virtblk_report_zones+0xda/0x430 ? __pfx_copy_zone_info_cb+0x10/0x10 blkdev_report_zones_cached+0x162/0x190 ? __pfx_copy_zone_info_cb+0x10/0x10 btrfs_get_dev_zones+0xdc/0x2e0 btrfs_get_dev_zone_info+0x219/0xe80 btrfs_get_dev_zone_info_all_devices+0x62/0x90 open_ctree+0x1200/0x23db btrfs_get_tree.cold+0x105/0x26c ? rcu_is_watching+0x18/0x50 vfs_get_tree+0x28/0xb0 __do_sys_fsconfig+0x324/0x680 do_syscall_64+0x92/0x4f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f615e27a40e RSP: 002b:00007fff11b18fb8 EFLAGS: 00000246 ORIG_RAX: 00000000000001af RAX: ffffffffffffffda RBX: 000055572e92ab10 RCX: 00007f615e27a40e RDX: 0000000000000000 RSI: 0000000000000006 RDI: 0000000000000003 RBP: 00007fff11b19100 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000055572e92bc40 R14: 00007f615e3faa60 R15: 000055572e92bd08 Don't hold the device_list_mutex while calling into btrfs_get_dev_zone_info() in btrfs_get_dev_zone_info_all_devices() to mitigate the issue. This is safe, as no other thread can touch the device list at the moment of execution. Reported-by: Shin'ichiro Kawasaki Reviewed-by: Damien Le Moal Signed-off-by: Johannes Thumshirn Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit abc10f85a3965ac14b9ed7ad3e67b35604a63aa3 Author: Deepanshu Kartikey Date: Mon Mar 9 21:29:08 2026 +0530 atm: lec: fix use-after-free in sock_def_readable() [ Upstream commit 922814879542c2e397b0e9641fd36b8202a8e555 ] A race condition exists between lec_atm_close() setting priv->lecd to NULL and concurrent access to priv->lecd in send_to_lecd(), lec_handle_bridge(), and lec_atm_send(). When the socket is freed via RCU while another thread is still using it, a use-after-free occurs in sock_def_readable() when accessing the socket's wait queue. The root cause is that lec_atm_close() clears priv->lecd without any synchronization, while callers dereference priv->lecd without any protection against concurrent teardown. Fix this by converting priv->lecd to an RCU-protected pointer: - Mark priv->lecd as __rcu in lec.h - Use rcu_assign_pointer() in lec_atm_close() and lecd_attach() for safe pointer assignment - Use rcu_access_pointer() for NULL checks that do not dereference the pointer in lec_start_xmit(), lec_push(), send_to_lecd() and lecd_attach() - Use rcu_read_lock/rcu_dereference/rcu_read_unlock in send_to_lecd(), lec_handle_bridge() and lec_atm_send() to safely access lecd - Use rcu_assign_pointer() followed by synchronize_rcu() in lec_atm_close() to ensure all readers have completed before proceeding. This is safe since lec_atm_close() is called from vcc_release() which holds lock_sock(), a sleeping lock. - Remove the manual sk_receive_queue drain from lec_atm_close() since vcc_destroy_socket() already drains it after lec_atm_close() returns. v2: Switch from spinlock + sock_hold/put approach to RCU to properly fix the race. The v1 spinlock approach had two issues pointed out by Eric Dumazet: 1. priv->lecd was still accessed directly after releasing the lock instead of using a local copy. 2. The spinlock did not prevent packets being queued after lec_atm_close() drains sk_receive_queue since timer and workqueue paths bypass netif_stop_queue(). Note: Syzbot patch testing was attempted but the test VM terminated unexpectedly with "Connection to localhost closed by remote host", likely due to a QEMU AHCI emulation issue unrelated to this fix. Compile testing with "make W=1 net/atm/lec.o" passes cleanly. Reported-by: syzbot+f50072212ab792c86925@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f50072212ab792c86925 Link: https://lore.kernel.org/all/20260309093614.502094-1-kartikey406@gmail.com/T/ [v1] Signed-off-by: Deepanshu Kartikey Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260309155908.508768-1-kartikey406@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c8dc23c97680eebefde06da5858aaef1b37cf75d Author: Benoît Sevens Date: Tue Mar 3 13:58:28 2026 +0000 HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq [ Upstream commit 2f1763f62909ccb6386ac50350fa0abbf5bb16a9 ] The wacom_intuos_bt_irq() function processes Bluetooth HID reports without sufficient bounds checking. A maliciously crafted short report can trigger an out-of-bounds read when copying data into the wacom structure. Specifically, report 0x03 requires at least 22 bytes to safely read the processed data and battery status, while report 0x04 (which falls through to 0x03) requires 32 bytes. Add explicit length checks for these report IDs and log a warning if a short report is received. Signed-off-by: Benoît Sevens Reviewed-by: Jason Gerecke Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit be81f17151fcb8546a95f35ca8f4231b065985de Author: Deepanshu Kartikey Date: Fri Mar 13 14:54:17 2026 +0530 wifi: mac80211: check tdls flag in ieee80211_tdls_oper [ Upstream commit 7d73872d949c488a1d7c308031d6a9d89b5e0a8b ] When NL80211_TDLS_ENABLE_LINK is called, the code only checks if the station exists but not whether it is actually a TDLS station. This allows the operation to proceed for non-TDLS stations, causing unintended side effects like modifying channel context and HT protection before failing. Add a check for sta->sta.tdls early in the ENABLE_LINK case, before any side effects occur, to ensure the operation is only allowed for actual TDLS peers. Reported-by: syzbot+56b6a844a4ea74487b7b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=56b6a844a4ea74487b7b Tested-by: syzbot+56b6a844a4ea74487b7b@syzkaller.appspotmail.com Suggested-by: Johannes Berg Signed-off-by: Deepanshu Kartikey Link: https://patch.msgid.link/20260313092417.520807-1-kartikey406@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 6c4e67e6ba25007a14b90e65af4fc21b62ebd331 Author: Adrian Freund Date: Wed Mar 11 20:19:33 2026 +0100 HID: logitech-hidpp: Enable MX Master 4 over bluetooth [ Upstream commit 70031e70ca15ede6a39db4d978e53a6cc720d454 ] The Logitech MX Master 4 can be connected over bluetooth or through a Logitech Bolt receiver. This change adds support for non-standard HID features, such as high resolution scrolling when the mouse is connected over bluetooth. Because no Logitech Bolt receiver driver exists yet those features won't be available when the mouse is connected through the receiver. Signed-off-by: Adrian Freund Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 1c41248cef835ca5ca10ec54836d319b4b4ff5a7 Author: Pepper Gray Date: Tue Mar 10 14:44:28 2026 +0100 arm64/scs: Fix handling of advance_loc4 [ Upstream commit d499e9627d70b1269020d59b95ed3e18bee6b8cd ] DW_CFA_advance_loc4 is defined but no handler is implemented. Its CFA opcode defaults to EDYNSCS_INVALID_CFA_OPCODE triggering an error which wrongfully prevents modules from loading. Link: https://bugs.gentoo.org/971060 Signed-off-by: Pepper Gray Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit eb894ca03fcda940d9be513160b61cb5e978d323 Author: Alexandre Frade Date: Thu Apr 2 18:17:44 2026 +0000 Linux 6.18.21-xanmod1 Signed-off-by: Alexandre Frade commit ecb9a3fa0c2b7b98008b3c4fad1b17c2bb902ab6 Merge: 40410158d77d 44c944a67997 Author: Alexandre Frade Date: Thu Apr 2 18:17:08 2026 +0000 Merge tag 'v6.18.21' into 6.18 This is the 6.18.21 stable release commit 44c944a679974c2d18ee9b87070456d34193f3d4 Author: Greg Kroah-Hartman Date: Thu Apr 2 13:23:33 2026 +0200 Linux 6.18.21 Link: https://lore.kernel.org/r/20260331161753.468533260@linuxfoundation.org Tested-by: Dileep Malepu Tested-by: Florian Fainelli Tested-by: Peter Schneider Tested-by: Wentao Guan Tested-by: Shung-Hsi Yu Tested-by: Brett A C Sheffield Tested-by: Jon Hunter Tested-by: Ron Economos Tested-by: Barry K. Nathan Tested-by: Shuah Khan Tested-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit e75a5c054d493bbe1dae5461add62bd4913ed2c6 Author: Luiz Augusto von Dentz Date: Tue Mar 17 11:54:01 2026 -0400 Bluetooth: L2CAP: Fix regressions caused by reusing ident commit 761fb8ec8778f0caf2bba5a41e3cff1ea86974f3 upstream. This attempt to fix regressions caused by reusing ident which apparently is not handled well on certain stacks causing the stack to not respond to requests, so instead of simple returning the first unallocated id this stores the last used tx_ident and then attempt to use the next until all available ids are exausted and then cycle starting over to 1. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221120 Link: https://bugzilla.kernel.org/show_bug.cgi?id=221177 Fixes: 6c3ea155e5ee ("Bluetooth: L2CAP: Fix not tracking outstanding TX ident") Signed-off-by: Luiz Augusto von Dentz Tested-by: Christian Eggers Signed-off-by: Greg Kroah-Hartman commit 853f70c67d1b37e368fdcb3e328c4b8c04f53ac0 Author: Hao-Yu Yang Date: Fri Mar 13 20:47:56 2026 +0800 futex: Fix UaF between futex_key_to_node_opt() and vma_replace_policy() [ Upstream commit 190a8c48ff623c3d67cb295b4536a660db2012aa ] During futex_key_to_node_opt() execution, vma->vm_policy is read under speculative mmap lock and RCU. Concurrently, mbind() may call vma_replace_policy() which frees the old mempolicy immediately via kmem_cache_free(). This creates a race where __futex_key_to_node() dereferences a freed mempolicy pointer, causing a use-after-free read of mpol->mode. [ 151.412631] BUG: KASAN: slab-use-after-free in __futex_key_to_node (kernel/futex/core.c:349) [ 151.414046] Read of size 2 at addr ffff888001c49634 by task e/87 [ 151.415969] Call Trace: [ 151.416732] __asan_load2 (mm/kasan/generic.c:271) [ 151.416777] __futex_key_to_node (kernel/futex/core.c:349) [ 151.416822] get_futex_key (kernel/futex/core.c:374 kernel/futex/core.c:386 kernel/futex/core.c:593) Fix by adding rcu to __mpol_put(). Fixes: c042c505210d ("futex: Implement FUTEX2_MPOL") Reported-by: Hao-Yu Yang Suggested-by: Eric Dumazet Signed-off-by: Hao-Yu Yang Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Eric Dumazet Acked-by: David Hildenbrand (Arm) Link: https://patch.msgid.link/20260324174418.GB1850007@noisy.programming.kicks-ass.net Signed-off-by: Sasha Levin commit 18b7d09c2b794c71d4252f3ea2cf84ad12b73d6a Author: Peter Zijlstra Date: Thu Mar 26 13:35:53 2026 +0100 futex: Require sys_futex_requeue() to have identical flags [ Upstream commit 19f94b39058681dec64a10ebeb6f23fe7fc3f77a ] Nicholas reported that his LLM found it was possible to create a UaF when sys_futex_requeue() is used with different flags. The initial motivation for allowing different flags was the variable sized futex, but since that hasn't been merged (yet), simply mandate the flags are identical, as is the case for the old style sys_futex() requeue operations. Fixes: 0f4b5f972216 ("futex: Add sys_futex_requeue()") Reported-by: Nicholas Carlini Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Sasha Levin commit a7df913754715184e2c4fb24e0f9622e328308dd Author: Biju Das Date: Mon Mar 23 12:49:14 2026 +0000 irqchip/renesas-rzv2h: Fix error path in rzv2h_icu_probe_common() [ Upstream commit 897cf98926429c8671a9009442883c2f62deae96 ] Replace pm_runtime_put() with pm_runtime_put_sync() when irq_domain_create_hierarchy() fails to ensure the device suspends synchronously before devres cleanup disables runtime PM via pm_runtime_disable(). Fixes: 5ec8cabc3b86 ("irqchip/renesas-rzv2h: Use devm_pm_runtime_enable()") Signed-off-by: Biju Das Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260323124917.41602-1-biju.das.jz@bp.renesas.com Signed-off-by: Sasha Levin commit f0035858dfb2335171b897fe7653fa8e8928cc04 Author: David Howells Date: Wed Mar 25 08:20:17 2026 +0000 netfs: Fix the handling of stream->front by removing it [ Upstream commit 0e764b9d46071668969410ec5429be0e2f38c6d3 ] The netfs_io_stream::front member is meant to point to the subrequest currently being collected on a stream, but it isn't actually used this way by direct write (which mostly ignores it). However, there's a tracepoint which looks at it. Further, stream->front is actually redundant with stream->subrequests.next. Fix the potential problem in the direct code by just removing the member and using stream->subrequests.next instead, thereby also simplifying the code. Fixes: a0b4c7a49137 ("netfs: Fix unbuffered/DIO writes to dispatch subrequests in strict sequence") Reported-by: Paulo Alcantara Signed-off-by: David Howells Link: https://patch.msgid.link/4158599.1774426817@warthog.procyon.org.uk Reviewed-by: Paulo Alcantara (Red Hat) cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit e7ba52b38766936f3e7451f9951e97fd5f6914f8 Author: GuoHan Zhao Date: Wed Mar 25 20:02:46 2026 +0800 xen/privcmd: unregister xenstore notifier on module exit [ Upstream commit cd7e1fef5a1ca1c4fcd232211962ac2395601636 ] Commit 453b8fb68f36 ("xen/privcmd: restrict usage in unprivileged domU") added a xenstore notifier to defer setting the restriction target until Xenstore is ready. XEN_PRIVCMD can be built as a module, but privcmd_exit() leaves that notifier behind. Balance the notifier lifecycle by unregistering it on module exit. This is harmless even if xenstore was already ready at registration time and the notifier was never queued on the chain. Fixes: 453b8fb68f3641fe ("xen/privcmd: restrict usage in unprivileged domU") Signed-off-by: GuoHan Zhao Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: <20260325120246.252899-1-zhaoguohan@kylinos.cn> Signed-off-by: Sasha Levin commit 806d40421a59bf55ddcf8375059825f0057e53ec Author: Filipe Manana Date: Wed Mar 18 16:17:59 2026 +0000 btrfs: fix lost error when running device stats on multiple devices fs [ Upstream commit 1c37d896b12dfd0d4c96e310b0033c6676933917 ] Whenever we get an error updating the device stats item for a device in btrfs_run_dev_stats() we allow the loop to go to the next device, and if updating the stats item for the next device succeeds, we end up losing the error we had from the previous device. Fix this by breaking out of the loop once we get an error and make sure it's returned to the caller. Since we are in the transaction commit path (and in the critical section actually), returning the error will result in a transaction abort. Fixes: 733f4fbbc108 ("Btrfs: read device stats on mount, write modified ones during commit") Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 3c844d01f9874a43004c82970d8da94f9aba8949 Author: Shin'ichiro Kawasaki Date: Sun Mar 1 21:17:04 2026 +0900 btrfs: fix leak of kobject name for sub-group space_info [ Upstream commit a4376d9a5d4c9610e69def3fc0b32c86a7ab7a41 ] When create_space_info_sub_group() allocates elements of space_info->sub_group[], kobject_init_and_add() is called for each element via btrfs_sysfs_add_space_info_type(). However, when check_removing_space_info() frees these elements, it does not call btrfs_sysfs_remove_space_info() on them. As a result, kobject_put() is not called and the associated kobj->name objects are leaked. This memory leak is reproduced by running the blktests test case zbd/009 on kernels built with CONFIG_DEBUG_KMEMLEAK. The kmemleak feature reports the following error: unreferenced object 0xffff888112877d40 (size 16): comm "mount", pid 1244, jiffies 4294996972 hex dump (first 16 bytes): 64 61 74 61 2d 72 65 6c 6f 63 00 c4 c6 a7 cb 7f data-reloc...... backtrace (crc 53ffde4d): __kmalloc_node_track_caller_noprof+0x619/0x870 kstrdup+0x42/0xc0 kobject_set_name_vargs+0x44/0x110 kobject_init_and_add+0xcf/0x150 btrfs_sysfs_add_space_info_type+0xfc/0x210 [btrfs] create_space_info_sub_group.constprop.0+0xfb/0x1b0 [btrfs] create_space_info+0x211/0x320 [btrfs] btrfs_init_space_info+0x15a/0x1b0 [btrfs] open_ctree+0x33c7/0x4a50 [btrfs] btrfs_get_tree.cold+0x9f/0x1ee [btrfs] vfs_get_tree+0x87/0x2f0 vfs_cmd_create+0xbd/0x280 __do_sys_fsconfig+0x3df/0x990 do_syscall_64+0x136/0x1540 entry_SYSCALL_64_after_hwframe+0x76/0x7e To avoid the leak, call btrfs_sysfs_remove_space_info() instead of kfree() for the elements. Fixes: f92ee31e031c ("btrfs: introduce btrfs_space_info sub-group") Link: https://lore.kernel.org/linux-block/b9488881-f18d-4f47-91a5-3c9bf63955a5@wdc.com/ Reviewed-by: Johannes Thumshirn Signed-off-by: Shin'ichiro Kawasaki Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit c1677817b906ef3fa6b778fd630ee633e58e4531 Author: Mark Harmstone Date: Tue Feb 17 17:35:42 2026 +0000 btrfs: fix super block offset in error message in btrfs_validate_super() [ Upstream commit b52fe51f724385b3ed81e37e510a4a33107e8161 ] Fix the superblock offset mismatch error message in btrfs_validate_super(): we changed it so that it considers all the superblocks, but the message still assumes we're only looking at the first one. The change from %u to %llu is because we're changing from a constant to a u64. Fixes: 069ec957c35e ("btrfs: Refactor btrfs_check_super_valid") Reviewed-by: Qu Wenruo Signed-off-by: Mark Harmstone Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 3e5fd8f53b575ff2188f82071da19c977ca56c41 Author: David Howells Date: Wed Mar 18 15:38:58 2026 +0000 netfs: Fix read abandonment during retry [ Upstream commit 7e57523490cd2efb52b1ea97f2e0a74c0fb634cd ] Under certain circumstances, all the remaining subrequests from a read request will get abandoned during retry. The abandonment process expects the 'subreq' variable to be set to the place to start abandonment from, but it doesn't always have a useful value (it will be uninitialised on the first pass through the loop and it may point to a deleted subrequest on later passes). Fix the first jump to "abandon:" to set subreq to the start of the first subrequest expected to need retry (which, in this abandonment case, turned out unexpectedly to no longer have NEED_RETRY set). Also clear the subreq pointer after discarding superfluous retryable subrequests to cause an oops if we do try to access it. Fixes: ee4cdf7ba857 ("netfs: Speed up buffered reading") Signed-off-by: David Howells Link: https://patch.msgid.link/3775287.1773848338@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 Signed-off-by: Sasha Levin commit 0c9256f31003d6d68e771a9999c4c993f55ad8b2 Author: Christian Brauner Date: Tue Mar 17 16:59:45 2026 +0100 selftests/mount_setattr: increase tmpfs size for idmapped mount tests [ Upstream commit c465f5591aa84a6f85d66d152e28b92844a45d4f ] The mount_setattr_idmapped fixture mounts a 2 MB tmpfs at /mnt and then creates a 2 GB sparse ext4 image at /mnt/C/ext4.img. While ftruncate() succeeds (sparse file), mkfs.ext4 needs to write actual metadata blocks (inode tables, journal, bitmaps) which easily exceeds the 2 MB tmpfs limit, causing ENOSPC and failing the fixture setup for all mount_setattr_idmapped tests. This was introduced by commit d37d4720c3e7 ("selftests/mount_settattr: ensure that ext4 filesystem can be created") which increased the image size from 2 MB to 2 GB but didn't adjust the tmpfs size. Bump the tmpfs size to 256 MB which is sufficient for the ext4 metadata. Fixes: d37d4720c3e7 ("selftests/mount_settattr: ensure that ext4 filesystem can be created") Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 285a2602bf37686fc1b51603f3572eb73d406fa0 Author: Tomi Valkeinen Date: Wed Mar 11 07:34:46 2026 +0200 dmaengine: xilinx_dma: Fix reset related timeout with two-channel AXIDMA [ Upstream commit a17ce4bc6f4f9acf77ba416c36791a15602e53aa ] A single AXIDMA controller can have one or two channels. When it has two channels, the reset for both are tied together: resetting one channel resets the other as well. This creates a problem where resetting one channel will reset the registers for both channels, including clearing interrupt enable bits for the other channel, which can then lead to timeouts as the driver is waiting for an interrupt which never comes. The driver currently has a probe-time work around for this: when a channel is created, the driver also resets and enables the interrupts. With two channels the reset for the second channel will clear the interrupt enables for the first one. The work around in the driver is just to manually enable the interrupts again in xilinx_dma_alloc_chan_resources(). This workaround only addresses the probe-time issue. When channels are reset at runtime (e.g., in xilinx_dma_terminate_all() or during error recovery), there's no corresponding mechanism to restore the other channel's interrupt enables. This leads to one channel having its interrupts disabled while the driver expects them to work, causing timeouts and DMA failures. A proper fix is a complicated matter, as we should not reset the other channel when it's operating normally. So, perhaps, there should be some kind of synchronization for a common reset, which is not trivial to implement. To add to the complexity, the driver also supports other DMA types, like VDMA, CDMA and MCDMA, which don't have a shared reset. However, when the two-channel AXIDMA is used in the (assumably) normal use case, providing DMA for a single memory-to-memory device, the common reset is a bit smaller issue: when something bad happens on one channel, or when one channel is terminated, the assumption is that we also want to terminate the other channel. And thus resetting both at the same time is "ok". With that line of thinking we can implement a bit better work around than just the current probe time work around: let's enable the AXIDMA interrupts at xilinx_dma_start_transfer() instead. This ensures interrupts are enabled whenever a transfer starts, regardless of any prior resets that may have cleared them. This approach is also more logical: enable interrupts only when needed for a transfer, rather than at resource allocation time, and, I think, all the other DMA types should also use this model, but I'm reluctant to do such changes as I cannot test them. The reset function still enables interrupts even though it's not needed for AXIDMA anymore, but it's common code for all DMA types (VDMA, CDMA, MCDMA), so leave it unchanged to avoid affecting other variants. Signed-off-by: Tomi Valkeinen Fixes: c0bba3a99f07 ("dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access Engine") Link: https://patch.msgid.link/20260311-xilinx-dma-fix-v2-1-a725abb66e3c@ideasonboard.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit ec48fb2f5936e35d6bca14899d7c0f313fb33444 Author: Marek Vasut Date: Mon Mar 16 23:25:24 2026 +0100 dmaengine: xilinx: xilinx_dma: Fix unmasked residue subtraction [ Upstream commit c7d812e33f3e8ca0fa9eeabf71d1c7bc3acedc09 ] The segment .control and .status fields both contain top bits which are not part of the buffer size, the buffer size is located only in the bottom max_buffer_len bits. To avoid interference from those top bits, mask out the size using max_buffer_len first, and only then subtract the values. Fixes: a575d0b4e663 ("dmaengine: xilinx_dma: Introduce xilinx_dma_get_residue") Signed-off-by: Marek Vasut Link: https://patch.msgid.link/20260316222530.163815-1-marex@nabladev.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit e75f5f76be906c4c40ad4a7487f289baab3a8ee7 Author: Marek Vasut Date: Mon Mar 16 23:18:57 2026 +0100 dmaengine: xilinx: xilinx_dma: Fix residue calculation for cyclic DMA [ Upstream commit f61d145999d61948a23cd436ebbfa4c3b9ab8987 ] The cyclic DMA calculation is currently entirely broken and reports residue only for the first segment. The problem is twofold. First, when the first descriptor finishes, it is moved from active_list to done_list, but it is never returned back into the active_list. The xilinx_dma_tx_status() expects the descriptor to be in the active_list to report any meaningful residue information, which never happens after the first descriptor finishes. Fix this up in xilinx_dma_start_transfer() and if the descriptor is cyclic, lift it from done_list and place it back into active_list list. Second, the segment .status fields of the descriptor remain dirty. Once the DMA did one pass on the descriptor, the .status fields are populated with data by the DMA, but the .status fields are not cleared before reuse during the next cyclic DMA round. The xilinx_dma_get_residue() recognizes that as if the descriptor was complete and had 0 residue, which is bogus. Reinitialize the status field before placing the descriptor back into the active_list. Fixes: c0bba3a99f07 ("dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access Engine") Signed-off-by: Marek Vasut Link: https://patch.msgid.link/20260316221943.160375-1-marex@nabladev.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit e9a6eba5f0c0312d69aac5056babaf0df0781eac Author: Marek Vasut Date: Mon Mar 16 23:16:54 2026 +0100 dmaengine: xilinx: xilinx_dma: Fix dma_device directions [ Upstream commit e9cc95397bb7da13fe8a5b53a2f23cfaf9018ade ] Unlike chan->direction , struct dma_device .directions field is a bitfield. Turn chan->direction into a bitfield to make it compatible with struct dma_device .directions . Fixes: 7e01511443c3 ("dmaengine: xilinx_dma: Set dma_device directions") Signed-off-by: Marek Vasut Link: https://patch.msgid.link/20260316221728.160139-1-marex@nabladev.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 82656e8daf8de00935ae91b91bed43f4d6e0d644 Author: Tuo Li Date: Tue Jan 6 11:24:28 2026 +0800 dmaengine: idxd: fix possible wrong descriptor completion in llist_abort_desc() [ Upstream commit e1c9866173c5f8521f2d0768547a01508cb9ff27 ] At the end of this function, d is the traversal cursor of flist, but the code completes found instead. This can lead to issues such as NULL pointer dereferences, double completion, or descriptor leaks. Fix this by completing d instead of found in the final list_for_each_entry_safe() loop. Fixes: aa8d18becc0c ("dmaengine: idxd: add callback support for iaa crypto") Signed-off-by: Tuo Li Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260106032428.162445-1-islituo@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit a4d1b4ba9754bac3efebd06f583a44a7af52c0ab Author: Deepanshu Kartikey Date: Sat Mar 7 10:09:47 2026 +0530 netfs: Fix NULL pointer dereference in netfs_unbuffered_write() on retry [ Upstream commit e9075e420a1eb3b52c60f3b95893a55e77419ce8 ] When a write subrequest is marked NETFS_SREQ_NEED_RETRY, the retry path in netfs_unbuffered_write() unconditionally calls stream->prepare_write() without checking if it is NULL. Filesystems such as 9P do not set the prepare_write operation, so stream->prepare_write remains NULL. When get_user_pages() fails with -EFAULT and the subrequest is flagged for retry, this results in a NULL pointer dereference at fs/netfs/direct_write.c:189. Fix this by mirroring the pattern already used in write_retry.c: if stream->prepare_write is NULL, skip renegotiation and directly reissue the subrequest via netfs_reissue_write(), which handles iterator reset, IN_PROGRESS flag, stats update and reissue internally. Fixes: a0b4c7a49137 ("netfs: Fix unbuffered/DIO writes to dispatch subrequests in strict sequence") Reported-by: syzbot+7227db0fbac9f348dba0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=7227db0fbac9f348dba0 Signed-off-by: Deepanshu Kartikey Link: https://patch.msgid.link/20260307043947.347092-1-kartikey406@gmail.com Tested-by: syzbot+7227db0fbac9f348dba0@syzkaller.appspotmail.com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 4bc2d72c7695cedf6d4e1a558924903c2b28a78e Author: Deepanshu Kartikey Date: Sat Mar 7 14:30:41 2026 +0530 netfs: Fix kernel BUG in netfs_limit_iter() for ITER_KVEC iterators [ Upstream commit 67e467a11f62ff64ad219dc6aa5459e132c79d14 ] When a process crashes and the kernel writes a core dump to a 9P filesystem, __kernel_write() creates an ITER_KVEC iterator. This iterator reaches netfs_limit_iter() via netfs_unbuffered_write(), which only handles ITER_FOLIOQ, ITER_BVEC and ITER_XARRAY iterator types, hitting the BUG() for any other type. Fix this by adding netfs_limit_kvec() following the same pattern as netfs_limit_bvec(), since both kvec and bvec are simple segment arrays with pointer and length fields. Dispatch it from netfs_limit_iter() when the iterator type is ITER_KVEC. Fixes: cae932d3aee5 ("netfs: Add func to calculate pagecount/size-limited span of an iterator") Reported-by: syzbot+9c058f0d63475adc97fd@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9c058f0d63475adc97fd Tested-by: syzbot+9c058f0d63475adc97fd@syzkaller.appspotmail.com Signed-off-by: Deepanshu Kartikey Link: https://patch.msgid.link/20260307090041.359870-1-kartikey406@gmail.com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit f27197ccfd2ecd2c71f27fd57c6d507e892ad24d Author: Alexander Stein Date: Tue Oct 14 08:13:08 2025 +0200 dmaengine: xilinx: xdma: Fix regmap init error handling [ Upstream commit e0adbf74e2a0455a6bc9628726ba87bcd0b42bf8 ] devm_regmap_init_mmio returns an ERR_PTR() upon error, not NULL. Fix the error check and also fix the error message. Use the error code from ERR_PTR() instead of the wrong value in ret. Fixes: 17ce252266c7 ("dmaengine: xilinx: xdma: Add xilinx xdma driver") Signed-off-by: Alexander Stein Reviewed-by: Frank Li Link: https://patch.msgid.link/20251014061309.283468-1-alexander.stein@ew.tq-group.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit e1d0d0080bab614c391684004dccf40e5710f47f Author: LUO Haowen Date: Wed Mar 4 14:45:09 2026 +0800 dmaengine: dw-edma: Fix multiple times setting of the CYCLE_STATE and CYCLE_BIT bits for HDMA. [ Upstream commit 3f63297ff61a994b99d710dcb6dbde41c4003233 ] Others have submitted this issue (https://lore.kernel.org/dmaengine/ 20240722030405.3385-1-zhengdongxiong@gxmicro.cn/), but it has not been fixed yet. Therefore, more supplementary information is provided here. As mentioned in the "PCS-CCS-CB-TCB" Producer-Consumer Synchronization of "DesignWare Cores PCI Express Controller Databook, version 6.00a": 1. The Consumer CYCLE_STATE (CCS) bit in the register only needs to be initialized once; the value will update automatically to be ~CYCLE_BIT (CB) in the next chunk. 2. The Consumer CYCLE_BIT bit in the register is loaded from the LL element and tested against CCS. When CB = CCS, the data transfer is executed. Otherwise not. The current logic sets customer (HDMA) CS and CB bits to 1 in each chunk while setting the producer (software) CB of odd chunks to 0 and even chunks to 1 in the linked list. This is leading to a mismatch between the producer CB and consumer CS bits. This issue can be reproduced by setting the transmission data size to exceed one chunk. By the way, in the EDMA using the same "PCS-CCS-CB-TCB" mechanism, the CS bit is only initialized once and this issue was not found. Refer to drivers/dma/dw-edma/dw-edma-v0-core.c:dw_edma_v0_core_start. So fix this issue by initializing the CYCLE_STATE and CYCLE_BIT bits only once. Fixes: e74c39573d35 ("dmaengine: dw-edma: Add support for native HDMA") Signed-off-by: LUO Haowen Reviewed-by: Frank Li Link: https://patch.msgid.link/tencent_CB11AA9F3920C1911AF7477A9BD8EFE0AD05@qq.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit eb048d11fa2a71bf1f23463d7cd1b61d6aafdcb5 Author: Felix Gu Date: Thu Feb 12 18:39:19 2026 +0800 phy: ti: j721e-wiz: Fix device node reference leak in wiz_get_lane_phy_types() [ Upstream commit 584b457f4166293bdfa50f930228e9fb91a38392 ] The serdes device_node is obtained using of_get_child_by_name(), which increments the reference count. However, it is never put, leading to a reference leak. Add the missing of_node_put() calls to ensure the reference count is properly balanced. Fixes: 7ae14cf581f2 ("phy: ti: j721e-wiz: Implement DisplayPort mode to the wiz driver") Suggested-by: Vladimir Oltean Signed-off-by: Felix Gu Reviewed-by: Vladimir Oltean Link: https://patch.msgid.link/20260212-wiz-v2-1-6e8bd4cc7a4a@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit facd0012708e942fc12890708738aebde497564e Author: Vinicius Costa Gomes Date: Wed Jan 21 10:34:36 2026 -0800 dmaengine: idxd: Fix leaking event log memory [ Upstream commit ee66bc29578391c9b48523dc9119af67bd5c7c0f ] During the device remove process, the device is reset, causing the configuration registers to go back to their default state, which is zero. As the driver is checking if the event log support was enabled before deallocating, it will fail if a reset happened before. Do not check if the support was enabled, the check for 'idxd->evl' being valid (only allocated if the HW capability is available) is enough. Fixes: 244da66cda35 ("dmaengine: idxd: setup event log configuration") Reviewed-by: Dave Jiang Signed-off-by: Vinicius Costa Gomes Link: https://patch.msgid.link/20260121-idxd-fix-flr-on-kernel-queues-v3-v3-10-7ed70658a9d1@intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit a18e809e22d35910b7630bc381f7a64f2250dc08 Author: Vinicius Costa Gomes Date: Wed Jan 21 10:34:35 2026 -0800 dmaengine: idxd: Fix freeing the allocated ida too late [ Upstream commit c311f5e9248471a950f0a524c2fd736414d98900 ] It can happen that when the cdev .release() is called, the driver already called ida_destroy(). Move ida_free() to the _del() path. We see with DEBUG_KOBJECT_RELEASE enabled and forcing an early PCI unbind. Fixes: 04922b7445a1 ("dmaengine: idxd: fix cdev setup and free device lifetime issues") Reviewed-by: Dave Jiang Signed-off-by: Vinicius Costa Gomes Link: https://patch.msgid.link/20260121-idxd-fix-flr-on-kernel-queues-v3-v3-9-7ed70658a9d1@intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit a9e7815d38629bcf59d3005001f1f315424a58de Author: Vinicius Costa Gomes Date: Wed Jan 21 10:34:34 2026 -0800 dmaengine: idxd: Fix memory leak when a wq is reset [ Upstream commit d9cfb5193a047a92a4d3c0e91ea4cc87c8f7c478 ] idxd_wq_disable_cleanup() which is called from the reset path for a workqueue, sets the wq type to NONE, which for other parts of the driver mean that the wq is empty (all its resources were released). Only set the wq type to NONE after its resources are released. Fixes: da32b28c95a7 ("dmaengine: idxd: cleanup workqueue config after disabling") Reviewed-by: Dave Jiang Signed-off-by: Vinicius Costa Gomes Link: https://patch.msgid.link/20260121-idxd-fix-flr-on-kernel-queues-v3-v3-8-7ed70658a9d1@intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 958e96533ddbd1edd127feb7624a7eed0cc379dc Author: Vinicius Costa Gomes Date: Wed Jan 21 10:34:33 2026 -0800 dmaengine: idxd: Fix not releasing workqueue on .release() [ Upstream commit 3d33de353b1ff9023d5ec73b9becf80ea87af695 ] The workqueue associated with an DSA/IAA device is not released when the object is freed. Fixes: 47c16ac27d4c ("dmaengine: idxd: fix idxd conf_dev 'struct device' lifetime") Reviewed-by: Dave Jiang Signed-off-by: Vinicius Costa Gomes Link: https://patch.msgid.link/20260121-idxd-fix-flr-on-kernel-queues-v3-v3-7-7ed70658a9d1@intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 504c0e6751001ac46917c73e703f2b1b92cfc026 Author: Vinicius Costa Gomes Date: Wed Jan 21 10:34:29 2026 -0800 dmaengine: idxd: Fix possible invalid memory access after FLR [ Upstream commit d6077df7b75d26e4edf98983836c05d00ebabd8d ] In the case that the first Function Level Reset (FLR) concludes correctly, but in the second FLR the scratch area for the saved configuration cannot be allocated, it's possible for a invalid memory access to happen. Always set the deallocated scratch area to NULL after FLR completes. Fixes: 98d187a98903 ("dmaengine: idxd: Enable Function Level Reset (FLR) for halt") Reviewed-by: Dave Jiang Signed-off-by: Vinicius Costa Gomes Link: https://patch.msgid.link/20260121-idxd-fix-flr-on-kernel-queues-v3-v3-3-7ed70658a9d1@intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit aa0ffc6d3990ec35976308a068dc23178037e564 Author: Vinicius Costa Gomes Date: Wed Jan 21 10:34:28 2026 -0800 dmaengine: idxd: Fix crash when the event log is disabled [ Upstream commit 52d2edea0d63c935e82631e4b9e4a94eccf97b5b ] If reporting errors to the event log is not supported by the hardware, and an error that causes Function Level Reset (FLR) is received, the driver will try to restore the event log even if it was not allocated. Also, only try to free the event log if it was properly allocated. Fixes: 6078a315aec1 ("dmaengine: idxd: Add idxd_device_config_save() and idxd_device_config_restore() helpers") Reviewed-by: Dave Jiang Signed-off-by: Vinicius Costa Gomes Link: https://patch.msgid.link/20260121-idxd-fix-flr-on-kernel-queues-v3-v3-2-7ed70658a9d1@intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 40b3f4700e5535fbe74738cebb9379a40ec66bed Author: Lorenzo Stoakes (Oracle) Date: Fri Mar 27 17:31:04 2026 +0000 mm/mseal: update VMA end correctly on merge commit 2697dd8ae721db4f6a53d4f4cbd438212a80f8dc upstream. Previously we stored the end of the current VMA in curr_end, and then upon iterating to the next VMA updated curr_start to curr_end to advance to the next VMA. However, this doesn't take into account the fact that a VMA might be updated due to a merge by vma_modify_flags(), which can result in curr_end being stale and thus, upon setting curr_start to curr_end, ending up with an incorrect curr_start on the next iteration. Resolve the issue by setting curr_end to vma->vm_end unconditionally to ensure this value remains updated should this occur. While we're here, eliminate this entire class of bug by simply setting const curr_[start/end] to be clamped to the input range and VMAs, which also happens to simplify the logic. Link: https://lkml.kernel.org/r/20260327173104.322405-1-ljs@kernel.org Fixes: 6c2da14ae1e0 ("mm/mseal: rework mseal apply logic") Signed-off-by: Lorenzo Stoakes (Oracle) Reported-by: Antonius Closes: https://lore.kernel.org/linux-mm/CAK8a0jwWGj9-SgFk0yKFh7i8jMkwKm5b0ao9=kmXWjO54veX2g@mail.gmail.com/ Suggested-by: David Hildenbrand (ARM) Acked-by: Vlastimil Babka (SUSE) Reviewed-by: Pedro Falcato Acked-by: David Hildenbrand (Arm) Cc: Jann Horn Cc: Jeff Xu Cc: Liam Howlett Cc: Signed-off-by: Andrew Morton Signed-off-by: Lorenzo Stoakes (Oracle) Signed-off-by: Greg Kroah-Hartman commit a5c6f6d6ceefed2d5210ee420fb75f8362461f46 Author: Werner Kasselman Date: Mon Mar 30 18:50:51 2026 -0400 ksmbd: fix use-after-free and NULL deref in smb_grant_oplock() [ Upstream commit 48623ec358c1c600fa1e38368746f933e0f1a617 ] smb_grant_oplock() has two issues in the oplock publication sequence: 1) opinfo is linked into ci->m_op_list (via opinfo_add) before add_lease_global_list() is called. If add_lease_global_list() fails (kmalloc returns NULL), the error path frees the opinfo via __free_opinfo() while it is still linked in ci->m_op_list. Concurrent m_op_list readers (opinfo_get_list, or direct iteration in smb_break_all_levII_oplock) dereference the freed node. 2) opinfo->o_fp is assigned after add_lease_global_list() publishes the opinfo on the global lease list. A concurrent find_same_lease_key() can walk the lease list and dereference opinfo->o_fp->f_ci while o_fp is still NULL. Fix by restructuring the publication sequence to eliminate post-publish failure: - Set opinfo->o_fp before any list publication (fixes NULL deref). - Preallocate lease_table via alloc_lease_table() before opinfo_add() so add_lease_global_list() becomes infallible after publication. - Keep the original m_op_list publication order (opinfo_add before lease list) so concurrent opens via same_client_has_lease() and opinfo_get_list() still see the in-flight grant. - Use opinfo_put() instead of __free_opinfo() on err_out so that the RCU-deferred free path is used. This also requires splitting add_lease_global_list() to take a preallocated lease_table and changing its return type from int to void, since it can no longer fail. Fixes: 1dfd062caa16 ("ksmbd: fix use-after-free by using call_rcu() for oplock_info") Cc: stable@vger.kernel.org Signed-off-by: Werner Kasselman Reviewed-by: ChenXiaoSong Acked-by: Namjae Jeon Signed-off-by: Steve French [ adapted kmalloc_obj() macro to kmalloc(sizeof()) ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7ad1997b9bc8032603df8f091761114479285769 Author: Jinjiang Tu Date: Mon Mar 30 21:09:28 2026 -0400 mm/huge_memory: fix folio isn't locked in softleaf_to_folio() [ Upstream commit 4c5e7f0fcd592801c9cc18f29f80fbee84eb8669 ] On arm64 server, we found folio that get from migration entry isn't locked in softleaf_to_folio(). This issue triggers when mTHP splitting and zap_nonpresent_ptes() races, and the root cause is lack of memory barrier in softleaf_to_folio(). The race is as follows: CPU0 CPU1 deferred_split_scan() zap_nonpresent_ptes() lock folio split_folio() unmap_folio() change ptes to migration entries __split_folio_to_order() softleaf_to_folio() set flags(including PG_locked) for tail pages folio = pfn_folio(softleaf_to_pfn(entry)) smp_wmb() VM_WARN_ON_ONCE(!folio_test_locked(folio)) prep_compound_page() for tail pages In __split_folio_to_order(), smp_wmb() guarantees page flags of tail pages are visible before the tail page becomes non-compound. smp_wmb() should be paired with smp_rmb() in softleaf_to_folio(), which is missed. As a result, if zap_nonpresent_ptes() accesses migration entry that stores tail pfn, softleaf_to_folio() may see the updated compound_head of tail page before page->flags. This issue will trigger VM_WARN_ON_ONCE() in pfn_swap_entry_folio() because of the race between folio split and zap_nonpresent_ptes() leading to a folio incorrectly undergoing modification without a folio lock being held. This is a BUG_ON() before commit 93976a20345b ("mm: eliminate further swapops predicates"), which in merged in v6.19-rc1. To fix it, add missing smp_rmb() if the softleaf entry is migration entry in softleaf_to_folio() and softleaf_to_page(). [tujinjiang@huawei.com: update function name and comments] Link: https://lkml.kernel.org/r/20260321075214.3305564-1-tujinjiang@huawei.com Link: https://lkml.kernel.org/r/20260319012541.4158561-1-tujinjiang@huawei.com Fixes: e9b61f19858a ("thp: reintroduce split_huge_page()") Signed-off-by: Jinjiang Tu Acked-by: David Hildenbrand (Arm) Reviewed-by: Lorenzo Stoakes (Oracle) Cc: Barry Song Cc: Kefeng Wang Cc: Liam Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Nanyong Sun Cc: Ryan Roberts Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton [ applied fix to swapops.h using old pfn_swap_entry/swp_entry_t naming ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e9de9f3ce06b133a348006668bc8d25c6e504867 Author: Josh Law Date: Sat Mar 21 10:54:24 2026 -0700 mm/damon/sysfs: fix param_ctx leak on damon_sysfs_new_test_ctx() failure commit 7fe000eb32904758a85e62f6ea9483f89d5dabfc upstream. Patch series "mm/damon/sysfs: fix memory leak and NULL dereference issues", v4. DAMON_SYSFS can leak memory under allocation failure, and do NULL pointer dereference when a privileged user make wrong sequences of control. Fix those. This patch (of 3): When damon_sysfs_new_test_ctx() fails in damon_sysfs_commit_input(), param_ctx is leaked because the early return skips the cleanup at the out label. Destroy param_ctx before returning. Link: https://lkml.kernel.org/r/20260321175427.86000-1-sj@kernel.org Link: https://lkml.kernel.org/r/20260321175427.86000-2-sj@kernel.org Fixes: f0c5118ebb0e ("mm/damon/sysfs: catch commit test ctx alloc failure") Signed-off-by: Josh Law Reviewed-by: SeongJae Park Signed-off-by: SeongJae Park Cc: [6.18+] Signed-off-by: Andrew Morton Signed-off-by: SeongJae Park Signed-off-by: Greg Kroah-Hartman commit 9c495f9d3781cd692bd199531cabd4627155e8cd Author: SeongJae Park Date: Thu Mar 19 07:52:17 2026 -0700 mm/damon/core: avoid use of half-online-committed context commit 26f775a054c3cda86ad465a64141894a90a9e145 upstream. One major usage of damon_call() is online DAMON parameters update. It is done by calling damon_commit_ctx() inside the damon_call() callback function. damon_commit_ctx() can fail for two reasons: 1) invalid parameters and 2) internal memory allocation failures. In case of failures, the damon_ctx that attempted to be updated (commit destination) can be partially updated (or, corrupted from a perspective), and therefore shouldn't be used anymore. The function only ensures the damon_ctx object can safely deallocated using damon_destroy_ctx(). The API callers are, however, calling damon_commit_ctx() only after asserting the parameters are valid, to avoid damon_commit_ctx() fails due to invalid input parameters. But it can still theoretically fail if the internal memory allocation fails. In the case, DAMON may run with the partially updated damon_ctx. This can result in unexpected behaviors including even NULL pointer dereference in case of damos_commit_dests() failure [1]. Such allocation failure is arguably too small to fail, so the real world impact would be rare. But, given the bad consequence, this needs to be fixed. Avoid such partially-committed (maybe-corrupted) damon_ctx use by saving the damon_commit_ctx() failure on the damon_ctx object. For this, introduce damon_ctx->maybe_corrupted field. damon_commit_ctx() sets it when it is failed. kdamond_call() checks if the field is set after each damon_call_control->fn() is executed. If it is set, ignore remaining callback requests and return. All kdamond_call() callers including kdamond_fn() also check the maybe_corrupted field right after kdamond_call() invocations. If the field is set, break the kdamond_fn() main loop so that DAMON sill doesn't use the context that might be corrupted. [sj@kernel.org: let kdamond_call() with cancel regardless of maybe_corrupted] Link: https://lkml.kernel.org/r/20260320031553.2479-1-sj@kernel.org Link: https://sashiko.dev/#/patchset/20260319145218.86197-1-sj%40kernel.org Link: https://lkml.kernel.org/r/20260319145218.86197-1-sj@kernel.org Link: https://lore.kernel.org/20260319043309.97966-1-sj@kernel.org [1] Fixes: 3301f1861d34 ("mm/damon/sysfs: handle commit command using damon_call()") Signed-off-by: SeongJae Park Cc: [6.15+] Signed-off-by: Andrew Morton Signed-off-by: SeongJae Park Signed-off-by: Greg Kroah-Hartman commit 9cf7588aa578163367831b1c609aca33e37a05a2 Author: SeongJae Park Date: Mon Mar 16 16:51:17 2026 -0700 mm/damon/stat: monitor all System RAM resources commit 84481e705ab07ed46e56587fe846af194acacafe upstream. DAMON_STAT usage document (Documentation/admin-guide/mm/damon/stat.rst) says it monitors the system's entire physical memory. But, it is monitoring only the biggest System RAM resource of the system. When there are multiple System RAM resources, this results in monitoring only an unexpectedly small fraction of the physical memory. For example, suppose the system has a 500 GiB System RAM, 10 MiB non-System RAM, and 500 GiB System RAM resources in order on the physical address space. DAMON_STAT will monitor only the first 500 GiB System RAM. This situation is particularly common on NUMA systems. Select a physical address range that covers all System RAM areas of the system, to fix this issue and make it work as documented. [sj@kernel.org: return error if monitoring target region is invalid] Link: https://lkml.kernel.org/r/20260317053631.87907-1-sj@kernel.org Link: https://lkml.kernel.org/r/20260316235118.873-1-sj@kernel.org Fixes: 369c415e6073 ("mm/damon: introduce DAMON_STAT module") Signed-off-by: SeongJae Park Cc: [6.17+] Signed-off-by: Andrew Morton Signed-off-by: SeongJae Park Signed-off-by: Greg Kroah-Hartman commit 5eeba3a7bf496d5c24379305d47933c6061e462a Author: Yang Wang Date: Wed Nov 19 10:46:23 2025 +0800 drm/amd/pm: fix amdgpu_irq enabled counter unbalanced on smu v11.0 commit e12603bf2c3d571476a21debfeab80bb70d8c0cc upstream. v1: - fix amdgpu_irq enabled counter unbalanced issue on smu_v11_0_disable_thermal_alert. v2: - re-enable smu thermal alert to make amdgpu irq counter balance for smu v11.0 if in runpm state [75582.361561] ------------[ cut here ]------------ [75582.361565] WARNING: CPU: 42 PID: 533 at drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c:639 amdgpu_irq_put+0xd8/0xf0 [amdgpu] ... [75582.362211] Tainted: [E]=UNSIGNED_MODULE [75582.362214] Hardware name: GIGABYTE MZ01-CE0-00/MZ01-CE0-00, BIOS F14a 08/14/2020 [75582.362218] Workqueue: pm pm_runtime_work [75582.362225] RIP: 0010:amdgpu_irq_put+0xd8/0xf0 [amdgpu] [75582.362556] Code: 31 f6 31 ff e9 c9 bf cf c2 44 89 f2 4c 89 e6 4c 89 ef e8 db fc ff ff 5b 41 5c 41 5d 41 5e 5d 31 d2 31 f6 31 ff e9 a8 bf cf c2 <0f> 0b eb c3 b8 fe ff ff ff eb 97 e9 84 e8 8b 00 0f 1f 84 00 00 00 [75582.362560] RSP: 0018:ffffd50d51297b80 EFLAGS: 00010246 [75582.362564] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 [75582.362568] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [75582.362570] RBP: ffffd50d51297ba0 R08: 0000000000000000 R09: 0000000000000000 [75582.362573] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8e72091d2008 [75582.362576] R13: ffff8e720af80000 R14: 0000000000000000 R15: ffff8e720af80000 [75582.362579] FS: 0000000000000000(0000) GS:ffff8e9158262000(0000) knlGS:0000000000000000 [75582.362582] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [75582.362585] CR2: 000074869d040c14 CR3: 0000001e37a3e000 CR4: 00000000003506f0 [75582.362588] Call Trace: [75582.362591] [75582.362597] smu_v11_0_disable_thermal_alert+0x17/0x30 [amdgpu] [75582.362983] smu_smc_hw_cleanup+0x79/0x4f0 [amdgpu] [75582.363375] smu_suspend+0x92/0x110 [amdgpu] [75582.363762] ? gfx_v10_0_hw_fini+0xd5/0x150 [amdgpu] [75582.364098] amdgpu_ip_block_suspend+0x27/0x80 [amdgpu] [75582.364377] ? timer_delete_sync+0x10/0x20 [75582.364384] amdgpu_device_ip_suspend_phase2+0x190/0x450 [amdgpu] [75582.364665] amdgpu_device_suspend+0x1ae/0x2f0 [amdgpu] [75582.364948] amdgpu_pmops_runtime_suspend+0xf3/0x1f0 [amdgpu] [75582.365230] pci_pm_runtime_suspend+0x6d/0x1f0 [75582.365237] ? __pfx_pci_pm_runtime_suspend+0x10/0x10 [75582.365242] __rpm_callback+0x4c/0x190 [75582.365246] ? srso_return_thunk+0x5/0x5f [75582.365252] ? srso_return_thunk+0x5/0x5f [75582.365256] ? ktime_get_mono_fast_ns+0x43/0xe0 [75582.365263] rpm_callback+0x6e/0x80 [75582.365267] rpm_suspend+0x124/0x5f0 [75582.365271] ? srso_return_thunk+0x5/0x5f [75582.365275] ? __schedule+0x439/0x15e0 [75582.365281] ? srso_return_thunk+0x5/0x5f [75582.365285] ? __queue_delayed_work+0xb8/0x180 [75582.365293] pm_runtime_work+0xc6/0xe0 [75582.365297] process_one_work+0x1a1/0x3f0 [75582.365303] worker_thread+0x2ba/0x3d0 [75582.365309] kthread+0x107/0x220 [75582.365313] ? __pfx_worker_thread+0x10/0x10 [75582.365318] ? __pfx_kthread+0x10/0x10 [75582.365323] ret_from_fork+0xa2/0x120 [75582.365328] ? __pfx_kthread+0x10/0x10 [75582.365332] ret_from_fork_asm+0x1a/0x30 [75582.365343] [75582.365345] ---[ end trace 0000000000000000 ]--- [75582.365350] amdgpu 0000:05:00.0: amdgpu: Fail to disable thermal alert! [75582.365379] amdgpu 0000:05:00.0: amdgpu: suspend of IP block failed -22 Signed-off-by: Yang Wang Reviewed-by: Alex Deucher Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit e1cd6e0251ef2762e8b38ab23d5e36ccf3004a1f Author: Benno Lossin Date: Mon Mar 2 15:04:15 2026 +0100 rust: pin-init: internal: init: document load-bearing fact of field accessors commit 580cc37b1de4fcd9997c48d7080e744533f09f36 upstream. The functions `[Pin]Init::__[pinned_]init` and `ptr::write` called from the `init!` macro require the passed pointer to be aligned. This fact is ensured by the creation of field accessors to previously initialized fields. Since we missed this very important fact from the beginning [1], document it in the code. Link: https://rust-for-linux.zulipchat.com/#narrow/channel/561532-pin-init/topic/initialized.20field.20accessor.20detection/with/576210658 [1] Fixes: 90e53c5e70a6 ("rust: add pin-init API core") Cc: # 6.6.y, 6.12.y: 42415d163e5d: rust: pin-init: add references to previously initialized fields Cc: # 6.6.y, 6.12.y, 6.18.y, 6.19.y Signed-off-by: Benno Lossin Reviewed-by: Gary Guo Link: https://patch.msgid.link/20260302140424.4097655-2-lossin@kernel.org [ Updated Cc: stable@ tags as discussed. - Miguel ] Signed-off-by: Miguel Ojeda [ Moved changes to the declarative macro, because 6.19.y and earlier do not have `syn`. Also duplicated the comment for all field accessor creations. - Benno ] Signed-off-by: Benno Lossin Signed-off-by: Greg Kroah-Hartman commit 6b60e35a7fdba4b36a02720a5aa69b1a6e589a95 Author: Peter Zijlstra Date: Wed Oct 29 14:24:57 2025 +0100 unwind_user/x86: Fix arch=um build commit aa7387e79a5cff0585cd1b9091944142a06872b6 upstream. Add CONFIG_HAVE_UNWIND_USER_FP guards to make sure this code doesn't break arch=um builds. Reported-by: kernel test robot Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Closes: https://lore.kernel.org/oe-kbuild-all/202510291919.FFGyU7nq-lkp@intel.com/ Signed-off-by: Greg Kroah-Hartman commit 41fc9825ac257ccf1b46210a13bc4de44e3bd33e Author: Hari Bathini Date: Tue Mar 3 23:40:25 2026 +0530 powerpc64/bpf: do not increment tailcall count when prog is NULL commit 521bd39d9d28ce54cbfec7f9b89c94ad4fdb8350 upstream. Do not increment tailcall count, if tailcall did not succeed due to missing BPF program. Fixes: ce0761419fae ("powerpc/bpf: Implement support for tail calls") Cc: stable@vger.kernel.org Tested-by: Venkat Rao Bagalkote Signed-off-by: Hari Bathini Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260303181031.390073-2-hbathini@linux.ibm.com [ Conflict due to missing feature commit 2ed2d8f6fb38 ("powerpc64/bpf: Support tailcalls with subprogs") resolved accordingly. ] Signed-off-by: Hari Bathini Signed-off-by: Greg Kroah-Hartman commit b159111cdd8a9bbec432245718b8b4ce4b1924a7 Author: Markus Niebel Date: Tue Dec 16 14:39:25 2025 +0100 arm64: dts: imx8mn-tqma8mqnl: fix LDO5 power off commit 8adc841d43ebceabec996c9dcff6e82d3e585268 upstream. Fix SD card removal caused by automatic LDO5 power off after boot To prevent this, add vqmmc regulator for USDHC, using a GPIO-controlled regulator that is supplied by LDO5. Since this is implemented on SoM but used on baseboards with SD-card interface, implement the functionality on SoM part and optionally enable it on baseboards if needed. Signed-off-by: Markus Niebel Signed-off-by: Alexander Stein Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 812b6a7cd3e7f3a3e8a24db85bc6313c26cb1098 Author: Theodore Ts'o Date: Fri Mar 27 02:13:15 2026 -0400 ext4: always drain queued discard work in ext4_mb_release() commit 9ee29d20aab228adfb02ca93f87fb53c56c2f3af upstream. While reviewing recent ext4 patch[1], Sashiko raised the following concern[2]: > If the filesystem is initially mounted with the discard option, > deleting files will populate sbi->s_discard_list and queue > s_discard_work. If it is then remounted with nodiscard, the > EXT4_MOUNT_DISCARD flag is cleared, but the pending s_discard_work is > neither cancelled nor flushed. [1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/ [2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev The concern was valid, but it had nothing to do with the patch[1]. One of the problems with Sashiko in its current (early) form is that it will detect pre-existing issues and report it as a problem with the patch that it is reviewing. In practice, it would be hard to hit deliberately (unless you are a malicious syzkaller fuzzer), since it would involve mounting the file system with -o discard, and then deleting a large number of files, remounting the file system with -o nodiscard, and then immediately unmounting the file system before the queued discard work has a change to drain on its own. Fix it because it's a real bug, and to avoid Sashiko from raising this concern when analyzing future patches to mballoc.c. Signed-off-by: Theodore Ts'o Fixes: 55cdd0af2bc5 ("ext4: get discard out of jbd2 commit kthread contex") Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit f7817ad399d604e8639005d87d148b5ec626ad26 Author: Baokun Li Date: Mon Mar 23 14:08:36 2026 +0800 ext4: fix iloc.bh leak in ext4_fc_replay_inode() error paths commit ec0a7500d8eace5b4f305fa0c594dd148f0e8d29 upstream. During code review, Joseph found that ext4_fc_replay_inode() calls ext4_get_fc_inode_loc() to get the inode location, which holds a reference to iloc.bh that must be released via brelse(). However, several error paths jump to the 'out' label without releasing iloc.bh: - ext4_handle_dirty_metadata() failure - sync_dirty_buffer() failure - ext4_mark_inode_used() failure - ext4_iget() failure Fix this by introducing an 'out_brelse' label placed just before the existing 'out' label to ensure iloc.bh is always released. Additionally, make ext4_fc_replay_inode() propagate errors properly instead of always returning 0. Reported-by: Joseph Qi Fixes: 8016e29f4362 ("ext4: fast commit recovery path") Signed-off-by: Baokun Li Reviewed-by: Zhang Yi Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260323060836.3452660-1-libaokun@linux.alibaba.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 12624c5b724a81e14e532972b40d863b0de3b7d1 Author: Theodore Ts'o Date: Thu Mar 26 00:58:34 2026 -0400 ext4: handle wraparound when searching for blocks for indirect mapped blocks commit bb81702370fad22c06ca12b6e1648754dbc37e0f upstream. Commit 4865c768b563 ("ext4: always allocate blocks only from groups inode can use") restricts what blocks will be allocated for indirect block based files to block numbers that fit within 32-bit block numbers. However, when using a review bot running on the latest Gemini LLM to check this commit when backporting into an LTS based kernel, it raised this concern: If ac->ac_g_ex.fe_group is >= ngroups (for instance, if the goal group was populated via stream allocation from s_mb_last_groups), then start will be >= ngroups. Does this allow allocating blocks beyond the 32-bit limit for indirect block mapped files? The commit message mentions that ext4_mb_scan_groups_linear() takes care to not select unsupported groups. However, its loop uses group = *start, and the very first iteration will call ext4_mb_scan_group() with this unsupported group because next_linear_group() is only called at the end of the iteration. After reviewing the code paths involved and considering the LLM review, I determined that this can happen when there is a file system where some files/directories are extent-mapped and others are indirect-block mapped. To address this, add a safety clamp in ext4_mb_scan_groups(). Fixes: 4865c768b563 ("ext4: always allocate blocks only from groups inode can use") Cc: Jan Kara Reviewed-by: Baokun Li Reviewed-by: Jan Kara Signed-off-by: Theodore Ts'o Link: https://patch.msgid.link/20260326045834.1175822-1-tytso@mit.edu Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 0652ab1bd814f9d09c43a8522553e46f7c4499f7 Author: Zqiang Date: Thu Mar 19 17:45:45 2026 +0800 ext4: fix the might_sleep() warnings in kvfree() commit 496bb99b7e66f48b178126626f47e9ba79e2d0fa upstream. Use the kvfree() in the RCU read critical section can trigger the following warnings: EXT4-fs (vdb): unmounting filesystem cd983e5b-3c83-4f5a-a136-17b00eb9d018. WARNING: suspicious RCU usage ./include/linux/rcupdate.h:409 Illegal context switch in RCU read-side critical section! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 Call Trace: dump_stack_lvl+0xbb/0xd0 dump_stack+0x14/0x20 lockdep_rcu_suspicious+0x15a/0x1b0 __might_resched+0x375/0x4d0 ? put_object.part.0+0x2c/0x50 __might_sleep+0x108/0x160 vfree+0x58/0x910 ? ext4_group_desc_free+0x27/0x270 kvfree+0x23/0x40 ext4_group_desc_free+0x111/0x270 ext4_put_super+0x3c8/0xd40 generic_shutdown_super+0x14c/0x4a0 ? __pfx_shrinker_free+0x10/0x10 kill_block_super+0x40/0x90 ext4_kill_sb+0x6d/0xb0 deactivate_locked_super+0xb4/0x180 deactivate_super+0x7e/0xa0 cleanup_mnt+0x296/0x3e0 __cleanup_mnt+0x16/0x20 task_work_run+0x157/0x250 ? __pfx_task_work_run+0x10/0x10 ? exit_to_user_mode_loop+0x6a/0x550 exit_to_user_mode_loop+0x102/0x550 do_syscall_64+0x44a/0x500 entry_SYSCALL_64_after_hwframe+0x77/0x7f BUG: sleeping function called from invalid context at mm/vmalloc.c:3441 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 556, name: umount preempt_count: 1, expected: 0 CPU: 3 UID: 0 PID: 556 Comm: umount Call Trace: dump_stack_lvl+0xbb/0xd0 dump_stack+0x14/0x20 __might_resched+0x275/0x4d0 ? put_object.part.0+0x2c/0x50 __might_sleep+0x108/0x160 vfree+0x58/0x910 ? ext4_group_desc_free+0x27/0x270 kvfree+0x23/0x40 ext4_group_desc_free+0x111/0x270 ext4_put_super+0x3c8/0xd40 generic_shutdown_super+0x14c/0x4a0 ? __pfx_shrinker_free+0x10/0x10 kill_block_super+0x40/0x90 ext4_kill_sb+0x6d/0xb0 deactivate_locked_super+0xb4/0x180 deactivate_super+0x7e/0xa0 cleanup_mnt+0x296/0x3e0 __cleanup_mnt+0x16/0x20 task_work_run+0x157/0x250 ? __pfx_task_work_run+0x10/0x10 ? exit_to_user_mode_loop+0x6a/0x550 exit_to_user_mode_loop+0x102/0x550 do_syscall_64+0x44a/0x500 entry_SYSCALL_64_after_hwframe+0x77/0x7f The above scenarios occur in initialization failures and teardown paths, there are no parallel operations on the resources released by kvfree(), this commit therefore remove rcu_read_lock/unlock() and use rcu_access_pointer() instead of rcu_dereference() operations. Fixes: 7c990728b99e ("ext4: fix potential race between s_flex_groups online resizing and access") Fixes: df3da4ea5a0f ("ext4: fix potential race between s_group_info online resizing and access") Signed-off-by: Zqiang Reviewed-by: Baokun Li Link: https://patch.msgid.link/20260319094545.19291-1-qiang.zhang@linux.dev Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit c97e282f7bfd0c3554c63d289964a5ca6a1d2ffe Author: Jiayuan Chen Date: Thu Mar 19 20:03:35 2026 +0800 ext4: fix use-after-free in update_super_work when racing with umount commit d15e4b0a418537aafa56b2cb80d44add83e83697 upstream. Commit b98535d09179 ("ext4: fix bug_on in start_this_handle during umount filesystem") moved ext4_unregister_sysfs() before flushing s_sb_upd_work to prevent new error work from being queued via /proc/fs/ext4/xx/mb_groups reads during unmount. However, this introduced a use-after-free because update_super_work calls ext4_notify_error_sysfs() -> sysfs_notify() which accesses the kobject's kernfs_node after it has been freed by kobject_del() in ext4_unregister_sysfs(): update_super_work ext4_put_super ----------------- -------------- ext4_unregister_sysfs(sb) kobject_del(&sbi->s_kobj) __kobject_del() sysfs_remove_dir() kobj->sd = NULL sysfs_put(sd) kernfs_put() // RCU free ext4_notify_error_sysfs(sbi) sysfs_notify(&sbi->s_kobj) kn = kobj->sd // stale pointer kernfs_get(kn) // UAF on freed kernfs_node ext4_journal_destroy() flush_work(&sbi->s_sb_upd_work) Instead of reordering the teardown sequence, fix this by making ext4_notify_error_sysfs() detect that sysfs has already been torn down by checking s_kobj.state_in_sysfs, and skipping the sysfs_notify() call in that case. A dedicated mutex (s_error_notify_mutex) serializes ext4_notify_error_sysfs() against kobject_del() in ext4_unregister_sysfs() to prevent TOCTOU races where the kobject could be deleted between the state_in_sysfs check and the sysfs_notify() call. Fixes: b98535d09179 ("ext4: fix bug_on in start_this_handle during umount filesystem") Cc: Jiayuan Chen Suggested-by: Jan Kara Signed-off-by: Jiayuan Chen Reviewed-by: Ritesh Harjani (IBM) Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260319120336.157873-1-jiayuan.chen@linux.dev Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit ad1f6d608f33f59d21a3d025615d6786a6443998 Author: Helen Koike Date: Tue Mar 17 11:23:10 2026 -0300 ext4: reject mount if bigalloc with s_first_data_block != 0 commit 3822743dc20386d9897e999dbb990befa3a5b3f8 upstream. bigalloc with s_first_data_block != 0 is not supported, reject mounting it. Signed-off-by: Helen Koike Suggested-by: Theodore Ts'o Reported-by: syzbot+b73703b873a33d8eb8f6@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b73703b873a33d8eb8f6 Link: https://patch.msgid.link/20260317142325.135074-1-koike@igalia.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 1895f7904be71c48f1e6f338b28f24dabd6b8aeb Author: Ye Bin Date: Mon Mar 2 21:46:19 2026 +0800 ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal() commit 46066e3a06647c5b186cc6334409722622d05c44 upstream. There's issue as follows: ... EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2243 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2239 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): error count since last fsck: 1 EXT4-fs (mmcblk0p1): initial error at time 1765597433: ext4_mb_generate_buddy:760 EXT4-fs (mmcblk0p1): last error at time 1765597433: ext4_mb_generate_buddy:760 ... According to the log analysis, blocks are always requested from the corrupted block group. This may happen as follows: ext4_mb_find_by_goal ext4_mb_load_buddy ext4_mb_load_buddy_gfp ext4_mb_init_cache ext4_read_block_bitmap_nowait ext4_wait_block_bitmap ext4_validate_block_bitmap if (!grp || EXT4_MB_GRP_BBITMAP_CORRUPT(grp)) return -EFSCORRUPTED; // There's no logs. if (err) return err; // Will return error ext4_lock_group(ac->ac_sb, group); if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info))) // Unreachable goto out; After commit 9008a58e5dce ("ext4: make the bitmap read routines return real error codes") merged, Commit 163a203ddb36 ("ext4: mark block group as corrupt on block bitmap error") is no real solution for allocating blocks from corrupted block groups. This is because if 'EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info)' is true, then 'ext4_mb_load_buddy()' may return an error. This means that the block allocation will fail. Therefore, check block group if corrupted when ext4_mb_load_buddy() returns error. Fixes: 163a203ddb36 ("ext4: mark block group as corrupt on block bitmap error") Fixes: 9008a58e5dce ("ext4: make the bitmap read routines return real error codes") Signed-off-by: Ye Bin Reviewed-by: Ritesh Harjani (IBM) Reviewed-by: Zhang Yi Reviewed-by: Andreas Dilger Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260302134619.3145520-1-yebin@huaweicloud.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 416c86f30f91b4fb2642ef6b102596ca898f41a5 Author: Edward Adam Davis Date: Fri Mar 6 09:31:58 2026 +0800 ext4: avoid infinite loops caused by residual data commit 5422fe71d26d42af6c454ca9527faaad4e677d6c upstream. On the mkdir/mknod path, when mapping logical blocks to physical blocks, if inserting a new extent into the extent tree fails (in this example, because the file system disabled the huge file feature when marking the inode as dirty), ext4_ext_map_blocks() only calls ext4_free_blocks() to reclaim the physical block without deleting the corresponding data in the extent tree. This causes subsequent mkdir operations to reference the previously reclaimed physical block number again, even though this physical block is already being used by the xattr block. Therefore, a situation arises where both the directory and xattr are using the same buffer head block in memory simultaneously. The above causes ext4_xattr_block_set() to enter an infinite loop about "inserted" and cannot release the inode lock, ultimately leading to the 143s blocking problem mentioned in [1]. If the metadata is corrupted, then trying to remove some extent space can do even more harm. Also in case EXT4_GET_BLOCKS_DELALLOC_RESERVE was passed, remove space wrongly update quota information. Jan Kara suggests distinguishing between two cases: 1) The error is ENOSPC or EDQUOT - in this case the filesystem is fully consistent and we must maintain its consistency including all the accounting. However these errors can happen only early before we've inserted the extent into the extent tree. So current code works correctly for this case. 2) Some other error - this means metadata is corrupted. We should strive to do as few modifications as possible to limit damage. So I'd just skip freeing of allocated blocks. [1] INFO: task syz.0.17:5995 blocked for more than 143 seconds. Call Trace: inode_lock_nested include/linux/fs.h:1073 [inline] __start_dirop fs/namei.c:2923 [inline] start_dirop fs/namei.c:2934 [inline] Reported-by: syzbot+512459401510e2a9a39f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1659aaaaa8d9d11265d7 Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com Reported-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=512459401510e2a9a39f Tested-by: syzbot+1659aaaaa8d9d11265d7@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Reviewed-by: Jan Kara Tested-by: syzbot+512459401510e2a9a39f@syzkaller.appspotmail.com Link: https://patch.msgid.link/tencent_43696283A68450B761D76866C6F360E36705@qq.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 93f2e975ed658ce09db4d4c2877ca2c06540df83 Author: Tejas Bharambe Date: Tue Mar 3 23:14:34 2026 -0800 ext4: validate p_idx bounds in ext4_ext_correct_indexes commit 2acb5c12ebd860f30e4faf67e6cc8c44ddfe5fe8 upstream. ext4_ext_correct_indexes() walks up the extent tree correcting index entries when the first extent in a leaf is modified. Before accessing path[k].p_idx->ei_block, there is no validation that p_idx falls within the valid range of index entries for that level. If the on-disk extent header contains a corrupted or crafted eh_entries value, p_idx can point past the end of the allocated buffer, causing a slab-out-of-bounds read. Fix this by validating path[k].p_idx against EXT_LAST_INDEX() at both access sites: before the while loop and inside it. Return -EFSCORRUPTED if the index pointer is out of range, consistent with how other bounds violations are handled in the ext4 extent tree code. Reported-by: syzbot+04c4e65cab786a2e5b7e@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=04c4e65cab786a2e5b7e Signed-off-by: Tejas Bharambe Link: https://patch.msgid.link/JH0PR06MB66326016F9B6AD24097D232B897CA@JH0PR06MB6632.apcprd06.prod.outlook.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit b44fc445b3b7f32214fcbd5e01b6be047ea494bb Author: Ye Bin Date: Tue Mar 3 09:22:42 2026 +0800 ext4: test if inode's all dirty pages are submitted to disk commit 73bf12adbea10b13647864cd1c62410d19e21086 upstream. The commit aa373cf55099 ("writeback: stop background/kupdate works from livelocking other works") introduced an issue where unmounting a filesystem in a multi-logical-partition scenario could lead to batch file data loss. This problem was not fixed until the commit d92109891f21 ("fs/writeback: bail out if there is no more inodes for IO and queued once"). It took considerable time to identify the root cause. Additionally, in actual production environments, we frequently encountered file data loss after normal system reboots. Therefore, we are adding a check in the inode release flow to verify whether all dirty pages have been flushed to disk, in order to determine whether the data loss is caused by a logic issue in the filesystem code. Signed-off-by: Ye Bin Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260303012242.3206465-1-yebin@huaweicloud.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 4855a59e21789c79f003a9b5f4135c95a7495c6b Author: Li Chen Date: Wed Feb 25 16:26:16 2026 +0800 ext4: publish jinode after initialization commit 1aec30021edd410b986c156f195f3d23959a9d11 upstream. ext4_inode_attach_jinode() publishes ei->jinode to concurrent users. It used to set ei->jinode before jbd2_journal_init_jbd_inode(), allowing a reader to observe a non-NULL jinode with i_vfs_inode still unset. The fast commit flush path can then pass this jinode to jbd2_wait_inode_data(), which dereferences i_vfs_inode->i_mapping and may crash. Below is the crash I observe: ``` BUG: unable to handle page fault for address: 000000010beb47f4 PGD 110e51067 P4D 110e51067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 4850 Comm: fc_fsync_bench_ Not tainted 6.18.0-00764-g795a690c06a5 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 RIP: 0010:xas_find_marked+0x3d/0x2e0 Code: e0 03 48 83 f8 02 0f 84 f0 01 00 00 48 8b 47 08 48 89 c3 48 39 c6 0f 82 fd 01 00 00 48 85 c9 74 3d 48 83 f9 03 77 63 4c 8b 0f <49> 8b 71 08 48 c7 47 18 00 00 00 00 48 89 f1 83 e1 03 48 83 f9 02 RSP: 0018:ffffbbee806e7bf0 EFLAGS: 00010246 RAX: 000000000010beb4 RBX: 000000000010beb4 RCX: 0000000000000003 RDX: 0000000000000001 RSI: 0000002000300000 RDI: ffffbbee806e7c10 RBP: 0000000000000001 R08: 0000002000300000 R09: 000000010beb47ec R10: ffff9ea494590090 R11: 0000000000000000 R12: 0000002000300000 R13: ffffbbee806e7c90 R14: ffff9ea494513788 R15: ffffbbee806e7c88 FS: 00007fc2f9e3e6c0(0000) GS:ffff9ea6b1444000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000010beb47f4 CR3: 0000000119ac5000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: filemap_get_folios_tag+0x87/0x2a0 __filemap_fdatawait_range+0x5f/0xd0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __schedule+0x3e7/0x10c0 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? cap_safe_nice+0x37/0x70 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 filemap_fdatawait_range_keep_errors+0x12/0x40 ext4_fc_commit+0x697/0x8b0 ? ext4_file_write_iter+0x64b/0x950 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? vfs_write+0x356/0x480 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ext4_sync_file+0xf7/0x370 do_fsync+0x3b/0x80 ? syscall_trace_enter+0x108/0x1d0 __x64_sys_fdatasync+0x16/0x20 do_syscall_64+0x62/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... ``` Fix this by initializing the jbd2_inode first. Use smp_wmb() and WRITE_ONCE() to publish ei->jinode after initialization. Readers use READ_ONCE() to fetch the pointer. Fixes: a361293f5fede ("jbd2: Fix oops in jbd2_journal_file_inode()") Cc: stable@vger.kernel.org Signed-off-by: Li Chen Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260225082617.147957-1-me@linux.beauty Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 823849a26af089ffc5dfdd2ae4b9d446b46a0cda Author: Yuto Ohnuki Date: Mon Feb 23 12:33:46 2026 +0000 ext4: replace BUG_ON with proper error handling in ext4_read_inline_folio commit 356227096eb66e41b23caf7045e6304877322edf upstream. Replace BUG_ON() with proper error handling when inline data size exceeds PAGE_SIZE. This prevents kernel panic and allows the system to continue running while properly reporting the filesystem corruption. The error is logged via ext4_error_inode(), the buffer head is released to prevent memory leak, and -EFSCORRUPTED is returned to indicate filesystem corruption. Signed-off-by: Yuto Ohnuki Link: https://patch.msgid.link/20260223123345.14838-2-ytohnuki@amazon.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit f49a14810dfe48c12ea7cc83950f3b69e5300563 Author: Jan Kara Date: Mon Feb 16 17:48:43 2026 +0100 ext4: make recently_deleted() properly work with lazy itable initialization commit bd060afa7cc3e0ad30afa9ecc544a78638498555 upstream. recently_deleted() checks whether inode has been used in the near past. However this can give false positive result when inode table is not initialized yet and we are in fact comparing to random garbage (or stale itable block of a filesystem before mkfs). Ultimately this results in uninitialized inodes being skipped during inode allocation and possibly they are never initialized and thus e2fsck complains. Verify if the inode has been initialized before checking for dtime. Signed-off-by: Jan Kara Reviewed-by: Zhang Yi Link: https://patch.msgid.link/20260216164848.3074-3-jack@suse.cz Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 1d4460f33ce8e5765ba91355cd6d4a4ad5126985 Author: Jan Kara Date: Mon Feb 16 17:48:44 2026 +0100 ext4: fix fsync(2) for nojournal mode commit 1308255bbf8452762f89f44f7447ce137ecdbcff upstream. When inode metadata is changed, we sometimes just call ext4_mark_inode_dirty() to track modified metadata. This copies inode metadata into block buffer which is enough when we are journalling metadata. However when we are running in nojournal mode we currently fail to write the dirtied inode buffer during fsync(2) because the inode is not marked as dirty. Use explicit ext4_write_inode() call to make sure the inode table buffer is written to the disk. This is a band aid solution but proper solution requires a much larger rewrite including changes in metadata bh tracking infrastructure. Reported-by: Free Ekanayaka Link: https://lore.kernel.org/all/87il8nhxdm.fsf@x1.mail-host-address-is-not-set/ CC: stable@vger.kernel.org Signed-off-by: Jan Kara Reviewed-by: Zhang Yi Link: https://patch.msgid.link/20260216164848.3074-4-jack@suse.cz Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 16041a808b5097e17d5ae7cbde3e9c9dde4a4c33 Author: Zhang Yi Date: Sat Jan 31 17:11:56 2026 +0800 ext4: do not check fast symlink during orphan recovery commit 84e21e3fb8fd99ea460eb7274584750d11cf3e9f upstream. Commit '5f920d5d6083 ("ext4: verify fast symlink length")' causes the generic/475 test to fail during orphan cleanup of zero-length symlinks. generic/475 84s ... _check_generic_filesystem: filesystem on /dev/vde is inconsistent The fsck reports are provided below: Deleted inode 9686 has zero dtime. Deleted inode 158230 has zero dtime. ... Inode bitmap differences: -9686 -158230 Orphan file (inode 12) block 13 is not clean. Failed to initialize orphan file. In ext4_symlink(), a newly created symlink can be added to the orphan list due to ENOSPC. Its data has not been initialized, and its size is zero. Therefore, we need to disregard the length check of the symbolic link when cleaning up orphan inodes. Instead, we should ensure that the nlink count is zero. Fixes: 5f920d5d6083 ("ext4: verify fast symlink length") Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260131091156.1733648-1-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 95de75794cd941026bc618c43ffbf3c5e8b14c5c Author: Jan Kara Date: Thu Feb 5 10:22:24 2026 +0100 ext4: fix stale xarray tags after writeback commit f4a2b42e78914ff15630e71289adc589c3a8eb45 upstream. There are cases where ext4_bio_write_page() gets called for a page which has no buffers to submit. This happens e.g. when the part of the file is actually a hole, when we cannot allocate blocks due to being called from jbd2, or in data=journal mode when checkpointing writes the buffers earlier. In these cases we just return from ext4_bio_write_page() however if the page didn't need redirtying, we will leave stale DIRTY and/or TOWRITE tags in xarray because those get cleared only in __folio_start_writeback(). As a result we can leave these tags set in mappings even after a final sync on filesystem that's getting remounted read-only or that's being frozen. Various assertions can then get upset when writeback is started on such filesystems (Gerald reported assertion in ext4_journal_check_start() firing). Fix the problem by cycling the page through writeback state even if we decide nothing needs to be written for it so that xarray tags get properly updated. This is slightly silly (we could update the xarray tags directly) but I don't think a special helper messing with xarray tags is really worth it in this relatively rare corner case. Reported-by: Gerald Yang Link: https://lore.kernel.org/all/20260128074515.2028982-1-gerald.yang@canonical.com Fixes: dff4ac75eeee ("ext4: move keep_towrite handling to ext4_bio_write_page()") Signed-off-by: Jan Kara Link: https://patch.msgid.link/20260205092223.21287-2-jack@suse.cz Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 93cb2d103e5c707de0f7ad58a39b7f0fddc27aa6 Author: Deepanshu Kartikey Date: Sat Feb 7 10:06:07 2026 +0530 ext4: convert inline data to extents when truncate exceeds inline size commit ed9356a30e59c7cc3198e7fc46cfedf3767b9b17 upstream. Add a check in ext4_setattr() to convert files from inline data storage to extent-based storage when truncate() grows the file size beyond the inline capacity. This prevents the filesystem from entering an inconsistent state where the inline data flag is set but the file size exceeds what can be stored inline. Without this fix, the following sequence causes a kernel BUG_ON(): 1. Mount filesystem with inode that has inline flag set and small size 2. truncate(file, 50MB) - grows size but inline flag remains set 3. sendfile() attempts to write data 4. ext4_write_inline_data() hits BUG_ON(write_size > inline_capacity) The crash occurs because ext4_write_inline_data() expects inline storage to accommodate the write, but the actual inline capacity (~60 bytes for i_block + ~96 bytes for xattrs) is far smaller than the file size and write request. The fix checks if the new size from setattr exceeds the inode's actual inline capacity (EXT4_I(inode)->i_inline_size) and converts the file to extent-based storage before proceeding with the size change. This addresses the root cause by ensuring the inline data flag and file size remain consistent during truncate operations. Reported-by: syzbot+7de5fe447862fc37576f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=7de5fe447862fc37576f Tested-by: syzbot+7de5fe447862fc37576f@syzkaller.appspotmail.com Signed-off-by: Deepanshu Kartikey Link: https://patch.msgid.link/20260207043607.1175976-1-kartikey406@gmail.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 69835472c72626abf81f4c6c261fbc71674a7d10 Author: Simon Weber Date: Sat Feb 7 10:53:03 2026 +0100 ext4: fix journal credit check when setting fscrypt context commit b1d682f1990c19fb1d5b97d13266210457092bcd upstream. Fix an issue arising when ext4 features has_journal, ea_inode, and encrypt are activated simultaneously, leading to ENOSPC when creating an encrypted file. Fix by passing XATTR_CREATE flag to xattr_set_handle function if a handle is specified, i.e., when the function is called in the control flow of creating a new inode. This aligns the number of jbd2 credits set_handle checks for with the number allocated for creating a new inode. ext4_set_context must not be called with a non-null handle (fs_data) if fscrypt context xattr is not guaranteed to not exist yet. The only other usage of this function currently is when handling the ioctl FS_IOC_SET_ENCRYPTION_POLICY, which calls it with fs_data=NULL. Fixes: c1a5d5f6ab21eb7e ("ext4: improve journal credit handling in set xattr paths") Co-developed-by: Anthony Durrer Signed-off-by: Anthony Durrer Signed-off-by: Simon Weber Reviewed-by: Eric Biggers Link: https://patch.msgid.link/20260207100148.724275-4-simon.weber.39@gmail.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 2c2db09b904312b8938aef693e6fea0060e30066 Author: Darrick J. Wong Date: Mon Mar 23 14:04:33 2026 -0700 xfs: remove file_path tracepoint data commit e31c53a8060e134111ed095783fee0aa0c43b080 upstream. The xfile/xmbuf shmem file descriptions are no longer as detailed as they were when online fsck was first merged, because moving to static strings in commit 60382993a2e180 ("xfs: get rid of the xchk_xfile_*_descr calls") removed a memory allocation and hence a source of failure. However this makes encoding the description in the tracepoints sort of a waste of memory. David Laight also points out that file_path doesn't zero the whole buffer which causes exposure of stale trace bytes, and Steven Rostedt wonders why we're not using a dynamic array for the file path. I don't think this is worth fixing, so let's just rip it out. Cc: rostedt@goodmis.org Cc: david.laight.linux@gmail.com Link: https://lore.kernel.org/linux-xfs/20260323172204.work.979-kees@kernel.org/ Cc: stable@vger.kernel.org # v6.11 Fixes: 19ebc8f84ea12e ("xfs: fix file_path handling in tracepoints") Signed-off-by: Darrick J. Wong Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit a1a5df1038f0b3c560d204270373621a4e622808 Author: Darrick J. Wong Date: Mon Mar 23 14:01:57 2026 -0700 xfs: don't irele after failing to iget in xfs_attri_recover_work commit 70685c291ef82269180758130394ecdc4496b52c upstream. xlog_recovery_iget* never set @ip to a valid pointer if they return an error, so this irele will walk off a dangling pointer. Fix that. Cc: stable@vger.kernel.org # v6.10 Fixes: ae673f534a3097 ("xfs: record inode generation in xattr update log intent items") Signed-off-by: Darrick J. Wong Reviewed-by: Long Li Reviewed-by: Christoph Hellwig Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 68d80f35ea62379deb419d0f8881aa0ae919be1c Author: Long Li Date: Fri Mar 20 10:11:29 2026 +0800 xfs: fix ri_total validation in xlog_recover_attri_commit_pass2 commit d72f2084e30966097c8eae762e31986a33c3c0ae upstream. The ri_total checks for SET/REPLACE operations are hardcoded to 3, but xfs_attri_item_size() only emits a value iovec when value_len > 0, so ri_total is 2 when value_len == 0. For PPTR_SET/PPTR_REMOVE/PPTR_REPLACE, value_len is validated by xfs_attri_validate() to be exactly sizeof(struct xfs_parent_rec) and is never zero, so their hardcoded checks remain correct. This problem may cause log recovery failures. The following script can be used to reproduce the problem: #!/bin/bash mkfs.xfs -f /dev/sda mount /dev/sda /mnt/test/ touch /mnt/test/file for i in {1..200}; do attr -s "user.attr_$i" -V "value_$i" /mnt/test/file > /dev/null done echo 1 > /sys/fs/xfs/debug/larp echo 1 > /sys/fs/xfs/sda/errortag/larp attr -s "user.zero" -V "" /mnt/test/file echo 0 > /sys/fs/xfs/sda/errortag/larp umount /mnt/test mount /dev/sda /mnt/test/ # mount failed Fix this by deriving the expected count dynamically as "2 + !!value_len" for SET/REPLACE operations. Cc: stable@vger.kernel.org # v6.9 Fixes: ad206ae50eca ("xfs: check opcode and iovec count match in xlog_recover_attri_commit_pass2") Reviewed-by: Darrick J. Wong Signed-off-by: Long Li Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 3b0c3414b308e6822cda90bf99f7eac94d4cca2b Author: hongao Date: Thu Mar 12 20:10:26 2026 +0800 xfs: scrub: unlock dquot before early return in quota scrub commit 268378b6ad20569af0d1957992de1c8b16c6e900 upstream. xchk_quota_item can return early after calling xchk_fblock_process_error. When that helper returns false, the function returned immediately without dropping dq->q_qlock, which can leave the dquot lock held and risk lock leaks or deadlocks in later quota operations. Fix this by unlocking dq->q_qlock before the early return. Signed-off-by: hongao Fixes: 7d1f0e167a067e ("xfs: check the ondisk space mapping behind a dquot") Cc: # v6.8 Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 95fb5d643cc70959baa54cd17f52f80ffc3295e7 Author: Yuto Ohnuki Date: Tue Mar 10 18:38:38 2026 +0000 xfs: avoid dereferencing log items after push callbacks commit 79ef34ec0554ec04bdbafafbc9836423734e1bd6 upstream. After xfsaild_push_item() calls iop_push(), the log item may have been freed if the AIL lock was dropped during the push. Background inode reclaim or the dquot shrinker can free the log item while the AIL lock is not held, and the tracepoints in the switch statement dereference the log item after iop_push() returns. Fix this by capturing the log item type, flags, and LSN before calling xfsaild_push_item(), and introducing a new xfs_ail_push_class trace event class that takes these pre-captured values and the ailp pointer instead of the log item pointer. Reported-by: syzbot+652af2b3c5569c4ab63c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=652af2b3c5569c4ab63c Fixes: 90c60e164012 ("xfs: xfs_iflush() is no longer necessary") Cc: stable@vger.kernel.org # v5.9 Signed-off-by: Yuto Ohnuki Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 50f5f056807b7bed74f4f307f2ca0ed92f3e556d Author: Yuto Ohnuki Date: Tue Mar 10 18:38:39 2026 +0000 xfs: save ailp before dropping the AIL lock in push callbacks commit 394d70b86fae9fe865e7e6d9540b7696f73aa9b6 upstream. In xfs_inode_item_push() and xfs_qm_dquot_logitem_push(), the AIL lock is dropped to perform buffer IO. Once the cluster buffer no longer protects the log item from reclaim, the log item may be freed by background reclaim or the dquot shrinker. The subsequent spin_lock() call dereferences lip->li_ailp, which is a use-after-free. Fix this by saving the ailp pointer in a local variable while the AIL lock is held and the log item is guaranteed to be valid. Reported-by: syzbot+652af2b3c5569c4ab63c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=652af2b3c5569c4ab63c Fixes: 90c60e164012 ("xfs: xfs_iflush() is no longer necessary") Cc: stable@vger.kernel.org # v5.9 Reviewed-by: Darrick J. Wong Reviewed-by: Dave Chinner Signed-off-by: Yuto Ohnuki Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 8147e304d7d32fd5c3e943babc296ce2873dc279 Author: Yuto Ohnuki Date: Tue Mar 10 18:38:37 2026 +0000 xfs: stop reclaim before pushing AIL during unmount commit 4f24a767e3d64a5f58c595b5c29b6063a201f1e3 upstream. The unmount sequence in xfs_unmount_flush_inodes() pushed the AIL while background reclaim and inodegc are still running. This is broken independently of any use-after-free issues - background reclaim and inodegc should not be running while the AIL is being pushed during unmount, as inodegc can dirty and insert inodes into the AIL during the flush, and background reclaim can race to abort and free dirty inodes. Reorder xfs_unmount_flush_inodes() to stop inodegc and cancel background reclaim before pushing the AIL. Stop inodegc before cancelling m_reclaim_work because the inodegc worker can re-queue m_reclaim_work via xfs_inodegc_set_reclaimable. Reported-by: syzbot+652af2b3c5569c4ab63c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=652af2b3c5569c4ab63c Fixes: 90c60e164012 ("xfs: xfs_iflush() is no longer necessary") Cc: stable@vger.kernel.org # v5.9 Signed-off-by: Yuto Ohnuki Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 38ec58670a0c5fc1edabdeccd857e586b7b3f318 Author: Max Boone Date: Wed Mar 25 10:59:16 2026 +0100 mm/pagewalk: fix race between concurrent split and refault commit 3b89863c3fa482912911cd65a12a3aeef662c250 upstream. The splitting of a PUD entry in walk_pud_range() can race with a concurrent thread refaulting the PUD leaf entry causing it to try walking a PMD range that has disappeared. An example and reproduction of this is to try reading numa_maps of a process while VFIO-PCI is setting up DMA (specifically the vfio_pin_pages_remote call) on a large BAR for that process. This will trigger a kernel BUG: vfio-pci 0000:03:00.0: enabling device (0000 -> 0002) BUG: unable to handle page fault for address: ffffa23980000000 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI ... RIP: 0010:walk_pgd_range+0x3b5/0x7a0 Code: 8d 43 ff 48 89 44 24 28 4d 89 ce 4d 8d a7 00 00 20 00 48 8b 4c 24 28 49 81 e4 00 00 e0 ff 49 8d 44 24 ff 48 39 c8 4c 0f 43 e3 <49> f7 06 9f ff ff ff 75 3b 48 8b 44 24 20 48 8b 40 28 48 85 c0 74 RSP: 0018:ffffac23e1ecf808 EFLAGS: 00010287 RAX: 00007f44c01fffff RBX: 00007f4500000000 RCX: 00007f44ffffffff RDX: 0000000000000000 RSI: 000ffffffffff000 RDI: ffffffff93378fe0 RBP: ffffac23e1ecf918 R08: 0000000000000004 R09: ffffa23980000000 R10: 0000000000000020 R11: 0000000000000004 R12: 00007f44c0200000 R13: 00007f44c0000000 R14: ffffa23980000000 R15: 00007f44c0000000 FS: 00007fe884739580(0000) GS:ffff9b7d7a9c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffa23980000000 CR3: 000000c0650e2005 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: __walk_page_range+0x195/0x1b0 walk_page_vma+0x62/0xc0 show_numa_map+0x12b/0x3b0 seq_read_iter+0x297/0x440 seq_read+0x11d/0x140 vfs_read+0xc2/0x340 ksys_read+0x5f/0xe0 do_syscall_64+0x68/0x130 ? get_page_from_freelist+0x5c2/0x17e0 ? mas_store_prealloc+0x17e/0x360 ? vma_set_page_prot+0x4c/0xa0 ? __alloc_pages_noprof+0x14e/0x2d0 ? __mod_memcg_lruvec_state+0x8d/0x140 ? __lruvec_stat_mod_folio+0x76/0xb0 ? __folio_mod_stat+0x26/0x80 ? do_anonymous_page+0x705/0x900 ? __handle_mm_fault+0xa8d/0x1000 ? __count_memcg_events+0x53/0xf0 ? handle_mm_fault+0xa5/0x360 ? do_user_addr_fault+0x342/0x640 ? arch_exit_to_user_mode_prepare.constprop.0+0x16/0xa0 ? irqentry_exit_to_user_mode+0x24/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fe88464f47e Code: c0 e9 b6 fe ff ff 50 48 8d 3d be 07 0b 00 e8 69 01 02 00 66 0f 1f 84 00 00 00 00 00 64 8b 04 25 18 00 00 00 85 c0 75 14 0f 05 <48> 3d 00 f0 ff ff 77 5a c3 66 0f 1f 84 00 00 00 00 00 48 83 ec 28 RSP: 002b:00007ffe6cd9a9b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007fe88464f47e RDX: 0000000000020000 RSI: 00007fe884543000 RDI: 0000000000000003 RBP: 00007fe884543000 R08: 00007fe884542010 R09: 0000000000000000 R10: fffffffffffffbc5 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000 Fix this by validating the PUD entry in walk_pmd_range() using a stable snapshot (pudp_get()). If the PUD is not present or is a leaf, retry the walk via ACTION_AGAIN instead of descending further. This mirrors the retry logic in walk_pte_range(), which lets walk_pmd_range() retry if the PTE is not being got by pte_offset_map_lock(). Link: https://lkml.kernel.org/r/20260325-pagewalk-check-pmd-refault-v2-1-707bff33bc60@akamai.com Fixes: f9e54c3a2f5b ("vfio/pci: implement huge_fault support") Co-developed-by: David Hildenbrand (Arm) Signed-off-by: David Hildenbrand (Arm) Signed-off-by: Max Boone Acked-by: David Hildenbrand (Arm) Cc: Liam Howlett Cc: Lorenzo Stoakes (Oracle) Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 3527e9fdc38570cea0f6ddb7a2c9303d4044b217 Author: Josh Law Date: Sat Mar 21 10:54:26 2026 -0700 mm/damon/sysfs: check contexts->nr in repeat_call_fn commit 6557004a8b59c7701e695f02be03c7e20ed1cc15 upstream. damon_sysfs_repeat_call_fn() calls damon_sysfs_upd_tuned_intervals(), damon_sysfs_upd_schemes_stats(), and damon_sysfs_upd_schemes_effective_quotas() without checking contexts->nr. If nr_contexts is set to 0 via sysfs while DAMON is running, these functions dereference contexts_arr[0] and cause a NULL pointer dereference. Add the missing check. For example, the issue can be reproduced using DAMON sysfs interface and DAMON user-space tool (damo) [1] like below. $ sudo damo start --refresh_interval 1s $ echo 0 | sudo tee \ /sys/kernel/mm/damon/admin/kdamonds/0/contexts/nr_contexts Link: https://patch.msgid.link/20260320163559.178101-3-objecting@objecting.org Link: https://lkml.kernel.org/r/20260321175427.86000-4-sj@kernel.org Link: https://github.com/damonitor/damo [1] Fixes: d809a7c64ba8 ("mm/damon/sysfs: implement refresh_ms file internal work") Signed-off-by: Josh Law Reviewed-by: SeongJae Park Signed-off-by: SeongJae Park Cc: [6.17+] Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 708033c231bd782858f4ddbb46ee874a5a5fbdab Author: Josh Law Date: Sat Mar 21 10:54:25 2026 -0700 mm/damon/sysfs: check contexts->nr before accessing contexts_arr[0] commit 1bfe9fb5ed2667fb075682408b776b5273162615 upstream. Multiple sysfs command paths dereference contexts_arr[0] without first verifying that kdamond->contexts->nr == 1. A user can set nr_contexts to 0 via sysfs while DAMON is running, causing NULL pointer dereferences. In more detail, the issue can be triggered by privileged users like below. First, start DAMON and make contexts directory empty (kdamond->contexts->nr == 0). # damo start # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/nr_contexts Then, each of below commands will cause the NULL pointer dereference. # echo update_schemes_stats > state # echo update_schemes_tried_regions > state # echo update_schemes_tried_bytes > state # echo update_schemes_effective_quotas > state # echo update_tuned_intervals > state Guard all commands (except OFF) at the entry point of damon_sysfs_handle_cmd(). Link: https://lkml.kernel.org/r/20260321175427.86000-3-sj@kernel.org Fixes: 0ac32b8affb5 ("mm/damon/sysfs: support DAMOS stats") Signed-off-by: Josh Law Reviewed-by: SeongJae Park Signed-off-by: SeongJae Park Cc: [5.18+] Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 54c143028eb45baec385e8731eb42e22b9c25333 Author: Asad Kamal Date: Wed Mar 18 13:52:57 2026 +0800 drm/amd/pm: Return -EOPNOTSUPP for unsupported OD_MCLK on smu_v13_0_6 commit 2f0e491faee43181b6a86e90f34016b256042fe1 upstream. When SET_UCLK_MAX capability is absent, return -EOPNOTSUPP from smu_v13_0_6_emit_clk_levels() for OD_MCLK instead of 0. This makes unsupported OD_MCLK reporting consistent with other clock types and allows callers to skip the entry cleanly. Signed-off-by: Asad Kamal Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher (cherry picked from commit d82e0a72d9189e8acd353988e1a57f85ce479e37) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 126053d0a685bf1f2e98db8966386f38b2336338 Author: Huacai Chen Date: Thu Mar 26 14:29:09 2026 +0800 LoongArch: KVM: Handle the case that EIOINTC's coremap is empty commit b97bd69eb0f67b5f961b304d28e9ba45e202d841 upstream. EIOINTC's coremap in eiointc_update_sw_coremap() can be empty, currently we get a cpuid with -1 in this case, but we actually need 0 because it's similar as the case that cpuid >= 4. This fix an out-of-bounds access to kvm_arch::phyid_map::phys_map[]. Cc: Fixes: 3956a52bc05bd81 ("LoongArch: KVM: Add EIOINTC read and write functions") Reported-by: Aurelien Jarno Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1131431 Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 878cf6acb4fd8ab4126cf9d369a5bb0e23123418 Author: Huacai Chen Date: Thu Mar 26 14:29:09 2026 +0800 LoongArch: KVM: Make kvm_get_vcpu_by_cpuid() more robust commit 2db06c15d8c7a0ccb6108524e16cd9163753f354 upstream. kvm_get_vcpu_by_cpuid() takes a cpuid parameter whose type is int, so cpuid can be negative. Let kvm_get_vcpu_by_cpuid() return NULL for this case so as to make it more robust. This fix an out-of-bounds access to kvm_arch::phyid_map::phys_map[]. Cc: Fixes: 73516e9da512adc ("LoongArch: KVM: Add vcpu mapping from physical cpuid") Reported-by: Aurelien Jarno Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1131431 Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 70fb63c5d36cc02eaf336b87ac6a82e657f832a4 Author: Huacai Chen Date: Thu Mar 26 14:29:09 2026 +0800 LoongArch: Workaround LS2K/LS7A GPU DMA hang bug commit 95db0c9f526d583634cddb2e5914718570fbac87 upstream. 1. Hardware limitation: GPU, DC and VPU are typically PCI device 06.0, 06.1 and 06.2. They share some hardware resources, so when configure the PCI 06.0 device BAR1, DMA memory access cannot be performed through this BAR, otherwise it will cause hardware abnormalities. 2. In typical scenarios of reboot or S3/S4, DC access to memory through BAR is not prohibited, resulting in GPU DMA hangs. 3. Workaround method: When configuring the 06.0 device BAR1, turn off the memory access of DC, GPU and VPU (via DC's CRTC registers). Cc: stable@vger.kernel.org Signed-off-by: Qianhai Wu Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 53a27c09850be4f5fcb225bfcb19eab7202e6933 Author: Xi Ruoyao Date: Thu Mar 26 14:29:09 2026 +0800 LoongArch: vDSO: Emit GNU_EH_FRAME correctly commit e4878c37f6679fdea91b27a0f4e60a871f0b7bad upstream. With -fno-asynchronous-unwind-tables and --no-eh-frame-hdr (the default of the linker), the GNU_EH_FRAME segment (specified by vdso.lds.S) is empty. This is not valid, as the current DWARF specification mandates the first byte of the EH frame to be the version number 1. It causes some unwinders to complain, for example the ClickHouse query profiler spams the log with messages: clickhouse-server[365854]: libunwind: unsupported .eh_frame_hdr version: 127 at 7ffffffb0000 Here "127" is just the byte located at the p_vaddr (0, i.e. the beginning of the vDSO) of the empty GNU_EH_FRAME segment. Cross- checking with /proc/365854/maps has also proven 7ffffffb0000 is the start of vDSO in the process VM image. In LoongArch the -fno-asynchronous-unwind-tables option seems just a MIPS legacy, and MIPS only uses this option to satisfy the MIPS-specific "genvdso" program, per the commit cfd75c2db17e ("MIPS: VDSO: Explicitly use -fno-asynchronous-unwind-tables"). IIRC it indicates some inherent limitation of the MIPS ELF ABI and has nothing to do with LoongArch. So we can simply flip it over to -fasynchronous-unwind-tables and pass --eh-frame-hdr for linking the vDSO, allowing the profilers to unwind the stack for statistics even if the sample point is taken when the PC is in the vDSO. However simply adjusting the options above would exploit an issue: when the libgcc unwinder saw the invalid GNU_EH_FRAME segment, it silently falled back to a machine-specific routine to match the code pattern of rt_sigreturn() and extract the registers saved in the sigframe if the code pattern is matched. As unwinding from signal handlers is vital for libgcc to support pthread cancellation etc., the fall-back routine had been silently keeping the LoongArch Linux systems functioning since Linux 5.19. But when we start to emit GNU_EH_FRAME with the correct format, fall-back routine will no longer be used and libgcc will fail to unwind the sigframe, and unwinding from signal handlers will no longer work, causing dozens of glibc test failures. To make it possible to unwind from signal handlers again, it's necessary to code the unwind info in __vdso_rt_sigreturn via .cfi_* directives. The offsets in the .cfi_* directives depend on the layout of struct sigframe, notably the offset of sigcontext in the sigframe. To use the offset in the assembly file, factor out struct sigframe into a header to allow asm-offsets.c to output the offset for assembly. To work around a long-term issue in the libgcc unwinder (the pc is unconditionally substracted by 1: doing so is technically incorrect for a signal frame), a nop instruction is included with the two real instructions in __vdso_rt_sigreturn in the same FDE PC range. The same hack has been used on x86 for a long time. Cc: stable@vger.kernel.org Fixes: c6b99bed6b8f ("LoongArch: Add VDSO and VSYSCALL support") Signed-off-by: Xi Ruoyao Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit a1da957c25cf751a2dce8fb7777f82ccbac0cb3e Author: Li Jun Date: Thu Mar 26 14:29:08 2026 +0800 LoongArch: Fix missing NULL checks for kstrdup() commit 3a28daa9b7d7c2ddf2c722e9e95d7e0928bf0cd1 upstream. 1. Replace "of_find_node_by_path("/")" with "of_root" to avoid multiple calls to "of_node_put()". 2. Fix a potential kernel oops during early boot when memory allocation fails while parsing CPU model from device tree. Cc: stable@vger.kernel.org Signed-off-by: Li Jun Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 70e2eb91cb6310a3508439f6f2539dfffa0abf77 Author: Ville Syrjälä Date: Mon Mar 16 18:39:51 2026 +0200 drm/i915: Unlink NV12 planes earlier commit bfa71b7a9dc6b5b8af157686e03308291141d00c upstream. unlink_nv12_plane() will clobber parts of the plane state potentially already set up by plane_atomic_check(), so we must make sure not to call the two in the wrong order. The problem happens when a plane previously selected as a Y plane is now configured as a normal plane by user space. plane_atomic_check() will first compute the proper plane state based on the userspace request, and unlink_nv12_plane() later clears some of the state. This used to work on account of unlink_nv12_plane() skipping the state clearing based on the plane visibility. But I removed that check, thinking it was an impossible situation. Now when that situation happens unlink_nv12_plane() will just WARN and proceed to clobber the state. Rather than reverting to the old way of doing things, I think it's more clear if we unlink the NV12 planes before we even compute the new plane state. Cc: stable@vger.kernel.org Reported-by: Khaled Almahallawy Closes: https://lore.kernel.org/intel-gfx/20260212004852.1920270-1-khaled.almahallawy@intel.com/ Tested-by: Khaled Almahallawy Fixes: 6a01df2f1b2a ("drm/i915: Remove pointless visible check in unlink_nv12_plane()") Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20260316163953.12905-2-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar (cherry picked from commit 017ecd04985573eeeb0745fa2c23896fb22ee0cc) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 859b14e0be9e7b0f26630510d337413c7747be51 Author: Ville Syrjälä Date: Fri Mar 13 13:07:40 2026 +0200 drm/i915: Order OP vs. timeout correctly in __wait_for() commit 6ad2a661ff0d3d94884947d2a593311ba46d34c2 upstream. Put the barrier() before the OP so that anything we read out in OP and check in COND will actually be read out after the timeout has been evaluated. Currently the only place where we use OP is __intel_wait_for_register(), but the use there is precisely susceptible to this reordering, assuming the ktime_*() stuff itself doesn't act as a sufficient barrier: __intel_wait_for_register(...) { ... ret = __wait_for(reg_value = intel_uncore_read_notrace(...), (reg_value & mask) == value, ...); ... } Cc: stable@vger.kernel.org Fixes: 1c3c1dc66a96 ("drm/i915: Add compiler barrier to wait_for") Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20260313110740.24620-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula (cherry picked from commit a464bace0482aa9a83e9aa7beefbaf44cd58e6cf) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 8581466b827fdf0300a3e2e93900ddefd8240053 Author: Imre Deak Date: Fri Mar 20 11:29:00 2026 +0200 drm/i915/dp_tunnel: Fix error handling when clearing stream BW in atomic state commit 77fcf58df15edcf3f5b5421f24814fb72796def9 upstream. Clearing the DP tunnel stream BW in the atomic state involves getting the tunnel group state, which can fail. Handle the error accordingly. This fixes at least one issue where drm_dp_tunnel_atomic_set_stream_bw() failed to get the tunnel group state returning -EDEADLK, which wasn't handled. This lead to the ctx->contended warn later in modeset_lock() while taking a WW mutex for another object in the same atomic state, and thus within the same already contended WW context. Moving intel_crtc_state_alloc() later would avoid freeing saved_state on the error path; this stable patch leaves that simplification for a follow-up. Cc: Uma Shankar Cc: Ville Syrjälä Cc: # v6.9+ Fixes: a4efae87ecb2 ("drm/i915/dp: Compute DP tunnel BW during encoder state computation") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7617 Reviewed-by: Michał Grzelak Reviewed-by: Uma Shankar Signed-off-by: Imre Deak Link: https://patch.msgid.link/20260320092900.13210-1-imre.deak@intel.com (cherry picked from commit fb69d0076e687421188bc8103ab0e8e5825b1df1) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit eb95595194e4755b62360aa821f40a79b0953105 Author: Alex Hung Date: Mon Mar 9 11:16:08 2026 -0600 drm/amd/display: Fix drm_edid leak in amdgpu_dm commit 37c2caa167b0b8aca4f74c32404c5288b876a2a3 upstream. [WHAT] When a sink is connected, aconnector->drm_edid was overwritten without freeing the previous allocation, causing a memory leak on resume. [HOW] Free the previous drm_edid before updating it. Reviewed-by: Roman Li Signed-off-by: Alex Hung Signed-off-by: Chuanyu Tseng Signed-off-by: Alex Deucher (cherry picked from commit 52024a94e7111366141cfc5d888b2ef011f879e5) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 51ccaf0e30c303149244c34820def83d74c86288 Author: Eric Huang Date: Mon Mar 16 11:01:30 2026 -0400 drm/amdgpu: prevent immediate PASID reuse case commit 14b81abe7bdc25f8097906fc2f91276ffedb2d26 upstream. PASID resue could cause interrupt issue when process immediately runs into hw state left by previous process exited with the same PASID, it's possible that page faults are still pending in the IH ring buffer when the process exits and frees up its PASID. To prevent the case, it uses idr cyclic allocator same as kernel pid's. Signed-off-by: Eric Huang Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 8f1de51f49be692de137c8525106e0fce2d1912d) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b6a468966347d1d1845b52c9e1d310818cea7394 Author: Claudiu Beznea Date: Mon Mar 16 15:32:46 2026 +0200 dmaengine: sh: rz-dmac: Move CHCTRL updates under spinlock commit 89a8567d84bde88cb7cdbbac2ab2299c4f991490 upstream. Both rz_dmac_disable_hw() and rz_dmac_irq_handle_channel() update the CHCTRL register. To avoid concurrency issues when configuring functionalities exposed by this registers, take the virtual channel lock. All other CHCTRL updates were already protected by the same lock. Previously, rz_dmac_disable_hw() disabled and re-enabled local IRQs, before accessing CHCTRL registers but this does not ensure race-free access. Remove the local IRQ disable/enable code as well. Fixes: 5000d37042a6 ("dmaengine: sh: Add DMAC driver for RZ/G2L SoC") Cc: stable@vger.kernel.org Reviewed-by: Biju Das Reviewed-by: Frank Li Signed-off-by: Claudiu Beznea Link: https://patch.msgid.link/20260316133252.240348-3-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 2b2518b1abb3cbd0e3bef7a06284ac4b3b086147 Author: Claudiu Beznea Date: Mon Mar 16 15:32:45 2026 +0200 dmaengine: sh: rz-dmac: Protect the driver specific lists commit abb863e6213dc41a58ef8bb3289b7e77460dabf3 upstream. The driver lists (ld_free, ld_queue) are used in rz_dmac_free_chan_resources(), rz_dmac_terminate_all(), rz_dmac_issue_pending(), and rz_dmac_irq_handler_thread(), all under the virtual channel lock. Take the same lock in rz_dmac_prep_slave_sg() and rz_dmac_prep_dma_memcpy() as well to avoid concurrency issues, since these functions also check whether the lists are empty and update or remove list entries. Fixes: 5000d37042a6 ("dmaengine: sh: Add DMAC driver for RZ/G2L SoC") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Signed-off-by: Claudiu Beznea Link: https://patch.msgid.link/20260316133252.240348-2-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 79d2151a7c3002eba0121664cdd418c19b26c137 Author: Joy Zou Date: Wed Sep 17 17:53:42 2025 +0800 dmaengine: fsl-edma: fix channel parameter config for fixed channel requests commit 2e7b5cf72e51c9cf9c8b75190189c757df31ddd9 upstream. Configure only the requested channel when a fixed channel is specified to avoid modifying other channels unintentionally. Fix parameter configuration when a fixed DMA channel is requested on i.MX9 AON domain and i.MX8QM/QXP/DXL platforms. When a client requests a fixed channel (e.g., channel 6), the driver traverses channels 0-5 and may unintentionally modify their configuration if they are unused. This leads to issues such as setting the `is_multi_fifo` flag unexpectedly, causing memcpy tests to fail when using the dmatest tool. Only affect edma memcpy test when the channel is fixed. Fixes: 72f5801a4e2b ("dmaengine: fsl-edma: integrate v3 support") Signed-off-by: Joy Zou Cc: stable@vger.kernel.org Reviewed-by: Frank Li Link: https://patch.msgid.link/20250917-b4-edma-chanconf-v1-1-886486e02e91@nxp.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 20768be1734c0943b0c1ce6d7c9c7b8fa41ee3ad Author: Stefan Eichenberger Date: Wed Feb 18 16:08:50 2026 +0100 i2c: imx: ensure no clock is generated after last read commit 13101db735bdb29c5f60e95fb578690bd178b30f upstream. When reading from the I2DR register, right after releasing the bus by clearing MSTA and MTX, the I2C controller might still generate an additional clock cycle which can cause devices to misbehave. Ensure to only read from I2DR after the bus is not busy anymore. Because this requires polling, the read of the last byte is moved outside of the interrupt handler. An example for such a failing transfer is this: i2ctransfer -y -a 0 w1@0x00 0x02 r1 Error: Sending messages failed: Connection timed out It does not happen with every device because not all devices react to the additional clock cycle. Fixes: 5f5c2d4579ca ("i2c: imx: prevent rescheduling in non dma mode") Cc: stable@vger.kernel.org # v6.13+ Signed-off-by: Stefan Eichenberger Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260218150940.131354-3-eichest@gmail.com Signed-off-by: Greg Kroah-Hartman commit dca0e38ecfd0bf18013387f60273e525412ba475 Author: Stefan Eichenberger Date: Wed Feb 18 16:08:49 2026 +0100 i2c: imx: fix i2c issue when reading multiple messages commit f88e2e748a1fc3cb4b8d163a9be790812f578850 upstream. When reading multiple messages, meaning a repeated start is required, polling the bus busy bit must be avoided. This must only be done for the last message. Otherwise, the driver will timeout. Here an example of such a sequence that fails with an error: i2ctransfer -y -a 0 w1@0x00 0x02 r1 w1@0x00 0x02 r1 Error: Sending messages failed: Connection timed out Fixes: 5f5c2d4579ca ("i2c: imx: prevent rescheduling in non dma mode") Cc: stable@vger.kernel.org # v6.13+ Signed-off-by: Stefan Eichenberger Reviewed-by: Frank Li Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260218150940.131354-2-eichest@gmail.com Signed-off-by: Greg Kroah-Hartman commit 92e47ad03e03dbb5515bdf06444bf6b1e147310d Author: Davidlohr Bueso Date: Wed Mar 25 17:17:59 2026 -0700 futex: Clear stale exiting pointer in futex_lock_pi() retry path commit 210d36d892de5195e6766c45519dfb1e65f3eb83 upstream. Fuzzying/stressing futexes triggered: WARNING: kernel/futex/core.c:825 at wait_for_owner_exiting+0x7a/0x80, CPU#11: futex_lock_pi_s/524 When futex_lock_pi_atomic() sees the owner is exiting, it returns -EBUSY and stores a refcounted task pointer in 'exiting'. After wait_for_owner_exiting() consumes that reference, the local pointer is never reset to nil. Upon a retry, if futex_lock_pi_atomic() returns a different error, the bogus pointer is passed to wait_for_owner_exiting(). CPU0 CPU1 CPU2 futex_lock_pi(uaddr) // acquires the PI futex exit() futex_cleanup_begin() futex_state = EXITING; futex_lock_pi(uaddr) futex_lock_pi_atomic() attach_to_pi_owner() // observes EXITING *exiting = owner; // takes ref return -EBUSY wait_for_owner_exiting(-EBUSY, owner) put_task_struct(); // drops ref // exiting still points to owner goto retry; futex_lock_pi_atomic() lock_pi_update_atomic() cmpxchg(uaddr) *uaddr ^= WAITERS // whatever // value changed return -EAGAIN; wait_for_owner_exiting(-EAGAIN, exiting) // stale WARN_ON_ONCE(exiting) Fix this by resetting upon retry, essentially aligning it with requeue_pi. Fixes: 3ef240eaff36 ("futex: Prevent exit livelock") Signed-off-by: Davidlohr Bueso Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260326001759.4129680-1-dave@stgolabs.net Signed-off-by: Greg Kroah-Hartman commit 83bcea9da91965484df64a6492b89e65d41ab31c Author: Pratap Nirujogi Date: Fri Mar 20 16:12:22 2026 -0400 i2c: designware: amdisp: Fix resume-probe race condition issue commit e2f1ada8e089dd5a331bcd8b88125ae2af8d188f upstream. Identified resume-probe race condition in kernel v7.0 with the commit 38fa29b01a6a ("i2c: designware: Combine the init functions"),but this issue existed from the beginning though not detected. The amdisp i2c device requires ISP to be in power-on state for probe to succeed. To meet this requirement, this device is added to genpd to control ISP power using runtime PM. The pm_runtime_get_sync() called before i2c_dw_probe() triggers PM resume, which powers on ISP and also invokes the amdisp i2c runtime resume before the probe completes resulting in this race condition and a NULL dereferencing issue in v7.0 Fix this race condition by using the genpd APIs directly during probe: - Call dev_pm_genpd_resume() to Power ON ISP before probe - Call dev_pm_genpd_suspend() to Power OFF ISP after probe - Set the device to suspended state with pm_runtime_set_suspended() - Enable runtime PM only after the device is fully initialized Fixes: d6263c468a761 ("i2c: amd-isp: Add ISP i2c-designware driver") Co-developed-by: Bin Du Signed-off-by: Bin Du Signed-off-by: Pratap Nirujogi Cc: # v6.16+ Acked-by: Mika Westerberg Reviewed-by: Mario Limonciello (AMD) Reviewed-by: Andy Shevchenko Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260320201302.3490570-1-pratap.nirujogi@amd.com Signed-off-by: Greg Kroah-Hartman commit 7319d57db908f218ff4bf0e5c23d2b415310d0c6 Author: Jassi Brar Date: Sun Mar 22 12:15:33 2026 -0500 irqchip/qcom-mpm: Add missing mailbox TX done acknowledgment commit cfe02147e86307a17057ee4e3604f5f5919571d2 upstream. The mbox_client for qcom-mpm sends NULL doorbell messages via mbox_send_message() but never signals TX completion. Set knows_txdone=true and call mbox_client_txdone() after a successful send, matching the pattern used by other Qualcomm mailbox clients (smp2p, smsm, qcom_aoss etc). Fixes: a6199bb514d8a6 "irqchip: Add Qualcomm MPM controller driver" Signed-off-by: Jassi Brar Signed-off-by: Thomas Gleixner Reviewed-by: Douglas Anderson Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260322171533.608436-1-jassisinghbrar@gmail.com Signed-off-by: Greg Kroah-Hartman commit 1d896b40864651ff40139941d50e399beae7956d Author: Milos Nikic Date: Tue Mar 10 21:15:48 2026 -0700 jbd2: gracefully abort on checkpointing state corruptions commit bac3190a8e79beff6ed221975e0c9b1b5f2a21da upstream. This patch targets two internal state machine invariants in checkpoint.c residing inside functions that natively return integer error codes. - In jbd2_cleanup_journal_tail(): A blocknr of 0 indicates a severely corrupted journal superblock. Replaced the J_ASSERT with a WARN_ON_ONCE and a graceful journal abort, returning -EFSCORRUPTED. - In jbd2_log_do_checkpoint(): Replaced the J_ASSERT_BH checking for an unexpected buffer_jwrite state. If the warning triggers, we explicitly drop the just-taken get_bh() reference and call __flush_batch() to safely clean up any previously queued buffers in the j_chkpt_bhs array, preventing a memory leak before returning -EFSCORRUPTED. Signed-off-by: Milos Nikic Reviewed-by: Andreas Dilger Reviewed-by: Zhang Yi Reviewed-by: Baokun Li Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260311041548.159424-1-nikic.milos@gmail.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit bab090e8fd5607f77379ea78b9d0c683cb1538a9 Author: Sean Christopherson Date: Thu Mar 5 17:42:14 2026 -0800 KVM: x86/mmu: Only WARN in direct MMUs when overwriting shadow-present SPTE commit df83746075778958954aa0460cca55f4b3fc9c02 upstream. Adjust KVM's sanity check against overwriting a shadow-present SPTE with a another SPTE with a different target PFN to only apply to direct MMUs, i.e. only to MMUs without shadowed gPTEs. While it's impossible for KVM to overwrite a shadow-present SPTE in response to a guest write, writes from outside the scope of KVM, e.g. from host userspace, aren't detected by KVM's write tracking and so can break KVM's shadow paging rules. ------------[ cut here ]------------ pfn != spte_to_pfn(*sptep) WARNING: arch/x86/kvm/mmu/mmu.c:3069 at mmu_set_spte+0x1e4/0x440 [kvm], CPU#0: vmx_ept_stale_r/872 Modules linked in: kvm_intel kvm irqbypass CPU: 0 UID: 1000 PID: 872 Comm: vmx_ept_stale_r Not tainted 7.0.0-rc2-eafebd2d2ab0-sink-vm #319 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:mmu_set_spte+0x1e4/0x440 [kvm] Call Trace: ept_page_fault+0x535/0x7f0 [kvm] kvm_mmu_do_page_fault+0xee/0x1f0 [kvm] kvm_mmu_page_fault+0x8d/0x620 [kvm] vmx_handle_exit+0x18c/0x5a0 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc55/0x1c20 [kvm] kvm_vcpu_ioctl+0x2d5/0x980 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb5/0x730 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---[ end trace 0000000000000000 ]--- Fixes: 11d45175111d ("KVM: x86/mmu: Warn if PFN changes on shadow-present SPTE in shadow MMU") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 695320de6eadb75aaed8be1787c4ce4c189e4c7b Author: Sean Christopherson Date: Thu Mar 5 17:28:04 2026 -0800 KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE commit aad885e774966e97b675dfe928da164214a71605 upstream. When installing an emulated MMIO SPTE, do so *after* dropping/zapping the existing SPTE (if it's shadow-present). While commit a54aa15c6bda3 was right about it being impossible to convert a shadow-present SPTE to an MMIO SPTE due to a _guest_ write, it failed to account for writes to guest memory that are outside the scope of KVM. E.g. if host userspace modifies a shadowed gPTE to switch from a memslot to emulted MMIO and then the guest hits a relevant page fault, KVM will install the MMIO SPTE without first zapping the shadow-present SPTE. ------------[ cut here ]------------ is_shadow_present_pte(*sptep) WARNING: arch/x86/kvm/mmu/mmu.c:484 at mark_mmio_spte+0xb2/0xc0 [kvm], CPU#0: vmx_ept_stale_r/4292 Modules linked in: kvm_intel kvm irqbypass CPU: 0 UID: 1000 PID: 4292 Comm: vmx_ept_stale_r Not tainted 7.0.0-rc2-eafebd2d2ab0-sink-vm #319 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:mark_mmio_spte+0xb2/0xc0 [kvm] Call Trace: mmu_set_spte+0x237/0x440 [kvm] ept_page_fault+0x535/0x7f0 [kvm] kvm_mmu_do_page_fault+0xee/0x1f0 [kvm] kvm_mmu_page_fault+0x8d/0x620 [kvm] vmx_handle_exit+0x18c/0x5a0 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc55/0x1c20 [kvm] kvm_vcpu_ioctl+0x2d5/0x980 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb5/0x730 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x47fa3f ---[ end trace 0000000000000000 ]--- Reported-by: Alexander Bulekov Debugged-by: Alexander Bulekov Suggested-by: Fred Griffoul Fixes: a54aa15c6bda3 ("KVM: x86/mmu: Handle MMIO SPTEs directly in mmu_set_spte()") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit f4bc91398b579730284328322365afa77a9d568f Author: Kevin Hao Date: Sat Mar 21 22:04:41 2026 +0800 net: macb: Use dev_consume_skb_any() to free TX SKBs commit 647b8a2fe474474704110db6bd07f7a139e621eb upstream. The napi_consume_skb() function is not intended to be called in an IRQ disabled context. However, after commit 6bc8a5098bf4 ("net: macb: Fix tx_ptr_lock locking"), the freeing of TX SKBs is performed with IRQs disabled. To resolve the following call trace, use dev_consume_skb_any() for freeing TX SKBs: WARNING: kernel/softirq.c:430 at __local_bh_enable_ip+0x174/0x188, CPU#0: ksoftirqd/0/15 Modules linked in: CPU: 0 UID: 0 PID: 15 Comm: ksoftirqd/0 Not tainted 7.0.0-rc4-next-20260319-yocto-standard-dirty #37 PREEMPT Hardware name: ZynqMP ZCU102 Rev1.1 (DT) pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __local_bh_enable_ip+0x174/0x188 lr : local_bh_enable+0x24/0x38 sp : ffff800082b3bb10 x29: ffff800082b3bb10 x28: ffff0008031f3c00 x27: 000000000011ede0 x26: ffff000800a7ff00 x25: ffff800083937ce8 x24: 0000000000017a80 x23: ffff000803243a78 x22: 0000000000000040 x21: 0000000000000000 x20: ffff000800394c80 x19: 0000000000000200 x18: 0000000000000001 x17: 0000000000000001 x16: ffff000803240000 x15: 0000000000000000 x14: ffffffffffffffff x13: 0000000000000028 x12: ffff000800395650 x11: ffff8000821d1528 x10: ffff800081c2bc08 x9 : ffff800081c1e258 x8 : 0000000100000301 x7 : ffff8000810426ec x6 : 0000000000000000 x5 : 0000000000000001 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000008 x1 : 0000000000000200 x0 : ffff8000810428dc Call trace: __local_bh_enable_ip+0x174/0x188 (P) local_bh_enable+0x24/0x38 skb_attempt_defer_free+0x190/0x1d8 napi_consume_skb+0x58/0x108 macb_tx_poll+0x1a4/0x558 __napi_poll+0x50/0x198 net_rx_action+0x1f4/0x3d8 handle_softirqs+0x16c/0x560 run_ksoftirqd+0x44/0x80 smpboot_thread_fn+0x1d8/0x338 kthread+0x120/0x150 ret_from_fork+0x10/0x20 irq event stamp: 29751 hardirqs last enabled at (29750): [] _raw_spin_unlock_irqrestore+0x44/0x88 hardirqs last disabled at (29751): [] _raw_spin_lock_irqsave+0x38/0x98 softirqs last enabled at (29150): [] handle_softirqs+0x504/0x560 softirqs last disabled at (29153): [] run_ksoftirqd+0x44/0x80 Fixes: 6bc8a5098bf4 ("net: macb: Fix tx_ptr_lock locking") Signed-off-by: Kevin Hao Cc: stable@vger.kernel.org Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260321-macb-tx-v1-1-b383a58dd4e6@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 33eeb5471a8bafd86c19e2bdb6c0b9775420aeb5 Author: Kevin Hao Date: Wed Mar 18 14:36:59 2026 +0800 net: macb: Protect access to net_device::ip_ptr with RCU lock commit baa35a698cea26930679a20a7550bbb4c8319725 upstream. Access to net_device::ip_ptr and its associated members must be protected by an RCU lock. Since we are modifying this piece of code, let's also move it to execute only when WAKE_ARP is enabled. To minimize the duration of the RCU lock, a local variable is used to temporarily store the IP address. This change resolves the following RCU check warning: WARNING: suspicious RCU usage 7.0.0-rc3-next-20260310-yocto-standard+ #122 Not tainted ----------------------------- drivers/net/ethernet/cadence/macb_main.c:5944 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 5 locks held by rtcwake/518: #0: ffff000803ab1408 (sb_writers#5){.+.+}-{0:0}, at: vfs_write+0xf8/0x368 #1: ffff0008090bf088 (&of->mutex#2){+.+.}-{4:4}, at: kernfs_fop_write_iter+0xbc/0x1c8 #2: ffff00080098d588 (kn->active#70){.+.+}-{0:0}, at: kernfs_fop_write_iter+0xcc/0x1c8 #3: ffff800081c84888 (system_transition_mutex){+.+.}-{4:4}, at: pm_suspend+0x1ec/0x290 #4: ffff0008009ba0f8 (&dev->mutex){....}-{4:4}, at: device_suspend+0x118/0x4f0 stack backtrace: CPU: 3 UID: 0 PID: 518 Comm: rtcwake Not tainted 7.0.0-rc3-next-20260310-yocto-standard+ #122 PREEMPT Hardware name: ZynqMP ZCU102 Rev1.1 (DT) Call trace: show_stack+0x24/0x38 (C) __dump_stack+0x28/0x38 dump_stack_lvl+0x64/0x88 dump_stack+0x18/0x24 lockdep_rcu_suspicious+0x134/0x1d8 macb_suspend+0xd8/0x4c0 device_suspend+0x218/0x4f0 dpm_suspend+0x244/0x3a0 dpm_suspend_start+0x50/0x78 suspend_devices_and_enter+0xec/0x560 pm_suspend+0x194/0x290 state_store+0x110/0x158 kobj_attr_store+0x1c/0x30 sysfs_kf_write+0xa8/0xd0 kernfs_fop_write_iter+0x11c/0x1c8 vfs_write+0x248/0x368 ksys_write+0x7c/0xf8 __arm64_sys_write+0x28/0x40 invoke_syscall+0x4c/0xe8 el0_svc_common+0x98/0xf0 do_el0_svc+0x28/0x40 el0_svc+0x54/0x1e0 el0t_64_sync_handler+0x84/0x130 el0t_64_sync+0x198/0x1a0 Fixes: 0cb8de39a776 ("net: macb: Add ARP support to WOL") Signed-off-by: Kevin Hao Cc: stable@vger.kernel.org Reviewed-by: Théo Lebrun Link: https://patch.msgid.link/20260318-macb-irq-v2-2-f1179768ab24@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 99405131d6edd0a09633f3d1c7f56424b3a60617 Author: Kevin Hao Date: Wed Mar 18 14:36:58 2026 +0800 net: macb: Move devm_{free,request}_irq() out of spin lock area commit 317e49358ebbf6390fa439ef3c142f9239dd25fb upstream. The devm_free_irq() and devm_request_irq() functions should not be executed in an atomic context. During device suspend, all userspace processes and most kernel threads are frozen. Additionally, we flush all tx/rx status, disable all macb interrupts, and halt rx operations. Therefore, it is safe to split the region protected by bp->lock into two independent sections, allowing devm_free_irq() and devm_request_irq() to run in a non-atomic context. This modification resolves the following lockdep warning: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 501, name: rtcwake preempt_count: 1, expected: 0 RCU nest depth: 1, expected: 0 7 locks held by rtcwake/501: #0: ffff0008038c3408 (sb_writers#5){.+.+}-{0:0}, at: vfs_write+0xf8/0x368 #1: ffff0008049a5e88 (&of->mutex#2){+.+.}-{4:4}, at: kernfs_fop_write_iter+0xbc/0x1c8 #2: ffff00080098d588 (kn->active#70){.+.+}-{0:0}, at: kernfs_fop_write_iter+0xcc/0x1c8 #3: ffff800081c84888 (system_transition_mutex){+.+.}-{4:4}, at: pm_suspend+0x1ec/0x290 #4: ffff0008009ba0f8 (&dev->mutex){....}-{4:4}, at: device_suspend+0x118/0x4f0 #5: ffff800081d00458 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire+0x4/0x48 #6: ffff0008031fb9e0 (&bp->lock){-.-.}-{3:3}, at: macb_suspend+0x144/0x558 irq event stamp: 8682 hardirqs last enabled at (8681): [] _raw_spin_unlock_irqrestore+0x44/0x88 hardirqs last disabled at (8682): [] _raw_spin_lock_irqsave+0x38/0x98 softirqs last enabled at (7322): [] handle_softirqs+0x52c/0x588 softirqs last disabled at (7317): [] __do_softirq+0x20/0x2c CPU: 1 UID: 0 PID: 501 Comm: rtcwake Not tainted 7.0.0-rc3-next-20260310-yocto-standard+ #125 PREEMPT Hardware name: ZynqMP ZCU102 Rev1.1 (DT) Call trace: show_stack+0x24/0x38 (C) __dump_stack+0x28/0x38 dump_stack_lvl+0x64/0x88 dump_stack+0x18/0x24 __might_resched+0x200/0x218 __might_sleep+0x38/0x98 __mutex_lock_common+0x7c/0x1378 mutex_lock_nested+0x38/0x50 free_irq+0x68/0x2b0 devm_irq_release+0x24/0x38 devres_release+0x40/0x80 devm_free_irq+0x48/0x88 macb_suspend+0x298/0x558 device_suspend+0x218/0x4f0 dpm_suspend+0x244/0x3a0 dpm_suspend_start+0x50/0x78 suspend_devices_and_enter+0xec/0x560 pm_suspend+0x194/0x290 state_store+0x110/0x158 kobj_attr_store+0x1c/0x30 sysfs_kf_write+0xa8/0xd0 kernfs_fop_write_iter+0x11c/0x1c8 vfs_write+0x248/0x368 ksys_write+0x7c/0xf8 __arm64_sys_write+0x28/0x40 invoke_syscall+0x4c/0xe8 el0_svc_common+0x98/0xf0 do_el0_svc+0x28/0x40 el0_svc+0x54/0x1e0 el0t_64_sync_handler+0x84/0x130 el0t_64_sync+0x198/0x1a0 Fixes: 558e35ccfe95 ("net: macb: WoL support for GEM type of Ethernet controller") Cc: stable@vger.kernel.org Reviewed-by: Théo Lebrun Signed-off-by: Kevin Hao Link: https://patch.msgid.link/20260318-macb-irq-v2-1-f1179768ab24@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4771b85954be5bf850e4fc1fd8ea19d8b6f19c01 Author: Greg Kroah-Hartman Date: Mon Feb 23 16:44:59 2026 +0100 scsi: ses: Handle positive SCSI error from ses_recv_diag() commit 7a9f448d44127217fabc4065c5ba070d4e0b5d37 upstream. ses_recv_diag() can return a positive value, which also means that an error happened, so do not only test for negative values. Cc: James E.J. Bottomley Cc: Martin K. Petersen Cc: stable Assisted-by: gkh_clanker_2000 Signed-off-by: Greg Kroah-Hartman Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/2026022301-bony-overstock-a07f@gregkh Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 786f10b1966e485046839f992e89f2c18cbd1983 Author: Tyllis Xu Date: Sat Mar 14 12:01:50 2026 -0500 scsi: ibmvfc: Fix OOB access in ibmvfc_discover_targets_done() commit 61d099ac4a7a8fb11ebdb6e2ec8d77f38e77362f upstream. A malicious or compromised VIO server can return a num_written value in the discover targets MAD response that exceeds max_targets. This value is stored directly in vhost->num_targets without validation, and is then used as the loop bound in ibmvfc_alloc_targets() to index into disc_buf[], which is only allocated for max_targets entries. Indices at or beyond max_targets access kernel memory outside the DMA-coherent allocation. The out-of-bounds data is subsequently embedded in Implicit Logout and PLOGI MADs that are sent back to the VIO server, leaking kernel memory. Fix by clamping num_written to max_targets before storing it. Fixes: 072b91f9c651 ("[SCSI] ibmvfc: IBM Power Virtual Fibre Channel Adapter Client Driver") Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Tyllis Xu Reviewed-by: Dave Marquardt Acked-by: Tyrel Datwyler Link: https://patch.msgid.link/20260314170151.548614-1-LivelyCarpet87@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit e02685511282e3e65a0889cfc1b44dd76bb406cc Author: Amir Goldstein Date: Sun Mar 8 12:02:21 2026 +0100 ovl: fix wrong detection of 32bit inode numbers commit 53a7c171e9dd833f0a96b545adcb89bd57387239 upstream. The implicit FILEID_INO32_GEN encoder was changed to be explicit, so we need to fix the detection. When mounting overlayfs with upperdir and lowerdir on different ext4 filesystems, the expected kmsg log is: overlayfs: "xino" feature enabled using 32 upper inode bits. But instead, since the regressing commit, the kmsg log was: overlayfs: "xino" feature enabled using 2 upper inode bits. Fixes: e21fc2038c1b9 ("exportfs: make ->encode_fh() a mandatory method for NFS export") Cc: stable@vger.kernel.org # v6.7+ Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit ebbac99bb66621da236edbc881c32d8725e101c2 Author: Fei Lv Date: Mon Jul 22 18:14:43 2024 +0800 ovl: make fsync after metadata copy-up opt-in mount option commit 1f6ee9be92f8df85a8c9a5a78c20fd39c0c21a95 upstream. Commit 7d6899fb69d25 ("ovl: fsync after metadata copy-up") was done to fix durability of overlayfs copy up on an upper filesystem which does not enforce ordering on storing of metadata changes (e.g. ubifs). In an earlier revision of the regressing commit by Lei Lv, the metadata fsync behavior was opt-in via a new "fsync=strict" mount option. We were hoping that the opt-in mount option could be avoided, so the change was only made to depend on metacopy=off, in the hope of not hurting performance of metadata heavy workloads, which are more likely to be using metacopy=on. This hope was proven wrong by a performance regression report from Google COS workload after upgrade to kernel 6.12. This is an adaptation of Lei's original "fsync=strict" mount option to the existing upstream code. The new mount option is mutually exclusive with the "volatile" mount option, so the latter is now an alias to the "fsync=volatile" mount option. Reported-by: Chenglong Tang Closes: https://lore.kernel.org/linux-unionfs/CAOdxtTadAFH01Vui1FvWfcmQ8jH1O45owTzUcpYbNvBxnLeM7Q@mail.gmail.com/ Link: https://lore.kernel.org/linux-unionfs/CAOQ4uxgKC1SgjMWre=fUb00v8rxtd6sQi-S+dxR8oDzAuiGu8g@mail.gmail.com/ Fixes: 7d6899fb69d25 ("ovl: fsync after metadata copy-up") Depends: 50e638beb67e0 ("ovl: Use str_on_off() helper in ovl_show_options()") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Fei Lv Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit db08e8c32090a4fb156caec9cacd79be0e8a579d Author: Abel Vesa Date: Thu Feb 19 13:11:48 2026 +0200 phy: qcom: qmp-ufs: Fix SM8650 PCS table for Gear 4 commit 81af9e40e2e4e1aa95f09fb34811760be6742c58 upstream. According to internal documentation, on SM8650, when the PHY is configured in Gear 4, the QPHY_V6_PCS_UFS_PLL_CNTL register needs to have the same value as for Gear 5. At the moment, there is no board that comes with a UFS 3.x device, so this issue doesn't show up, but with the new Eliza SoC, which uses the same init sequence as SM8650, on the MTP board, the link startup fails with the current Gear 4 PCS table. So fix that by moving the entry into the PCS generic table instead, while keeping the value from Gear 5 configuration. Cc: stable@vger.kernel.org # v6.10 Fixes: b9251e64a96f ("phy: qcom: qmp-ufs: update SM8650 tables for Gear 4 & 5") Suggested-by: Nitin Rawat Signed-off-by: Abel Vesa Reviewed-by: Konrad Dybcio Reviewed-by: Neil Armstrong Tested-by: Neil Armstrong # on SM8650-HDK Link: https://patch.msgid.link/20260219-phy-qcom-qmp-ufs-fix-sm8650-pcs-g4-table-v1-1-f136505b57f6@oss.qualcomm.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 4cce3cd5ed79fc604541fc3bbddccd63b0ef60a1 Author: Nikunj A Dadhania Date: Wed Mar 18 07:56:54 2026 +0000 x86/fred: Fix early boot failures on SEV-ES/SNP guests commit 3645eb7e3915990a149460c151a00894cb586253 upstream. FRED-enabled SEV-(ES,SNP) guests fail to boot due to the following issues in the early boot sequence: * FRED does not have a #VC exception handler in the dispatch logic * Early FRED #VC exceptions attempt to use uninitialized per-CPU GHCBs instead of boot_ghcb Add X86_TRAP_VC case to fred_hwexc() with a new exc_vmm_communication() function that provides the unified entry point FRED requires, dispatching to existing user/kernel handlers based on privilege level. The function is already declared via DECLARE_IDTENTRY_VC(). Fix early GHCB access by falling back to boot_ghcb in __sev_{get,put}_ghcb() when per-CPU GHCBs are not yet initialized. Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code") Signed-off-by: Nikunj A Dadhania Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Tom Lendacky Cc: # 6.12+ Link: https://patch.msgid.link/20260318075654.1792916-4-nikunj@amd.com Signed-off-by: Greg Kroah-Hartman commit a6e14114684d2324e5401617d6d01acb4a4e0e22 Author: Borislav Petkov (AMD) Date: Thu Mar 19 12:07:59 2026 +0100 x86/cpu: Remove X86_CR4_FRED from the CR4 pinned bits mask commit 411df123c017169922cc767affce76282b8e6c85 upstream. Commit in Fixes added the FRED CR4 bit to the CR4 pinned bits mask so that whenever something else modifies CR4, that bit remains set. Which in itself is a perfectly fine idea. However, there's an issue when during boot FRED is initialized: first on the BSP and later on the APs. Thus, there's a window in time when exceptions cannot be handled. This becomes particularly nasty when running as SEV-{ES,SNP} or TDX guests which, when they manage to trigger exceptions during that short window described above, triple fault due to FRED MSRs not being set up yet. See Link tag below for a much more detailed explanation of the situation. So, as a result, the commit in that Link URL tried to address this shortcoming by temporarily disabling CR4 pinning when an AP is not online yet. However, that is a problem in itself because in this case, an attack on the kernel needs to only modify the online bit - a single bit in RW memory - and then disable CR4 pinning and then disable SM*P, leading to more and worse things to happen to the system. So, instead, remove the FRED bit from the CR4 pinning mask, thus obviating the need to temporarily disable CR4 pinning. If someone manages to disable FRED when poking at CR4, then idt_invalidate() would make sure the system would crash'n'burn on the first exception triggered, which is a much better outcome security-wise. Fixes: ff45746fbf00 ("x86/cpu: Add X86_CR4_FRED macro") Suggested-by: Dave Hansen Suggested-by: Peter Zijlstra Signed-off-by: Borislav Petkov (AMD) Cc: # 6.12+ Link: https://lore.kernel.org/r/177385987098.1647592.3381141860481415647.tip-bot2@tip-bot2 Signed-off-by: Greg Kroah-Hartman commit 5433c7ac4bc8eb0ca9a51f14559d0aa153fc46be Author: Nikunj A Dadhania Date: Wed Mar 18 07:56:52 2026 +0000 x86/cpu: Enable FSGSBASE early in cpu_init_exception_handling() commit 05243d490bb7852a8acca7b5b5658019c7797a52 upstream. Move FSGSBASE enablement from identify_cpu() to cpu_init_exception_handling() to ensure it is enabled before any exceptions can occur on both boot and secondary CPUs. == Background == Exception entry code (paranoid_entry()) uses ALTERNATIVE patching based on X86_FEATURE_FSGSBASE to decide whether to use RDGSBASE/WRGSBASE instructions or the slower RDMSR/SWAPGS sequence for saving/restoring GSBASE. On boot CPU, ALTERNATIVE patching happens after enabling FSGSBASE in CR4. When the feature is available, the code is permanently patched to use RDGSBASE/WRGSBASE, which require CR4.FSGSBASE=1 to execute without triggering == Boot Sequence == Boot CPU (with CR pinning enabled): trap_init() cpu_init() <- Uses unpatched code (RDMSR/SWAPGS) x2apic_setup() ... arch_cpu_finalize_init() identify_boot_cpu() identify_cpu() cr4_set_bits(X86_CR4_FSGSBASE) # Enables the feature # This becomes part of cr4_pinned_bits ... alternative_instructions() <- Patches code to use RDGSBASE/WRGSBASE Secondary CPUs (with CR pinning enabled): start_secondary() cr4_init() <- Code already patched, CR4.FSGSBASE=1 set implicitly via cr4_pinned_bits cpu_init() <- exceptions work because FSGSBASE is already enabled Secondary CPU (with CR pinning disabled): start_secondary() cr4_init() <- Code already patched, CR4.FSGSBASE=0 cpu_init() x2apic_setup() rdmsrq(MSR_IA32_APICBASE) <- Triggers #VC in SNP guests exc_vmm_communication() paranoid_entry() <- Uses RDGSBASE with CR4.FSGSBASE=0 (patched code) ... ap_starting() identify_secondary_cpu() identify_cpu() cr4_set_bits(X86_CR4_FSGSBASE) <- Enables the feature, which is too late == CR Pinning == Currently, for secondary CPUs, CR4.FSGSBASE is set implicitly through CR-pinning: the boot CPU sets it during identify_cpu(), it becomes part of cr4_pinned_bits, and cr4_init() applies those pinned bits to secondary CPUs. This works but creates an undocumented dependency between cr4_init() and the pinning mechanism. == Problem == Secondary CPUs boot after alternatives have been applied globally. They execute already-patched paranoid_entry() code that uses RDGSBASE/WRGSBASE instructions, which require CR4.FSGSBASE=1. Upcoming changes to CR pinning behavior will break the implicit dependency, causing secondary CPUs to generate #UD. This issue manifests itself on AMD SEV-SNP guests, where the rdmsrq() in x2apic_setup() triggers a #VC exception early during cpu_init(). The #VC handler (exc_vmm_communication()) executes the patched paranoid_entry() path. Without CR4.FSGSBASE enabled, RDGSBASE instructions trigger #UD. == Fix == Enable FSGSBASE explicitly in cpu_init_exception_handling() before loading exception handlers. This makes the dependency explicit and ensures both boot and secondary CPUs have FSGSBASE enabled before paranoid_entry() executes. Fixes: c82965f9e530 ("x86/entry/64: Handle FSGSBASE enabled paranoid entry/exit") Reported-by: Borislav Petkov Suggested-by: Sohil Mehta Signed-off-by: Nikunj A Dadhania Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Sohil Mehta Cc: Link: https://patch.msgid.link/20260318075654.1792916-2-nikunj@amd.com Signed-off-by: Greg Kroah-Hartman commit 83800f8ef358ea2fc9b1ae4986b83f2bc24be927 Author: Joanne Koong Date: Thu Mar 19 17:51:45 2026 -0700 writeback: don't block sync for filesystems with no data integrity guarantees commit 76f9377cd2ab7a9220c25d33940d9ca20d368172 upstream. Add a SB_I_NO_DATA_INTEGRITY superblock flag for filesystems that cannot guarantee data persistence on sync (eg fuse). For superblocks with this flag set, sync kicks off writeback of dirty inodes but does not wait for the flusher threads to complete the writeback. This replaces the per-inode AS_NO_DATA_INTEGRITY mapping flag added in commit f9a49aa302a0 ("fs/writeback: skip AS_NO_DATA_INTEGRITY mappings in wait_sb_inodes()"). The flag belongs at the superblock level because data integrity is a filesystem-wide property, not a per-inode one. Having this flag at the superblock level also allows us to skip having to iterate every dirty inode in wait_sb_inodes() only to skip each inode individually. Prior to this commit, mappings with no data integrity guarantees skipped waiting on writeback completion but still waited on the flusher threads to finish initiating the writeback. Waiting on the flusher threads is unnecessary. This commit kicks off writeback but does not wait on the flusher threads. This change properly addresses a recent report [1] for a suspend-to-RAM hang seen on fuse-overlayfs that was caused by waiting on the flusher threads to finish: Workqueue: pm_fs_sync pm_fs_sync_work_fn Call Trace: __schedule+0x457/0x1720 schedule+0x27/0xd0 wb_wait_for_completion+0x97/0xe0 sync_inodes_sb+0xf8/0x2e0 __iterate_supers+0xdc/0x160 ksys_sync+0x43/0xb0 pm_fs_sync_work_fn+0x17/0xa0 process_one_work+0x193/0x350 worker_thread+0x1a1/0x310 kthread+0xfc/0x240 ret_from_fork+0x243/0x280 ret_from_fork_asm+0x1a/0x30 On fuse this is problematic because there are paths that may cause the flusher thread to block (eg if systemd freezes the user session cgroups first, which freezes the fuse daemon, before invoking the kernel suspend. The kernel suspend triggers ->write_node() which on fuse issues a synchronous setattr request, which cannot be processed since the daemon is frozen. Or if the daemon is buggy and cannot properly complete writeback, initiating writeback on a dirty folio already under writeback leads to writeback_get_folio() -> folio_prepare_writeback() -> unconditional wait on writeback to finish, which will cause a hang). This commit restores fuse to its prior behavior before tmp folios were removed, where sync was essentially a no-op. [1] https://lore.kernel.org/linux-fsdevel/CAJnrk1a-asuvfrbKXbEwwDSctvemF+6zfhdnuzO65Pt8HsFSRw@mail.gmail.com/T/#m632c4648e9cafc4239299887109ebd880ac6c5c1 Fixes: 0c58a97f919c ("fuse: remove tmp folio for writebacks and internal rb tree") Reported-by: John Cc: stable@vger.kernel.org Signed-off-by: Joanne Koong Link: https://patch.msgid.link/20260320005145.2483161-2-joannelkoong@gmail.com Reviewed-by: Jan Kara Reviewed-by: David Hildenbrand (Arm) Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit e54c8863ba33e68efc594e2ca389f475b003c871 Author: Zhan Xusheng Date: Mon Mar 23 14:11:30 2026 +0800 alarmtimer: Fix argument order in alarm_timer_forward() commit 5d16467ae56343b9205caedf85e3a131e0914ad8 upstream. alarm_timer_forward() passes arguments to alarm_forward() in the wrong order: alarm_forward(alarm, timr->it_interval, now); However, alarm_forward() is defined as: u64 alarm_forward(struct alarm *alarm, ktime_t now, ktime_t interval); and uses the second argument as the current time: delta = ktime_sub(now, alarm->node.expires); Passing the interval as "now" results in incorrect delta computation, which can lead to missed expirations or incorrect overrun accounting. This issue has been present since the introduction of alarm_timer_forward(). Fix this by swapping the arguments. Fixes: e7561f1633ac ("alarmtimer: Implement forward callback") Signed-off-by: Zhan Xusheng Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260323061130.29991-1-zhanxusheng@xiaomi.com Signed-off-by: Greg Kroah-Hartman commit da40464064599eefe78749f75cd2bba371044c04 Author: Jiucheng Xu Date: Wed Mar 11 17:11:31 2026 +0800 erofs: add GFP_NOIO in the bio completion if needed commit c23df30915f83e7257c8625b690a1cece94142a0 upstream. The bio completion path in the process context (e.g. dm-verity) will directly call into decompression rather than trigger another workqueue context for minimal scheduling latencies, which can then call vm_map_ram() with GFP_KERNEL. Due to insufficient memory, vm_map_ram() may generate memory swapping I/O, which can cause submit_bio_wait to deadlock in some scenarios. Trimmed down the call stack, as follows: f2fs_submit_read_io submit_bio //bio_list is initialized. mmc_blk_mq_recovery z_erofs_endio vm_map_ram __pte_alloc_kernel __alloc_pages_direct_reclaim shrink_folio_list __swap_writepage submit_bio_wait //bio_list is non-NULL, hang!!! Use memalloc_noio_{save,restore}() to wrap up this path. Reviewed-by: Gao Xiang Signed-off-by: Jiucheng Xu Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Greg Kroah-Hartman commit 9a18629f2525781f0f3dda7be72b204e4cf77d08 Author: xietangxin Date: Thu Mar 12 10:54:06 2026 +0800 virtio_net: Fix UAF on dst_ops when IFF_XMIT_DST_RELEASE is cleared and napi_tx is false commit ba8bda9a0896746053aa97ac6c3e08168729172c upstream. A UAF issue occurs when the virtio_net driver is configured with napi_tx=N and the device's IFF_XMIT_DST_RELEASE flag is cleared (e.g., during the configuration of tc route filter rules). When IFF_XMIT_DST_RELEASE is removed from the net_device, the network stack expects the driver to hold the reference to skb->dst until the packet is fully transmitted and freed. In virtio_net with napi_tx=N, skbs may remain in the virtio transmit ring for an extended period. If the network namespace is destroyed while these skbs are still pending, the corresponding dst_ops structure has freed. When a subsequent packet is transmitted, free_old_xmit() is triggered to clean up old skbs. It then calls dst_release() on the skb associated with the stale dst_entry. Since the dst_ops (referenced by the dst_entry) has already been freed, a UAF kernel paging request occurs. fix it by adds skb_dst_drop(skb) in start_xmit to explicitly release the dst reference before the skb is queued in virtio_net. Call Trace: Unable to handle kernel paging request at virtual address ffff80007e150000 CPU: 2 UID: 0 PID: 6236 Comm: ping Kdump: loaded Not tainted 7.0.0-rc1+ #6 PREEMPT ... percpu_counter_add_batch+0x3c/0x158 lib/percpu_counter.c:98 (P) dst_release+0xe0/0x110 net/core/dst.c:177 skb_release_head_state+0xe8/0x108 net/core/skbuff.c:1177 sk_skb_reason_drop+0x54/0x2d8 net/core/skbuff.c:1255 dev_kfree_skb_any_reason+0x64/0x78 net/core/dev.c:3469 napi_consume_skb+0x1c4/0x3a0 net/core/skbuff.c:1527 __free_old_xmit+0x164/0x230 drivers/net/virtio_net.c:611 [virtio_net] free_old_xmit drivers/net/virtio_net.c:1081 [virtio_net] start_xmit+0x7c/0x530 drivers/net/virtio_net.c:3329 [virtio_net] ... Reproduction Steps: NETDEV="enp3s0" config_qdisc_route_filter() { tc qdisc del dev $NETDEV root tc qdisc add dev $NETDEV root handle 1: prio tc filter add dev $NETDEV parent 1:0 \ protocol ip prio 100 route to 100 flowid 1:1 ip route add 192.168.1.100/32 dev $NETDEV realm 100 } test_ns() { ip netns add testns ip link set $NETDEV netns testns ip netns exec testns ifconfig $NETDEV 10.0.32.46/24 ip netns exec testns ping -c 1 10.0.32.1 ip netns del testns } config_qdisc_route_filter test_ns sleep 2 test_ns Fixes: f2fc6a54585a ("[NETNS][IPV6] route6 - move ip6_dst_ops inside the network namespace") Cc: stable@vger.kernel.org Signed-off-by: xietangxin Reviewed-by: Xuan Zhuo Fixes: 0287587884b1 ("net: better IFF_XMIT_DST_RELEASE support") Link: https://patch.msgid.link/20260312025406.15641-1-xietangxin@yeah.net Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6f3c8795ae9ba74fa10fe979293d1904712d3fb1 Author: Zubin Mithra Date: Wed Mar 18 13:40:13 2026 +0000 virt: tdx-guest: Fix handling of host controlled 'quote' buffer length commit c3fd16c3b98ed726294feab2f94f876290bf7b61 upstream. Validate host controlled value `quote_buf->out_len` that determines how many bytes of the quote are copied out to guest userspace. In TDX environments with remote attestation, quotes are not considered private, and can be forwarded to an attestation server. Catch scenarios where the host specifies a response length larger than the guest's allocation, or otherwise races modifying the response while the guest consumes it. This prevents contents beyond the pages allocated for `quote_buf` (up to TSM_REPORT_OUTBLOB_MAX) from being read out to guest userspace, and possibly forwarded in attestation requests. Recall that some deployments want per-container configs-tsm-report interfaces, so the leak may cross container protection boundaries, not just local root. Fixes: f4738f56d1dc ("virt: tdx-guest: Add Quote generation support using TSM_REPORTS") Cc: stable@vger.kernel.org Signed-off-by: Zubin Mithra Reviewed-by: Dan Williams Reviewed-by: Kiryl Shutsemau (Meta) Reviewed-by: Kuppuswamy Sathyanarayanan Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 371a43c4ac70cac0de9f9b1fc5b1660b9565b9f1 Author: Paul Moses Date: Mon Mar 16 14:56:51 2026 +0000 xfrm: iptfs: only publish mode_data after clone setup commit d849a2f7309fc0616e79d13b008b0a47e0458b6e upstream. iptfs_clone_state() stores x->mode_data before allocating the reorder window. If that allocation fails, the code frees the cloned state and returns -ENOMEM, leaving x->mode_data pointing at freed memory. The xfrm clone unwind later runs destroy_state() through x->mode_data, so the failed clone path tears down IPTFS state that clone_state() already freed. Keep the cloned IPTFS state private until all allocations succeed so failed clones leave x->mode_data unset. The destroy path already handles a NULL mode_data pointer. Fixes: 6be02e3e4f37 ("xfrm: iptfs: handle reordering of received packets") Cc: stable@vger.kernel.org Signed-off-by: Paul Moses Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit de6d8e8ce5187f7402c9859b443355e7120c5f09 Author: Roshan Kumar Date: Sun Mar 1 10:56:38 2026 +0000 xfrm: iptfs: validate inner IPv4 header length in IPTFS payload commit 0d10393d5eac33cbd92f7a41fddca12c41d3cb7e upstream. Add validation of the inner IPv4 packet tot_len and ihl fields parsed from decrypted IPTFS payloads in __input_process_payload(). A crafted ESP packet containing an inner IPv4 header with tot_len=0 causes an infinite loop: iplen=0 leads to capturelen=min(0, remaining)=0, so the data offset never advances and the while(data < tail) loop never terminates, spinning forever in softirq context. Reject inner IPv4 packets where tot_len < ihl*4 or ihl*4 < sizeof(struct iphdr), which catches both the tot_len=0 case and malformed ihl values. The normal IP stack performs this validation in ip_rcv_core(), but IPTFS extracts and processes inner packets before they reach that layer. Reported-by: Roshan Kumar Fixes: 6c82d2433671 ("xfrm: iptfs: add basic receive packet (tunnel egress) handling") Cc: stable@vger.kernel.org Signed-off-by: Roshan Kumar Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 72b9e81e0203f03c40f3adb457f55bd4c8eb112d Author: Yuchan Nam Date: Fri Mar 6 21:52:23 2026 +0900 media: mc, v4l2: serialize REINIT and REQBUFS with req_queue_mutex commit bef4f4a88b73e4cc550d25f665b8a9952af22773 upstream. MEDIA_REQUEST_IOC_REINIT can run concurrently with VIDIOC_REQBUFS(0) queue teardown paths. This can race request object cleanup against vb2 queue cancellation and lead to use-after-free reports. We already serialize request queueing against STREAMON/OFF with req_queue_mutex. Extend that serialization to REQBUFS, and also take the same mutex in media_request_ioctl_reinit() so REINIT is in the same exclusion domain. This keeps request cleanup and queue cancellation from running in parallel for request-capable devices. Fixes: 6093d3002eab ("media: vb2: keep a reference to the request until dqbuf") Cc: stable@vger.kernel.org Signed-off-by: Yuchan Nam Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 529a3f3c49d3e7db74a68085e295ffbc57332264 Author: Sanman Pradhan Date: Mon Mar 23 00:24:37 2026 +0000 hwmon: (peci/cputemp) Fix off-by-one in cputemp_is_visible() commit b0c9d8ae71509f25690d57f2efddebf7f4b12194 upstream. cputemp_is_visible() validates the channel index against CPUTEMP_CHANNEL_NUMS, but currently uses '>' instead of '>='. As a result, channel == CPUTEMP_CHANNEL_NUMS is not rejected even though valid indices are 0 .. CPUTEMP_CHANNEL_NUMS - 1. Fix the bounds check by using '>=' so invalid channel indices are rejected before indexing the core bitmap. Fixes: bf3608f338e9 ("hwmon: peci: Add cputemp driver") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan Link: https://lore.kernel.org/r/20260323002352.93417-3-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit d640ef7117a135de0dacad608c9c542864cbb757 Author: Sanman Pradhan Date: Mon Mar 23 00:24:25 2026 +0000 hwmon: (peci/cputemp) Fix crit_hyst returning delta instead of absolute temperature commit 0adc752b4f7d82af7bd14f7cad3091b3b5d702ba upstream. The hwmon sysfs ABI expects tempN_crit_hyst to report the temperature at which the critical condition clears, not the hysteresis delta from the critical limit. The peci cputemp driver currently returns tjmax - tcontrol for crit_hyst_type, which is the hysteresis margin rather than the corresponding absolute temperature. Return tcontrol directly, and update the documentation accordingly. Fixes: bf3608f338e9 ("hwmon: peci: Add cputemp driver") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan Link: https://lore.kernel.org/r/20260323002352.93417-2-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 67fd1e71f7682d9a7b8b996884ba013949249563 Author: Sanman Pradhan Date: Thu Mar 19 17:31:29 2026 +0000 hwmon: (pmbus/isl68137) Add mutex protection for AVS enable sysfs attributes commit 3075a3951f7708da5a8ab47b0b7d068a32f69e58 upstream. The custom avs0_enable and avs1_enable sysfs attributes access PMBus registers through the exported API helpers (pmbus_read_byte_data, pmbus_read_word_data, pmbus_write_word_data, pmbus_update_byte_data) without holding the PMBus update_lock mutex. These exported helpers do not acquire the mutex internally, unlike the core's internal callers which hold the lock before invoking them. The store callback is especially vulnerable: it performs a multi-step read-modify-write sequence (read VOUT_COMMAND, write VOUT_COMMAND, then update OPERATION) where concurrent access from another thread could interleave and corrupt the register state. Add pmbus_lock_interruptible()/pmbus_unlock() around both the show and store callbacks to serialize PMBus register access with the rest of the driver. Fixes: 038a9c3d1e424 ("hwmon: (pmbus/isl68137) Add driver for Intersil ISL68137 PWM Controller") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan Link: https://lore.kernel.org/r/20260319173055.125271-3-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit bf28ab8bed18eff2b16ab758b5dc4f6983ba5024 Author: Sanman Pradhan Date: Thu Mar 19 17:31:19 2026 +0000 hwmon: (pmbus/ina233) Fix error handling and sign extension in shunt voltage read commit f7e775c4694782844c66da5316fed82881835cf8 upstream. ina233_read_word_data() reads MFR_READ_VSHUNT via pmbus_read_word_data() but has two issues: 1. The return value is not checked for errors before being used in arithmetic. A negative error code from a failed I2C transaction is passed directly to DIV_ROUND_CLOSEST(), producing garbage data. 2. MFR_READ_VSHUNT is a 16-bit two's complement value. Negative shunt voltages (values with bit 15 set) are treated as large positive values since pmbus_read_word_data() returns them zero-extended in an int. This leads to incorrect scaling in the VIN coefficient conversion. Fix both issues by adding an error check, casting to s16 for proper sign extension, and clamping the result to a valid non-negative range. The clamp is necessary because read_word_data callbacks must return non-negative values on success (negative values indicate errors to the pmbus core). Fixes: b64b6cb163f16 ("hwmon: Add driver for TI INA233 Current and Power Monitor") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan Link: https://lore.kernel.org/r/20260319173055.125271-2-sanman.pradhan@hpe.com [groeck: Fixed clamp to avoid losing the sign bit] Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 8e209d882b674d1a4fb4b18bc1c23167ae35c30e Author: Marc Zyngier Date: Thu Mar 12 14:08:50 2026 +0000 KVM: arm64: Discard PC update state on vcpu reset commit 1744a6ef48b9a48f017e3e1a0d05de0a6978396e upstream. Our vcpu reset suffers from a particularly interesting flaw, as it does not correctly deal with state that will have an effect on the execution flow out of reset. Take the following completely random example, never seen in the wild and that never resulted in a couple of sleepless nights: /s - vcpu-A issues a PSCI_CPU_OFF using the SMC conduit - SMC being a trapped instruction (as opposed to HVC which is always normally executed), we annotate the vcpu as needing to skip the next instruction, which is the SMC itself - vcpu-A is now safely off - vcpu-B issues a PSCI_CPU_ON for vcpu-A, providing a starting PC - vcpu-A gets reset, get the new PC, and is sent on its merry way - right at the point of entering the guest, we notice that a PC increment is pending (remember the earlier SMC?) - vcpu-A skips its first instruction... What could possibly go wrong? Well, I'm glad you asked. For pKVM as a NV guest, that first instruction is extremely significant, as it indicates whether the CPU is booting or resuming. Having skipped that instruction, nothing makes any sense anymore, and CPU hotplugging fails. This is all caused by the decoupling of PC update from the handling of an exception that triggers such update, making it non-obvious what affects what when. Fix this train wreck by discarding all the PC-affecting state on vcpu reset. Fixes: f5e30680616ab ("KVM: arm64: Move __adjust_pc out of line") Cc: stable@vger.kernel.org Reviewed-by: Suzuki K Poulose Reviewed-by: Joey Gouly Link: https://patch.msgid.link/20260312140850.822968-1-maz@kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 4cf2cc6bc1cdb206e7693442b0cf15ef0b64e1cd Author: Srinivas Pandruvada Date: Mon Mar 23 08:36:35 2026 -0700 platform/x86: ISST: Correct locked bit width commit fbddf68d7b4e1e6da7a78dd7fbd8ec376536584a upstream. SST-PP locked bit width is set to three bits. It should be only one bit. Use SST_PP_LOCK_WIDTH define instead of SST_PP_LEVEL_WIDTH. Fixes: ea009e4769fa ("platform/x86: ISST: Add SST-PP support via TPMI") Signed-off-by: Srinivas Pandruvada Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260323153635.3263828-1-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit fdaf61f2831a4b6aa58b0248f2174b5fb8ec9b97 Author: Abhijit Gangurde Date: Fri Feb 27 11:48:09 2026 +0530 RDMA/ionic: Preserve and set Ethernet source MAC after ib_ud_header_init() commit a08aaf3968aec5d05cd32c801b8cc0c61da69c41 upstream. ionic_build_hdr() populated the Ethernet source MAC (hdr->eth.smac_h) by passing the header’s storage directly to rdma_read_gid_l2_fields(). However, ib_ud_header_init() is called after that and re-initializes the UD header, which wipes the previously written smac_h. As a result, packets are emitted with an zero source MAC address on the wire. Correct the source MAC by reading the GID-derived smac into a temporary buffer and copy it after ib_ud_header_init() completes. Fixes: e8521822c733 ("RDMA/ionic: Register device ops for control path") Cc: stable@vger.kernel.org # 6.18 Signed-off-by: Abhijit Gangurde Link: https://patch.msgid.link/20260227061809.2979990-1-abhijit.gangurde@amd.com Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman commit ab839325a41c98f69f332450881fa024ea6cc5dc Author: Srinivas Pandruvada Date: Tue Mar 24 10:23:46 2026 -0700 thermal: intel: int340x: soc_slider: Set offset only for balanced mode commit 7dfe9846016b15816e287a4650be1ff1b48c5ab4 upstream. The slider offset can be set via debugfs for balanced mode. The offset should be only applicable in balanced mode. For other modes, it should be 0 when writing to MMIO offset, Fixes: 8306bcaba06d ("thermal: intel: int340x: Add module parameter to change slider offset") Tested-by: Erin Park Signed-off-by: Srinivas Pandruvada Cc: 6.18+ # 6.18+ [ rjw: Subject and changelog tweaks ] Link: https://patch.msgid.link/20260324172346.3317145-1-srinivas.pandruvada@linux.intel.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 8def1e51df141614388d9efa90a8d397597ee8af Author: Charles Mirabile Date: Sat Mar 7 23:43:30 2026 -0500 kbuild: Delete .builtin-dtbs.S when running make clean commit a76e30c2479ce6ffa2aa6c8a8462897afc82bc90 upstream. The makefile tries to delete a file named ".builtin-dtb.S" but the file created by scripts/Makefile.vmlinux is actually called ".builtin-dtbs.S". Fixes: 654102df2ac2a ("kbuild: add generic support for built-in boot DTBs") Cc: stable@vger.kernel.org Signed-off-by: Charles Mirabile Reviewed-by: Nicolas Schier Link: https://patch.msgid.link/20260308044338.181403-1-cmirabil@redhat.com [nathan: Small commit message adjustments] Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit e2f7e4d83ab8f360fc8e81f26074461b4766cb44 Author: Viresh Kumar Date: Fri Mar 20 15:08:14 2026 +0530 cpufreq: conservative: Reset requested_freq on limits change commit 6a28fb8cb28b9eb39a392e531d938a889eacafc5 upstream. A recently reported issue highlighted that the cached requested_freq is not guaranteed to stay in sync with policy->cur. If the platform changes the actual CPU frequency after the governor sets one (e.g. due to platform-specific frequency scaling) and a re-sync occurs later, policy->cur may diverge from requested_freq. This can lead to incorrect behavior in the conservative governor. For example, the governor may assume the CPU is already running at the maximum frequency and skip further increases even though there is still headroom. Avoid this by resetting the cached requested_freq to policy->cur on detecting a change in policy limits. Reported-by: Lifeng Zheng Tested-by: Lifeng Zheng Link: https://lore.kernel.org/all/20260210115458.3493646-1-zhenglifeng1@huawei.com/ Signed-off-by: Viresh Kumar Reviewed-by: Zhongqiu Han Cc: All applicable Link: https://patch.msgid.link/d846a141a98ac0482f20560fcd7525c0f0ec2f30.1773999467.git.viresh.kumar@linaro.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit f162aa749a40f5053c5d551851c351a2d30004ae Author: Marc Kleine-Budde Date: Tue Mar 10 13:48:03 2026 +0100 can: netlink: can_changelink(): add missing error handling to call can_ctrlmode_changelink() commit cadf6019231b614ebbd9ec2a16e5997ecbd8d016 upstream. In commit e1a5cd9d6665 ("can: netlink: add can_ctrlmode_changelink()") the CAN Control Mode (IFLA_CAN_CTRLMODE) handling was factored out into the can_ctrlmode_changelink() function. But the call to can_ctrlmode_changelink() is missing the error handling. Add the missing error handling and propagation to the call can_ctrlmode_changelink(). Cc: stable@vger.kernel.org Fixes: e1a5cd9d6665 ("can: netlink: add can_ctrlmode_changelink()") Link: https://patch.msgid.link/20260310-can_ctrlmode_changelink-add-error-handling-v1-1-0daf63d85922@pengutronix.de Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit eec8a1b18a79600bd4419079dc0026c1db72a830 Author: Oliver Hartkopp Date: Thu Mar 19 16:47:45 2026 +0100 can: isotp: fix tx.buf use-after-free in isotp_sendmsg() commit 424e95d62110cdbc8fd12b40918f37e408e35a92 upstream. isotp_sendmsg() uses only cmpxchg() on so->tx.state to serialize access to so->tx.buf. isotp_release() waits for ISOTP_IDLE via wait_event_interruptible() and then calls kfree(so->tx.buf). If a signal interrupts the wait_event_interruptible() inside close() while tx.state is ISOTP_SENDING, the loop exits early and release proceeds to force ISOTP_SHUTDOWN and continues to kfree(so->tx.buf) while sendmsg may still be reading so->tx.buf for the final CAN frame in isotp_fill_dataframe(). The so->tx.buf can be allocated once when the standard tx.buf length needs to be extended. Move the kfree() of this potentially extended tx.buf to sk_destruct time when either isotp_sendmsg() and isotp_release() are done. Fixes: 96d1c81e6a04 ("can: isotp: add module parameter for maximum pdu size") Cc: stable@vger.kernel.org Reported-by: Ali Norouzi Co-developed-by: Ali Norouzi Signed-off-by: Ali Norouzi Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260319-fix-can-gw-and-can-isotp-v2-2-c45d52c6d2d8@pengutronix.de Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 84f8b76d24273175a22713e83e90874e1880d801 Author: Ali Norouzi Date: Thu Mar 19 16:47:44 2026 +0100 can: gw: fix OOB heap access in cgw_csum_crc8_rel() commit b9c310d72783cc2f30d103eed83920a5a29c671a upstream. cgw_csum_crc8_rel() correctly computes bounds-safe indices via calc_idx(): int from = calc_idx(crc8->from_idx, cf->len); int to = calc_idx(crc8->to_idx, cf->len); int res = calc_idx(crc8->result_idx, cf->len); if (from < 0 || to < 0 || res < 0) return; However, the loop and the result write then use the raw s8 fields directly instead of the computed variables: for (i = crc8->from_idx; ...) /* BUG: raw negative index */ cf->data[crc8->result_idx] = ...; /* BUG: raw negative index */ With from_idx = to_idx = result_idx = -64 on a 64-byte CAN FD frame, calc_idx(-64, 64) = 0 so the guard passes, but the loop iterates with i = -64, reading cf->data[-64], and the write goes to cf->data[-64]. This write might end up to 56 (7.0-rc) or 40 (<= 6.19) bytes before the start of the canfd_frame on the heap. The companion function cgw_csum_xor_rel() uses `from`/`to`/`res` correctly throughout; fix cgw_csum_crc8_rel() to match. Confirmed with KASAN on linux-7.0-rc2: BUG: KASAN: slab-out-of-bounds in cgw_csum_crc8_rel+0x515/0x5b0 Read of size 1 at addr ffff8880076619c8 by task poc_cgw_oob/62 To configure the can-gw crc8 checksums CAP_NET_ADMIN is needed. Fixes: 456a8a646b25 ("can: gw: add support for CAN FD frames") Cc: stable@vger.kernel.org Reported-by: Ali Norouzi Reviewed-by: Oliver Hartkopp Acked-by: Oliver Hartkopp Signed-off-by: Ali Norouzi Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260319-fix-can-gw-and-can-isotp-v2-1-c45d52c6d2d8@pengutronix.de Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit cab361aa6404a6d177e5e4ac8c593fa1b8be4a38 Author: Peter Ujfalusi Date: Thu Mar 26 09:56:18 2026 +0200 ASoC: SOF: ipc4-topology: Allow bytes controls without initial payload commit d40a198e2b7821197c5c77b89d0130cc90f400f5 upstream. It is unexpected, but allowed to have no initial payload for a bytes control and the code is prepared to handle this case, but the size check missed this corner case. Update the check for minimal size to allow the initial size to be 0. Cc: stable@vger.kernel.org Fixes: a653820700b8 ("ASoC: SOF: ipc4-topology: Correct the allocation size for bytes controls") Signed-off-by: Peter Ujfalusi Reviewed-by: Bard Liao Reviewed-by: Liam Girdwood Reviewed-by: Seppo Ingalsuo Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20260326075618.1603-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit d472d1a52985211b92883bb64bbe710b45980190 Author: Guangshuo Li Date: Fri Mar 13 12:06:11 2026 +0800 ASoC: sma1307: fix double free of devm_kzalloc() memory commit fe757092d2329c397ecb32f2bf68a5b1c4bd9193 upstream. A previous change added NULL checks and cleanup for allocation failures in sma1307_setting_loaded(). However, the cleanup for mode_set entries is wrong. Those entries are allocated with devm_kzalloc(), so they are device-managed resources and must not be freed with kfree(). Manually freeing them in the error path can lead to a double free when devres later releases the same memory. Drop the manual kfree() loop and let devres handle the cleanup. Fixes: 0ec6bd16705fe ("ASoC: sma1307: Add NULL check in sma1307_setting_loaded()") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260313040611.391479-1-lgs201920130244@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6ab27f2dc76d2dc233e5023e3665abb3cb5ef015 Author: Srinivas Kandagatla Date: Mon Mar 23 23:17:48 2026 +0000 ASoC: codecs: wcd934x: fix typo in dt parsing commit cfb385a8dc88d86a805a5682eaa68f59fa5c0ec3 upstream. Looks like we ended up with a typo during device tree data parsing as part of 4f16b6351bbff ("ASoC: codecs: wcd: add common helper for wcd codecs") patch. This will result in not parsing the device tree data and results in zero mic bias values. Fix this by calling wcd_dt_parse_micbias_info instead of wcd_dt_parse_mbhc_data. Fixes: 4f16b6351bbff ("ASoC: codecs: wcd: add common helper for wcd codecs") Cc: Stable@vger.kernel.org Reported-by: Joel Selvaraj Signed-off-by: Srinivas Kandagatla Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260323231748.2217967-1-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c215d25cf050b86c74c7600363e8576a8d5a8b70 Author: Alexey Nepomnyashih Date: Mon Mar 16 19:18:22 2026 +0000 ALSA: firewire-lib: fix uninitialized local variable commit bb120ad57def62e3f23e3d999c5fbed11f610993 upstream. Similar to commit d8dc8720468a ("ALSA: firewire-lib: fix uninitialized local variable"), the local variable `curr_cycle_time` in process_rx_packets() is declared without initialization. When the tracepoint event is not probed, the variable may appear to be used without being initialized. In practice the value is only relevant when the tracepoint is enabled, however initializing it avoids potential use of an uninitialized value and improves code safety. Initialize `curr_cycle_time` to zero. Fixes: fef4e61b0b76 ("ALSA: firewire-lib: extend tracepoints event including CYCLE_TIME of 1394 OHCI") Cc: stable@vger.kernel.org Signed-off-by: Alexey Nepomnyashih Link: https://patch.msgid.link/20260316191824.83249-1-sdl@nppct.ru Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 61aff3c1edc38b6df385252012a45b64a710663e Author: Zhang Heng Date: Mon Mar 16 10:28:43 2026 +0800 ALSA: hda/realtek: add quirk for ASUS Strix G16 G615JMR commit 0bdf27abaf8940592207be939142451436afe39f upstream. The machine is equipped with ALC294 and requires the ALC287_FIXUP_TXNW2781_I2C_ASUS quirk for the amplifier to work properly. Since the machine's PCI SSID is also 1043:1204, HDA_CODEC_QUIRK is used to retain the previous quirk. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221173 Cc: Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260316022843.2809968-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 47c459a6c9b67cc68dd305c07da305733c844cbc Author: Mario Limonciello Date: Thu Mar 26 14:05:38 2026 -0500 Revert "ALSA: hda/intel: Add MSI X870E Tomahawk to denylist" commit ed4da361bf943b9041fc63e5cb6af01b3c0de978 upstream. commit 30b3211aa2416 ("ALSA: hda/intel: Add MSI X870E Tomahawk to denylist") was added to silence a warning, but this effectively reintroduced commit df42ee7e22f03 ("ALSA: hda: Add ASRock X670E Taichi to denylist") which was already reported to cause problems and reverted in commit ee8f1613596ad ("Revert "ALSA: hda: Add ASRock X670E Taichi to denylist"") Revert it yet again. Cc: stable@vger.kernel.org Reported-by: Juhyun Song Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221274 Cc: Stuart Hayhurst Signed-off-by: Mario Limonciello Link: https://patch.msgid.link/20260326190542.524515-1-mario.limonciello@amd.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a897064a457056acb976e20e3007cdf553de340f Author: Hyunwoo Kim Date: Tue Mar 17 08:52:01 2026 +0900 ksmbd: do not expire session on binding failure commit 9bbb19d21ded7d78645506f20d8c44895e3d0fb9 upstream. When a multichannel session binding request fails (e.g. wrong password), the error path unconditionally sets sess->state = SMB2_SESSION_EXPIRED. However, during binding, sess points to the target session looked up via ksmbd_session_lookup_slowpath() -- which belongs to another connection's user. This allows a remote attacker to invalidate any active session by simply sending a binding request with a wrong password (DoS). Fix this by skipping session expiration when the failed request was a binding attempt, since the session does not belong to the current connection. The reference taken by ksmbd_session_lookup_slowpath() is still correctly released via ksmbd_user_session_put(). Cc: stable@vger.kernel.org Signed-off-by: Hyunwoo Kim Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 3cdacd11b41569ce75b3162142240f2355e04900 Author: Werner Kasselman Date: Tue Mar 17 07:55:37 2026 +0000 ksmbd: fix memory leaks and NULL deref in smb2_lock() commit 309b44ed684496ed3f9c5715d10b899338623512 upstream. smb2_lock() has three error handling issues after list_del() detaches smb_lock from lock_list at no_check_cl: 1) If vfs_lock_file() returns an unexpected error in the non-UNLOCK path, goto out leaks smb_lock and its flock because the out: handler only iterates lock_list and rollback_list, neither of which contains the detached smb_lock. 2) If vfs_lock_file() returns -ENOENT in the UNLOCK path, goto out leaks smb_lock and flock for the same reason. The error code returned to the dispatcher is also stale. 3) In the rollback path, smb_flock_init() can return NULL on allocation failure. The result is dereferenced unconditionally, causing a kernel NULL pointer dereference. Add a NULL check to prevent the crash and clean up the bookkeeping; the VFS lock itself cannot be rolled back without the allocation and will be released at file or connection teardown. Fix cases 1 and 2 by hoisting the locks_free_lock()/kfree() to before the if(!rc) check in the UNLOCK branch so all exit paths share one free site, and by freeing smb_lock and flock before goto out in the non-UNLOCK branch. Propagate the correct error code in both cases. Fix case 3 by wrapping the VFS unlock in an if(rlock) guard and adding a NULL check for locks_free_lock(rlock) in the shared cleanup. Found via call-graph analysis using sqry. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Suggested-by: ChenXiaoSong Signed-off-by: Werner Kasselman Reviewed-by: ChenXiaoSong Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit b0cd9725fe2bcc9f37d096b132318a9060373f5d Author: Namjae Jeon Date: Thu Mar 19 21:00:02 2026 +0900 ksmbd: fix potencial OOB in get_file_all_info() for compound requests commit beef2634f81f1c086208191f7228bce1d366493d upstream. When a compound request consists of QUERY_DIRECTORY + QUERY_INFO (FILE_ALL_INFORMATION) and the first command consumes nearly the entire max_trans_size, get_file_all_info() would blindly call smbConvertToUTF16() with PATH_MAX, causing out-of-bounds write beyond the response buffer. In get_file_all_info(), there was a missing validation check for the client-provided OutputBufferLength before copying the filename into FileName field of the smb2_file_all_info structure. If the filename length exceeds the available buffer space, it could lead to potential buffer overflows or memory corruption during smbConvertToUTF16 conversion. This calculating the actual free buffer size using smb2_calc_max_out_buf_len() and returning -EINVAL if the buffer is insufficient and updating smbConvertToUTF16 to use the actual filename length (clamped by PATH_MAX) to ensure a safe copy operation. Cc: stable@vger.kernel.org Fixes: e2b76ab8b5c9 ("ksmbd: add support for read compound") Reported-by: Asim Viladi Oglu Manizada Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 80824c7e527b70cf9039534e60aff592e8f209d1 Author: Namjae Jeon Date: Fri Mar 13 14:45:58 2026 +0900 ksmbd: replace hardcoded hdr2_len with offsetof() in smb2_calc_max_out_buf_len() commit 0e55f63dd08f09651d39e1b709a91705a8a0ddcb upstream. After this commit (e2b76ab8b5c9 "ksmbd: add support for read compound"), response buffer management was changed to use dynamic iov array. In the new design, smb2_calc_max_out_buf_len() expects the second argument (hdr2_len) to be the offset of ->Buffer field in the response structure, not a hardcoded magic number. Fix the remaining call sites to use the correct offsetof() value. Cc: stable@vger.kernel.org Fixes: e2b76ab8b5c9 ("ksmbd: add support for read compound") Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 5eda8001ebb5269755608d678dd1f3928ab077c9 Author: Matthew Auld Date: Wed Mar 18 10:02:09 2026 +0000 drm/xe: always keep track of remap prev/next commit bfe9e314d7574d1c5c851972e7aee342733819d2 upstream. During 3D workload, user is reporting hitting: [ 413.361679] WARNING: drivers/gpu/drm/xe/xe_vm.c:1217 at vm_bind_ioctl_ops_unwind+0x1e2/0x2e0 [xe], CPU#7: vkd3d_queue/9925 [ 413.361944] CPU: 7 UID: 1000 PID: 9925 Comm: vkd3d_queue Kdump: loaded Not tainted 7.0.0-070000rc3-generic #202603090038 PREEMPT(lazy) [ 413.361949] RIP: 0010:vm_bind_ioctl_ops_unwind+0x1e2/0x2e0 [xe] [ 413.362074] RSP: 0018:ffffd4c25c3df930 EFLAGS: 00010282 [ 413.362077] RAX: 0000000000000000 RBX: ffff8f3ee817ed10 RCX: 0000000000000000 [ 413.362078] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 413.362079] RBP: ffffd4c25c3df980 R08: 0000000000000000 R09: 0000000000000000 [ 413.362081] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8f41fbf99380 [ 413.362082] R13: ffff8f3ee817e968 R14: 00000000ffffffef R15: ffff8f43d00bd380 [ 413.362083] FS: 00000001040ff6c0(0000) GS:ffff8f4696d89000(0000) knlGS:00000000330b0000 [ 413.362085] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 [ 413.362086] CR2: 00007ddfc4747000 CR3: 00000002e6262005 CR4: 0000000000f72ef0 [ 413.362088] PKRU: 55555554 [ 413.362089] Call Trace: [ 413.362092] [ 413.362096] xe_vm_bind_ioctl+0xa9a/0xc60 [xe] Which seems to hint that the vma we are re-inserting for the ops unwind is either invalid or overlapping with something already inserted in the vm. It shouldn't be invalid since this is a re-insertion, so must have worked before. Leaving the likely culprit as something already placed where we want to insert the vma. Following from that, for the case where we do something like a rebind in the middle of a vma, and one or both mapped ends are already compatible, we skip doing the rebind of those vma and set next/prev to NULL. As well as then adjust the original unmap va range, to avoid unmapping the ends. However, if we trigger the unwind path, we end up with three va, with the two ends never being removed and the original va range in the middle still being the shrunken size. If this occurs, one failure mode is when another unwind op needs to interact with that range, which can happen with a vector of binds. For example, if we need to re-insert something in place of the original va. In this case the va is still the shrunken version, so when removing it and then doing a re-insert it can overlap with the ends, which were never removed, triggering a warning like above, plus leaving the vm in a bad state. With that, we need two things here: 1) Stop nuking the prev/next tracking for the skip cases. Instead relying on checking for skip prev/next, where needed. That way on the unwind path, we now correctly remove both ends. 2) Undo the unmap va shrinkage, on the unwind path. With the two ends now removed the unmap va should expand back to the original size again, before re-insertion. v2: - Update the explanation in the commit message, based on an actual IGT of triggering this issue, rather than conjecture. - Also undo the unmap shrinkage, for the skip case. With the two ends now removed, the original unmap va range should expand back to the original range. v3: - Track the old start/range separately. vma_size/start() uses the va info directly. Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7602 Fixes: 8f33b4f054fc ("drm/xe: Avoid doing rebinds") Signed-off-by: Matthew Auld Cc: Matthew Brost Cc: # v6.8+ Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20260318100208.78097-2-matthew.auld@intel.com (cherry picked from commit aec6969f75afbf4e01fd5fb5850ed3e9c27043ac) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit f278b8ebf7eba2a1699cfc7bf30dd3ef898d60d7 Author: Luo Haiyang Date: Thu Mar 26 14:19:53 2026 +0800 tracing: Fix potential deadlock in cpu hotplug with osnoise commit 1f9885732248d22f788e4992c739a98c88ab8a55 upstream. The following sequence may leads deadlock in cpu hotplug: task1 task2 task3 ----- ----- ----- mutex_lock(&interface_lock) [CPU GOING OFFLINE] cpus_write_lock(); osnoise_cpu_die(); kthread_stop(task3); wait_for_completion(); osnoise_sleep(); mutex_lock(&interface_lock); cpus_read_lock(); [DEAD LOCK] Fix by swap the order of cpus_read_lock() and mutex_lock(&interface_lock). Cc: stable@vger.kernel.org Cc: Cc: Cc: Cc: Fixes: bce29ac9ce0bb ("trace: Add osnoise tracer") Link: https://patch.msgid.link/20260326141953414bVSj33dAYktqp9Oiyizq8@zte.com.cn Reviewed-by: Masami Hiramatsu (Google) Signed-off-by: Luo Haiyang Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 7f4e3233faa8470dd0627bc49b2809f2bfebd909 Author: Vasily Gorbik Date: Thu Mar 26 19:50:14 2026 +0100 s390/entry: Scrub r12 register on kernel entry commit 0738d395aab8fae3b5a3ad3fc640630c91693c27 upstream. Before commit f33f2d4c7c80 ("s390/bp: remove TIF_ISOLATE_BP"), all entry handlers loaded r12 with the current task pointer (lg %r12,__LC_CURRENT) for use by the BPENTER/BPEXIT macros. That commit removed TIF_ISOLATE_BP, dropping both the branch prediction macros and the r12 load, but did not add r12 to the register clearing sequence. Add the missing xgr %r12,%r12 to make the register scrub consistent across all entry points. Fixes: f33f2d4c7c80 ("s390/bp: remove TIF_ISOLATE_BP") Cc: stable@kernel.org Reviewed-by: Ilya Leoshkevich Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 3d39a4ec6380835edd7f097f24c4bbef31ca3b80 Author: Vasily Gorbik Date: Thu Mar 26 14:38:44 2026 +0100 s390/barrier: Make array_index_mask_nospec() __always_inline commit c5c0a268b38adffbb2e70e6957017537ff54c157 upstream. Mark array_index_mask_nospec() as __always_inline to guarantee the mitigation is emitted inline regardless of compiler inlining decisions. Fixes: e2dd833389cc ("s390: add optimized array_index_mask_nospec") Cc: stable@kernel.org Reviewed-by: Ilya Leoshkevich Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 87776f02449e3bded95b2ccbd6b012e9ae64e6f3 Author: Greg Kroah-Hartman Date: Tue Mar 24 17:34:05 2026 +0100 s390/syscalls: Add spectre boundary for syscall dispatch table commit 48b8814e25d073dd84daf990a879a820bad2bcbd upstream. The s390 syscall number is directly controlled by userspace, but does not have an array_index_nospec() boundary to prevent access past the syscall function pointer tables. Cc: Heiko Carstens Cc: Vasily Gorbik Cc: Alexander Gordeev Cc: Christian Borntraeger Cc: Sven Schnelle Cc: Arnd Bergmann Fixes: 56e62a737028 ("s390: convert to generic entry") Cc: stable@kernel.org Assisted-by: gkh_clanker_2000 Signed-off-by: Greg Kroah-Hartman Reviewed-by: Vasily Gorbik Link: https://lore.kernel.org/r/2026032404-sterling-swoosh-43e6@gregkh Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 44900508771846af81a37ed7fa62a70e1bb7e257 Author: Geoffrey D. Bennett Date: Mon Mar 23 21:59:21 2026 +1030 ALSA: usb-audio: Exclude Scarlett 2i4 1st Gen from SKIP_IFACE_SETUP [ Upstream commit 990a8b0732cf899d4a0f847b0a67efeb9a384c82 ] Same issue that the Scarlett 2i2 1st Gen had: QUIRK_FLAG_SKIP_IFACE_SETUP causes distorted/flanging audio on the Scarlett 2i4 1st Gen (1235:800a). Fixes: 38c322068a26 ("ALSA: usb-audio: Add QUIRK_FLAG_SKIP_IFACE_SETUP") Reported-by: dcferreira [https://github.com/geoffreybennett/linux-fcp/issues/54] Signed-off-by: Geoffrey D. Bennett Link: https://patch.msgid.link/acEkEbftzyNe8W7C@m.b4.vu Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit e89e2b97253c124d37bf88e96e5e8ce5c3aeeec3 Author: Marc Kleine-Budde Date: Thu Mar 19 19:38:12 2026 +0100 spi: spi-fsl-lpspi: fix teardown order issue (UAF) [ Upstream commit b341c1176f2e001b3adf0b47154fc31589f7410e ] There is a teardown order issue in the driver. The SPI controller is registered using devm_spi_register_controller(), which delays unregistration of the SPI controller until after the fsl_lpspi_remove() function returns. As the fsl_lpspi_remove() function synchronously tears down the DMA channels, a running SPI transfer triggers the following NULL pointer dereference due to use after free: | fsl_lpspi 42550000.spi: I/O Error in DMA RX | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] | Call trace: | fsl_lpspi_dma_transfer+0x260/0x340 [spi_fsl_lpspi] | fsl_lpspi_transfer_one+0x198/0x448 [spi_fsl_lpspi] | spi_transfer_one_message+0x49c/0x7c8 | __spi_pump_transfer_message+0x120/0x420 | __spi_sync+0x2c4/0x520 | spi_sync+0x34/0x60 | spidev_message+0x20c/0x378 [spidev] | spidev_ioctl+0x398/0x750 [spidev] [...] Switch from devm_spi_register_controller() to spi_register_controller() in fsl_lpspi_probe() and add the corresponding spi_unregister_controller() in fsl_lpspi_remove(). Fixes: 5314987de5e5 ("spi: imx: add lpspi bus driver") Signed-off-by: Marc Kleine-Budde Link: https://patch.msgid.link/20260319-spi-fsl-lpspi-fixes-v1-1-b433e435b2d8@pengutronix.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit efb07062d95c0c447a3b5ebf860d32a8b5c00a80 Author: Jihed Chaibi Date: Wed Mar 25 22:07:04 2026 +0100 ASoC: adau1372: Fix clock leak on PLL lock failure [ Upstream commit bfe6a264effcb6fe99ad7ceaf9e8c7439fc9555b ] adau1372_enable_pll() was a void function that logged a dev_err() on PLL lock timeout but did not propagate the error. As a result, adau1372_set_power() would continue with adau1372->enabled set to true despite the PLL being unlocked, and the mclk left enabled with no corresponding disable on the error path. Convert adau1372_enable_pll() to return int, using -ETIMEDOUT on lock timeout and propagating regmap errors directly. In adau1372_set_power(), check the return value and unwind in reverse order: restore regcache to cache-only mode, reassert GPIO power-down, and disable the clock before returning the error. Signed-off-by: Jihed Chaibi Fixes: 6cd4c6459e47 ("ASoC: Add ADAU1372 audio CODEC support") Reviewed-by: Nuno Sá Link: https://patch.msgid.link/20260325210704.76847-3-jihed.chaibi.dev@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 02709ae51f939cf530604db134d63a5d1eacd992 Author: Jihed Chaibi Date: Wed Mar 25 22:07:03 2026 +0100 ASoC: adau1372: Fix unchecked clk_prepare_enable() return value [ Upstream commit 326fe8104a4020d30080d37ac8b6b43893cdebca ] adau1372_set_power() calls clk_prepare_enable() but discards the return value. If the clock enable fails, the driver proceeds to access registers on unpowered hardware, potentially causing silent corruption. Make adau1372_set_power() return int and propagate the error from clk_prepare_enable(). Update adau1372_set_bias_level() to return the error directly for the STANDBY and OFF cases. Signed-off-by: Jihed Chaibi Fixes: 6cd4c6459e47 ("ASoC: Add ADAU1372 audio CODEC support") Reviewed-by: Nuno Sá Link: https://patch.msgid.link/20260325210704.76847-2-jihed.chaibi.dev@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 01d5711be772f90591990a769b6505eb6758463c Author: Marc Buerg Date: Wed Mar 25 23:29:50 2026 +0100 sysctl: fix uninitialized variable in proc_do_large_bitmap [ Upstream commit f63a9df7e3f9f842945d292a19d9938924f066f9 ] proc_do_large_bitmap() does not initialize variable c, which is expected to be set to a trailing character by proc_get_long(). However, proc_get_long() only sets c when the input buffer contains a trailing character after the parsed value. If c is not initialized it may happen to contain a '-'. If this is the case proc_do_large_bitmap() expects to be able to parse a second part of the input buffer. If there is no second part an unjustified -EINVAL will be returned. Initialize c to 0 to prevent returning -EINVAL on valid input. Fixes: 9f977fb7ae9d ("sysctl: add proc_do_large_bitmap") Signed-off-by: Marc Buerg Reviewed-by: Joel Granados Signed-off-by: Joel Granados Signed-off-by: Sasha Levin commit 4e9d723d9f198b86f6882a84c501ba1f39e8d055 Author: Guenter Roeck Date: Sun Mar 22 09:12:33 2026 -0700 hwmon: (pmbus/core) Protect regulator operations with mutex [ Upstream commit 754bd2b4a084b90b5e7b630e1f423061a9b9b761 ] The regulator operations pmbus_regulator_get_voltage(), pmbus_regulator_set_voltage(), and pmbus_regulator_list_voltage() access PMBus registers and shared data but were not protected by the update_lock mutex. This could lead to race conditions. However, adding mutex protection directly to these functions causes a deadlock because pmbus_regulator_notify() (which calls regulator_notifier_call_chain()) is often called with the mutex already held (e.g., from pmbus_fault_handler()). If a regulator callback then calls one of the now-protected voltage functions, it will attempt to acquire the same mutex. Rework pmbus_regulator_notify() to utilize a worker function to send notifications outside of the mutex protection. Events are stored as atomics in a per-page bitmask and processed by the worker. Initialize the worker and its associated data during regulator registration, and ensure it is cancelled on device removal using devm_add_action_or_reset(). While at it, remove the unnecessary include of linux/of.h. Cc: Sanman Pradhan Fixes: ddbb4db4ced1b ("hwmon: (pmbus) Add regulator support") Reviewed-by: Sanman Pradhan Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit cdf31cf5ca4aa2f1429e8d050b71f5e119c912af Author: Guenter Roeck Date: Tue Mar 24 18:54:11 2026 -0700 hwmon: (pmbus) Introduce the concept of "write-only" attributes [ Upstream commit cd658475e7694d58e1c40dabc1dacf8431ccedb2 ] Attributes intended to clear sensor history are intended to be writeable only. Reading those attributes today results in reporting more or less random values. To avoid ABI surprises, have those attributes explicitly return 0 when reading. Fixes: 787c095edaa9d ("hwmon: (pmbus/core) Add support for rated attributes") Reviewed-by: Sanman Pradhan Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 34479e52f1e992dc256ab782437d55d882d76be8 Author: Guenter Roeck Date: Tue Mar 24 16:41:07 2026 -0700 hwmon: (pmbus) Mark lowest/average/highest/rated attributes as read-only [ Upstream commit 805a5bd1c3f307d45ae4e9cf8915ef16d585a54a ] Writing those attributes is not supported, so mark them as read-only. Prior to this change, attempts to write into these attributes returned an error. Mark boolean fields in struct pmbus_limit_attr and in struct pmbus_sensor_attr as bit fields to reduce configuration data size. The data is scanned only while probing, so performance is not a concern. Fixes: 6f183d33a02e6 ("hwmon: (pmbus) Add support for peak attributes") Reviewed-by: Sanman Pradhan Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 8b476d95e98b17a59f0bd2699dd986a7188420f0 Author: Sanman Pradhan Date: Wed Mar 25 05:13:06 2026 +0000 hwmon: (adm1177) fix sysfs ABI violation and current unit conversion [ Upstream commit bf08749a6abb6d1959bfdc0edc32c640df407558 ] The adm1177 driver exposes the current alert threshold through hwmon_curr_max_alarm. This violates the hwmon sysfs ABI, where *_alarm attributes are read-only status flags and writable thresholds must use currN_max. The driver also stores the threshold internally in microamps, while currN_max is defined in milliamps. Convert the threshold accordingly on both the read and write paths. Widen the cached threshold and related calculations to 64 bits so that small shunt resistor values do not cause truncation or overflow. Also use 64-bit arithmetic for the mA/uA conversions, clamp writes to the range the hardware can represent, and propagate failures from adm1177_write_alert_thr() instead of silently ignoring them. Update the hwmon documentation to reflect the attribute rename and the correct units returned by the driver. Fixes: 09b08ac9e8d5 ("hwmon: (adm1177) Add ADM1177 Hot Swap Controller and Digital Power Monitor driver") Signed-off-by: Sanman Pradhan Acked-by: Nuno Sá Link: https://lore.kernel.org/r/20260325051246.28262-1-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 39820864eacd886f1a6f817414fb8f9ea3e9a2b4 Author: Srinivasan Shanmugam Date: Mon Mar 23 13:41:18 2026 +0530 drm/amdgpu: Fix fence put before wait in amdgpu_amdkfd_submit_ib [ Upstream commit 7150850146ebfa4ca998f653f264b8df6f7f85be ] amdgpu_amdkfd_submit_ib() submits a GPU job and gets a fence from amdgpu_ib_schedule(). This fence is used to wait for job completion. Currently, the code drops the fence reference using dma_fence_put() before calling dma_fence_wait(). If dma_fence_put() releases the last reference, the fence may be freed before dma_fence_wait() is called. This can lead to a use-after-free. Fix this by waiting on the fence first and releasing the reference only after dma_fence_wait() completes. Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:697 amdgpu_amdkfd_submit_ib() warn: passing freed memory 'f' (line 696) Fixes: 9ae55f030dc5 ("drm/amdgpu: Follow up change to previous drm scheduler change.") Cc: Felix Kuehling Cc: Dan Carpenter Cc: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 8b9e5259adc385b61a6590a13b82ae0ac2bd3482) Signed-off-by: Sasha Levin commit d04c007047c88158141d9bd5eac761cdadd3782c Author: Weiming Shi Date: Wed Mar 25 00:54:59 2026 +0800 ACPI: EC: clean up handlers on probe failure in acpi_ec_setup() [ Upstream commit f6484cadbcaf26b5844b51bd7307a663dda48ef6 ] When ec_install_handlers() returns -EPROBE_DEFER on reduced-hardware platforms, it has already started the EC and installed the address space handler with the struct acpi_ec pointer as handler context. However, acpi_ec_setup() propagates the error without any cleanup. The caller acpi_ec_add() then frees the struct acpi_ec for non-boot instances, leaving a dangling handler context in ACPICA. Any subsequent AML evaluation that accesses an EC OpRegion field dispatches into acpi_ec_space_handler() with the freed pointer, causing a use-after-free: BUG: KASAN: slab-use-after-free in mutex_lock (kernel/locking/mutex.c:289) Write of size 8 at addr ffff88800721de38 by task init/1 Call Trace: mutex_lock (kernel/locking/mutex.c:289) acpi_ec_space_handler (drivers/acpi/ec.c:1362) acpi_ev_address_space_dispatch (drivers/acpi/acpica/evregion.c:293) acpi_ex_access_region (drivers/acpi/acpica/exfldio.c:246) acpi_ex_field_datum_io (drivers/acpi/acpica/exfldio.c:509) acpi_ex_extract_from_field (drivers/acpi/acpica/exfldio.c:700) acpi_ex_read_data_from_field (drivers/acpi/acpica/exfield.c:327) acpi_ex_resolve_node_to_value (drivers/acpi/acpica/exresolv.c:392) Allocated by task 1: acpi_ec_alloc (drivers/acpi/ec.c:1424) acpi_ec_add (drivers/acpi/ec.c:1692) Freed by task 1: kfree (mm/slub.c:6876) acpi_ec_add (drivers/acpi/ec.c:1751) The bug triggers on reduced-hardware EC platforms (ec->gpe < 0) when the GPIO IRQ provider defers probing. Once the stale handler exists, any unprivileged sysfs read that causes AML to touch an EC OpRegion (battery, thermal, backlight) exercises the dangling pointer. Fix this by calling ec_remove_handlers() in the error path of acpi_ec_setup() before clearing first_ec. ec_remove_handlers() checks each EC_FLAGS_* bit before acting, so it is safe to call regardless of how far ec_install_handlers() progressed: -ENODEV (handler not installed): only calls acpi_ec_stop() -EPROBE_DEFER (handler installed): removes handler, stops EC Fixes: 03e9a0e05739 ("ACPI: EC: Consolidate event handler installation code") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Link: https://patch.msgid.link/20260324165458.1337233-2-bestswngs@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit c73a58661a760373d08a6883af4f0bb5cc991a67 Author: Danilo Krummrich Date: Tue Mar 24 01:59:15 2026 +0100 spi: use generic driver_override infrastructure [ Upstream commit cc34d77dd48708d810c12bfd6f5bf03304f6c824 ] 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] Also note that we do not enable the driver_override feature of struct bus_type, as SPI - in contrast to most other buses - passes "" to sysfs_emit() when the driver_override pointer is NULL. Thus, printing "\n" instead of "(null)\n". 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: 5039563e7c25 ("spi: Add driver_override SPI device attribute") Signed-off-by: Danilo Krummrich Link: https://patch.msgid.link/20260324005919.2408620-12-dakr@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 15da4f5e10012a3f16652936159888530cc63a9e Author: Matt Roper Date: Thu Mar 19 15:30:34 2026 -0700 drm/xe: Implement recent spec updates to Wa_16025250150 [ Upstream commit 56781a4597706cd25185b1dedc38841ec6c31496 ] The hardware teams noticed that the originally documented workaround steps for Wa_16025250150 may not be sufficient to fully avoid a hardware issue. The workaround documentation has been augmented to suggest programming one additional register; make the corresponding change in the driver. Fixes: 7654d51f1fd8 ("drm/xe/xe2hpg: Add Wa_16025250150") Reviewed-by: Matt Atwood Link: https://patch.msgid.link/20260319-wa_16025250150_part2-v1-1-46b1de1a31b2@intel.com Signed-off-by: Matt Roper (cherry picked from commit a31566762d4075646a8a2214586158b681e94305) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 4e96a8440e743d71add2efefb432c52a09228d24 Author: Alice Ryhl Date: Tue Mar 24 10:49:59 2026 +0000 rust: regulator: do not assume that regulator_get() returns non-null [ Upstream commit 8121353a4bf8e38afee26299419a78ec108e14a6 ] The Rust `Regulator` abstraction uses `NonNull` to wrap the underlying `struct regulator` pointer. When `CONFIG_REGULATOR` is disabled, the C stub for `regulator_get` returns `NULL`. `from_err_ptr` does not treat `NULL` as an error, so it was passed to `NonNull::new_unchecked`, causing undefined behavior. Fix this by using a raw pointer `*mut bindings::regulator` instead of `NonNull`. This allows `inner` to be `NULL` when `CONFIG_REGULATOR` is disabled, and leverages the C stubs which are designed to handle `NULL` or are no-ops. Fixes: 9b614ceada7c ("rust: regulator: add a bare minimum regulator abstraction") Reported-by: Miguel Ojeda Closes: https://lore.kernel.org/r/20260322193830.89324-1-ojeda@kernel.org Signed-off-by: Alice Ryhl Reviewed-by: Daniel Almeida Link: https://patch.msgid.link/20260324-regulator-fix-v1-1-a5244afa3c15@google.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8f3226f00cb1f9f82c3d0b04251b465889e7fce0 Author: Jihed Chaibi Date: Sat Mar 21 02:20:11 2026 +0100 ASoC: dt-bindings: stm32: Fix incorrect compatible string in stm32h7-sai match [ Upstream commit 91049ec2e18376ec2192e73ef7be4c7110436350 ] The conditional block that defines clock constraints for the stm32h7-sai variant references "st,stm32mph7-sai", which does not match any compatible string in the enum. As a result, clock validation for the h7 variant is silently skipped. Correct the compatible string to "st,stm32h7-sai". Fixes: 8509bb1f11a1f ("ASoC: dt-bindings: add stm32mp25 support for sai") Signed-off-by: Jihed Chaibi Reviewed-by: Olivier Moysan Link: https://patch.msgid.link/20260321012011.125791-1-jihed.chaibi.dev@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8a5edc97fd9c6415ff2eff872748439a97e3c3d8 Author: Yussuf Khalil Date: Fri Mar 6 12:06:35 2026 +0000 drm/amd/display: Do not skip unrelated mode changes in DSC validation [ Upstream commit aed3d041ab061ec8a64f50a3edda0f4db7280025 ] Starting with commit 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation in atomic check"), amdgpu resets the CRTC state mode_changed flag to false when recomputing the DSC configuration results in no timing change for a particular stream. However, this is incorrect in scenarios where a change in MST/DSC configuration happens in the same KMS commit as another (unrelated) mode change. For example, the integrated panel of a laptop may be configured differently (e.g., HDR enabled/disabled) depending on whether external screens are attached. In this case, plugging in external DP-MST screens may result in the mode_changed flag being dropped incorrectly for the integrated panel if its DSC configuration did not change during precomputation in pre_validate_dsc(). At this point, however, dm_update_crtc_state() has already created new streams for CRTCs with DSC-independent mode changes. In turn, amdgpu_dm_commit_streams() will never release the old stream, resulting in a memory leak. amdgpu_dm_atomic_commit_tail() will never acquire a reference to the new stream either, which manifests as a use-after-free when the stream gets disabled later on: BUG: KASAN: use-after-free in dc_stream_release+0x25/0x90 [amdgpu] Write of size 4 at addr ffff88813d836524 by task kworker/9:9/29977 Workqueue: events drm_mode_rmfb_work_fn Call Trace: dump_stack_lvl+0x6e/0xa0 print_address_description.constprop.0+0x88/0x320 ? dc_stream_release+0x25/0x90 [amdgpu] print_report+0xfc/0x1ff ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x225/0x4e0 ? dc_stream_release+0x25/0x90 [amdgpu] kasan_report+0xe1/0x180 ? dc_stream_release+0x25/0x90 [amdgpu] kasan_check_range+0x125/0x200 dc_stream_release+0x25/0x90 [amdgpu] dc_state_destruct+0x14d/0x5c0 [amdgpu] dc_state_release.part.0+0x4e/0x130 [amdgpu] dm_atomic_destroy_state+0x3f/0x70 [amdgpu] drm_atomic_state_default_clear+0x8ee/0xf30 ? drm_mode_object_put.part.0+0xb1/0x130 __drm_atomic_state_free+0x15c/0x2d0 atomic_remove_fb+0x67e/0x980 Since there is no reliable way of figuring out whether a CRTC has unrelated mode changes pending at the time of DSC validation, remember the value of the mode_changed flag from before the point where a CRTC was marked as potentially affected by a change in DSC configuration. Reset the mode_changed flag to this earlier value instead in pre_validate_dsc(). Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5004 Fixes: 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation in atomic check") Signed-off-by: Yussuf Khalil Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher (cherry picked from commit cc7c7121ae082b7b82891baa7280f1ff2608f22b) Signed-off-by: Sasha Levin commit da06a104f0486355073ff0d1bcb1fcbebb7080d6 Author: Felix Gu Date: Sun Mar 22 21:29:56 2026 +0800 spi: meson-spicc: Fix double-put in remove path [ Upstream commit 63542bb402b7013171c9f621c28b609eda4dbf1f ] meson_spicc_probe() registers the controller with devm_spi_register_controller(), so teardown already drops the controller reference via devm cleanup. Calling spi_controller_put() again in meson_spicc_remove() causes a double-put. Fixes: 8311ee2164c5 ("spi: meson-spicc: fix memory leak in meson_spicc_remove") Signed-off-by: Felix Gu Reviewed-by: Johan Hovold Link: https://patch.msgid.link/20260322-rockchip-v1-1-fac3f0c6dad8@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7af2d06ec25b56a0d59167e956ba8d550455bfd6 Author: Cezary Rojewski Date: Fri Mar 20 11:12:17 2026 +0100 ASoC: Intel: catpt: Fix the device initialization [ Upstream commit 5a184f1cb43a8e035251c635f5c47da5dc3e3049 ] The DMA mask shall be coerced before any buffer allocations for the device are done. At the same time explain why DMA mask of 31 bits is used in the first place. Cc: Andy Shevchenko Fixes: 7a10b66a5df9 ("ASoC: Intel: catpt: Device driver lifecycle") Signed-off-by: Cezary Rojewski Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20260320101217.1243688-1-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 234a82a13886520488eb0efa0df88bdc562e9ef9 Author: Felix Gu Date: Thu Mar 19 00:12:34 2026 +0800 spi: sn-f-ospi: Fix resource leak in f_ospi_probe() [ Upstream commit ef3d549e1deb3466c61f3b01d22fc3fe3e5efb08 ] In f_ospi_probe(), when num_cs validation fails, it returns without calling spi_controller_put() on the SPI controller, which causes a resource leak. Use devm_spi_alloc_host() instead of spi_alloc_host() to ensure the SPI controller is properly freed when probe fails. Fixes: 1b74dd64c861 ("spi: Add Socionext F_OSPI SPI flash controller driver") Signed-off-by: Felix Gu Link: https://patch.msgid.link/20260319-sn-f-v1-1-33a6738d2da8@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3025ca5daa9d682b629c0c958b538e41deeb559d Author: Youngjun Park Date: Sun Mar 22 21:05:28 2026 +0900 PM: sleep: Drop spurious WARN_ON() from pm_restore_gfp_mask() [ Upstream commit a8d51efb5929ae308895455a3e496b5eca2cd143 ] Commit 35e4a69b2003f ("PM: sleep: Allow pm_restrict_gfp_mask() stacking") introduced refcount-based GFP mask management that warns when pm_restore_gfp_mask() is called with saved_gfp_count == 0. Some hibernation paths call pm_restore_gfp_mask() defensively where the GFP mask may or may not be restricted depending on the execution path. For example, the uswsusp interface invokes it in SNAPSHOT_CREATE_IMAGE, SNAPSHOT_UNFREEZE, and snapshot_release(). Before the stacking change this was a silent no-op; it now triggers a spurious WARNING. Remove the WARN_ON() wrapper from the !saved_gfp_count check while retaining the check itself, so that defensive calls remain harmless without producing false warnings. Fixes: 35e4a69b2003f ("PM: sleep: Allow pm_restrict_gfp_mask() stacking") Signed-off-by: Youngjun Park [ rjw: Subject tweak ] Link: https://patch.msgid.link/20260322120528.750178-1-youngjun.park@lge.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 13a6af01c1e3b0b019922616d59d04144d99d83a Author: Alberto Garcia Date: Mon Mar 9 18:39:41 2026 +0100 PM: hibernate: Drain trailing zero pages on userspace restore [ Upstream commit 734eba62cd32cb9ceffa09e57cdc03d761528525 ] Commit 005e8dddd497 ("PM: hibernate: don't store zero pages in the image file") added an optimization to skip zero-filled pages in the hibernation image. On restore, zero pages are handled internally by snapshot_write_next() in a loop that processes them without returning to the caller. With the userspace restore interface, writing the last non-zero page to /dev/snapshot is followed by the SNAPSHOT_ATOMIC_RESTORE ioctl. At this point there are no more calls to snapshot_write_next() so any trailing zero pages are not processed, snapshot_image_loaded() fails because handle->cur is smaller than expected, the ioctl returns -EPERM and the image is not restored. The in-kernel restore path is not affected by this because the loop in load_image() in swap.c calls snapshot_write_next() until it returns 0. It is this final call that drains any trailing zero pages. Fixed by calling snapshot_write_next() in snapshot_write_finalize(), giving the kernel the chance to drain any trailing zero pages. Fixes: 005e8dddd497 ("PM: hibernate: don't store zero pages in the image file") Signed-off-by: Alberto Garcia Acked-by: Brian Geffon Link: https://patch.msgid.link/ef5a7c5e3e3dbd17dcb20efaa0c53a47a23498bb.1773075892.git.berto@igalia.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 842aa6103b6f286e2bcee395b38807d3ae0d0b26 Author: Samasth Norway Ananda Date: Mon Mar 16 16:19:19 2026 -0700 drm/i915/gmbus: fix spurious timeout on 512-byte burst reads [ Upstream commit 08441f10f4dc09fdeb64529953ac308abc79dd38 ] When reading exactly 512 bytes with burst read enabled, the extra_byte_added path breaks out of the inner do-while without decrementing len. The outer while(len) then re-enters and gmbus_wait() times out since all data has been delivered. Decrement len before the break so the outer loop terminates correctly. Fixes: d5dc0f43f268 ("drm/i915/gmbus: Enable burst read") Signed-off-by: Samasth Norway Ananda Reviewed-by: Jani Nikula Link: https://patch.msgid.link/20260316231920.135438-2-samasth.norway.ananda@oracle.com Signed-off-by: Jani Nikula (cherry picked from commit 4ab0f09ee73fc853d00466682635f67c531f909c) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin commit 9a709b7e36324dfc1e6728eb81405470b7ae84e5 Author: Luca Leonardo Scorcia Date: Wed Feb 25 09:38:41 2026 +0000 drm/mediatek: dsi: Store driver data before invoking mipi_dsi_host_register [ Upstream commit 4cfdfeb6ac06079f92fccd977fa742d6c5b8dd3a ] The call to mipi_dsi_host_register triggers a callback to mtk_dsi_bind, which uses dev_get_drvdata to retrieve the mtk_dsi struct, so this structure needs to be stored inside the driver data before invoking it. As drvdata is currently uninitialized it leads to a crash when registering the DSI DRM encoder right after acquiring the mode_config.idr_mutex, blocking all subsequent DRM operations. Fixes the following crash during mediatek-drm probe (tested on Xiaomi Smart Clock x04g): Unable to handle kernel NULL pointer dereference at virtual address 0000000000000040 [...] Modules linked in: mediatek_drm(+) drm_display_helper cec drm_client_lib drm_dma_helper drm_kms_helper panel_simple [...] Call trace: drm_mode_object_add+0x58/0x98 (P) __drm_encoder_init+0x48/0x140 drm_encoder_init+0x6c/0xa0 drm_simple_encoder_init+0x20/0x34 [drm_kms_helper] mtk_dsi_bind+0x34/0x13c [mediatek_drm] component_bind_all+0x120/0x280 mtk_drm_bind+0x284/0x67c [mediatek_drm] try_to_bring_up_aggregate_device+0x23c/0x320 __component_add+0xa4/0x198 component_add+0x14/0x20 mtk_dsi_host_attach+0x78/0x100 [mediatek_drm] mipi_dsi_attach+0x2c/0x50 panel_simple_dsi_probe+0x4c/0x9c [panel_simple] mipi_dsi_drv_probe+0x1c/0x28 really_probe+0xc0/0x3dc __driver_probe_device+0x80/0x160 driver_probe_device+0x40/0x120 __device_attach_driver+0xbc/0x17c bus_for_each_drv+0x88/0xf0 __device_attach+0x9c/0x1cc device_initial_probe+0x54/0x60 bus_probe_device+0x34/0xa0 device_add+0x5b0/0x800 mipi_dsi_device_register_full+0xdc/0x16c mipi_dsi_host_register+0xc4/0x17c mtk_dsi_probe+0x10c/0x260 [mediatek_drm] platform_probe+0x5c/0xa4 really_probe+0xc0/0x3dc __driver_probe_device+0x80/0x160 driver_probe_device+0x40/0x120 __driver_attach+0xc8/0x1f8 bus_for_each_dev+0x7c/0xe0 driver_attach+0x24/0x30 bus_add_driver+0x11c/0x240 driver_register+0x68/0x130 __platform_register_drivers+0x64/0x160 mtk_drm_init+0x24/0x1000 [mediatek_drm] do_one_initcall+0x60/0x1d0 do_init_module+0x54/0x240 load_module+0x1838/0x1dc0 init_module_from_file+0xd8/0xf0 __arm64_sys_finit_module+0x1b4/0x428 invoke_syscall.constprop.0+0x48/0xc8 do_el0_svc+0x3c/0xb8 el0_svc+0x34/0xe8 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 52800022 941004ab 2a0003f3 37f80040 (29005a80) Fixes: e4732b590a77 ("drm/mediatek: dsi: Register DSI host after acquiring clocks and PHY") Signed-off-by: Luca Leonardo Scorcia Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/dri-devel/patch/20260225094047.76780-1-l.scorcia@gmail.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit f8afc292d4bc18d67e69c4f32962e610c3e3740c Author: Mike Rapoport (Microsoft) Date: Fri Mar 20 15:59:48 2026 +0200 x86/efi: efi_unmap_boot_services: fix calculation of ranges_to_free size [ Upstream commit 217c0a5c177a3d4f7c8497950cbf5c36756e8bbb ] ranges_to_free array should have enough room to store the entire EFI memmap plus an extra element for NULL entry. The calculation of this array size wrongly adds 1 to the overall size instead of adding 1 to the number of elements. Add parentheses to properly size the array. Reported-by: Guenter Roeck Fixes: a4b0bf6a40f3 ("x86/efi: defer freeing of boot services memory") Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit a8b66cf9ba3c718c51af1b28a88cfa1684c6c2d5 Author: Yihang Li Date: Tue Mar 17 14:31:47 2026 +0800 scsi: scsi_transport_sas: Fix the maximum channel scanning issue [ Upstream commit d71afa9deb4d413232ba16d693f7d43b321931b4 ] After commit 37c4e72b0651 ("scsi: Fix sas_user_scan() to handle wildcard and multi-channel scans"), if the device supports multiple channels (0 to shost->max_channel), user_scan() invokes updated sas_user_scan() to perform the scan behavior for a specific transfer. However, when the user specifies shost->max_channel, it will return -EINVAL, which is not expected. Fix and support specifying the scan shost->max_channel for scanning. Fixes: 37c4e72b0651 ("scsi: Fix sas_user_scan() to handle wildcard and multi-channel scans") Signed-off-by: Yihang Li Reviewed-by: John Garry Link: https://patch.msgid.link/20260317063147.2182562-1-liyihang9@huawei.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 6140239d451889669849f32bf3bd36c35992bc08 Author: Shengjiu Wang Date: Wed Mar 18 18:28:50 2026 +0800 ASoC: fsl: imx-card: initialize playback_only and capture_only [ Upstream commit ca67bd564e94aaa898a2cbb90922ca3cccd0612b ] Fix uninitialized variable playback_only and capture_only because graph_util_parse_link_direction() may not write them. Fixes: 1877c3e7937f ("ASoC: imx-card: Add playback_only or capture_only support") Suggested-by: Kuninori Morimoto Acked-by: Kuninori Morimoto Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260318102850.2794029-3-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3f08351de5ca4f2f724b86ad252fbc21289467e1 Author: Shiraz Saleem Date: Mon Mar 16 13:39:47 2026 -0500 RDMA/irdma: Harden depth calculation functions [ Upstream commit e37afcb56ae070477741fe2d6e61fc0c542cce2d ] An issue was exposed where OS can pass in U32_MAX for SQ/RQ/SRQ size. This can cause integer overflow and truncation of SQ/RQ/SRQ depth returning a success when it should have failed. Harden the functions to do all depth calculations and boundary checking in u64 sizes. Fixes: 563e1feb5f6e ("RDMA/irdma: Add SRQ support") Signed-off-by: Shiraz Saleem Signed-off-by: Tatyana Nikolova Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 0e04f3f2dca4e63f0c31a0c85bf0fff96e60eb7d Author: Tatyana Nikolova Date: Mon Mar 16 13:39:46 2026 -0500 RDMA/irdma: Return EINVAL for invalid arp index error [ Upstream commit 7221f581eefa79ead06e171044f393fb7ee22f87 ] When rdma_connect() fails due to an invalid arp index, user space rdma core reports ENOMEM which is confusing. Modify irdma_make_cm_node() to return the correct error code. Fixes: 146b9756f14c ("RDMA/irdma: Add connection manager") Signed-off-by: Tatyana Nikolova Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit cd8bcec2de5e24e05c34c9391940fda6f50e79b4 Author: Anil Samal Date: Mon Mar 16 13:39:45 2026 -0500 RDMA/irdma: Fix deadlock during netdev reset with active connections [ Upstream commit 6f52370970ac07d352a7af4089e55e0e6425f827 ] Resolve deadlock that occurs when user executes netdev reset while RDMA applications (e.g., rping) are active. The netdev reset causes ice driver to remove irdma auxiliary driver, triggering device_delete and subsequent client removal. During client removal, uverbs_client waits for QP reference count to reach zero while cma_client holds the final reference, creating circular dependency and indefinite wait in iWARP mode. Skip QP reference count wait during device reset to prevent deadlock. Fixes: c8f304d75f6c ("RDMA/irdma: Prevent QP use after free") Signed-off-by: Anil Samal Signed-off-by: Tatyana Nikolova Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 8203f295b4bcd5efe1a21b61994826a4b8208961 Author: Tatyana Nikolova Date: Mon Mar 16 13:39:44 2026 -0500 RDMA/irdma: Remove reset check from irdma_modify_qp_to_err() [ Upstream commit c45c6ebd693b944f1ffe429fdfb6cc1674c237be ] During reset, irdma_modify_qp() to error should be called to disconnect the QP. Without this fix, if not preceded by irdma_modify_qp() to error, the API call irdma_destroy_qp() gets stuck waiting for the QP refcount to go to zero, because the cm_node associated with this QP isn't disconnected. Fixes: 915cc7ac0f8e ("RDMA/irdma: Add miscellaneous utility definitions") Signed-off-by: Tatyana Nikolova Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 30d9491bbb69ff83a1abcbbe7842ec8544861732 Author: Ivan Barrera Date: Mon Mar 16 13:39:43 2026 -0500 RDMA/irdma: Clean up unnecessary dereference of event->cm_node [ Upstream commit b415399c9a024d574b65479636f0d4eb625b9abd ] The cm_node is available and the usage of cm_node and event->cm_node seems arbitrary. Clean up unnecessary dereference of event->cm_node. Fixes: 146b9756f14c ("RDMA/irdma: Add connection manager") Signed-off-by: Ivan Barrera Signed-off-by: Tatyana Nikolova Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 4c2b2ea802bc7bac3ab31ab3f3c23a375f6f1bd0 Author: Tatyana Nikolova Date: Mon Mar 16 13:39:42 2026 -0500 RDMA/irdma: Remove a NOP wait_event() in irdma_modify_qp_roce() [ Upstream commit 5e8f0239731a83753473b7aa91bda67bbdff5053 ] Remove a NOP wait_event() in irdma_modify_qp_roce() which is relevant for iWARP and likely a copy and paste artifact for RoCEv2. The wait event is for sending a reset on a TCP connection, after the reset has been requested in irdma_modify_qp(), which occurs only in iWarp mode. Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Signed-off-by: Tatyana Nikolova Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit feeabfc936d73811bc0e010bb4b375132c380516 Author: Tatyana Nikolova Date: Mon Mar 16 13:39:41 2026 -0500 RDMA/irdma: Update ibqp state to error if QP is already in error state [ Upstream commit 8c1f19a2225cf37b3f8ab0b5a8a5322291cda620 ] In irdma_modify_qp() update ibqp state to error if the irdma QP is already in error state, otherwise the ibqp state which is visible to the consumer app remains stale. Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Signed-off-by: Tatyana Nikolova Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 3cb88c12461b71c7d9c604aa2e6a9a477ecfa147 Author: Jacob Moroni Date: Mon Mar 16 13:39:38 2026 -0500 RDMA/irdma: Initialize free_qp completion before using it [ Upstream commit 11a95521fb93c91e2d4ef9d53dc80ef0a755549b ] In irdma_create_qp, if ib_copy_to_udata fails, it will call irdma_destroy_qp to clean up which will attempt to wait on the free_qp completion, which is not initialized yet. Fix this by initializing the completion before the ib_copy_to_udata call. Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Signed-off-by: Jacob Moroni Signed-off-by: Tatyana Nikolova Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 9d4fe0d7586e4ed958e5cccb142dee8b652836bf Author: Geoffrey D. Bennett Date: Wed Mar 18 06:02:30 2026 +1030 ALSA: usb-audio: Exclude Scarlett 2i2 1st Gen from SKIP_IFACE_SETUP [ Upstream commit 8780f561f6717dec52351251881bff79e960eb46 ] The Focusrite Scarlett 2i2 1st Gen (1235:8006) produces distorted/silent audio when QUIRK_FLAG_SKIP_IFACE_SETUP is active, as that flag causes the feedback format to be detected as 17.15 instead of 16.16. Add a DEVICE_FLG entry for this device before the Focusrite VENDOR_FLG entry so that it gets no quirk flags, overriding the vendor-wide SKIP_IFACE_SETUP. This device doesn't have the internal mixer, Air, or Safe modes that the quirk was designed to protect. Fixes: 38c322068a26 ("ALSA: usb-audio: Add QUIRK_FLAG_SKIP_IFACE_SETUP") Reported-by: pairomaniac [https://github.com/geoffreybennett/linux-fcp/issues/54] Tested-by: pairomaniac [https://github.com/geoffreybennett/linux-fcp/issues/54] Signed-off-by: Geoffrey D. Bennett Link: https://patch.msgid.link/abmsTjKmQMKbhYtK@m.b4.vu Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit f9433abfcf8327967d6f3efc6df3386c71f73bdd Author: Ethan Tidmore Date: Fri Mar 13 23:57:30 2026 -0500 RDMA/efa: Fix possible deadlock [ Upstream commit 0f2055db7b630559870afb40fc84490816ab8ec5 ] In the error path for efa_com_alloc_comp_ctx() the semaphore assigned to &aq->avail_cmds is not released. Detected by Smatch: drivers/infiniband/hw/efa/efa_com.c:662 efa_com_cmd_exec() warn: inconsistent returns '&aq->avail_cmds' Add release for &aq->avail_cmds in efa_com_alloc_comp_ctx() error path. Fixes: ef3b06742c8a2 ("RDMA/efa: Fix use of completion ctx after free") Signed-off-by: Ethan Tidmore Link: https://patch.msgid.link/20260314045730.1143862-1-ethantidmore06@gmail.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 21ae8790e5a8b22b81e9703c17f0a2014058152b Author: Chuck Lever Date: Fri Mar 13 15:41:58 2026 -0400 RDMA/rw: Fall back to direct SGE on MR pool exhaustion [ Upstream commit 00da250c21b074ea9494c375d0117b69e5b1d0a4 ] When IOMMU passthrough mode is active, ib_dma_map_sgtable_attrs() produces no coalescing: each scatterlist page maps 1:1 to a DMA entry, so sgt.nents equals the raw page count. A 1 MB transfer yields 256 DMA entries. If that count exceeds the device's max_sgl_rd threshold (an optimization hint from mlx5 firmware), rdma_rw_io_needs_mr() steers the operation into the MR registration path. Each such operation consumes one or more MRs from a pool sized at max_rdma_ctxs -- roughly one MR per concurrent context. Under write-intensive workloads that issue many concurrent RDMA READs, the pool is rapidly exhausted, ib_mr_pool_get() returns NULL, and rdma_rw_init_one_mr() returns -EAGAIN. Upper layer protocols treat this as a fatal DMA mapping failure and tear down the connection. The max_sgl_rd check is a performance optimization, not a correctness requirement: the device can handle large SGE counts via direct posting, just less efficiently than with MR registration. When the MR pool cannot satisfy a request, falling back to the direct SGE (map_wrs) path avoids the connection reset while preserving the MR optimization for the common case where pool resources are available. Add a fallback in rdma_rw_ctx_init() so that -EAGAIN from rdma_rw_init_mr_wrs() triggers direct SGE posting instead of propagating the error. iWARP devices, which mandate MR registration for RDMA READs, and force_mr debug mode continue to treat -EAGAIN as terminal. Fixes: 00bd1439f464 ("RDMA/rw: Support threshold for registration vs scattering to local pages") Signed-off-by: Chuck Lever Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260313194201.5818-2-cel@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit a1dc886137aba40ad66b5ac68014ca23e5f07d4a Author: Sean Rhodes Date: Sun Mar 15 20:11:27 2026 +0000 ALSA: hda/realtek: Sequence GPIO2 on Star Labs StarFighter [ Upstream commit a6919f2a01f8fbf807b015e5b26aecae7db8117b ] The initial StarFighter quirk fixed the runtime suspend pop by muting speakers in the shutup callback before power-down. Further hardware validation showed that the speaker path is controlled directly by LINE2 EAPD on NID 0x1b together with GPIO2 for the external amplifier. Replace the shutup-delay workaround with explicit sequencing of those controls at playback start and stop: - assert LINE2 EAPD and drive GPIO2 high on PREPARE - deassert LINE2 EAPD and drive GPIO2 low on CLEANUP This avoids the runtime suspend pop without a sleep, and also fixes pops around G3 entry and display-manager start that the original workaround did not cover. Fixes: 1cb3c20688fc ("ALSA: hda/realtek: Fix speaker pop on Star Labs StarFighter") Tested-by: Sean Rhodes Signed-off-by: Sean Rhodes Link: https://patch.msgid.link/20260315201127.33744-1-sean@starlabs.systems Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit f710129df9fcbd9da5f131e22c308691c14ac7c6 Author: Andy Shevchenko Date: Mon Mar 2 19:43:31 2026 +0100 regmap: Synchronize cache for the page selector [ Upstream commit 09e70e4f119ff650d24c96161fd2f62ac7e424b0 ] If the selector register is represented in each page, its value according to the debugfs is stale because it gets synchronized only after the real page switch happens. Hence the regmap cache initialisation from the HW inherits outdated data in the selector register. Synchronize cache for the page selector just in time. Before (offset followed by hexdump, the first byte is selector): // Real registers 18: 05 ff 00 00 ff 0f 00 00 f0 00 00 00 ... // Virtual (per port) 40: 05 ff 00 00 e0 e0 00 00 00 00 00 1f 50: 00 ff 00 00 e0 e0 00 00 00 00 00 1f 60: 01 ff 00 00 ff ff 00 00 00 00 00 00 70: 02 ff 00 00 cf f3 00 00 00 00 00 0c 80: 03 ff 00 00 00 00 00 00 00 00 00 ff 90: 04 ff 00 00 ff 0f 00 00 f0 00 00 00 After: // Real registers 18: 05 ff 00 00 ff 0f 00 00 f0 00 00 00 ... // Virtual (per port) 40: 00 ff 00 00 e0 e0 00 00 00 00 00 1f 50: 01 ff 00 00 e0 e0 00 00 00 00 00 1f 60: 02 ff 00 00 ff ff 00 00 00 00 00 00 70: 03 ff 00 00 cf f3 00 00 00 00 00 0c 80: 04 ff 00 00 00 00 00 00 00 00 00 ff 90: 05 ff 00 00 ff 0f 00 00 f0 00 00 00 Fixes: 6863ca622759 ("regmap: Add support for register indirect addressing.") Signed-off-by: Andy Shevchenko Link: https://patch.msgid.link/20260302184753.2693803-1-andriy.shevchenko@linux.intel.com Tested-by: Marek Szyprowski Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0dd98aea1c0c45987fa2dd92f988b0eb1a72c125 Author: Yonatan Nachum Date: Sun Mar 8 16:53:50 2026 +0000 RDMA/efa: Fix use of completion ctx after free [ Upstream commit ef3b06742c8a201d0e83edc9a33a89a4fe3009f8 ] On admin queue completion handling, if the admin command completed with error we print data from the completion context. The issue is that we already freed the completion context in polling/interrupts handler which means we print data from context in an unknown state (it might be already used again). Change the admin submission flow so alloc/dealloc of the context will be symmetric and dealloc will be called after any potential use of the context. Fixes: 68fb9f3e312a ("RDMA/efa: Remove redundant NULL pointer check of CQE") Reviewed-by: Daniel Kranzdorf Reviewed-by: Michael Margolin Signed-off-by: Yonatan Nachum Link: https://patch.msgid.link/20260308165350.18219-1-ynachum@amazon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 97da0d993d7c38c8fc4f88ad939436cf5c9d8069 Author: Yonatan Nachum Date: Wed Dec 10 13:06:14 2025 +0000 RDMA/efa: Improve admin completion context state machine [ Upstream commit dab5825491f7b0ea92a09390f39df0a51100f12f ] Add a new unused state to the admin completion contexts state machine instead of the occupied field. This improves the completion validity check because it now enforce the context to be in submitted state prior to completing it. Also add allocated state as a intermediate state between unused and submitted. Reviewed-by: Daniel Kranzdorf Reviewed-by: Michael Margolin Signed-off-by: Yonatan Nachum Link: https://patch.msgid.link/20251210130614.36460-3-ynachum@amazon.com Signed-off-by: Leon Romanovsky Stable-dep-of: ef3b06742c8a ("RDMA/efa: Fix use of completion ctx after free") Signed-off-by: Sasha Levin commit 26bd3a77c5ffefd417e5e3b9dec795b5de9a76af Author: Yonatan Nachum Date: Wed Dec 10 13:06:13 2025 +0000 RDMA/efa: Check stored completion CTX command ID with received one [ Upstream commit 4b01ec0f133b3fe1038dc538d6bfcbd72462d2f0 ] In admin command completion, we receive a CQE with the command ID which is constructed from context index and entropy bits from the admin queue producer counter. To try to detect memory corruptions in the received CQE, validate the full command ID of the fetched context with the CQE command ID. If there is a mismatch, complete the CQE with error. Also use LSBs of the admin queue producer counter to better detect entropy mismatch between smaller number of commands. Reviewed-by: Daniel Kranzdorf Reviewed-by: Michael Margolin Signed-off-by: Yonatan Nachum Link: https://patch.msgid.link/20251210130614.36460-2-ynachum@amazon.com Signed-off-by: Leon Romanovsky Stable-dep-of: ef3b06742c8a ("RDMA/efa: Fix use of completion ctx after free") Signed-off-by: Sasha Levin commit 7ff87da099210856cbfe2f2f7f52ddfa57af4f0c Author: Paolo Valerio Date: Mon Mar 23 20:16:34 2026 +0100 net: macb: use the current queue number for stats [ Upstream commit 72d96e4e24bbefdcfbc68bdb9341a05d8f5cb6e5 ] There's a potential mismatch between the memory reserved for statistics and the amount of memory written. gem_get_sset_count() correctly computes the number of stats based on the active queues, whereas gem_get_ethtool_stats() indiscriminately copies data using the maximum number of queues, and in the case the number of active queues is less than MACB_MAX_QUEUES, this results in a OOB write as observed in the KASAN splat. ================================================================== BUG: KASAN: vmalloc-out-of-bounds in gem_get_ethtool_stats+0x54/0x78 [macb] Write of size 760 at addr ffff80008080b000 by task ethtool/1027 CPU: [...] Tainted: [E]=UNSIGNED_MODULE Hardware name: raspberrypi rpi/rpi, BIOS 2025.10 10/01/2025 Call trace: show_stack+0x20/0x38 (C) dump_stack_lvl+0x80/0xf8 print_report+0x384/0x5e0 kasan_report+0xa0/0xf0 kasan_check_range+0xe8/0x190 __asan_memcpy+0x54/0x98 gem_get_ethtool_stats+0x54/0x78 [macb 926c13f3af83b0c6fe64badb21ec87d5e93fcf65] dev_ethtool+0x1220/0x38c0 dev_ioctl+0x4ac/0xca8 sock_do_ioctl+0x170/0x1d8 sock_ioctl+0x484/0x5d8 __arm64_sys_ioctl+0x12c/0x1b8 invoke_syscall+0xd4/0x258 el0_svc_common.constprop.0+0xb4/0x240 do_el0_svc+0x48/0x68 el0_svc+0x40/0xf8 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1b0/0x1b8 The buggy address belongs to a 1-page vmalloc region starting at 0xffff80008080b000 allocated at dev_ethtool+0x11f0/0x38c0 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff00000a333000 pfn:0xa333 flags: 0x7fffc000000000(node=0|zone=0|lastcpupid=0x1ffff) raw: 007fffc000000000 0000000000000000 dead000000000122 0000000000000000 raw: ffff00000a333000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff80008080b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff80008080b100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff80008080b180: 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffff80008080b200: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffff80008080b280: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ================================================================== Fix it by making sure the copied size only considers the active number of queues. Fixes: 512286bbd4b7 ("net: macb: Added some queue statistics") Signed-off-by: Paolo Valerio Reviewed-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260323191634.2185840-1-pvalerio@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c6cb41eaae875501eaaa487b8db6539feb092292 Author: David Carlier Date: Wed Mar 25 14:11:08 2026 +0100 netfilter: ctnetlink: use netlink policy range checks [ Upstream commit 8f15b5071b4548b0aafc03b366eb45c9c6566704 ] Replace manual range and mask validations with netlink policy annotations in ctnetlink code paths, so that the netlink core rejects invalid values early and can generate extack errors. - CTA_PROTOINFO_TCP_STATE: reject values > TCP_CONNTRACK_SYN_SENT2 at policy level, removing the manual >= TCP_CONNTRACK_MAX check. - CTA_PROTOINFO_TCP_WSCALE_ORIGINAL/REPLY: reject values > TCP_MAX_WSCALE (14). The normal TCP option parsing path already clamps to this value, but the ctnetlink path accepted 0-255, causing undefined behavior when used as a u32 shift count. - CTA_FILTER_ORIG_FLAGS/REPLY_FLAGS: use NLA_POLICY_MASK with CTA_FILTER_F_ALL, removing the manual mask checks. - CTA_EXPECT_FLAGS: use NLA_POLICY_MASK with NF_CT_EXPECT_MASK, adding a new mask define grouping all valid expect flags. Extracted from a broader nf-next patch by Florian Westphal, scoped to ctnetlink for the fixes tree. Fixes: c8e2078cfe41 ("[NETFILTER]: ctnetlink: add support for internal tcp connection tracking flags handling") Signed-off-by: David Carlier Co-developed-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 01f34a80ac23ae90b1909b94b4ed05343a62f646 Author: Weiming Shi Date: Wed Mar 25 14:11:07 2026 +0100 netfilter: nf_conntrack_sip: fix use of uninitialized rtp_addr in process_sdp [ Upstream commit 6a2b724460cb67caed500c508c2ae5cf012e4db4 ] process_sdp() declares union nf_inet_addr rtp_addr on the stack and passes it to the nf_nat_sip sdp_session hook after walking the SDP media descriptions. However rtp_addr is only initialized inside the media loop when a recognized media type with a non-zero port is found. If the SDP body contains no m= lines, only inactive media sections (m=audio 0 ...) or only unrecognized media types, rtp_addr is never assigned. Despite that, the function still calls hooks->sdp_session() with &rtp_addr, causing nf_nat_sdp_session() to format the stale stack value as an IP address and rewrite the SDP session owner and connection lines with it. With CONFIG_INIT_STACK_ALL_ZERO (default on most distributions) this results in the session-level o= and c= addresses being rewritten to 0.0.0.0 for inactive SDP sessions. Without stack auto-init the rewritten address is whatever happened to be on the stack. Fix this by pre-initializing rtp_addr from the session-level connection address (caddr) when available, and tracking via a have_rtp_addr flag whether any valid address was established. Skip the sdp_session hook entirely when no valid address exists. Fixes: 4ab9e64e5e3c ("[NETFILTER]: nf_nat_sip: split up SDP mangling") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 9ca8c7452493d915f9bbf2f39331e6c583d07a23 Author: Pablo Neira Ayuso Date: Wed Mar 25 14:11:06 2026 +0100 netfilter: nf_conntrack_expect: skip expectations in other netns via proc [ Upstream commit 3db5647984de03d9cae0dcddb509b058351f0ee4 ] Skip expectations that do not reside in this netns. Similar to e77e6ff502ea ("netfilter: conntrack: do not dump other netns's conntrack entries via proc"). Fixes: 9b03f38d0487 ("netfilter: netns nf_conntrack: per-netns expectations") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 53d8899452d9b660f68bb45b9d92c69cde1d4bf8 Author: Pablo Neira Ayuso Date: Wed Mar 25 14:11:01 2026 +0100 netfilter: nft_set_rbtree: revisit array resize logic [ Upstream commit fafdd92b9e30fe057740c5bb5cd4f92ecea9bf26 ] Chris Arges reports high memory consumption with thousands of containers, this patch revisits the array allocation logic. For anonymous sets, start by 16 slots (which takes 256 bytes on x86_64). Expand it by x2 until threshold of 512 slots is reached, over that threshold, expand it by x1.5. For non-anonymous set, start by 1024 slots in the array (which takes 16 Kbytes initially on x86_64). Expand it by x1.5. Use set->ndeact to subtract deactivated elements when calculating the number of the slots in the array, otherwise the array size array gets increased artifically. Add special case shrink logic to deal with flush set too. The shrink logic is skipped by anonymous sets. Use check_add_overflow() to calculate the new array size. Add a WARN_ON_ONCE check to make sure elements fit into the new array size. Reported-by: Chris Arges Fixes: 7e43e0a1141d ("netfilter: nft_set_rbtree: translate rbtree to array for binary search") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit d8795fde1f78669a87c87ac29fceab2f104daa8c Author: Ren Wei Date: Wed Mar 25 14:11:00 2026 +0100 netfilter: ip6t_rt: reject oversized addrnr in rt_mt6_check() [ Upstream commit 9d3f027327c2fa265f7f85ead41294792c3296ed ] Reject rt match rules whose addrnr exceeds IP6T_RT_HOPS. rt_mt6() expects addrnr to stay within the bounds of rtinfo->addrs[]. Validate addrnr during rule installation so malformed rules are rejected before the match logic can use an out-of-range value. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Yifan Wu Reported-by: Juefei Pu Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Tested-by: Yuhang Zheng Signed-off-by: Ren Wei Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit c9f6c51d36482805ac3ffadb9663fe775a13e926 Author: Weiming Shi Date: Wed Mar 25 14:10:58 2026 +0100 netfilter: nfnetlink_log: fix uninitialized padding leak in NFULA_PAYLOAD [ Upstream commit 52025ebaa29f4eb4ed8bf92ce83a68f24ab7fdf7 ] __build_packet_message() manually constructs the NFULA_PAYLOAD netlink attribute using skb_put() and skb_copy_bits(), bypassing the standard nla_reserve()/nla_put() helpers. While nla_total_size(data_len) bytes are allocated (including NLA alignment padding), only data_len bytes of actual packet data are copied. The trailing nla_padlen(data_len) bytes (1-3 when data_len is not 4-byte aligned) are never initialized, leaking stale heap contents to userspace via the NFLOG netlink socket. Replace the manual attribute construction with nla_reserve(), which handles the tailroom check, header setup, and padding zeroing via __nla_reserve(). The subsequent skb_copy_bits() fills in the payload data on top of the properly initialized attribute. Fixes: df6fb868d611 ("[NETFILTER]: nfnetlink: convert to generic netlink attribute functions") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 9f557c7eae127b44d2e863917dc986a4b6cb1269 Author: Chuck Lever Date: Tue Mar 24 08:53:23 2026 -0400 tls: Purge async_hold in tls_decrypt_async_wait() [ Upstream commit 84a8335d8300576f1b377ae24abca1d9f197807f ] The async_hold queue pins encrypted input skbs while the AEAD engine references their scatterlist data. Once tls_decrypt_async_wait() returns, every AEAD operation has completed and the engine no longer references those skbs, so they can be freed unconditionally. A subsequent patch adds batch async decryption to tls_sw_read_sock(), introducing a new call site that must drain pending AEAD operations and release held skbs. Move __skb_queue_purge(&ctx->async_hold) into tls_decrypt_async_wait() so the purge is centralized and every caller -- recvmsg's drain path, the -EBUSY fallback in tls_do_decryption(), and the new read_sock batch path -- releases held skbs on synchronization without each site managing the purge independently. This fixes a leak when tls_strp_msg_hold() fails part-way through, after having added some cloned skbs to the async_hold queue. tls_decrypt_sg() will then call tls_decrypt_async_wait() to process all pending decrypts, and drop back to synchronous mode, but tls_sw_recvmsg() only flushes the async_hold queue when one record has been processed in "fully-async" mode, which may not be the case here. Signed-off-by: Chuck Lever Reported-by: Yiming Qian Fixes: b8a6ff84abbc ("tls: wait for pending async decryptions if tls_strp_msg_hold fails") Link: https://patch.msgid.link/20260324-tls-read-sock-v5-1-5408befe5774@oracle.com [pabeni@redhat.com: added leak comment] Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1019028eb124564cf7bca58a16f1df8a1ca30726 Author: Pengpeng Hou Date: Wed Mar 25 08:42:45 2026 +0800 Bluetooth: btusb: clamp SCO altsetting table indices [ Upstream commit 129fa608b6ad08b8ab7178eeb2ec272c993aaccc ] btusb_work() maps the number of active SCO links to USB alternate settings through a three-entry lookup table when CVSD traffic uses transparent voice settings. The lookup currently indexes alts[] with data->sco_num - 1 without first constraining sco_num to the number of available table entries. While the table only defines alternate settings for up to three SCO links, data->sco_num comes from hci_conn_num() and is used directly. Cap the lookup to the last table entry before indexing it so the driver keeps selecting the highest supported alternate setting without reading past alts[]. Fixes: baac6276c0a9 ("Bluetooth: btusb: handle mSBC audio over USB Endpoints") Signed-off-by: Pengpeng Hou Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 900e4db5385ec2cacd372345a80ab9c8e105b3a3 Author: Hyunwoo Kim Date: Fri Mar 20 20:23:10 2026 +0900 Bluetooth: L2CAP: Fix ERTM re-init and zero pdu_len infinite loop [ Upstream commit 25f420a0d4cfd61d3d23ec4b9c56d9f443d91377 ] l2cap_config_req() processes CONFIG_REQ for channels in BT_CONNECTED state to support L2CAP reconfiguration (e.g. MTU changes). However, since both CONF_INPUT_DONE and CONF_OUTPUT_DONE are already set from the initial configuration, the reconfiguration path falls through to l2cap_ertm_init(), which re-initializes tx_q, srej_q, srej_list, and retrans_list without freeing the previous allocations and sets chan->sdu to NULL without freeing the existing skb. This leaks all previously allocated ERTM resources. Additionally, l2cap_parse_conf_req() does not validate the minimum value of remote_mps derived from the RFC max_pdu_size option. A zero value propagates to l2cap_segment_sdu() where pdu_len becomes zero, causing the while loop to never terminate since len is never decremented, exhausting all available memory. Fix the double-init by skipping l2cap_ertm_init() and l2cap_chan_ready() when the channel is already in BT_CONNECTED state, while still allowing the reconfiguration parameters to be updated through l2cap_parse_conf_req(). Also add a pdu_len zero check in l2cap_segment_sdu() as a safeguard. Fixes: 96298f640104 ("Bluetooth: L2CAP: handle l2cap config request during open state") Signed-off-by: Hyunwoo Kim Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 3f26ecbd9cde621dd94be7ef252c7210b965a5c7 Author: Hyunwoo Kim Date: Fri Mar 20 20:01:26 2026 +0900 Bluetooth: L2CAP: Fix deadlock in l2cap_conn_del() [ Upstream commit 00fdebbbc557a2fc21321ff2eaa22fd70c078608 ] l2cap_conn_del() calls cancel_delayed_work_sync() for both info_timer and id_addr_timer while holding conn->lock. However, the work functions l2cap_info_timeout() and l2cap_conn_update_id_addr() both acquire conn->lock, creating a potential AB-BA deadlock if the work is already executing when l2cap_conn_del() takes the lock. Move the work cancellations before acquiring conn->lock and use disable_delayed_work_sync() to additionally prevent the works from being rearmed after cancellation, consistent with the pattern used in hci_conn_del(). Fixes: ab4eedb790ca ("Bluetooth: L2CAP: Fix corrupted list in hci_chan_del") Signed-off-by: Hyunwoo Kim Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit ea6cf86167b3972caa68972d2a1ad43ecbbb8331 Author: Luiz Augusto von Dentz Date: Wed Jan 21 16:39:44 2026 -0500 Bluetooth: L2CAP: Fix not tracking outstanding TX ident [ Upstream commit 6c3ea155e5ee3e56606233acde8309afda66d483 ] This attempts to proper track outstanding request by using struct ida and allocating from it in l2cap_get_ident using ida_alloc_range which would reuse ids as they are free, then upon completion release the id using ida_free. This fixes the qualification test case L2CAP/COS/CED/BI-29-C which attempts to check if the host stack is able to work after 256 attempts to connect which requires Ident field to use the full range of possible values in order to pass the test. Link: https://github.com/bluez/bluez/issues/1829 Signed-off-by: Luiz Augusto von Dentz Reviewed-by: Paul Menzel Stable-dep-of: 00fdebbbc557 ("Bluetooth: L2CAP: Fix deadlock in l2cap_conn_del()") Signed-off-by: Sasha Levin commit 66696648af477dc87859e5e4b607112f5f29d010 Author: Cen Zhang Date: Wed Mar 18 20:54:03 2026 +0800 Bluetooth: btintel: serialize btintel_hw_error() with hci_req_sync_lock [ Upstream commit 94d8e6fe5d0818e9300e514e095a200bd5ff93ae ] btintel_hw_error() issues two __hci_cmd_sync() calls (HCI_OP_RESET and Intel exception-info retrieval) without holding hci_req_sync_lock(). This lets it race against hci_dev_do_close() -> btintel_shutdown_combined(), which also runs __hci_cmd_sync() under the same lock. When both paths manipulate hdev->req_status/req_rsp concurrently, the close path may free the response skb first, and the still-running hw_error path hits a slab-use-after-free in kfree_skb(). Wrap the whole recovery sequence in hci_req_sync_lock/unlock so it is serialized with every other synchronous HCI command issuer. Below is the data race report and the kasan report: BUG: data-race in __hci_cmd_sync_sk / btintel_shutdown_combined read of hdev->req_rsp at net/bluetooth/hci_sync.c:199 by task kworker/u17:1/83: __hci_cmd_sync_sk+0x12f2/0x1c30 net/bluetooth/hci_sync.c:200 __hci_cmd_sync+0x55/0x80 net/bluetooth/hci_sync.c:223 btintel_hw_error+0x114/0x670 drivers/bluetooth/btintel.c:254 hci_error_reset+0x348/0xa30 net/bluetooth/hci_core.c:1030 write/free by task ioctl/22580: btintel_shutdown_combined+0xd0/0x360 drivers/bluetooth/btintel.c:3648 hci_dev_close_sync+0x9ae/0x2c10 net/bluetooth/hci_sync.c:5246 hci_dev_do_close+0x232/0x460 net/bluetooth/hci_core.c:526 BUG: KASAN: slab-use-after-free in sk_skb_reason_drop+0x43/0x380 net/core/skbuff.c:1202 Read of size 4 at addr ffff888144a738dc by task kworker/u17:1/83: __hci_cmd_sync_sk+0x12f2/0x1c30 net/bluetooth/hci_sync.c:200 __hci_cmd_sync+0x55/0x80 net/bluetooth/hci_sync.c:223 btintel_hw_error+0x186/0x670 drivers/bluetooth/btintel.c:260 Fixes: 973bb97e5aee ("Bluetooth: btintel: Add generic function for handling hardware errors") Signed-off-by: Cen Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 5c7cd74673bcb0d3fe29f4af3f79314f44c05e51 Author: Zhang Chen Date: Thu Mar 19 17:32:11 2026 +0800 Bluetooth: L2CAP: Fix send LE flow credits in ACL link [ Upstream commit f39f905e55f529b036321220af1ba4f4085564a5 ] When the L2CAP channel mode is L2CAP_MODE_ERTM/L2CAP_MODE_STREAMING, l2cap_publish_rx_avail will be called and le flow credits will be sent in l2cap_chan_rx_avail, even though the link type is ACL. The logs in question as follows: > ACL Data RX: Handle 129 flags 0x02 dlen 12 L2CAP: Unknown (0x16) ident 4 len 4 40 00 ed 05 < ACL Data TX: Handle 129 flags 0x00 dlen 10 L2CAP: Command Reject (0x01) ident 4 len 2 Reason: Command not understood (0x0000) Bluetooth: Unknown BR/EDR signaling command 0x16 Bluetooth: Wrong link type (-22) Fixes: ce60b9231b66 ("Bluetooth: compute LE flow credits based on recvbuf space") Signed-off-by: Zhang Chen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 4f23cceb35000f50bcdf3837c6c6ed6cd7090e82 Author: Miguel Ojeda Date: Wed Mar 25 02:55:48 2026 +0100 dma-mapping: add missing `inline` for `dma_free_attrs` [ Upstream commit 2cdaff22ed26f1e619aa2b43f27bb84f2c6ef8f8 ] Under an UML build for an upcoming series [1], I got `-Wstatic-in-inline` for `dma_free_attrs`: BINDGEN rust/bindings/bindings_generated.rs - due to target missing In file included from rust/helpers/helpers.c:59: rust/helpers/dma.c:17:2: warning: static function 'dma_free_attrs' is used in an inline function with external linkage [-Wstatic-in-inline] 17 | dma_free_attrs(dev, size, cpu_addr, dma_handle, attrs); | ^ rust/helpers/dma.c:12:1: note: use 'static' to give inline function 'rust_helper_dma_free_attrs' internal linkage 12 | __rust_helper void rust_helper_dma_free_attrs(struct device *dev, size_t size, | ^ | static The issue is that `dma_free_attrs` was not marked `inline` when it was introduced alongside the rest of the stubs. Thus mark it. Fixes: ed6ccf10f24b ("dma-mapping: properly stub out the DMA API for !CONFIG_HAS_DMA") Closes: https://lore.kernel.org/rust-for-linux/20260322194616.89847-1-ojeda@kernel.org/ [1] Signed-off-by: Miguel Ojeda Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20260325015548.70912-1-ojeda@kernel.org Signed-off-by: Sasha Levin commit 064fede3ae78c79bfb3d08703a2b8317cabd5ada Author: Sabrina Dubroca Date: Mon Mar 23 16:19:43 2026 +0100 rtnetlink: fix leak of SRCU struct in rtnl_link_register [ Upstream commit 09474055f2619be9445ba4245e4013741ed01a5e ] Commit 6b57ff21a310 ("rtnetlink: Protect link_ops by mutex.") swapped the EEXIST check with the init_srcu_struct, but didn't add cleanup of the SRCU struct we just allocated in case of error. Fixes: 6b57ff21a310 ("rtnetlink: Protect link_ops by mutex.") Signed-off-by: Sabrina Dubroca Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/e77fe499f9a58c547b33b5212b3596dad417cec6.1774025341.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4e27807943b116d1066f32767c1c7af167bc1fb3 Author: Thangaraj Samynathan Date: Mon Mar 23 12:23:45 2026 +0530 net: lan743x: fix duplex configuration in mac_link_up [ Upstream commit 71399707876b93240f236f48b8062f3423a5fe97 ] The driver does not explicitly configure the MAC duplex mode when bringing the link up. As a result, the MAC may retain a stale duplex setting from a previous link state, leading to duplex mismatches with the link partner and degraded network performance. Update lan743x_phylink_mac_link_up() to set or clear the MAC_CR_DPX_ bit according to the negotiated duplex mode. This ensures the MAC configuration is consistent with the phylink resolved state. Fixes: a5f199a8d8a03 ("net: lan743x: Migrate phylib to phylink") Signed-off-by: Thangaraj Samynathan Reviewed-by: Russell King (Oracle) Link: https://patch.msgid.link/20260323065345.144915-1-thangaraj.s@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0a7468ed49a6b65d34abcc6eb60e15f7f6d34da0 Author: Jiayuan Chen Date: Fri Mar 20 15:21:26 2026 +0800 team: fix header_ops type confusion with non-Ethernet ports [ Upstream commit 425000dbf17373a4ab8be9428f5dc055ef870a56 ] Similar to commit 950803f72547 ("bonding: fix type confusion in bond_setup_by_slave()") team has the same class of header_ops type confusion. For non-Ethernet ports, team_setup_by_port() copies port_dev->header_ops directly. When the team device later calls dev_hard_header() or dev_parse_header(), these callbacks can run with the team net_device instead of the real lower device, so netdev_priv(dev) is interpreted as the wrong private type and can crash. The syzbot report shows a crash in bond_header_create(), but the root cause is in team: the topology is gre -> bond -> team, and team calls the inherited header_ops with its own net_device instead of the lower device, so bond_header_create() receives a team device and interprets netdev_priv() as bonding private data, causing a type confusion crash. Fix this by introducing team header_ops wrappers for create/parse, selecting a team port under RCU, and calling the lower device callbacks with port->dev, so each callback always sees the correct net_device context. Also pass the selected lower device to the lower parse callback, so recursion is bounded in stacked non-Ethernet topologies and parse callbacks always run with the correct device context. Fixes: 1d76efe1577b ("team: add support for non-ethernet devices") Reported-by: syzbot+3d8bc31c45e11450f24c@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/69b46af7.050a0220.36eb34.000e.GAE@google.com/T/ Cc: Jiayuan Chen Signed-off-by: Jiayuan Chen Link: https://patch.msgid.link/20260320072139.134249-2-jiayuan.chen@linux.dev Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit a728914446237a577caeebe5be9a6807648ccbc4 Author: Xuan Zhuo Date: Fri Mar 20 10:18:18 2026 +0800 virtio-net: correct hdr_len handling for tunnel gso [ Upstream commit 6c860dc02a8e60b438e26940227dfa641fcdb66a ] The commit a2fb4bc4e2a6a03 ("net: implement virtio helpers to handle UDP GSO tunneling.") introduces support for the UDP GSO tunnel feature in virtio-net. The virtio spec says: If the \field{gso_type} has the VIRTIO_NET_HDR_GSO_UDP_TUNNEL_IPV4 bit or VIRTIO_NET_HDR_GSO_UDP_TUNNEL_IPV6 bit set, \field{hdr_len} accounts for all the headers up to and including the inner transport. The commit did not update the hdr_len to include the inner transport. I observed that the "hdr_len" is 116 for this packet: 17:36:18.241105 52:55:00:d1:27:0a > 2e:2c:df:46:a9:e1, ethertype IPv4 (0x0800), length 2912: (tos 0x0, ttl 64, id 45197, offset 0, flags [none], proto UDP (17), length 2898) 192.168.122.100.50613 > 192.168.122.1.4789: [bad udp cksum 0x8106 -> 0x26a0!] VXLAN, flags [I] (0x08), vni 1 fa:c3:ba:82:05:ee > ce:85:0c:31:77:e5, ethertype IPv4 (0x0800), length 2862: (tos 0x0, ttl 64, id 14678, offset 0, flags [DF], proto TCP (6), length 2848) 192.168.3.1.49880 > 192.168.3.2.9898: Flags [P.], cksum 0x9266 (incorrect -> 0xaa20), seq 515667:518463, ack 1, win 64, options [nop,nop,TS val 2990048824 ecr 2798801412], length 2796 116 = 14(mac) + 20(ip) + 8(udp) + 8(vxlan) + 14(inner mac) + 20(inner ip) + 32(innner tcp) Fixes: a2fb4bc4e2a6a03 ("net: implement virtio helpers to handle UDP GSO tunneling.") Signed-off-by: Xuan Zhuo Link: https://patch.msgid.link/20260320021818.111741-3-xuanzhuo@linux.alibaba.com Acked-by: Michael S. Tsirkin Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 5f217e718236a35b77553f8828f8b55c18ac4c5b Author: Xuan Zhuo Date: Fri Mar 20 10:18:17 2026 +0800 virtio-net: correct hdr_len handling for VIRTIO_NET_F_GUEST_HDRLEN [ Upstream commit 38ec410b99a5ee6566f75650ce3d4fd632940fd0 ] The commit be50da3e9d4a ("net: virtio_net: implement exact header length guest feature") introduces support for the VIRTIO_NET_F_GUEST_HDRLEN feature in virtio-net. This feature requires virtio-net to set hdr_len to the actual header length of the packet when transmitting, the number of bytes from the start of the packet to the beginning of the transport-layer payload. However, in practice, hdr_len was being set using skb_headlen(skb), which is clearly incorrect. This commit fixes that issue. Fixes: be50da3e9d4a ("net: virtio_net: implement exact header length guest feature") Signed-off-by: Xuan Zhuo Link: https://patch.msgid.link/20260320021818.111741-2-xuanzhuo@linux.alibaba.com Acked-by: Michael S. Tsirkin Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 2fefa595d484e16a9662c0fdcbf1fdaed7b63b04 Author: Wei Fang Date: Fri Mar 20 17:42:22 2026 +0800 net: enetc: fix the output issue of 'ethtool --show-ring' [ Upstream commit 70b439bf06f6a12e491f827fa81a9887a11501f9 ] Currently, enetc_get_ringparam() only provides rx_pending and tx_pending, but 'ethtool --show-ring' no longer displays these fields. Because the ringparam retrieval path has moved to the new netlink interface, where rings_fill_reply() emits the *x_pending only if the *x_max_pending values are non-zero. So rx_max_pending and tx_max_pending to are added to enetc_get_ringparam() to fix the issue. Note that the maximum tx/rx ring size of hardware is 64K, but we haven't added set_ringparam() to make the ring size configurable. To avoid users mistakenly believing that the ring size can be increased, so set the *x_max_pending to priv->*x_bd_count. Fixes: e4a1717b677c ("ethtool: provide ring sizes with RINGS_GET request") Signed-off-by: Wei Fang Link: https://patch.msgid.link/20260320094222.706339-1-wei.fang@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 18d84c45def3671d5c89fbdd5d4ab8a3217fe4b4 Author: Martin KaFai Lau Date: Thu Mar 19 11:18:17 2026 -0700 udp: Fix wildcard bind conflict check when using hash2 [ Upstream commit e537dd15d0d4ad989d56a1021290f0c674dd8b28 ] When binding a udp_sock to a local address and port, UDP uses two hashes (udptable->hash and udptable->hash2) for collision detection. The current code switches to "hash2" when hslot->count > 10. "hash2" is keyed by local address and local port. "hash" is keyed by local port only. The issue can be shown in the following bind sequence (pseudo code): bind(fd1, "[fd00::1]:8888") bind(fd2, "[fd00::2]:8888") bind(fd3, "[fd00::3]:8888") bind(fd4, "[fd00::4]:8888") bind(fd5, "[fd00::5]:8888") bind(fd6, "[fd00::6]:8888") bind(fd7, "[fd00::7]:8888") bind(fd8, "[fd00::8]:8888") bind(fd9, "[fd00::9]:8888") bind(fd10, "[fd00::10]:8888") /* Correctly return -EADDRINUSE because "hash" is used * instead of "hash2". udp_lib_lport_inuse() detects the * conflict. */ bind(fail_fd, "[::]:8888") /* After one more socket is bound to "[fd00::11]:8888", * hslot->count exceeds 10 and "hash2" is used instead. */ bind(fd11, "[fd00::11]:8888") bind(fail_fd, "[::]:8888") /* succeeds unexpectedly */ The same issue applies to the IPv4 wildcard address "0.0.0.0" and the IPv4-mapped wildcard address "::ffff:0.0.0.0". For example, if there are existing sockets bound to "192.168.1.[1-11]:8888", then binding "0.0.0.0:8888" or "[::ffff:0.0.0.0]:8888" can also miss the conflict when hslot->count > 10. TCP inet_csk_get_port() already has the correct check in inet_use_bhash2_on_bind(). Rename it to inet_use_hash2_on_bind() and move it to inet_hashtables.h so udp.c can reuse it in this fix. Fixes: 30fff9231fad ("udp: bind() optimisation") Reported-by: Andrew Onyshchuk Signed-off-by: Martin KaFai Lau Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260319181817.1901357-1-martin.lau@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 966937039e07e72796abee0e00f22b7d2e16a472 Author: Qingfang Deng Date: Fri Mar 20 17:43:15 2026 +0800 net: airoha: add RCU lock around dev_fill_forward_path [ Upstream commit 1065913dedfd3a8269816835bfe810b6e2c28579 ] Since 0417adf367a0 ("ppp: fix race conditions in ppp_fill_forward_path") dev_fill_forward_path() should be called with RCU read lock held. This fix was applied to net, while the Airoha flowtable commit was applied to net-next, so it hadn't been an issue until net was merged into net-next. Fixes: a8bdd935d1dd ("net: airoha: Add wlan flowtable TX offload") Signed-off-by: Qingfang Deng Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260320094315.525126-1-dqfext@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d0c7cdc15fdf8c4f91aca1928e52295d175b6ec6 Author: Yochai Eisenrich Date: Thu Mar 19 22:06:10 2026 +0200 net: fix fanout UAF in packet_release() via NETDEV_UP race [ Upstream commit 42156f93d123436f2a27c468f18c966b7e5db796 ] `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617. Fixes: ce06b03e60fc ("packet: Add helpers to register/unregister ->prot_hook") Link: https://blog.calif.io/p/a-race-within-a-race-exploiting-cve Signed-off-by: Yochai Eisenrich Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260319200610.25101-1-echelonh@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 103931f6fdbbab6dbd287d6f173f9158cf978449 Author: Kuniyuki Iwashima Date: Fri Mar 20 07:23:00 2026 +0000 ipv6: Don't remove permanent routes with exceptions from tb6_gc_hlist. [ Upstream commit 4be7b99c253f0c85a255cc1db7127ba3232dfa30 ] The cited commit mechanically put fib6_remove_gc_list() just after every fib6_clean_expires() call. When a temporary route is promoted to a permanent route, there may already be exception routes tied to it. If fib6_remove_gc_list() removes the route from tb6_gc_hlist, such exception routes will no longer be aged. Let's replace fib6_remove_gc_list() with a new helper fib6_may_remove_gc_list() and use fib6_age_exceptions() there. Note that net->ipv6 is only compiled when CONFIG_IPV6 is enabled, so fib6_{add,remove,may_remove}_gc_list() are guarded. Fixes: 5eb902b8e719 ("net/ipv6: Remove expired routes with a separated list of routes.") Signed-off-by: Kuniyuki Iwashima Reviewed-by: David Ahern Link: https://patch.msgid.link/20260320072317.2561779-3-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit edf57ce04bc10457aec6b2bda1008b3bff4a588b Author: Kuniyuki Iwashima Date: Fri Mar 20 07:22:59 2026 +0000 ipv6: Remove permanent routes from tb6_gc_hlist when all exceptions expire. [ Upstream commit 6af51e9f31336632263c4680b2a3712295103e1f ] Commit 5eb902b8e719 ("net/ipv6: Remove expired routes with a separated list of routes.") introduced a per-table GC list and changed GC to iterate over that list instead of traversing the entire route table. However, it forgot to add permanent routes to tb6_gc_hlist when exception routes are added. Commit cfe82469a00f ("ipv6: add exception routes to GC list in rt6_insert_exception") fixed that issue but introduced another one. Even after all exception routes expire, the permanent routes remain in tb6_gc_hlist, potentially negating the performance benefits intended by the initial change. Let's count gc_args->more before and after rt6_age_exceptions() and remove the permanent route when the delta is 0. Note that the next patch will reuse fib6_age_exceptions(). Fixes: cfe82469a00f ("ipv6: add exception routes to GC list in rt6_insert_exception") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Xin Long Reviewed-by: David Ahern Link: https://patch.msgid.link/20260320072317.2561779-2-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bb85741d2dc2be207353a412f51b83697fcbefcf Author: Kohei Enju Date: Sat Feb 14 19:14:25 2026 +0000 iavf: fix out-of-bounds writes in iavf_get_ethtool_stats() [ Upstream commit fecacfc95f195b99c71c579a472120d0b4ed65fa ] iavf incorrectly uses real_num_tx_queues for ETH_SS_STATS. Since the value could change in runtime, we should use num_tx_queues instead. Moreover iavf_get_ethtool_stats() uses num_active_queues while iavf_get_sset_count() and iavf_get_stat_strings() use real_num_tx_queues, which triggers out-of-bounds writes when we do "ethtool -L" and "ethtool -S" simultaneously [1]. For example when we change channels from 1 to 8, Thread 3 could be scheduled before Thread 2, and out-of-bounds writes could be triggered in Thread 3: Thread 1 (ethtool -L) Thread 2 (work) Thread 3 (ethtool -S) iavf_set_channels() ... iavf_alloc_queues() -> num_active_queues = 8 iavf_schedule_finish_config() iavf_get_sset_count() real_num_tx_queues: 1 -> buffer for 1 queue iavf_get_ethtool_stats() num_active_queues: 8 -> out-of-bounds! iavf_finish_config() -> real_num_tx_queues = 8 Use immutable num_tx_queues in all related functions to avoid the issue. [1] BUG: KASAN: vmalloc-out-of-bounds in iavf_add_one_ethtool_stat+0x200/0x270 Write of size 8 at addr ffffc900031c9080 by task ethtool/5800 CPU: 1 UID: 0 PID: 5800 Comm: ethtool Not tainted 6.19.0-enjuk-08403-g8137e3db7f1c #241 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+0x6f/0xb0 print_report+0x170/0x4f3 kasan_report+0xe1/0x180 iavf_add_one_ethtool_stat+0x200/0x270 iavf_get_ethtool_stats+0x14c/0x2e0 __dev_ethtool+0x3d0c/0x5830 dev_ethtool+0x12d/0x270 dev_ioctl+0x53c/0xe30 sock_do_ioctl+0x1a9/0x270 sock_ioctl+0x3d4/0x5e0 __x64_sys_ioctl+0x137/0x1c0 do_syscall_64+0xf3/0x690 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f7da0e6e36d ... The buggy address belongs to a 1-page vmalloc region starting at 0xffffc900031c9000 allocated at __dev_ethtool+0x3cc9/0x5830 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88813a013de0 pfn:0x13a013 flags: 0x200000000000000(node=0|zone=2) raw: 0200000000000000 0000000000000000 dead000000000122 0000000000000000 raw: ffff88813a013de0 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffffc900031c8f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900031c9000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900031c9080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900031c9100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900031c9180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fixes: 64430f70ba6f ("iavf: Fix displaying queue statistics shown by ethtool") Signed-off-by: Kohei Enju Reviewed-by: Simon Horman Reviewed-by: Przemek Kitszel Reviewed-by: Paul Menzel Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 22c11774549536b93ad6f1e22ffb2d9edaf7447a Author: Petr Oros Date: Thu Feb 12 08:53:11 2026 +0100 ice: use ice_update_eth_stats() for representor stats [ Upstream commit 2526e440df2725e7328d59b835a164826f179b93 ] ice_repr_get_stats64() and __ice_get_ethtool_stats() call ice_update_vsi_stats() on the VF's src_vsi. This always returns early because ICE_VSI_DOWN is permanently set for VF VSIs - ice_up() is never called on them since queues are managed by iavf through virtchnl. In __ice_get_ethtool_stats() the original code called ice_update_vsi_stats() for all VSIs including representors, iterated over ice_gstrings_vsi_stats[] to populate the data, and then bailed out with an early return before the per-queue ring stats section. That early return was necessary because representor VSIs have no rings on the PF side - the rings belong to the VF driver (iavf), so accessing per-queue stats would be invalid. Move the representor handling to the top of __ice_get_ethtool_stats() and call ice_update_eth_stats() directly to read the hardware GLV_* counters. This matches ice_get_vf_stats() which already uses ice_update_eth_stats() for the same VF VSI in legacy mode. Apply the same fix to ice_repr_get_stats64(). Note that ice_gstrings_vsi_stats[] contains five software ring counters (rx_buf_failed, rx_page_failed, tx_linearize, tx_busy, tx_restart) that are always zero for representors since the PF never processes packets on VF rings. This is pre-existing behavior unchanged by this patch. Fixes: 7aae80cef7ba ("ice: add port representor ethtool ops and stats") Signed-off-by: Petr Oros Reviewed-by: Aleksandr Loktionov Tested-by: Patryk Holda Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 218609e1e46617646ce23d58d46fb62017acfcf4 Author: Petr Oros Date: Thu Feb 12 08:53:10 2026 +0100 ice: fix inverted ready check for VF representors [ Upstream commit ad85de0fc09eb3236e73df5acb2bc257625103f5 ] Commit 0f00a897c9fcbd ("ice: check if SF is ready in ethtool ops") refactored the VF readiness check into a generic repr->ops.ready() callback but implemented ice_repr_ready_vf() with inverted logic: return !ice_check_vf_ready_for_cfg(repr->vf); ice_check_vf_ready_for_cfg() returns 0 on success, so the negation makes ready() return non-zero when the VF is ready. All callers treat non-zero as "not ready, skip", causing ndo_get_stats64, get_drvinfo, get_strings and get_ethtool_stats to always bail out in switchdev mode. Remove the erroneous negation. The SF variant ice_repr_ready_sf() is already correct (returns !active, i.e. non-zero when not active). Fixes: 0f00a897c9fcbd ("ice: check if SF is ready in ethtool ops") Signed-off-by: Petr Oros Reviewed-by: Aleksandr Loktionov Reviewed-by: Michal Swiatkowski Tested-by: Patryk Holda Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit fe1ed519210a367db421ff6f00b905dc73e32228 Author: David McFarland Date: Thu Feb 5 19:16:24 2026 -0400 platform/x86: intel-hid: disable wakeup_mode during hibernation [ Upstream commit e02ea3ae8ee40d5835a845884c7b161a27c10bcb ] Add a freeze handler which clears wakeup_mode. This fixes aborted hibernation on Dell Precision 3880. Wakeup event detected during hibernation, rolling back This system sends power button events during hibernation, even when triggered by software. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218634 Fixes: 0c4cae1bc00d ("PM: hibernate: Avoid missing wakeup events during hibernation") Signed-off-by: David McFarland Link: https://patch.msgid.link/20260205231629.1336348-1-corngood@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit a825ab202533374744ccc029c6e16af5124ee77b Author: Alok Tiwari Date: Tue Mar 10 06:01:35 2026 -0700 platform/olpc: olpc-xo175-ec: Fix overflow error message to print inlen [ Upstream commit 2061f7b042f88d372cca79615f8425f3564c0b40 ] The command length check validates inlen (> 5), but the error message incorrectly printed resp_len. Print inlen so the log reflects the actual command length. Fixes: 0c3d931b3ab9e ("Platform: OLPC: Add XO-1.75 EC driver") Signed-off-by: Alok Tiwari Acked-by: Lubomir Rintel Reviewed-by: Randy Dunlap Link: https://patch.msgid.link/20260310130138.700687-1-alok.a.tiwari@oracle.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit eaa3dae239f2b1b9cc242f2aa9ccee05a8655d21 Author: Nathan Chancellor Date: Fri Mar 13 14:06:34 2026 -0700 platform/x86: lenovo: wmi-gamezone: Drop gz_chain_head [ Upstream commit 5a3955f3602950d1888df743a5b1889e43b5cb60 ] The gz_chain_head variable has been unused since the driver's initial addition to the tree. Its use was eliminated between v3 and v4 during development but due to the reference of gz_chain_head's wait_list member, the compiler could not warn that it was unused. After a (tip) commit ("locking/rwsem: Remove the list_head from struct rw_semaphore"), which removed a reference to the variable passed to __RWSEM_INITIALIZER(), certain configurations show an unused variable warning from the Lenovo wmi-gamezone driver: drivers/platform/x86/lenovo/wmi-gamezone.c:34:31: warning: 'gz_chain_head' defined but not used [-Wunused-variable] 34 | static BLOCKING_NOTIFIER_HEAD(gz_chain_head); | ^~~~~~~~~~~~~ include/linux/notifier.h:119:39: note: in definition of macro 'BLOCKING_NOTIFIER_HEAD' 119 | struct blocking_notifier_head name = \ | ^~~~ Remove the variable to prevent the warning from showing up. Fixes: 22024ac5366f ("platform/x86: Add Lenovo Gamezone WMI Driver") Signed-off-by: Nathan Chancellor Reviewed-by: Mark Pearson Link: https://patch.msgid.link/20260313-lenovo-wmi-gamezone-remove-gz_chain_head-v1-1-ce5231f0c6fa@kernel.org [ij: reorganized the changelog] Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit e29850b0faa815467501224c9623098fe2efcbd5 Author: Li RongQing Date: Tue Mar 3 02:46:35 2026 -0500 platform/x86: ISST: Check HWP support before MSR access [ Upstream commit 9f11d9b15efb5f77e810b6dfbeb01b4650a79eae ] On some systems, HWP can be explicitly disabled in the BIOS settings When HWP is disabled by firmware, the HWP CPUID bit is not set, and attempting to read MSR_PM_ENABLE will result in a General Protection (GP) fault. unchecked MSR access error: RDMSR from 0x770 at rIP: 0xffffffffc33db92e (disable_dynamic_sst_features+0xe/0x50 [isst_tpmi_core]) Call Trace: ? ex_handler_msr+0xf6/0x150 ? fixup_exception+0x1ad/0x340 ? gp_try_fixup_and_notify+0x1e/0xb0 ? exc_general_protection+0xc9/0x390 ? terminate_walk+0x64/0x100 ? asm_exc_general_protection+0x22/0x30 ? disable_dynamic_sst_features+0xe/0x50 [isst_tpmi_core] isst_if_def_ioctl+0xece/0x1050 [isst_tpmi_core] ? ioctl_has_perm.constprop.42+0xe0/0x130 isst_if_def_ioctl+0x10d/0x1a0 [isst_if_common] __se_sys_ioctl+0x86/0xc0 do_syscall_64+0x8a/0x100 entry_SYSCALL_64_after_hwframe+0x78/0xe2 RIP: 0033:0x7f36eaef54a7 Add a check for X86_FEATURE_HWP before accessing the MSR. If HWP is not available, return true safely. Fixes: 12a7d2cb811d ("platform/x86: ISST: Add SST-CP support via TPMI") Signed-off-by: Li RongQing Acked-by: Srinivas Pandruvada Link: https://patch.msgid.link/20260303074635.2218-1-lirongqing@baidu.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit d57cf5c770c0c48e3c5bd144e88780421fa42a9f Author: Justin Chen Date: Thu Mar 19 16:48:13 2026 -0700 net: bcmasp: fix double disable of clk [ Upstream commit 27dfe9030acbc601c260b42ecdbb4e5858a97b53 ] Switch to devm_clk_get_optional() so we can manage the clock ourselves. We dynamically control the clocks depending on the state of the interface for power savings. The default state is clock disabled, so unbinding the driver causes a double disable. Fixes: 490cb412007d ("net: bcmasp: Add support for ASP2.0 Ethernet controller") Signed-off-by: Justin Chen Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260319234813.1937315-3-justin.chen@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9e5f5c07cc7d66522f8c9676c28605eba5d4a20e Author: Justin Chen Date: Thu Mar 19 16:48:12 2026 -0700 net: bcmasp: fix double free of WoL irq [ Upstream commit cbfa5be2bf64511d49b854a0f9fd6d0b5118621f ] We do not need to free wol_irq since it was instantiated with devm_request_irq(). So devres will free for us. Fixes: a2f0751206b0 ("net: bcmasp: Add support for WoL magic packet") Signed-off-by: Justin Chen Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260319234813.1937315-2-justin.chen@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit aba90ae2379f9ed38e66e29e9df162395240ee06 Author: Justin Chen Date: Thu Jan 22 11:49:49 2026 -0800 net: bcmasp: streamline early exit in probe [ Upstream commit 1fd1281250c38408d793863c8dcaa43c7de8932c ] Streamline the bcmasp_probe early exit. As support for other functionality is added(i.e. ptp), it is easier to keep track of early exit cleanup when it is all in one place. Signed-off-by: Justin Chen Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260122194949.1145107-3-justin.chen@broadcom.com Signed-off-by: Jakub Kicinski Stable-dep-of: cbfa5be2bf64 ("net: bcmasp: fix double free of WoL irq") Signed-off-by: Sasha Levin commit 60ed7fa717b12db61c1a42eeaa72bdf1d6a5c2ac Author: Sabrina Dubroca Date: Fri Mar 20 00:02:53 2026 +0100 rtnetlink: count IFLA_INFO_SLAVE_KIND in if_nlmsg_size [ Upstream commit ee00a12593ffb69db4dd1a1c00ecb0253376874a ] rtnl_link_get_slave_info_data_size counts IFLA_INFO_SLAVE_DATA, but rtnl_link_slave_info_fill adds both IFLA_INFO_SLAVE_DATA and IFLA_INFO_SLAVE_KIND. Fixes: ba7d49b1f0f8 ("rtnetlink: provide api for getting and setting slave info") Reviewed-by: Jiri Pirko Signed-off-by: Sabrina Dubroca Link: https://patch.msgid.link/049843b532e23cde7ddba263c0bbe35ba6f0d26d.1773919462.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6fa3f2764f49ff11135411a432926f69993b2dbd Author: Sabrina Dubroca Date: Fri Mar 20 00:02:52 2026 +0100 rtnetlink: count IFLA_PARENT_DEV_{NAME,BUS_NAME} in if_nlmsg_size [ Upstream commit 52501989c76206462d9b11a8485beef40ef41821 ] Commit 00e77ed8e64d ("rtnetlink: add IFLA_PARENT_[DEV|DEV_BUS]_NAME") added those attributes to rtnl_fill_ifinfo, but forgot to extend if_nlmsg_size. Fixes: 00e77ed8e64d ("rtnetlink: add IFLA_PARENT_[DEV|DEV_BUS]_NAME") Signed-off-by: Sabrina Dubroca Link: https://patch.msgid.link/0b849da95562af45487080528d60f578636aba5c.1773919462.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 54c87a730157868543ebdfa0ecb21b4590ed23a5 Author: Qi Tang Date: Wed Mar 18 14:48:47 2026 +0800 net/smc: fix double-free of smc_spd_priv when tee() duplicates splice pipe buffer [ Upstream commit 24dd586bb4cbba1889a50abe74143817a095c1c9 ] smc_rx_splice() allocates one smc_spd_priv per pipe_buffer and stores the pointer in pipe_buffer.private. The pipe_buf_operations for these buffers used .get = generic_pipe_buf_get, which only increments the page reference count when tee(2) duplicates a pipe buffer. The smc_spd_priv pointer itself was not handled, so after tee() both the original and the cloned pipe_buffer share the same smc_spd_priv *. When both pipes are subsequently released, smc_rx_pipe_buf_release() is called twice against the same object: 1st call: kfree(priv) sock_put(sk) smc_rx_update_cons() [correct] 2nd call: kfree(priv) sock_put(sk) smc_rx_update_cons() [UAF] KASAN reports a slab-use-after-free in smc_rx_pipe_buf_release(), which then escalates to a NULL-pointer dereference and kernel panic via smc_rx_update_consumer() when it chases the freed priv->smc pointer: BUG: KASAN: slab-use-after-free in smc_rx_pipe_buf_release+0x78/0x2a0 Read of size 8 at addr ffff888004a45740 by task smc_splice_tee_/74 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xce/0x650 kasan_report+0xc6/0x100 smc_rx_pipe_buf_release+0x78/0x2a0 free_pipe_info+0xd4/0x130 pipe_release+0x142/0x160 __fput+0x1c6/0x490 __x64_sys_close+0x4f/0x90 do_syscall_64+0xa6/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f BUG: kernel NULL pointer dereference, address: 0000000000000020 RIP: 0010:smc_rx_update_consumer+0x8d/0x350 Call Trace: smc_rx_pipe_buf_release+0x121/0x2a0 free_pipe_info+0xd4/0x130 pipe_release+0x142/0x160 __fput+0x1c6/0x490 __x64_sys_close+0x4f/0x90 do_syscall_64+0xa6/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Kernel panic - not syncing: Fatal exception Beyond the memory-safety problem, duplicating an SMC splice buffer is semantically questionable: smc_rx_update_cons() would advance the consumer cursor twice for the same data, corrupting receive-window accounting. A refcount on smc_spd_priv could fix the double-free, but the cursor-accounting issue would still need to be addressed separately. The .get callback is invoked by both tee(2) and splice_pipe_to_pipe() for partial transfers; both will now return -EFAULT. Users who need to duplicate SMC socket data must use a copy-based read path. Fixes: 9014db202cb7 ("smc: add support for splice()") Signed-off-by: Qi Tang Link: https://patch.msgid.link/20260318064847.23341-1-tpluszz77@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bd50c7484c3bb34097571c1334174fb8b7408036 Author: Yang Yang Date: Thu Mar 19 08:02:27 2026 +0000 openvswitch: validate MPLS set/set_masked payload length [ Upstream commit 546b68ac893595877ffbd7751e5c55fd1c43ede6 ] validate_set() accepted OVS_KEY_ATTR_MPLS as variable-sized payload for SET/SET_MASKED actions. In action handling, OVS expects fixed-size MPLS key data (struct ovs_key_mpls). Use the already normalized key_len (masked case included) and reject non-matching MPLS action key sizes. Reject invalid MPLS action payload lengths early. Fixes: fbdcdd78da7c ("Change in Openvswitch to support MPLS label depth of 3 in ingress direction") Reported-by: Yifan Wu Reported-by: Juefei Pu Tested-by: Ao Zhou Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Signed-off-by: Yang Yang Reviewed-by: Ilya Maximets Link: https://patch.msgid.link/20260319080228.3423307-1-n05ec@lzu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 98b726ab5e2a4811e27c28e4d041f75bba147eab Author: Yang Yang Date: Thu Mar 19 07:42:41 2026 +0000 openvswitch: defer tunnel netdev_put to RCU release [ Upstream commit 6931d21f87bc6d657f145798fad0bf077b82486c ] ovs_netdev_tunnel_destroy() may run after NETDEV_UNREGISTER already detached the device. Dropping the netdev reference in destroy can race with concurrent readers that still observe vport->dev. Do not release vport->dev in ovs_netdev_tunnel_destroy(). Instead, let vport_netdev_free() drop the reference from the RCU callback, matching the non-tunnel destroy path and avoiding additional synchronization under RTNL. Fixes: a9020fde67a6 ("openvswitch: Move tunnel destroy function to oppenvswitch module.") Reported-by: Yifan Wu Reported-by: Juefei Pu Tested-by: Ao Zhou Co-developed-by: Yuan Tan Signed-off-by: Yuan Tan Suggested-by: Xin Liu Signed-off-by: Yang Yang Reviewed-by: Ilya Maximets Link: https://patch.msgid.link/20260319074241.3405262-1-n05ec@lzu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 95265232b49765a4d00f4d028c100bb7185600f4 Author: Toke Høiland-Jørgensen Date: Wed Mar 18 16:55:51 2026 +0100 net: openvswitch: Avoid releasing netdev before teardown completes [ Upstream commit 7c770dadfda5cbbde6aa3c4363ed513f1d212bf8 ] The patch cited in the Fixes tag below changed the teardown code for OVS ports to no longer unconditionally take the RTNL. After this change, the netdev_destroy() callback can proceed immediately to the call_rcu() invocation if the IFF_OVS_DATAPATH flag is already cleared on the netdev. The ovs_netdev_detach_dev() function clears the flag before completing the unregistration, and if it gets preempted after clearing the flag (as can happen on an -rt kernel), netdev_destroy() can complete and the device can be freed before the unregistration completes. This leads to a splat like: [ 998.393867] Oops: general protection fault, probably for non-canonical address 0xff00000001000239: 0000 [#1] SMP PTI [ 998.393877] CPU: 42 UID: 0 PID: 55177 Comm: ip Kdump: loaded Not tainted 6.12.0-211.1.1.el10_2.x86_64+rt #1 PREEMPT_RT [ 998.393886] Hardware name: Dell Inc. PowerEdge R740/0JMK61, BIOS 2.24.0 03/27/2025 [ 998.393889] RIP: 0010:dev_set_promiscuity+0x8d/0xa0 [ 998.393901] Code: 00 00 75 d8 48 8b 53 08 48 83 ba b0 02 00 00 00 75 ca 48 83 c4 08 5b c3 cc cc cc cc 48 83 bf 48 09 00 00 00 75 91 48 8b 47 08 <48> 83 b8 b0 02 00 00 00 74 97 eb 81 0f 1f 80 00 00 00 00 90 90 90 [ 998.393906] RSP: 0018:ffffce5864a5f6a0 EFLAGS: 00010246 [ 998.393912] RAX: ff00000000ffff89 RBX: ffff894d0adf5a05 RCX: 0000000000000000 [ 998.393917] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: ffff894d0adf5a05 [ 998.393921] RBP: ffff894d19252000 R08: ffff894d19252000 R09: 0000000000000000 [ 998.393924] R10: ffff894d19252000 R11: ffff894d192521b8 R12: 0000000000000006 [ 998.393927] R13: ffffce5864a5f738 R14: 00000000ffffffe2 R15: 0000000000000000 [ 998.393931] FS: 00007fad61971800(0000) GS:ffff894cc0140000(0000) knlGS:0000000000000000 [ 998.393936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 998.393940] CR2: 000055df0a2a6e40 CR3: 000000011c7fe003 CR4: 00000000007726f0 [ 998.393944] PKRU: 55555554 [ 998.393946] Call Trace: [ 998.393949] [ 998.393952] ? show_trace_log_lvl+0x1b0/0x2f0 [ 998.393961] ? show_trace_log_lvl+0x1b0/0x2f0 [ 998.393975] ? dp_device_event+0x41/0x80 [openvswitch] [ 998.394009] ? __die_body.cold+0x8/0x12 [ 998.394016] ? die_addr+0x3c/0x60 [ 998.394027] ? exc_general_protection+0x16d/0x390 [ 998.394042] ? asm_exc_general_protection+0x26/0x30 [ 998.394058] ? dev_set_promiscuity+0x8d/0xa0 [ 998.394066] ? ovs_netdev_detach_dev+0x3a/0x80 [openvswitch] [ 998.394092] dp_device_event+0x41/0x80 [openvswitch] [ 998.394102] notifier_call_chain+0x5a/0xd0 [ 998.394106] unregister_netdevice_many_notify+0x51b/0xa60 [ 998.394110] rtnl_dellink+0x169/0x3e0 [ 998.394121] ? rt_mutex_slowlock.constprop.0+0x95/0xd0 [ 998.394125] rtnetlink_rcv_msg+0x142/0x3f0 [ 998.394128] ? avc_has_perm_noaudit+0x69/0xf0 [ 998.394130] ? __pfx_rtnetlink_rcv_msg+0x10/0x10 [ 998.394132] netlink_rcv_skb+0x50/0x100 [ 998.394138] netlink_unicast+0x292/0x3f0 [ 998.394141] netlink_sendmsg+0x21b/0x470 [ 998.394145] ____sys_sendmsg+0x39d/0x3d0 [ 998.394149] ___sys_sendmsg+0x9a/0xe0 [ 998.394156] __sys_sendmsg+0x7a/0xd0 [ 998.394160] do_syscall_64+0x7f/0x170 [ 998.394162] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 998.394165] RIP: 0033:0x7fad61bf4724 [ 998.394188] Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d c5 e9 0c 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 [ 998.394189] RSP: 002b:00007ffd7e2f7cb8 EFLAGS: 00000202 ORIG_RAX: 000000000000002e [ 998.394191] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fad61bf4724 [ 998.394193] RDX: 0000000000000000 RSI: 00007ffd7e2f7d20 RDI: 0000000000000003 [ 998.394194] RBP: 00007ffd7e2f7d90 R08: 0000000000000010 R09: 000000000000003f [ 998.394195] R10: 000055df11558010 R11: 0000000000000202 R12: 00007ffd7e2f8380 [ 998.394196] R13: 0000000069b233d7 R14: 000055df0a256040 R15: 0000000000000000 [ 998.394200] To fix this, reorder the operations in ovs_netdev_detach_dev() to only clear the flag after completing the other operations, and introduce an smp_wmb() to make the ordering requirement explicit. The smp_wmb() is paired with a full smp_mb() in netdev_destroy() to make sure the call_rcu() invocation does not happen before the unregister operations are visible. Reported-by: Minxi Hou Tested-by: Minxi Hou Fixes: 549822767630 ("net: openvswitch: Avoid needlessly taking the RTNL on vport destroy") Signed-off-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20260318155554.1133405-1-toke@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d89b74bf08f067b55c03d7f999ba0a0e73177eb3 Author: Jakub Kicinski Date: Tue Mar 17 12:33:34 2026 -0700 nfc: nci: fix circular locking dependency in nci_close_device [ Upstream commit 4527025d440ce84bf56e75ce1df2e84cb8178616 ] nci_close_device() flushes rx_wq and tx_wq while holding req_lock. This causes a circular locking dependency because nci_rx_work() running on rx_wq can end up taking req_lock too: nci_rx_work -> nci_rx_data_packet -> nci_data_exchange_complete -> __sk_destruct -> rawsock_destruct -> nfc_deactivate_target -> nci_deactivate_target -> nci_request -> mutex_lock(&ndev->req_lock) Move the flush of rx_wq after req_lock has been released. This should safe (I think) because NCI_UP has already been cleared and the transport is closed, so the work will see it and return -ENETDOWN. NIPA has been hitting this running the nci selftest with a debug kernel on roughly 4% of the runs. Fixes: 6a2968aaf50c ("NFC: basic NCI protocol implementation") Reviewed-by: Ian Ray Link: https://patch.msgid.link/20260317193334.988609-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 097b16ffa61e3097535a4bb95cd5f8d2406df0c7 Author: Mohammad Heib Date: Tue Mar 17 19:08:06 2026 +0200 ionic: fix persistent MAC address override on PF [ Upstream commit cbcb3cfcdc436d6f91a3d95ecfa9c831abe14aed ] The use of IONIC_CMD_LIF_SETATTR in the MAC address update path causes the ionic firmware to update the LIF's identity in its persistent state. Since the firmware state is maintained across host warm boots and driver reloads, any MAC change on the Physical Function (PF) becomes "sticky. This is problematic because it causes ethtool -P to report the user-configured MAC as the permanent factory address, which breaks system management tools that rely on a stable hardware identity. While Virtual Functions (VFs) need this hardware-level programming to properly handle MAC assignments in guest environments, the PF should maintain standard transient behavior. This patch gates the ionic_program_mac call using is_virtfn so that PF MAC changes remain local to the netdev filters and do not overwrite the firmware's permanent identity block. Fixes: 19058be7c48c ("ionic: VF initial random MAC address if no assigned mac") Signed-off-by: Mohammad Heib Reviewed-by: Simon Horman Reviewed-by: Brett Creeley Link: https://patch.msgid.link/20260317170806.35390-1-mheib@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 936a3c0c10e2b1340f1a7988da5ccb7483d5cbc4 Author: Luca Leonardo Scorcia Date: Tue Mar 17 11:02:06 2026 +0000 pinctrl: mediatek: common: Fix probe failure for devices without EINT [ Upstream commit 8f9f64c8f90dca07d3b9f1d7ce5d34ccd246c9dd ] Some pinctrl devices like mt6397 or mt6392 don't support EINT at all, but the mtk_eint_init function is always called and returns -ENODEV, which then bubbles up and causes probe failure. To address this only call mtk_eint_init if EINT pins are present. Tested on Xiaomi Mi Smart Clock x04g (mt6392). Fixes: e46df235b4e6 ("pinctrl: mediatek: refactor EINT related code for all MediaTek pinctrl can fit") Signed-off-by: Luca Leonardo Scorcia Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 1dc6db047919ecd59493cd51248b37381bbabcbb Author: Helen Koike Date: Thu Mar 19 08:58:01 2026 -0300 Bluetooth: L2CAP: Fix null-ptr-deref on l2cap_sock_ready_cb [ Upstream commit b6552e0503973daf6f23bd6ed9273ef131ee364f ] Before using sk pointer, check if it is null. Fix the following: KASAN: null-ptr-deref in range [0x0000000000000260-0x0000000000000267] CPU: 0 UID: 0 PID: 5985 Comm: kworker/0:5 Not tainted 7.0.0-rc4-00029-ga989fde763f4 #1 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-9.fc43 06/10/2025 Workqueue: events l2cap_info_timeout RIP: 0010:kasan_byte_accessible+0x12/0x30 Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df <0f> b6 04 07 3c 08 0f 92 c0 c3 cc cce veth0_macvtap: entered promiscuous mode RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001 RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000 R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005582615a5008 CR3: 000000007007e000 CR4: 0000000000752ef0 PKRU: 55555554 Call Trace: __kasan_check_byte+0x12/0x40 lock_acquire+0x79/0x2e0 lock_sock_nested+0x48/0x100 ? l2cap_sock_ready_cb+0x46/0x160 l2cap_sock_ready_cb+0x46/0x160 l2cap_conn_start+0x779/0xff0 ? __pfx_l2cap_conn_start+0x10/0x10 ? l2cap_info_timeout+0x60/0xa0 ? __pfx___mutex_lock+0x10/0x10 l2cap_info_timeout+0x68/0xa0 ? process_scheduled_works+0xa8d/0x18c0 process_scheduled_works+0xb6e/0x18c0 ? __pfx_process_scheduled_works+0x10/0x10 ? assign_work+0x3d5/0x5e0 worker_thread+0xa53/0xfc0 kthread+0x388/0x470 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x51e/0xb90 ? __pfx_ret_from_fork+0x10/0x10 veth1_macvtap: entered promiscuous mode ? __switch_to+0xc7d/0x1450 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: ---[ end trace 0000000000000000 ]--- batman_adv: batadv0: Interface activated: batadv_slave_0 batman_adv: batadv0: Interface activated: batadv_slave_1 netdevsim netdevsim7 netdevsim0: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim1: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim2: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim3: set [1, 0] type 2 family 0 port 6081 - 0 RIP: 0010:kasan_byte_accessible+0x12/0x30 Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df <0f> b6 04 07 3c 08 0f 92 c0 c3 cc cce ieee80211 phy39: Selected rate control algorithm 'minstrel_ht' RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001 RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000 R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7e16139e9c CR3: 000000000e74e000 CR4: 0000000000752ef0 PKRU: 55555554 Kernel panic - not syncing: Fatal exception Fixes: 54a59aa2b562 ("Bluetooth: Add l2cap_chan->ops->ready()") Signed-off-by: Helen Koike Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 9ecbfd93cd6de6c78cb7fd51fe079e36c7ff074b Author: Anas Iqbal Date: Sun Mar 15 10:51:37 2026 +0000 Bluetooth: hci_ll: Fix firmware leak on error path [ Upstream commit 31148a7be723aa9f2e8fbd62424825ab8d577973 ] Smatch reports: drivers/bluetooth/hci_ll.c:587 download_firmware() warn: 'fw' from request_firmware() not released on lines: 544. In download_firmware(), if request_firmware() succeeds but the returned firmware content is invalid (no data or zero size), the function returns without releasing the firmware, resulting in a resource leak. Fix this by calling release_firmware() before returning when request_firmware() succeeded but the firmware content is invalid. Fixes: 371805522f87 ("bluetooth: hci_uart: add LL protocol serdev driver support") Reviewed-by: Paul Menzel Signed-off-by: Anas Iqbal Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit bafec9325d4de26b6c49db75b5d5172de652aae0 Author: Luiz Augusto von Dentz Date: Mon Mar 16 15:03:27 2026 -0400 Bluetooth: MGMT: Fix dangling pointer on mgmt_add_adv_patterns_monitor_complete [ Upstream commit 5f5fa4cd35f707344f65ce9e225b6528691dbbaa ] This fixes the condition checking so mgmt_pending_valid is executed whenever status != -ECANCELED otherwise calling mgmt_pending_free(cmd) would kfree(cmd) without unlinking it from the list first, leaving a dangling pointer. Any subsequent list traversal (e.g., mgmt_pending_foreach during __mgmt_power_off, or another mgmt_pending_valid call) would dereference freed memory. Link: https://lore.kernel.org/linux-bluetooth/20260315132013.75ab40c5@kernel.org/T/#m1418f9c82eeff8510c1beaa21cf53af20db96c06 Fixes: 302a1f674c00 ("Bluetooth: MGMT: Fix possible UAFs") Signed-off-by: Luiz Augusto von Dentz Reviewed-by: Paul Menzel Signed-off-by: Sasha Levin commit 7197462e90b8ce15caa1ae15d4bc2bb8cd21b11e Author: Hyunwoo Kim Date: Fri Mar 13 05:26:16 2026 +0900 Bluetooth: SCO: Fix use-after-free in sco_recv_frame() due to missing sock_hold [ Upstream commit 598dbba9919c5e36c54fe1709b557d64120cb94b ] sco_recv_frame() reads conn->sk under sco_conn_lock() but immediately releases the lock without holding a reference to the socket. A concurrent close() can free the socket between the lock release and the subsequent sk->sk_state access, resulting in a use-after-free. Other functions in the same file (sco_sock_timeout(), sco_conn_del()) correctly use sco_sock_hold() to safely hold a reference under the lock. Fix by using sco_sock_hold() to take a reference before releasing the lock, and adding sock_put() on all exit paths. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Hyunwoo Kim Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 8c96f3bd4ae0802db90630be8e9851827e9c9209 Author: Hyunwoo Kim Date: Fri Mar 13 05:22:39 2026 +0900 Bluetooth: L2CAP: Validate PDU length before reading SDU length in l2cap_ecred_data_rcv() [ Upstream commit c65bd945d1c08c3db756821b6bf9f1c4a77b29c6 ] l2cap_ecred_data_rcv() reads the SDU length field from skb->data using get_unaligned_le16() without first verifying that skb contains at least L2CAP_SDULEN_SIZE (2) bytes. When skb->len is less than 2, this reads past the valid data in the skb. The ERTM reassembly path correctly calls pskb_may_pull() before reading the SDU length (l2cap_reassemble_sdu, L2CAP_SAR_START case). Apply the same validation to the Enhanced Credit Based Flow Control data path. Fixes: aac23bf63659 ("Bluetooth: Implement LE L2CAP reassembly") Signed-off-by: Hyunwoo Kim Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 5b35f8211a913cfe7ab9d54fa36a272d2059a588 Author: Minseo Park Date: Sun Mar 15 22:14:37 2026 +0900 Bluetooth: L2CAP: Fix stack-out-of-bounds read in l2cap_ecred_conn_req [ Upstream commit 9d87cb22195b2c67405f5485d525190747ad5493 ] Syzbot reported a KASAN stack-out-of-bounds read in l2cap_build_cmd() that is triggered by a malformed Enhanced Credit Based Connection Request. The vulnerability stems from l2cap_ecred_conn_req(). The function allocates a local stack buffer (`pdu`) designed to hold a maximum of 5 Source Channel IDs (SCIDs), totaling 18 bytes. When an attacker sends a request with more than 5 SCIDs, the function calculates `rsp_len` based on this unvalidated `cmd_len` before checking if the number of SCIDs exceeds L2CAP_ECRED_MAX_CID. If the SCID count is too high, the function correctly jumps to the `response` label to reject the packet, but `rsp_len` retains the attacker's oversized value. Consequently, l2cap_send_cmd() is instructed to read past the end of the 18-byte `pdu` buffer, triggering a KASAN panic. Fix this by moving the assignment of `rsp_len` to after the `num_scid` boundary check. If the packet is rejected, `rsp_len` will safely remain 0, and the error response will only read the 8-byte base header from the stack. Fixes: c28d2bff7044 ("Bluetooth: L2CAP: Fix result of L2CAP_ECRED_CONN_RSP when MTU is too short") Reported-by: syzbot+b7f3e7d9a596bf6a63e3@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b7f3e7d9a596bf6a63e3 Tested-by: syzbot+b7f3e7d9a596bf6a63e3@syzkaller.appspotmail.com Signed-off-by: Minseo Park Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 46737243be216e49343697ef24a321e833f71074 Author: Amelie Delaunay Date: Tue Mar 17 11:06:54 2026 +0100 pinctrl: stm32: fix HDP driver dependency on GPIO_GENERIC [ Upstream commit c8cfeb4b9dda2cdfce79519aee4aaff16310a7b6 ] The HDP driver uses the generic GPIO chip API, but this configuration may not be enabled. Ensure it is enabled by selecting the appropriate option. Fixes: 4bcff9c05b9d ("pinctrl: stm32: use new generic GPIO chip API") Signed-off-by: Amelie Delaunay Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 1500005f286fb1f4d48cbb06b1efe7942680fca9 Author: Oliver Hartkopp Date: Wed Mar 18 18:34:13 2026 +0100 can: statistics: add missing atomic access in hot path [ Upstream commit 46eee1661aa9b49966e6c43d07126fe408edda57 ] Commit 80b5f90158d1 ("can: statistics: use atomic access in hot path") fixed a KCSAN issue in can_receive() but missed to convert the 'matches' variable used in can_rcv_filter(). Fixes: 80b5f90158d1 ("can: statistics: use atomic access in hot path") Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260318173413.28235-1-socketcan@hartkopp.net Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 5cf3972c8221abdb1b464a14ccf8103d840b9085 Author: Sheng Yong Date: Fri Feb 27 10:30:08 2026 +0800 erofs: set fileio bio failed in short read case [ Upstream commit eade54040384f54b7fb330e4b0975c5734850b3c ] For file-backed mount, IO requests are handled by vfs_iocb_iter_read(). However, it can be interrupted by SIGKILL, returning the number of bytes actually copied. Unused folios in bio are unexpectedly marked as uptodate. vfs_read filemap_read filemap_get_pages filemap_readahead erofs_fileio_readahead erofs_fileio_rq_submit vfs_iocb_iter_read filemap_read filemap_get_pages <= detect signal erofs_fileio_ki_complete <= set all folios uptodate This patch addresses this by setting short read bio with an error directly. Fixes: bc804a8d7e86 ("erofs: handle end of filesystem properly for file-backed mounts") Reported-by: chenguanyou Signed-off-by: Yunlei He Signed-off-by: Sheng Yong Reviewed-by: Gao Xiang Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit f4b4debc0b7319a163e8fbf135a89d034918a600 Author: Shigeru Yoshida Date: Sun Mar 15 17:27:49 2026 +0900 dma: swiotlb: add KMSAN annotations to swiotlb_bounce() [ Upstream commit 6f770b73d0311a5b099277653199bb6421c4fed2 ] When a device performs DMA to a bounce buffer, KMSAN is unaware of the write and does not mark the data as initialized. When swiotlb_bounce() later copies the bounce buffer back to the original buffer, memcpy propagates the uninitialized shadow to the original buffer, causing false positive uninit-value reports. Fix this by calling kmsan_unpoison_memory() on the bounce buffer before copying it back in the DMA_FROM_DEVICE path, so that memcpy naturally propagates initialized shadow to the destination. Suggested-by: Alexander Potapenko Link: https://lore.kernel.org/CAG_fn=WUGta-paG1BgsGRoAR+fmuCgh3xo=R3XdzOt_-DqSdHw@mail.gmail.com/ Fixes: 7ade4f10779c ("dma: kmsan: unpoison DMA mappings") Signed-off-by: Shigeru Yoshida Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20260315082750.2375581-1-syoshida@redhat.com Signed-off-by: Sasha Levin commit 83f644ea92987c100b82d8481ae2230faeed3d34 Author: Eric Dumazet Date: Sat Mar 14 17:02:10 2026 +0000 af_key: validate families in pfkey_send_migrate() [ Upstream commit eb2d16a7d599dc9d4df391b5e660df9949963786 ] syzbot was able to trigger a crash in skb_put() [1] Issue is that pfkey_send_migrate() does not check old/new families, and that set_ipsecrequest() @family argument was truncated, thus possibly overfilling the skb. Validate families early, do not wait set_ipsecrequest(). [1] skbuff: skb_over_panic: text:ffffffff8a752120 len:392 put:16 head:ffff88802a4ad040 data:ffff88802a4ad040 tail:0x188 end:0x180 dev: kernel BUG at net/core/skbuff.c:214 ! Call Trace: skb_over_panic net/core/skbuff.c:219 [inline] skb_put+0x159/0x210 net/core/skbuff.c:2655 skb_put_zero include/linux/skbuff.h:2788 [inline] set_ipsecrequest net/key/af_key.c:3532 [inline] pfkey_send_migrate+0x1270/0x2e50 net/key/af_key.c:3636 km_migrate+0x155/0x260 net/xfrm/xfrm_state.c:2848 xfrm_migrate+0x2140/0x2450 net/xfrm/xfrm_policy.c:4705 xfrm_do_migrate+0x8ff/0xaa0 net/xfrm/xfrm_user.c:3150 Fixes: 08de61beab8a ("[PFKEYV2]: Extension for dynamic update of endpoint address(es)") Reported-by: syzbot+b518dfc8e021988fbd55@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/69b5933c.050a0220.248e02.00f2.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Cc: Steffen Klassert Cc: Herbert Xu Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 8854e9367465d784046362698731c1111e3b39b8 Author: Minwoo Ra Date: Sat Mar 14 00:58:44 2026 +0900 xfrm: prevent policy_hthresh.work from racing with netns teardown [ Upstream commit 29fe3a61bcdce398ee3955101c39f89c01a8a77e ] A XFRM_MSG_NEWSPDINFO request can queue the per-net work item policy_hthresh.work onto the system workqueue. The queued callback, xfrm_hash_rebuild(), retrieves the enclosing struct net via container_of(). If the net namespace is torn down before that work runs, the associated struct net may already have been freed, and xfrm_hash_rebuild() may then dereference stale memory. xfrm_policy_fini() already flushes policy_hash_work during teardown, but it does not synchronize policy_hthresh.work. Synchronize policy_hthresh.work in xfrm_policy_fini() as well, so the queued work cannot outlive the net namespace teardown and access a freed struct net. Fixes: 880a6fab8f6b ("xfrm: configure policy hash table thresholds by netlink") Signed-off-by: Minwoo Ra Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 2255ed6adbc3100d2c4a83abd9d0396d04b87792 Author: Hyunwoo Kim Date: Wed Mar 11 03:16:29 2026 +0900 xfrm: Fix work re-schedule after cancel in xfrm_nat_keepalive_net_fini() [ Upstream commit daf8e3b253aa760ff9e96c7768a464bc1d6b3c90 ] After cancel_delayed_work_sync() is called from xfrm_nat_keepalive_net_fini(), xfrm_state_fini() flushes remaining states via __xfrm_state_delete(), which calls xfrm_nat_keepalive_state_updated() to re-schedule nat_keepalive_work. The following is a simple race scenario: cpu0 cpu1 cleanup_net() [Round 1] ops_undo_list() xfrm_net_exit() xfrm_nat_keepalive_net_fini() cancel_delayed_work_sync(nat_keepalive_work); xfrm_state_fini() xfrm_state_flush() xfrm_state_delete(x) __xfrm_state_delete(x) xfrm_nat_keepalive_state_updated(x) schedule_delayed_work(nat_keepalive_work); rcu_barrier(); net_complete_free(); net_passive_dec(net); llist_add(&net->defer_free_list, &defer_free_list); cleanup_net() [Round 2] rcu_barrier(); net_complete_free() kmem_cache_free(net_cachep, net); nat_keepalive_work() // on freed net To prevent this, cancel_delayed_work_sync() is replaced with disable_delayed_work_sync(). Fixes: f531d13bdfe3 ("xfrm: support sending NAT keepalives in ESP in UDP states") Signed-off-by: Hyunwoo Kim Reviewed-by: Sabrina Dubroca Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit ee0e3521f8069bb31db1fac262b65982d3bccac8 Author: Dmitry Torokhov Date: Wed Feb 18 12:58:09 2026 -0800 pinctrl: renesas: rza1: Normalize return value of gpio_get() [ Upstream commit fb22bb9701d48c4b0e81fe204c2f96a37a520568 ] The GPIO .get() callback is expected to return 0 or 1 (or a negative error code). Ensure that the value returned by rza1_gpio_get() is normalized to the [0, 1] range. Fixes: 86ef402d805d606a ("gpiolib: sanitize the return value of gpio_chip::get()") Signed-off-by: Dmitry Torokhov Reviewed-by: Andy Shevchenko Reviewed-by: Bartosz Golaszewski Reviewed-by: Linus Walleij Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/aZYnyl-Nf4S1U2yj@google.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 33a7b36268933c75bdc355e5531951e0ea9f1951 Author: Fernando Fernandez Mancera Date: Wed Mar 4 15:09:35 2026 +0100 xfrm: iptfs: fix skb_put() panic on non-linear skb during reassembly [ Upstream commit 0b352f83cabfefdaafa806d6471f0eca117dc7d5 ] In iptfs_reassem_cont(), IP-TFS attempts to append data to the new inner packet 'newskb' that is being reassembled. First a zero-copy approach is tried if it succeeds then newskb becomes non-linear. When a subsequent fragment in the same datagram does not meet the fast-path conditions, a memory copy is performed. It calls skb_put() to append the data and as newskb is non-linear it triggers SKB_LINEAR_ASSERT check. Oops: invalid opcode: 0000 [#1] SMP NOPTI [...] RIP: 0010:skb_put+0x3c/0x40 [...] Call Trace: iptfs_reassem_cont+0x1ab/0x5e0 [xfrm_iptfs] iptfs_input_ordered+0x2af/0x380 [xfrm_iptfs] iptfs_input+0x122/0x3e0 [xfrm_iptfs] xfrm_input+0x91e/0x1a50 xfrm4_esp_rcv+0x3a/0x110 ip_protocol_deliver_rcu+0x1d7/0x1f0 ip_local_deliver_finish+0xbe/0x1e0 __netif_receive_skb_core.constprop.0+0xb56/0x1120 __netif_receive_skb_list_core+0x133/0x2b0 netif_receive_skb_list_internal+0x1ff/0x3f0 napi_complete_done+0x81/0x220 virtnet_poll+0x9d6/0x116e [virtio_net] __napi_poll.constprop.0+0x2b/0x270 net_rx_action+0x162/0x360 handle_softirqs+0xdc/0x510 __irq_exit_rcu+0xe7/0x110 irq_exit_rcu+0xe/0x20 common_interrupt+0x85/0xa0 Fix this by checking if the skb is non-linear. If it is, linearize it by calling skb_linearize(). As the initial allocation of newskb originally reserved enough tailroom for the entire reassembled packet we do not need to check if we have enough tailroom or extend it. Fixes: 5f2b6a909574 ("xfrm: iptfs: add skb-fragment sharing code") Reported-by: Hao Long Closes: https://lore.kernel.org/netdev/DGRCO9SL0T5U.JTINSHJQ9KPK@imlonghao.com/ Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 7068aaa1cef4e23504e376f6eb2682df7487258a Author: Felix Gu Date: Tue Jan 27 00:35:47 2026 +0800 pinctrl: renesas: rzt2h: Fix device node leak in rzt2h_gpio_register() [ Upstream commit e825c79ef914bd55cf7c2476ddcfb2738eb689c3 ] When calling of_parse_phandle_with_fixed_args(), the caller is responsible for calling of_node_put() to release the device node reference. In rzt2h_gpio_register(), the driver fails to call of_node_put() to release the reference in of_args.np, which causes a memory leak. Add the missing of_node_put() call to fix the leak. Fixes: 34d4d093077a ("pinctrl: renesas: Add support for RZ/T2H") Signed-off-by: Felix Gu Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260127-rzt2h-v1-1-86472e7421b8@gmail.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 88d386243ed374ac969dabd3bbc1409a31d81818 Author: Sabrina Dubroca Date: Tue Feb 24 00:05:14 2026 +0100 esp: fix skb leak with espintcp and async crypto [ Upstream commit 0c0eef8ccd2413b0a10eb6bbd3442333b1e64dd2 ] When the TX queue for espintcp is full, esp_output_tail_tcp will return an error and not free the skb, because with synchronous crypto, the common xfrm output code will drop the packet for us. With async crypto (esp_output_done), we need to drop the skb when esp_output_tail_tcp returns an error. Fixes: e27cca96cd68 ("xfrm: add espintcp (RFC 8229)") Signed-off-by: Sabrina Dubroca Reviewed-by: Simon Horman Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit af834169a410d1d22da59c9c0fa49611e4a914df Author: Sabrina Dubroca Date: Tue Feb 24 00:05:13 2026 +0100 xfrm: call xdo_dev_state_delete during state update [ Upstream commit 7d2fc41f91bc69acb6e01b0fa23cd7d0109a6a23 ] When we update an SA, we construct a new state and call xdo_dev_state_add, but never insert it. The existing state is updated, then we immediately destroy the new state. Since we haven't added it, we don't go through the standard state delete code, and we're skipping removing it from the device (but xdo_dev_state_free will get called when we destroy the temporary state). This is similar to commit c5d4d7d83165 ("xfrm: Fix deletion of offloaded SAs on failure."). Fixes: d77e38e612a0 ("xfrm: Add an IPsec hardware offloading API") Signed-off-by: Sabrina Dubroca Reviewed-by: Simon Horman Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit ecb02f949e3eb891e771e07a9d2ca421f88e9f0d Author: Sabrina Dubroca Date: Tue Feb 24 00:05:12 2026 +0100 xfrm: fix the condition on x->pcpu_num in xfrm_sa_len [ Upstream commit b57defcf8f109da5ba9cf59b2a736606faf3d846 ] pcpu_num = 0 is a valid value. The marker for "unset pcpu_num" which makes copy_to_user_state_extra not add the XFRMA_SA_PCPU attribute is UINT_MAX. Fixes: 1ddf9916ac09 ("xfrm: Add support for per cpu xfrm state handling.") Signed-off-by: Sabrina Dubroca Reviewed-by: Simon Horman Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 88467620fa4a378da13a6145dfe7330f9ed67444 Author: Sabrina Dubroca Date: Tue Feb 24 00:05:11 2026 +0100 xfrm: add missing extack for XFRMA_SA_PCPU in add_acquire and allocspi [ Upstream commit aa8a3f3c67235422a0c3608a8772f69ca3b7b63f ] We're returning an error caused by invalid user input without setting an extack. Add one. Fixes: 1ddf9916ac09 ("xfrm: Add support for per cpu xfrm state handling.") Signed-off-by: Sabrina Dubroca Reviewed-by: Simon Horman Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit b4a1e07944fe67e722057458d7f3c2156d9d0a7a Author: Peter Yin Date: Mon Mar 2 15:56:42 2026 +0800 i3c: master: dw-i3c: Fix missing of_node for virtual I2C adapter [ Upstream commit f26ecaa0f0abfe5db173416214098a00d3b7db79 ] The DesignWare I3C master driver creates a virtual I2C adapter to provide backward compatibility with I2C devices. However, the current implementation does not associate this virtual adapter with any Device Tree node. Propagate the of_node from the I3C master platform device to the virtual I2C adapter's device structure. This ensures that standard I2C aliases are correctly resolved and bus numbering remains consistent. Signed-off-by: Peter Yin Reviewed-by: Frank Li Link: https://patch.msgid.link/20260302075645.1492766-1-peteryin.openbmc@gmail.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 6eee692c42045cb2f025b21527941b7d5f188021 Author: Zhang Heng Date: Fri Mar 6 20:33:17 2026 +0800 ALSA: hda/realtek: add quirk for ASUS UM6702RC [ Upstream commit 0d3429f12133c2ca47aa82ddab2342bc360c47d3 ] The sound card of this machine cannot adjust the volume, it can only be 0 or 100%. The reason is that the DAC with pin 0x17 is connected to 0x06. Testing found that connecting 0x02 can fix this problem. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220356 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260306123317.575346-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 72969a102f93ad1aa04d52b7ce007bc3acbd57b7 Author: Alan Borzeszkowski Date: Mon Mar 9 16:37:03 2026 +0100 spi: intel-pci: Add support for Nova Lake mobile SPI flash [ Upstream commit 85b731ad4bbf6eb3fedf267ab00be3596f148432 ] Add Intel Nova Lake PCD-H SPI serial flash PCI ID to the list of supported devices. Signed-off-by: Alan Borzeszkowski Acked-by: Mika Westerberg Link: https://patch.msgid.link/20260309153703.74282-1-alan.borzeszkowski@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cbc467b4d9f3168b57c03f188db70dde45780135 Author: Jie Deng Date: Fri Feb 27 16:49:31 2026 +0800 usb: core: new quirk to handle devices with zero configurations [ Upstream commit 9f6a983cfa22ac662c86e60816d3a357d4b551e9 ] Some USB devices incorrectly report bNumConfigurations as 0 in their device descriptor, which causes the USB core to reject them during enumeration. logs: usb 1-2: device descriptor read/64, error -71 usb 1-2: no configurations usb 1-2: can't read configurations, error -22 However, these devices actually work correctly when treated as having a single configuration. Add a new quirk USB_QUIRK_FORCE_ONE_CONFIG to handle such devices. When this quirk is set, assume the device has 1 configuration instead of failing with -EINVAL. This quirk is applied to the device with VID:PID 5131:2007 which exhibits this behavior. Signed-off-by: Jie Deng Link: https://patch.msgid.link/20260227084931.1527461-1-dengjie03@kylinos.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ad696758a45ca0c70fa60b7fd2f921edec7fc600 Author: Yang Wang Date: Wed Mar 4 18:45:45 2026 -0500 drm/amdgpu: fix gpu idle power consumption issue for gfx v12 [ Upstream commit a6571045cf06c4aa749b4801382ae96650e2f0e1 ] Older versions of the MES firmware may cause abnormal GPU power consumption. When performing inference tasks on the GPU (e.g., with Ollama using ROCm), the GPU may show abnormal power consumption in idle state and incorrect GPU load information. This issue has been fixed in firmware version 0x8b and newer. Closes: https://github.com/ROCm/ROCm/issues/5706 Signed-off-by: Yang Wang Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 4e22a5fe6ea6e0b057e7f246df4ac3ff8bfbc46a) Signed-off-by: Sasha Levin commit ca111c9d8d6c9d5735878d933a1716c4be86c2d1 Author: Chaitanya Kulkarni Date: Wed Feb 25 20:30:03 2026 -0800 nvmet: move async event work off nvmet-wq [ Upstream commit 2922e3507f6d5caa7f1d07f145e186fc6f317a4e ] For target nvmet_ctrl_free() flushes ctrl->async_event_work. If nvmet_ctrl_free() runs on nvmet-wq, the flush re-enters workqueue completion for the same worker:- A. Async event work queued on nvmet-wq (prior to disconnect): nvmet_execute_async_event() queue_work(nvmet_wq, &ctrl->async_event_work) nvmet_add_async_event() queue_work(nvmet_wq, &ctrl->async_event_work) B. Full pre-work chain (RDMA CM path): nvmet_rdma_cm_handler() nvmet_rdma_queue_disconnect() __nvmet_rdma_queue_disconnect() queue_work(nvmet_wq, &queue->release_work) process_one_work() lock((wq_completion)nvmet-wq) <--------- 1st nvmet_rdma_release_queue_work() C. Recursive path (same worker): nvmet_rdma_release_queue_work() nvmet_rdma_free_queue() nvmet_sq_destroy() nvmet_ctrl_put() nvmet_ctrl_free() flush_work(&ctrl->async_event_work) __flush_work() touch_wq_lockdep_map() lock((wq_completion)nvmet-wq) <--------- 2nd Lockdep splat: ============================================ WARNING: possible recursive locking detected 6.19.0-rc3nvme+ #14 Tainted: G N -------------------------------------------- kworker/u192:42/44933 is trying to acquire lock: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90 but task is already holding lock: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x53e/0x660 3 locks held by kworker/u192:42/44933: #0: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x53e/0x660 #1: ffffc9000e6cbe28 ((work_completion)(&queue->release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x660 #2: ffffffff82d4db60 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530 Workqueue: nvmet-wq nvmet_rdma_release_queue_work [nvmet_rdma] Call Trace: __flush_work+0x268/0x530 nvmet_ctrl_free+0x140/0x310 [nvmet] nvmet_cq_put+0x74/0x90 [nvmet] nvmet_rdma_free_queue+0x23/0xe0 [nvmet_rdma] nvmet_rdma_release_queue_work+0x19/0x50 [nvmet_rdma] process_one_work+0x206/0x660 worker_thread+0x184/0x320 kthread+0x10c/0x240 ret_from_fork+0x319/0x390 Move async event work to a dedicated nvmet-aen-wq to avoid reentrant flush on nvmet-wq. Reviewed-by: Christoph Hellwig Signed-off-by: Chaitanya Kulkarni Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 17c9ad5aa46cca1ebba9e0679084f1dcd07c7888 Author: Josh Poimboeuf Date: Fri Mar 6 09:35:06 2026 -0800 objtool: Handle Clang RSP musical chairs [ Upstream commit 7fdaa640c810cb42090a182c33f905bcc47a616a ] For no apparent reason (possibly related to CONFIG_KMSAN), Clang can randomly pass the value of RSP to other registers and then back again to RSP. Handle that accordingly. Fixes the following warnings: drivers/input/misc/uinput.o: warning: objtool: uinput_str_to_user+0x165: undefined stack state drivers/input/misc/uinput.o: warning: objtool: uinput_str_to_user+0x165: unknown CFA base reg -1 Reported-by: Arnd Bergmann Closes: https://lore.kernel.org/90956545-2066-46e3-b547-10c884582eb0@app.fastmail.com Link: https://patch.msgid.link/240e6a172cc73292499334a3724d02ccb3247fc7.1772818491.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit 90420418e622d740b200a4ecf9fee9ce790cd66c Author: Uzair Mughal Date: Sat Mar 7 06:29:06 2026 +0500 ALSA: hda/realtek: Add headset jack quirk for Thinkpad X390 [ Upstream commit 542127f6528ca7cc3cf61e1651d6ccb58495f953 ] The Lenovo ThinkPad X390 (ALC257 codec, subsystem ID 0x17aa2288) does not report headset button press events. Headphone insertion is detected (SW_HEADPHONE_INSERT), but pressing the inline microphone button on a headset produces no input events. Add a SND_PCI_QUIRK entry that maps this subsystem ID to ALC285_FIXUP_THINKPAD_NO_BASS_SPK_HEADSET_JACK, which enables headset jack button detection through alc_fixup_headset_jack() and ThinkPad ACPI integration. This is the same fixup used by similar ThinkPad models (P1 Gen 3, X1 Extreme Gen 3). Signed-off-by: Uzair Mughal Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260307012906.20093-1-contact@uzair.is-a.dev Signed-off-by: Sasha Levin commit f93b6da04ec72a7c8fcad81f73e753415db818fc Author: Zhang Heng Date: Thu Mar 5 10:35:59 2026 +0800 ALSA: hda/realtek: Add quirk for Gigabyte Technology to fix headphone [ Upstream commit 56fbbe096a89ff4b52af78a21a4afd9d94bdcc80 ] The BIOS of this machine has set 0x19 to mic, which needs to be set to headphone pin in order to work properly. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220814 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/b55f6ebe-7449-49f7-ae85-00d2ba1e7af0@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit bee43f7b9bc62939934e62bcfd8d3e6f430d2b44 Author: Liucheng Lu Date: Sat Mar 7 11:27:27 2026 +0800 ALSA: hda/realtek: add HP Laptop 14s-dr5xxx mute LED quirk [ Upstream commit 178dd118c0f07fd63a9ed74cfbd8c31ae50e33af ] HP Laptop 14s-dr5xxx with ALC236 codec does not handle the toggling of the mute LED. This patch adds a quirk entry for subsystem ID 0x8a1f using ALC236_FIXUP_HP_MUTE_LED_COEFBIT2 fixup, enabling correct mute LED behavior. Signed-off-by: Liucheng Lu Link: https://patch.msgid.link/PAVPR03MB9774F3FCE9CCD181C585281AE37BA@PAVPR03MB9774.eurprd03.prod.outlook.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ed97a37b00d9fbf064c92e8a82deb3ed3ad8d7ce Author: Hari Bathini Date: Tue Jan 27 14:19:25 2026 +0530 powerpc64/ftrace: fix OOL stub count with clang [ Upstream commit 875612a7745013a43c67493cb0583ee3f7476344 ] The total number of out-of-line (OOL) stubs required for function tracing is determined using the following command: $(OBJDUMP) -r -j __patchable_function_entries vmlinux.o While this works correctly with GNU objdump, llvm-objdump does not list the expected relocation records for this section. Fix this by using the -d option and counting R_PPC64_ADDR64 relocation entries. This works as desired with both objdump and llvm-objdump. Signed-off-by: Hari Bathini Tested-by: Venkat Rao Bagalkote Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260127084926.34497-3-hbathini@linux.ibm.com Signed-off-by: Sasha Levin commit 2ec578e6452138ab76f6c9a9c18711fcd197649f Author: Boris Burkov Date: Tue Feb 24 14:25:35 2026 -0800 btrfs: set BTRFS_ROOT_ORPHAN_CLEANUP during subvol create [ Upstream commit 5131fa077f9bb386a1b901bf5b247041f0ec8f80 ] We have recently observed a number of subvolumes with broken dentries. ls-ing the parent dir looks like: drwxrwxrwt 1 root root 16 Jan 23 16:49 . drwxr-xr-x 1 root root 24 Jan 23 16:48 .. d????????? ? ? ? ? ? broken_subvol and similarly stat-ing the file fails. In this state, deleting the subvol fails with ENOENT, but attempting to create a new file or subvol over it errors out with EEXIST and even aborts the fs. Which leaves us a bit stuck. dmesg contains a single notable error message reading: "could not do orphan cleanup -2" 2 is ENOENT and the error comes from the failure handling path of btrfs_orphan_cleanup(), with the stack leading back up to btrfs_lookup(). btrfs_lookup btrfs_lookup_dentry btrfs_orphan_cleanup // prints that message and returns -ENOENT After some detailed inspection of the internal state, it became clear that: - there are no orphan items for the subvol - the subvol is otherwise healthy looking, it is not half-deleted or anything, there is no drop progress, etc. - the subvol was created a while ago and does the meaningful first btrfs_orphan_cleanup() call that sets BTRFS_ROOT_ORPHAN_CLEANUP much later. - after btrfs_orphan_cleanup() fails, btrfs_lookup_dentry() returns -ENOENT, which results in a negative dentry for the subvolume via d_splice_alias(NULL, dentry), leading to the observed behavior. The bug can be mitigated by dropping the dentry cache, at which point we can successfully delete the subvolume if we want. i.e., btrfs_lookup() btrfs_lookup_dentry() if (!sb_rdonly(inode->vfs_inode)->vfs_inode) btrfs_orphan_cleanup(sub_root) test_and_set_bit(BTRFS_ROOT_ORPHAN_CLEANUP) btrfs_search_slot() // finds orphan item for inode N ... prints "could not do orphan cleanup -2" if (inode == ERR_PTR(-ENOENT)) inode = NULL; return d_splice_alias(NULL, dentry) // NEGATIVE DENTRY for valid subvolume btrfs_orphan_cleanup() does test_and_set_bit(BTRFS_ROOT_ORPHAN_CLEANUP) on the root when it runs, so it cannot run more than once on a given root, so something else must run concurrently. However, the obvious routes to deleting an orphan when nlinks goes to 0 should not be able to run without first doing a lookup into the subvolume, which should run btrfs_orphan_cleanup() and set the bit. The final important observation is that create_subvol() calls d_instantiate_new() but does not set BTRFS_ROOT_ORPHAN_CLEANUP, so if the dentry cache gets dropped, the next lookup into the subvolume will make a real call into btrfs_orphan_cleanup() for the first time. This opens up the possibility of concurrently deleting the inode/orphan items but most typical evict() paths will be holding a reference on the parent dentry (child dentry holds parent->d_lockref.count via dget in d_alloc(), released in __dentry_kill()) and prevent the parent from being removed from the dentry cache. The one exception is delayed iputs. Ordered extent creation calls igrab() on the inode. If the file is unlinked and closed while those refs are held, iput() in __dentry_kill() decrements i_count but does not trigger eviction (i_count > 0). The child dentry is freed and the subvol dentry's d_lockref.count drops to 0, making it evictable while the inode is still alive. Since there are two races (the race between writeback and unlink and the race between lookup and delayed iputs), and there are too many moving parts, the following three diagrams show the complete picture. (Only the second and third are races) Phase 1: Create Subvol in dentry cache without BTRFS_ROOT_ORPHAN_CLEANUP set btrfs_mksubvol() lookup_one_len() __lookup_slow() d_alloc_parallel() __d_alloc() // d_lockref.count = 1 create_subvol(dentry) // doesn't touch the bit.. d_instantiate_new(dentry, inode) // dentry in cache with d_lockref.count == 1 Phase 2: Create a delayed iput for a file in the subvol but leave the subvol in state where its dentry can be evicted (d_lockref.count == 0) T1 (task) T2 (writeback) T3 (OE workqueue) write() // dirty pages btrfs_writepages() btrfs_run_delalloc_range() cow_file_range() btrfs_alloc_ordered_extent() igrab() // i_count: 1 -> 2 btrfs_unlink_inode() btrfs_orphan_add() close() __fput() dput() finish_dput() __dentry_kill() dentry_unlink_inode() iput() // 2 -> 1 --parent->d_lockref.count // 1 -> 0; evictable finish_ordered_fn() btrfs_finish_ordered_io() btrfs_put_ordered_extent() btrfs_add_delayed_iput() Phase 3: Once the delayed iput is pending and the subvol dentry is evictable, the shrinker can free it, causing the next lookup to go through btrfs_lookup() and call btrfs_orphan_cleanup() for the first time. If the cleaner kthread processes the delayed iput concurrently, the two race: T1 (shrinker) T2 (cleaner kthread) T3 (lookup) super_cache_scan() prune_dcache_sb() __dentry_kill() // subvol dentry freed btrfs_run_delayed_iputs() iput() // i_count -> 0 evict() // sets I_FREEING btrfs_evict_inode() // truncation loop btrfs_lookup() btrfs_lookup_dentry() btrfs_orphan_cleanup() // first call (bit never set) btrfs_iget() // blocks on I_FREEING btrfs_orphan_del() // inode freed // returns -ENOENT btrfs_del_orphan_item() // -ENOENT // "could not do orphan cleanup -2" d_splice_alias(NULL, dentry) // negative dentry for valid subvol The most straightforward fix is to ensure the invariant that a dentry for a subvolume can exist if and only if that subvolume has BTRFS_ROOT_ORPHAN_CLEANUP set on its root (and is known to have no orphans or ran btrfs_orphan_cleanup()). Reviewed-by: Filipe Manana Signed-off-by: Boris Burkov Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 91608747a8d2b65b2dadf328e606e1891d48a3b0 Author: zhidao su Date: Wed Mar 4 13:37:30 2026 +0800 sched_ext: Use WRITE_ONCE() for the write side of dsq->seq update [ Upstream commit 7a8464555d2e5f038758bb19e72ab4710b79e9cd ] bpf_iter_scx_dsq_new() reads dsq->seq via READ_ONCE() without holding any lock, making dsq->seq a lock-free concurrently accessed variable. However, dispatch_enqueue(), the sole writer of dsq->seq, uses a plain increment without the matching WRITE_ONCE() on the write side: dsq->seq++; ^^^^^^^^^^^ plain write -- KCSAN data race The KCSAN documentation requires that if one accessor uses READ_ONCE() or WRITE_ONCE() on a variable to annotate lock-free access, all other accesses must also use the appropriate accessor. A plain write leaves the pair incomplete and will trigger KCSAN warnings. Fix by using WRITE_ONCE() for the write side of the update: WRITE_ONCE(dsq->seq, dsq->seq + 1); This is consistent with bpf_iter_scx_dsq_new() and makes the concurrent access annotation complete and KCSAN-clean. Signed-off-by: zhidao su Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit be1a341c161430282acdfe2ac99b413271575cf1 Author: Günther Noack Date: Thu Feb 19 16:43:36 2026 +0100 HID: apple: avoid memory leak in apple_report_fixup() [ Upstream commit 239c15116d80f67d32f00acc34575f1a6b699613 ] The apple_report_fixup() function was returning a newly kmemdup()-allocated buffer, but never freeing it. The caller of report_fixup() does not take ownership of the returned pointer, but it *is* permitted to return a sub-portion of the input rdesc, whose lifetime is managed by the caller. Assisted-by: Gemini-CLI:Google Gemini 3 Signed-off-by: Günther Noack Signed-off-by: Benjamin Tissoires Signed-off-by: Sasha Levin commit 74b1b0d846975dbae57273cfaaed408e9cbf26b5 Author: Eduard Zingerman Date: Fri Mar 6 16:54:24 2026 -0800 bpf: Fix u32/s32 bounds when ranges cross min/max boundary [ Upstream commit fbc7aef517d8765e4c425d2792409bb9bf2e1f13 ] Same as in __reg64_deduce_bounds(), refine s32/u32 ranges in __reg32_deduce_bounds() in the following situations: - s32 range crosses U32_MAX/0 boundary, positive part of the s32 range overlaps with u32 range: 0 U32_MAX | [xxxxxxxxxxxxxx u32 range xxxxxxxxxxxxxx] | |----------------------------|----------------------------| |xxxxx s32 range xxxxxxxxx] [xxxxxxx| 0 S32_MAX S32_MIN -1 - s32 range crosses U32_MAX/0 boundary, negative part of the s32 range overlaps with u32 range: 0 U32_MAX | [xxxxxxxxxxxxxx u32 range xxxxxxxxxxxxxx] | |----------------------------|----------------------------| |xxxxxxxxx] [xxxxxxxxxxxx s32 range | 0 S32_MAX S32_MIN -1 - No refinement if ranges overlap in two intervals. This helps for e.g. consider the following program: call %[bpf_get_prandom_u32]; w0 &= 0xffffffff; if w0 < 0x3 goto 1f; // on fall-through u32 range [3..U32_MAX] if w0 s> 0x1 goto 1f; // on fall-through s32 range [S32_MIN..1] if w0 s< 0x0 goto 1f; // range can be narrowed to [S32_MIN..-1] r10 = 0; 1: ...; The reg_bounds.c selftest is updated to incorporate identical logic, refinement based on non-overflowing range halves: ((x ∩ [0, smax]) ∩ (y ∩ [0, smax])) ∪ ((x ∩ [smin,-1]) ∩ (y ∩ [smin,-1])) Reported-by: Andrea Righi Reported-by: Emil Tsalapatis Closes: https://lore.kernel.org/bpf/aakqucg4vcujVwif@gpd4/T/ Reviewed-by: Emil Tsalapatis Acked-by: Shung-Hsi Yu Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260306-bpf-32-bit-range-overflow-v3-1-f7f67e060a6b@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit b4770c2e70e64c4976e2a11d1c59775a5753ca1f Author: Simon Trimmer Date: Tue Feb 24 13:03:07 2026 +0000 ASoC: amd: acp: Add ACP6.3 match entries for Cirrus Logic parts [ Upstream commit fd13fc700e3e239826a46448bf7f01847dd26f5a ] This adds some match entries for a few system configurations: cs42l43 link 0 UID 0 cs35l56 link 1 UID 0 cs35l56 link 1 UID 1 cs35l56 link 1 UID 2 cs35l56 link 1 UID 3 cs42l45 link 1 UID 0 cs35l63 link 0 UID 0 cs35l63 link 0 UID 2 cs35l63 link 0 UID 4 cs35l63 link 0 UID 6 cs42l45 link 0 UID 0 cs35l63 link 1 UID 0 cs35l63 link 1 UID 1 cs42l45 link 0 UID 0 cs35l63 link 1 UID 1 cs35l63 link 1 UID 3 cs42l45 link 1 UID 0 cs35l63 link 0 UID 0 cs35l63 link 0 UID 1 cs42l43 link 1 UID 0 cs35l56 link 1 UID 0 cs35l56 link 1 UID 1 cs35l56 link 1 UID 2 cs35l56 link 1 UID 3 cs35l56 link 1 UID 0 cs35l56 link 1 UID 1 cs35l56 link 1 UID 2 cs35l56 link 1 UID 3 cs35l63 link 0 UID 0 cs35l63 link 0 UID 2 cs35l63 link 0 UID 4 cs35l63 link 0 UID 6 cs42l43 link 0 UID 1 cs42l43b link 0 UID 1 cs42l45 link 0 UID 0 cs42l45 link 1 UID 0 Signed-off-by: Simon Trimmer Link: https://patch.msgid.link/20260224130307.526626-1-simont@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit be0c2255d717c8c548cba3b78c6d3c33ecd1feb8 Author: Maarten Lankhorst Date: Wed Mar 4 09:56:16 2026 +0100 drm/ttm/tests: Fix build failure on PREEMPT_RT [ Upstream commit a58d487fb1a52579d3c37544ea371da78ed70c45 ] Fix a compile error in the kunit tests when CONFIG_PREEMPT_RT is enabled, and the normal mutex is converted into a rtmutex. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202602261547.3bM6yVAS-lkp@intel.com/ Reviewed-by: Jouni Högander Link: https://patch.msgid.link/20260304085616.1216961-1-dev@lankhorst.se Signed-off-by: Maarten Lankhorst Signed-off-by: Sasha Levin commit 34f0790eb71296288b854fbf05151aa989f62fdd Author: wangdicheng Date: Tue Mar 3 16:15:16 2026 +0800 ALSA: hda/senary: Ensure EAPD is enabled during init [ Upstream commit 7ae0d8f1abbbba6f98cac735145e1206927c67d9 ] The driver sets spec->gen.own_eapd_ctl to take manual control of the EAPD (External Amplifier). However, senary_init does not turn on the EAPD, while senary_shutdown turns it off. Since the generic driver skips EAPD handling when own_eapd_ctl is set, the EAPD remains off after initialization (e.g., after resume), leaving the codec in a non-functional state. Explicitly call senary_auto_turn_eapd in senary_init to ensure the EAPD is enabled and the codec is functional. Signed-off-by: wangdicheng Link: https://patch.msgid.link/20260303081516.583438-1-wangdich9700@163.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 5cf83b76f738632c3cfc3d4614bd8c7d5bb9f890 Author: Nilay Shroff Date: Sun Mar 1 18:29:43 2026 +0530 block: break pcpu_alloc_mutex dependency on freeze_lock [ Upstream commit 539d1b47e935e8384977dd7e5cec370c08b7a644 ] While nr_hw_update allocates tagset tags it acquires ->pcpu_alloc_mutex after ->freeze_lock is acquired or queue is frozen. This potentially creates a circular dependency involving ->fs_reclaim if reclaim is triggered simultaneously in a code path which first acquires ->pcpu_ alloc_mutex. As the queue is already frozen while nr_hw_queue update allocates tagsets, the reclaim can't forward progress and thus it could cause a potential deadlock as reported in lockdep splat[1]. Fix this by pre-allocating tagset tags before we freeze queue during nr_hw_queue update. Later the allocated tagset tags could be safely installed and used after queue is frozen. Reported-by: Yi Zhang Closes: https://lore.kernel.org/all/CAHj4cs8F=OV9s3La2kEQ34YndgfZP-B5PHS4Z8_b9euKG6J4mw@mail.gmail.com/ [1] Signed-off-by: Nilay Shroff Reviewed-by: Ming Lei Tested-by: Yi Zhang Reviewed-by: Yu Kuai [axboe: fix brace style issue] Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e33c0c59f1f4107e11a6a0b1e8084cd446d5548a Author: Isaac J. Manjarres Date: Mon Mar 2 16:23:09 2026 -0800 dma-buf: Include ioctl.h in UAPI header [ Upstream commit a116bac87118903925108e57781bbfc7a7eea27b ] include/uapi/linux/dma-buf.h uses several macros from ioctl.h to define its ioctl commands. However, it does not include ioctl.h itself. So, if userspace source code tries to include the dma-buf.h file without including ioctl.h, it can result in build failures. Therefore, include ioctl.h in the dma-buf UAPI header. Signed-off-by: Isaac J. Manjarres Reviewed-by: T.J. Mercier Reviewed-by: Christian König Signed-off-by: Christian König Link: https://lore.kernel.org/r/20260303002309.1401849-1-isaacmanjarres@google.com Signed-off-by: Sasha Levin commit 9924fd289901fb3c7195413e66c35e5e18ed91c0 Author: Richard Fitzgerald Date: Thu Feb 26 11:01:37 2026 +0000 ASoC: cs35l56: Only patch ASP registers if the DAI is part of a DAIlink [ Upstream commit 9351cf3fd92dc1349bb75f2f7f7324607dcf596f ] Move the ASP register patches to a separate struct and apply this from the ASP DAI probe() function so that the registers are only patched if the DAI is part of a DAI link. Some systems use the ASP as a special-purpose interconnect and on these systems the ASP registers are configured by a third party (the firmware, the BIOS, or another device using the amp's secondary host control interface). If the machine driver does not hook up the ASP DAI then the ASP registers must be omitted from the patch to prevent overwriting the third party configuration. If the machine driver includes the ASP DAI in a DAI link, this implies that the machine driver and higher components (such as alsa-ucm) are taking ownership of the ASP. In this case the ASP registers are patched to known defaults and the machine driver should configure the ASP. Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260226110137.1664562-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1e68eeada7b0e89171fe863a01c17890afe69456 Author: Mark Brown Date: Thu Feb 5 00:25:37 2026 +0000 ASoC: fsl_easrc: Fix event generation in fsl_easrc_iec958_put_bits() [ Upstream commit 54a86cf48eaa6d1ab5130d756b718775e81e1748 ] ALSA controls should return 1 if the value in the control changed but the control put operation fsl_easrc_iec958_put_bits() unconditionally returns 0, causing ALSA to not generate any change events. This is detected by mixer-test with large numbers of messages in the form: No event generated for Context 3 IEC958 CS5 Context 3 IEC958 CS5.0 orig 5224 read 5225, is_volatile 0 Add a suitable check. Signed-off-by: Mark Brown Link: https://patch.msgid.link/20260205-asoc-fsl-easrc-fix-events-v1-1-39d4c766918b@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 77759925aeb6c81d12ac5cf32ba540eae2c055a6 Author: Sheetal Date: Mon Mar 2 14:12:17 2026 +0530 ALSA: hda/hdmi: Add Tegra238 HDA codec device ID [ Upstream commit 5f4338e5633dc034a81000b2516a78cfb51c601d ] Add Tegra238 HDA codec device in hda_device_id list. Signed-off-by: Sheetal Link: https://patch.msgid.link/20260302084217.3135982-1-sheetal@nvidia.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 3d5f63d86720722f859a1769060b337b25352178 Author: Oliver Freyermuth Date: Tue Feb 24 20:02:24 2026 +0100 ASoC: Intel: sof_sdw: Add quirk for Alienware Area 51 (2025) 0CCD SKU [ Upstream commit 70eddf6a0a3fc6d3ab6f77251676da97cc7f12ae ] This adds the necessary quirk for the Alienware 18 Area 51 (2025). Complements commit 1b03391d073d ("ASoC: Intel: sof_sdw: Add quirk for Alienware Area 51 (2025) 0CCC SKU"). Signed-off-by: Oliver Freyermuth Tested-by: Oliver Freyermuth Link: https://patch.msgid.link/20260224190224.30630-1-o.freyermuth@googlemail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 74b25178943fee093cdf03347d7b5824a4c2a5de Author: Florian Fuchs Date: Fri Feb 27 19:18:23 2026 +0100 scsi: devinfo: Add BLIST_SKIP_IO_HINTS for Iomega ZIP [ Upstream commit 80bf3b28d32b431f84f244a8469488eb6d96afbb ] The Iomega ZIP 100 (Z100P2) can't process IO Advice Hints Grouping mode page query. It immediately switches to the status phase 0xb8 after receiving the subpage code 0x05 of MODE_SENSE_10 command, which fails imm_out() and turns into DID_ERROR of this command, which leads to unusable device. This was tested with an Iomega ZIP 100 (Z100P2) connected with a StarTech PEX1P2 AX99100 PCIe parallel port card. Prior to this fix, Test Unit Ready fails and the drive can't be used: IMM: returned SCSI status b8 sd 7:0:6:0: [sdh] Test Unit Ready failed: Result: hostbyte=0x01 driverbyte=DRIVER_OK Signed-off-by: Florian Fuchs Link: https://patch.msgid.link/20260227181823.892932-1-fuchsfl@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 09293aecd479182877a48b2be144e3210013568b Author: Shuming Fan Date: Wed Feb 25 17:12:10 2026 +0800 ASoC: rt1321: fix DMIC ch2/3 mask issue [ Upstream commit 986841dcad257615a6e3f89231bb38e1f3506b77 ] This patch fixed the DMIC ch2/3 mask missing problem. Signed-off-by: Shuming Fan Link: https://patch.msgid.link/20260225091210.3648905-1-shumingf@realtek.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 99c9a684b22d72d15f639d2b4f986599dcc85bc0 Author: Ranjan Kumar Date: Wed Feb 25 13:56:22 2026 +0530 scsi: mpi3mr: Clear reset history on ready and recheck state after timeout [ Upstream commit dbd53975ed4132d161b6a97ebe785a262380182d ] The driver retains reset history even after the IOC has successfully reached the READY state. That leaves stale reset information active during normal operation and can mislead recovery and diagnostics. In addition, if the IOC becomes READY just as the ready timeout loop exits, the driver still follows the failure path and may retry or report failure incorrectly. Clear reset history once READY is confirmed so driver state matches actual IOC status. After the timeout loop, recheck the IOC state and treat READY as success instead of failing. Signed-off-by: Ranjan Kumar Link: https://patch.msgid.link/20260225082622.82588-1-ranjan.kumar@broadcom.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f927555140c7cb6dd2e4222dc0a9e8ce0272af28 Author: Mark Brown Date: Thu Feb 5 00:25:38 2026 +0000 ASoC: fsl_easrc: Fix event generation in fsl_easrc_iec958_set_reg() [ Upstream commit 31ddc62c1cd92e51b9db61d7954b85ae2ec224da ] ALSA controls should return 1 if the value in the control changed but the control put operation fsl_easrc_set_reg() only returns 0 or a negative error code, causing ALSA to not generate any change events. Add a suitable check by using regmap_update_bits_check() with the underlying regmap, this is more clearly and simply correct than trying to verify that one of the generic ops is exactly equivalent to this one. Signed-off-by: Mark Brown Link: https://patch.msgid.link/20260205-asoc-fsl-easrc-fix-events-v1-2-39d4c766918b@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ef75dc1401d8e797ee51559a0dd0336c225e1776 Author: Ihor Solodrai Date: Tue Dec 30 10:32:08 2025 -0800 module: Fix kernel panic when a symbol st_shndx is out of bounds [ Upstream commit f9d69d5e7bde2295eb7488a56f094ac8f5383b92 ] The module loader doesn't check for bounds of the ELF section index in simplify_symbols(): for (i = 1; i < symsec->sh_size / sizeof(Elf_Sym); i++) { const char *name = info->strtab + sym[i].st_name; switch (sym[i].st_shndx) { case SHN_COMMON: [...] default: /* Divert to percpu allocation if a percpu var. */ if (sym[i].st_shndx == info->index.pcpu) secbase = (unsigned long)mod_percpu(mod); else /** HERE --> **/ secbase = info->sechdrs[sym[i].st_shndx].sh_addr; sym[i].st_value += secbase; break; } } A symbol with an out-of-bounds st_shndx value, for example 0xffff (known as SHN_XINDEX or SHN_HIRESERVE), may cause a kernel panic: BUG: unable to handle page fault for address: ... RIP: 0010:simplify_symbols+0x2b2/0x480 ... Kernel panic - not syncing: Fatal exception This can happen when module ELF is legitimately using SHN_XINDEX or when it is corrupted. Add a bounds check in simplify_symbols() to validate that st_shndx is within the valid range before using it. This issue was discovered due to a bug in llvm-objcopy, see relevant discussion for details [1]. [1] https://lore.kernel.org/linux-modules/20251224005752.201911-1-ihor.solodrai@linux.dev/ Signed-off-by: Ihor Solodrai Reviewed-by: Daniel Gomez Reviewed-by: Petr Pavlu Signed-off-by: Sami Tolvanen Signed-off-by: Sasha Levin commit 4ebc4d48fca9bbbf875d4431473dec0a5ace1a91 Author: Denis Benato Date: Mon Feb 16 18:55:38 2026 +0100 HID: asus: add xg mobile 2023 external hardware support [ Upstream commit 377f8e788945d45b012ed9cfc35ca56c02e86cd8 ] XG mobile stations have the 0x5a endpoint and has to be initialized: add them to hid-asus. Signed-off-by: Denis Benato Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit bf0ffc028f829cde22164dba919a8ba9be77177a Author: Romain Sioen Date: Fri Feb 6 17:32:58 2026 +0100 HID: mcp2221: cancel last I2C command on read error [ Upstream commit e31b556c0ba21f20c298aa61181b96541140b7b9 ] When an I2C SMBus read operation fails, the MCP2221 internal state machine may not reset correctly, causing subsequent transactions to fail. By adding a short delay and explicitly cancelling the last command, we ensure the device is ready for the next operation. Fix an issue where i2cdetect was not able to detect all devices correctly on the bus. Signed-off-by: Romain Sioen Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 0a4e44eb4b0c19549a9358fe7f68cb995de362b5 Author: Antheas Kapenekakis Date: Mon Feb 23 19:29:52 2026 +0100 platform/x86: oxpec: Add support for OneXPlayer X1 Air [ Upstream commit 2a3b4a8c10a64a62c4243007139d253dc1324dfd ] X1 Air is an X1 variant with a newer Intel chipset. It uses the same registers as the X1. Add a quirk for it to the oxpec driver. Signed-off-by: Antheas Kapenekakis Link: https://patch.msgid.link/20260223183004.2696892-4-lkml@antheas.dev Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit ba6af12e600bf0f011fe76bbee70eb73850d7758 Author: Antheas Kapenekakis Date: Mon Feb 23 19:29:53 2026 +0100 platform/x86: oxpec: Add support for Aokzoe A2 Pro [ Upstream commit cd0883055b04586770dab43c64159348bf480a3e ] Aokzoe A2 Pro is an older device that the oxpec driver is missing the quirk for. It has the same behavior as the AOKZOE A1 devices. Add a quirk for it to the oxpec driver. Signed-off-by: Antheas Kapenekakis Link: https://patch.msgid.link/20260223183004.2696892-5-lkml@antheas.dev Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 6ea6cfdbd6465eda004543fd0a07cd57984c783a Author: Thomas Weißschuh Date: Thu Feb 26 08:41:48 2026 +0100 kbuild: install-extmod-build: Package resolve_btfids if necessary [ Upstream commit 459cb3c054c2352bb321648744b620259a716b60 ] When CONFIG_DEBUG_INFO_BTF_MODULES is enabled and vmlinux is available, Makefile.modfinal and gen-btf.sh will try to use resolve_btfids on the module .ko. install-extmod-build currently does not package resolve_btfids, so that step fails. Package resolve_btfids if it may be used. Signed-off-by: Thomas Weißschuh Reviewed-by: Nicolas Schier Link: https://patch.msgid.link/20260226-kbuild-resolve_btfids-v1-1-2bf38b93dfe7@linutronix.de [nathan: Small commit message tweaks] Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit 4121e616c08ad31a6b6dda0bbec0e49c1a400f70 Author: Valentin Spreckels Date: Thu Feb 26 20:54:09 2026 +0100 net: usb: r8152: add TRENDnet TUC-ET2G [ Upstream commit 15fba71533bcdfaa8eeba69a5a5a2927afdf664a ] The TRENDnet TUC-ET2G is a RTL8156 based usb ethernet adapter. Add its vendor and product IDs. Signed-off-by: Valentin Spreckels Link: https://patch.msgid.link/20260226195409.7891-2-valentin@spreckels.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1faaa81aabab7af36b14057bf53516ae5ecb62da Author: Antheas Kapenekakis Date: Mon Feb 23 19:29:51 2026 +0100 platform/x86: oxpec: Add support for OneXPlayer X1z [ Upstream commit 4049c46edb5d44c0de045f6f504371705dd603dd ] X1z is a variant of OneXPlayer X1 A with 8840U. It seems that only one user has this one. Add a quirk for it to the oxpec driver. Signed-off-by: Antheas Kapenekakis Link: https://patch.msgid.link/20260223183004.2696892-3-lkml@antheas.dev Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit b06021c3cfd8cebbe05ce8f52d1a5ed5e548d475 Author: Takashi Iwai Date: Tue Feb 24 10:00:02 2026 +0100 HID: apple: Add EPOMAKER TH87 to the non-apple keyboards list [ Upstream commit 7c698de0dc5daa1e1a5fd1f0c6aa1b6bb2f5d867 ] EPOMAKER TH87 has the very same ID as Apple Aluminum keyboard (05ac:024f) although it doesn't work as expected in compatible way. Put three entries to the non-apple keyboards list to exclude this device: one for BT ("TH87"), one for USB ("HFD Epomaker TH87") and one for dongle ("2.4G Wireless Receiver"). Link: https://bugzilla.suse.com/show_bug.cgi?id=1258455 Signed-off-by: Takashi Iwai Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 43c40bfb8503897e26a48fb4fa0d257d8be4079c Author: Antheas Kapenekakis Date: Mon Feb 23 19:29:50 2026 +0100 platform/x86: oxpec: Add support for OneXPlayer APEX [ Upstream commit 3385ea97c14d271dcb0c6e6fcf16972f819eecd8 ] OneXPlayer Apex is a new Strix Halo handheld. It uses the same registers as the OneXPlayer Fly devices. Add a quirk for it to the oxpec driver. Signed-off-by: Antheas Kapenekakis Link: https://patch.msgid.link/20260223183004.2696892-2-lkml@antheas.dev Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit f061affafb599beccb6dc31a1cfdf93b517a5f25 Author: Zhang Lixu Date: Tue Feb 3 08:55:07 2026 +0800 HID: intel-ish-hid: ipc: Add Nova Lake-H/S PCI device IDs [ Upstream commit 22f8bcec5aeb05104b3eaa950cb5a345e95f0aa8 ] Add device IDs of Nova Lake-H and Nova Lake-S into ishtp support list. Signed-off-by: Zhang Lixu Reviewed-by: Andy Shevchenko Acked-by: Srinivas Pandruvada Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 136f605e246b4bfe7ac2259471d1ff814aed0084 Author: Günther Noack Date: Thu Feb 19 16:43:37 2026 +0100 HID: magicmouse: avoid memory leak in magicmouse_report_fixup() [ Upstream commit 91e8c6e601bdc1ccdf886479b6513c01c7e51c2c ] The magicmouse_report_fixup() function was returning a newly kmemdup()-allocated buffer, but never freeing it. The caller of report_fixup() does not take ownership of the returned pointer, but it *is* permitted to return a sub-portion of the input rdesc, whose lifetime is managed by the caller. Assisted-by: Gemini-CLI:Google Gemini 3 Signed-off-by: Günther Noack Signed-off-by: Benjamin Tissoires Signed-off-by: Sasha Levin commit 4101a437c2363b1a78866ac7d740c60d814e1147 Author: Julius Lehmann Date: Sat Feb 14 20:34:21 2026 +0100 HID: magicmouse: fix battery reporting for Apple Magic Trackpad 2 [ Upstream commit 5f3518d77419255f8b12bb23c8ec22acbeb6bc5b ] Battery reporting does not work for the Apple Magic Trackpad 2 if it is connected via USB. The current hid descriptor fixup code checks for a hid descriptor length of exactly 83 bytes. If the hid descriptor is larger, which is the case for newer apple mice, the fixup is not applied. This fix checks for hid descriptor sizes greater/equal 83 bytes which applies the fixup for newer devices as well. Signed-off-by: Julius Lehmann Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit b96c7b25eb1b748f3e3b1832ebf028b0b223d7e3 Author: Keith Busch Date: Tue Feb 10 09:26:54 2026 -0800 nvme-pci: ensure we're polling a polled queue [ Upstream commit 166e31d7dbf6aa44829b98aa446bda5c9580f12a ] A user can change the polled queue count at run time. There's a brief window during a reset where a hipri task may try to poll that queue before the block layer has updated the queue maps, which would race with the now interrupt driven queue and may cause double completions. Reviewed-by: Christoph Hellwig Reviewed-by: Kanchan Joshi Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 4877461104f2e22b378cc2dff2bb07ad74368556 Author: Hans de Goede Date: Tue Feb 17 14:23:46 2026 +0100 platform/x86: touchscreen_dmi: Add quirk for y-inverted Goodix touchscreen on SUPI S10 [ Upstream commit 7d87ed70fc95482c12edf9493c249b6413be485e ] The touchscreen on the SUPI S10 tablet reports inverted Y coordinates, causing touch input to be mirrored vertically relative to the display. Add a quirk to set the "touchscreen-inverted-y" boolean device-property on the touchscreen device, so that the goodix_ts driver will fixup the coordinates. Reported-by: Yajat Kumar Closes: https://lore.kernel.org/linux-input/20251230221639.582406-1-yajatapps3@gmail.com/ Tested-by: Yajat Kumar Signed-off-by: Hans de Goede Link: https://patch.msgid.link/20260217132346.34535-1-johannes.goede@oss.qualcomm.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 05bc9939b501fb08501904ab274db00ccfacd5de Author: Leif Skunberg Date: Tue Feb 10 09:56:25 2026 +0100 platform/x86: intel-hid: Enable 5-button array on ThinkPad X1 Fold 16 Gen 1 [ Upstream commit b38d478dad79e61e8a65931021bdfd7a71741212 ] The Lenovo ThinkPad X1 Fold 16 Gen 1 has physical volume up/down buttons that are handled through the intel-hid 5-button array interface. The firmware does not advertise 5-button array support via HEBC, so the driver relies on a DMI allowlist to enable it. Add the ThinkPad X1 Fold 16 Gen 1 to the button_array_table so the volume buttons work out of the box. Signed-off-by: Leif Skunberg Reviewed-by: Hans de Goede Link: https://patch.msgid.link/20260210085625.34380-1-diamondback@cohunt.app Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 94b2a56fd4b1c774194b1855893d123fe86008a6 Author: Krishna Chomal Date: Wed Feb 18 10:32:35 2026 +0530 platform/x86: hp-wmi: Add Omen 16-xd0xxx fan and thermal support [ Upstream commit 3c99a545b372c77b5d39715968a141f523eccbf2 ] The HP Omen 16-xd0xxx (board ID: 8BCD) has the same WMI interface as other Victus S boards, but requires quirks for correctly switching thermal profile (similar to HP Omen 16-wf1xxx, board ID: 8C78). Add the DMI board name to victus_s_thermal_profile_boards[] table and map it to omen_v1_thermal_params. Testing on HP Omen 16-xd0xxx confirmed that platform profile is registered successfully and fan RPMs are readable and controllable. Tested-by: Varad Amol Pisale Signed-off-by: Krishna Chomal Link: https://patch.msgid.link/20260218050235.94687-1-krishna.chomal108@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 470e01ae896c0aa6c36c04561aae9b82beb70d95 Author: Daniel Hodges Date: Sat Jan 31 19:08:40 2026 -0800 nvme-fabrics: use kfree_sensitive() for DHCHAP secrets [ Upstream commit 0a1fc2f301529ac75aec0ce80d5ab9d9e4dc4b16 ] The DHCHAP secrets (dhchap_secret and dhchap_ctrl_secret) contain authentication key material for NVMe-oF. Use kfree_sensitive() instead of kfree() in nvmf_free_options() to ensure secrets are zeroed before the memory is freed, preventing recovery from freed pages. Reviewed-by: Christoph Hellwig Signed-off-by: Daniel Hodges Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 2e9b4ca982d817db20c14fb149bebeaec328c857 Author: Keith Busch Date: Tue Feb 10 11:00:12 2026 -0800 nvme-pci: cap queue creation to used queues [ Upstream commit 4735b510a00fb2d4ac9e8d21a8c9552cb281f585 ] If the user reduces the special queue count at runtime and resets the controller, we need to reduce the number of queues and interrupts requested accordingly rather than start with the pre-allocated queue count. Tested-by: Kanchan Joshi Reviewed-by: Kanchan Joshi Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 47910033f542e4d6a2f98934ec3e3f052d07f0a8 Author: Peter Metz Date: Thu Feb 12 23:46:27 2026 -0500 platform/x86: intel-hid: Add Dell 14 Plus 2-in-1 to dmi_vgbs_allow_list [ Upstream commit 6b3fa0615cd8432148581de62a52f83847af3d70 ] The Dell 14 Plus 2-in-1 (model DB04250) requires the VGBS allow list entry to correctly enable the tablet mode switch. Without this, the chassis state is not reported, and the hinge rotation only emits unknown scancodes. Verified on Dell 14 Plus 2-in-1 DB04250. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221090 Signed-off-by: Peter Metz Reviewed-by: Hans de Goede Link: https://patch.msgid.link/20260213044627.203638-1-peter.metz@unarin.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit a41cc7c1668e44ff2c2d36f9a6353253ffc43e3c Author: Günther Noack Date: Thu Feb 19 16:43:38 2026 +0100 HID: asus: avoid memory leak in asus_report_fixup() [ Upstream commit 2bad24c17742fc88973d6aea526ce1353f5334a3 ] The asus_report_fixup() function was returning a newly allocated kmemdup()-allocated buffer, but never freeing it. Switch to devm_kzalloc() to ensure the memory is managed and freed automatically when the device is removed. The caller of report_fixup() does not take ownership of the returned pointer, but it is permitted to return a pointer whose lifetime is at least that of the input buffer. Also fix a harmless out-of-bounds read by copying only the original descriptor size. Assisted-by: Gemini-CLI:Google Gemini 3 Signed-off-by: Günther Noack Signed-off-by: Benjamin Tissoires Signed-off-by: Sasha Levin commit c6a021ae84aa146ae86890c0e01a93207844163d Author: Krishna Chomal Date: Mon Feb 16 12:50:03 2026 +0530 platform/x86: hp-wmi: Add Omen 16-wf0xxx fan and thermal support [ Upstream commit 13fa3aaf02edaad9b41fc61d7f6326d2b6a4bf80 ] The HP Omen 16-wf0xxx (board ID: 8BAB) has the same WMI interface as other Victus S boards, but requires quirks for correctly switching thermal profile (similar to HP Omen 16-wf1xxx, board ID: 8C78). Add the DMI board name to victus_s_thermal_profile_boards[] table and map it to omen_v1_thermal_params. Testing on HP Omen 16-wf0xxx confirmed that platform profile is registered successfully and fan RPMs are readable and controllable. Suggested-by: Noah Provenzano Tested-by: Juan Martin Morales Reported-by: Juan Martin Morales Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220639 Signed-off-by: Krishna Chomal Link: https://patch.msgid.link/20260216072003.90151-1-krishna.chomal108@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 61415d080d43170e507beeaa842bab6f35db885b Author: Xuewen Yan Date: Fri Mar 6 15:59:54 2026 +0800 tracing: Revert "tracing: Remove pid in task_rename tracing output" [ Upstream commit a6f22e50c7d51aa225c392c62c33f0fae11f734d ] This reverts commit e3f6a42272e028c46695acc83fc7d7c42f2750ad. The commit says that the tracepoint only deals with the current task, however the following case is not current task: comm_write() { p = get_proc_task(inode); if (!p) return -ESRCH; if (same_thread_group(current, p)) set_task_comm(p, buffer); } where set_task_comm() calls __set_task_comm() which records the update of p and not current. So revert the patch to show pid. Cc: Cc: Cc: Cc: Link: https://patch.msgid.link/20260306075954.4533-1-xuewen.yan@unisoc.com Fixes: e3f6a42272e0 ("tracing: Remove pid in task_rename tracing output") Reported-by: Guohua Yan Signed-off-by: Xuewen Yan Reviewed-by: Steven Rostedt (Google) Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 58bd87d0e69204dbd739e4387a1edb0c4b1644e7 Author: Daniel Wade Date: Sat Mar 14 13:15:20 2026 +1100 bpf: Fix unsound scalar forking in maybe_fork_scalars() for BPF_OR [ Upstream commit c845894ebd6fb43226b3118d6b017942550910c5 ] maybe_fork_scalars() is called for both BPF_AND and BPF_OR when the source operand is a constant. When dst has signed range [-1, 0], it forks the verifier state: the pushed path gets dst = 0, the current path gets dst = -1. For BPF_AND this is correct: 0 & K == 0. For BPF_OR this is wrong: 0 | K == K, not 0. The pushed path therefore tracks dst as 0 when the runtime value is K, producing an exploitable verifier/runtime divergence that allows out-of-bounds map access. Fix this by passing env->insn_idx (instead of env->insn_idx + 1) to push_stack(), so the pushed path re-executes the ALU instruction with dst = 0 and naturally computes the correct result for any opcode. Fixes: bffacdb80b93 ("bpf: Recognize special arithmetic shift in the verifier") Signed-off-by: Daniel Wade Reviewed-by: Amery Hung Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260314021521.128361-2-danjwade95@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit f14ca604c0ff274fba19f73f1f0485c0047c1396 Author: Jenny Guanni Qu Date: Wed Mar 11 01:11:15 2026 +0000 bpf: Fix undefined behavior in interpreter sdiv/smod for INT_MIN [ Upstream commit c77b30bd1dcb61f66c640ff7d2757816210c7cb0 ] The BPF interpreter's signed 32-bit division and modulo handlers use the kernel abs() macro on s32 operands. The abs() macro documentation (include/linux/math.h) explicitly states the result is undefined when the input is the type minimum. When DST contains S32_MIN (0x80000000), abs((s32)DST) triggers undefined behavior and returns S32_MIN unchanged on arm64/x86. This value is then sign-extended to u64 as 0xFFFFFFFF80000000, causing do_div() to compute the wrong result. The verifier's abstract interpretation (scalar32_min_max_sdiv) computes the mathematically correct result for range tracking, creating a verifier/interpreter mismatch that can be exploited for out-of-bounds map value access. Introduce abs_s32() which handles S32_MIN correctly by casting to u32 before negating, avoiding signed overflow entirely. Replace all 8 abs((s32)...) call sites in the interpreter's sdiv32/smod32 handlers. s32 is the only affected case -- the s64 division/modulo handlers do not use abs(). Fixes: ec0e2da95f72 ("bpf: Support new signed div/mod instructions.") Acked-by: Yonghong Song Acked-by: Mykyta Yatsenko Signed-off-by: Jenny Guanni Qu Link: https://lore.kernel.org/r/20260311011116.2108005-2-qguanni@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit c0281da1f2aa5c2fca3a05f79b86bea96591c358 Author: Ihor Solodrai Date: Thu Mar 19 17:08:08 2026 -0700 bpf: Fix exception exit lock checking for subprogs [ Upstream commit 6c2128505f61b504c79a20b89596feba61388112 ] process_bpf_exit_full() passes check_lock = !curframe to check_resource_leak(), which is false in cases when bpf_throw() is called from a static subprog. This makes check_resource_leak() to skip validation of active_rcu_locks, active_preempt_locks, and active_irq_id on exception exits from subprogs. At runtime bpf_throw() unwinds the stack via ORC without releasing any user-acquired locks, which may cause various issues as the result. Fix by setting check_lock = true for exception exits regardless of curframe, since exceptions bypass all intermediate frame cleanup. Update the error message prefix to "bpf_throw" for exception exits to distinguish them from normal BPF_EXIT. Fix reject_subprog_with_rcu_read_lock test which was previously passing for the wrong reason. Test program returned directly from the subprog call without closing the RCU section, so the error was triggered by the unclosed RCU lock on normal exit, not by bpf_throw. Update __msg annotations for affected tests to match the new "bpf_throw" error prefix. The spin_lock case is not affected because they are already checked [1] at the call site in do_check_insn() before bpf_throw can run. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/bpf/verifier.c?h=v7.0-rc4#n21098 Assisted-by: Claude:claude-opus-4-6 Fixes: f18b03fabaa9 ("bpf: Implement BPF exceptions") Signed-off-by: Ihor Solodrai Acked-by: Yonghong Song Acked-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260320000809.643798-1-ihor.solodrai@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit a85bbd9ef8a0d9d6d45b42e3bf9af58f57d9e616 Author: Cui Chao Date: Thu Mar 19 15:45:35 2026 +0800 cxl: Adjust the startup priority of cxl_pmem to be higher than that of cxl_acpi [ Upstream commit be5c5280cf2b20e363dc8e2a424dd200a29b1c77 ] During the cxl_acpi probe process, it checks whether the cxl_nvb device and driver have been attached. Currently, the startup priority of the cxl_pmem driver is lower than that of the cxl_acpi driver. At this point, the cxl_nvb driver has not yet been registered on the cxl_bus, causing the attachment check to fail. This results in a failure to add the root nvdimm bridge, leading to a cxl_acpi probe failure and ultimately affecting the subsequent loading of cxl drivers. As a consequence, only one mem device object exists on the cxl_bus, while the cxl_port device objects and decoder device objects are missing. The solution is to raise the startup priority of cxl_pmem to be higher than that of cxl_acpi, ensuring that the cxl_pmem driver is registered before the aforementioned attachment check occurs. Co-developed-by: Wang Yinfeng Signed-off-by: Wang Yinfeng Signed-off-by: Cui Chao Fixes: e7e222ad73d9 ("cxl: Move devm_cxl_add_nvdimm_bridge() to cxl_pmem.ko") Reviewed-by: Dan Williams Link: https://patch.msgid.link/20260319074535.1709250-1-cuichao1753@phytium.com.cn Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit a446dbcb387759fa2fe063e3cf60951f8f3a6e45 Author: Kumar Kartikeya Dwivedi Date: Thu Mar 12 13:53:07 2026 -0700 bpf: Release module BTF IDR before module unload [ Upstream commit 146bd2a87a65aa407bb17fac70d8d583d19aba06 ] Gregory reported in [0] that the global_map_resize test when run in repeatedly ends up failing during program load. This stems from the fact that BTF reference has not dropped to zero after the previous run's module is unloaded, and the older module's BTF is still discoverable and visible. Later, in libbpf, load_module_btfs() will find the ID for this stale BTF, open its fd, and then it will be used during program load where later steps taking module reference using btf_try_get_module() fail since the underlying module for the BTF is gone. Logically, once a module is unloaded, it's associated BTF artifacts should become hidden. The BTF object inside the kernel may still remain alive as long its reference counts are alive, but it should no longer be discoverable. To fix this, let us call btf_free_id() from the MODULE_STATE_GOING case for the module unload to free the BTF associated IDR entry, and disable its discovery once module unload returns to user space. If a race happens during unload, the outcome is non-deterministic anyway. However, user space should be able to rely on the guarantee that once it has synchronously established a successful module unload, no more stale artifacts associated with this module can be obtained subsequently. Note that we must be careful to not invoke btf_free_id() in btf_put() when btf_is_module() is true now. There could be a window where the module unload drops a non-terminal reference, frees the IDR, but the same ID gets reused and the second unconditional btf_free_id() ends up releasing an unrelated entry. To avoid a special case for btf_is_module() case, set btf->id to zero to make btf_free_id() idempotent, such that we can unconditionally invoke it from btf_put(), and also from the MODULE_STATE_GOING case. Since zero is an invalid IDR, the idr_remove() should be a noop. Note that we can be sure that by the time we reach final btf_put() for btf_is_module() case, the btf_free_id() is already done, since the module itself holds the BTF reference, and it will call this function for the BTF before dropping its own reference. [0]: https://lore.kernel.org/bpf/cover.1773170190.git.grbell@redhat.com Fixes: 36e68442d1af ("bpf: Load and verify kernel module BTFs") Acked-by: Martin KaFai Lau Suggested-by: Martin KaFai Lau Reported-by: Gregory Bell Reviewed-by: Emil Tsalapatis Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260312205307.1346991-1-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 7c02a9bd7d14a89065fcf672b86d8e1d1a41d3b1 Author: Danilo Krummrich Date: Tue Mar 3 12:53:21 2026 +0100 driver core: platform: use generic driver_override infrastructure [ Upstream commit 2b38efc05bf7a8568ec74bfffea0f5cfa62bc01d ] 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: 3d713e0e382e ("driver core: platform: add device binding path 'driver_override'") Reviewed-by: Greg Kroah-Hartman Link: https://patch.msgid.link/20260303115720.48783-5-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit ad9465ca3444c70a164ff81caa457b46318c1a6d Author: Danilo Krummrich Date: Tue Mar 3 12:53:18 2026 +0100 driver core: generalize driver_override in struct device [ Upstream commit cb3d1049f4ea77d5ad93f17d8ac1f2ed4da70501 ] Currently, there are 12 busses (including platform and PCI) that duplicate the driver_override logic for their individual devices. All of them seem to be prone to the bug described in [1]. While this could be solved for every bus individually using a separate lock, solving this in the driver-core generically results in less (and cleaner) changes overall. Thus, move driver_override to struct device, provide corresponding accessors for busses and handle locking with a separate lock internally. In particular, add device_set_driver_override(), device_has_driver_override(), device_match_driver_override() and generalize the sysfs store() and show() callbacks via a driver_override feature flag in struct bus_type. Until all busses have migrated, keep driver_set_override() in place. Note that we can't use the device lock for the reasons described in [2]. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220789 [1] Link: https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/ [2] Tested-by: Gui-Dong Han Co-developed-by: Gui-Dong Han Signed-off-by: Gui-Dong Han Reviewed-by: Greg Kroah-Hartman Link: https://patch.msgid.link/20260303115720.48783-2-dakr@kernel.org [ Use dev->bus instead of sp->bus for consistency; fix commit message to refer to the struct bus_type's driver_override feature flag. - Danilo ] Signed-off-by: Danilo Krummrich Stable-dep-of: 2b38efc05bf7 ("driver core: platform: use generic driver_override infrastructure") Signed-off-by: Sasha Levin commit 1b1f570444dcc8dba025352842c87bbb8d05212e Author: Danilo Krummrich Date: Tue Mar 17 00:37:15 2026 +0100 sh: platform_early: remove pdev->driver_override check [ Upstream commit c5f60e3f07b6609562d21efda878e83ce8860728 ] In commit 507fd01d5333 ("drivers: move the early platform device support to arch/sh") platform_match() was copied over to the sh platform_early code, accidentally including the driver_override check. This check does not make sense for platform_early, as sysfs is not even available in first place at this point in the boot process, hence remove the check. Reviewed-by: Greg Kroah-Hartman Reviewed-by: Geert Uytterhoeven Fixes: 507fd01d5333 ("drivers: move the early platform device support to arch/sh") Link: https://lore.kernel.org/all/DH4M3DJ4P58T.1BGVAVXN71Z09@kernel.org/ Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 1f11dc6dc792e5fd5f90d7ec59f6e09a8d07c46c Author: Danilo Krummrich Date: Tue Mar 3 12:53:20 2026 +0100 hwmon: axi-fan: don't use driver_override as IRQ name [ Upstream commit 813bbc4d33d2ca5b0da63e70ae13b60874f20d37 ] Do not use driver_override as IRQ name, as it is not guaranteed to point to a valid string; use NULL instead (which makes the devm IRQ helpers use dev_name()). Fixes: 8412b410fa5e ("hwmon: Support ADI Fan Control IP") Reviewed-by: Nuno Sá Acked-by: Guenter Roeck Reviewed-by: Greg Kroah-Hartman Link: https://patch.msgid.link/20260303115720.48783-4-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit e85f446e82aae76aef010a97331d8f9c922dfdce Author: Smita Koralahalli Date: Mon Mar 16 20:19:49 2026 +0000 cxl/hdm: Avoid incorrect DVSEC fallback when HDM decoders are enabled [ Upstream commit 75cea0776de502f2a1be5ca02d37c586dc81887e ] Check the global CXL_HDM_DECODER_ENABLE bit instead of looping over per-decoder COMMITTED bits to determine whether to fall back to DVSEC range emulation. When the HDM decoder capability is globally enabled, ignore DVSEC range registers regardless of individual decoder commit state. should_emulate_decoders() currently loops over per-decoder COMMITTED bits, which leads to an incorrect DVSEC fallback when those bits are zero. One way to trigger this is to destroy a region and bounce the memdev: cxl disable-region region0 cxl destroy-region region0 cxl disable-memdev mem0 cxl enable-memdev mem0 Region teardown zeroes the HDM decoder registers including the committed bits. The subsequent memdev re-probe finds uncommitted decoders and falls back to DVSEC emulation, even though HDM remains globally enabled. Observed failures: should_emulate_decoders: cxl_port endpoint6: decoder6.0: committed: 0 base: 0x0_00000000 size: 0x0_00000000 devm_cxl_setup_hdm: cxl_port endpoint6: Fallback map 1 range register .. devm_cxl_add_region: cxl_acpi ACPI0017:00: decoder0.0: created region0 __construct_region: cxl_pci 0000:e1:00.0: mem1:decoder6.0: __construct_region region0 res: [mem 0x850000000-0x284fffffff flags 0x200] iw: 1 ig: 4096 cxl region0: pci0000:e0:port1 cxl_port_setup_targets expected iw: 1 ig: 4096 .. cxl region0: pci0000:e0:port1 cxl_port_setup_targets got iw: 1 ig: 256 state: disabled .. cxl_port endpoint6: failed to attach decoder6.0 to region0: -6 .. devm_cxl_add_region: cxl_acpi ACPI0017:00: decoder0.0: created region4 alloc_hpa: cxl region4: HPA allocation error (-34) .. Fixes: 52cc48ad2a76 ("cxl/hdm: Limit emulation to the number of range registers") Signed-off-by: Smita Koralahalli Reviewed-by: Dan Williams Link: https://patch.msgid.link/20260316201950.224567-1-Smita.KoralahalliChannabasappa@amd.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit b36b0e804aee5f20c6798dbeaeaa7cfdb7c6cf88 Author: Janosch Frank Date: Wed Mar 4 10:18:37 2026 +0000 s390/mm: Add missing secure storage access fixups for donated memory [ Upstream commit b00be77302d7ec4ad0367bb236494fce7172b730 ] There are special cases where secure storage access exceptions happen in a kernel context for pages that don't have the PG_arch_1 bit set. That bit is set for non-exported guest secure storage (memory) but is absent on storage donated to the Ultravisor since the kernel isn't allowed to export donated pages. Prior to this patch we would try to export the page by calling arch_make_folio_accessible() which would instantly return since the arch bit is absent signifying that the page was already exported and no further action is necessary. This leads to secure storage access exception loops which can never be resolved. With this patch we unconditionally try to export and if that fails we fixup. Fixes: 084ea4d611a3 ("s390/mm: add (non)secure page access exceptions handlers") Reported-by: Heiko Carstens Suggested-by: Heiko Carstens Reviewed-by: Claudio Imbrenda Tested-by: Christian Borntraeger Signed-off-by: Janosch Frank Signed-off-by: Christian Borntraeger Signed-off-by: Sasha Levin commit 35f7914e54fe7f13654c22ee045b05e4b6d8062b Author: Peter Zijlstra Date: Mon Mar 9 13:55:46 2026 +0100 perf: Make sure to use pmu_ctx->pmu for groups [ Upstream commit 4b9ce671960627b2505b3f64742544ae9801df97 ] Oliver reported that x86_pmu_del() ended up doing an out-of-bound memory access when group_sched_in() fails and needs to roll back. This *should* be handled by the transaction callbacks, but he found that when the group leader is a software event, the transaction handlers of the wrong PMU are used. Despite the move_group case in perf_event_open() and group_sched_in() using pmu_ctx->pmu. Turns out, inherit uses event->pmu to clone the events, effectively undoing the move_group case for all inherited contexts. Fix this by also making inherit use pmu_ctx->pmu, ensuring all inherited counters end up in the same pmu context. Similarly, __perf_event_read() should use equally use pmu_ctx->pmu for the group case. Fixes: bd2756811766 ("perf: Rewrite core context handling") Reported-by: Oliver Rosenberg Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Ian Rogers Link: https://patch.msgid.link/20260309133713.GB606826@noisy.programming.kicks-ass.net Signed-off-by: Sasha Levin commit d94e6989e26c8ee2550f1fad04161722433b7ce6 Author: Peter Zijlstra Date: Wed Mar 11 21:29:14 2026 +0100 x86/perf: Make sure to program the counter value for stopped events on migration [ Upstream commit f1cac6ac62d28a9a57b17f51ac5795bf250c12d3 ] Both Mi Dapeng and Ian Rogers noted that not everything that sets HES_STOPPED is required to EF_UPDATE. Specifically the 'step 1' loop of rescheduling explicitly does EF_UPDATE to ensure the counter value is read. However, then 'step 2' simply leaves the new counter uninitialized when HES_STOPPED, even though, as noted above, the thing that stopped them might not be aware it needs to EF_RELOAD -- since it didn't EF_UPDATE on stop. One such location that is affected is throttling, throttle does pmu->stop(, 0); and unthrottle does pmu->start(, 0); possibly restarting an uninitialized counter. Fixes: a4eaf7f14675 ("perf: Rework the PMU methods") Reported-by: Dapeng Mi Reported-by: Ian Rogers Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dapeng Mi Link: https://patch.msgid.link/20260311204035.GX606826@noisy.programming.kicks-ass.net Signed-off-by: Sasha Levin commit ccbf29b28b5554f9d65b2fb53b994673ad58b3bf Author: Sachin Kumar Date: Mon Mar 9 18:25:42 2026 +0000 bpf: Fix constant blinding for PROBE_MEM32 stores [ Upstream commit 2321a9596d2260310267622e0ad8fbfa6f95378f ] BPF_ST | BPF_PROBE_MEM32 immediate stores are not handled by bpf_jit_blind_insn(), allowing user-controlled 32-bit immediates to survive unblinded into JIT-compiled native code when bpf_jit_harden >= 1. The root cause is that convert_ctx_accesses() rewrites BPF_ST|BPF_MEM to BPF_ST|BPF_PROBE_MEM32 for arena pointer stores during verification, before bpf_jit_blind_constants() runs during JIT compilation. The blinding switch only matches BPF_ST|BPF_MEM (mode 0x60), not BPF_ST|BPF_PROBE_MEM32 (mode 0xa0). The instruction falls through unblinded. Add BPF_ST|BPF_PROBE_MEM32 cases to bpf_jit_blind_insn() alongside the existing BPF_ST|BPF_MEM cases. The blinding transformation is identical: load the blinded immediate into BPF_REG_AX via mov+xor, then convert the immediate store to a register store (BPF_STX). The rewritten STX instruction must preserve the BPF_PROBE_MEM32 mode so the architecture JIT emits the correct arena addressing (R12-based on x86-64). Cannot use the BPF_STX_MEM() macro here because it hardcodes BPF_MEM mode; construct the instruction directly instead. Fixes: 6082b6c328b5 ("bpf: Recognize addr_space_cast instruction in the verifier.") Reviewed-by: Puranjay Mohan Reviewed-by: Emil Tsalapatis Signed-off-by: Sachin Kumar Acked-by: Daniel Borkmann Link: https://lore.kernel.org/r/Y6IT5VvNRchPBLI5D7JZHBzZrU9rb0ycRJPJzJSXGj7kJlX8RJwZFSM2YZjcDxoQKABkxt1T8Os2gi23PYyFuQe6KkZGWVyfz8K5afdy9ak=@protonmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit a17443af874229408ce6b78e2c8a2b5adeb4b7d8 Author: Yazhou Tang Date: Wed Mar 4 16:32:27 2026 +0800 bpf: Reset register ID for BPF_END value tracking [ Upstream commit a3125bc01884431d30d731461634c8295b6f0529 ] When a register undergoes a BPF_END (byte swap) operation, its scalar value is mutated in-place. If this register previously shared a scalar ID with another register (e.g., after an `r1 = r0` assignment), this tie must be broken. Currently, the verifier misses resetting `dst_reg->id` to 0 for BPF_END. Consequently, if a conditional jump checks the swapped register, the verifier incorrectly propagates the learned bounds to the linked register, leading to false confidence in the linked register's value and potentially allowing out-of-bounds memory accesses. Fix this by explicitly resetting `dst_reg->id` to 0 in the BPF_END case to break the scalar tie, similar to how BPF_NEG handles it via `__mark_reg_known`. Fixes: 9d2119984224 ("bpf: Add bitwise tracking for BPF_END") Closes: https://lore.kernel.org/bpf/AMBPR06MB108683CFEB1CB8D9E02FC95ECF17EA@AMBPR06MB10868.eurprd06.prod.outlook.com/ Link: https://lore.kernel.org/bpf/4be25f7442a52244d0dd1abb47bc6750e57984c9.camel@gmail.com/ Reported-by: Guillaume Laporte Co-developed-by: Tianci Cao Signed-off-by: Tianci Cao Co-developed-by: Shenghao Yuan Signed-off-by: Shenghao Yuan Signed-off-by: Yazhou Tang Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260304083228.142016-2-tangyazhou@zju.edu.cn Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 2c32141462045cf93d54a5146a0ba572b83533dd Author: Alison Schofield Date: Thu Feb 26 10:44:36 2026 -0800 cxl/port: Fix use after free of parent_port in cxl_detach_ep() [ Upstream commit 19d2f0b97a131198efc2c4ca3eb7f980bba8c2b4 ] cxl_detach_ep() is called during bottom-up removal when all CXL memory devices beneath a switch port have been removed. For each port in the hierarchy it locks both the port and its parent, removes the endpoint, and if the port is now empty, marks it dead and unregisters the port by calling delete_switch_port(). There are two places during this work where the parent_port may be used after freeing: First, a concurrent detach may have already processed a port by the time a second worker finds it via bus_find_device(). Without pinning parent_port, it may already be freed when we discover port->dead and attempt to unlock the parent_port. In a production kernel that's a silent memory corruption, with lock debug, it looks like this: []DEBUG_LOCKS_WARN_ON(__owner_task(owner) != get_current()) []WARNING: kernel/locking/mutex.c:949 at __mutex_unlock_slowpath+0x1ee/0x310 []Call Trace: []mutex_unlock+0xd/0x20 []cxl_detach_ep+0x180/0x400 [cxl_core] []devm_action_release+0x10/0x20 []devres_release_all+0xa8/0xe0 []device_unbind_cleanup+0xd/0xa0 []really_probe+0x1a6/0x3e0 Second, delete_switch_port() releases three devm actions registered against parent_port. The last of those is unregister_port() and it calls device_unregister() on the child port, which can cascade. If parent_port is now also empty the device core may unregister and free it too. So by the time delete_switch_port() returns, parent_port may be free, and the subsequent device_unlock(&parent_port->dev) operates on freed memory. The kernel log looks same as above, with a different offset in cxl_detach_ep(). Both of these issues stem from the absence of a lifetime guarantee between a child port and its parent port. Establish a lifetime rule for ports: child ports hold a reference to their parent device until release. Take the reference when the port is allocated and drop it when released. This ensures the parent is valid for the full lifetime of the child and eliminates the use after free window in cxl_detach_ep(). This is easily reproduced with a reload of cxl_acpi in QEMU with CXL devices present. Fixes: 2345df54249c ("cxl/memdev: Fix endpoint port removal") Reviewed-by: Dave Jiang Reviewed-by: Li Ming Signed-off-by: Alison Schofield Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/20260226184439.1732841-1-alison.schofield@intel.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 40410158d77da3feeecfdaabea6dc4251f242032 Author: Alexandre Frade Date: Wed Mar 25 17:12:04 2026 +0000 Linux 6.18.20-xanmod1 Signed-off-by: Alexandre Frade commit a60ab72620d305e609f3e1bd82667b19cb560482 Merge: 8c86bc38bc32 dd26ea937ef5 Author: Alexandre Frade Date: Wed Mar 25 17:10:35 2026 +0000 Merge tag 'v6.18.20' into 6.18 This is the 6.18.20 stable release commit dd26ea937ef593a9c47aa4c85296e6b57a5344a1 Author: Greg Kroah-Hartman Date: Wed Mar 25 11:10:46 2026 +0100 Linux 6.18.20 Link: https://lore.kernel.org/r/20260323134503.770111826@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Peter Schneider Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Jeffrin Jose T Tested-by: Ron Economos Tested-by: Jon Hunter Tested-by: Wentao Guan Tested-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit a52e3970f971771b79950d38aa5479bcf5755a91 Author: Juergen Gross Date: Tue Oct 14 13:28:15 2025 +0200 xen/privcmd: add boot control for restricted usage in domU commit 1613462be621ad5103ec338a7b0ca0746ec4e5f1 upstream. When running in an unprivileged domU under Xen, the privcmd driver is restricted to allow only hypercalls against a target domain, for which the current domU is acting as a device model. Add a boot parameter "unrestricted" to allow all hypercalls (the hypervisor will still refuse destructive hypercalls affecting other guests). Make this new parameter effective only in case the domU wasn't started using secure boot, as otherwise hypercalls targeting the domU itself might result in violating the secure boot functionality. This is achieved by adding another lockdown reason, which can be tested to not being set when applying the "unrestricted" option. This is part of XSA-482 Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 389bae9a4409934e8b8d4dbdaaf02a3ae71cf8e4 Author: Juergen Gross Date: Thu Oct 9 16:54:58 2025 +0200 xen/privcmd: restrict usage in unprivileged domU commit 453b8fb68f3641fea970db88b7d9a153ed2a37e8 upstream. The Xen privcmd driver allows to issue arbitrary hypercalls from user space processes. This is normally no problem, as access is usually limited to root and the hypervisor will deny any hypercalls affecting other domains. In case the guest is booted using secure boot, however, the privcmd driver would be enabling a root user process to modify e.g. kernel memory contents, thus breaking the secure boot feature. The only known case where an unprivileged domU is really needing to use the privcmd driver is the case when it is acting as the device model for another guest. In this case all hypercalls issued via the privcmd driver will target that other guest. Fortunately the privcmd driver can already be locked down to allow only hypercalls targeting a specific domain, but this mode can be activated from user land only today. The target domain can be obtained from Xenstore, so when not running in dom0 restrict the privcmd driver to that target domain from the beginning, resolving the potential problem of breaking secure boot. This is XSA-482 Reported-by: Teddy Astie Fixes: 1c5de1939c20 ("xen: add privcmd driver") Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit f909f22f5cec6553d0d6a708393d422ba1ebae46 Author: Guenter Roeck Date: Thu Mar 19 21:31:22 2026 -0700 hwmon: (max6639) Fix pulses-per-revolution implementation [ Upstream commit e7bae9a7a5e1251ab414291f4e9304d702bb9221 ] The valid range for the pulses-per-revolution devicetree property is 1..4. The current code checks for a range of 1..5. Fix it. Declare the variable used to retrieve pulses per revolution from devicetree as u32 (unsigned) to match the of_property_read_u32() API. The current code uses a postfix decrement when writing the pulses per resolution into the chip. This has no effect since the value is evaluated before it is decremented. Fix it by decrementing before evaluating the value. Fixes: 7506ebcd662b ("hwmon: (max6639) : Configure based on DT property") Cc: Naresh Solanki Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 96955cf9f5ba67b095fa33cb2556051c847a806b Author: Suzuki K Poulose Date: Mon Mar 16 16:19:01 2026 +0000 arm64: realm: Fix PTE_NS_SHARED for 52bit PA support [ Upstream commit 8c6e9b60f5c7985a9fe41320556a92d7a33451df ] With LPA/LPA2, the top bits of the PFN (Bits[51:48]) end up in the lower bits of the PTE. So, simply creating a mask of the "top IPA bit" doesn't work well for these configurations to set the "top" bit at the output of Stage1 translation. Fix this by using the __phys_to_pte_val() to do the right thing for all configurations. Tested using, kvmtool, placing the memory at a higher address (-m @). e.g: # lkvm run --realm -c 4 -m 512M@@128T -k Image --console serial sh-5.0# dmesg | grep "LPA2\|RSI" [ 0.000000] RME: Using RSI version 1.0 [ 0.000000] CPU features: detected: 52-bit Virtual Addressing (LPA2) [ 0.777354] CPU features: detected: 52-bit Virtual Addressing for KVM (LPA2) Fixes: 399306954996 ("arm64: realm: Query IPA size from the RMM") Cc: Catalin Marinas Cc: Steven Price Cc: Will Deacon Signed-off-by: Suzuki K Poulose Reviewed-by: Steven Price Reviewed-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit ef6e6484747e34152b5515c2a087051975d8d116 Author: Josh Law Date: Thu Mar 19 08:43:06 2026 +0900 tools/bootconfig: fix fd leak in load_xbc_file() on fstat failure [ Upstream commit 3b2c2ab4ceb82af484310c3087541eab00ea288b ] If fstat() fails after open() succeeds, the function returns without closing the file descriptor. Also preserve errno across close(), since close() may overwrite it before the error is returned. Link: https://lore.kernel.org/all/20260318155847.78065-3-objecting@objecting.org/ Fixes: 950313ebf79c ("tools: bootconfig: Add bootconfig command") Signed-off-by: Josh Law Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin commit d03e8c281fd3eb4139a096d495e48e29030b33de Author: Josh Law Date: Thu Mar 19 08:43:05 2026 +0900 lib/bootconfig: check xbc_init_node() return in override path [ Upstream commit bb288d7d869e86d382f35a0e26242c5ccb05ca82 ] The ':=' override path in xbc_parse_kv() calls xbc_init_node() to re-initialize an existing value node but does not check the return value. If xbc_init_node() fails (data offset out of range), parsing silently continues with stale node data. Add the missing error check to match the xbc_add_node() call path which already checks for failure. In practice, a bootconfig using ':=' to override a value near the 32KB data limit could silently retain the old value, meaning a security-relevant boot parameter override (e.g., a trace filter or debug setting) would not take effect as intended. Link: https://lore.kernel.org/all/20260318155847.78065-2-objecting@objecting.org/ Fixes: e5efaeb8a8f5 ("bootconfig: Support mixing a value and subkeys under a key") Signed-off-by: Josh Law Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin commit 3ab1d7c8b6b7eafa42300028a90435f5b5ff4d37 Author: Kees Cook Date: Wed Mar 18 11:36:29 2026 -0700 fs/tests: exec: Remove bad test vector [ Upstream commit c4192754e836e0ffed95833509b6ada975b74418 ] Drop an unusable test in the bprm stack limits. Reported-by: Guenter Roeck Closes: https://lore.kernel.org/all/a3e9b1c2-40c1-45df-9fa2-14ee6a7b3fe2@roeck-us.net Fixes: 60371f43e56b ("exec: Add KUnit test for bprm_stack_limits()") Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit cf4b224ffb9a58181be32b64130fc36cf59c3192 Author: Rahul Bukte Date: Tue Feb 3 10:18:39 2026 +0530 drm/i915/gt: Check set_default_submission() before deferencing [ Upstream commit 0162ab3220bac870e43e229e6e3024d1a21c3f26 ] When the i915 driver firmware binaries are not present, the set_default_submission pointer is not set. This pointer is dereferenced during suspend anyways. Add a check to make sure it is set before dereferencing. [ 23.289926] PM: suspend entry (deep) [ 23.293558] Filesystems sync: 0.000 seconds [ 23.298010] Freezing user space processes [ 23.302771] Freezing user space processes completed (elapsed 0.000 seconds) [ 23.309766] OOM killer disabled. [ 23.313027] Freezing remaining freezable tasks [ 23.318540] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 23.342038] serial 00:05: disabled [ 23.345719] serial 00:02: disabled [ 23.349342] serial 00:01: disabled [ 23.353782] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 23.358993] sd 1:0:0:0: [sdb] Synchronizing SCSI cache [ 23.361635] ata1.00: Entering standby power mode [ 23.368863] ata2.00: Entering standby power mode [ 23.445187] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 23.452194] #PF: supervisor instruction fetch in kernel mode [ 23.457896] #PF: error_code(0x0010) - not-present page [ 23.463065] PGD 0 P4D 0 [ 23.465640] Oops: Oops: 0010 [#1] SMP NOPTI [ 23.469869] CPU: 8 UID: 0 PID: 211 Comm: kworker/u48:18 Tainted: G S W 6.19.0-rc4-00020-gf0b9d8eb98df #10 PREEMPT(voluntary) [ 23.482512] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN [ 23.496511] Workqueue: async async_run_entry_fn [ 23.501087] RIP: 0010:0x0 [ 23.503755] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 23.510324] RSP: 0018:ffffb4a60065fca8 EFLAGS: 00010246 [ 23.515592] RAX: 0000000000000000 RBX: ffff9f428290e000 RCX: 000000000000000f [ 23.522765] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff9f428290e000 [ 23.529937] RBP: ffff9f4282907070 R08: ffff9f4281130428 R09: 00000000ffffffff [ 23.537111] R10: 0000000000000000 R11: 0000000000000001 R12: ffff9f42829070f8 [ 23.544284] R13: ffff9f4282906028 R14: ffff9f4282900000 R15: ffff9f4282906b68 [ 23.551457] FS: 0000000000000000(0000) GS:ffff9f466b2cf000(0000) knlGS:0000000000000000 [ 23.559588] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 23.565365] CR2: ffffffffffffffd6 CR3: 000000031c230001 CR4: 0000000000f70ef0 [ 23.572539] PKRU: 55555554 [ 23.575281] Call Trace: [ 23.577770] [ 23.579905] intel_engines_reset_default_submission+0x42/0x60 [ 23.585695] __intel_gt_unset_wedged+0x191/0x200 [ 23.590360] intel_gt_unset_wedged+0x20/0x40 [ 23.594675] gt_sanitize+0x15e/0x170 [ 23.598290] i915_gem_suspend_late+0x6b/0x180 [ 23.602692] i915_drm_suspend_late+0x35/0xf0 [ 23.607008] ? __pfx_pci_pm_suspend_late+0x10/0x10 [ 23.611843] dpm_run_callback+0x78/0x1c0 [ 23.615817] device_suspend_late+0xde/0x2e0 [ 23.620037] async_suspend_late+0x18/0x30 [ 23.624082] async_run_entry_fn+0x25/0xa0 [ 23.628129] process_one_work+0x15b/0x380 [ 23.632182] worker_thread+0x2a5/0x3c0 [ 23.635973] ? __pfx_worker_thread+0x10/0x10 [ 23.640279] kthread+0xf6/0x1f0 [ 23.643464] ? __pfx_kthread+0x10/0x10 [ 23.647263] ? __pfx_kthread+0x10/0x10 [ 23.651045] ret_from_fork+0x131/0x190 [ 23.654837] ? __pfx_kthread+0x10/0x10 [ 23.658634] ret_from_fork_asm+0x1a/0x30 [ 23.662597] [ 23.664826] Modules linked in: [ 23.667914] CR2: 0000000000000000 [ 23.671271] ------------[ cut here ]------------ Signed-off-by: Rahul Bukte Reviewed-by: Suraj Kandpal Signed-off-by: Suraj Kandpal Link: https://patch.msgid.link/20260203044839.1555147-1-suraj.kandpal@intel.com (cherry picked from commit daa199abc3d3d1740c9e3a2c3e9216ae5b447cad) Fixes: ff44ad51ebf8 ("drm/i915: Move engine->submit_request selection to a vfunc") Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin commit a5828c14a9e3d5eeed0bcc0a58f0f3fbca0cdcb2 Author: Hyunwoo Kim Date: Thu Mar 12 17:15:51 2026 +0900 ksmbd: fix use-after-free in durable v2 replay of active file handles [ Upstream commit b425e4d0eb321a1116ddbf39636333181675d8f4 ] parse_durable_handle_context() unconditionally assigns dh_info->fp->conn to the current connection when handling a DURABLE_REQ_V2 context with SMB2_FLAGS_REPLAY_OPERATION. ksmbd_lookup_fd_cguid() does not filter by fp->conn, so it returns file handles that are already actively connected. The unconditional overwrite replaces fp->conn, and when the overwriting connection is subsequently freed, __ksmbd_close_fd() dereferences the stale fp->conn via spin_lock(&fp->conn->llist_lock), causing a use-after-free. KASAN report: [ 7.349357] ================================================================== [ 7.349607] BUG: KASAN: slab-use-after-free in _raw_spin_lock+0x75/0xe0 [ 7.349811] Write of size 4 at addr ffff8881056ac18c by task kworker/1:2/108 [ 7.350010] [ 7.350064] CPU: 1 UID: 0 PID: 108 Comm: kworker/1:2 Not tainted 7.0.0-rc3+ #58 PREEMPTLAZY [ 7.350068] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 7.350070] Workqueue: ksmbd-io handle_ksmbd_work [ 7.350083] Call Trace: [ 7.350087] [ 7.350087] dump_stack_lvl+0x64/0x80 [ 7.350094] print_report+0xce/0x660 [ 7.350100] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 7.350101] ? __pfx___mod_timer+0x10/0x10 [ 7.350106] ? _raw_spin_lock+0x75/0xe0 [ 7.350108] kasan_report+0xce/0x100 [ 7.350109] ? _raw_spin_lock+0x75/0xe0 [ 7.350114] kasan_check_range+0x105/0x1b0 [ 7.350116] _raw_spin_lock+0x75/0xe0 [ 7.350118] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350119] ? __call_rcu_common.constprop.0+0x25e/0x780 [ 7.350125] ? close_id_del_oplock+0x2cc/0x4e0 [ 7.350128] __ksmbd_close_fd+0x27f/0xaf0 [ 7.350131] ksmbd_close_fd+0x135/0x1b0 [ 7.350133] smb2_close+0xb19/0x15b0 [ 7.350142] ? __pfx_smb2_close+0x10/0x10 [ 7.350143] ? xas_load+0x18/0x270 [ 7.350146] ? _raw_spin_lock+0x84/0xe0 [ 7.350148] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350150] ? _raw_spin_unlock+0xe/0x30 [ 7.350151] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 7.350153] ? ksmbd_tree_conn_lookup+0xcd/0xf0 [ 7.350154] handle_ksmbd_work+0x40f/0x1080 [ 7.350156] process_one_work+0x5fa/0xef0 [ 7.350162] ? assign_work+0x122/0x3e0 [ 7.350163] worker_thread+0x54b/0xf70 [ 7.350165] ? __pfx_worker_thread+0x10/0x10 [ 7.350166] kthread+0x346/0x470 [ 7.350170] ? recalc_sigpending+0x19b/0x230 [ 7.350176] ? __pfx_kthread+0x10/0x10 [ 7.350178] ret_from_fork+0x4fb/0x6c0 [ 7.350183] ? __pfx_ret_from_fork+0x10/0x10 [ 7.350185] ? __switch_to+0x36c/0xbe0 [ 7.350188] ? __pfx_kthread+0x10/0x10 [ 7.350190] ret_from_fork_asm+0x1a/0x30 [ 7.350197] [ 7.350197] [ 7.355160] Allocated by task 123: [ 7.355261] kasan_save_stack+0x33/0x60 [ 7.355373] kasan_save_track+0x14/0x30 [ 7.355484] __kasan_kmalloc+0x8f/0xa0 [ 7.355593] ksmbd_conn_alloc+0x44/0x6d0 [ 7.355711] ksmbd_kthread_fn+0x243/0xd70 [ 7.355839] kthread+0x346/0x470 [ 7.355942] ret_from_fork+0x4fb/0x6c0 [ 7.356051] ret_from_fork_asm+0x1a/0x30 [ 7.356164] [ 7.356214] Freed by task 134: [ 7.356305] kasan_save_stack+0x33/0x60 [ 7.356416] kasan_save_track+0x14/0x30 [ 7.356527] kasan_save_free_info+0x3b/0x60 [ 7.356646] __kasan_slab_free+0x43/0x70 [ 7.356761] kfree+0x1ca/0x430 [ 7.356862] ksmbd_tcp_disconnect+0x59/0xe0 [ 7.356993] ksmbd_conn_handler_loop+0x77e/0xd40 [ 7.357138] kthread+0x346/0x470 [ 7.357240] ret_from_fork+0x4fb/0x6c0 [ 7.357350] ret_from_fork_asm+0x1a/0x30 [ 7.357463] [ 7.357513] The buggy address belongs to the object at ffff8881056ac000 [ 7.357513] which belongs to the cache kmalloc-1k of size 1024 [ 7.357857] The buggy address is located 396 bytes inside of [ 7.357857] freed 1024-byte region [ffff8881056ac000, ffff8881056ac400) Fix by removing the unconditional fp->conn assignment and rejecting the replay when fp->conn is non-NULL. This is consistent with ksmbd_lookup_durable_fd(), which also rejects file handles with a non-NULL fp->conn. For disconnected file handles (fp->conn == NULL), ksmbd_reopen_durable_fd() handles setting fp->conn. Fixes: c8efcc786146 ("ksmbd: add support for durable handles v1/v2") Signed-off-by: Hyunwoo Kim Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 7f7468fd2a7554cea91b7d430335a3dbf01dcc09 Author: Hyunwoo Kim Date: Thu Mar 12 17:17:02 2026 +0900 ksmbd: fix use-after-free of share_conf in compound request [ Upstream commit c33615f995aee80657b9fdfbc4ee7f49c2bd733d ] smb2_get_ksmbd_tcon() reuses work->tcon in compound requests without validating tcon->t_state. ksmbd_tree_conn_lookup() checks t_state == TREE_CONNECTED on the initial lookup path, but the compound reuse path bypasses this check entirely. If a prior command in the compound (SMB2_TREE_DISCONNECT) sets t_state to TREE_DISCONNECTED and frees share_conf via ksmbd_share_config_put(), subsequent commands dereference the freed share_conf through work->tcon->share_conf. KASAN report: [ 4.144653] ================================================================== [ 4.145059] BUG: KASAN: slab-use-after-free in smb2_write+0xc74/0xe70 [ 4.145415] Read of size 4 at addr ffff88810430c194 by task kworker/1:1/44 [ 4.145772] [ 4.145867] CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted 7.0.0-rc3+ #60 PREEMPTLAZY [ 4.145871] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 4.145875] Workqueue: ksmbd-io handle_ksmbd_work [ 4.145888] Call Trace: [ 4.145892] [ 4.145894] dump_stack_lvl+0x64/0x80 [ 4.145910] print_report+0xce/0x660 [ 4.145919] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 4.145928] ? smb2_write+0xc74/0xe70 [ 4.145931] kasan_report+0xce/0x100 [ 4.145934] ? smb2_write+0xc74/0xe70 [ 4.145937] smb2_write+0xc74/0xe70 [ 4.145939] ? __pfx_smb2_write+0x10/0x10 [ 4.145942] ? _raw_spin_unlock+0xe/0x30 [ 4.145945] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 4.145948] ? smb2_tree_disconnect+0x31c/0x480 [ 4.145951] handle_ksmbd_work+0x40f/0x1080 [ 4.145953] process_one_work+0x5fa/0xef0 [ 4.145962] ? assign_work+0x122/0x3e0 [ 4.145964] worker_thread+0x54b/0xf70 [ 4.145967] ? __pfx_worker_thread+0x10/0x10 [ 4.145970] kthread+0x346/0x470 [ 4.145976] ? recalc_sigpending+0x19b/0x230 [ 4.145980] ? __pfx_kthread+0x10/0x10 [ 4.145984] ret_from_fork+0x4fb/0x6c0 [ 4.145992] ? __pfx_ret_from_fork+0x10/0x10 [ 4.145995] ? __switch_to+0x36c/0xbe0 [ 4.145999] ? __pfx_kthread+0x10/0x10 [ 4.146003] ret_from_fork_asm+0x1a/0x30 [ 4.146013] [ 4.146014] [ 4.149858] Allocated by task 44: [ 4.149953] kasan_save_stack+0x33/0x60 [ 4.150061] kasan_save_track+0x14/0x30 [ 4.150169] __kasan_kmalloc+0x8f/0xa0 [ 4.150274] ksmbd_share_config_get+0x1dd/0xdd0 [ 4.150401] ksmbd_tree_conn_connect+0x7e/0x600 [ 4.150529] smb2_tree_connect+0x2e6/0x1000 [ 4.150645] handle_ksmbd_work+0x40f/0x1080 [ 4.150761] process_one_work+0x5fa/0xef0 [ 4.150873] worker_thread+0x54b/0xf70 [ 4.150978] kthread+0x346/0x470 [ 4.151071] ret_from_fork+0x4fb/0x6c0 [ 4.151176] ret_from_fork_asm+0x1a/0x30 [ 4.151286] [ 4.151332] Freed by task 44: [ 4.151418] kasan_save_stack+0x33/0x60 [ 4.151526] kasan_save_track+0x14/0x30 [ 4.151634] kasan_save_free_info+0x3b/0x60 [ 4.151751] __kasan_slab_free+0x43/0x70 [ 4.151861] kfree+0x1ca/0x430 [ 4.151952] __ksmbd_tree_conn_disconnect+0xc8/0x190 [ 4.152088] smb2_tree_disconnect+0x1cd/0x480 [ 4.152211] handle_ksmbd_work+0x40f/0x1080 [ 4.152326] process_one_work+0x5fa/0xef0 [ 4.152438] worker_thread+0x54b/0xf70 [ 4.152545] kthread+0x346/0x470 [ 4.152638] ret_from_fork+0x4fb/0x6c0 [ 4.152743] ret_from_fork_asm+0x1a/0x30 [ 4.152853] [ 4.152900] The buggy address belongs to the object at ffff88810430c180 [ 4.152900] which belongs to the cache kmalloc-96 of size 96 [ 4.153226] The buggy address is located 20 bytes inside of [ 4.153226] freed 96-byte region [ffff88810430c180, ffff88810430c1e0) [ 4.153549] [ 4.153596] The buggy address belongs to the physical page: [ 4.153750] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88810430ce80 pfn:0x10430c [ 4.154000] flags: 0x100000000000200(workingset|node=0|zone=2) [ 4.154160] page_type: f5(slab) [ 4.154251] raw: 0100000000000200 ffff888100041280 ffff888100040110 ffff888100040110 [ 4.154461] raw: ffff88810430ce80 0000000800200009 00000000f5000000 0000000000000000 [ 4.154668] page dumped because: kasan: bad access detected [ 4.154820] [ 4.154866] Memory state around the buggy address: [ 4.155002] ffff88810430c080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 4.155196] ffff88810430c100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 4.155391] >ffff88810430c180: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc [ 4.155587] ^ [ 4.155693] ffff88810430c200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 4.155891] ffff88810430c280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 4.156087] ================================================================== Add the same t_state validation to the compound reuse path, consistent with ksmbd_tree_conn_lookup(). Fixes: 5005bcb42191 ("ksmbd: validate session id and tree id in the compound request") Signed-off-by: Hyunwoo Kim Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 2cb24caacee21666034732b92229072b76556e7a Author: Jonas Karlman Date: Sat Feb 28 11:28:22 2026 +0000 drm/bridge: dw-hdmi-qp: fix multi-channel audio output [ Upstream commit cffcb42c57686e9a801dfcf37a3d0c62e51c1c3e ] Channel Allocation (PB4) and Level Shift Information (PB5) are configured with values from PB1 and PB2 due to the wrong offset being used. This results in missing audio channels or incorrect speaker placement when playing multi-channel audio. Use the correct offset to fix multi-channel audio output. Fixes: fd0141d1a8a2 ("drm/bridge: synopsys: Add audio support for dw-hdmi-qp") Reported-by: Christian Hewitt Signed-off-by: Jonas Karlman Signed-off-by: Christian Hewitt Reviewed-by: Cristian Ciocaltea Link: https://patch.msgid.link/20260228112822.4056354-1-christianshewitt@gmail.com Signed-off-by: Luca Ceresoli Signed-off-by: Sasha Levin commit c51a5319bf6551a926f02ec3bdc07ff12d06e2f5 Author: Andy Nguyen Date: Sun Mar 15 17:51:47 2026 +0100 drm/amd: fix dcn 2.01 check [ Upstream commit 39f44f54afa58661ecae9c27e15f5dbce2372892 ] The ASICREV_IS_BEIGE_GOBY_P check always took precedence, because it includes all chip revisions upto NV_UNKNOWN. Fixes: 54b822b3eac3 ("drm/amd/display: Use dce_version instead of chip_id") Signed-off-by: Andy Nguyen Signed-off-by: Alex Deucher (cherry picked from commit 9c7be0efa6f0daa949a5f3e3fdf9ea090b0713cb) Signed-off-by: Sasha Levin commit 430334e9e4e815b0541f8337c2dbd49d7d3b55fa Author: Srinivasan Shanmugam Date: Sun Mar 15 18:30:26 2026 +0530 drm/amd/display: Fix DisplayID not-found handling in parse_edid_displayid_vrr() [ Upstream commit 2323b019651ad81c20a0f7f817c63392b3110652 ] parse_edid_displayid_vrr() searches the EDID extension blocks for a DisplayID extension before parsing the dynamic video timing range. The code previously checked whether edid_ext was NULL after the search loop. However, edid_ext is assigned during each iteration of the loop, so it will never be NULL once the loop has executed. If no DisplayID extension is found, edid_ext ends up pointing to the last extension block, and the NULL check does not correctly detect the failure case. Instead, check whether the loop completed without finding a matching DisplayID block by testing "i == edid->extensions". This ensures the function exits early when no DisplayID extension is present and avoids parsing an unrelated EDID extension block. Also simplify the EDID validation check using "!edid || !edid->extensions". Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:13079 parse_edid_displayid_vrr() warn: variable dereferenced before check 'edid_ext' (see line 13075) Fixes: a638b837d0e6 ("drm/amd/display: Fix refresh rate range for some panel") Cc: Roman Li Cc: Alex Hung Cc: Jerry Zuo Cc: Sun peng Li Cc: Tom Chung Cc: Dan Carpenter Cc: Aurabindo Pillai Signed-off-by: Srinivasan Shanmugam Reviewed-by: Tom Chung Signed-off-by: Alex Deucher (cherry picked from commit 91c7e6342e98c846b259c57273436fdea4c043f2) Signed-off-by: Sasha Levin commit 58abeb7b9562f25bdfa2f5ae5ce803eb02e74433 Author: Lizhi Hou Date: Wed Mar 4 22:18:42 2026 -0800 iommu/sva: Fix crash in iommu_sva_unbind_device() [ Upstream commit 06e14c36e20b48171df13d51b89fe67c594ed07a ] domain->mm->iommu_mm can be freed by iommu_domain_free(): iommu_domain_free() mmdrop() __mmdrop() mm_pasid_drop() After iommu_domain_free() returns, accessing domain->mm->iommu_mm may dereference a freed mm structure, leading to a crash. Fix this by moving the code that accesses domain->mm->iommu_mm to before the call to iommu_domain_free(). Fixes: e37d5a2d60a3 ("iommu/sva: invalidate stale IOTLB entries for kernel address space") Signed-off-by: Lizhi Hou Reviewed-by: Jason Gunthorpe Reviewed-by: Yi Liu Reviewed-by: Vasant Hegde Reviewed-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 3f300a41a3668095688aa4551214e8080829fa93 Author: Ian Forbes Date: Mon Mar 2 14:03:30 2026 -0600 drm/vmwgfx: Don't overwrite KMS surface dirty tracker [ Upstream commit c6cb77c474a32265e21c4871c7992468bf5e7638 ] We were overwriting the surface's dirty tracker here causing a memory leak. Reported-by: Mika Penttilä Closes: https://lore.kernel.org/dri-devel/8c53f3c6-c6de-46fe-a8ca-d98dd52b3abe@redhat.com/ Fixes: 965544150d1c ("drm/vmwgfx: Refactor cursor handling") Signed-off-by: Ian Forbes Reviewed-by: Maaz Mombasawala Signed-off-by: Zack Rusin Link: https://patch.msgid.link/20260302200330.66763-1-ian.forbes@broadcom.com Signed-off-by: Sasha Levin commit bec21d97c968a4806939eb2946df49ea6c341bde Author: Felix Gu Date: Sun Mar 8 14:49:21 2026 +0800 spi: amlogic-spisg: Fix memory leak in aml_spisg_probe() [ Upstream commit b8db9552997924b750e727a625a30eaa4603bbb9 ] In aml_spisg_probe(), ctlr is allocated by spi_alloc_target()/spi_alloc_host(), but fails to call spi_controller_put() in several error paths. This leads to a memory leak whenever the driver fails to probe after the initial allocation. Convert to use devm_spi_alloc_host()/devm_spi_alloc_target() to fix the memory leak. Fixes: cef9991e04ae ("spi: Add Amlogic SPISG driver") Signed-off-by: Felix Gu Link: https://patch.msgid.link/20260308-spisg-v1-1-2cace5cafc24@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f15e0706e366b96bdaee150c1a3a1cde922da091 Author: Felix Gu Date: Sun Mar 8 21:34:55 2026 +0800 spi: amlogic: spifc-a4: Remove redundant clock cleanup [ Upstream commit a00da54d06f435dbbeacb84f9121dbbe6d6eda74 ] The driver uses devm_clk_get_enabled() which enables the clock and registers a callback to automatically disable it when the device is unbound. Remove the redundant aml_sfc_disable_clk() call in the error paths and remove callback. Fixes: 4670db6f32e9 ("spi: amlogic: add driver for Amlogic SPI Flash Controller") Signed-off-by: Felix Gu Link: https://patch.msgid.link/20260308-spifc-a4-1-v1-1-77e286c26832@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a9e119d027fd5cace44196dd0f77248aa07721c9 Author: Kamal Dasu Date: Thu Mar 5 15:21:57 2026 -0500 mtd: rawnand: brcmnand: skip DMA during panic write [ Upstream commit da9ba4dcc01e7cf52b7676f0ee9607b8358c2171 ] When oops_panic_write is set, the driver disables interrupts and switches to PIO polling mode but still falls through into the DMA path. DMA cannot be used reliably in panic context, so make the DMA path an else branch to ensure only PIO is used during panic writes. Fixes: c1ac2dc34b51 ("mtd: rawnand: brcmnand: When oops in progress use pio and interrupt polling") Signed-off-by: Kamal Dasu Reviewed-by: William Zhang Reviewed-by: Florian Fainelli Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 5fd5c078af23cb353507aa522e09d557d7eaef04 Author: Kamal Dasu Date: Thu Mar 5 14:49:06 2026 -0500 mtd: rawnand: serialize lock/unlock against other NAND operations [ Upstream commit bab2bc6e850a697a23b9e5f0e21bb8c187615e95 ] nand_lock() and nand_unlock() call into chip->ops.lock_area/unlock_area without holding the NAND device lock. On controllers that implement SET_FEATURES via multiple low-level PIO commands, these can race with concurrent UBI/UBIFS background erase/write operations that hold the device lock, resulting in cmd_pending conflicts on the NAND controller. Add nand_get_device()/nand_release_device() around the lock/unlock operations to serialize them against all other NAND controller access. Fixes: 92270086b7e5 ("mtd: rawnand: Add support for manufacturer specific lock/unlock operation") Signed-off-by: Kamal Dasu Reviewed-by: William Zhang Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit f8b5b833728bf9357935cd3c1a37e95150c7a604 Author: Andrei Vagin Date: Tue Feb 17 18:01:05 2026 +0000 binfmt_elf_fdpic: fix AUXV size calculation for ELF_HWCAP3 and ELF_HWCAP4 [ Upstream commit 4ced4cf5c9d172d91f181df3accdf949d3761aab ] Commit 4e6e8c2b757f ("binfmt_elf: Wire up AT_HWCAP3 at AT_HWCAP4") added support for AT_HWCAP3 and AT_HWCAP4, but it missed updating the AUX vector size calculation in create_elf_fdpic_tables() and AT_VECTOR_SIZE_BASE in include/linux/auxvec.h. Similar to the fix for AT_HWCAP2 in commit c6a09e342f8e ("binfmt_elf_fdpic: fix AUXV size calculation when ELF_HWCAP2 is defined"), this omission leads to a mismatch between the reserved space and the actual number of AUX entries, eventually triggering a kernel BUG_ON(csp != sp). Fix this by incrementing nitems when ELF_HWCAP3 or ELF_HWCAP4 are defined and updating AT_VECTOR_SIZE_BASE. Cc: Mark Brown Cc: Max Filippov Reviewed-by: Michal Koutný Reviewed-by: Mark Brown Reviewed-by: Cyrill Gorcunov Reviewed-by: Alexander Mikhalitsyn Fixes: 4e6e8c2b757f ("binfmt_elf: Wire up AT_HWCAP3 at AT_HWCAP4") Signed-off-by: Andrei Vagin Link: https://patch.msgid.link/20260217180108.1420024-2-avagin@google.com Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 75668e58244e63ec3785098a02e1cdcff14a6c2e Author: Steven Rostedt Date: Mon Mar 23 08:52:55 2026 -0400 tracing: Fix trace_marker copy link list updates [ Upstream commit 07183aac4a6828e474f00b37c9d795d0d99e18a7 ] When the "copy_trace_marker" option is enabled for an instance, anything written into /sys/kernel/tracing/trace_marker is also copied into that instances buffer. When the option is set, that instance's trace_array descriptor is added to the marker_copies link list. This list is protected by RCU, as all iterations uses an RCU protected list traversal. When the instance is deleted, all the flags that were enabled are cleared. This also clears the copy_trace_marker flag and removes the trace_array descriptor from the list. The issue is after the flags are called, a direct call to update_marker_trace() is performed to clear the flag. This function returns true if the state of the flag changed and false otherwise. If it returns true here, synchronize_rcu() is called to make sure all readers see that its removed from the list. But since the flag was already cleared, the state does not change and the synchronization is never called, leaving a possible UAF bug. Move the clearing of all flags below the updating of the copy_trace_marker option which then makes sure the synchronization is performed. Also use the flag for checking the state in update_marker_trace() instead of looking at if the list is empty. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Link: https://patch.msgid.link/20260318185512.1b6c7db4@gandalf.local.home Fixes: 7b382efd5e8a ("tracing: Allow the top level trace_marker to write into another instances") Reported-by: Sasha Levin Closes: https://lore.kernel.org/all/20260225133122.237275-1-sashal@kernel.org/ Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 79f0faf81d3bbbe5f07bf6892450d3740a1b290d Author: Kyle Meyer Date: Fri Mar 20 12:19:20 2026 -0500 x86/platform/uv: Handle deconfigured sockets commit 1f6aa5bbf1d0f81a8a2aafc16136e7dd9a609ff3 upstream. When a socket is deconfigured, it's mapped to SOCK_EMPTY (0xffff). This causes a panic while allocating UV hub info structures. Fix this by using NUMA_NO_NODE, allowing UV hub info structures to be allocated on valid nodes. Fixes: 8a50c5851927 ("x86/platform/uv: UV support for sub-NUMA clustering") Signed-off-by: Kyle Meyer Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Steve Wahl Cc: stable@vger.kernel.org Link: https://patch.msgid.link/ab2BmGL0ehVkkjKk@hpe.com Signed-off-by: Greg Kroah-Hartman commit 38539f55f61ad92f95fb373e8619846ad8a7c0e5 Author: Steven Rostedt Date: Mon Mar 16 13:07:34 2026 -0400 tracing: Fix failure to read user space from system call trace events commit edca33a56297d5741ccf867669debec116681987 upstream. The system call trace events call trace_user_fault_read() to read the user space part of some system calls. This is done by grabbing a per-cpu buffer, disabling migration, enabling preemption, calling copy_from_user(), disabling preemption, enabling migration and checking if the task was preempted while preemption was enabled. If it was, the buffer is considered corrupted and it tries again. There's a safety mechanism that will fail out of this loop if it fails 100 times (with a warning). That warning message was triggered in some pi_futex stress tests. Enabling the sched_switch trace event and traceoff_on_warning, showed the problem: pi_mutex_hammer-1375 [006] d..21 138.981648: sched_switch: prev_comm=pi_mutex_hammer prev_pid=1375 prev_prio=95 prev_state=R+ ==> next_comm=migration/6 next_pid=47 next_prio=0 migration/6-47 [006] d..2. 138.981651: sched_switch: prev_comm=migration/6 prev_pid=47 prev_prio=0 prev_state=S ==> next_comm=pi_mutex_hammer next_pid=1375 next_prio=95 pi_mutex_hammer-1375 [006] d..21 138.981656: sched_switch: prev_comm=pi_mutex_hammer prev_pid=1375 prev_prio=95 prev_state=R+ ==> next_comm=migration/6 next_pid=47 next_prio=0 migration/6-47 [006] d..2. 138.981659: sched_switch: prev_comm=migration/6 prev_pid=47 prev_prio=0 prev_state=S ==> next_comm=pi_mutex_hammer next_pid=1375 next_prio=95 pi_mutex_hammer-1375 [006] d..21 138.981664: sched_switch: prev_comm=pi_mutex_hammer prev_pid=1375 prev_prio=95 prev_state=R+ ==> next_comm=migration/6 next_pid=47 next_prio=0 migration/6-47 [006] d..2. 138.981667: sched_switch: prev_comm=migration/6 prev_pid=47 prev_prio=0 prev_state=S ==> next_comm=pi_mutex_hammer next_pid=1375 next_prio=95 pi_mutex_hammer-1375 [006] d..21 138.981671: sched_switch: prev_comm=pi_mutex_hammer prev_pid=1375 prev_prio=95 prev_state=R+ ==> next_comm=migration/6 next_pid=47 next_prio=0 migration/6-47 [006] d..2. 138.981675: sched_switch: prev_comm=migration/6 prev_pid=47 prev_prio=0 prev_state=S ==> next_comm=pi_mutex_hammer next_pid=1375 next_prio=95 pi_mutex_hammer-1375 [006] d..21 138.981679: sched_switch: prev_comm=pi_mutex_hammer prev_pid=1375 prev_prio=95 prev_state=R+ ==> next_comm=migration/6 next_pid=47 next_prio=0 migration/6-47 [006] d..2. 138.981682: sched_switch: prev_comm=migration/6 prev_pid=47 prev_prio=0 prev_state=S ==> next_comm=pi_mutex_hammer next_pid=1375 next_prio=95 pi_mutex_hammer-1375 [006] d..21 138.981687: sched_switch: prev_comm=pi_mutex_hammer prev_pid=1375 prev_prio=95 prev_state=R+ ==> next_comm=migration/6 next_pid=47 next_prio=0 migration/6-47 [006] d..2. 138.981690: sched_switch: prev_comm=migration/6 prev_pid=47 prev_prio=0 prev_state=S ==> next_comm=pi_mutex_hammer next_pid=1375 next_prio=95 pi_mutex_hammer-1375 [006] d..21 138.981695: sched_switch: prev_comm=pi_mutex_hammer prev_pid=1375 prev_prio=95 prev_state=R+ ==> next_comm=migration/6 next_pid=47 next_prio=0 migration/6-47 [006] d..2. 138.981698: sched_switch: prev_comm=migration/6 prev_pid=47 prev_prio=0 prev_state=S ==> next_comm=pi_mutex_hammer next_pid=1375 next_prio=95 pi_mutex_hammer-1375 [006] d..21 138.981703: sched_switch: prev_comm=pi_mutex_hammer prev_pid=1375 prev_prio=95 prev_state=R+ ==> next_comm=migration/6 next_pid=47 next_prio=0 migration/6-47 [006] d..2. 138.981706: sched_switch: prev_comm=migration/6 prev_pid=47 prev_prio=0 prev_state=S ==> next_comm=pi_mutex_hammer next_pid=1375 next_prio=95 pi_mutex_hammer-1375 [006] d..21 138.981711: sched_switch: prev_comm=pi_mutex_hammer prev_pid=1375 prev_prio=95 prev_state=R+ ==> next_comm=migration/6 next_pid=47 next_prio=0 migration/6-47 [006] d..2. 138.981714: sched_switch: prev_comm=migration/6 prev_pid=47 prev_prio=0 prev_state=S ==> next_comm=pi_mutex_hammer next_pid=1375 next_prio=95 pi_mutex_hammer-1375 [006] d..21 138.981719: sched_switch: prev_comm=pi_mutex_hammer prev_pid=1375 prev_prio=95 prev_state=R+ ==> next_comm=migration/6 next_pid=47 next_prio=0 migration/6-47 [006] d..2. 138.981722: sched_switch: prev_comm=migration/6 prev_pid=47 prev_prio=0 prev_state=S ==> next_comm=pi_mutex_hammer next_pid=1375 next_prio=95 pi_mutex_hammer-1375 [006] d..21 138.981727: sched_switch: prev_comm=pi_mutex_hammer prev_pid=1375 prev_prio=95 prev_state=R+ ==> next_comm=migration/6 next_pid=47 next_prio=0 migration/6-47 [006] d..2. 138.981730: sched_switch: prev_comm=migration/6 prev_pid=47 prev_prio=0 prev_state=S ==> next_comm=pi_mutex_hammer next_pid=1375 next_prio=95 pi_mutex_hammer-1375 [006] d..21 138.981735: sched_switch: prev_comm=pi_mutex_hammer prev_pid=1375 prev_prio=95 prev_state=R+ ==> next_comm=migration/6 next_pid=47 next_prio=0 migration/6-47 [006] d..2. 138.981738: sched_switch: prev_comm=migration/6 prev_pid=47 prev_prio=0 prev_state=S ==> next_comm=pi_mutex_hammer next_pid=1375 next_prio=95 What happened was the task 1375 was flagged to be migrated. When preemption was enabled, the migration thread woke up to migrate that task, but failed because migration for that task was disabled. This caused the loop to fail to exit because the task scheduled out while trying to read user space. Every time the task enabled preemption the migration thread would schedule in, try to migrate the task, fail and let the task continue. But because the loop would only enable preemption with migration disabled, it would always fail because each time it enabled preemption to read user space, the migration thread would try to migrate it. To solve this, when the loop fails to read user space without being scheduled out, enabled and disable preemption with migration enabled. This will allow the migration task to successfully migrate the task and the next loop should succeed to read user space without being scheduled out. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Link: https://patch.msgid.link/20260316130734.1858a998@gandalf.local.home Fixes: 64cf7d058a005 ("tracing: Have trace_marker use per-cpu data to read user space") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit b6925774dd15d40858265b9dc970540c359dbfe5 Author: Masami Hiramatsu (Google) Date: Thu Mar 19 18:12:19 2026 +0900 ring-buffer: Fix to update per-subbuf entries of persistent ring buffer commit f35dbac6942171dc4ce9398d1d216a59224590a9 upstream. Since the validation loop in rb_meta_validate_events() updates the same cpu_buffer->head_page->entries, the other subbuf entries are not updated. Fix to use head_page to update the entries field, since it is the cursor in this loop. Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Cc: Ian Rogers Fixes: 5f3b6e839f3c ("ring-buffer: Validate boot range memory events") Link: https://patch.msgid.link/177391153882.193994.17158784065013676533.stgit@mhiramat.tok.corp.google.com Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 886fa869153917d902784098922defa20c3a2fe5 Author: Breno Leitao Date: Tue Mar 10 03:13:16 2026 -0700 perf/x86: Move event pointer setup earlier in x86_pmu_enable() commit 8d5fae6011260de209aaf231120e8146b14bc8e0 upstream. A production AMD EPYC system crashed with a NULL pointer dereference in the PMU NMI handler: BUG: kernel NULL pointer dereference, address: 0000000000000198 RIP: x86_perf_event_update+0xc/0xa0 Call Trace: amd_pmu_v2_handle_irq+0x1a6/0x390 perf_event_nmi_handler+0x24/0x40 The faulting instruction is `cmpq $0x0, 0x198(%rdi)` with RDI=0, corresponding to the `if (unlikely(!hwc->event_base))` check in x86_perf_event_update() where hwc = &event->hw and event is NULL. drgn inspection of the vmcore on CPU 106 showed a mismatch between cpuc->active_mask and cpuc->events[]: active_mask: 0x1e (bits 1, 2, 3, 4) events[1]: 0xff1100136cbd4f38 (valid) events[2]: 0x0 (NULL, but active_mask bit 2 set) events[3]: 0xff1100076fd2cf38 (valid) events[4]: 0xff1100079e990a90 (valid) The event that should occupy events[2] was found in event_list[2] with hw.idx=2 and hw.state=0x0, confirming x86_pmu_start() had run (which clears hw.state and sets active_mask) but events[2] was never populated. Another event (event_list[0]) had hw.state=0x7 (STOPPED|UPTODATE|ARCH), showing it was stopped when the PMU rescheduled events, confirming the throttle-then-reschedule sequence occurred. The root cause is commit 7e772a93eb61 ("perf/x86: Fix NULL event access and potential PEBS record loss") which moved the cpuc->events[idx] assignment out of x86_pmu_start() and into step 2 of x86_pmu_enable(), after the PERF_HES_ARCH check. This broke any path that calls pmu->start() without going through x86_pmu_enable() -- specifically the unthrottle path: perf_adjust_freq_unthr_events() -> perf_event_unthrottle_group() -> perf_event_unthrottle() -> event->pmu->start(event, 0) -> x86_pmu_start() // sets active_mask but not events[] The race sequence is: 1. A group of perf events overflows, triggering group throttle via perf_event_throttle_group(). All events are stopped: active_mask bits cleared, events[] preserved (x86_pmu_stop no longer clears events[] after commit 7e772a93eb61). 2. While still throttled (PERF_HES_STOPPED), x86_pmu_enable() runs due to other scheduling activity. Stopped events that need to move counters get PERF_HES_ARCH set and events[old_idx] cleared. In step 2 of x86_pmu_enable(), PERF_HES_ARCH causes these events to be skipped -- events[new_idx] is never set. 3. The timer tick unthrottles the group via pmu->start(). Since commit 7e772a93eb61 removed the events[] assignment from x86_pmu_start(), active_mask[new_idx] is set but events[new_idx] remains NULL. 4. A PMC overflow NMI fires. The handler iterates active counters, finds active_mask[2] set, reads events[2] which is NULL, and crashes dereferencing it. Move the cpuc->events[hwc->idx] assignment in x86_pmu_enable() to before the PERF_HES_ARCH check, so that events[] is populated even for events that are not immediately started. This ensures the unthrottle path via pmu->start() always finds a valid event pointer. Fixes: 7e772a93eb61 ("perf/x86: Fix NULL event access and potential PEBS record loss") Signed-off-by: Breno Leitao Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260310-perf-v2-1-4a3156fce43c@debian.org Signed-off-by: Greg Kroah-Hartman commit ed1f5c1d43c30c44efc0f7943005be3cef3ef3a0 Author: Dapeng Mi Date: Sat Feb 28 13:33:20 2026 +0800 perf/x86/intel: Add missing branch counters constraint apply commit 1d07bbd7ea36ea0b8dfa8068dbe67eb3a32d9590 upstream. When running the command: 'perf record -e "{instructions,instructions:p}" -j any,counter sleep 1', a "shift-out-of-bounds" warning is reported on CWF. UBSAN: shift-out-of-bounds in /kbuild/src/consumer/arch/x86/events/intel/lbr.c:970:15 shift exponent 64 is too large for 64-bit type 'long long unsigned int' ...... intel_pmu_lbr_counters_reorder.isra.0.cold+0x2a/0xa7 intel_pmu_lbr_save_brstack+0xc0/0x4c0 setup_arch_pebs_sample_data+0x114b/0x2400 The warning occurs because the second "instructions:p" event, which involves branch counters sampling, is incorrectly programmed to fixed counter 0 instead of the general-purpose (GP) counters 0-3 that support branch counters sampling. Currently only GP counters 0-3 support branch counters sampling on CWF, any event involving branch counters sampling should be programed on GP counters 0-3. Since the counter index of fixed counter 0 is 32, it leads to the "src" value in below code is right shifted 64 bits and trigger the "shift-out-of-bounds" warning. cnt = (src >> (order[j] * LBR_INFO_BR_CNTR_BITS)) & LBR_INFO_BR_CNTR_MASK; The root cause is the loss of the branch counters constraint for the new event in the branch counters sampling event group. Since it isn't yet part of the sibling list. This results in the second "instructions:p" event being programmed on fixed counter 0 incorrectly instead of the appropriate GP counters 0-3. To address this, we apply the missing branch counters constraint for the last event in the group. Additionally, we introduce a new function, `intel_set_branch_counter_constr()`, to apply the branch counters constraint and avoid code duplication. Fixes: 33744916196b ("perf/x86/intel: Support branch counters logging") Reported-by: Xudong Hao Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260228053320.140406-2-dapeng1.mi@linux.intel.com Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 560ec8f998522280ef29836f0b2fc930c3768457 Author: Felix Gu Date: Sun Mar 15 15:17:54 2026 +0800 irqchip/riscv-rpmi-sysmsi: Fix mailbox channel leak in rpmi_sysmsi_probe() commit 76f0930d6e809234904cf9f0f5f42ee6c1dc694e upstream. When riscv_acpi_get_gsi_info() fails, the mailbox channel previously requested via mbox_request_channel() is not freed. Add the missing mbox_free_channel() call to prevent the resource leak. Fixes: 4752b0cfbc37 ("irqchip/riscv-rpmi-sysmsi: Add ACPI support") Signed-off-by: Felix Gu Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Reviewed-by: Rahul Pathak Link: https://patch.msgid.link/20260315-sysmsi-v1-1-5f090c86c2ca@gmail.com Signed-off-by: Greg Kroah-Hartman commit aa9faa6486cfc169e3393356f3f46681faa024f7 Author: Gabor Juhos Date: Thu Feb 26 14:11:27 2026 +0100 i2c: pxa: defer reset on Armada 3700 when recovery is used commit 78a6ee14f8b9e1c8f7c77612122444f3be8dc8cc upstream. The I2C communication is completely broken on the Armada 3700 platform since commit 0b01392c18b9 ("i2c: pxa: move to generic GPIO recovery"). For example, on the Methode uDPU board, probing of the two onboard temperature sensors fails ... [ 7.271713] i2c i2c-0: using pinctrl states for GPIO recovery [ 7.277503] i2c i2c-0: PXA I2C adapter [ 7.282199] i2c i2c-1: using pinctrl states for GPIO recovery [ 7.288241] i2c i2c-1: PXA I2C adapter [ 7.292947] sfp sfp-eth1: Host maximum power 3.0W [ 7.299614] sfp sfp-eth0: Host maximum power 3.0W [ 7.308178] lm75 1-0048: supply vs not found, using dummy regulator [ 32.489631] lm75 1-0048: probe with driver lm75 failed with error -121 [ 32.496833] lm75 1-0049: supply vs not found, using dummy regulator [ 82.890614] lm75 1-0049: probe with driver lm75 failed with error -121 ... and accessing the plugged-in SFP modules also does not work: [ 511.298537] sfp sfp-eth1: please wait, module slow to respond [ 536.488530] sfp sfp-eth0: please wait, module slow to respond ... [ 1065.688536] sfp sfp-eth1: failed to read EEPROM: -EREMOTEIO [ 1090.888532] sfp sfp-eth0: failed to read EEPROM: -EREMOTEIO After a discussion [1], there was an attempt to fix the problem by reverting the offending change by commit 7b211c767121 ("Revert "i2c: pxa: move to generic GPIO recovery""), but that only helped to fix the issue in the 6.1.y stable tree. The reason behind the partial succes is that there was another change in commit 20cb3fce4d60 ("i2c: Set i2c pinctrl recovery info from it's device pinctrl") in the 6.3-rc1 cycle which broke things further. The cause of the problem is the same in case of both offending commits mentioned above. Namely, the I2C core code changes the pinctrl state to GPIO while running the recovery initialization code. Although the PXA specific initialization also does this, but the key difference is that it happens before the controller is getting enabled in i2c_pxa_reset(), whereas in the case of the generic initialization it happens after that. Change the code to reset the controller only before the first transfer instead of before registering the controller. This ensures that the controller is not enabled at the time when the generic recovery code performs the pinctrl state changes, thus avoids the problem described above. As the result this change restores the original behaviour, which in turn makes the I2C communication to work again as it can be seen from the following log: [ 7.363250] i2c i2c-0: using pinctrl states for GPIO recovery [ 7.369041] i2c i2c-0: PXA I2C adapter [ 7.373673] i2c i2c-1: using pinctrl states for GPIO recovery [ 7.379742] i2c i2c-1: PXA I2C adapter [ 7.384506] sfp sfp-eth1: Host maximum power 3.0W [ 7.393013] sfp sfp-eth0: Host maximum power 3.0W [ 7.399266] lm75 1-0048: supply vs not found, using dummy regulator [ 7.407257] hwmon hwmon0: temp1_input not attached to any thermal zone [ 7.413863] lm75 1-0048: hwmon0: sensor 'tmp75c' [ 7.418746] lm75 1-0049: supply vs not found, using dummy regulator [ 7.426371] hwmon hwmon1: temp1_input not attached to any thermal zone [ 7.432972] lm75 1-0049: hwmon1: sensor 'tmp75c' [ 7.755092] sfp sfp-eth1: module MENTECHOPTO POS22-LDCC-KR rev 1.0 sn MNC208U90009 dc 200828 [ 7.764997] mvneta d0040000.ethernet eth1: unsupported SFP module: no common interface modes [ 7.785362] sfp sfp-eth0: module Mikrotik S-RJ01 rev 1.0 sn 61B103C55C58 dc 201022 [ 7.803426] hwmon hwmon2: temp1_input not attached to any thermal zone Link: https://lore.kernel.org/r/20230926160255.330417-1-robert.marko@sartura.hr #1 Cc: stable@vger.kernel.org # 6.3+ Fixes: 20cb3fce4d60 ("i2c: Set i2c pinctrl recovery info from it's device pinctrl") Signed-off-by: Gabor Juhos Tested-by: Robert Marko Reviewed-by: Linus Walleij Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260226-i2c-pxa-fix-i2c-communication-v4-1-797a091dae87@gmail.com Signed-off-by: Greg Kroah-Hartman commit bf8a9c92cdd1fade846858bdaaabd64b4e94260a Author: Christophe JAILLET Date: Sun Mar 1 17:21:01 2026 +0100 i2c: fsi: Fix a potential leak in fsi_i2c_probe() commit be627abcc0d5dbd5882873bd85fbc18aa3d189ed upstream. In the commit in Fixes:, when the code has been updated to use an explicit for loop, instead of for_each_available_child_of_node(), the assumption that a reference to a device_node structure would be released at each iteration has been broken. Now, an explicit of_node_put() is needed to release the reference. Fixes: 095561f476ab ("i2c: fsi: Create busses for all ports") Signed-off-by: Christophe JAILLET Cc: # v5.3+ Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/fd805c39f8de51edf303856103d782138a1633c8.1772382022.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman commit a9778298f47036866ea15eeb17242e8a4612580f Author: Johan Hovold Date: Mon Mar 9 08:50:16 2026 +0100 i2c: cp2615: fix serial string NULL-deref at probe commit aa79f996eb41e95aed85a1bd7f56bcd6a3842008 upstream. The cp2615 driver uses the USB device serial string as the i2c adapter name but does not make sure that the string exists. Verify that the device has a serial number before accessing it to avoid triggering a NULL-pointer dereference (e.g. with malicious devices). Fixes: 4a7695429ead ("i2c: cp2615: add i2c driver for Silicon Labs' CP2615 Digital Audio Bridge") Cc: stable@vger.kernel.org # 5.13 Cc: Bence Csókás Signed-off-by: Johan Hovold Reviewed-by: Bence Csókás Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260309075016.25612-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 7003794316b18350dd32bd3788004829a21e4c2e Author: Ji-Ze Hong (Peter Hong) Date: Fri Dec 12 15:08:31 2025 +0800 USB: serial: f81232: fix incomplete serial port generation commit cd644b805da8a253198718741bf363c4c58862ff upstream. The Fintek F81532A/534A/535/536 family relies on the F81534A_CTRL_CMD_ENABLE_PORT (116h) register during initialization to both determine serial port status and control port creation. If the driver experiences fast load/unload cycles, the device state may becomes unstable, resulting in the incomplete generation of serial ports. Performing a dummy read operation on the register prior to the initial write command resolves the issue. This clears the device's stale internal state. Subsequent write operations will correctly generate all serial ports. This patch also removes the retry loop in f81534a_ctrl_set_register() because the stale state has been fixed. Tested on: HygonDM1SLT(Hygon C86 3250 8-core Processor) Signed-off-by: Ji-Ze Hong (Peter Hong) Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 58b91c5cb685ac86877bd2816017005d56ae1937 Author: Sanman Pradhan Date: Wed Mar 18 19:40:19 2026 +0000 hwmon: (pmbus/isl68137) Fix unchecked return value and use sysfs_emit() commit 86259558e422b250aa6aa57163a6d759074573f5 upstream. isl68137_avs_enable_show_page() uses the return value of pmbus_read_byte_data() without checking for errors. If the I2C transaction fails, a negative error code is passed through bitwise operations, producing incorrect output. Add an error check to propagate the return value if it is negative. Additionally, modernize the callback by replacing sprintf() with sysfs_emit(). Fixes: 038a9c3d1e424 ("hwmon: (pmbus/isl68137) Add driver for Intersil ISL68137 PWM Controller") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan Link: https://lore.kernel.org/r/20260318193952.47908-2-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 81f61e3e1ca2dae1b15ca369e3392dba78357e8d Author: Sanman Pradhan Date: Tue Mar 17 17:37:41 2026 +0000 hwmon: (pmbus/mp2869) Check pmbus_read_byte_data() before using its return value commit c6f45ed26b6eb4766db06f21ff28a97ed485bcbb upstream. In mp2869_read_byte_data() and mp2869_read_word_data(), the return value of pmbus_read_byte_data() for PMBUS_STATUS_MFR_SPECIFIC is used directly inside FIELD_GET() macro arguments without error checking. If the I2C transaction fails, a negative error code is passed to FIELD_GET() and FIELD_PREP(), silently corrupting the status register bits being constructed. Extract the nested pmbus_read_byte_data() calls into a separate variable and check for errors before use. This also eliminates a redundant duplicate read of the same register in the PMBUS_STATUS_TEMPERATURE case. Fixes: a3a2923aaf7f2 ("hwmon: add MP2869,MP29608,MP29612 and MP29816 series driver") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan Link: https://lore.kernel.org/r/20260317173308.382545-4-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 48fed64590800f0d5abc00cb2479dec3093a2340 Author: Sanman Pradhan Date: Tue Mar 17 17:37:17 2026 +0000 hwmon: (pmbus/mp2975) Add error check for pmbus_read_word_data() return value commit 19d4b9c8a136704d5f2544e7ac550f27918a5004 upstream. mp2973_read_word_data() XORs the return value of pmbus_read_word_data() with PB_STATUS_POWER_GOOD_N without first checking for errors. If the I2C transaction fails, a negative error code is XORed with the constant, producing a corrupted value that is returned as valid status data instead of propagating the error. Add the missing error check before modifying the return value. Fixes: acda945afb465 ("hwmon: (pmbus/mp2975) Fix PGOOD in READ_STATUS_WORD") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan Link: https://lore.kernel.org/r/20260317173308.382545-3-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 4418f3186b22376dfd447716819f5490f4a8335a Author: Sanman Pradhan Date: Tue Mar 17 17:46:31 2026 +0000 hwmon: (pmbus/ina233) Add error check for pmbus_read_word_data() return value commit 32f59301b9898c0ab5e72908556d553e2d481945 upstream. ina233_read_word_data() uses the return value of pmbus_read_word_data() directly in a DIV_ROUND_CLOSEST() computation without first checking for errors. If the underlying I2C transaction fails, a negative error code is used in the arithmetic, producing a garbage sensor value instead of propagating the error. Add the missing error check before using the return value. Fixes: b64b6cb163f16 ("hwmon: Add driver for TI INA233 Current and Power Monitor") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan Link: https://lore.kernel.org/r/20260317174553.385567-1-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit beab26de7bcac7dde5a3eaa3b02f0fa574fe5a94 Author: Li Xiasong Date: Thu Mar 19 19:21:59 2026 +0800 MPTCP: fix lock class name family in pm_nl_create_listen_socket [ Upstream commit 7ab4a7c5d969642782b8a5b608da0dd02aa9f229 ] In mptcp_pm_nl_create_listen_socket(), use entry->addr.family instead of sk->sk_family for lock class setup. The 'sk' parameter is a netlink socket, not the MPTCP subflow socket being created. Fixes: cee4034a3db1 ("mptcp: fix lockdep false positive in mptcp_pm_nl_create_listen_socket()") Signed-off-by: Li Xiasong Reviewed-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260319112159.3118874-1-lixiasong1@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d938dd5a0ad780c891ea3bc94cae7405f11e618a Author: Weiming Shi Date: Wed Mar 18 21:06:01 2026 +0800 icmp: fix NULL pointer dereference in icmp_tag_validation() [ Upstream commit 614aefe56af8e13331e50220c936fc0689cf5675 ] icmp_tag_validation() unconditionally dereferences the result of rcu_dereference(inet_protos[proto]) without checking for NULL. The inet_protos[] array is sparse -- only about 15 of 256 protocol numbers have registered handlers. When ip_no_pmtu_disc is set to 3 (hardened PMTU mode) and the kernel receives an ICMP Fragmentation Needed error with a quoted inner IP header containing an unregistered protocol number, the NULL dereference causes a kernel panic in softirq context. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:icmp_unreach (net/ipv4/icmp.c:1085 net/ipv4/icmp.c:1143) Call Trace: icmp_rcv (net/ipv4/icmp.c:1527) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:207) ip_local_deliver_finish (net/ipv4/ip_input.c:242) ip_local_deliver (net/ipv4/ip_input.c:262) ip_rcv (net/ipv4/ip_input.c:573) __netif_receive_skb_one_core (net/core/dev.c:6164) process_backlog (net/core/dev.c:6628) handle_softirqs (kernel/softirq.c:561) Add a NULL check before accessing icmp_strict_tag_validation. If the protocol has no registered handler, return false since it cannot perform strict tag validation. Fixes: 8ed1dc44d3e9 ("ipv4: introduce hardened ip_no_pmtu_disc mode") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Link: https://patch.msgid.link/20260318130558.1050247-4-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6ab68b4adf7444c7ce529dd216c8bed93fd8010d Author: Anas Iqbal Date: Wed Mar 18 08:42:12 2026 +0000 net: dsa: bcm_sf2: fix missing clk_disable_unprepare() in error paths [ Upstream commit b48731849609cbd8c53785a48976850b443153fd ] Smatch reports: drivers/net/dsa/bcm_sf2.c:997 bcm_sf2_sw_resume() warn: 'priv->clk' from clk_prepare_enable() not released on lines: 983,990. The clock enabled by clk_prepare_enable() in bcm_sf2_sw_resume() is not released if bcm_sf2_sw_rst() or bcm_sf2_cfp_resume() fails. Add the missing clk_disable_unprepare() calls in the error paths to properly release the clock resource. Fixes: e9ec5c3bd238 ("net: dsa: bcm_sf2: request and handle clocks") Reviewed-by: Jonas Gorski Reviewed-by: Florian Fainelli Signed-off-by: Anas Iqbal Link: https://patch.msgid.link/20260318084212.1287-1-mohd.abd.6602@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 719f6784f918f9e32f3ff3b197f900e852223f9d Author: Jakub Kicinski Date: Tue Mar 17 09:10:14 2026 -0700 net: shaper: protect from late creation of hierarchy [ Upstream commit d75ec7e8ba1979a1eb0b9211d94d749cdce849c8 ] We look up a netdev during prep of Netlink ops (pre- callbacks) and take a ref to it. Then later in the body of the callback we take its lock or RCU which are the actual protections. The netdev may get unregistered in between the time we take the ref and the time we lock it. We may allocate the hierarchy after flush has already run, which would lead to a leak. Take the instance lock in pre- already, this saves us from the race and removes the need for dedicated lock/unlock callbacks completely. After all, if there's any chance of write happening concurrently with the flush - we're back to leaking the hierarchy. We may take the lock for devices which don't support shapers but we're only dealing with SET operations here, not taking the lock would be optimizing for an error case. Fixes: 93954b40f6a4 ("net-shapers: implement NL set and delete operations") Link: https://lore.kernel.org/20260309173450.538026-1-p@1g4.org Signed-off-by: Jakub Kicinski Link: https://patch.msgid.link/20260317161014.779569-2-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 581eee0890a8bde44f1fb78ad3e70502a897d583 Author: Jakub Kicinski Date: Tue Mar 17 09:10:13 2026 -0700 net: shaper: protect late read accesses to the hierarchy [ Upstream commit 0f9ea7141f365b4f27226898e62220fb98ef8dc6 ] We look up a netdev during prep of Netlink ops (pre- callbacks) and take a ref to it. Then later in the body of the callback we take its lock or RCU which are the actual protections. This is not proper, a conversion from a ref to a locked netdev must include a liveness check (a check if the netdev hasn't been unregistered already). Fix the read cases (those under RCU). Writes needs a separate change to protect from creating the hierarchy after flush has already run. Fixes: 4b623f9f0f59 ("net-shapers: implement NL get operation") Reported-by: Paul Moses Link: https://lore.kernel.org/20260309173450.538026-1-p@1g4.org Signed-off-by: Jakub Kicinski Link: https://patch.msgid.link/20260317161014.779569-1-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 7df2b50cae1a76cbb90b294f3edb61e3e10bf2e9 Author: Muhammad Hammad Ijaz Date: Mon Mar 16 12:31:01 2026 -0700 net: mvpp2: guard flow control update with global_tx_fc in buffer switching [ Upstream commit 8a63baadf08453f66eb582fdb6dd234f72024723 ] mvpp2_bm_switch_buffers() unconditionally calls mvpp2_bm_pool_update_priv_fc() when switching between per-cpu and shared buffer pool modes. This function programs CM3 flow control registers via mvpp2_cm3_read()/mvpp2_cm3_write(), which dereference priv->cm3_base without any NULL check. When the CM3 SRAM resource is not present in the device tree (the third reg entry added by commit 60523583b07c ("dts: marvell: add CM3 SRAM memory to cp11x ethernet device tree")), priv->cm3_base remains NULL and priv->global_tx_fc is false. Any operation that triggers mvpp2_bm_switch_buffers(), for example an MTU change that crosses the jumbo frame threshold, will crash: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits pc : readl+0x0/0x18 lr : mvpp2_cm3_read.isra.0+0x14/0x20 Call trace: readl+0x0/0x18 mvpp2_bm_pool_update_fc+0x40/0x12c mvpp2_bm_pool_update_priv_fc+0x94/0xd8 mvpp2_bm_switch_buffers.isra.0+0x80/0x1c0 mvpp2_change_mtu+0x140/0x380 __dev_set_mtu+0x1c/0x38 dev_set_mtu_ext+0x78/0x118 dev_set_mtu+0x48/0xa8 dev_ifsioc+0x21c/0x43c dev_ioctl+0x2d8/0x42c sock_ioctl+0x314/0x378 Every other flow control call site in the driver already guards hardware access with either priv->global_tx_fc or port->tx_fc. mvpp2_bm_switch_buffers() is the only place that omits this check. Add the missing priv->global_tx_fc guard to both the disable and re-enable calls in mvpp2_bm_switch_buffers(), consistent with the rest of the driver. Fixes: 3a616b92a9d1 ("net: mvpp2: Add TX flow control support for jumbo frames") Signed-off-by: Muhammad Hammad Ijaz Reviewed-by: Gunnar Kudrjavets Link: https://patch.msgid.link/20260316193157.65748-1-mhijaz@amazon.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 3932620c04c2938c93c0890c225960d3d34ba355 Author: Weiming Shi Date: Thu Mar 19 15:32:44 2026 +0800 nfnetlink_osf: validate individual option lengths in fingerprints [ Upstream commit dbdfaae9609629a9569362e3b8f33d0a20fd783c ] nfnl_osf_add_callback() validates opt_num bounds and string NUL-termination but does not check individual option length fields. A zero-length option causes nf_osf_match_one() to enter the option matching loop even when foptsize sums to zero, which matches packets with no TCP options where ctx->optp is NULL: Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98) Call Trace: nf_osf_match (net/netfilter/nfnetlink_osf.c:227) xt_osf_match_packet (net/netfilter/xt_osf.c:32) ipt_do_table (net/ipv4/netfilter/ip_tables.c:293) nf_hook_slow (net/netfilter/core.c:623) ip_local_deliver (net/ipv4/ip_input.c:262) ip_rcv (net/ipv4/ip_input.c:573) Additionally, an MSS option (kind=2) with length < 4 causes out-of-bounds reads when nf_osf_match_one() unconditionally accesses optp[2] and optp[3] for MSS value extraction. While RFC 9293 section 3.2 specifies that the MSS option is always exactly 4 bytes (Kind=2, Length=4), the check uses "< 4" rather than "!= 4" because lengths greater than 4 do not cause memory safety issues -- the buffer is guaranteed to be at least foptsize bytes by the ctx->optsize == foptsize check. Reject fingerprints where any option has zero length, or where an MSS option has length less than 4, at add time rather than trusting these values in the packet matching hot path. Fixes: 11eeef41d5f6 ("netfilter: passive OS fingerprint xtables match") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit c8092edb9a11f20f95ccceeb9422b7dd0df337bd Author: Pablo Neira Ayuso Date: Tue Mar 17 20:00:26 2026 +0100 netfilter: nf_tables: release flowtable after rcu grace period on error [ Upstream commit d73f4b53aaaea4c95f245e491aa5eeb8a21874ce ] Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane. This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu(). There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised. Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks. Fixes: 3b49e2e94e6e ("netfilter: nf_tables: add flow table netlink frontend") Reported-by: Yiming Qian Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit c25e0dec366ae99b7264324ce3c7cbaea34691f9 Author: Florian Westphal Date: Tue Mar 17 12:23:08 2026 +0100 netfilter: bpf: defer hook memory release until rcu readers are done [ Upstream commit 24f90fa3994b992d1a09003a3db2599330a5232a ] Yiming Qian reports UaF when concurrent process is dumping hooks via nfnetlink_hooks: BUG: KASAN: slab-use-after-free in nfnl_hook_dump_one.isra.0+0xe71/0x10f0 Read of size 8 at addr ffff888003edbf88 by task poc/79 Call Trace: nfnl_hook_dump_one.isra.0+0xe71/0x10f0 netlink_dump+0x554/0x12b0 nfnl_hook_get+0x176/0x230 [..] Defer release until after concurrent readers have completed. Reported-by: Yiming Qian Fixes: 84601d6ee68a ("bpf: add bpf_link support for BPF_NETFILTER programs") Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 017d674cf6930e9586a29ee808c7ca09d1396d07 Author: Xiang Mei Date: Mon Mar 16 17:50:34 2026 -0700 net: bonding: fix NULL deref in bond_debug_rlb_hash_show [ Upstream commit 605b52497bf89b3b154674deb135da98f916e390 ] rlb_clear_slave intentionally keeps RLB hash-table entries on the rx_hashtbl_used_head list with slave set to NULL when no replacement slave is available. However, bond_debug_rlb_hash_show visites client_info->slave without checking if it's NULL. Other used-list iterators in bond_alb.c already handle this NULL-slave state safely: - rlb_update_client returns early on !client_info->slave - rlb_req_update_slave_clients, rlb_clear_slave, and rlb_rebalance compare slave values before visiting - lb_req_update_subnet_clients continues if slave is NULL The following NULL deref crash can be trigger in bond_debug_rlb_hash_show: [ 1.289791] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 1.292058] RIP: 0010:bond_debug_rlb_hash_show (drivers/net/bonding/bond_debugfs.c:41) [ 1.293101] RSP: 0018:ffffc900004a7d00 EFLAGS: 00010286 [ 1.293333] RAX: 0000000000000000 RBX: ffff888102b48200 RCX: ffff888102b48204 [ 1.293631] RDX: ffff888102b48200 RSI: ffffffff839daad5 RDI: ffff888102815078 [ 1.293924] RBP: ffff888102815078 R08: ffff888102b4820e R09: 0000000000000000 [ 1.294267] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100f929c0 [ 1.294564] R13: ffff888100f92a00 R14: 0000000000000001 R15: ffffc900004a7ed8 [ 1.294864] FS: 0000000001395380(0000) GS:ffff888196e75000(0000) knlGS:0000000000000000 [ 1.295239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.295480] CR2: 0000000000000000 CR3: 0000000102adc004 CR4: 0000000000772ef0 [ 1.295897] Call Trace: [ 1.296134] seq_read_iter (fs/seq_file.c:231) [ 1.296341] seq_read (fs/seq_file.c:164) [ 1.296493] full_proxy_read (fs/debugfs/file.c:378 (discriminator 1)) [ 1.296658] vfs_read (fs/read_write.c:572) [ 1.296981] ksys_read (fs/read_write.c:717) [ 1.297132] do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) [ 1.297325] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Add a NULL check and print "(none)" for entries with no assigned slave. Fixes: caafa84251b88 ("bonding: add the debugfs interface to see RLB hash table") Reported-by: Weiming Shi Signed-off-by: Xiang Mei Link: https://patch.msgid.link/20260317005034.1888794-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 003343985f26dfefd0c94b1fe1316a2de74428b9 Author: Xiang Mei Date: Mon Mar 16 18:02:41 2026 -0700 udp_tunnel: fix NULL deref caused by udp_sock_create6 when CONFIG_IPV6=n [ Upstream commit b3a6df291fecf5f8a308953b65ca72b7fc9e015d ] When CONFIG_IPV6 is disabled, the udp_sock_create6() function returns 0 (success) without actually creating a socket. Callers such as fou_create() then proceed to dereference the uninitialized socket pointer, resulting in a NULL pointer dereference. The captured NULL deref crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:fou_nl_add_doit (net/ipv4/fou_core.c:590 net/ipv4/fou_core.c:764) [...] Call Trace: genl_family_rcv_msg_doit.constprop.0 (net/netlink/genetlink.c:1114) genl_rcv_msg (net/netlink/genetlink.c:1194 net/netlink/genetlink.c:1209) [...] netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sock_sendmsg (net/socket.c:727 (discriminator 1) net/socket.c:742 (discriminator 1)) __sys_sendto (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:2183 (discriminator 1)) __x64_sys_sendto (net/socket.c:2213 (discriminator 1) net/socket.c:2209 (discriminator 1) net/socket.c:2209 (discriminator 1)) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (net/arch/x86/entry/entry_64.S:130) This patch makes udp_sock_create6 return -EPFNOSUPPORT instead, so callers correctly take their error paths. There is only one caller of the vulnerable function and only privileged users can trigger it. Fixes: fd384412e199b ("udp_tunnel: Seperate ipv6 functions into its own file.") Reported-by: Weiming Shi Signed-off-by: Xiang Mei Link: https://patch.msgid.link/20260317010241.1893893-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 96c9c25b74686ac2de15921c9ad30c5ef13af8cd Author: Jianbo Liu Date: Mon Mar 16 11:46:03 2026 +0200 net/mlx5e: Fix race condition during IPSec ESN update [ Upstream commit beb6e2e5976a128b0cccf10d158124422210c5ef ] In IPSec full offload mode, the device reports an ESN (Extended Sequence Number) wrap event to the driver. The driver validates this event by querying the IPSec ASO and checking that the esn_event_arm field is 0x0, which indicates an event has occurred. After handling the event, the driver must re-arm the context by setting esn_event_arm back to 0x1. A race condition exists in this handling path. After validating the event, the driver calls mlx5_accel_esp_modify_xfrm() to update the kernel's xfrm state. This function temporarily releases and re-acquires the xfrm state lock. So, need to acknowledge the event first by setting esn_event_arm to 0x1. This prevents the driver from reprocessing the same ESN update if the hardware sends events for other reason. Since the next ESN update only occurs after nearly 2^31 packets are received, there's no risk of missing an update, as it will happen long after this handling has finished. Processing the event twice causes the ESN high-order bits (esn_msb) to be incremented incorrectly. The driver then programs the hardware with this invalid ESN state, which leads to anti-replay failures and a complete halt of IPSec traffic. Fix this by re-arming the ESN event immediately after it is validated, before calling mlx5_accel_esp_modify_xfrm(). This ensures that any spurious, duplicate events are correctly ignored, closing the race window. Fixes: fef06678931f ("net/mlx5e: Fix ESN update kernel panic") Signed-off-by: Jianbo Liu Reviewed-by: Leon Romanovsky Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260316094603.6999-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2c6a5be0aee5a44066f68a332c30650900e32ad4 Author: Jianbo Liu Date: Mon Mar 16 11:46:02 2026 +0200 net/mlx5e: Prevent concurrent access to IPSec ASO context [ Upstream commit 99b36850d881e2d65912b2520a1c80d0fcc9429a ] The query or updating IPSec offload object is through Access ASO WQE. The driver uses a single mlx5e_ipsec_aso struct for each PF, which contains a shared DMA-mapped context for all ASO operations. A race condition exists because the ASO spinlock is released before the hardware has finished processing WQE. If a second operation is initiated immediately after, it overwrites the shared context in the DMA area. When the first operation's completion is processed later, it reads this corrupted context, leading to unexpected behavior and incorrect results. This commit fixes the race by introducing a private context within each IPSec offload object. The shared ASO context is now copied to this private context while the ASO spinlock is held. Subsequent processing uses this saved, per-object context, ensuring its integrity is maintained. Fixes: 1ed78fc03307 ("net/mlx5e: Update IPsec soft and hard limits") Signed-off-by: Jianbo Liu Reviewed-by: Leon Romanovsky Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260316094603.6999-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ea52e95be46385ebf8f85c803e21318166015fcf Author: Cosmin Ratiu Date: Mon Mar 16 11:46:01 2026 +0200 net/mlx5: qos: Restrict RTNL area to avoid a lock cycle [ Upstream commit b7e3a5d9c0d66b7fb44f63aef3bd734821afa0c8 ] A lock dependency cycle exists where: 1. mlx5_ib_roce_init -> mlx5_core_uplink_netdev_event_replay -> mlx5_blocking_notifier_call_chain (takes notifier_rwsem) -> mlx5e_mdev_notifier_event -> mlx5_netdev_notifier_register -> register_netdevice_notifier_dev_net (takes rtnl) => notifier_rwsem -> rtnl 2. mlx5e_probe -> _mlx5e_probe -> mlx5_core_uplink_netdev_set (takes uplink_netdev_lock) -> mlx5_blocking_notifier_call_chain (takes notifier_rwsem) => uplink_netdev_lock -> notifier_rwsem 3: devlink_nl_rate_set_doit -> devlink_nl_rate_set -> mlx5_esw_devlink_rate_leaf_tx_max_set -> esw_qos_devlink_rate_to_mbps -> mlx5_esw_qos_max_link_speed_get (takes rtnl) -> mlx5_esw_qos_lag_link_speed_get_locked -> mlx5_uplink_netdev_get (takes uplink_netdev_lock) => rtnl -> uplink_netdev_lock => BOOM! (lock cycle) Fix that by restricting the rtnl-protected section to just the necessary part, the call to netdev_master_upper_dev_get and speed querying, so that the last lock dependency is avoided and the cycle doesn't close. This is safe because mlx5_uplink_netdev_get uses netdev_hold to keep the uplink netdev alive while its master device is queried. Use this opportunity to rename the ambiguously-named "hold_rtnl_lock" argument to "take_rtnl" and remove the "_locked" suffix from mlx5_esw_qos_lag_link_speed_get_locked. Fixes: 6b4be64fd9fe ("net/mlx5e: Harden uplink netdev access against device unbind") Signed-off-by: Cosmin Ratiu Reviewed-by: Dragos Tatulea Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260316094603.6999-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c852ebfe433442682a153724837d5001e2b4e739 Author: Fedor Pchelkin Date: Mon Mar 16 13:38:25 2026 +0300 net: macb: fix uninitialized rx_fs_lock [ Upstream commit 34b11cc56e4369bc08b1f4c4a04222d75ed596ce ] If hardware doesn't support RX Flow Filters, rx_fs_lock spinlock is not initialized leading to the following assertion splat triggerable via set_rxnfc callback. INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 1 PID: 949 Comm: syz.0.6 Not tainted 6.1.164+ #113 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8d/0xba lib/dump_stack.c:106 assign_lock_key kernel/locking/lockdep.c:974 [inline] register_lock_class+0x141b/0x17f0 kernel/locking/lockdep.c:1287 __lock_acquire+0x74f/0x6c40 kernel/locking/lockdep.c:4928 lock_acquire kernel/locking/lockdep.c:5662 [inline] lock_acquire+0x190/0x4b0 kernel/locking/lockdep.c:5627 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x33/0x50 kernel/locking/spinlock.c:162 gem_del_flow_filter drivers/net/ethernet/cadence/macb_main.c:3562 [inline] gem_set_rxnfc+0x533/0xac0 drivers/net/ethernet/cadence/macb_main.c:3667 ethtool_set_rxnfc+0x18c/0x280 net/ethtool/ioctl.c:961 __dev_ethtool net/ethtool/ioctl.c:2956 [inline] dev_ethtool+0x229c/0x6290 net/ethtool/ioctl.c:3095 dev_ioctl+0x637/0x1070 net/core/dev_ioctl.c:510 sock_do_ioctl+0x20d/0x2c0 net/socket.c:1215 sock_ioctl+0x577/0x6d0 net/socket.c:1320 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x18c/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:46 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 A more straightforward solution would be to always initialize rx_fs_lock, just like rx_fs_list. However, in this case the driver set_rxnfc callback would return with a rather confusing error code, e.g. -EINVAL. So deny set_rxnfc attempts directly if the RX filtering feature is not supported by hardware. Fixes: ae8223de3df5 ("net: macb: Added support for RX filtering") Signed-off-by: Fedor Pchelkin Link: https://patch.msgid.link/20260316103826.74506-2-pchelkin@ispras.ru Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 63e192b8956a27c23d7dd757305cafcaf70d8ee3 Author: Wesley Atwell Date: Tue Mar 17 00:14:31 2026 -0600 netdevsim: drop PSP ext ref on forward failure [ Upstream commit 7d9351435ebba08bbb60f42793175c9dc714d2fb ] nsim_do_psp() takes an extra reference to the PSP skb extension so the extension survives __dev_forward_skb(). That forward path scrubs the skb and drops attached skb extensions before nsim_psp_handle_ext() can reattach the PSP metadata. If __dev_forward_skb() fails in nsim_forward_skb(), the function returns before nsim_psp_handle_ext() can attach that extension to the skb, leaving the extra reference leaked. Drop the saved PSP extension reference before returning from the forward-failure path. Guard the put because plain or non-decapsulated traffic can also fail forwarding without ever taking the extra PSP reference. Fixes: f857478d6206 ("netdevsim: a basic test PSP implementation") Signed-off-by: Wesley Atwell Reviewed-by: Daniel Zahka Link: https://patch.msgid.link/20260317061431.1482716-1-atwellwea@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 98473309a36acc271009b85e0bb53a4c0dddf5c2 Author: Rafael J. Wysocki Date: Tue Mar 17 21:39:05 2026 +0100 ACPI: processor: Fix previous acpi_processor_errata_piix4() fix [ Upstream commit bf504b229cb8d534eccbaeaa23eba34c05131e25 ] After commi f132e089fe89 ("ACPI: processor: Fix NULL-pointer dereference in acpi_processor_errata_piix4()"), device pointers may be dereferenced after dropping references to the device objects pointed to by them, which may cause a use-after-free to occur. Moreover, debug messages about enabling the errata may be printed if the errata flags corresponding to them are unset. Address all of these issues by moving message printing to the points in the code where the errata flags are set. Fixes: f132e089fe89 ("ACPI: processor: Fix NULL-pointer dereference in acpi_processor_errata_piix4()") Reported-by: Guenter Roeck Closes: https://lore.kernel.org/linux-acpi/938e2206-def5-4b7a-9b2c-d1fd37681d8a@roeck-us.net/ Reviewed-by: Guenter Roeck Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/5975693.DvuYhMxLoT@rafael.j.wysocki Signed-off-by: Sasha Levin commit 06e769dddcbeb3baf2ce346273b53dd61fdbecf4 Author: Felix Fietkau Date: Sat Mar 14 06:54:55 2026 +0000 wifi: mac80211: always free skb on ieee80211_tx_prepare_skb() failure [ Upstream commit d5ad6ab61cbd89afdb60881f6274f74328af3ee9 ] ieee80211_tx_prepare_skb() has three error paths, but only two of them free the skb. The first error path (ieee80211_tx_prepare() returning TX_DROP) does not free it, while invoke_tx_handlers() failure and the fragmentation check both do. Add kfree_skb() to the first error path so all three are consistent, and remove the now-redundant frees in callers (ath9k, mt76, mac80211_hwsim) to avoid double-free. Document the skb ownership guarantee in the function's kdoc. Signed-off-by: Felix Fietkau Link: https://patch.msgid.link/20260314065455.2462900-1-nbd@nbd.name Fixes: 06be6b149f7e ("mac80211: add ieee80211_tx_prepare_skb() helper function") Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 46c670ff1ff466e5eccb3940f726586473dc053c Author: Guenter Roeck Date: Tue Mar 17 23:46:36 2026 -0700 wifi: wlcore: Return -ENOMEM instead of -EAGAIN if there is not enough headroom [ Upstream commit deb353d9bb009638b7762cae2d0b6e8fdbb41a69 ] Since upstream commit e75665dd0968 ("wifi: wlcore: ensure skb headroom before skb_push"), wl1271_tx_allocate() and with it wl1271_prepare_tx_frame() returns -EAGAIN if pskb_expand_head() fails. However, in wlcore_tx_work_locked(), a return value of -EAGAIN from wl1271_prepare_tx_frame() is interpreted as the aggregation buffer being full. This causes the code to flush the buffer, put the skb back at the head of the queue, and immediately retry the same skb in a tight while loop. Because wlcore_tx_work_locked() holds wl->mutex, and the retry happens immediately with GFP_ATOMIC, this will result in an infinite loop and a CPU soft lockup. Return -ENOMEM instead so the packet is dropped and the loop terminates. The problem was found by an experimental code review agent based on gemini-3.1-pro while reviewing backports into v6.18.y. Assisted-by: Gemini:gemini-3.1-pro Fixes: e75665dd0968 ("wifi: wlcore: ensure skb headroom before skb_push") Cc: Peter Astrand Signed-off-by: Guenter Roeck Link: https://patch.msgid.link/20260318064636.3065925-1-linux@roeck-us.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 44699c6cdfce80a0f296b54ae9314461e3e41b3d Author: Xiang Mei Date: Tue Mar 17 20:42:44 2026 -0700 wifi: mac80211: fix NULL deref in mesh_matches_local() [ Upstream commit c73bb9a2d33bf81f6eecaa0f474b6c6dbe9855bd ] mesh_matches_local() unconditionally dereferences ie->mesh_config to compare mesh configuration parameters. When called from mesh_rx_csa_frame(), the parsed action-frame elements may not contain a Mesh Configuration IE, leaving ie->mesh_config NULL and triggering a kernel NULL pointer dereference. The other two callers are already safe: - ieee80211_mesh_rx_bcn_presp() checks !elems->mesh_config before calling mesh_matches_local() - mesh_plink_get_event() is only reached through mesh_process_plink_frame(), which checks !elems->mesh_config, too mesh_rx_csa_frame() is the only caller that passes raw parsed elements to mesh_matches_local() without guarding mesh_config. An adjacent attacker can exploit this by sending a crafted CSA action frame that includes a valid Mesh ID IE but omits the Mesh Configuration IE, crashing the kernel. The captured crash log: Oops: general protection fault, probably for non-canonical address ... KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events_unbound cfg80211_wiphy_work [...] Call Trace: ? __pfx_mesh_matches_local (net/mac80211/mesh.c:65) ieee80211_mesh_rx_queued_mgmt (net/mac80211/mesh.c:1686) [...] ieee80211_iface_work (net/mac80211/iface.c:1754 net/mac80211/iface.c:1802) [...] cfg80211_wiphy_work (net/wireless/core.c:426) process_one_work (net/kernel/workqueue.c:3280) ? assign_work (net/kernel/workqueue.c:1219) worker_thread (net/kernel/workqueue.c:3352) ? __pfx_worker_thread (net/kernel/workqueue.c:3385) kthread (net/kernel/kthread.c:436) [...] ret_from_fork_asm (net/arch/x86/entry/entry_64.S:255) This patch adds a NULL check for ie->mesh_config at the top of mesh_matches_local() to return false early when the Mesh Configuration IE is absent. Fixes: 2e3c8736820b ("mac80211: support functions for mesh") Reported-by: Weiming Shi Signed-off-by: Xiang Mei Link: https://patch.msgid.link/20260318034244.2595020-1-xmei5@asu.edu Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 5f284b12cc1270a3ede773e47b9c98addd2d255b Author: Michal Swiatkowski Date: Wed Feb 11 10:10:08 2026 +0100 libie: prevent memleak in fwlog code [ Upstream commit 6850deb61118345996f03b87817b4ae0f2f25c38 ] All cmd_buf buffers are allocated and need to be freed after usage. Add an error unwinding path that properly frees these buffers. The memory leak happens whenever fwlog configuration is changed. For example: $echo 256K > /sys/kernel/debug/ixgbe/0000\:32\:00.0/fwlog/log_size Fixes: 96a9a9341cda ("ice: configure FW logging") Reviewed-by: Aleksandr Loktionov Signed-off-by: Michal Swiatkowski Reviewed-by: Simon Horman Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit cff11b1c03e6fb640f471e71a4b0b657e501629e Author: Petr Oros Date: Wed Feb 25 11:01:37 2026 +0100 iavf: fix VLAN filter lost on add/delete race [ Upstream commit fc9c69be594756b81b54c6bc40803fa6052f35ae ] When iavf_add_vlan() finds an existing filter in IAVF_VLAN_REMOVE state, it transitions the filter to IAVF_VLAN_ACTIVE assuming the pending delete can simply be cancelled. However, there is no guarantee that iavf_del_vlans() has not already processed the delete AQ request and removed the filter from the PF. In that case the filter remains in the driver's list as IAVF_VLAN_ACTIVE but is no longer programmed on the NIC. Since iavf_add_vlans() only picks up filters in IAVF_VLAN_ADD state, the filter is never re-added, and spoof checking drops all traffic for that VLAN. CPU0 CPU1 Workqueue ---- ---- --------- iavf_del_vlan(vlan 100) f->state = REMOVE schedule AQ_DEL_VLAN iavf_add_vlan(vlan 100) f->state = ACTIVE iavf_del_vlans() f is ACTIVE, skip iavf_add_vlans() f is ACTIVE, skip Filter is ACTIVE in driver but absent from NIC. Transition to IAVF_VLAN_ADD instead and schedule IAVF_FLAG_AQ_ADD_VLAN_FILTER so iavf_add_vlans() re-programs the filter. A duplicate add is idempotent on the PF. Fixes: 0c0da0e95105 ("iavf: refactor VLAN filter states") Signed-off-by: Petr Oros Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 31521c124e6488c4a81658e35199feb75a988d86 Author: Zdenek Bouska Date: Wed Feb 25 10:58:29 2026 +0100 igc: fix page fault in XDP TX timestamps handling [ Upstream commit 45b33e805bd39f615d9353a7194b2da5281332df ] If an XDP application that requested TX timestamping is shutting down while the link of the interface in use is still up the following kernel splat is reported: [ 883.803618] [ T1554] BUG: unable to handle page fault for address: ffffcfb6200fd008 ... [ 883.803650] [ T1554] Call Trace: [ 883.803652] [ T1554] [ 883.803654] [ T1554] igc_ptp_tx_tstamp_event+0xdf/0x160 [igc] [ 883.803660] [ T1554] igc_tsync_interrupt+0x2d5/0x300 [igc] ... During shutdown of the TX ring the xsk_meta pointers are left behind, so that the IRQ handler is trying to touch them. This issue is now being fixed by cleaning up the stale xsk meta data on TX shutdown. TX timestamps on other queues remain unaffected. Fixes: 15fd021bc427 ("igc: Add Tx hardware timestamp request for AF_XDP zero-copy packet") Signed-off-by: Zdenek Bouska Reviewed-by: Paul Menzel Reviewed-by: Florian Bezdeka Tested-by: Avigail Dahan Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 3472c22c067abcfe4045da79fb0c4275117f0469 Author: Kohei Enju Date: Sat Feb 14 19:46:32 2026 +0000 igc: fix missing update of skb->tail in igc_xmit_frame() [ Upstream commit 0ffba246652faf4a36aedc66059c2f94e4c83ea5 ] igc_xmit_frame() misses updating skb->tail when the packet size is shorter than the minimum one. Use skb_put_padto() in alignment with other Intel Ethernet drivers. Fixes: 0507ef8a0372 ("igc: Add transmit and receive fastpath and interrupt handlers") Signed-off-by: Kohei Enju Reviewed-by: Simon Horman Reviewed-by: Paul Menzel Tested-by: Avigail Dahan Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 89b2b1c64d09a7e9a78e485740e575c97e9d05d5 Author: Saket Dumbre Date: Tue Mar 17 20:34:49 2026 +0100 ACPICA: Update the format of Arg3 of _DSM [ Upstream commit ab93d7eee94205430fc3b0532557cb0494bf2faf ] To get rid of type incompatibility warnings in Linux. Fixes: 81f92cff6d42 ("ACPICA: ACPI_TYPE_ANY does not include the package type") Link: https://github.com/acpica/acpica/commit/4fb74872dcec Signed-off-by: Saket Dumbre Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/12856643.O9o76ZdvQC@rafael.j.wysocki Signed-off-by: Sasha Levin commit d3e32a612c6391ca9b7c183aeec22b4fd24c300c Author: Nikola Z. Ivanov Date: Fri Mar 13 16:16:43 2026 +0200 net: usb: aqc111: Do not perform PM inside suspend callback [ Upstream commit 069c8f5aebe4d5224cf62acc7d4b3486091c658a ] syzbot reports "task hung in rpm_resume" This is caused by aqc111_suspend calling the PM variant of its write_cmd routine. The simplified call trace looks like this: rpm_suspend() usb_suspend_both() - here udev->dev.power.runtime_status == RPM_SUSPENDING aqc111_suspend() - called for the usb device interface aqc111_write32_cmd() usb_autopm_get_interface() pm_runtime_resume_and_get() rpm_resume() - here we call rpm_resume() on our parent rpm_resume() - Here we wait for a status change that will never happen. At this point we block another task which holds rtnl_lock and locks up the whole networking stack. Fix this by replacing the write_cmd calls with their _nopm variants Reported-by: syzbot+48dc1e8dfc92faf1124c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=48dc1e8dfc92faf1124c Fixes: e58ba4544c77 ("net: usb: aqc111: Add support for wake on LAN by MAGIC packet") Signed-off-by: Nikola Z. Ivanov Link: https://patch.msgid.link/20260313141643.1181386-1-zlatistiv@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 4c9af67f99aa3e51b522c54968ab3ac8272be41c Author: Daniel Borkmann Date: Fri Mar 13 07:55:31 2026 +0100 clsact: Fix use-after-free in init/destroy rollback asymmetry [ Upstream commit a0671125d4f55e1e98d9bde8a0b671941987e208 ] Fix a use-after-free in the clsact qdisc upon init/destroy rollback asymmetry. The latter is achieved by first fully initializing a clsact instance, and then in a second step having a replacement failure for the new clsact qdisc instance. clsact_init() initializes ingress first and then takes care of the egress part. This can fail midway, for example, via tcf_block_get_ext(). Upon failure, the kernel will trigger the clsact_destroy() callback. Commit 1cb6f0bae504 ("bpf: Fix too early release of tcx_entry") details the way how the transition is happening. If tcf_block_get_ext on the q->ingress_block ends up failing, we took the tcx_miniq_inc reference count on the ingress side, but not yet on the egress side. clsact_destroy() tests whether the {ingress,egress}_entry was non-NULL. However, even in midway failure on the replacement, both are in fact non-NULL with a valid egress_entry from the previous clsact instance. What we really need to test for is whether the qdisc instance-specific ingress or egress side previously got initialized. This adds a small helper for checking the miniq initialization called mini_qdisc_pair_inited, and utilizes that upon clsact_destroy() in order to fix the use-after-free scenario. Convert the ingress_destroy() side as well so both are consistent to each other. Fixes: 1cb6f0bae504 ("bpf: Fix too early release of tcx_entry") Reported-by: Keenan Dong Signed-off-by: Daniel Borkmann Cc: Martin KaFai Lau Acked-by: Martin KaFai Lau Link: https://patch.msgid.link/20260313065531.98639-1-daniel@iogearbox.net Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit a5bd5a2710310c965ea4153cba4210988a3454e2 Author: Tobi Gaertner Date: Fri Mar 13 22:46:40 2026 -0700 net: usb: cdc_ncm: add ndpoffset to NDP32 nframes bounds check [ Upstream commit 77914255155e68a20aa41175edeecf8121dac391 ] The same bounds-check bug fixed for NDP16 in the previous patch also exists in cdc_ncm_rx_verify_ndp32(). The DPE array size is validated against the total skb length without accounting for ndpoffset, allowing out-of-bounds reads when the NDP32 is placed near the end of the NTB. Add ndpoffset to the nframes bounds check and use struct_size_t() to express the NDP-plus-DPE-array size more clearly. Compile-tested only. Fixes: 0fa81b304a79 ("cdc_ncm: Implement the 32-bit version of NCM Transfer Block") Signed-off-by: Tobi Gaertner Link: https://patch.msgid.link/20260314054640.2895026-3-tob.gaertner@me.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 403f94ddcb36c552fbef51dea735b131e3dcde8b Author: Tobi Gaertner Date: Fri Mar 13 22:46:39 2026 -0700 net: usb: cdc_ncm: add ndpoffset to NDP16 nframes bounds check [ Upstream commit 2aa8a4fa8d5b7d0e1ebcec100e1a4d80a1f4b21a ] cdc_ncm_rx_verify_ndp16() validates that the NDP header and its DPE entries fit within the skb. The first check correctly accounts for ndpoffset: if ((ndpoffset + sizeof(struct usb_cdc_ncm_ndp16)) > skb_in->len) but the second check omits it: if ((sizeof(struct usb_cdc_ncm_ndp16) + ret * (sizeof(struct usb_cdc_ncm_dpe16))) > skb_in->len) This validates the DPE array size against the total skb length as if the NDP were at offset 0, rather than at ndpoffset. When the NDP is placed near the end of the NTB (large wNdpIndex), the DPE entries can extend past the skb data buffer even though the check passes. cdc_ncm_rx_fixup() then reads out-of-bounds memory when iterating the DPE array. Add ndpoffset to the nframes bounds check and use struct_size_t() to express the NDP-plus-DPE-array size more clearly. Fixes: ff06ab13a4cc ("net: cdc_ncm: splitting rx_fixup for code reuse") Signed-off-by: Tobi Gaertner Link: https://patch.msgid.link/20260314054640.2895026-2-tob.gaertner@me.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d538b371da1e7306753c68560266d2bf6f9f9ade Author: Lorenzo Bianconi Date: Fri Mar 13 12:27:00 2026 +0100 net: airoha: Remove airoha_dev_stop() in airoha_remove() [ Upstream commit d4a533ad249e9fbdc2d0633f2ddd60a5b3a9a4ca ] Do not run airoha_dev_stop routine explicitly in airoha_remove() since ndo_stop() callback is already executed by unregister_netdev() in __dev_close_many routine if necessary and, doing so, we will end up causing an underflow in the qdma users atomic counters. Rely on networking subsystem to stop the device removing the airoha_eth module. Fixes: 23020f0493270 ("net: airoha: Introduce ethernet support for EN7581 SoC") Signed-off-by: Lorenzo Bianconi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260313-airoha-remove-ndo_stop-remove-net-v2-1-67542c3ceeca@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e9c66d3e7d8557b3308e55c613aa07254fe97611 Author: Jamal Hadi Salim Date: Sun Mar 15 11:54:22 2026 -0400 net/sched: teql: Fix double-free in teql_master_xmit [ Upstream commit 66360460cab63c248ca5b1070a01c0c29133b960 ] Whenever a TEQL devices has a lockless Qdisc as root, qdisc_reset should be called using the seq_lock to avoid racing with the datapath. Failure to do so may cause crashes like the following: [ 238.028993][ T318] BUG: KASAN: double-free in skb_release_data (net/core/skbuff.c:1139) [ 238.029328][ T318] Free of addr ffff88810c67ec00 by task poc_teql_uaf_ke/318 [ 238.029749][ T318] [ 238.029900][ T318] CPU: 3 UID: 0 PID: 318 Comm: poc_teql_ke Not tainted 7.0.0-rc3-00149-ge5b31d988a41 #704 PREEMPT(full) [ 238.029906][ T318] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 238.029910][ T318] Call Trace: [ 238.029913][ T318] [ 238.029916][ T318] dump_stack_lvl (lib/dump_stack.c:122) [ 238.029928][ T318] print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) [ 238.029940][ T318] ? skb_release_data (net/core/skbuff.c:1139) [ 238.029944][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) ... [ 238.029957][ T318] ? skb_release_data (net/core/skbuff.c:1139) [ 238.029969][ T318] kasan_report_invalid_free (mm/kasan/report.c:221 mm/kasan/report.c:563) [ 238.029979][ T318] ? skb_release_data (net/core/skbuff.c:1139) [ 238.029989][ T318] check_slab_allocation (mm/kasan/common.c:231) [ 238.029995][ T318] kmem_cache_free (mm/slub.c:2637 (discriminator 1) mm/slub.c:6168 (discriminator 1) mm/slub.c:6298 (discriminator 1)) [ 238.030004][ T318] skb_release_data (net/core/skbuff.c:1139) ... [ 238.030025][ T318] sk_skb_reason_drop (net/core/skbuff.c:1256) [ 238.030032][ T318] pfifo_fast_reset (./include/linux/ptr_ring.h:171 ./include/linux/ptr_ring.h:309 ./include/linux/skb_array.h:98 net/sched/sch_generic.c:827) [ 238.030039][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) ... [ 238.030054][ T318] qdisc_reset (net/sched/sch_generic.c:1034) [ 238.030062][ T318] teql_destroy (./include/linux/spinlock.h:395 net/sched/sch_teql.c:157) [ 238.030071][ T318] __qdisc_destroy (./include/net/pkt_sched.h:328 net/sched/sch_generic.c:1077) [ 238.030077][ T318] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 238.030089][ T318] ? __pfx_qdisc_graft (net/sched/sch_api.c:1091) [ 238.030095][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 238.030102][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 238.030106][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 238.030114][ T318] tc_get_qdisc (net/sched/sch_api.c:1529 net/sched/sch_api.c:1556) ... [ 238.072958][ T318] Allocated by task 303 on cpu 5 at 238.026275s: [ 238.073392][ T318] kasan_save_stack (mm/kasan/common.c:58) [ 238.073884][ T318] kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5)) [ 238.074230][ T318] __kasan_slab_alloc (mm/kasan/common.c:369) [ 238.074578][ T318] kmem_cache_alloc_node_noprof (./include/linux/kasan.h:253 mm/slub.c:4542 mm/slub.c:4869 mm/slub.c:4921) [ 238.076091][ T318] kmalloc_reserve (net/core/skbuff.c:616 (discriminator 107)) [ 238.076450][ T318] __alloc_skb (net/core/skbuff.c:713) [ 238.076834][ T318] alloc_skb_with_frags (./include/linux/skbuff.h:1383 net/core/skbuff.c:6763) [ 238.077178][ T318] sock_alloc_send_pskb (net/core/sock.c:2997) [ 238.077520][ T318] packet_sendmsg (net/packet/af_packet.c:2926 net/packet/af_packet.c:3019 net/packet/af_packet.c:3108) [ 238.081469][ T318] [ 238.081870][ T318] Freed by task 299 on cpu 1 at 238.028496s: [ 238.082761][ T318] kasan_save_stack (mm/kasan/common.c:58) [ 238.083481][ T318] kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5)) [ 238.085348][ T318] kasan_save_free_info (mm/kasan/generic.c:587 (discriminator 1)) [ 238.085900][ T318] __kasan_slab_free (mm/kasan/common.c:287) [ 238.086439][ T318] kmem_cache_free (mm/slub.c:6168 (discriminator 3) mm/slub.c:6298 (discriminator 3)) [ 238.087007][ T318] skb_release_data (net/core/skbuff.c:1139) [ 238.087491][ T318] consume_skb (net/core/skbuff.c:1451) [ 238.087757][ T318] teql_master_xmit (net/sched/sch_teql.c:358) [ 238.088116][ T318] dev_hard_start_xmit (./include/linux/netdevice.h:5324 ./include/linux/netdevice.h:5333 net/core/dev.c:3871 net/core/dev.c:3887) [ 238.088468][ T318] sch_direct_xmit (net/sched/sch_generic.c:347) [ 238.088820][ T318] __qdisc_run (net/sched/sch_generic.c:420 (discriminator 1)) [ 238.089166][ T318] __dev_queue_xmit (./include/net/sch_generic.h:229 ./include/net/pkt_sched.h:121 ./include/net/pkt_sched.h:117 net/core/dev.c:4196 net/core/dev.c:4802) Workflow to reproduce: 1. Initialize a TEQL topology (dummy0 and ifb0 as slaves, teql0 up). 2. Start multiple sender workers continuously transmitting packets through teql0 to drive teql_master_xmit(). 3. In parallel, repeatedly delete and re-add the root qdisc on dummy0 and ifb0 via RTNETLINK, forcing frequent teardown and reset activity (teql_destroy() / qdisc_reset()). 4. After running both workloads concurrently for several iterations, KASAN reports slab-use-after-free or double-free in the skb free path. Fix this by moving dev_reset_queue to sch_generic.h and calling it, instead of qdisc_reset, in teql_destroy since it handles both the lock and lockless cases correctly for root qdiscs. Fixes: 96009c7d500e ("sched: replace __QDISC_STATE_RUNNING bit with a spin lock") Reported-by: Xianrui Dong Tested-by: Xianrui Dong Co-developed-by: Victor Nogueira Signed-off-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260315155422.147256-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fd7579f0a2c84ba8a7d4f206201b50dc8ddf90c2 Author: Jiayuan Chen Date: Thu Mar 12 17:29:07 2026 +0800 net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock() [ Upstream commit 6d5e4538364b9ceb1ac2941a4deb86650afb3538 ] Syzkaller reported a panic in smc_tcp_syn_recv_sock() [1]. smc_tcp_syn_recv_sock() is called in the TCP receive path (softirq) via icsk_af_ops->syn_recv_sock on the clcsock (TCP listening socket). It reads sk_user_data to get the smc_sock pointer. However, when the SMC listen socket is being closed concurrently, smc_close_active() sets clcsock->sk_user_data to NULL under sk_callback_lock, and then the smc_sock itself can be freed via sock_put() in smc_release(). This leads to two issues: 1) NULL pointer dereference: sk_user_data is NULL when accessed. 2) Use-after-free: sk_user_data is read as non-NULL, but the smc_sock is freed before its fields (e.g., queued_smc_hs, ori_af_ops) are accessed. The race window looks like this (the syzkaller crash [1] triggers via the SYN cookie path: tcp_get_cookie_sock() -> smc_tcp_syn_recv_sock(), but the normal tcp_check_req() path has the same race): CPU A (softirq) CPU B (process ctx) tcp_v4_rcv() TCP_NEW_SYN_RECV: sk = req->rsk_listener sock_hold(sk) /* No lock on listener */ smc_close_active(): write_lock_bh(cb_lock) sk_user_data = NULL write_unlock_bh(cb_lock) ... smc_clcsock_release() sock_put(smc->sk) x2 -> smc_sock freed! tcp_check_req() smc_tcp_syn_recv_sock(): smc = user_data(sk) -> NULL or dangling smc->queued_smc_hs -> crash! Note that the clcsock and smc_sock are two independent objects with separate refcounts. TCP stack holds a reference on the clcsock, which keeps it alive, but this does NOT prevent the smc_sock from being freed. Fix this by using RCU and refcount_inc_not_zero() to safely access smc_sock. Since smc_tcp_syn_recv_sock() is called in the TCP three-way handshake path, taking read_lock_bh on sk_callback_lock is too heavy and would not survive a SYN flood attack. Using rcu_read_lock() is much more lightweight. - Set SOCK_RCU_FREE on the SMC listen socket so that smc_sock freeing is deferred until after the RCU grace period. This guarantees the memory is still valid when accessed inside rcu_read_lock(). - Use rcu_read_lock() to protect reading sk_user_data. - Use refcount_inc_not_zero(&smc->sk.sk_refcnt) to pin the smc_sock. If the refcount has already reached zero (close path completed), it returns false and we bail out safely. Note: smc_hs_congested() has a similar lockless read of sk_user_data without rcu_read_lock(), but it only checks for NULL and accesses the global smc_hs_wq, never dereferencing any smc_sock field, so it is not affected. Reproducer was verified with mdelay injection and smc_run, the issue no longer occurs with this patch applied. [1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9 Fixes: 8270d9c21041 ("net/smc: Limit backlog connections") Reported-by: syzbot+827ae2bfb3a3529333e9@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/67eaf9b8.050a0220.3c3d88.004a.GAE@google.com/T/ Suggested-by: Eric Dumazet Reviewed-by: Eric Dumazet Signed-off-by: Jiayuan Chen Link: https://patch.msgid.link/20260312092909.48325-1-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4172a7901cf43fe1cc63ef7a2ef33735ff7b7d13 Author: Eric Dumazet Date: Sun Mar 15 10:41:52 2026 +0000 bonding: prevent potential infinite loop in bond_header_parse() [ Upstream commit b7405dcf7385445e10821777143f18c3ce20fa04 ] bond_header_parse() can loop if a stack of two bonding devices is setup, because skb->dev always points to the hierarchy top. Add new "const struct net_device *dev" parameter to (struct header_ops)->parse() method to make sure the recursion is bounded, and that the final leaf parse method is called. Fixes: 950803f72547 ("bonding: fix type confusion in bond_setup_by_slave()") Signed-off-by: Eric Dumazet Reviewed-by: Jiayuan Chen Tested-by: Jiayuan Chen Cc: Jay Vosburgh Cc: Andrew Lunn Link: https://patch.msgid.link/20260315104152.1436867-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bb081fd37f8312651140d7429557258afe51693d Author: Bart Van Assche Date: Thu Mar 12 11:27:20 2026 -0700 PM: runtime: Fix a race condition related to device removal [ Upstream commit 29ab768277617452d88c0607c9299cdc63b6e9ff ] The following code in pm_runtime_work() may dereference the dev->parent pointer after the parent device has been freed: /* Maybe the parent is now able to suspend. */ if (parent && !parent->power.ignore_children) { spin_unlock(&dev->power.lock); spin_lock(&parent->power.lock); rpm_idle(parent, RPM_ASYNC); spin_unlock(&parent->power.lock); spin_lock(&dev->power.lock); } Fix this by inserting a flush_work() call in pm_runtime_remove(). Without this patch blktest block/001 triggers the following complaint sporadically: BUG: KASAN: slab-use-after-free in lock_acquire+0x70/0x160 Read of size 1 at addr ffff88812bef7198 by task kworker/u553:1/3081 Workqueue: pm pm_runtime_work Call Trace: dump_stack_lvl+0x61/0x80 print_address_description.constprop.0+0x8b/0x310 print_report+0xfd/0x1d7 kasan_report+0xd8/0x1d0 __kasan_check_byte+0x42/0x60 lock_acquire.part.0+0x38/0x230 lock_acquire+0x70/0x160 _raw_spin_lock+0x36/0x50 rpm_suspend+0xc6a/0xfe0 rpm_idle+0x578/0x770 pm_runtime_work+0xee/0x120 process_one_work+0xde3/0x1410 worker_thread+0x5eb/0xfe0 kthread+0x37b/0x480 ret_from_fork+0x6cb/0x920 ret_from_fork_asm+0x11/0x20 Allocated by task 4314: kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_alloc_info+0x3d/0x50 __kasan_kmalloc+0xa0/0xb0 __kmalloc_noprof+0x311/0x990 scsi_alloc_target+0x122/0xb60 [scsi_mod] __scsi_scan_target+0x101/0x460 [scsi_mod] scsi_scan_channel+0x179/0x1c0 [scsi_mod] scsi_scan_host_selected+0x259/0x2d0 [scsi_mod] store_scan+0x2d2/0x390 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506/0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810 do_syscall_64+0xee/0xfc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4314: kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_free_info+0x3f/0x50 __kasan_slab_free+0x67/0x80 kfree+0x225/0x6c0 scsi_target_dev_release+0x3d/0x60 [scsi_mod] device_release+0xa3/0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_dev_release+0xacf/0x12c0 [scsi_mod] device_release+0xa3/0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_put+0x7f/0xc0 [scsi_mod] sdev_store_delete+0xa5/0x120 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506/0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810 Reported-by: Ming Lei Closes: https://lore.kernel.org/all/ZxdNvLNI8QaOfD2d@fedora/ Reported-by: syzbot+6c905ab800f20cf4086c@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68c13942.050a0220.2ff435.000b.GAE@google.com/ Fixes: 5e928f77a09a ("PM: Introduce core framework for run-time PM of I/O devices (rev. 17)") Signed-off-by: Bart Van Assche Link: https://patch.msgid.link/20260312182720.2776083-1-bvanassche@acm.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 34c979e29bf680b70ed633a3c2eadac34348eb0e Author: Rafael J. Wysocki Date: Fri Mar 13 13:25:41 2026 +0100 sched: idle: Consolidate the handling of two special cases [ Upstream commit f4c31b07b136839e0fb3026f8a5b6543e3b14d2f ] There are two special cases in the idle loop that are handled inconsistently even though they are analogous. The first one is when a cpuidle driver is absent and the default CPU idle time power management implemented by the architecture code is used. In that case, the scheduler tick is stopped every time before invoking default_idle_call(). The second one is when a cpuidle driver is present, but there is only one idle state in its table. In that case, the scheduler tick is never stopped at all. Since each of these approaches has its drawbacks, reconcile them with the help of one simple heuristic. Namely, stop the tick if the CPU has been woken up by it in the previous iteration of the idle loop, or let it tick otherwise. Signed-off-by: Rafael J. Wysocki Reviewed-by: Christian Loehle Reviewed-by: Frederic Weisbecker Reviewed-by: Qais Yousef Reviewed-by: Aboorva Devarajan Fixes: ed98c3491998 ("sched: idle: Do not stop the tick before cpuidle_idle_call()") [ rjw: Added Fixes tag, changelog edits ] Link: https://patch.msgid.link/4741364.LvFx2qVVIh@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit afdb1533eb9c05432aeb793a7280fa827c502f5c Author: Dipayaan Roy Date: Wed Mar 11 12:22:04 2026 -0700 net: mana: fix use-after-free in mana_hwc_destroy_channel() by reordering teardown [ Upstream commit fa103fc8f56954a60699a29215cb713448a39e87 ] A potential race condition exists in mana_hwc_destroy_channel() where hwc->caller_ctx is freed before the HWC's Completion Queue (CQ) and Event Queue (EQ) are destroyed. This allows an in-flight CQ interrupt handler to dereference freed memory, leading to a use-after-free or NULL pointer dereference in mana_hwc_handle_resp(). mana_smc_teardown_hwc() signals the hardware to stop but does not synchronize against IRQ handlers already executing on other CPUs. The IRQ synchronization only happens in mana_hwc_destroy_cq() via mana_gd_destroy_eq() -> mana_gd_deregister_irq(). Since this runs after kfree(hwc->caller_ctx), a concurrent mana_hwc_rx_event_handler() can dereference freed caller_ctx (and rxq->msg_buf) in mana_hwc_handle_resp(). Fix this by reordering teardown to reverse-of-creation order: destroy the TX/RX work queues and CQ/EQ before freeing hwc->caller_ctx. This ensures all in-flight interrupt handlers complete before the memory they access is freed. Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Reviewed-by: Haiyang Zhang Signed-off-by: Dipayaan Roy Reviewed-by: Simon Horman Link: https://patch.msgid.link/abHA3AjNtqa1nx9k@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6995dcc1a93de0a8b533bf15897210bc3910b5b4 Author: Justin Chen Date: Thu Mar 12 12:18:52 2026 -0700 net: bcmgenet: increase WoL poll timeout [ Upstream commit 6cfc3bc02b977f2fba5f7268e6504d1931a774f7 ] Some systems require more than 5ms to get into WoL mode. Increase the timeout value to 50ms. Fixes: c51de7f3976b ("net: bcmgenet: add Wake-on-LAN support code") Signed-off-by: Justin Chen Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260312191852.3904571-1-justin.chen@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 683be1d1670e9bc408f164bcde8317376956b714 Author: Guenter Roeck Date: Wed Mar 4 12:39:34 2026 -0800 crypto: ccp - Fix leaking the same page twice [ Upstream commit 5c52607c43c397b79a9852ce33fc61de58c3645c ] Commit 551120148b67 ("crypto: ccp - Fix a case where SNP_SHUTDOWN is missed") fixed a case where SNP is left in INIT state if page reclaim fails. It removes the transition to the INIT state for this command and adjusts the page state management. While doing this, it added a call to snp_leak_pages() after a call to snp_reclaim_pages() failed. Since snp_reclaim_pages() already calls snp_leak_pages() internally on the pages it fails to reclaim, calling it again leaks the exact same page twice. Fix by removing the extra call to snp_leak_pages(). The problem was found by an experimental code review agent based on gemini-3.1-pro while reviewing backports into v6.18.y. Assisted-by: Gemini:gemini-3.1-pro Fixes: 551120148b67 ("crypto: ccp - Fix a case where SNP_SHUTDOWN is missed") Cc: Tycho Andersen (AMD) Cc: Tom Lendacky Signed-off-by: Guenter Roeck Reviewed-by: Tom Lendacky Reviewed-by: Tycho Andersen (AMD) Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9d00fe7d6d7c5b5f1065a6e042b54f2e44bd6df8 Author: Jenny Guanni Qu Date: Thu Mar 12 14:49:50 2026 +0000 netfilter: nf_conntrack_h323: check for zero length in DecodeQ931() [ Upstream commit f173d0f4c0f689173f8cdac79991043a4a89bf66 ] In DecodeQ931(), the UserUserIE code path reads a 16-bit length from the packet, then decrements it by 1 to skip the protocol discriminator byte before passing it to DecodeH323_UserInformation(). If the encoded length is 0, the decrement wraps to -1, which is then passed as a large value to the decoder, leading to an out-of-bounds read. Add a check to ensure len is positive after the decrement. Fixes: 5e35941d9901 ("[NETFILTER]: Add H.323 conntrack/NAT helper") Reported-by: Klaudia Kloc Reported-by: Dawid Moczadło Tested-by: Jenny Guanni Qu Signed-off-by: Jenny Guanni Qu Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit f1aa81396d779711e8488be88efcd1f5684124d6 Author: Jenny Guanni Qu Date: Thu Mar 12 14:59:49 2026 +0000 netfilter: xt_time: use unsigned int for monthday bit shift [ Upstream commit 00050ec08cecfda447e1209b388086d76addda3a ] The monthday field can be up to 31, and shifting a signed integer 1 by 31 positions (1 << 31) is undefined behavior in C, as the result overflows a 32-bit signed int. Use 1U to ensure well-defined behavior for all valid monthday values. Change the weekday shift to 1U as well for consistency. Fixes: ee4411a1b1e0 ("[NETFILTER]: x_tables: add xt_time match") Reported-by: Klaudia Kloc Reported-by: Dawid Moczadło Tested-by: Jenny Guanni Qu Signed-off-by: Jenny Guanni Qu Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit cb549925875fa06dd155e49db4ac2c5044c30f9c Author: Pablo Neira Ayuso Date: Thu Mar 12 13:48:48 2026 +0100 netfilter: xt_CT: drop pending enqueued packets on template removal [ Upstream commit f62a218a946b19bb59abdd5361da85fa4606b96b ] Templates refer to objects that can go away while packets are sitting in nfqueue refer to: - helper, this can be an issue on module removal. - timeout policy, nfnetlink_cttimeout might remove it. The use of templates with zone and event cache filter are safe, since this just copies values. Flush these enqueued packets in case the template rule gets removed. Fixes: 24de58f46516 ("netfilter: xt_CT: allow to attach timeout policy + glue code") Reported-by: Yiming Qian Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit f29a055e4f593e577805b41228b142b58f48df1b Author: Pablo Neira Ayuso Date: Thu Mar 12 13:48:47 2026 +0100 netfilter: nft_ct: drop pending enqueued packets on removal [ Upstream commit 36eae0956f659e48d5366d9b083d9417f3263ddc ] Packets sitting in nfqueue might hold a reference to: - templates that specify the conntrack zone, because a percpu area is used and module removal is possible. - conntrack timeout policies and helper, where object removal leave a stale reference. Since these objects can just go away, drop enqueued packets to avoid stale reference to them. If there is a need for finer grain removal, this logic can be revisited to make selective packet drop upon dependencies. Fixes: 7e0b2b57f01d ("netfilter: nft_ct: add ct timeout support") Reported-by: Yiming Qian Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 31641c682db73353e4647e40735c7f2a75ff58ef Author: Pablo Neira Ayuso Date: Thu Mar 12 12:38:59 2026 +0100 nf_tables: nft_dynset: fix possible stateful expression memleak in error path [ Upstream commit 0548a13b5a145b16e4da0628b5936baf35f51b43 ] If cloning the second stateful expression in the element via GFP_ATOMIC fails, then the first stateful expression remains in place without being released.   unreferenced object (percpu) 0x607b97e9cab8 (size 16):     comm "softirq", pid 0, jiffies 4294931867     hex dump (first 16 bytes on cpu 3):       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     backtrace (crc 0):       pcpu_alloc_noprof+0x453/0xd80       nft_counter_clone+0x9c/0x190 [nf_tables]       nft_expr_clone+0x8f/0x1b0 [nf_tables]       nft_dynset_new+0x2cb/0x5f0 [nf_tables]       nft_rhash_update+0x236/0x11c0 [nf_tables]       nft_dynset_eval+0x11f/0x670 [nf_tables]       nft_do_chain+0x253/0x1700 [nf_tables]       nft_do_chain_ipv4+0x18d/0x270 [nf_tables]       nf_hook_slow+0xaa/0x1e0       ip_local_deliver+0x209/0x330 Fixes: 563125a73ac3 ("netfilter: nftables: generalize set extension to support for several expressions") Reported-by: Gurpreet Shergill Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 6bce72daeccca9aa1746e92d6c3d4784e71f2ebb Author: Jenny Guanni Qu Date: Thu Mar 12 02:29:32 2026 +0000 netfilter: nf_conntrack_h323: fix OOB read in decode_int() CONS case [ Upstream commit 1e3a3593162c96e8a8de48b1e14f60c3b57fca8a ] In decode_int(), the CONS case calls get_bits(bs, 2) to read a length value, then calls get_uint(bs, len) without checking that len bytes remain in the buffer. The existing boundary check only validates the 2 bits for get_bits(), not the subsequent 1-4 bytes that get_uint() reads. This allows a malformed H.323/RAS packet to cause a 1-4 byte slab-out-of-bounds read. Add a boundary check for len bytes after get_bits() and before get_uint(). Fixes: 5e35941d9901 ("[NETFILTER]: Add H.323 conntrack/NAT helper") Reported-by: Klaudia Kloc Reported-by: Dawid Moczadło Signed-off-by: Jenny Guanni Qu Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 865dba58958c3a86786f89a501971ab0e3ec6ba9 Author: Lukas Johannes Möller Date: Tue Mar 10 21:49:01 2026 +0000 netfilter: nf_conntrack_sip: fix Content-Length u32 truncation in sip_help_tcp() [ Upstream commit fbce58e719a17aa215c724473fd5baaa4a8dc57c ] sip_help_tcp() parses the SIP Content-Length header with simple_strtoul(), which returns unsigned long, but stores the result in unsigned int clen. On 64-bit systems, values exceeding UINT_MAX are silently truncated before computing the SIP message boundary. For example, Content-Length 4294967328 (2^32 + 32) is truncated to 32, causing the parser to miscalculate where the current message ends. The loop then treats trailing data in the TCP segment as a second SIP message and processes it through the SDP parser. Fix this by changing clen to unsigned long to match the return type of simple_strtoul(), and reject Content-Length values that exceed the remaining TCP payload length. Fixes: f5b321bd37fb ("netfilter: nf_conntrack_sip: add TCP support") Signed-off-by: Lukas Johannes Möller Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 04c8907ce4e3d3e26c5e1a3e47aa5d17082cbb56 Author: Hyunwoo Kim Date: Sun Mar 8 02:21:37 2026 +0900 netfilter: ctnetlink: fix use-after-free in ctnetlink_dump_exp_ct() [ Upstream commit 5cb81eeda909dbb2def209dd10636b51549a3f8a ] ctnetlink_dump_exp_ct() stores a conntrack pointer in cb->data for the netlink dump callback ctnetlink_exp_ct_dump_table(), but drops the conntrack reference immediately after netlink_dump_start(). When the dump spans multiple rounds, the second recvmsg() triggers the dump callback which dereferences the now-freed conntrack via nfct_help(ct), leading to a use-after-free on ct->ext. The bug is that the netlink_dump_control has no .start or .done callbacks to manage the conntrack reference across dump rounds. Other dump functions in the same file (e.g. ctnetlink_get_conntrack) properly use .start/.done callbacks for this purpose. Fix this by adding .start and .done callbacks that hold and release the conntrack reference for the duration of the dump, and move the nfct_help() call after the cb->args[0] early-return check in the dump callback to avoid dereferencing ct->ext unnecessarily. BUG: KASAN: slab-use-after-free in ctnetlink_exp_ct_dump_table+0x4f/0x2e0 Read of size 8 at addr ffff88810597ebf0 by task ctnetlink_poc/133 CPU: 1 UID: 0 PID: 133 Comm: ctnetlink_poc Not tainted 7.0.0-rc2+ #3 PREEMPTLAZY Call Trace: ctnetlink_exp_ct_dump_table+0x4f/0x2e0 netlink_dump+0x333/0x880 netlink_recvmsg+0x3e2/0x4b0 ? aa_sk_perm+0x184/0x450 sock_recvmsg+0xde/0xf0 Allocated by task 133: kmem_cache_alloc_noprof+0x134/0x440 __nf_conntrack_alloc+0xa8/0x2b0 ctnetlink_create_conntrack+0xa1/0x900 ctnetlink_new_conntrack+0x3cf/0x7d0 nfnetlink_rcv_msg+0x48e/0x510 netlink_rcv_skb+0xc9/0x1f0 nfnetlink_rcv+0xdb/0x220 netlink_unicast+0x3ec/0x590 netlink_sendmsg+0x397/0x690 __sys_sendmsg+0xf4/0x180 Freed by task 0: slab_free_after_rcu_debug+0xad/0x1e0 rcu_core+0x5c3/0x9c0 Fixes: e844a928431f ("netfilter: ctnetlink: allow to dump expectation per master conntrack") Signed-off-by: Hyunwoo Kim Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit e01a597707c8879f6f4ebbac3a41c4930e9a6823 Author: Sabrina Dubroca Date: Wed Mar 11 23:35:09 2026 +0100 mpls: add missing unregister_netdevice_notifier to mpls_init [ Upstream commit 99600f79b28c83c68bae199a3d8e95049a758308 ] If mpls_init() fails after registering mpls_dev_notifier, it never gets removed. Add the missing unregister_netdevice_notifier() call to the error handling path. Fixes: 5be2062e3080 ("mpls: Handle error of rtnl_register_module().") Signed-off-by: Sabrina Dubroca Link: https://patch.msgid.link/7c55363c4f743d19e2306204a134407c90a69bbb.1773228081.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0c3e8bff808f17ad37a51d8e719eed22c7863120 Author: Jiayuan Chen Date: Wed Mar 11 15:06:02 2026 +0800 net/rose: fix NULL pointer dereference in rose_transmit_link on reconnect [ Upstream commit e1f0a18c9564cdb16523c802e2c6fe5874e3d944 ] syzkaller reported a bug [1], and the reproducer is available at [2]. ROSE sockets use four sk->sk_state values: TCP_CLOSE, TCP_LISTEN, TCP_SYN_SENT, and TCP_ESTABLISHED. rose_connect() already rejects calls for TCP_ESTABLISHED (-EISCONN) and TCP_CLOSE with SS_CONNECTING (-ECONNREFUSED), but lacks a check for TCP_SYN_SENT. When rose_connect() is called a second time while the first connection attempt is still in progress (TCP_SYN_SENT), it overwrites rose->neighbour via rose_get_neigh(). If that returns NULL, the socket is left with rose->state == ROSE_STATE_1 but rose->neighbour == NULL. When the socket is subsequently closed, rose_release() sees ROSE_STATE_1 and calls rose_write_internal() -> rose_transmit_link(skb, NULL), causing a NULL pointer dereference. Per connect(2), a second connect() while a connection is already in progress should return -EALREADY. Add this missing check for TCP_SYN_SENT to complete the state validation in rose_connect(). [1] https://syzkaller.appspot.com/bug?extid=d00f90e0af54102fb271 [2] https://gist.github.com/mrpre/9e6779e0d13e2c66779b1653fef80516 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+d00f90e0af54102fb271@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/69694d6f.050a0220.58bed.0027.GAE@google.com/T/ Suggested-by: Eric Dumazet Signed-off-by: Jiayuan Chen Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260311070611.76913-1-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d8f35767bacb3c7769d470a41cf161e3f3c07e70 Author: Hyunwoo Kim Date: Wed Mar 11 03:18:09 2026 +0900 bridge: cfm: Fix race condition in peer_mep deletion [ Upstream commit 3715a00855316066cdda69d43648336367422127 ] When a peer MEP is being deleted, cancel_delayed_work_sync() is called on ccm_rx_dwork before freeing. However, br_cfm_frame_rx() runs in softirq context under rcu_read_lock (without RTNL) and can re-schedule ccm_rx_dwork via ccm_rx_timer_start() between cancel_delayed_work_sync() returning and kfree_rcu() being called. The following is a simple race scenario: cpu0 cpu1 mep_delete_implementation() cancel_delayed_work_sync(ccm_rx_dwork); br_cfm_frame_rx() // peer_mep still in hlist if (peer_mep->ccm_defect) ccm_rx_timer_start() queue_delayed_work(ccm_rx_dwork) hlist_del_rcu(&peer_mep->head); kfree_rcu(peer_mep, rcu); ccm_rx_work_expired() // on freed peer_mep To prevent this, cancel_delayed_work_sync() is replaced with disable_delayed_work_sync() in both peer MEP deletion paths, so that subsequent queue_delayed_work() calls from br_cfm_frame_rx() are silently rejected. The cc_peer_disable() helper retains cancel_delayed_work_sync() because it is also used for the CC enable/disable toggle path where the work must remain re-schedulable. Fixes: dc32cbb3dbd7 ("bridge: cfm: Kernel space implementation of CFM. CCM frame RX added.") Signed-off-by: Hyunwoo Kim Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/abBgYT5K_FI9rD1a@v4bel Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1e1b7a7496a2e57b7ca7aaaea7f1b33f7ac7cb39 Author: Dmitry Baryshkov Date: Wed Mar 11 01:02:57 2026 +0200 Bluetooth: qca: fix ROM version reading on WCN3998 chips [ Upstream commit 99b2c531e0e797119ae1b9195a8764ee98b00e65 ] WCN3998 uses a bit different format for rom version: [ 5.479978] Bluetooth: hci0: setting up wcn399x [ 5.633763] Bluetooth: hci0: QCA Product ID :0x0000000a [ 5.645350] Bluetooth: hci0: QCA SOC Version :0x40010224 [ 5.650906] Bluetooth: hci0: QCA ROM Version :0x00001001 [ 5.665173] Bluetooth: hci0: QCA Patch Version:0x00006699 [ 5.679356] Bluetooth: hci0: QCA controller version 0x02241001 [ 5.691109] Bluetooth: hci0: QCA Downloading qca/crbtfw21.tlv [ 6.680102] Bluetooth: hci0: QCA Downloading qca/crnv21.bin [ 6.842948] Bluetooth: hci0: QCA setup on UART is completed Fixes: 523760b7ff88 ("Bluetooth: hci_qca: Added support for WCN3998") Reviewed-by: Bartosz Golaszewski Signed-off-by: Dmitry Baryshkov Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit da3000cbe4851458a22be38bb18c0689c39fdd5f Author: Shaurya Rane Date: Thu Nov 6 23:50:16 2025 +0530 Bluetooth: L2CAP: Fix use-after-free in l2cap_unregister_user [ Upstream commit 752a6c9596dd25efd6978a73ff21f3b592668f4a ] After commit ab4eedb790ca ("Bluetooth: L2CAP: Fix corrupted list in hci_chan_del"), l2cap_conn_del() uses conn->lock to protect access to conn->users. However, l2cap_register_user() and l2cap_unregister_user() don't use conn->lock, creating a race condition where these functions can access conn->users and conn->hchan concurrently with l2cap_conn_del(). This can lead to use-after-free and list corruption bugs, as reported by syzbot. Fix this by changing l2cap_register_user() and l2cap_unregister_user() to use conn->lock instead of hci_dev_lock(), ensuring consistent locking for the l2cap_conn structure. Reported-by: syzbot+14b6d57fb728e27ce23c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=14b6d57fb728e27ce23c Fixes: ab4eedb790ca ("Bluetooth: L2CAP: Fix corrupted list in hci_chan_del") Signed-off-by: Shaurya Rane Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit f8b6ed2f06d3baa44f347a0fa2af52433f386463 Author: Luiz Augusto von Dentz Date: Thu Mar 5 10:17:47 2026 -0500 Bluetooth: HIDP: Fix possible UAF [ Upstream commit dbf666e4fc9bdd975a61bf682b3f75cb0145eedd ] This fixes the following trace caused by not dropping l2cap_conn reference when user->remove callback is called: [ 97.809249] l2cap_conn_free: freeing conn ffff88810a171c00 [ 97.809907] CPU: 1 UID: 0 PID: 1419 Comm: repro_standalon Not tainted 7.0.0-rc1-dirty #14 PREEMPT(lazy) [ 97.809935] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 97.809947] Call Trace: [ 97.809954] [ 97.809961] dump_stack_lvl (lib/dump_stack.c:122) [ 97.809990] l2cap_conn_free (net/bluetooth/l2cap_core.c:1808) [ 97.810017] l2cap_conn_del (./include/linux/kref.h:66 net/bluetooth/l2cap_core.c:1821 net/bluetooth/l2cap_core.c:1798) [ 97.810055] l2cap_disconn_cfm (net/bluetooth/l2cap_core.c:7347 (discriminator 1) net/bluetooth/l2cap_core.c:7340 (discriminator 1)) [ 97.810086] ? __pfx_l2cap_disconn_cfm (net/bluetooth/l2cap_core.c:7341) [ 97.810117] hci_conn_hash_flush (./include/net/bluetooth/hci_core.h:2152 (discriminator 2) net/bluetooth/hci_conn.c:2644 (discriminator 2)) [ 97.810148] hci_dev_close_sync (net/bluetooth/hci_sync.c:5360) [ 97.810180] ? __pfx_hci_dev_close_sync (net/bluetooth/hci_sync.c:5285) [ 97.810212] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810242] ? up_write (./arch/x86/include/asm/atomic64_64.h:87 (discriminator 5) ./include/linux/atomic/atomic-arch-fallback.h:2852 (discriminator 5) ./include/linux/atomic/atomic-long.h:268 (discriminator 5) ./include/linux/atomic/atomic-instrumented.h:3391 (discriminator 5) kernel/locking/rwsem.c:1385 (discriminator 5) kernel/locking/rwsem.c:1643 (discriminator 5)) [ 97.810267] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810290] ? rcu_is_watching (./arch/x86/include/asm/atomic.h:23 ./include/linux/atomic/atomic-arch-fallback.h:457 ./include/linux/context_tracking.h:128 kernel/rcu/tree.c:752) [ 97.810320] hci_unregister_dev (net/bluetooth/hci_core.c:504 net/bluetooth/hci_core.c:2716) [ 97.810346] vhci_release (drivers/bluetooth/hci_vhci.c:691) [ 97.810375] ? __pfx_vhci_release (drivers/bluetooth/hci_vhci.c:678) [ 97.810404] __fput (fs/file_table.c:470) [ 97.810430] task_work_run (kernel/task_work.c:235) [ 97.810451] ? __pfx_task_work_run (kernel/task_work.c:201) [ 97.810472] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810495] ? do_raw_spin_unlock (./include/asm-generic/qspinlock.h:128 (discriminator 5) kernel/locking/spinlock_debug.c:142 (discriminator 5)) [ 97.810527] do_exit (kernel/exit.c:972) [ 97.810547] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810574] ? __pfx_do_exit (kernel/exit.c:897) [ 97.810594] ? lock_acquire (kernel/locking/lockdep.c:470 (discriminator 6) kernel/locking/lockdep.c:5870 (discriminator 6) kernel/locking/lockdep.c:5825 (discriminator 6)) [ 97.810616] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810639] ? do_raw_spin_lock (kernel/locking/spinlock_debug.c:95 (discriminator 4) kernel/locking/spinlock_debug.c:118 (discriminator 4)) [ 97.810664] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810688] ? find_held_lock (kernel/locking/lockdep.c:5350 (discriminator 1)) [ 97.810721] do_group_exit (kernel/exit.c:1093) [ 97.810745] get_signal (kernel/signal.c:3007 (discriminator 1)) [ 97.810772] ? security_file_permission (./arch/x86/include/asm/jump_label.h:37 security/security.c:2366) [ 97.810803] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810826] ? vfs_read (fs/read_write.c:555) [ 97.810854] ? __pfx_get_signal (kernel/signal.c:2800) [ 97.810880] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810905] ? __pfx_vfs_read (fs/read_write.c:555) [ 97.810932] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.810960] arch_do_signal_or_restart (arch/x86/kernel/signal.c:337 (discriminator 1)) [ 97.810990] ? __pfx_arch_do_signal_or_restart (arch/x86/kernel/signal.c:334) [ 97.811021] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.811055] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.811078] ? ksys_read (fs/read_write.c:707) [ 97.811106] ? __pfx_ksys_read (fs/read_write.c:707) [ 97.811137] exit_to_user_mode_loop (kernel/entry/common.c:66 kernel/entry/common.c:98) [ 97.811169] ? rcu_is_watching (./arch/x86/include/asm/atomic.h:23 ./include/linux/atomic/atomic-arch-fallback.h:457 ./include/linux/context_tracking.h:128 kernel/rcu/tree.c:752) [ 97.811192] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.811215] ? trace_hardirqs_off (./include/trace/events/preemptirq.h:36 (discriminator 33) kernel/trace/trace_preemptirq.c:95 (discriminator 33) kernel/trace/trace_preemptirq.c:90 (discriminator 33)) [ 97.811240] do_syscall_64 (./include/linux/irq-entry-common.h:226 ./include/linux/irq-entry-common.h:256 ./include/linux/entry-common.h:325 arch/x86/entry/syscall_64.c:100) [ 97.811268] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 97.811292] ? exc_page_fault (arch/x86/mm/fault.c:1480 (discriminator 3) arch/x86/mm/fault.c:1527 (discriminator 3)) [ 97.811318] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) [ 97.811338] RIP: 0033:0x445cfe [ 97.811352] Code: Unable to access opcode bytes at 0x445cd4. Code starting with the faulting instruction =========================================== [ 97.811360] RSP: 002b:00007f65c41c6dc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 97.811378] RAX: fffffffffffffe00 RBX: 00007f65c41c76c0 RCX: 0000000000445cfe [ 97.811391] RDX: 0000000000000400 RSI: 00007f65c41c6e40 RDI: 0000000000000004 [ 97.811403] RBP: 00007f65c41c7250 R08: 0000000000000000 R09: 0000000000000000 [ 97.811415] R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffffe8 [ 97.811428] R13: 0000000000000000 R14: 00007fff780a8c00 R15: 00007f65c41c76c0 [ 97.811453] [ 98.402453] ================================================================== [ 98.403560] BUG: KASAN: use-after-free in __mutex_lock (kernel/locking/mutex.c:199 kernel/locking/mutex.c:694 kernel/locking/mutex.c:776) [ 98.404541] Read of size 8 at addr ffff888113ee40a8 by task khidpd_00050004/1430 [ 98.405361] [ 98.405563] CPU: 1 UID: 0 PID: 1430 Comm: khidpd_00050004 Not tainted 7.0.0-rc1-dirty #14 PREEMPT(lazy) [ 98.405588] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 98.405600] Call Trace: [ 98.405607] [ 98.405614] dump_stack_lvl (lib/dump_stack.c:122) [ 98.405641] print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) [ 98.405667] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 98.405691] ? __virt_addr_valid (arch/x86/mm/physaddr.c:55) [ 98.405724] ? __mutex_lock (kernel/locking/mutex.c:199 kernel/locking/mutex.c:694 kernel/locking/mutex.c:776) [ 98.405748] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:597) [ 98.405778] ? __mutex_lock (kernel/locking/mutex.c:199 kernel/locking/mutex.c:694 kernel/locking/mutex.c:776) [ 98.405807] __mutex_lock (kernel/locking/mutex.c:199 kernel/locking/mutex.c:694 kernel/locking/mutex.c:776) [ 98.405832] ? do_raw_spin_lock (kernel/locking/spinlock_debug.c:95 (discriminator 4) kernel/locking/spinlock_debug.c:118 (discriminator 4)) [ 98.405859] ? l2cap_unregister_user (./include/linux/list.h:381 (discriminator 2) net/bluetooth/l2cap_core.c:1723 (discriminator 2)) [ 98.405888] ? __pfx_do_raw_spin_lock (kernel/locking/spinlock_debug.c:114) [ 98.405915] ? __pfx___mutex_lock (kernel/locking/mutex.c:775) [ 98.405939] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 98.405963] ? lock_acquire (kernel/locking/lockdep.c:470 (discriminator 6) kernel/locking/lockdep.c:5870 (discriminator 6) kernel/locking/lockdep.c:5825 (discriminator 6)) [ 98.405984] ? find_held_lock (kernel/locking/lockdep.c:5350 (discriminator 1)) [ 98.406015] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 98.406038] ? lock_release (kernel/locking/lockdep.c:5536 kernel/locking/lockdep.c:5889 kernel/locking/lockdep.c:5875) [ 98.406061] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 98.406085] ? _raw_spin_unlock_irqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:119 ./arch/x86/include/asm/irqflags.h:159 ./include/linux/spinlock_api_smp.h:178 kernel/locking/spinlock.c:194) [ 98.406107] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 98.406130] ? __timer_delete_sync (kernel/time/timer.c:1592) [ 98.406158] ? l2cap_unregister_user (./include/linux/list.h:381 (discriminator 2) net/bluetooth/l2cap_core.c:1723 (discriminator 2)) [ 98.406186] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 98.406210] l2cap_unregister_user (./include/linux/list.h:381 (discriminator 2) net/bluetooth/l2cap_core.c:1723 (discriminator 2)) [ 98.406263] hidp_session_thread (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 ./include/linux/kref.h:64 net/bluetooth/hidp/core.c:996 net/bluetooth/hidp/core.c:1305) [ 98.406293] ? __pfx_hidp_session_thread (net/bluetooth/hidp/core.c:1264) [ 98.406323] ? kthread (kernel/kthread.c:433) [ 98.406340] ? __pfx_hidp_session_wake_function (net/bluetooth/hidp/core.c:1251) [ 98.406370] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 98.406393] ? find_held_lock (kernel/locking/lockdep.c:5350 (discriminator 1)) [ 98.406424] ? __pfx_hidp_session_wake_function (net/bluetooth/hidp/core.c:1251) [ 98.406453] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 98.406476] ? trace_hardirqs_on (kernel/trace/trace_preemptirq.c:79 (discriminator 1)) [ 98.406499] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 98.406523] ? kthread (kernel/kthread.c:433) [ 98.406539] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 98.406565] ? kthread (kernel/kthread.c:433) [ 98.406581] ? __pfx_hidp_session_thread (net/bluetooth/hidp/core.c:1264) [ 98.406610] kthread (kernel/kthread.c:467) [ 98.406627] ? __pfx_kthread (kernel/kthread.c:412) [ 98.406645] ret_from_fork (arch/x86/kernel/process.c:164) [ 98.406674] ? __pfx_ret_from_fork (arch/x86/kernel/process.c:153) [ 98.406704] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 98.406728] ? __pfx_kthread (kernel/kthread.c:412) [ 98.406747] ret_from_fork_asm (arch/x86/entry/entry_64.S:258) [ 98.406774] [ 98.406780] [ 98.433693] The buggy address belongs to the physical page: [ 98.434405] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888113ee7c40 pfn:0x113ee4 [ 98.435557] flags: 0x200000000000000(node=0|zone=2) [ 98.436198] raw: 0200000000000000 ffffea0004244308 ffff8881f6f3ebc0 0000000000000000 [ 98.437195] raw: ffff888113ee7c40 0000000000000000 00000000ffffffff 0000000000000000 [ 98.438115] page dumped because: kasan: bad access detected [ 98.438951] [ 98.439211] Memory state around the buggy address: [ 98.439871] ffff888113ee3f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 98.440714] ffff888113ee4000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 98.441580] >ffff888113ee4080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 98.442458] ^ [ 98.443011] ffff888113ee4100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 98.443889] ffff888113ee4180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 98.444768] ================================================================== [ 98.445719] Disabling lock debugging due to kernel taint [ 98.448074] l2cap_conn_free: freeing conn ffff88810c22b400 [ 98.450012] CPU: 1 UID: 0 PID: 1430 Comm: khidpd_00050004 Tainted: G B 7.0.0-rc1-dirty #14 PREEMPT(lazy) [ 98.450040] Tainted: [B]=BAD_PAGE [ 98.450047] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 98.450059] Call Trace: [ 98.450065] [ 98.450071] dump_stack_lvl (lib/dump_stack.c:122) [ 98.450099] l2cap_conn_free (net/bluetooth/l2cap_core.c:1808) [ 98.450125] l2cap_conn_put (net/bluetooth/l2cap_core.c:1822) [ 98.450154] session_free (net/bluetooth/hidp/core.c:990) [ 98.450181] hidp_session_thread (net/bluetooth/hidp/core.c:1307) [ 98.450213] ? __pfx_hidp_session_thread (net/bluetooth/hidp/core.c:1264) [ 98.450271] ? kthread (kernel/kthread.c:433) [ 98.450293] ? __pfx_hidp_session_wake_function (net/bluetooth/hidp/core.c:1251) [ 98.450339] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 98.450368] ? find_held_lock (kernel/locking/lockdep.c:5350 (discriminator 1)) [ 98.450406] ? __pfx_hidp_session_wake_function (net/bluetooth/hidp/core.c:1251) [ 98.450442] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 98.450471] ? trace_hardirqs_on (kernel/trace/trace_preemptirq.c:79 (discriminator 1)) [ 98.450499] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 98.450528] ? kthread (kernel/kthread.c:433) [ 98.450547] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 98.450578] ? kthread (kernel/kthread.c:433) [ 98.450598] ? __pfx_hidp_session_thread (net/bluetooth/hidp/core.c:1264) [ 98.450637] kthread (kernel/kthread.c:467) [ 98.450657] ? __pfx_kthread (kernel/kthread.c:412) [ 98.450680] ret_from_fork (arch/x86/kernel/process.c:164) [ 98.450715] ? __pfx_ret_from_fork (arch/x86/kernel/process.c:153) [ 98.450752] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 98.450782] ? __pfx_kthread (kernel/kthread.c:412) [ 98.450804] ret_from_fork_asm (arch/x86/entry/entry_64.S:258) [ 98.450836] Fixes: b4f34d8d9d26 ("Bluetooth: hidp: add new session-management helpers") Reported-by: soufiane el hachmi Tested-by: soufiane el hachmi Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit b5c5e96f3b0a5003c3ff98ebb33e59afec51dd77 Author: Wang Tao Date: Fri Feb 27 11:03:39 2026 +0000 Bluetooth: MGMT: Fix list corruption and UAF in command complete handlers [ Upstream commit 17f89341cb4281d1da0e2fb0de5406ab7c4e25ef ] Commit 302a1f674c00 ("Bluetooth: MGMT: Fix possible UAFs") introduced mgmt_pending_valid(), which not only validates the pending command but also unlinks it from the pending list if it is valid. This change in semantics requires updates to several completion handlers to avoid list corruption and memory safety issues. This patch addresses two left-over issues from the aforementioned rework: 1. In mgmt_add_adv_patterns_monitor_complete(), mgmt_pending_remove() is replaced with mgmt_pending_free() in the success path. Since mgmt_pending_valid() already unlinks the command at the beginning of the function, calling mgmt_pending_remove() leads to a double list_del() and subsequent list corruption/kernel panic. 2. In set_mesh_complete(), the use of mgmt_pending_foreach() in the error path is removed. Since the current command is already unlinked by mgmt_pending_valid(), this foreach loop would incorrectly target other pending mesh commands, potentially freeing them while they are still being processed concurrently (leading to UAFs). The redundant mgmt_cmd_status() is also simplified to use cmd->opcode directly. Fixes: 302a1f674c00 ("Bluetooth: MGMT: Fix possible UAFs") Signed-off-by: Wang Tao Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 84d041cfefab578b9511e9f858f1b5d857d1771b Author: Michael Grzeschik Date: Thu Mar 5 14:50:52 2026 +0100 Bluetooth: hci_sync: Fix hci_le_create_conn_sync [ Upstream commit 2cabe7ff1001b7a197009cf50ba71701f9cbd354 ] While introducing hci_le_create_conn_sync the functionality of hci_connect_le was ported to hci_le_create_conn_sync including the disable of the scan before starting the connection. When this code was run non synchronously the immediate call that was setting the flag HCI_LE_SCAN_INTERRUPTED had an impact. Since the completion handler for the LE_SCAN_DISABLE was not immediately called. In the completion handler of the LE_SCAN_DISABLE event, this flag is checked to set the state of the hdev to DISCOVERY_STOPPED. With the synchronised approach the later setting of the HCI_LE_SCAN_INTERRUPTED flag has not the same effect. The completion handler would immediately fire in the LE_SCAN_DISABLE call, check for the flag, which is then not yet set and do nothing. To fix this issue and make the function call work as before, we move the setting of the flag HCI_LE_SCAN_INTERRUPTED before disabling the scan. Fixes: 8e8b92ee60de ("Bluetooth: hci_sync: Add hci_le_create_conn_sync") Signed-off-by: Michael Grzeschik Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 874e73969d48ca1099438f40f331fc3c27c72190 Author: Luiz Augusto von Dentz Date: Fri Feb 27 15:23:01 2026 -0500 Bluetooth: ISO: Fix defer tests being unstable [ Upstream commit 62bcaa6b351b6dc400f6c6b83762001fd9f5c12d ] iso-tester defer tests seem to fail with hci_conn_hash_lookup_cig being unable to resolve a cig in set_cig_params_sync due a race where it is run immediatelly before hci_bind_cis is able to set the QoS settings into the hci_conn object. So this moves the assigning of the QoS settings to be done directly by hci_le_set_cig_params to prevent that from happening again. Fixes: 26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit fce04c8b54e438900b91c6797a57fb8a7077459d Author: Christian Eggers Date: Wed Feb 25 18:07:28 2026 +0100 Bluetooth: SMP: make SM/PER/KDU/BI-04-C happy [ Upstream commit 0e4d4dcc1a6e82cc6f9abf32193558efa7e1613d ] The last test step ("Test with Invalid public key X and Y, all set to 0") expects to get an "DHKEY check failed" instead of "unspecified". Fixes: 6d19628f539f ("Bluetooth: SMP: Fail if remote and local public keys are identical") Signed-off-by: Christian Eggers Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 37021b16b270cc47334fac7308c0aa4526bb876d Author: Christian Eggers Date: Wed Feb 25 18:07:27 2026 +0100 Bluetooth: LE L2CAP: Disconnect if sum of payload sizes exceed SDU [ Upstream commit b6a2bf43aa37670432843bc73ae2a6288ba4d6f8 ] Core 6.0, Vol 3, Part A, 3.4.3: "... If the sum of the payload sizes for the K-frames exceeds the specified SDU length, the receiver shall disconnect the channel." This fixes L2CAP/LE/CFC/BV-27-C (running together with 'l2test -r -P 0x0027 -V le_public'). Fixes: aac23bf63659 ("Bluetooth: Implement LE L2CAP reassembly") Signed-off-by: Christian Eggers Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 734aa845f2748b85dbbd2031620c238eb13132e4 Author: Christian Eggers Date: Wed Feb 25 18:07:25 2026 +0100 Bluetooth: LE L2CAP: Disconnect if received packet's SDU exceeds IMTU [ Upstream commit e1d9a66889867c232657a9b6f25d451d7c3ab96f ] Core 6.0, Vol 3, Part A, 3.4.3: "If the SDU length field value exceeds the receiver's MTU, the receiver shall disconnect the channel..." This fixes L2CAP/LE/CFC/BV-26-C (running together with 'l2test -r -P 0x0027 -V le_public -I 100'). Fixes: aac23bf63659 ("Bluetooth: Implement LE L2CAP reassembly") Signed-off-by: Christian Eggers Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 70d9bd9a2e683afe6200b0c20af22f06f1a199a4 Author: Cristian Marussi Date: Thu Mar 5 13:10:11 2026 +0000 firmware: arm_scmi: Fix NULL dereference on notify error path [ Upstream commit 555317d6100164748f7d09f80142739bd29f0cda ] Since commit b5daf93b809d1 ("firmware: arm_scmi: Avoid notifier registration for unsupported events") the call chains leading to the helper __scmi_event_handler_get_ops expect an ERR_PTR to be returned on failure to get an handler for the requested event key, while the current helper can still return a NULL when no handler could be found or created. Fix by forcing an ERR_PTR return value when the handler reference is NULL. Fixes: b5daf93b809d1 ("firmware: arm_scmi: Avoid notifier registration for unsupported events") Signed-off-by: Cristian Marussi Reviewed-by: Dan Carpenter Message-Id: <20260305131011.541444-1-cristian.marussi@arm.com> Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit d282757b0f6dd3e733a605961dff953b2b7a838d Author: Felix Gu Date: Wed Jan 21 21:08:19 2026 +0800 firmware: arm_scpi: Fix device_node reference leak in probe path [ Upstream commit 879c001afbac3df94160334fe5117c0c83b2cf48 ] A device_node reference obtained from the device tree is not released on all error paths in the arm_scpi probe path. Specifically, a node returned by of_parse_phandle() could be leaked when the probe failed after the node was acquired. The probe function returns early and the shmem reference is not released. Use __free(device_node) scope-based cleanup to automatically release the reference when the variable goes out of scope. Fixes: ed7ecb883901 ("firmware: arm_scpi: Add compatibility checks for shmem node") Signed-off-by: Felix Gu Message-Id: <20260121-arm_scpi_2-v2-1-702d7fa84acb@gmail.com> Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 3983811cab779c978692d79f1335617eace1c8dd Author: Yeoreum Yun Date: Wed Mar 4 12:09:53 2026 +0000 firmware: arm_ffa: Remove vm_id argument in ffa_rxtx_unmap() [ Upstream commit a4e8473b775160f3ce978f621cf8dea2c7250433 ] According to the FF-A specification (DEN0077, v1.1, §13.7), when FFA_RXTX_UNMAP is invoked from any instance other than non-secure physical, the w1 register must be zero (MBZ). If a non-zero value is supplied in this context, the SPMC must return FFA_INVALID_PARAMETER. The Arm FF-A driver operates exclusively as a guest or non-secure physical instance where the partition ID is always zero and is not invoked from a hypervisor context where w1 carries a VM ID. In this execution model, the partition ID observed by the driver is always zero, and passing a VM ID is unnecessary and potentially invalid. Remove the vm_id parameter from ffa_rxtx_unmap() and ensure that the SMC call is issued with w1 implicitly zeroed, as required by the specification. This prevents invalid parameter errors and aligns the implementation with the defined FF-A ABI behavior. Fixes: 3bbfe9871005 ("firmware: arm_ffa: Add initial Arm FFA driver support") Signed-off-by: Yeoreum Yun Message-Id: <20260304120953.847671-1-yeoreum.yun@arm.com> Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit ad01256fa62d0948f51651bd2cb452bf60eea077 Author: Claudiu Beznea Date: Mon Mar 2 15:57:03 2026 +0200 arm64: dts: renesas: rzg3s-smarc-som: Set bypass for Versa3 PLL2 [ Upstream commit 6dcbb6f070cccabc6a13d640a5a84de581fdd761 ] The default settings for the Versa3 device on the Renesas RZ/G3S SMARC SoM board have PLL2 disabled. PLL2 was later enabled together with audio support, as it is required to support both 44.1 kHz and 48 kHz audio. With PLL2 enabled, it was observed that Linux occasionally either hangs during boot (the last log message being related to the I2C probe) or randomly crashes. This was mainly reproducible on cold boots. During debugging, it was also noticed that the Unicode replacement character (�) sometimes appears on the serial console. Further investigation traced this to the configuration applied through the Versa3 register at offset 0x1c, which controls PLL enablement. The appearance of the Unicode replacement character suggested an issue with the SoC reference clock. The RZ/G3S reference clock is provided by the Versa3 clock generator (REF output). After checking with the Renesas Versa3 hardware team, it was found that this is related to the PLL2 lock bit being set through the renesas,settings DT property. The PLL lock bit must be set to avoid unstable clock output from the PLL. However, due to the Versa3 hardware design, when a PLL lock bit is set, all outputs (including the REF clock) are temporarily disabled until the configured PLLs become stable. As an alternative, the bypass bit can be used. This does not interrupt the PLL2 output or any other Versa3 outputs, but it may result in temporary instability on PLL2 output while the configuration is applied. Since PLL2 feeds only the audio path and audio is not used during early boot, this is acceptable and does not affect system boot. Drop the PLL2 lock bit and set the bypass bit instead. This has been tested with more than 1000 cold boots. Fixes: a94253232b04 ("arm64: dts: renesas: rzg3s-smarc-som: Add versa3 clock generator node") Signed-off-by: Claudiu Beznea Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260302135703.162601-1-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 2a53d63ac78c2d4ba707ba54de1a5845b6664693 Author: Lad Prabhakar Date: Fri Feb 13 13:17:42 2026 +0000 arm64: dts: renesas: r9a09g087: Fix CPG register region sizes [ Upstream commit f459672cf3ffd3c062973838951418271aa2ceef ] The CPG register regions were incorrectly sized. Update them to match the actual hardware specification: - First region (0x80280000): 0x1000 -> 0x10000 (64kiB) - Second region (0x81280000): 0x9000 -> 0x10000 (64kiB) Fixes: 4b3d31f0b81fe ("arm64: dts: renesas: Add initial SoC DTSI for the RZ/N2H SoC") Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260213131742.3606334-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit dfe08c4dde872d5a7742cc9291cc5b9629bee9c1 Author: Lad Prabhakar Date: Fri Feb 13 13:17:41 2026 +0000 arm64: dts: renesas: r9a09g077: Fix CPG register region sizes [ Upstream commit b12985ceca18bcf67f176883175d544daad5e00e ] The CPG register regions were incorrectly sized. Update them to match the actual hardware specification: - First region (0x80280000): 0x1000 -> 0x10000 (64kiB) - Second region (0x81280000): 0x9000 -> 0x10000 (64kiB) Fixes: d17b34744f5e4 ("arm64: dts: renesas: Add initial support for the Renesas RZ/T2H SoC") Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260213131742.3606334-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit fa59e9cfbed9a65a621d08b65a34928ebd7a74a3 Author: Fabrizio Castro Date: Tue Feb 3 12:42:46 2026 +0000 arm64: dts: renesas: r9a09g057: Remove wdt{0,2,3} nodes [ Upstream commit a3f34651de4287138c0da19ba321ad72622b4af3 ] The HW user manual for the Renesas RZ/V2H(P) SoC (a.k.a r9a09g057) states that only WDT1 is supposed to be accessed by the CA55 cores. WDT0 is supposed to be used by the CM33 core, WDT2 is supposed to be used by the CR8 core 0, and WDT3 is supposed to be used by the CR8 core 1. Remove wdt{0,2,3} from the SoC specific device tree to make it compliant with the specification from the HW manual. This change is harmless as there are currently no users of the wdt{0,2,3} device tree nodes, only the wdt1 node is actually used. Fixes: 095105496e7d ("arm64: dts: renesas: r9a09g057: Add WDT0-WDT3 nodes") Signed-off-by: Fabrizio Castro Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260203124247.7320-3-fabrizio.castro.jz@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 74893eb6d3602ce4ebe8992c41c92c2a0d4fbbb7 Author: Ovidiu Panait Date: Fri Nov 7 21:07:05 2025 +0000 arm64: dts: renesas: r9a09g057: Add RTC node [ Upstream commit cfc733da4e79018f88d8ac5f3a5306abbba8ef89 ] Add RTC node to Renesas RZ/V2H ("R9A09G057") SoC DTSI. Signed-off-by: Ovidiu Panait Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20251107210706.45044-4-ovidiu.panait.rb@renesas.com Signed-off-by: Geert Uytterhoeven Stable-dep-of: a3f34651de42 ("arm64: dts: renesas: r9a09g057: Remove wdt{0,2,3} nodes") Signed-off-by: Sasha Levin commit 2e5902c28fbdea603b9002af803fc4e93cc96728 Author: Lad Prabhakar Date: Fri Jan 23 22:59:57 2026 +0000 arm64: dts: renesas: rzv2-evk-cn15-sd: Add ramp delay for SD0 regulator [ Upstream commit 5c03465ecf6a56b7b261df9594f0e10612f53a50 ] Set an appropriate ramp delay for the SD0 I/O voltage regulator in the CN15 SD overlay to make UHS-I voltage switching reliable during card initialization. This issue was observed on the RZ/V2H EVK, while the same UHS-I cards worked on the RZ/V2N EVK without problems. Adding the ramp delay makes the behavior consistent and avoids SD init timeouts. Before this change SD0 could fail with: mmc0: error -110 whilst initialising SD card With the delay in place UHS-I cards enumerate correctly: mmc0: new UHS-I speed SDR104 SDXC card at address aaaa mmcblk0: mmc0:aaaa SR64G 59.5 GiB mmcblk0: p1 Fixes: 3d6c2bc7629c8 ("arm64: dts: renesas: Add CN15 eMMC and SD overlays for RZ/V2H and RZ/V2N EVKs") Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260123225957.1007089-5-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit edf76d9576907b010b585ea1d7c2cade82101ea3 Author: Lad Prabhakar Date: Fri Jan 23 22:59:54 2026 +0000 arm64: dts: renesas: rzt2h-n2h-evk: Add ramp delay for SD0 card regulator [ Upstream commit bb70589b67039e491dd60cf71272884e926a0f95 ] Add a ramp delay of 60 uV/us to the vqmmc_sdhi0 voltage regulator to fix UHS-I SD card detection failures. Measurements on CN78 pin 4 showed the actual voltage ramp time to be 21.86ms when switching between 3.3V and 1.8V. A 25ms ramp delay has been configured to provide adequate margin. The calculation is based on the voltage delta of 1.5V (3.3V - 1.8V): 1500000 uV / 60 uV/us = 25000 us (25ms) Prior to this patch, UHS-I cards failed to initialize with: mmc0: error -110 whilst initialising SD card After this patch, UHS-I cards are properly detected on SD0: mmc0: new UHS-I speed SDR104 SDXC card at address aaaa mmcblk0: mmc0:aaaa SR64G 59.5 GiB Fixes: d065453e5ee09 ("arm64: dts: renesas: rzt2h-rzn2h-evk: Enable SD card slot") Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260123225957.1007089-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit a1b7a843f12a0c3e9d3a2ca607ce451916ef42cf Author: Peddolla Harshavardhan Reddy Date: Thu Mar 5 21:36:59 2026 +0530 wifi: cfg80211: cancel pmsr_free_wk in cfg80211_pmsr_wdev_down [ Upstream commit 6dccbc9f3e1d38565dff7730d2b7d1e8b16c9b09 ] When the nl80211 socket that originated a PMSR request is closed, cfg80211_release_pmsr() sets the request's nl_portid to zero and schedules pmsr_free_wk to process the abort asynchronously. If the interface is concurrently torn down before that work runs, cfg80211_pmsr_wdev_down() calls cfg80211_pmsr_process_abort() directly. However, the already- scheduled pmsr_free_wk work item remains pending and may run after the interface has been removed from the driver. This could cause the driver's abort_pmsr callback to operate on a torn-down interface, leading to undefined behavior and potential crashes. Cancel pmsr_free_wk synchronously in cfg80211_pmsr_wdev_down() before calling cfg80211_pmsr_process_abort(). This ensures any pending or in-progress work is drained before interface teardown proceeds, preventing the work from invoking the driver abort callback after the interface is gone. Fixes: 9bb7e0f24e7e ("cfg80211: add peer measurement with FTM initiator API") Signed-off-by: Peddolla Harshavardhan Reddy Link: https://patch.msgid.link/20260305160712.1263829-3-peddolla.reddy@oss.qualcomm.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 5ba05436f15d16ae7ab04b880e8bf8d440be892b Author: Kuniyuki Iwashima Date: Fri Mar 6 07:24:02 2026 +0000 wifi: mac80211: Fix static_branch_dec() underflow for aql_disable. [ Upstream commit b94ae8e0d5fe1bdbbfdc3854ff6ce98f6876a828 ] syzbot reported static_branch_dec() underflow in aql_enable_write(). [0] The problem is that aql_enable_write() does not serialise concurrent write()s to the debugfs. aql_enable_write() checks static_key_false(&aql_disable.key) and later calls static_branch_inc() or static_branch_dec(), but the state may change between the two calls. aql_disable does not need to track inc/dec. Let's use static_branch_enable() and static_branch_disable(). [0]: val == 0 WARNING: kernel/jump_label.c:311 at __static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311, CPU#0: syz.1.3155/20288 Modules linked in: CPU: 0 UID: 0 PID: 20288 Comm: syz.1.3155 Tainted: G U L syzkaller #0 PREEMPT(full) Tainted: [U]=USER, [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026 RIP: 0010:__static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311 Code: f2 c9 ff 5b 5d c3 cc cc cc cc e8 54 f2 c9 ff 48 89 df e8 ac f9 ff ff eb ad e8 45 f2 c9 ff 90 0f 0b 90 eb a2 e8 3a f2 c9 ff 90 <0f> 0b 90 eb 97 48 89 df e8 5c 4b 33 00 e9 36 ff ff ff 0f 1f 80 00 RSP: 0018:ffffc9000b9f7c10 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffffff9b3e5d40 RCX: ffffffff823c57b4 RDX: ffff8880285a0000 RSI: ffffffff823c5846 RDI: ffff8880285a0000 RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 000000000000000a R13: 1ffff9200173ef88 R14: 0000000000000001 R15: ffffc9000b9f7e98 FS: 00007f530dd726c0(0000) GS:ffff8881245e3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000001140 CR3: 000000007cc4a000 CR4: 00000000003526f0 Call Trace: __static_key_slow_dec_cpuslocked kernel/jump_label.c:297 [inline] __static_key_slow_dec kernel/jump_label.c:321 [inline] static_key_slow_dec+0x7c/0xc0 kernel/jump_label.c:336 aql_enable_write+0x2b2/0x310 net/mac80211/debugfs.c:343 short_proxy_write+0x133/0x1a0 fs/debugfs/file.c:383 vfs_write+0x2aa/0x1070 fs/read_write.c:684 ksys_pwrite64 fs/read_write.c:793 [inline] __do_sys_pwrite64 fs/read_write.c:801 [inline] __se_sys_pwrite64 fs/read_write.c:798 [inline] __x64_sys_pwrite64+0x1eb/0x250 fs/read_write.c:798 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc9/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f530cf9aeb9 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:00007f530dd72028 EFLAGS: 00000246 ORIG_RAX: 0000000000000012 RAX: ffffffffffffffda RBX: 00007f530d215fa0 RCX: 00007f530cf9aeb9 RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000010 RBP: 00007f530d008c1f R08: 0000000000000000 R09: 0000000000000000 R10: 4200000000000005 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f530d216038 R14: 00007f530d215fa0 R15: 00007ffde89fb978 Fixes: e908435e402a ("mac80211: introduce aql_enable node in debugfs") Reported-by: syzbot+feb9ce36a95341bb47a4@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/69a8979e.a70a0220.b118c.0025.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260306072405.3649474-1-kuniyu@google.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 31d4ceb785d9b699d8195bd7e51f2aafc855f4e1 Author: Nicolas Cavallari Date: Tue Mar 3 17:06:39 2026 +0100 wifi: mac80211: use jiffies_delta_to_msecs() for sta_info inactive times [ Upstream commit ac6f24cc9c0a9aefa55ec9696dcafa971d4d760b ] Inactive times of around 0xffffffff milliseconds have been observed on an ath9k device on ARM. This is likely due to a memory ordering race in the jiffies_to_msecs(jiffies - last_active()) calculation causing an overflow when the observed jiffies is below ieee80211_sta_last_active(). Use jiffies_delta_to_msecs() instead to avoid this problem. Fixes: 7bbdd2d98797 ("mac80211: implement station stats retrieval") Signed-off-by: Nicolas Cavallari Link: https://patch.msgid.link/20260303161701.31808-1-nicolas.cavallari@green-communications.fr Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit f6a620a9d6a604be3ded73eaf5059fd30cbf6588 Author: Johannes Berg Date: Tue Mar 3 15:03:39 2026 +0100 wifi: mac80211: remove keys after disabling beaconing [ Upstream commit 708bbb45537780a8d3721ca1e0cf1932c1d1bf5f ] We shouldn't remove keys before disable beaconing, at least when beacon protection is used, since that would remove keys that are still used for beacon transmission at the same time. Stop before removing keys so there's no race. Fixes: af2d14b01c32 ("mac80211: Beacon protection using the new BIGTK (STA)") Reviewed-by: Miriam Rachel Korenblit Link: https://patch.msgid.link/20260303150339.574e7887b3ab.I50d708f5aa22584506a91d0da7f8a73ba39fceac@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit c2f6107728ea36b8ad7deb69c1e556b03103d58f Author: Matthew Wilcox Date: Fri Feb 20 14:19:59 2026 +0530 tee: shm: Remove refcounting of kernel pages [ Upstream commit 08d9a4580f71120be3c5b221af32dca00a48ceb0 ] Earlier TEE subsystem assumed to refcount all the memory pages to be shared with TEE implementation to be refcounted. However, the slab allocations within the kernel don't allow refcounting kernel pages. It is rather better to trust the kernel clients to not free pages while being shared with TEE implementation. Hence, remove refcounting of kernel pages from register_shm_helper() API. Fixes: b9c0e49abfca ("mm: decline to manipulate the refcount on a slab page") Reported-by: Marco Felsch Reported-by: Sven Püschel Signed-off-by: Matthew Wilcox Co-developed-by: Sumit Garg Signed-off-by: Sumit Garg Tested-by: Sven Püschel Signed-off-by: Jens Wiklander Signed-off-by: Sasha Levin commit 294e0c8bc35021e264d90376b812845b216be2f5 Author: Chen Ni Date: Mon Feb 9 09:59:04 2026 +0800 soc: fsl: cpm1: qmc: Fix error check for devm_ioremap_resource() in qmc_qe_init_resources() [ Upstream commit 3f4e403304186d79fddace860360540fc3af97f9 ] Fix wrong variable used for error checking after devm_ioremap_resource() call. The function checks qmc->scc_pram instead of qmc->dpram, which could lead to incorrect error handling. Fixes: eb680d563089 ("soc: fsl: cpm1: qmc: Add support for QUICC Engine (QE) implementation") Signed-off-by: Chen Ni Acked-by: Herve Codina Link: https://lore.kernel.org/r/20260209015904.871269-1-nichen@iscas.ac.cn Signed-off-by: Christophe Leroy (CS GROUP) Signed-off-by: Sasha Levin commit 85dbbf7dc88b0a54f2e334daedf6f3f31fd004fa Author: Richard Genoud Date: Tue Dec 23 08:25:49 2025 +0100 soc: fsl: qbman: fix race condition in qman_destroy_fq [ Upstream commit 014077044e874e270ec480515edbc1cadb976cf2 ] When QMAN_FQ_FLAG_DYNAMIC_FQID is set, there's a race condition between fq_table[fq->idx] state and freeing/allocating from the pool and WARN_ON(fq_table[fq->idx]) in qman_create_fq() gets triggered. Indeed, we can have: Thread A Thread B qman_destroy_fq() qman_create_fq() qman_release_fqid() qman_shutdown_fq() gen_pool_free() -- At this point, the fqid is available again -- qman_alloc_fqid() -- so, we can get the just-freed fqid in thread B -- fq->fqid = fqid; fq->idx = fqid * 2; WARN_ON(fq_table[fq->idx]); fq_table[fq->idx] = fq; fq_table[fq->idx] = NULL; And adding some logs between qman_release_fqid() and fq_table[fq->idx] = NULL makes the WARN_ON() trigger a lot more. To prevent that, ensure that fq_table[fq->idx] is set to NULL before gen_pool_free() is called by using smp_wmb(). Fixes: c535e923bb97 ("soc/fsl: Introduce DPAA 1.x QMan device driver") Signed-off-by: Richard Genoud Tested-by: CHAMPSEIX Thomas Link: https://lore.kernel.org/r/20251223072549.397625-1-richard.genoud@bootlin.com Signed-off-by: Christophe Leroy (CS GROUP) Signed-off-by: Sasha Levin commit 2315d328faa899905e6a83638ab23a2e932e2915 Author: Shawn Lin Date: Wed Feb 11 21:02:37 2026 +0800 soc: rockchip: grf: Add missing of_node_put() when returning [ Upstream commit 24ed11ee5bacf9a9aca18fc6b47667c7f38d578b ] Fix the smatch checking: drivers/soc/rockchip/grf.c:249 rockchip_grf_init() warn: inconsistent refcounting 'np->kobj.kref.refcount.refs.counter': Reported-by: Dan Carpenter Fixes: 75fb63ae0312 ("soc: rockchip: grf: Support multiple grf to be handled") Closes: https://lore.kernel.org/all/aYXvgTcUJWQL2can@stanley.mountain/ Signed-off-by: Shawn Lin Link: https://patch.msgid.link/1770814957-17762-1-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 640452dbc118e203e41754a8215d1af12c0be73c Author: Felix Gu Date: Sat Jan 31 01:49:09 2026 +0800 cache: ax45mp: Fix device node reference leak in ax45mp_cache_init() [ Upstream commit 0528a348b04b327a4611e29589beb4c9ae81304a ] In ax45mp_cache_init(), of_find_matching_node() returns a device node with an incremented reference count that must be released with of_node_put(). The current code fails to call of_node_put() which causes a reference leak. Use the __free(device_node) attribute to ensure automatic cleanup when the variable goes out of scope. Fixes: d34599bcd2e4 ("cache: Add L2 cache management for Andes AX45MP RISC-V core") Signed-off-by: Felix Gu Signed-off-by: Conor Dooley Signed-off-by: Sasha Levin commit 606fcf901c132ed87286d8b3d06a0fff36256c84 Author: Felix Gu Date: Sat Jan 31 01:13:45 2026 +0800 cache: starfive: fix device node leak in starlink_cache_init() [ Upstream commit 3c85234b979af71cb9db5eb976ea08a468415767 ] of_find_matching_node() returns a device_node with refcount incremented. Use __free(device_node) attribute to automatically call of_node_put() when the variable goes out of scope, preventing the refcount leak. Fixes: cabff60ca77d ("cache: Add StarFive StarLink cache management") Signed-off-by: Felix Gu Reviewed-by: Jonathan Cameron Signed-off-by: Conor Dooley Signed-off-by: Sasha Levin commit e3dd5cffba07de6574165a72851471cd42cc6d15 Author: Zilin Guan Date: Sun Dec 28 12:48:36 2025 +0000 soc: microchip: mpfs: Fix memory leak in mpfs_sys_controller_probe() [ Upstream commit 5a741f8cc6fe62542f955cd8d24933a1b6589cbd ] In mpfs_sys_controller_probe(), if of_get_mtd_device_by_node() fails, the function returns immediately without freeing the allocated memory for sys_controller, leading to a memory leak. Fix this by jumping to the out_free label to ensure the memory is properly freed. Also, consolidate the error handling for the mbox_request_channel() failure case to use the same label. Fixes: 742aa6c563d2 ("soc: microchip: mpfs: enable access to the system controller's flash") Co-developed-by: Jianhao Xu Signed-off-by: Jianhao Xu Signed-off-by: Zilin Guan Signed-off-by: Conor Dooley Signed-off-by: Sasha Levin commit 8f9e054f605ae5496552aa3fdff3c38fee6a5235 Author: ZhengYuan Huang Date: Thu Mar 12 08:33:21 2026 +0800 btrfs: tree-checker: fix misleading root drop_level error message [ Upstream commit fc1cd1f18c34f91e78362f9629ab9fd43b9dcab9 ] Fix tree-checker error message to report "invalid root drop_level" instead of the misleading "invalid root level". Fixes: 259ee7754b67 ("btrfs: tree-checker: Add ROOT_ITEM check") Reviewed-by: Qu Wenruo Signed-off-by: ZhengYuan Huang Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 1cf30c73602c69d750c9345c47f2c0e9d0cfb578 Author: Filipe Manana Date: Tue Mar 3 16:57:43 2026 +0000 btrfs: log new dentries when logging parent dir of a conflicting inode [ Upstream commit 9573a365ff9ff45da9222d3fe63695ce562beb24 ] If we log the parent directory of a conflicting inode, we are not logging the new dentries of the directory, so when we finish we have the parent directory's inode marked as logged but we did not log its new dentries. As a consequence if the parent directory is explicitly fsynced later and it does not have any new changes since we logged it, the fsync is a no-op and after a power failure the new dentries are missing. Example scenario: $ mkdir foo $ sync $rmdir foo $ mkdir dir1 $ mkdir dir2 # A file with the same name and parent as the directory we just deleted # and was persisted in a past transaction. So the deleted directory's # inode is a conflicting inode of this new file's inode. $ touch foo $ ln foo dir2/link # The fsync on dir2 will log the parent directory (".") because the # conflicting inode (deleted directory) does not exists anymore, but it # it does not log its new dentries (dir1). $ xfs_io -c "fsync" dir2 # This fsync on the parent directory is no-op, since the previous fsync # logged it (but without logging its new dentries). $ xfs_io -c "fsync" . # After log replay dir1 is missing. Fix this by ensuring we log new dir dentries whenever we log the parent directory of a no longer existing conflicting inode. A test case for fstests will follow soon. Reported-by: Vyacheslav Kovalevsky Link: https://lore.kernel.org/linux-btrfs/182055fa-e9ce-4089-9f5f-4b8a23e8dd91@gmail.com/ Fixes: a3baaf0d786e ("Btrfs: fix fsync after succession of renames and unlink/rmdir") Reviewed-by: Boris Burkov Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 9691c50fd5dd14ecb88ce8e80a8632cb7471c052 Author: Jouni Högander Date: Thu Mar 12 10:37:10 2026 +0200 drm/i915/psr: Compute PSR entry_setup_frames into intel_crtc_state commit 7caac659a837af9fd4cad85be851982b88859484 upstream. PSR entry_setup_frames is currently computed directly into struct intel_dp:intel_psr:entry_setup_frames. This causes a problem if mode change gets rejected after PSR compute config: Psr_entry_setup_frames computed for this rejected state is in intel_dp:intel_psr:entry_setup_frame. Fix this by computing it into intel_crtc_state and copy the value into intel_dp:intel_psr:entry_setup_frames on PSR enable. Fixes: 2b981d57e480 ("drm/i915/display: Support PSR entry VSC packet to be transmitted one frame earlier") Cc: Mika Kahola Cc: # v6.8+ Signed-off-by: Jouni Högander Reviewed-by: Suraj Kandpal Link: https://patch.msgid.link/20260312083710.1593781-3-jouni.hogander@intel.com (cherry picked from commit 8c229b4aa00262c13787982e998c61c0783285e0) Signed-off-by: Joonas Lahtinen [ adapted context lines to account for missing `no_psr_reason` field and `alpm_state` struct. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8d0d94f8ba5b3a0beec3b0da558b9bea48018117 Author: Luiz Augusto von Dentz Date: Tue Mar 3 13:29:53 2026 -0500 Bluetooth: L2CAP: Fix accepting multiple L2CAP_ECRED_CONN_REQ commit 5b3e2052334f2ff6d5200e952f4aa66994d09899 upstream. Currently the code attempts to accept requests regardless of the command identifier which may cause multiple requests to be marked as pending (FLAG_DEFER_SETUP) which can cause more than L2CAP_ECRED_MAX_CID(5) to be allocated in l2cap_ecred_rsp_defer causing an overflow. The spec is quite clear that the same identifier shall not be used on subsequent requests: 'Within each signaling channel a different Identifier shall be used for each successive request or indication.' https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-32a25a06-4aa4-c6c7-77c5-dcfe3682355d So this attempts to check if there are any channels pending with the same identifier and rejects if any are found. Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode") Reported-by: Yiming Qian Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 1e9e2640d870d4837bcfdc220cb2c99ae5ee119f Author: Matthew Brost Date: Tue Mar 10 18:50:39 2026 -0400 drm/xe: Open-code GGTT MMIO access protection commit 01f2557aa684e514005541e71a3d01f4cd45c170 upstream. GGTT MMIO access is currently protected by hotplug (drm_dev_enter), which works correctly when the driver loads successfully and is later unbound or unloaded. However, if driver load fails, this protection is insufficient because drm_dev_unplug() is never called. Additionally, devm release functions cannot guarantee that all BOs with GGTT mappings are destroyed before the GGTT MMIO region is removed, as some BOs may be freed asynchronously by worker threads. To address this, introduce an open-coded flag, protected by the GGTT lock, that guards GGTT MMIO access. The flag is cleared during the dev_fini_ggtt devm release function to ensure MMIO access is disabled once teardown begins. Cc: stable@vger.kernel.org Fixes: 919bb54e989c ("drm/xe: Fix missing runtime outer protection for ggtt_remove_node") Reviewed-by: Zhanjun Dong Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260310225039.1320161-8-zhanjun.dong@intel.com (cherry picked from commit 4f3a998a173b4325c2efd90bdadc6ccd3ad9a431) Signed-off-by: Thomas Hellström Signed-off-by: Greg Kroah-Hartman commit 8613cca4f5f4f5bb2603075b24415f19cab8d35b Author: Ashutosh Dixit Date: Thu Mar 12 22:36:30 2026 -0700 drm/xe/oa: Allow reading after disabling OA stream commit 9be6fd9fbd2032b683e51374497768af9aaa228a upstream. Some OA data might be present in the OA buffer when OA stream is disabled. Allow UMD's to retrieve this data, so that all data till the point when OA stream is disabled can be retrieved. v2: Update tail pointer after disable (Umesh) Fixes: efb315d0a013 ("drm/xe/oa/uapi: Read file_operation") Cc: stable@vger.kernel.org Signed-off-by: Ashutosh Dixit Reviewed-by: Umesh Nerlige Ramappa Link: https://patch.msgid.link/20260313053630.3176100-1-ashutosh.dixit@intel.com (cherry picked from commit 4ff57c5e8dbba23b5457be12f9709d5c016da16e) Signed-off-by: Thomas Hellström Signed-off-by: Greg Kroah-Hartman commit 954dae0d94fbf5e04876990501a8b0a2b4212ea3 Author: Zhanjun Dong Date: Tue Mar 10 18:50:37 2026 -0400 drm/xe/guc: Ensure CT state transitions via STOP before DISABLED commit 7838dd8367419e9fc43b79c038321cb3c04de2a2 upstream. The GuC CT state transition requires moving to the STOP state before entering the DISABLED state. Update the driver teardown sequence to make the proper state machine transitions. Fixes: ee4b32220a6b ("drm/xe/guc: Add devm release action to safely tear down CT") Cc: stable@vger.kernel.org Signed-off-by: Zhanjun Dong Reviewed-by: Matthew Brost Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260310225039.1320161-6-zhanjun.dong@intel.com (cherry picked from commit dace8cb0032f57ea67c87b3b92ad73c89dd2db44) Signed-off-by: Thomas Hellström Signed-off-by: Greg Kroah-Hartman commit 0b35d11fbbcfd1079c8489282a341944228835e3 Author: Imre Deak Date: Mon Mar 9 18:48:03 2026 +0200 drm/i915/dmc: Fix an unlikely NULL pointer deference at probe commit ac57eb3b7d2ad649025b5a0fa207315f755ac4f6 upstream. intel_dmc_update_dc6_allowed_count() oopses when DMC hasn't been initialized, and dmc is thus NULL. That would be the case when the call path is intel_power_domains_init_hw() -> {skl,bxt,icl}_display_core_init() -> gen9_set_dc_state() -> intel_dmc_update_dc6_allowed_count(), as intel_power_domains_init_hw() is called *before* intel_dmc_init(). However, gen9_set_dc_state() calls intel_dmc_update_dc6_allowed_count() conditionally, depending on the current and target DC states. At probe, the target is disabled, but if DC6 is enabled, the function is called, and an oops follows. Apparently it's quite unlikely that DC6 is enabled at probe, as we haven't seen this failure mode before. It is also strange to have DC6 enabled at boot, since that would require the DMC firmware (loaded by BIOS); the BIOS loading the DMC firmware and the driver stopping / reprogramming the firmware is a poorly specified sequence and as such unlikely an intentional BIOS behaviour. It's more likely that BIOS is leaving an unintentionally enabled DC6 HW state behind (without actually loading the required DMC firmware for this). The tracking of the DC6 allowed counter only works if starting / stopping the counter depends on the _SW_ DC6 state vs. the current _HW_ DC6 state (since stopping the counter requires the DC5 counter captured when the counter was started). Thus, using the HW DC6 state is incorrect and it also leads to the above oops. Fix both issues by using the SW DC6 state for the tracking. This is v2 of the fix originally sent by Jani, updated based on the first Link: discussion below. Link: https://lore.kernel.org/all/3626411dc9e556452c432d0919821b76d9991217@intel.com Link: https://lore.kernel.org/all/20260228130946.50919-2-ltao@redhat.com Fixes: 88c1f9a4d36d ("drm/i915/dmc: Create debugfs entry for dc6 counter") Cc: Mohammed Thasleem Cc: Jani Nikula Cc: Tao Liu Cc: # v6.16+ Tested-by: Tao Liu Reviewed-by: Jani Nikula Signed-off-by: Imre Deak Link: https://patch.msgid.link/20260309164803.1918158-1-imre.deak@intel.com (cherry picked from commit 2344b93af8eb5da5d496b4e0529d35f0f559eaf0) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 5ce4a38e6c2488949e373d5066303f9c128db614 Author: Jesse.Zhang Date: Thu Mar 12 18:06:17 2026 +0800 drm/amdgpu: Limit BO list entry count to prevent resource exhaustion commit 6270b1a5dab94665d7adce3dc78bc9066ed28bdd upstream. Userspace can pass an arbitrary number of BO list entries via the bo_number field. Although the previous multiplication overflow check prevents out-of-bounds allocation, a large number of entries could still cause excessive memory allocation (up to potentially gigabytes) and unnecessarily long list processing times. Introduce a hard limit of 128k entries per BO list, which is more than sufficient for any realistic use case (e.g., a single list containing all buffers in a large scene). This prevents memory exhaustion attacks and ensures predictable performance. Return -EINVAL if the requested entry count exceeds the limit Reviewed-by: Christian König Suggested-by: Christian König Signed-off-by: Jesse Zhang Signed-off-by: Alex Deucher (cherry picked from commit 688b87d39e0aa8135105b40dc167d74b5ada5332) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 73908f65f5cc32f9da07c5df0f58d1fd5ed5834e Author: Alex Deucher Date: Mon Sep 25 10:44:07 2023 -0400 drm/amdgpu: apply state adjust rules to some additional HAINAN vairants commit 9787f7da186ee8143b7b6d914cfa0b6e7fee2648 upstream. They need a similar workaround. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/1839 Signed-off-by: Alex Deucher (cherry picked from commit 0de31d92a173d3d94f28051b0b80a6c98913aed4) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit c18eef45af03655e1c93b6438a357ceaeb567200 Author: Alex Deucher Date: Mon Sep 25 10:44:06 2023 -0400 drm/radeon: apply state adjust rules to some additional HAINAN vairants commit 86650ee2241ff84207eaa298ab318533f3c21a38 upstream. They need a similar workaround. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/1839 Signed-off-by: Alex Deucher (cherry picked from commit 87327658c848f56eac166cb382b57b83bf06c5ac) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 772f3653eef50ea7cf721b05d8e275f93bc460f3 Author: Alessio Belle Date: Tue Mar 10 11:41:11 2026 +0000 drm/imagination: Synchronize interrupts before suspending the GPU commit 2d7f05cddf4c268cc36256a2476946041dbdd36d upstream. The runtime PM suspend callback doesn't know whether the IRQ handler is in progress on a different CPU core and doesn't wait for it to finish. Depending on timing, the IRQ handler could be running while the GPU is suspended, leading to kernel crashes when trying to access GPU registers. See example signature below. In a power off sequence initiated by the runtime PM suspend callback, wait for any IRQ handlers in progress on other CPU cores to finish, by calling synchronize_irq(). At the same time, remove the runtime PM resume/put calls in the threaded IRQ handler. On top of not being the right approach to begin with, and being at the wrong place as they should have wrapped all GPU register accesses, the driver would hit a deadlock between synchronize_irq() being called from a runtime PM suspend callback, holding the device power lock, and the resume callback requiring the same. Example crash signature on a TI AM68 SK platform: [ 337.241218] SError Interrupt on CPU0, code 0x00000000bf000000 -- SError [ 337.241239] CPU: 0 UID: 0 PID: 112 Comm: irq/234-gpu Tainted: G M 6.17.7-B2C-00005-g9c7bbe4ea16c #2 PREEMPT [ 337.241246] Tainted: [M]=MACHINE_CHECK [ 337.241249] Hardware name: Texas Instruments AM68 SK (DT) [ 337.241252] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 337.241256] pc : pvr_riscv_irq_pending+0xc/0x24 [ 337.241277] lr : pvr_device_irq_thread_handler+0x64/0x310 [ 337.241282] sp : ffff800085b0bd30 [ 337.241284] x29: ffff800085b0bd50 x28: ffff0008070d9eab x27: ffff800083a5ce10 [ 337.241291] x26: ffff000806e48f80 x25: ffff0008070d9eac x24: 0000000000000000 [ 337.241296] x23: ffff0008068e9bf0 x22: ffff0008068e9bd0 x21: ffff800085b0bd30 [ 337.241301] x20: ffff0008070d9e00 x19: ffff0008068e9000 x18: 0000000000000001 [ 337.241305] x17: 637365645f656c70 x16: 0000000000000000 x15: ffff000b7df9ff40 [ 337.241310] x14: 0000a585fe3c0d0e x13: 000000999704f060 x12: 000000000002771a [ 337.241314] x11: 00000000000000c0 x10: 0000000000000af0 x9 : ffff800085b0bd00 [ 337.241318] x8 : ffff0008071175d0 x7 : 000000000000b955 x6 : 0000000000000003 [ 337.241323] x5 : 0000000000000000 x4 : 0000000000000002 x3 : 0000000000000000 [ 337.241327] x2 : ffff800080e39d20 x1 : ffff800080e3fc48 x0 : 0000000000000000 [ 337.241333] Kernel panic - not syncing: Asynchronous SError Interrupt [ 337.241337] CPU: 0 UID: 0 PID: 112 Comm: irq/234-gpu Tainted: G M 6.17.7-B2C-00005-g9c7bbe4ea16c #2 PREEMPT [ 337.241342] Tainted: [M]=MACHINE_CHECK [ 337.241343] Hardware name: Texas Instruments AM68 SK (DT) [ 337.241345] Call trace: [ 337.241348] show_stack+0x18/0x24 (C) [ 337.241357] dump_stack_lvl+0x60/0x80 [ 337.241364] dump_stack+0x18/0x24 [ 337.241368] vpanic+0x124/0x2ec [ 337.241373] abort+0x0/0x4 [ 337.241377] add_taint+0x0/0xbc [ 337.241384] arm64_serror_panic+0x70/0x80 [ 337.241389] do_serror+0x3c/0x74 [ 337.241392] el1h_64_error_handler+0x30/0x48 [ 337.241400] el1h_64_error+0x6c/0x70 [ 337.241404] pvr_riscv_irq_pending+0xc/0x24 (P) [ 337.241410] irq_thread_fn+0x2c/0xb0 [ 337.241416] irq_thread+0x170/0x334 [ 337.241421] kthread+0x12c/0x210 [ 337.241428] ret_from_fork+0x10/0x20 [ 337.241434] SMP: stopping secondary CPUs [ 337.241451] Kernel Offset: disabled [ 337.241453] CPU features: 0x040000,02002800,20002001,0400421b [ 337.241456] Memory Limit: none [ 337.457921] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]--- Fixes: cc1aeedb98ad ("drm/imagination: Implement firmware infrastructure and META FW support") Fixes: 96822d38ff57 ("drm/imagination: Handle Rogue safety event IRQs") Cc: stable@vger.kernel.org # see patch description, needs adjustments for < 6.16 Signed-off-by: Alessio Belle Reviewed-by: Matt Coster Link: https://patch.msgid.link/20260310-drain-irqs-before-suspend-v1-1-bf4f9ed68e75@imgtec.com Signed-off-by: Matt Coster Signed-off-by: Greg Kroah-Hartman commit 9497b1f309436971726e229aa6026954ea7c28e9 Author: Alessio Belle Date: Mon Mar 9 15:23:48 2026 +0000 drm/imagination: Fix deadlock in soft reset sequence commit a55c2a5c8d680156495b7b1e2a9f5a3e313ba524 upstream. The soft reset sequence is currently executed from the threaded IRQ handler, hence it cannot call disable_irq() which internally waits for IRQ handlers, i.e. itself, to complete. Use disable_irq_nosync() during a soft reset instead. Fixes: cc1aeedb98ad ("drm/imagination: Implement firmware infrastructure and META FW support") Cc: stable@vger.kernel.org Signed-off-by: Alessio Belle Reviewed-by: Matt Coster Link: https://patch.msgid.link/20260309-fix-soft-reset-v1-1-121113be554f@imgtec.com Signed-off-by: Matt Coster Signed-off-by: Greg Kroah-Hartman commit 7687403d658054027c60654cf71fc29ad90c9e1d Author: Alex Deucher Date: Wed Mar 4 17:25:56 2026 -0500 drm/amdgpu/mmhub4.1.0: add bounds checking for cid commit 3cdd405831d8cc50a5eae086403402697bb98a4a upstream. The value should never exceed the array size as those are the only values the hardware is expected to return, but add checks anyway. Reviewed-by: Benjamin Cheng Signed-off-by: Alex Deucher (cherry picked from commit 04f063d85090f5dd0c671010ce88ee49d9dcc8ed) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 72365be44cc7e2cf05514e0dafcd7664f3267358 Author: Alex Deucher Date: Wed Mar 4 17:25:30 2026 -0500 drm/amdgpu/mmhub3.0: add bounds checking for cid commit cdb82ecbeccb55fae75a3c956b605f7801a30db1 upstream. The value should never exceed the array size as those are the only values the hardware is expected to return, but add checks anyway. Reviewed-by: Benjamin Cheng Signed-off-by: Alex Deucher (cherry picked from commit f14f27bbe2a3ed7af32d5f6eaf3f417139f45253) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 4b9e5676db815341b0c21006250845e5a0161afa Author: Alex Deucher Date: Wed Mar 4 17:25:09 2026 -0500 drm/amdgpu/mmhub3.0.2: add bounds checking for cid commit e5e6d67b1ce9764e67aef2d0eef9911af53ad99a upstream. The value should never exceed the array size as those are the only values the hardware is expected to return, but add checks anyway. Reviewed-by: Benjamin Cheng Signed-off-by: Alex Deucher (cherry picked from commit 1441f52c7f6ae6553664aa9e3e4562f6fc2fe8ea) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 56f0473d3c6314502fdcf76e574985a585aa707d Author: Alex Deucher Date: Wed Mar 4 17:24:35 2026 -0500 drm/amdgpu/mmhub3.0.1: add bounds checking for cid commit 5d4e88bcfef29569a1db224ef15e28c603666c6d upstream. The value should never exceed the array size as those are the only values the hardware is expected to return, but add checks anyway. Reviewed-by: Benjamin Cheng Signed-off-by: Alex Deucher (cherry picked from commit 5f76083183363c4528a4aaa593f5d38c28fe7d7b) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 603db8a36517ce318b213cf1740b7d1f0f6b233b Author: Alex Deucher Date: Wed Mar 4 17:24:10 2026 -0500 drm/amdgpu/mmhub2.3: add bounds checking for cid commit a54403a534972af5d9ba5aaa3bb6ead612500ec6 upstream. The value should never exceed the array size as those are the only values the hardware is expected to return, but add checks anyway. Reviewed-by: Benjamin Cheng Signed-off-by: Alex Deucher (cherry picked from commit 89cd90375c19fb45138990b70e9f4ba4806f05c4) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2c4eea0eba197b036804cf4c76bd9b70aa02f30a Author: Alex Deucher Date: Wed Mar 4 17:22:43 2026 -0500 drm/amdgpu/mmhub2.0: add bounds checking for cid commit 0b26edac4ac5535df1f63e6e8ab44c24fe1acad7 upstream. The value should never exceed the array size as those are the only values the hardware is expected to return, but add checks anyway. Reviewed-by: Benjamin Cheng Signed-off-by: Alex Deucher (cherry picked from commit e064cef4b53552602bb6ac90399c18f662f3cacd) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 3256b95b2d3c472bccee9a6ba83e883a540c1e83 Author: Alex Deucher Date: Mon Mar 16 15:51:08 2026 -0400 drm/amdgpu/gmc9.0: add bounds checking for cid commit f39e1270277f4b06db0b2c6ec9405b6dd766fb13 upstream. The value should never exceed the array size as those are the only values the hardware is expected to return, but add checks anyway. Cc: Benjamin Cheng Reviewed-by: Benjamin Cheng Signed-off-by: Alex Deucher (cherry picked from commit e14d468304832bcc4a082d95849bc0a41b18ddea) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e25fff4a9eac969a580eaac86b650d355ac9a91c Author: Xi Ruoyao Date: Fri Mar 6 14:28:03 2026 +0800 drm/amd/display: Wrap dcn32_override_min_req_memclk() in DC_FP_{START, END} commit ebe82c6e75cfc547154d0fd843b0dd6cca3d548f upstream. [Why] The dcn32_override_min_req_memclk function is in dcn32_fpu.c, which is compiled with CC_FLAGS_FPU into FP instructions. So when we call it we must use DC_FP_{START,END} to save and restore the FP context, and prepare the FP unit on architectures like LoongArch where the FP unit isn't always on. Reported-by: LiarOnce Fixes: ee7be8f3de1c ("drm/amd/display: Limit DCN32 8 channel or less parts to DPM1 for FPO") Signed-off-by: Xi Ruoyao Reviewed-by: Alex Hung Signed-off-by: Alex Deucher (cherry picked from commit 25bb1d54ba3983c064361033a8ec15474fece37e) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 074d06d3724ccab0c5bb779db594a82b6405e501 Author: Maarten Lankhorst Date: Fri Mar 13 16:17:27 2026 +0100 drm: Fix use-after-free on framebuffers and property blobs when calling drm_dev_unplug commit 6bee098b91417654703e17eb5c1822c6dfd0c01d upstream. When trying to do a rather aggressive test of igt's "xe_module_load --r reload" with a full desktop environment and game running I noticed a few OOPSes when dereferencing freed pointers, related to framebuffers and property blobs after the compositor exits. Solve this by guarding the freeing in drm_file with drm_dev_enter/exit, and immediately put the references from struct drm_file objects during drm_dev_unplug(). Related warnings for framebuffers on the subtest: [ 739.713076] ------------[ cut here ]------------ WARN_ON(!list_empty(&dev->mode_config.fb_list)) [ 739.713079] WARNING: drivers/gpu/drm/drm_mode_config.c:584 at drm_mode_config_cleanup+0x30b/0x320 [drm], CPU#12: xe_module_load/13145 .... [ 739.713328] Call Trace: [ 739.713330] [ 739.713335] ? intel_pmdemand_destroy_state+0x11/0x20 [xe] [ 739.713574] ? intel_atomic_global_obj_cleanup+0xe4/0x1a0 [xe] [ 739.713794] intel_display_driver_remove_noirq+0x51/0xb0 [xe] [ 739.714041] xe_display_fini_early+0x33/0x50 [xe] [ 739.714284] devm_action_release+0xf/0x20 [ 739.714294] devres_release_all+0xad/0xf0 [ 739.714301] device_unbind_cleanup+0x12/0xa0 [ 739.714305] device_release_driver_internal+0x1b7/0x210 [ 739.714311] device_driver_detach+0x14/0x20 [ 739.714315] unbind_store+0xa6/0xb0 [ 739.714319] drv_attr_store+0x21/0x30 [ 739.714322] sysfs_kf_write+0x48/0x60 [ 739.714328] kernfs_fop_write_iter+0x16b/0x240 [ 739.714333] vfs_write+0x266/0x520 [ 739.714341] ksys_write+0x72/0xe0 [ 739.714345] __x64_sys_write+0x19/0x20 [ 739.714347] x64_sys_call+0xa15/0xa30 [ 739.714355] do_syscall_64+0xd8/0xab0 [ 739.714361] entry_SYSCALL_64_after_hwframe+0x4b/0x53 and [ 739.714459] ------------[ cut here ]------------ [ 739.714461] xe 0000:67:00.0: [drm] drm_WARN_ON(!list_empty(&fb->filp_head)) [ 739.714464] WARNING: drivers/gpu/drm/drm_framebuffer.c:833 at drm_framebuffer_free+0x6c/0x90 [drm], CPU#12: xe_module_load/13145 [ 739.714715] RIP: 0010:drm_framebuffer_free+0x7a/0x90 [drm] ... [ 739.714869] Call Trace: [ 739.714871] [ 739.714876] drm_mode_config_cleanup+0x26a/0x320 [drm] [ 739.714998] ? __drm_printfn_seq_file+0x20/0x20 [drm] [ 739.715115] ? drm_mode_config_cleanup+0x207/0x320 [drm] [ 739.715235] intel_display_driver_remove_noirq+0x51/0xb0 [xe] [ 739.715576] xe_display_fini_early+0x33/0x50 [xe] [ 739.715821] devm_action_release+0xf/0x20 [ 739.715828] devres_release_all+0xad/0xf0 [ 739.715843] device_unbind_cleanup+0x12/0xa0 [ 739.715850] device_release_driver_internal+0x1b7/0x210 [ 739.715856] device_driver_detach+0x14/0x20 [ 739.715860] unbind_store+0xa6/0xb0 [ 739.715865] drv_attr_store+0x21/0x30 [ 739.715868] sysfs_kf_write+0x48/0x60 [ 739.715873] kernfs_fop_write_iter+0x16b/0x240 [ 739.715878] vfs_write+0x266/0x520 [ 739.715886] ksys_write+0x72/0xe0 [ 739.715890] __x64_sys_write+0x19/0x20 [ 739.715893] x64_sys_call+0xa15/0xa30 [ 739.715900] do_syscall_64+0xd8/0xab0 [ 739.715905] entry_SYSCALL_64_after_hwframe+0x4b/0x53 and then finally file close blows up: [ 743.186530] Oops: general protection fault, probably for non-canonical address 0xdead000000000122: 0000 [#1] SMP [ 743.186535] CPU: 3 UID: 1000 PID: 3453 Comm: kwin_wayland Tainted: G W 7.0.0-rc1-valkyria+ #110 PREEMPT_{RT,(lazy)} [ 743.186537] Tainted: [W]=WARN [ 743.186538] Hardware name: Gigabyte Technology Co., Ltd. X299 AORUS Gaming 3/X299 AORUS Gaming 3-CF, BIOS F8n 12/06/2021 [ 743.186539] RIP: 0010:drm_framebuffer_cleanup+0x55/0xc0 [drm] [ 743.186588] Code: d8 72 73 0f b6 42 05 ff c3 39 c3 72 e8 49 8d bd 50 07 00 00 31 f6 e8 3a 80 d3 e1 49 8b 44 24 10 49 8d 7c 24 08 49 8b 54 24 08 <48> 3b 38 0f 85 95 7f 02 00 48 3b 7a 08 0f 85 8b 7f 02 00 48 89 42 [ 743.186589] RSP: 0018:ffffc900085e3cf8 EFLAGS: 00010202 [ 743.186591] RAX: dead000000000122 RBX: 0000000000000001 RCX: ffffffff8217ed03 [ 743.186592] RDX: dead000000000100 RSI: 0000000000000000 RDI: ffff88814675ba08 [ 743.186593] RBP: ffffc900085e3d10 R08: 0000000000000000 R09: 0000000000000000 [ 743.186593] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88814675ba00 [ 743.186594] R13: ffff88810d778000 R14: ffff888119f6dca0 R15: ffff88810c660bb0 [ 743.186595] FS: 00007ff377d21280(0000) GS:ffff888cec3f8000(0000) knlGS:0000000000000000 [ 743.186596] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 743.186596] CR2: 000055690b55e000 CR3: 0000000113586003 CR4: 00000000003706f0 [ 743.186597] Call Trace: [ 743.186598] [ 743.186603] intel_user_framebuffer_destroy+0x12/0x90 [xe] [ 743.186722] drm_framebuffer_free+0x3a/0x90 [drm] [ 743.186750] ? trace_hardirqs_on+0x5f/0x120 [ 743.186754] drm_mode_object_put+0x51/0x70 [drm] [ 743.186786] drm_fb_release+0x105/0x190 [drm] [ 743.186812] ? rt_mutex_slowunlock+0x3aa/0x410 [ 743.186817] ? rt_spin_lock+0xea/0x1b0 [ 743.186819] drm_file_free+0x1e0/0x2c0 [drm] [ 743.186843] drm_release_noglobal+0x91/0xf0 [drm] [ 743.186865] __fput+0x100/0x2e0 [ 743.186869] fput_close_sync+0x40/0xa0 [ 743.186870] __x64_sys_close+0x3e/0x80 [ 743.186873] x64_sys_call+0xa07/0xa30 [ 743.186879] do_syscall_64+0xd8/0xab0 [ 743.186881] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 743.186882] RIP: 0033:0x7ff37e567732 [ 743.186884] Code: 08 0f 85 a1 38 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 0f 1f 00 f3 0f 1e fa 55 bf 01 00 [ 743.186885] RSP: 002b:00007ffc818169a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 [ 743.186886] RAX: ffffffffffffffda RBX: 00007ffc81816a30 RCX: 00007ff37e567732 [ 743.186887] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000012 [ 743.186888] RBP: 00007ffc818169d0 R08: 0000000000000000 R09: 0000000000000000 [ 743.186889] R10: 0000000000000000 R11: 0000000000000246 R12: 000055d60a7996e0 [ 743.186889] R13: 00007ffc81816a90 R14: 00007ffc81816a90 R15: 000055d60a782a30 [ 743.186892] [ 743.186893] Modules linked in: rfcomm snd_hrtimer xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_addrtype nft_compat x_tables nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables overlay cfg80211 bnep mtd_intel_dg snd_hda_codec_intelhdmi mtd snd_hda_codec_hdmi nls_utf8 mxm_wmi intel_wmi_thunderbolt gigabyte_wmi wmi_bmof xe drm_gpuvm drm_gpusvm_helper i2c_algo_bit drm_buddy drm_ttm_helper ttm video drm_suballoc_helper gpu_sched drm_client_lib drm_exec drm_display_helper cec drm_kunit_helpers drm_kms_helper kunit x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_alc882 snd_hda_codec_realtek_lib snd_hda_codec_generic snd_hda_intel snd_soc_avs snd_soc_hda_codec snd_hda_ext_core snd_hda_codec snd_hwdep snd_hda_core snd_intel_dspcfg snd_soc_core snd_compress ac97_bus snd_pcm snd_seq snd_seq_device snd_timer i2c_i801 i2c_mux snd i2c_smbus btusb btrtl btbcm btmtk btintel bluetooth ecdh_generic rfkill ecc mei_me mei ioatdma dca wmi nfsd drm i2c_dev fuse nfnetlink [ 743.186938] ---[ end trace 0000000000000000 ]--- And for property blobs: void drm_mode_config_cleanup(struct drm_device *dev) { ... list_for_each_entry_safe(blob, bt, &dev->mode_config.property_blob_list, head_global) { drm_property_blob_put(blob); } Resulting in: [ 371.072940] BUG: unable to handle page fault for address: 000001ffffffffff [ 371.072944] #PF: supervisor read access in kernel mode [ 371.072945] #PF: error_code(0x0000) - not-present page [ 371.072947] PGD 0 P4D 0 [ 371.072950] Oops: Oops: 0000 [#1] SMP [ 371.072953] CPU: 0 UID: 1000 PID: 3693 Comm: kwin_wayland Not tainted 7.0.0-rc1-valkyria+ #111 PREEMPT_{RT,(lazy)} [ 371.072956] Hardware name: Gigabyte Technology Co., Ltd. X299 AORUS Gaming 3/X299 AORUS Gaming 3-CF, BIOS F8n 12/06/2021 [ 371.072957] RIP: 0010:drm_property_destroy_user_blobs+0x3b/0x90 [drm] [ 371.073019] Code: 00 00 48 83 ec 10 48 8b 86 30 01 00 00 48 39 c3 74 59 48 89 c2 48 8d 48 c8 48 8b 00 4c 8d 60 c8 eb 04 4c 8d 60 c8 48 8b 71 40 <48> 39 16 0f 85 39 32 01 00 48 3b 50 08 0f 85 2f 32 01 00 48 89 70 [ 371.073021] RSP: 0018:ffffc90006a73de8 EFLAGS: 00010293 [ 371.073022] RAX: 000001ffffffffff RBX: ffff888118a1a930 RCX: ffff8881b92355c0 [ 371.073024] RDX: ffff8881b92355f8 RSI: 000001ffffffffff RDI: ffff888118be4000 [ 371.073025] RBP: ffffc90006a73e08 R08: ffff8881009b7300 R09: ffff888cecc5b000 [ 371.073026] R10: ffffc90006a73e90 R11: 0000000000000002 R12: 000001ffffffffc7 [ 371.073027] R13: ffff888118a1a980 R14: ffff88810b366d20 R15: ffff888118a1a970 [ 371.073028] FS: 00007f1faccbb280(0000) GS:ffff888cec2db000(0000) knlGS:0000000000000000 [ 371.073029] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 371.073030] CR2: 000001ffffffffff CR3: 000000010655c001 CR4: 00000000003706f0 [ 371.073031] Call Trace: [ 371.073033] [ 371.073036] drm_file_free+0x1df/0x2a0 [drm] [ 371.073077] drm_release_noglobal+0x7a/0xe0 [drm] [ 371.073113] __fput+0xe2/0x2b0 [ 371.073118] fput_close_sync+0x40/0xa0 [ 371.073119] __x64_sys_close+0x3e/0x80 [ 371.073122] x64_sys_call+0xa07/0xa30 [ 371.073126] do_syscall_64+0xc0/0x840 [ 371.073130] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 371.073132] RIP: 0033:0x7f1fb3501732 [ 371.073133] Code: 08 0f 85 a1 38 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 0f 1f 00 f3 0f 1e fa 55 bf 01 00 [ 371.073135] RSP: 002b:00007ffe8e6f0278 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 [ 371.073136] RAX: ffffffffffffffda RBX: 00007ffe8e6f0300 RCX: 00007f1fb3501732 [ 371.073137] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000012 [ 371.073138] RBP: 00007ffe8e6f02a0 R08: 0000000000000000 R09: 0000000000000000 [ 371.073139] R10: 0000000000000000 R11: 0000000000000246 R12: 00005585ba46eea0 [ 371.073140] R13: 00007ffe8e6f0360 R14: 00007ffe8e6f0360 R15: 00005585ba458a30 [ 371.073143] [ 371.073144] Modules linked in: rfcomm snd_hrtimer xt_addrtype xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp nft_compat x_tables nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables overlay cfg80211 bnep snd_hda_codec_intelhdmi snd_hda_codec_hdmi mtd_intel_dg mtd nls_utf8 wmi_bmof mxm_wmi gigabyte_wmi intel_wmi_thunderbolt xe drm_gpuvm drm_gpusvm_helper i2c_algo_bit drm_buddy drm_ttm_helper ttm video drm_suballoc_helper gpu_sched drm_client_lib drm_exec drm_display_helper cec drm_kunit_helpers drm_kms_helper kunit x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_alc882 snd_hda_codec_realtek_lib snd_hda_codec_generic snd_hda_intel snd_soc_avs snd_soc_hda_codec snd_hda_ext_core snd_hda_codec snd_hwdep snd_hda_core snd_intel_dspcfg snd_soc_core snd_compress ac97_bus snd_pcm snd_seq snd_seq_device snd_timer i2c_i801 btusb i2c_mux i2c_smbus btrtl snd btbcm btmtk btintel bluetooth ecdh_generic rfkill ecc mei_me mei ioatdma dca wmi nfsd drm i2c_dev fuse nfnetlink [ 371.073198] CR2: 000001ffffffffff [ 371.073199] ---[ end trace 0000000000000000 ]--- Add a guard around file close, and ensure the warnings from drm_mode_config do not trigger. Fix those by allowing an open reference to the file descriptor and cleaning up the file linked list entry in drm_mode_config_cleanup(). Cc: # v4.18+ Fixes: bee330f3d672 ("drm: Use srcu to protect drm_device.unplugged") Cc: Thomas Hellström Reviewed-by: Thomas Hellström Link: https://patch.msgid.link/20260313151728.14990-4-dev@lankhorst.se Signed-off-by: Maarten Lankhorst Signed-off-by: Greg Kroah-Hartman commit 3b02923b046afd1632d97dff3d55127cbcf09eca Author: Maciej Andrzejewski ICEYE Date: Thu Mar 5 13:37:51 2026 +0100 serial: uartlite: fix PM runtime usage count underflow on probe commit d54801cd509515f674a5aac1d3ea1401d2a05863 upstream. ulite_probe() calls pm_runtime_put_autosuspend() at the end of probe without holding a corresponding PM runtime reference for non-console ports. During ulite_assign(), uart_add_one_port() triggers uart_configure_port() which calls ulite_pm() via uart_change_pm(). For non-console ports, the UART core performs a balanced get/put cycle: uart_change_pm(ON) -> ulite_pm() -> pm_runtime_get_sync() +1 uart_change_pm(OFF) -> ulite_pm() -> pm_runtime_put_autosuspend() -1 This leaves no spare reference for the pm_runtime_put_autosuspend() at the end of probe. The PM runtime core prevents the count from actually going below zero, and instead triggers a "Runtime PM usage count underflow!" warning. For console ports the bug is masked: the UART core skips the uart_change_pm(OFF) call, so the UART core's unbalanced get happens to pair with probe's trailing put. Add pm_runtime_get_noresume() before pm_runtime_enable() to take an explicit probe-owned reference that the trailing pm_runtime_put_autosuspend() can release. This ensures a correct usage count regardless of whether the port is a console. Fixes: 5bbe10a6942d ("tty: serial: uartlite: Add runtime pm support") Cc: stable Signed-off-by: Maciej Andrzejewski ICEYE Link: https://patch.msgid.link/20260305123746.4152800-1-maciej.andrzejewski@m-works.net Signed-off-by: Greg Kroah-Hartman commit efe85a557186b7fe915572ae93a8f3f78bfd9a22 Author: Jiayuan Chen Date: Wed Feb 4 15:43:20 2026 +0800 serial: core: fix infinite loop in handle_tx() for PORT_UNKNOWN commit 455ce986fa356ff43a43c0d363ba95fa152f21d5 upstream. uart_write_room() and uart_write() behave inconsistently when xmit_buf is NULL (which happens for PORT_UNKNOWN ports that were never properly initialized): - uart_write_room() returns kfifo_avail() which can be > 0 - uart_write() checks xmit_buf and returns 0 if NULL This inconsistency causes an infinite loop in drivers that rely on tty_write_room() to determine if they can write: while (tty_write_room(tty) > 0) { written = tty->ops->write(...); // written is always 0, loop never exits } For example, caif_serial's handle_tx() enters an infinite loop when used with PORT_UNKNOWN serial ports, causing system hangs. Fix by making uart_write_room() also check xmit_buf and return 0 if it's NULL, consistent with uart_write(). Reproducer: https://gist.github.com/mrpre/d9a694cc0e19828ee3bc3b37983fde13 Signed-off-by: Jiayuan Chen Cc: stable Link: https://patch.msgid.link/20260204074327.226165-1-jiayuan.chen@linux.dev Signed-off-by: Greg Kroah-Hartman commit a773f019c0b061b9bbc67b13a084bd7b74e6e76d Author: Ilpo Järvinen Date: Tue Feb 3 19:10:49 2026 +0200 serial: 8250_dw: Ensure BUSY is deasserted commit a7b9ce39fbe4ae2919fe4f7ac16c293cb6632d30 upstream. DW UART cannot write to LCR, DLL, and DLH while BUSY is asserted. Existance of BUSY depends on uart_16550_compatible, if UART HW is configured with it those registers can always be written. There currently is dw8250_force_idle() which attempts to achieve non-BUSY state by disabling FIFO, however, the solution is unreliable when Rx keeps getting more and more characters. Create a sequence of operations that ensures UART cannot keep BUSY asserted indefinitely. The new sequence relies on enabling loopback mode temporarily to prevent incoming Rx characters keeping UART BUSY. Ensure no Tx in ongoing while the UART is switches into the loopback mode (requires exporting serial8250_fifo_wait_for_lsr_thre() and adding DMA Tx pause/resume functions). According to tests performed by Adriana Nicolae , simply disabling FIFO or clearing FIFOs only once does not always ensure BUSY is deasserted but up to two tries may be needed. This could be related to ongoing Rx of a character (a guess, not known for sure). Therefore, retry FIFO clearing a few times (retry limit 4 is arbitrary number but using, e.g., p->fifosize seems overly large). Tests performed by others did not exhibit similar challenge but it does not seem harmful to leave the FIFO clearing loop in place for all DW UARTs with BUSY functionality. Use the new dw8250_idle_enter/exit() to do divisor writes and LCR writes. In case of plain LCR writes, opportunistically try to update LCR first and only invoke dw8250_idle_enter() if the write did not succeed (it has been observed that in practice most LCR writes do succeed without complications). This issue was first reported by qianfan Zhao who put lots of debugging effort into understanding the solution space. Fixes: c49436b657d0 ("serial: 8250_dw: Improve unwritable LCR workaround") Fixes: 7d4008ebb1c9 ("tty: add a DesignWare 8250 driver") Cc: stable Reported-by: qianfan Zhao Link: https://lore.kernel.org/linux-serial/289bb78a-7509-1c5c-2923-a04ed3b6487d@163.com/ Reported-by: Adriana Nicolae Link: https://lore.kernel.org/linux-serial/20250819182322.3451959-1-adriana@arista.com/ Reported-by: Bandal, Shankar Tested-by: Bandal, Shankar Tested-by: Murthy, Shanth Reviewed-by: Andy Shevchenko Signed-off-by: Ilpo Järvinen Link: https://patch.msgid.link/20260203171049.4353-8-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 0e16f461f2b19c674883f47e0ccb2b3d1659f2fe Author: Ilpo Järvinen Date: Tue Feb 3 19:10:48 2026 +0200 serial: 8250: Add late synchronize_irq() to shutdown to handle DW UART BUSY commit e0a368ae79531ff92105a2692f10d83052055856 upstream. When DW UART is !uart_16550_compatible, it can indicate BUSY at any point (when under constant Rx pressure) unless a complex sequence of steps is performed. Any LCR write can run a foul with the condition that prevents writing LCR while the UART is BUSY, which triggers BUSY_DETECT interrupt that seems unmaskable using IER bits. Normal flow is that dw8250_handle_irq() handles BUSY_DETECT condition by reading USR register. This BUSY feature, however, breaks the assumptions made in serial8250_do_shutdown(), which runs synchronize_irq() after clearing IER and assumes no interrupts can occur after that point but then proceeds to update LCR, which on DW UART can trigger an interrupt. If serial8250_do_shutdown() releases the interrupt handler before the handler has run and processed the BUSY_DETECT condition by read the USR register, the IRQ is not deasserted resulting in interrupt storm that triggers "irq x: nobody cared" warning leading to disabling the IRQ. Add late synchronize_irq() into serial8250_do_shutdown() to ensure BUSY_DETECT from DW UART is handled before port's interrupt handler is released. Alternative would be to add DW UART specific shutdown function but it would mostly duplicate the generic code and the extra synchronize_irq() seems pretty harmless in serial8250_do_shutdown(). Fixes: 7d4008ebb1c9 ("tty: add a DesignWare 8250 driver") Cc: stable Reported-by: Bandal, Shankar Tested-by: Bandal, Shankar Tested-by: Murthy, Shanth Reviewed-by: Andy Shevchenko Signed-off-by: Ilpo Järvinen Link: https://patch.msgid.link/20260203171049.4353-7-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 5dfd8c76c0a4dd0a6db2e2720e43604c72322474 Author: Ilpo Järvinen Date: Tue Feb 3 19:10:47 2026 +0200 serial: 8250_dw: Rework IIR_NO_INT handling to stop interrupt storm commit 73a4ed8f9efaaaf8207614ccc1c9d5ca1888f23a upstream. INTC10EE UART can end up into an interrupt storm where it reports IIR_NO_INT (0x1). If the storm happens during active UART operation, it is promptly stopped by IIR value change due to Rx or Tx events. However, when there is no activity, either due to idle serial line or due to specific circumstances such as during shutdown that writes IER=0, there is nothing to stop the storm. During shutdown the storm is particularly problematic because serial8250_do_shutdown() calls synchronize_irq() that will hang in waiting for the storm to finish which never happens. This problem can also result in triggering a warning: irq 45: nobody cared (try booting with the "irqpoll" option) [...snip...] handlers: serial8250_interrupt Disabling IRQ #45 Normal means to reset interrupt status by reading LSR, MSR, USR, or RX register do not result in the UART deasserting the IRQ. Add a quirk to INTC10EE UARTs to enable Tx interrupts if UART's Tx is currently empty and inactive. Rework IIR_NO_INT to keep track of the number of consecutive IIR_NO_INT, and on fourth one perform the quirk. Enabling Tx interrupts should change IIR value from IIR_NO_INT to IIR_THRI which has been observed to stop the storm. Fixes: e92fad024929 ("serial: 8250_dw: Add ACPI ID for Granite Rapids-D UART") Cc: stable Reported-by: Bandal, Shankar Tested-by: Bandal, Shankar Tested-by: Murthy, Shanth Reviewed-by: Andy Shevchenko Signed-off-by: Ilpo Järvinen Link: https://patch.msgid.link/20260203171049.4353-6-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 2d21617bce4f2dc771ff1e2ef0a8e792189bbe69 Author: Ilpo Järvinen Date: Tue Feb 3 19:10:46 2026 +0200 serial: 8250_dw: Rework dw8250_handle_irq() locking and IIR handling commit 883c5a2bc934c165c4491d1ef7da0ac4e9765077 upstream. dw8250_handle_irq() takes port's lock multiple times with no good reason to release it in between and calls serial8250_handle_irq() that also takes port's lock. Take port's lock only once in dw8250_handle_irq() and use serial8250_handle_irq_locked() to avoid releasing port's lock in between. As IIR_NO_INT check in serial8250_handle_irq() was outside of port's lock, it has to be done already in dw8250_handle_irq(). DW UART can, in addition to IIR_NO_INT, report BUSY_DETECT (0x7) which collided with the IIR_NO_INT (0x1) check in serial8250_handle_irq() (because & is used instead of ==) meaning that no other work is done by serial8250_handle_irq() during an BUSY_DETECT interrupt. This allows reorganizing code in dw8250_handle_irq() to do both IIR_NO_INT and BUSY_DETECT handling right at the start simplifying the logic. Tested-by: Bandal, Shankar Tested-by: Murthy, Shanth Cc: stable Reviewed-by: Andy Shevchenko Signed-off-by: Ilpo Järvinen Link: https://patch.msgid.link/20260203171049.4353-5-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 9bb497252a4203e0da1997ef10fc0a148785a4ed Author: Ilpo Järvinen Date: Tue Feb 3 19:10:45 2026 +0200 serial: 8250: Add serial8250_handle_irq_locked() commit 8324a54f604da18f21070702a8ad82ab2062787b upstream. 8250_port exports serial8250_handle_irq() to HW specific 8250 drivers. It takes port's lock within but a HW specific 8250 driver may want to take port's lock itself, do something, and then call the generic handler in 8250_port but to do that, the caller has to release port's lock for no good reason. Introduce serial8250_handle_irq_locked() which a HW specific driver can call while already holding port's lock. As this is new export, put it straight into a namespace (where all 8250 exports should eventually be moved). Tested-by: Bandal, Shankar Tested-by: Murthy, Shanth Cc: stable Reviewed-by: Andy Shevchenko Signed-off-by: Ilpo Järvinen Link: https://patch.msgid.link/20260203171049.4353-4-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 3b1d813de41ebde3798a3dbb61b0aaea39010477 Author: Ilpo Järvinen Date: Tue Feb 3 19:10:44 2026 +0200 serial: 8250_dw: Avoid unnecessary LCR writes commit 8002d6d6d0d8a36a7d6ca523b17a51cb0fa7c3c3 upstream. When DW UART is configured with BUSY flag, LCR writes may not always succeed which can make any LCR write complex and very expensive. Performing write directly can trigger IRQ and the driver has to perform complex and distruptive sequence while retrying the write. Therefore, it's better to avoid doing LCR write that would not change the value of the LCR register. Add LCR write avoidance code into the 8250_dw driver's .serial_out() functions. Reported-by: Bandal, Shankar Tested-by: Bandal, Shankar Tested-by: Murthy, Shanth Cc: stable Reviewed-by: Andy Shevchenko Signed-off-by: Ilpo Järvinen Link: https://patch.msgid.link/20260203171049.4353-3-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit e6cc0536d1547e7fafbda2bf34fb46e6ee68c847 Author: Ilpo Järvinen Date: Tue Feb 3 19:10:43 2026 +0200 serial: 8250: Protect LCR write in shutdown commit 59a33d83bbe6d73d2071d7ae21590b29faed0503 upstream. The 8250_dw driver needs to potentially perform very complex operations during LCR writes because its BUSY handling prevents updates to LCR while UART is BUSY (which is not fully under our control without those complex operations). Thus, LCR writes should occur under port's lock. Move LCR write under port's lock in serial8250_do_shutdown(). Also split the LCR RMW so that the logic is on a separate line for clarity. Reported-by: Bandal, Shankar Tested-by: Bandal, Shankar Tested-by: Murthy, Shanth Cc: stable Reviewed-by: Andy Shevchenko Signed-off-by: Ilpo Järvinen Link: https://patch.msgid.link/20260203171049.4353-2-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 4afc12dae7487693d4432f3371afdb488650abdf Author: Peng Zhang Date: Tue Feb 24 13:16:39 2026 +0100 serial: 8250: always disable IRQ during THRE test commit 24b98e8664e157aff0814a0f49895ee8223f382f upstream. commit 039d4926379b ("serial: 8250: Toggle IER bits on only after irq has been set up") moved IRQ setup before the THRE test, in combination with commit 205d300aea75 ("serial: 8250: change lock order in serial8250_do_startup()") the interrupt handler can run during the test and race with its IIR reads. This can produce wrong THRE test results and cause spurious registration of the serial8250_backup_timeout timer. Unconditionally disable the IRQ for the short duration of the test and re-enable it afterwards to avoid the race. Fixes: 039d4926379b ("serial: 8250: Toggle IER bits on only after irq has been set up") Depends-on: 205d300aea75 ("serial: 8250: change lock order in serial8250_do_startup()") Cc: stable Signed-off-by: Peng Zhang Reviewed-by: Muchun Song Signed-off-by: Alban Bedel Tested-by: Maximilian Lueer Link: https://patch.msgid.link/20260224121639.579404-1-alban.bedel@lht.dlh.de Signed-off-by: Greg Kroah-Hartman commit 5f6b17562f03fc65c7d3474ef8f1959b19d1ca41 Author: Raul E Rangel Date: Mon Feb 9 13:58:18 2026 -0700 serial: 8250: Fix TX deadlock when using DMA commit a424a34b8faddf97b5af41689087e7a230f79ba7 upstream. `dmaengine_terminate_async` does not guarantee that the `__dma_tx_complete` callback will run. The callback is currently the only place where `dma->tx_running` gets cleared. If the transaction is canceled and the callback never runs, then `dma->tx_running` will never get cleared and we will never schedule new TX DMA transactions again. This change makes it so we clear `dma->tx_running` after we terminate the DMA transaction. This is "safe" because `serial8250_tx_dma_flush` is holding the UART port lock. The first thing the callback does is also grab the UART port lock, so access to `dma->tx_running` is serialized. Fixes: 9e512eaaf8f4 ("serial: 8250: Fix fifo underflow on flush") Cc: stable Signed-off-by: Raul E Rangel Link: https://patch.msgid.link/20260209135815.1.I16366ecb0f62f3c96fe3dd5763fcf6f3c2b4d8cd@changeid Signed-off-by: Greg Kroah-Hartman commit 5e5b209b2d932786bc9294f0589b69b6104364fe Author: Martin Roukala (né Peres) Date: Mon Mar 9 15:53:10 2026 +0200 serial: 8250_pci: add support for the AX99100 commit 9c0072bc33d349c83d223e64be30794e11938a6b upstream. This is found in popular brands such as StarTech.com or Delock, and has been a source of frustration to quite a few people, if I can trust Amazon comments complaining about Linux support via the official out-of-the-tree driver. Signed-off-by: Martin Roukala (né Peres) Cc: stable Link: https://patch.msgid.link/20260309-8250_pci_ax99100-v1-1-3328bdfd8e94@mupuf.org Signed-off-by: Greg Kroah-Hartman commit c4efef65a46f610418a3f69149c51492d31c8591 Author: Nicolas Pitre Date: Tue Jan 27 17:56:01 2026 -0500 vt: save/restore unicode screen buffer for alternate screen commit 5eb608319bb56464674a71b4a66ea65c6c435d64 upstream. The alternate screen support added by commit 23743ba64709 ("vt: add support for smput/rmput escape codes") only saves and restores the regular screen buffer (vc_origin), but completely ignores the corresponding unicode screen buffer (vc_uni_lines) creating a messed-up display. Add vc_saved_uni_lines to save the unicode screen buffer when entering the alternate screen, and restore it when leaving. Also ensure proper cleanup in reset_terminal() and vc_deallocate(). Fixes: 23743ba64709 ("vt: add support for smput/rmput escape codes") Cc: stable Signed-off-by: Nicolas Pitre Link: https://patch.msgid.link/5o2p6qp3-91pq-0p17-or02-1oors4417ns7@onlyvoer.pbz Signed-off-by: Greg Kroah-Hartman commit 19e46bf37943bc26bd81045558bcd38b01f06f23 Author: Jens Axboe Date: Thu Mar 19 14:29:20 2026 -0600 io_uring/kbuf: propagate BUF_MORE through early buffer commit path commit 418eab7a6f3c002d8e64d6e95ec27118017019af upstream. When io_should_commit() returns true (eg for non-pollable files), buffer commit happens at buffer selection time and sel->buf_list is set to NULL. When __io_put_kbufs() generates CQE flags at completion time, it calls __io_put_kbuf_ring() which finds a NULL buffer_list and hence cannot determine whether the buffer was consumed or not. This means that IORING_CQE_F_BUF_MORE is never set for non-pollable input with incrementally consumed buffers. Likewise for io_buffers_select(), which always commits upfront and discards the return value of io_kbuf_commit(). Add REQ_F_BUF_MORE to store the result of io_kbuf_commit() during early commit. Then __io_put_kbuf_ring() can check this flag and set IORING_F_BUF_MORE accordingy. Reported-by: Martin Michaelis Cc: stable@vger.kernel.org Fixes: ae98dbf43d75 ("io_uring/kbuf: add support for incremental buffer consumption") Link: https://github.com/axboe/liburing/issues/1553 Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit f98405afd2a7017f2d1bea769299c55ab41f1384 Author: Jens Axboe Date: Thu Mar 19 14:29:09 2026 -0600 io_uring/kbuf: fix missing BUF_MORE for incremental buffers at EOF commit 3ecd3e03144b38a21a3b70254f1b9d2e16629b09 upstream. For a zero length transfer, io_kbuf_inc_commit() is called with !len. Since we never enter the while loop to consume the buffers, io_kbuf_inc_commit() ends up returning true, consuming the buffer. But if no data was consumed, by definition it cannot have consumed the buffer. Return false for that case. Reported-by: Martin Michaelis Cc: stable@vger.kernel.org Fixes: ae98dbf43d75 ("io_uring/kbuf: add support for incremental buffer consumption") Link: https://github.com/axboe/liburing/issues/1553 Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 0f4ce79b8db7b040373fc664c8bc6c5fd74bd196 Author: Jens Axboe Date: Sun Mar 15 09:03:03 2026 -0600 io_uring/poll: fix multishot recv missing EOF on wakeup race commit a68ed2df72131447d131531a08fe4dfcf4fa4653 upstream. When a socket send and shutdown() happen back-to-back, both fire wake-ups before the receiver's task_work has a chance to run. The first wake gets poll ownership (poll_refs=1), and the second bumps it to 2. When io_poll_check_events() runs, it calls io_poll_issue() which does a recv that reads the data and returns IOU_RETRY. The loop then drains all accumulated refs (atomic_sub_return(2) -> 0) and exits, even though only the first event was consumed. Since the shutdown is a persistent state change, no further wakeups will happen, and the multishot recv can hang forever. Check specifically for HUP in the poll loop, and ensure that another loop is done to check for status if more than a single poll activation is pending. This ensures we don't lose the shutdown event. Cc: stable@vger.kernel.org Fixes: dbc2564cfe0f ("io_uring: let fast poll support multishot") Reported-by: Francis Brosseau Link: https://github.com/axboe/liburing/issues/1549 Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit ee312bb1052e45cbccaf6abac1012db9ca43150a Author: Lu Baolu Date: Mon Mar 16 15:16:40 2026 +0800 iommu/vt-d: Only handle IOPF for SVA when PRI is supported commit 39c20c4e83b9f78988541d829aa34668904e54a0 upstream. In intel_svm_set_dev_pasid(), the driver unconditionally manages the IOPF handling during a domain transition. However, commit a86fb7717320 ("iommu/vt-d: Allow SVA with device-specific IOPF") introduced support for SVA on devices that handle page faults internally without utilizing the PCI PRI. On such devices, the IOMMU-side IOPF infrastructure is not required. Calling iopf_for_domain_replace() on these devices is incorrect and can lead to unexpected failures during PASID attachment or unwinding. Add a check for info->pri_supported to ensure that the IOPF queue logic is only invoked for devices that actually rely on the IOMMU's PRI-based fault handling. Fixes: 17fce9d2336d ("iommu/vt-d: Put iopf enablement in domain attach path") Cc: stable@vger.kernel.org Suggested-by: Kevin Tian Reviewed-by: Kevin Tian Signed-off-by: Lu Baolu Link: https://lore.kernel.org/r/20260310075520.295104-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 300e7cfdc92bbfb6fec00efe322555763ba88600 Author: Guanghui Feng Date: Mon Mar 16 15:16:39 2026 +0800 iommu/vt-d: Fix intel iommu iotlb sync hardlockup and retry commit fe89277c9ceb0d6af0aa665bcf24a41d8b1b79cd upstream. During the qi_check_fault process after an IOMMU ITE event, requests at odd-numbered positions in the queue are set to QI_ABORT, only satisfying single-request submissions. However, qi_submit_sync now supports multiple simultaneous submissions, and can't guarantee that the wait_desc will be at an odd-numbered position. Therefore, if an item times out, IOMMU can't re-initiate the request, resulting in an infinite polling wait. This modifies the process by setting the status of all requests already fetched by IOMMU and recorded as QI_IN_USE status (including wait_desc requests) to QI_ABORT, thus enabling multiple requests to be resubmitted. Fixes: 8a1d82462540 ("iommu/vt-d: Multiple descriptors per qi_submit_sync()") Cc: stable@vger.kernel.org Signed-off-by: Guanghui Feng Tested-by: Shuai Xue Reviewed-by: Shuai Xue Reviewed-by: Samiullah Khawaja Link: https://lore.kernel.org/r/20260306101516.3885775-1-guanghuifeng@linux.alibaba.com Signed-off-by: Lu Baolu Fixes: 8a1d82462540 ("iommu/vt-d: Multiple descriptors per qi_submit_sync()") Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit c4054ad2d8bff4e8e937cd4a1d1a04c1e8f77a2c Author: Finn Thain Date: Mon Feb 16 18:01:30 2026 +1100 mtd: Avoid boot crash in RedBoot partition table parser commit 8e2f8020270af7777d49c2e7132260983e4fc566 upstream. Given CONFIG_FORTIFY_SOURCE=y and a recent compiler, commit 439a1bcac648 ("fortify: Use __builtin_dynamic_object_size() when available") produces the warning below and an oops. Searching for RedBoot partition table in 50000000.flash at offset 0x7e0000 ------------[ cut here ]------------ WARNING: lib/string_helpers.c:1035 at 0xc029e04c, CPU#0: swapper/0/1 memcmp: detected buffer overflow: 15 byte read of buffer size 14 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.19.0 #1 NONE As Kees said, "'names' is pointing to the final 'namelen' many bytes of the allocation ... 'namelen' could be basically any length at all. This fortify warning looks legit to me -- this code used to be reading beyond the end of the allocation." Since the size of the dynamic allocation is calculated with strlen() we can use strcmp() instead of memcmp() and remain within bounds. Cc: Kees Cook Cc: stable@vger.kernel.org Cc: linux-hardening@vger.kernel.org Link: https://lore.kernel.org/all/202602151911.AD092DFFCD@keescook/ Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Suggested-by: Kees Cook Signed-off-by: Finn Thain Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 215f6d6845a3ee37979c3e3b6b3d1430945b11af Author: Chen Ni Date: Mon Feb 9 15:56:18 2026 +0800 mtd: rawnand: cadence: Fix error check for dma_alloc_coherent() in cadence_nand_init() commit 0410e1a4c545c769c59c6eda897ad5d574d0c865 upstream. Fix wrong variable used for error checking after dma_alloc_coherent() call. The function checks cdns_ctrl->dma_cdma_desc instead of cdns_ctrl->cdma_desc, which could lead to incorrect error handling. Fixes: ec4ba01e894d ("mtd: rawnand: Add new Cadence NAND driver to MTD subsystem") Cc: stable@vger.kernel.org Signed-off-by: Chen Ni Reviewed-by: Alok Tiwari Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 978f50a3d7dac189d24d66bfa3b5ad97150f353a Author: Olivier Sobrie Date: Tue Mar 17 18:18:07 2026 +0100 mtd: rawnand: pl353: make sure optimal timings are applied commit b9465b04de4b90228de03db9a1e0d56b00814366 upstream. Timings of the nand are adjusted by pl35x_nfc_setup_interface() but actually applied by the pl35x_nand_select_target() function. If there is only one nand chip, the pl35x_nand_select_target() will only apply the timings once since the test at its beginning will always be true after the first call to this function. As a result, the hardware will keep using the default timings set at boot to detect the nand chip, not the optimal ones. With this patch, we program directly the new timings when pl35x_nfc_setup_interface() is called. Fixes: 08d8c62164a3 ("mtd: rawnand: pl353: Add support for the ARM PL353 SMC NAND controller") Signed-off-by: Olivier Sobrie Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman commit 378b295f67102eef78cf2c28105f60ae1dab5cc1 Author: Johan Hovold Date: Thu Mar 12 16:18:14 2026 +0100 spi: fix statistics allocation commit dee0774bbb2abb172e9069ce5ffef579b12b3ae9 upstream. The controller per-cpu statistics is not allocated until after the controller has been registered with driver core, which leaves a window where accessing the sysfs attributes can trigger a NULL-pointer dereference. Fix this by moving the statistics allocation to controller allocation while tying its lifetime to that of the controller (rather than using implicit devres). Fixes: 6598b91b5ac3 ("spi: spi.c: Convert statistics to per-cpu u64_stats_t") Cc: stable@vger.kernel.org # 6.0 Cc: David Jander Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260312151817.32100-3-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 80f3e8cd2b4ad355b2ad2024cf423f6d183404f7 Author: Johan Hovold Date: Thu Mar 12 16:18:13 2026 +0100 spi: fix use-after-free on controller registration failure commit 8634e05b08ead636e926022f4a98416e13440df9 upstream. Make sure to deregister from driver core also in the unlikely event that per-cpu statistics allocation fails during controller registration to avoid use-after-free (of driver resources) and unclocked register accesses. Fixes: 6598b91b5ac3 ("spi: spi.c: Convert statistics to per-cpu u64_stats_t") Cc: stable@vger.kernel.org # 6.0 Cc: David Jander Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260312151817.32100-2-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 18605b1b936b66b1f34dcf8e9ad4f1fbcf7a7c13 Author: Maíra Canal Date: Tue Mar 17 19:41:49 2026 -0300 pmdomain: bcm: bcm2835-power: Increase ASB control timeout commit b826d2c0b0ecb844c84431ba6b502e744f5d919a upstream. The bcm2835_asb_control() function uses a tight polling loop to wait for the ASB bridge to acknowledge a request. During intensive workloads, this handshake intermittently fails for V3D's master ASB on BCM2711, resulting in "Failed to disable ASB master for v3d" errors during runtime PM suspend. As a consequence, the failed power-off leaves V3D in a broken state, leading to bus faults or system hangs on later accesses. As the timeout is insufficient in some scenarios, increase the polling timeout from 1us to 5us, which is still negligible in the context of a power domain transition. Also, replace the open-coded ktime_get_ns()/ cpu_relax() polling loop with readl_poll_timeout_atomic(). Cc: stable@vger.kernel.org Fixes: 670c672608a1 ("soc: bcm: bcm2835-pm: Add support for power domains under a new binding.") Signed-off-by: Maíra Canal Reviewed-by: Stefan Wahren Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 5ed633b212bda330b1bbc054daf2f607945ff91a Author: Luke Wang Date: Wed Mar 11 17:50:06 2026 +0800 mmc: sdhci: fix timing selection for 1-bit bus width commit 5e3486e64094c28a526543f1e8aa0d5964b7f02d upstream. When 1-bit bus width is used with HS200/HS400 capabilities set, mmc_select_hs200() returns 0 without actually switching. This causes mmc_select_timing() to skip mmc_select_hs(), leaving eMMC in legacy mode (26MHz) instead of High Speed SDR (52MHz). Per JEDEC eMMC spec section 5.3.2, 1-bit mode supports High Speed SDR. Drop incompatible HS200/HS400/UHS/DDR caps early so timing selection falls through to mmc_select_hs() correctly. Fixes: f2119df6b764 ("mmc: sd: add support for signal voltage switch procedure") Signed-off-by: Luke Wang Acked-by: Adrian Hunter Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit c8d5757ab6d6aef4272543c452970c6449f357fc Author: Matthew Schwartz Date: Mon Mar 2 13:07:17 2026 -0800 mmc: sdhci-pci-gli: fix GL9750 DMA write corruption commit 2b76e0cc7803e5ab561c875edaba7f6bbd87fbb0 upstream. The GL9750 SD host controller has intermittent data corruption during DMA write operations. The GM_BURST register's R_OSRC_Lmt field (bits 17:16), which limits outstanding DMA read requests from system memory, is not being cleared during initialization. The Windows driver sets R_OSRC_Lmt to zero, limiting requests to the smallest unit. Clear R_OSRC_Lmt to match the Windows driver behavior. This eliminates write corruption verified with f3write/f3read tests while maintaining DMA performance. Cc: stable@vger.kernel.org Fixes: e51df6ce668a ("mmc: host: sdhci-pci: Add Genesys Logic GL975x support") Closes: https://lore.kernel.org/linux-mmc/33d12807-5c72-41ce-8679-57aa11831fad@linux.dev/ Acked-by: Adrian Hunter Signed-off-by: Matthew Schwartz Reviewed-by: Ben Chuang Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 1343f110663dd79e0096d31586fcc04a80bac4d5 Author: Damien Le Moal Date: Fri Mar 20 12:48:01 2026 +0900 ata: libata-scsi: report correct sense field pointer in ata_scsiop_maint_in() commit e6d7eba23b666d85cacee0643be280d6ce1ebffc upstream. Commit 4ab7bb976343 ("ata: libata-scsi: Refactor ata_scsiop_maint_in()") modified ata_scsiop_maint_in() to directly call ata_scsi_set_invalid_field() to set the field pointer of the sense data of a failed MAINTENANCE IN command. However, in the case of an invalid command format, the sense data field incorrectly indicates byte 1 of the CDB. Fix this to indicate byte 2 of the command. Reported-by: Guenter Roeck Fixes: 4ab7bb976343 ("ata: libata-scsi: Refactor ata_scsiop_maint_in()") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit 2229b4cf973017fa6fe3554f59f841c4eee47508 Author: Damien Le Moal Date: Sun Mar 15 07:24:15 2026 +0900 ata: libata-core: disable LPM on ADATA SU680 SSD commit ce5ae93d1a216680460040c7c0465a6e3b629dec upstream. ADATA SU680 SSDs suffer from NCQ read and write commands timeouts or bus errors when link power management (LPM) is enabled. Flag these devices with the ATA_QUIRK_NOLPM quirk to prevent the use of LPM and avoid these command failures. Reported-by: Mohammad Khaled Bayan Closes: https://bugs.launchpad.net/ubuntu/+source/linux-hwe-6.17/+bug/2144060 Cc: stable@vger.kernel.org Tested-by: Mohammad-Khaled Bayan Signed-off-by: Damien Le Moal Reviewed-by: Martin K. Petersen Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit 08b2b65c63bb26dbb2a4e2adc2ce96e2929b8b60 Author: Zi Yan Date: Wed Mar 18 10:55:25 2026 -0400 mm/huge_memory: fix a folio_split() race condition with folio_try_get() During a pagecache folio split, the values in the related xarray should not be changed from the original folio at xarray split time until all after-split folios are well formed and stored in the xarray. Current use of xas_try_split() in __split_unmapped_folio() lets some after-split folios show up at wrong indices in the xarray. When these misplaced after-split folios are unfrozen, before correct folios are stored via __xa_store(), and grabbed by folio_try_get(), they are returned to userspace at wrong file indices, causing data corruption. More detailed explanation is at the bottom. The reproducer is at: https://github.com/dfinity/thp-madv-remove-test It 1. creates a memfd, 2. forks, 3. in the child process, maps the file with large folios (via shmem code path) and reads the mapped file continuously with 16 threads, 4. in the parent process, uses madvise(MADV_REMOVE) to punch poles in the large folio. Data corruption can be observed without the fix. Basically, data from a wrong page->index is returned. Fix it by using the original folio in xas_try_split() calls, so that folio_try_get() can get the right after-split folios after the original folio is unfrozen. Uniform split, split_huge_page*(), is not affected, since it uses xas_split_alloc() and xas_split() only once and stores the original folio in the xarray. Change xas_split() used in uniform split branch to use the original folio to avoid confusion. Fixes below points to the commit introduces the code, but folio_split() is used in a later commit 7460b470a131f ("mm/truncate: use folio_split() in truncate operation"). More details: For example, a folio f is split non-uniformly into f, f2, f3, f4 like below: +----------------+---------+----+----+ | f | f2 | f3 | f4 | +----------------+---------+----+----+ but the xarray would look like below after __split_unmapped_folio() is done: +----------------+---------+----+----+ | f | f2 | f3 | f3 | +----------------+---------+----+----+ After __split_unmapped_folio(), the code changes the xarray and unfreezes after-split folios: 1. unfreezes f2, __xa_store(f2) 2. unfreezes f3, __xa_store(f3) 3. unfreezes f4, __xa_store(f4), which overwrites the second f3 to f4. 4. unfreezes f. Meanwhile, a parallel filemap_get_entry() can read the second f3 from the xarray and use folio_try_get() on it at step 2 when f3 is unfrozen. Then, f3 is wrongly returned to user. After the fix, the xarray looks like below after __split_unmapped_folio(): +----------------+---------+----+----+ | f | f | f | f | +----------------+---------+----+----+ so that the race window no longer exists. [ziy@nvidia.com: move comment, per David] Link: https://lkml.kernel.org/r/5C9FA053-A4C6-4615-BE05-74E47A6462B3@nvidia.com Link: https://lkml.kernel.org/r/20260302203159.3208341-1-ziy@nvidia.com Fixes: 00527733d0dc ("mm/huge_memory: add two new (not yet used) functions for folio_split()") Signed-off-by: Zi Yan Reported-by: Bas van Dijk Closes: https://lore.kernel.org/all/CAKNNEtw5_kZomhkugedKMPOG-sxs5Q5OLumWJdiWXv+C9Yct0w@mail.gmail.com/ Tested-by: Lance Yang Reviewed-by: Lorenzo Stoakes Reviewed-by: Wei Yang Reviewed-by: Baolin Wang Cc: Barry Song Cc: David Hildenbrand Cc: Dev Jain Cc: Hugh Dickins Cc: Liam Howlett Cc: Matthew Wilcox (Oracle) Cc: Nico Pache Cc: Ryan Roberts Cc: Signed-off-by: Andrew Morton (cherry picked from commit 577a1f495fd78d8fb61b67ac3d3b595b01f6fcb0) Signed-off-by: Zi Yan Signed-off-by: Greg Kroah-Hartman commit edb6c2118293c1fba9cd11ca80ed043d2411a7e5 Author: Corey Minyard Date: Tue Mar 17 13:04:32 2026 -0400 ipmi:msghandler: Handle error returns from the SMI sender [ Upstream commit 62cd145453d577113f993efd025f258dd86aa183 ] It used to be, until recently, that the sender operation on the low level interfaces would not fail. That's not the case any more with recent changes. So check the return value from the sender operation, and propagate it back up from there and handle the errors in all places. Reported-by: Rafael J. Wysocki Fixes: bc3a9d217755 ("ipmi:si: Gracefully handle if the BMC is non-functional") Cc: stable@vger.kernel.org # 4.18 Signed-off-by: Corey Minyard Reviewed-by: Rafael J. Wysocki (Intel) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1e363c11cd2f13eaffe7b8c39a48ffb1a0e9f445 Author: Corey Minyard Date: Tue Mar 17 13:04:31 2026 -0400 ipmi: Consolidate the run to completion checking for xmit msgs lock [ Upstream commit 1d90e6c1a56f6ab83e5c9d30ded19e7ac8155713 ] It made things hard to read, move the check to a function. Signed-off-by: Corey Minyard Reviewed-by: Breno Leitao Stable-dep-of: 62cd145453d5 ("ipmi:msghandler: Handle error returns from the SMI sender") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 522acaae34aa7e05859260056b39c7c030592a0c Author: Tejun Heo Date: Tue Mar 17 13:21:52 2026 -0400 sched_ext: Disable preemption between scx_claim_exit() and kicking helper work [ Upstream commit 83236b2e43dba00bee5b82eb5758816b1a674f6a ] scx_claim_exit() atomically sets exit_kind, which prevents scx_error() from triggering further error handling. After claiming exit, the caller must kick the helper kthread work which initiates bypass mode and teardown. If the calling task gets preempted between claiming exit and kicking the helper work, and the BPF scheduler fails to schedule it back (since error handling is now disabled), the helper work is never queued, bypass mode never activates, tasks stop being dispatched, and the system wedges. Disable preemption across scx_claim_exit() and the subsequent work kicking in all callers - scx_disable() and scx_vexit(). Add lockdep_assert_preemption_disabled() to scx_claim_exit() to enforce the requirement. Fixes: f0e1a0643a59 ("sched_ext: Implement BPF extensible scheduler class") Cc: stable@vger.kernel.org # v6.12+ Reviewed-by: Andrea Righi Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c1b8245c0a38787533dd7da0c4e0e68f89a623c0 Author: Tejun Heo Date: Tue Mar 17 13:21:51 2026 -0400 sched_ext: Simplify breather mechanism with scx_aborting flag [ Upstream commit a69040ed57f50156e5452474d25c79b9e62075d0 ] The breather mechanism was introduced in 62dcbab8b0ef ("sched_ext: Avoid live-locking bypass mode switching") and e32c260195e6 ("sched_ext: Enable the ops breather and eject BPF scheduler on softlockup") to prevent live-locks by injecting delays when CPUs are trapped in dispatch paths. Currently, it uses scx_breather_depth (atomic_t) and scx_in_softlockup (unsigned long) with separate increment/decrement and cleanup operations. The breather is only activated when aborting, so tie it directly to the exit mechanism. Replace both variables with scx_aborting flag set when exit is claimed and cleared after bypass is enabled. Introduce scx_claim_exit() to consolidate exit_kind claiming and breather enablement. This eliminates scx_clear_softlockup() and simplifies scx_softlockup() and scx_bypass(). The breather mechanism will be replaced by a different abort mechanism in a future patch. This simplification prepares for that change. Reviewed-by: Dan Schatzberg Reviewed-by: Emil Tsalapatis Acked-by: Andrea Righi Signed-off-by: Tejun Heo Stable-dep-of: 83236b2e43db ("sched_ext: Disable preemption between scx_claim_exit() and kicking helper work") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c44198f25fdfecc0ec0fe366bf8a47fe17d8e229 Author: Tejun Heo Date: Tue Mar 17 13:29:35 2026 -0400 sched_ext: Fix starvation of scx_enable() under fair-class saturation [ Upstream commit b06ccbabe2506fd70b9167a644978b049150224a ] During scx_enable(), the READY -> ENABLED task switching loop changes the calling thread's sched_class from fair to ext. Since fair has higher priority than ext, saturating fair-class workloads can indefinitely starve the enable thread, hanging the system. This was introduced when the enable path switched from preempt_disable() to scx_bypass() which doesn't protect against fair-class starvation. Note that the original preempt_disable() protection wasn't complete either - in partial switch modes, the calling thread could still be starved after preempt_enable() as it may have been switched to ext class. Fix it by offloading the enable body to a dedicated system-wide RT (SCHED_FIFO) kthread which cannot be starved by either fair or ext class tasks. scx_enable() lazily creates the kthread on first use and passes the ops pointer through a struct scx_enable_cmd containing the kthread_work, then synchronously waits for completion. The workfn runs on a different kthread from sch->helper (which runs disable_work), so it can safely flush disable_work on the error path without deadlock. Fixes: 8c2090c504e9 ("sched_ext: Initialize in bypass mode") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2f3dea284c761c890d676f77d5e55c0c496b4ef4 Author: Christian Brauner Date: Tue Mar 17 16:02:24 2026 -0400 nsfs: tighten permission checks for ns iteration ioctls [ Upstream commit e6b899f08066e744f89df16ceb782e06868bd148 ] Even privileged services should not necessarily be able to see other privileged service's namespaces so they can't leak information to each other. Use may_see_all_namespaces() helper that centralizes this policy until the nstree adapts. Link: https://patch.msgid.link/20260226-work-visibility-fixes-v1-1-d2c2853313bd@kernel.org Fixes: a1d220d9dafa ("nsfs: iterate through mount namespaces") Reviewed-by: Jeff Layton Cc: stable@kernel.org # v6.12+ Signed-off-by: Christian Brauner [ context ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 05edc78eb4699e8e000a62aaa8dace50a17e19e3 Author: Shuicheng Lin Date: Tue Mar 17 20:46:14 2026 -0400 drm/xe/sync: Fix user fence leak on alloc failure [ Upstream commit 0879c3f04f67e2a1677c25dcc24669ce21eb6a6c ] When dma_fence_chain_alloc() fails, properly release the user fence reference to prevent a memory leak. Fixes: 0995c2fc39b0 ("drm/xe: Enforce correct user fence signaling order using") Cc: Matthew Brost Signed-off-by: Shuicheng Lin Reviewed-by: Matthew Brost Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260219233516.2938172-6-shuicheng.lin@intel.com (cherry picked from commit a5d5634cde48a9fcd68c8504aa07f89f175074a0) Cc: stable@vger.kernel.org Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 528aaa37d3c3fc4c7d1199ff28e3b0c64e6675ac Author: Shengming Hu Date: Wed Mar 18 09:13:53 2026 -0400 fgraph: Fix thresh_return nosleeptime double-adjust [ Upstream commit b96d0c59cdbb2a22b2545f6f3d5c6276b05761dd ] trace_graph_thresh_return() called handle_nosleeptime() and then delegated to trace_graph_return(), which calls handle_nosleeptime() again. When sleep-time accounting is disabled this double-adjusts calltime and can produce bogus durations (including underflow). Fix this by computing rettime once, applying handle_nosleeptime() only once, using the adjusted calltime for threshold comparison, and writing the return event directly via __trace_graph_return() when the threshold is met. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260221113314048jE4VRwIyZEALiYByGK0My@zte.com.cn Fixes: 3c9880f3ab52b ("ftrace: Use a running sleeptime instead of saving on shadow stack") Acked-by: Masami Hiramatsu (Google) Signed-off-by: Shengming Hu Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 407cc37c21d51f9b9d4d20204b04890880cfa6ae Author: Thorsten Blum Date: Wed Mar 18 09:14:44 2026 -0400 ksmbd: Don't log keys in SMB3 signing and encryption key generation [ Upstream commit 441336115df26b966575de56daf7107ed474faed ] When KSMBD_DEBUG_AUTH logging is enabled, generate_smb3signingkey() and generate_smb3encryptionkey() log the session, signing, encryption, and decryption key bytes. Remove the logs to avoid exposing credentials. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Acked-by: Namjae Jeon Signed-off-by: Steve French [ Context ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 58f5d34f88e8f00910b692537f7b2efdb8c3705d Author: Kevin Hao Date: Wed Mar 18 10:59:56 2026 -0400 net: macb: Shuffle the tx ring before enabling tx [ Upstream commit 881a0263d502e1a93ebc13a78254e9ad19520232 ] Quanyang observed that when using an NFS rootfs on an AMD ZynqMp board, the rootfs may take an extended time to recover after a suspend. Upon investigation, it was determined that the issue originates from a problem in the macb driver. According to the Zynq UltraScale TRM [1], when transmit is disabled, the transmit buffer queue pointer resets to point to the address specified by the transmit buffer queue base address register. In the current implementation, the code merely resets `queue->tx_head` and `queue->tx_tail` to '0'. This approach presents several issues: - Packets already queued in the tx ring are silently lost, leading to memory leaks since the associated skbs cannot be released. - Concurrent write access to `queue->tx_head` and `queue->tx_tail` may occur from `macb_tx_poll()` or `macb_start_xmit()` when these values are reset to '0'. - The transmission may become stuck on a packet that has already been sent out, with its 'TX_USED' bit set, but has not yet been processed. However, due to the manipulation of 'queue->tx_head' and 'queue->tx_tail', `macb_tx_poll()` incorrectly assumes there are no packets to handle because `queue->tx_head == queue->tx_tail`. This issue is only resolved when a new packet is placed at this position. This is the root cause of the prolonged recovery time observed for the NFS root filesystem. To resolve this issue, shuffle the tx ring and tx skb array so that the first unsent packet is positioned at the start of the tx ring. Additionally, ensure that updates to `queue->tx_head` and `queue->tx_tail` are properly protected with the appropriate lock. [1] https://docs.amd.com/v/u/en-US/ug1085-zynq-ultrascale-trm Fixes: bf9cf80cab81 ("net: macb: Fix tx/rx malfunction after phy link down and up") Reported-by: Quanyang Wang Signed-off-by: Kevin Hao Cc: stable@vger.kernel.org Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260307-zynqmp-v2-1-6ef98a70e1d0@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0cbc0d719ecc1cf2f5326c11aa1bff4cad3cf12d Author: Théo Lebrun Date: Wed Mar 18 10:59:55 2026 -0400 net: macb: sort #includes [ Upstream commit 8ebeef3d01c8b9e5807afdf1d38547f4625d0e4e ] Sort #include preprocessor directives. Reviewed-by: Andrew Lunn Reviewed-by: Sean Anderson Signed-off-by: Théo Lebrun Link: https://patch.msgid.link/20251014-macb-cleanup-v1-15-31cd266e22cd@bootlin.com Signed-off-by: Jakub Kicinski Stable-dep-of: 881a0263d502 ("net: macb: Shuffle the tx ring before enabling tx") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8a7d29b8bda144d44e61df1b2705b1d4378f4e44 Author: Ville Syrjälä Date: Wed Mar 18 12:14:17 2026 -0400 drm/i915/vrr: Configure VRR timings after enabling TRANS_DDI_FUNC_CTL [ Upstream commit 237aab549676288d9255bb8dcc284738e56eaa31 ] Apparently ICL may hang with an MCE if we write TRANS_VRR_VMAX/FLIPLINE before enabling TRANS_DDI_FUNC_CTL. Personally I was only able to reproduce a hang (on an Dell XPS 7390 2-in-1) with an external display connected via a dock using a dodgy type-C cable that made the link training fail. After the failed link training the machine would hang. TGL seemed immune to the problem for whatever reason. BSpec does tell us to configure VRR after enabling TRANS_DDI_FUNC_CTL as well. The DMC firmware also does the VRR restore in two stages: - first stage seems to be unconditional and includes TRANS_VRR_CTL and a few other VRR registers, among other things - second stage is conditional on the DDI being enabled, and includes TRANS_DDI_FUNC_CTL and TRANS_VRR_VMAX/VMIN/FLIPLINE, among other things So let's reorder the steps to match to avoid the hang, and toss in an extra WARN to make sure we don't screw this up later. BSpec: 22243 Cc: stable@vger.kernel.org Cc: Ankit Nautiyal Reported-by: Benjamin Tissoires Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15777 Tested-by: Benjamin Tissoires Fixes: dda7dcd9da73 ("drm/i915/vrr: Use fixed timings for platforms that support VRR") Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20260303095414.4331-1-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal (cherry picked from commit 93f3a267c3dd4d811b224bb9e179a10d81456a74) Signed-off-by: Tvrtko Ursulin Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1aa7745b97fda5c099b0a3321a45129430afa14c Author: Ville Syrjälä Date: Wed Mar 18 12:14:16 2026 -0400 drm/i915/vrr: Move HAS_VRR() check into intel_vrr_set_transcoder_timings() [ Upstream commit 78ea8eb5b6235b3ef68fa0fb8ffe0b3b490baf38 ] Reduce the clutter in hsw_configure_cpu_transcoder() a bit by moving the HAS_VRR() check into intel_vrr_set_transcoder_timings(). Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-18-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal Stable-dep-of: 237aab549676 ("drm/i915/vrr: Configure VRR timings after enabling TRANS_DDI_FUNC_CTL") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c3aa7b837920c844d5ae0dd3dbaeb465a461de40 Author: Varun Gupta Date: Wed Mar 18 16:48:15 2026 -0400 drm/xe: Fix memory leak in xe_vm_madvise_ioctl [ Upstream commit 0cfe9c4838f1147713f6b5c02094cd4dc0c598fa ] When check_bo_args_are_sane() validation fails, jump to the new free_vmas cleanup label to properly free the allocated resources. This ensures proper cleanup in this error path. Fixes: 293032eec4ba ("drm/xe/bo: Update atomic_access attribute on madvise") Cc: stable@vger.kernel.org # v6.18+ Reviewed-by: Shuicheng Lin Signed-off-by: Varun Gupta Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20260223175145.1532801-1-varun.gupta@intel.com Signed-off-by: Tejas Upadhyay (cherry picked from commit 29bd06faf727a4b76663e4be0f7d770e2d2a7965) Signed-off-by: Rodrigo Vivi [ changed old goto target from `madv_fini` to `unlock_vm` ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f655467a9973f964b267871e5fef533ad5014494 Author: Shyam Prasad N Date: Wed Mar 18 17:15:57 2026 -0400 cifs: open files should not hold ref on superblock [ Upstream commit 340cea84f691c5206561bb2e0147158fe02070be ] Today whenever we deal with a file, in addition to holding a reference on the dentry, we also get a reference on the superblock. This happens in two cases: 1. when a new cinode is allocated 2. when an oplock break is being processed The reasoning for holding the superblock ref was to make sure that when umount happens, if there are users of inodes and dentries, it does not try to clean them up and wait for the last ref to superblock to be dropped by last of such users. But the side effect of doing that is that umount silently drops a ref on the superblock and we could have deferred closes and lease breaks still holding these refs. Ideally, we should ensure that all of these users of inodes and dentries are cleaned up at the time of umount, which is what this code is doing. This code change allows these code paths to use a ref on the dentry (and hence the inode). That way, umount is ensured to clean up SMB client resources when it's the last ref on the superblock (For ex: when same objects are shared). The code change also moves the call to close all the files in deferred close list to the umount code path. It also waits for oplock_break workers to be flushed before calling kill_anon_super (which eventually frees up those objects). Fixes: 24261fc23db9 ("cifs: delay super block destruction until all cifsFileInfo objects are gone") Fixes: 705c79101ccf ("smb: client: fix use-after-free in cifs_oplock_break") Cc: Signed-off-by: Shyam Prasad N Signed-off-by: Steve French [ replaced kmalloc_obj() with kmalloc(sizeof(...)) ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6f502049a96b368ea6646c49d9520d6f69a101fa Author: Thorsten Blum Date: Wed Mar 18 20:41:19 2026 -0400 crypto: atmel-sha204a - Fix OOM ->tfm_count leak [ Upstream commit d240b079a37e90af03fd7dfec94930eb6c83936e ] If memory allocation fails, decrement ->tfm_count to avoid blocking future reads. Cc: stable@vger.kernel.org Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator") Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu [ adapted kmalloc_obj() macro to kmalloc(sizeof()) ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2d7238eec40ad4b9a5aa553c7a9ba2bcdf90706c Author: Breno Leitao Date: Wed Mar 18 21:00:09 2026 -0400 netconsole: fix sysdata_release_enabled_show checking wrong flag [ Upstream commit 5af6e8b54927f7a8d3c7fd02b1bdc09e93d5c079 ] sysdata_release_enabled_show() checks SYSDATA_TASKNAME instead of SYSDATA_RELEASE, causing the configfs release_enabled attribute to reflect the taskname feature state rather than the release feature state. This is a copy-paste error from the adjacent sysdata_taskname_enabled_show() function. The corresponding _store function already uses the correct SYSDATA_RELEASE flag. Fixes: 343f90227070 ("netconsole: implement configfs for release_enabled") Signed-off-by: Breno Leitao Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260302-sysdata_release_fix-v1-1-e5090f677c7c@debian.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f13fe6794726755a43090cb680c4c58cea6aa5f1 Author: Mehul Rao Date: Thu Mar 19 08:53:03 2026 -0400 ublk: fix NULL pointer dereference in ublk_ctrl_set_size() [ Upstream commit 25966fc097691e5c925ad080f64a2f19c5fd940a ] ublk_ctrl_set_size() unconditionally dereferences ub->ub_disk via set_capacity_and_notify() without checking if it is NULL. ub->ub_disk is NULL before UBLK_CMD_START_DEV completes (it is only assigned in ublk_ctrl_start_dev()) and after UBLK_CMD_STOP_DEV runs (ublk_detach_disk() sets it to NULL). Since the UBLK_CMD_UPDATE_SIZE handler performs no state validation, a user can trigger a NULL pointer dereference by sending UPDATE_SIZE to a device that has been added but not yet started, or one that has been stopped. Fix this by checking ub->ub_disk under ub->mutex before dereferencing it, and returning -ENODEV if the disk is not available. Fixes: 98b995660bff ("ublk: Add UBLK_U_CMD_UPDATE_SIZE") Cc: stable@vger.kernel.org Signed-off-by: Mehul Rao Reviewed-by: Ming Lei Signed-off-by: Jens Axboe [ adapted `&header` to `header` ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bea2848ba20e147f743aa96b92e5b90686cad92d Author: Tiezhu Yang Date: Fri Mar 20 09:52:59 2026 -0400 LoongArch: Check return values for set_memory_{rw,rox} [ Upstream commit 431ce839dad66d0d56fb604785452c6a57409f35 ] set_memory_rw() and set_memory_rox() may fail, so we should check the return values and return immediately in larch_insn_text_copy(). Cc: stable@vger.kernel.org Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen [ kept `stop_machine()` instead of `stop_machine_cpuslocked()` ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fc9d6999ebfa23c604eaaf5000d187857a3e359f Author: Kevin Hao Date: Fri Mar 20 09:53:02 2026 -0400 net: macb: Reinitialize tx/rx queue pointer registers and rx ring during resume [ Upstream commit 718d0766ce4c7634ce62fa78b526ea7263487edd ] On certain platforms, such as AMD Versal boards, the tx/rx queue pointer registers are cleared after suspend, and the rx queue pointer register is also disabled during suspend if WOL is enabled. Previously, we assumed that these registers would be restored by macb_mac_link_up(). However, in commit bf9cf80cab81, macb_init_buffers() was moved from macb_mac_link_up() to macb_open(). Therefore, we should call macb_init_buffers() to reinitialize the tx/rx queue pointer registers during resume. Due to the reset of these two registers, we also need to adjust the tx/rx rings accordingly. The tx ring will be handled by gem_shuffle_tx_rings() in macb_mac_link_up(), so we only need to initialize the rx ring here. Fixes: bf9cf80cab81 ("net: macb: Fix tx/rx malfunction after phy link down and up") Reported-by: Quanyang Wang Signed-off-by: Kevin Hao Tested-by: Quanyang Wang Cc: stable@vger.kernel.org Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260312-macb-versal-v1-2-467647173fa4@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4e1436e0b13c667baeb5e283956016f23f959193 Author: Kevin Hao Date: Fri Mar 20 09:53:01 2026 -0400 net: macb: Introduce gem_init_rx_ring() [ Upstream commit 1a7124ecd655bcaf1845197fe416aa25cff4c3ea ] Extract the initialization code for the GEM RX ring into a new function. This change will be utilized in a subsequent patch. No functional changes are introduced. Signed-off-by: Kevin Hao Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260312-macb-versal-v1-1-467647173fa4@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: 718d0766ce4c ("net: macb: Reinitialize tx/rx queue pointer registers and rx ring during resume") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4ab7c9fa0a477ebe4eb40847f85bfbcb70dfd653 Author: Jouni Högander Date: Wed Mar 4 13:30:11 2026 +0200 drm/i915/psr: Write DSC parameters on Selective Update in ET mode commit 5923a6e0459fdd3edac4ad5abccb24d777d8f1b6 upstream. There are slice row per frame and pic height parameters in DSC that needs to be configured on every Selective Update in Early Transport mode. Use helper provided by DSC code to configure these on Selective Update when in Early Transport mode. Also fill crtc_state->psr2_su_area with full frame area on full frame update for DSC calculation. v2: move psr2_su_area under skip_sel_fetch_set_loop label Bspec: 68927, 71709 Fixes: 467e4e061c44 ("drm/i915/psr: Enable psr2 early transport as possible") Cc: # v6.9+ Signed-off-by: Jouni Högander Reviewed-by: Ankit Nautiyal Link: https://patch.msgid.link/20260304113011.626542-5-jouni.hogander@intel.com (cherry picked from commit 3140af2fab505a4cd47d516284529bf1585628be) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit a5cdbbc77147047219e7f35da4c778d30778e754 Author: Jouni Högander Date: Wed Mar 4 13:30:10 2026 +0200 drm/i915/dsc: Add helper for writing DSC Selective Update ET parameters commit bb5f1cd10101c2567bff4d0e760b74aee7c42f44 upstream. There are slice row per frame and pic height configuration in DSC Selective Update Parameter Set 1 register. Add helper for configuring these. v2: - Add WARN_ON_ONCE if vdsc instances per pipe > 2 - instead of checking vdsc instances per pipe being > 1 check == 2 Bspec: 71709 Signed-off-by: Jouni Högander Reviewed-by: Ankit Nautiyal Link: https://patch.msgid.link/20260304113011.626542-4-jouni.hogander@intel.com (cherry picked from commit c8698d61aeb3f70fe33761ee9d3d0e131b5bc2eb) Signed-off-by: Tvrtko Ursulin [tursulin: fixup forward declaration conflict] Signed-off-by: Greg Kroah-Hartman commit 291d19d586a5af8d24eaef71e53509b5e093c2ee Author: Jouni Högander Date: Wed Mar 4 13:30:09 2026 +0200 drm/i915/dsc: Add Selective Update register definitions commit c2c79c6d5b939ae8a42ddb884f576bddae685672 upstream. Add definitions for DSC_SU_PARAMETER_SET_0_DSC0 and DSC_SU_PARAMETER_SET_0_DSC1 registers. These are for Selective Update Early Transport configuration. Bspec: 71709 Signed-off-by: Jouni Högander Reviewed-by: Ankit Nautiyal Link: https://patch.msgid.link/20260304113011.626542-3-jouni.hogander@intel.com (cherry picked from commit 24f96d903daf3dcf8fafe84d3d22b80ef47ba493) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit 3d80ebe6d1b7bc9ad20fd9b0c1a0c56d804f8a0a Author: Namjae Jeon Date: Fri Mar 13 10:01:29 2026 +0900 ksmbd: use volume UUID in FS_OBJECT_ID_INFORMATION commit 3a64125730cabc34fccfbc230c2667c2e14f7308 upstream. Use sb->s_uuid for a proper volume identifier as the primary choice. For filesystems that do not provide a UUID, fall back to stfs.f_fsid obtained from vfs_statfs(). Cc: stable@vger.kernel.org Reported-by: Hyunwoo Kim Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 9feb2d1bf86d9e5e66b8565f37f8d3a7d281a772 Author: Namjae Jeon Date: Fri Mar 13 10:00:58 2026 +0900 ksmbd: unset conn->binding on failed binding request commit 282343cf8a4a5a3603b1cb0e17a7083e4a593b03 upstream. When a multichannel SMB2_SESSION_SETUP request with SMB2_SESSION_REQ_FLAG_BINDING fails ksmbd sets conn->binding = true but never clears it on the error path. This leaves the connection in a binding state where all subsequent ksmbd_session_lookup_all() calls fall back to the global sessions table. This fix it by clearing conn->binding = false in the error path. Cc: stable@vger.kernel.org Reported-by: Hyunwoo Kim Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 9ee803bfdba0cf739038dbdabdd4c02582c8f2b2 Author: Paulo Alcantara Date: Fri Mar 13 00:03:38 2026 -0300 smb: client: fix krb5 mount with username option commit 12b4c5d98cd7ca46d5035a57bcd995df614c14e1 upstream. Customer reported that some of their krb5 mounts were failing against a single server as the client was trying to mount the shares with wrong credentials. It turned out the client was reusing SMB session from first mount to try mounting the other shares, even though a different username= option had been specified to the other mounts. By using username mount option along with sec=krb5 to search for principals from keytab is supported by cifs.upcall(8) since cifs-utils-4.8. So fix this by matching username mount option in match_session() even with Kerberos. For example, the second mount below should fail with -ENOKEY as there is no 'foobar' principal in keytab (/etc/krb5.keytab). The client ends up reusing SMB session from first mount to perform the second one, which is wrong. ``` $ ktutil ktutil: add_entry -password -p testuser -k 1 -e aes256-cts Password for testuser@ZELDA.TEST: ktutil: write_kt /etc/krb5.keytab ktutil: quit $ klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- ---------------------------------------------------------------- 1 testuser@ZELDA.TEST (aes256-cts-hmac-sha1-96) $ mount.cifs //w22-root2/scratch /mnt/1 -o sec=krb5,username=testuser $ mount.cifs //w22-root2/scratch /mnt/2 -o sec=krb5,username=foobar $ mount -t cifs | grep -Po 'username=\K\w+' testuser testuser ``` Reported-by: Oscar Santos Signed-off-by: Paulo Alcantara (Red Hat) Cc: David Howells Cc: linux-cifs@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit e7ff754e339e3d5ce29aa9f95352d0186df8fbd9 Author: Lukas Johannes Möller Date: Tue Mar 10 21:59:47 2026 +0000 Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access commit dd815e6e3918dc75a49aaabac36e4f024d675101 upstream. l2cap_information_rsp() checks that cmd_len covers the fixed l2cap_info_rsp header (type + result, 4 bytes) but then reads rsp->data without verifying that the payload is present: - L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp->data), which reads 4 bytes past the header (needs cmd_len >= 8). - L2CAP_IT_FIXED_CHAN reads rsp->data[0], 1 byte past the header (needs cmd_len >= 5). A truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an out-of-bounds read of adjacent skb data. Guard each data access with the required payload length check. If the payload is too short, skip the read and let the state machine complete with safe defaults (feat_mask and remote_fixed_chan remain zero from kzalloc), so the info timer cleanup and l2cap_conn_start() still run and the connection is not stalled. Fixes: 4e8402a3f884 ("[Bluetooth] Retrieve L2CAP features mask on connection setup") Cc: stable@vger.kernel.org Signed-off-by: Lukas Johannes Möller Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 5a1ea296f8589ce8f1e3141b2b123b34ad010e19 Author: Lukas Johannes Möller Date: Tue Mar 10 21:59:46 2026 +0000 Bluetooth: L2CAP: Fix type confusion in l2cap_ecred_reconf_rsp() commit 15145675690cab2de1056e7ed68e59cbd0452529 upstream. l2cap_ecred_reconf_rsp() casts the incoming data to struct l2cap_ecred_conn_rsp (the ECRED *connection* response, 8 bytes with result at offset 6) instead of struct l2cap_ecred_reconf_rsp (2 bytes with result at offset 0). This causes two problems: - The sizeof(*rsp) length check requires 8 bytes instead of the correct 2, so valid L2CAP_ECRED_RECONF_RSP packets are rejected with -EPROTO. - rsp->result reads from offset 6 instead of offset 0, returning wrong data when the packet is large enough to pass the check. Fix by using the correct type. Also pass the already byte-swapped result variable to BT_DBG instead of the raw __le16 field. Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode") Cc: stable@vger.kernel.org Signed-off-by: Lukas Johannes Möller Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 1768244b85dd2882ccf64ee21a5a9929cfb37267 Author: AlanSong-oc Date: Fri Mar 13 16:01:49 2026 +0800 crypto: padlock-sha - Disable for Zhaoxin processor commit ebba09f198078b7a2565004104ef762d1148e7f0 upstream. For Zhaoxin processors, the XSHA1 instruction requires the total memory allocated at %rdi register must be 32 bytes, while the XSHA1 and XSHA256 instruction doesn't perform any operation when %ecx is zero. Due to these requirements, the current padlock-sha driver does not work correctly with Zhaoxin processors. It cannot pass the self-tests and therefore does not activate the driver on Zhaoxin processors. This issue has been reported in Debian [1]. The self-tests fail with the following messages [2]: alg: shash: sha1-padlock-nano test failed (wrong result) on test vector 0, cfg="init+update+final aligned buffer" alg: self-tests for sha1 using sha1-padlock-nano failed (rc=-22) alg: shash: sha256-padlock-nano test failed (wrong result) on test vector 0, cfg="init+update+final aligned buffer" alg: self-tests for sha256 using sha256-padlock-nano failed (rc=-22) Disable the padlock-sha driver on Zhaoxin processors with the CPU family 0x07 and newer. Following the suggestion in [3], support for PHE will be added to lib/crypto/ instead. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1113996 [2] https://linux-hardware.org/?probe=271fabb7a4&log=dmesg [3] https://lore.kernel.org/linux-crypto/aUI4CGp6kK7mxgEr@gondor.apana.org.au/ Fixes: 63dc06cd12f9 ("crypto: padlock-sha - Use API partial block handling") Cc: stable@vger.kernel.org Signed-off-by: AlanSong-oc Link: https://lore.kernel.org/r/20260313080150.9393-2-AlanSong-oc@zhaoxin.com Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 5a86d4e920d9783a198e39cf53f0e410fba5fbd6 Author: Felix Fietkau Date: Thu Mar 5 17:08:12 2026 +0000 mac80211: fix crash in ieee80211_chan_bw_change for AP_VLAN stations commit 672e5229e1ecfc2a3509b53adcb914d8b024a853 upstream. ieee80211_chan_bw_change() iterates all stations and accesses link->reserved.oper via sta->sdata->link[link_id]. For stations on AP_VLAN interfaces (e.g. 4addr WDS clients), sta->sdata points to the VLAN sdata, whose link never participates in chanctx reservations. This leaves link->reserved.oper zero-initialized with chan == NULL, causing a NULL pointer dereference in __ieee80211_sta_cap_rx_bw() when accessing chandef->chan->band during CSA. Resolve the VLAN sdata to its parent AP sdata using get_bss_sdata() before accessing link data. Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau Link: https://patch.msgid.link/20260305170812.2904208-1-nbd@nbd.name [also change sta->sdata in ARRAY_SIZE even if it doesn't matter] Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 0e35db29fc5a97a8553f7c2d3a2ba730e46b1ee8 Author: Yang Yang Date: Sat Mar 14 07:11:27 2026 +0000 batman-adv: avoid OGM aggregation when skb tailroom is insufficient commit 0d4aef630be9d5f9c1227d07669c26c4383b5ad0 upstream. When OGM aggregation state is toggled at runtime, an existing forwarded packet may have been allocated with only packet_len bytes, while a later packet can still be selected for aggregation. Appending in this case can hit skb_put overflow conditions. Reject aggregation when the target skb tailroom cannot accommodate the new packet. The caller then falls back to creating a new forward packet instead of appending. Fixes: c6c8fea29769 ("net: Add batman-adv meshing protocol") Cc: stable@vger.kernel.org Reported-by: Yifan Wu Reported-by: Juefei Pu Signed-off-by: Yuan Tan Signed-off-by: Xin Liu Signed-off-by: Ao Zhou Signed-off-by: Yang Yang Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Greg Kroah-Hartman commit f5ed9e50c08724b14687af5e7c05fed2b810a24f Author: Helge Deller Date: Mon Mar 9 15:16:37 2026 +0100 parisc: Flush correct cache in cacheflush() syscall commit 2c98a8fbd6aa647414c6248dacf254ebe91c79ad upstream. The assembly flush instructions were swapped for I- and D-cache flags: SYSCALL_DEFINE3(cacheflush, ...) { if (cache & DCACHE) { "fic ...\n" } if (cache & ICACHE && error == 0) { "fdc ...\n" } Fix it by using fdc for DCACHE, and fic for ICACHE flushing. Reported-by: Felix Lechner Fixes: c6d96328fecd ("parisc: Add cacheflush() syscall") Cc: # v6.5+ Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 19aa416eed9e4aaf1bbe8da0f7bd9a9be31158c8 Author: Junrui Luo Date: Sat Mar 14 17:41:04 2026 +0800 bnxt_en: fix OOB access in DBG_BUF_PRODUCER async event handler commit 64dcbde7f8f870a4f2d9daf24ffb06f9748b5dd3 upstream. The ASYNC_EVENT_CMPL_EVENT_ID_DBG_BUF_PRODUCER handler in bnxt_async_event_process() uses a firmware-supplied 'type' field directly as an index into bp->bs_trace[] without bounds validation. The 'type' field is a 16-bit value extracted from DMA-mapped completion ring memory that the NIC writes directly to host RAM. A malicious or compromised NIC can supply any value from 0 to 65535, causing an out-of-bounds access into kernel heap memory. The bnxt_bs_trace_check_wrap() call then dereferences bs_trace->magic_byte and writes to bs_trace->last_offset and bs_trace->wrapped, leading to kernel memory corruption or a crash. Fix by adding a bounds check and defining BNXT_TRACE_MAX as DBG_LOG_BUFFER_FLUSH_REQ_TYPE_ERR_QPC_TRACE + 1 to cover all currently defined firmware trace types (0x0 through 0xc). Fixes: 84fcd9449fd7 ("bnxt_en: Manage the FW trace context memory") Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Reviewed-by: Michael Chan Link: https://patch.msgid.link/SYBPR01MB7881A253A1C9775D277F30E9AF42A@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1f4714065b2bcbb0a4013fd355b84b848e6cc345 Author: Fedor Pchelkin Date: Mon Mar 16 13:38:24 2026 +0300 net: macb: fix use-after-free access to PTP clock commit 8da13e6d63c1a97f7302d342c89c4a56a55c7015 upstream. PTP clock is registered on every opening of the interface and destroyed on every closing. However it may be accessed via get_ts_info ethtool call which is possible while the interface is just present in the kernel. BUG: KASAN: use-after-free in ptp_clock_index+0x47/0x50 drivers/ptp/ptp_clock.c:426 Read of size 4 at addr ffff8880194345cc by task syz.0.6/948 CPU: 1 PID: 948 Comm: syz.0.6 Not tainted 6.1.164+ #109 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8d/0xba lib/dump_stack.c:106 print_address_description mm/kasan/report.c:316 [inline] print_report+0x17f/0x496 mm/kasan/report.c:420 kasan_report+0xd9/0x180 mm/kasan/report.c:524 ptp_clock_index+0x47/0x50 drivers/ptp/ptp_clock.c:426 gem_get_ts_info+0x138/0x1e0 drivers/net/ethernet/cadence/macb_main.c:3349 macb_get_ts_info+0x68/0xb0 drivers/net/ethernet/cadence/macb_main.c:3371 __ethtool_get_ts_info+0x17c/0x260 net/ethtool/common.c:558 ethtool_get_ts_info net/ethtool/ioctl.c:2367 [inline] __dev_ethtool net/ethtool/ioctl.c:3017 [inline] dev_ethtool+0x2b05/0x6290 net/ethtool/ioctl.c:3095 dev_ioctl+0x637/0x1070 net/core/dev_ioctl.c:510 sock_do_ioctl+0x20d/0x2c0 net/socket.c:1215 sock_ioctl+0x577/0x6d0 net/socket.c:1320 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x18c/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:46 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 457: kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:699 [inline] ptp_clock_register+0x144/0x10e0 drivers/ptp/ptp_clock.c:235 gem_ptp_init+0x46f/0x930 drivers/net/ethernet/cadence/macb_ptp.c:375 macb_open+0x901/0xd10 drivers/net/ethernet/cadence/macb_main.c:2920 __dev_open+0x2ce/0x500 net/core/dev.c:1501 __dev_change_flags+0x56a/0x740 net/core/dev.c:8651 dev_change_flags+0x92/0x170 net/core/dev.c:8722 do_setlink+0xaf8/0x3a80 net/core/rtnetlink.c:2833 __rtnl_newlink+0xbf4/0x1940 net/core/rtnetlink.c:3608 rtnl_newlink+0x63/0xa0 net/core/rtnetlink.c:3655 rtnetlink_rcv_msg+0x3c6/0xed0 net/core/rtnetlink.c:6150 netlink_rcv_skb+0x15d/0x430 net/netlink/af_netlink.c:2511 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x6d7/0xa30 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x97e/0xeb0 net/netlink/af_netlink.c:1872 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x14b/0x180 net/socket.c:730 __sys_sendto+0x320/0x3b0 net/socket.c:2152 __do_sys_sendto net/socket.c:2164 [inline] __se_sys_sendto net/socket.c:2160 [inline] __x64_sys_sendto+0xdc/0x1b0 net/socket.c:2160 do_syscall_x64 arch/x86/entry/common.c:46 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 938: kasan_slab_free include/linux/kasan.h:177 [inline] slab_free_hook mm/slub.c:1729 [inline] slab_free_freelist_hook mm/slub.c:1755 [inline] slab_free mm/slub.c:3687 [inline] __kmem_cache_free+0xbc/0x320 mm/slub.c:3700 device_release+0xa0/0x240 drivers/base/core.c:2507 kobject_cleanup lib/kobject.c:681 [inline] kobject_release lib/kobject.c:712 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1cd/0x350 lib/kobject.c:729 put_device+0x1b/0x30 drivers/base/core.c:3805 ptp_clock_unregister+0x171/0x270 drivers/ptp/ptp_clock.c:391 gem_ptp_remove+0x4e/0x1f0 drivers/net/ethernet/cadence/macb_ptp.c:404 macb_close+0x1c8/0x270 drivers/net/ethernet/cadence/macb_main.c:2966 __dev_close_many+0x1b9/0x310 net/core/dev.c:1585 __dev_close net/core/dev.c:1597 [inline] __dev_change_flags+0x2bb/0x740 net/core/dev.c:8649 dev_change_flags+0x92/0x170 net/core/dev.c:8722 dev_ifsioc+0x151/0xe00 net/core/dev_ioctl.c:326 dev_ioctl+0x33e/0x1070 net/core/dev_ioctl.c:572 sock_do_ioctl+0x20d/0x2c0 net/socket.c:1215 sock_ioctl+0x577/0x6d0 net/socket.c:1320 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x18c/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:46 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Set the PTP clock pointer to NULL after unregistering. Fixes: c2594d804d5c ("macb: Common code to enable ptp support for MACB/GEM") Cc: stable@vger.kernel.org Signed-off-by: Fedor Pchelkin Link: https://patch.msgid.link/20260316103826.74506-1-pchelkin@ispras.ru Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4de9ed2ea22d611b4149969266b45a86ea8daf35 Author: Ian Ray Date: Tue Mar 17 10:53:36 2026 +0200 NFC: nxp-nci: allow GPIOs to sleep commit 55dc632ab2ac2889b15995a9eef56c753d48ebc7 upstream. Allow the firmware and enable GPIOs to sleep. This fixes a `WARN_ON' and allows the driver to operate GPIOs which are connected to I2C GPIO expanders. -- >8 -- kernel: WARNING: CPU: 3 PID: 2636 at drivers/gpio/gpiolib.c:3880 gpiod_set_value+0x88/0x98 -- >8 -- Fixes: 43201767b44c ("NFC: nxp-nci: Convert to use GPIO descriptor") Cc: stable@vger.kernel.org Signed-off-by: Ian Ray Link: https://patch.msgid.link/20260317085337.146545-1-ian.ray@gehealthcare.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8dd23bb5c6f5cb7c57917541338b7842996e448b Author: Tiezhu Yang Date: Mon Mar 16 10:36:01 2026 +0800 LoongArch: No need to flush icache if text copy failed commit d3b8491961207ac967795c34375890407fd51a45 upstream. If copy_to_kernel_nofault() failed, no need to flush icache and just return immediately. Cc: stable@vger.kernel.org Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 250aae6a5738a326287bd29aebf5beab44bf28fe Author: Tiezhu Yang Date: Mon Mar 16 10:36:01 2026 +0800 LoongArch: Give more information if kmem access failed commit a47f0754bdd01f971c9715acdbdd3a07515c8f83 upstream. If memory access such as copy_{from, to}_kernel_nofault() failed, its users do not know what happened, so it is very useful to print the exception code for such cases. Furthermore, it is better to print the caller function to know where is the entry. Here are the low level call chains: copy_from_kernel_nofault() copy_from_kernel_nofault_loop() __get_kernel_nofault() copy_to_kernel_nofault() copy_to_kernel_nofault_loop() __put_kernel_nofault() Cc: stable@vger.kernel.org Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 6e096db800db807d32d947270111e853da167990 Author: Wei Yang Date: Thu Mar 5 01:50:06 2026 +0000 mm/huge_memory: fix early failure try_to_migrate() when split huge pmd for shared THP commit 939080834fef3ce42fdbcfef33fd29c9ffe5bbed upstream. Commit 60fbb14396d5 ("mm/huge_memory: adjust try_to_migrate_one() and split_huge_pmd_locked()") return false unconditionally after split_huge_pmd_locked(). This may fail try_to_migrate() early when TTU_SPLIT_HUGE_PMD is specified. The reason is the above commit adjusted try_to_migrate_one() to, when a PMD-mapped THP entry is found, and TTU_SPLIT_HUGE_PMD is specified (for example, via unmap_folio()), return false unconditionally. This breaks the rmap walk and fail try_to_migrate() early, if this PMD-mapped THP is mapped in multiple processes. The user sensible impact of this bug could be: * On memory pressure, shrink_folio_list() may split partially mapped folio with split_folio_to_list(). Then free unmapped pages without IO. If failed, it may not be reclaimed. * On memory failure, memory_failure() would call try_to_split_thp_page() to split folio contains the bad page. If succeed, the PG_has_hwpoisoned bit is only set in the after-split folio contains @split_at. By doing so, we limit bad memory. If failed to split, the whole folios is not usable. One way to reproduce: Create an anonymous THP range and fork 512 children, so we have a THP shared mapped in 513 processes. Then trigger folio split with /sys/kernel/debug/split_huge_pages debugfs to split the THP folio to order 0. Without the above commit, we can successfully split to order 0. With the above commit, the folio is still a large folio. And currently there are two core users of TTU_SPLIT_HUGE_PMD: * try_to_unmap_one() * try_to_migrate_one() try_to_unmap_one() would restart the rmap walk, so only try_to_migrate_one() is affected. We can't simply revert commit 60fbb14396d5 ("mm/huge_memory: adjust try_to_migrate_one() and split_huge_pmd_locked()"), since it removed some duplicated check covered by page_vma_mapped_walk(). This patch fixes this by restart page_vma_mapped_walk() after split_huge_pmd_locked(). Since we cannot simply return "true" to fix the problem, as that would affect another case: When invoking folio_try_share_anon_rmap_pmd() from split_huge_pmd_locked(), the latter can fail and leave a large folio mapped through PTEs, in which case we ought to return true from try_to_migrate_one(). This might result in unnecessary walking of the rmap but is relatively harmless. Link: https://lkml.kernel.org/r/20260305015006.27343-1-richard.weiyang@gmail.com Fixes: 60fbb14396d5 ("mm/huge_memory: adjust try_to_migrate_one() and split_huge_pmd_locked()") Signed-off-by: Wei Yang Reviewed-by: Baolin Wang Reviewed-by: Zi Yan Tested-by: Lance Yang Reviewed-by: Lance Yang Reviewed-by: Gavin Guo Acked-by: David Hildenbrand (arm) Reviewed-by: Lorenzo Stoakes (Oracle) Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit f3caaee0f9e489fd2282d4ce45791dc8aed2da62 Author: Chris Down Date: Tue Mar 3 07:21:21 2026 +0000 mm/huge_memory: fix use of NULL folio in move_pages_huge_pmd() commit fae654083bfa409bb2244f390232e2be47f05bfc upstream. move_pages_huge_pmd() handles UFFDIO_MOVE for both normal THPs and huge zero pages. For the huge zero page path, src_folio is explicitly set to NULL, and is used as a sentinel to skip folio operations like lock and rmap. In the huge zero page branch, src_folio is NULL, so folio_mk_pmd(NULL, pgprot) passes NULL through folio_pfn() and page_to_pfn(). With SPARSEMEM_VMEMMAP this silently produces a bogus PFN, installing a PMD pointing to non-existent physical memory. On other memory models it is a NULL dereference. Use page_folio(src_page) to obtain the valid huge zero folio from the page, which was obtained from pmd_page() and remains valid throughout. After commit d82d09e48219 ("mm/huge_memory: mark PMD mappings of the huge zero folio special"), moved huge zero PMDs must remain special so vm_normal_page_pmd() continues to treat them as special mappings. move_pages_huge_pmd() currently reconstructs the destination PMD in the huge zero page branch, which drops PMD state such as pmd_special() on architectures with CONFIG_ARCH_HAS_PTE_SPECIAL. As a result, vm_normal_page_pmd() can treat the moved huge zero PMD as a normal page and corrupt its refcount. Instead of reconstructing the PMD from the folio, derive the destination entry from src_pmdval after pmdp_huge_clear_flush(), then handle the PMD metadata the same way move_huge_pmd() does for moved entries by marking it soft-dirty and clearing uffd-wp. Link: https://lkml.kernel.org/r/a1e787dd-b911-474d-8570-f37685357d86@lucifer.local Fixes: e3981db444a0 ("mm: add folio_mk_pmd()") Signed-off-by: Chris Down Signed-off-by: Lorenzo Stoakes Reviewed-by: Lorenzo Stoakes Tested-by: Lorenzo Stoakes Acked-by: David Hildenbrand (Arm) Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 99888a4f340ca8e839a0524556bd4db76d63f4e0 Author: Dev Jain Date: Tue Mar 3 11:45:28 2026 +0530 mm/rmap: fix incorrect pte restoration for lazyfree folios commit 29f40594a28114b9a9bc87f6cf7bbee9609628f2 upstream. We batch unmap anonymous lazyfree folios by folio_unmap_pte_batch. If the batch has a mix of writable and non-writable bits, we may end up setting the entire batch writable. Fix this by respecting writable bit during batching. Although on a successful unmap of a lazyfree folio, the soft-dirty bit is lost, preserve it on pte restoration by respecting the bit during batching, to make the fix consistent w.r.t both writable bit and soft-dirty bit. I was able to write the below reproducer and crash the kernel. Explanation of reproducer (set 64K mTHP to always): Fault in a 64K large folio. Split the VMA at mid-point with MADV_DONTFORK. fork() - parent points to the folio with 8 writable ptes and 8 non-writable ptes. Merge the VMAs with MADV_DOFORK so that folio_unmap_pte_batch() can determine all the 16 ptes as a batch. Do MADV_FREE on the range to mark the folio as lazyfree. Write to the memory to dirty the pte, eventually rmap will dirty the folio. Then trigger reclaim, we will hit the pte restoration path, and the kernel will crash with the trace given below. The BUG happens at: BUG_ON(atomic_inc_return(&ptc->anon_map_count) > 1 && rw); The code path is asking for anonymous page to be mapped writable into the pagetable. The BUG_ON() firing implies that such a writable page has been mapped into the pagetables of more than one process, which breaks anonymous memory/CoW semantics. [ 21.134473] kernel BUG at mm/page_table_check.c:118! [ 21.134497] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 21.135917] Modules linked in: [ 21.136085] CPU: 1 UID: 0 PID: 1735 Comm: dup-lazyfree Not tainted 7.0.0-rc1-00116-g018018a17770 #1028 PREEMPT [ 21.136858] Hardware name: linux,dummy-virt (DT) [ 21.137019] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 21.137308] pc : page_table_check_set+0x28c/0x2a8 [ 21.137607] lr : page_table_check_set+0x134/0x2a8 [ 21.137885] sp : ffff80008a3b3340 [ 21.138124] x29: ffff80008a3b3340 x28: fffffdffc3d14400 x27: ffffd1a55e03d000 [ 21.138623] x26: 0040000000000040 x25: ffffd1a55f7dd000 x24: 0000000000000001 [ 21.139045] x23: 0000000000000001 x22: 0000000000000001 x21: ffffd1a55f217f30 [ 21.139629] x20: 0000000000134521 x19: 0000000000134519 x18: 005c43e000040000 [ 21.140027] x17: 0001400000000000 x16: 0001700000000000 x15: 000000000000ffff [ 21.140578] x14: 000000000000000c x13: 005c006000000000 x12: 0000000000000020 [ 21.140828] x11: 0000000000000000 x10: 005c000000000000 x9 : ffffd1a55c079ee0 [ 21.141077] x8 : 0000000000000001 x7 : 005c03e000040000 x6 : 000000004000ffff [ 21.141490] x5 : ffff00017fffce00 x4 : 0000000000000001 x3 : 0000000000000002 [ 21.141741] x2 : 0000000000134510 x1 : 0000000000000000 x0 : ffff0000c08228c0 [ 21.141991] Call trace: [ 21.142093] page_table_check_set+0x28c/0x2a8 (P) [ 21.142265] __page_table_check_ptes_set+0x144/0x1e8 [ 21.142441] __set_ptes_anysz.constprop.0+0x160/0x1a8 [ 21.142766] contpte_set_ptes+0xe8/0x140 [ 21.142907] try_to_unmap_one+0x10c4/0x10d0 [ 21.143177] rmap_walk_anon+0x100/0x250 [ 21.143315] try_to_unmap+0xa0/0xc8 [ 21.143441] shrink_folio_list+0x59c/0x18a8 [ 21.143759] shrink_lruvec+0x664/0xbf0 [ 21.144043] shrink_node+0x218/0x878 [ 21.144285] __node_reclaim.constprop.0+0x98/0x338 [ 21.144763] user_proactive_reclaim+0x2a4/0x340 [ 21.145056] reclaim_store+0x3c/0x60 [ 21.145216] dev_attr_store+0x20/0x40 [ 21.145585] sysfs_kf_write+0x84/0xa8 [ 21.145835] kernfs_fop_write_iter+0x130/0x1c8 [ 21.145994] vfs_write+0x2b8/0x368 [ 21.146119] ksys_write+0x70/0x110 [ 21.146240] __arm64_sys_write+0x24/0x38 [ 21.146380] invoke_syscall+0x50/0x120 [ 21.146513] el0_svc_common.constprop.0+0x48/0xf8 [ 21.146679] do_el0_svc+0x28/0x40 [ 21.146798] el0_svc+0x34/0x110 [ 21.146926] el0t_64_sync_handler+0xa0/0xe8 [ 21.147074] el0t_64_sync+0x198/0x1a0 [ 21.147225] Code: f9400441 b4fff241 17ffff94 d4210000 (d4210000) [ 21.147440] ---[ end trace 0000000000000000 ]--- #define _GNU_SOURCE #include #include #include #include #include #include #include #include void write_to_reclaim() { const char *path = "/sys/devices/system/node/node0/reclaim"; const char *value = "409600000000"; int fd = open(path, O_WRONLY); if (fd == -1) { perror("open"); exit(EXIT_FAILURE); } if (write(fd, value, sizeof("409600000000") - 1) == -1) { perror("write"); close(fd); exit(EXIT_FAILURE); } printf("Successfully wrote %s to %s\n", value, path); close(fd); } int main() { char *ptr = mmap((void *)(1UL << 30), 1UL << 16, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if ((unsigned long)ptr != (1UL << 30)) { perror("mmap"); return 1; } /* a 64K folio gets faulted in */ memset(ptr, 0, 1UL << 16); /* 32K half will not be shared into child */ if (madvise(ptr, 1UL << 15, MADV_DONTFORK)) { perror("madvise madv dontfork"); return 1; } pid_t pid = fork(); if (pid < 0) { perror("fork"); return 1; } else if (pid == 0) { sleep(15); } else { /* merge VMAs. now first half of the 16 ptes are writable, the other half not. */ if (madvise(ptr, 1UL << 15, MADV_DOFORK)) { perror("madvise madv fork"); return 1; } if (madvise(ptr, (1UL << 16), MADV_FREE)) { perror("madvise madv free"); return 1; } /* dirty the large folio */ (*ptr) += 10; write_to_reclaim(); // sleep(10); waitpid(pid, NULL, 0); } } Link: https://lkml.kernel.org/r/20260303061528.2429162-1-dev.jain@arm.com Fixes: 354dffd29575 ("mm: support batched unmap for lazyfree large folios during reclamation") Signed-off-by: Dev Jain Acked-by: David Hildenbrand (Arm) Reviewed-by: Lorenzo Stoakes Reviewed-by: Barry Song Reviewed-by: Wei Yang Tested-by: Lance Yang Cc: Anshuman Khandual Cc: Harry Yoo Cc: Jann Horn Cc: Liam Howlett Cc: Rik van Riel Cc: Ryan Roberts Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 4897bd307ba8757c31a3325ba6730961be606016 Author: Thorsten Blum Date: Sat Feb 28 00:00:09 2026 +0100 crash_dump: don't log dm-crypt key bytes in read_key_from_user_keying commit 36f46b0e36892eba08978eef7502ff3c94ddba77 upstream. When debug logging is enabled, read_key_from_user_keying() logs the first 8 bytes of the key payload and partially exposes the dm-crypt key. Stop logging any key bytes. Link: https://lkml.kernel.org/r/20260227230008.858641-2-thorsten.blum@linux.dev Fixes: 479e58549b0f ("crash_dump: store dm crypt keys in kdump reserved memory") Signed-off-by: Thorsten Blum Cc: Baoquan He Cc: Coiby Xu Cc: Dave Young Cc: Vivek Goyal Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit a226e5b49e5fe8c98b14f8507de670189d191348 Author: Ira Weiny Date: Fri Mar 6 12:33:05 2026 -0600 nvdimm/bus: Fix potential use after free in asynchronous initialization commit a8aec14230322ed8f1e8042b6d656c1631d41163 upstream. Dingisoul with KASAN reports a use after free if device_add() fails in nd_async_device_register(). Commit b6eae0f61db2 ("libnvdimm: Hold reference on parent while scheduling async init") correctly added a reference on the parent device to be held until asynchronous initialization was complete. However, if device_add() results in an allocation failure the ref count of the device drops to 0 prior to the parent pointer being accessed. Thus resulting in use after free. The bug bot AI correctly identified the fix. Save a reference to the parent pointer to be used to drop the parent reference regardless of the outcome of device_add(). Reported-by: Dingisoul Closes: http://lore.kernel.org/8855544b-be9e-4153-aa55-0bc328b13733@gmail.com Fixes: b6eae0f61db2 ("libnvdimm: Hold reference on parent while scheduling async init") Cc: stable@vger.kernel.org Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260306-fix-uaf-async-init-v1-1-a28fd7526723@intel.com Signed-off-by: Ira Weiny Signed-off-by: Greg Kroah-Hartman commit be5c35960e5ead70862736161836e2d1bc7352dc Author: Jeff Layton Date: Mon Feb 23 12:09:58 2026 -0500 sunrpc: fix cache_request leak in cache_release commit 17ad31b3a43b72aec3a3d83605891e1397d0d065 upstream. When a reader's file descriptor is closed while in the middle of reading a cache_request (rp->offset != 0), cache_release() decrements the request's readers count but never checks whether it should free the request. In cache_read(), when readers drops to 0 and CACHE_PENDING is clear, the cache_request is removed from the queue and freed along with its buffer and cache_head reference. cache_release() lacks this cleanup. The only other path that frees requests with readers == 0 is cache_dequeue(), but it runs only when CACHE_PENDING transitions from set to clear. If that transition already happened while readers was still non-zero, cache_dequeue() will have skipped the request, and no subsequent call will clean it up. Add the same cleanup logic from cache_read() to cache_release(): after decrementing readers, check if it reached 0 with CACHE_PENDING clear, and if so, dequeue and free the cache_request. Reported-by: NeilBrown Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@kernel.org Signed-off-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 73c5b5aea1c443239c8cb4191b4af7a4bd6fd7b1 Author: Benjamin Tissoires Date: Fri Mar 13 08:40:25 2026 +0100 HID: bpf: prevent buffer overflow in hid_hw_request commit 2b658c1c442ec1cd9eec5ead98d68662c40fe645 upstream. right now the returned value is considered to be always valid. However, when playing with HID-BPF, the return value can be arbitrary big, because it's the return value of dispatch_hid_bpf_raw_requests(), which calls the struct_ops and we have no guarantees that the value makes sense. Fixes: 8bd0488b5ea5 ("HID: bpf: add HID-BPF hooks for hid_hw_raw_requests") Cc: stable@vger.kernel.org Acked-by: Jiri Kosina Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 6487774a576dd2d86d1c2e4fe4d8abbdc2f45e6d Author: Benjamin Tissoires Date: Fri Mar 13 08:40:24 2026 +0100 selftests/hid: fix compilation when bpf_wq and hid_device are not exported commit 5d4c6c132ea9a967d48890dd03e6a786c060e968 upstream. This can happen in situations when CONFIG_HID_SUPPORT is set to no, or some complex situations where struct bpf_wq is not exported. So do the usual dance of hiding them before including vmlinux.h, and then redefining them and make use of CO-RE to have the correct offsets. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202603111558.KLCIxsZB-lkp@intel.com/ Fixes: fe8d561db3e8 ("selftests/hid: add wq test for hid_bpf_input_report()") Cc: stable@vger.kernel.org Acked-by: Jiri Kosina Reviewed-by: Thomas Weißschuh Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 0f0e2a54a31a7f9ad2915db99156114872317388 Author: Jeff Layton Date: Tue Feb 24 11:33:35 2026 -0500 nfsd: fix heap overflow in NFSv4.0 LOCK replay cache commit 5133b61aaf437e5f25b1b396b14242a6bb0508e2 upstream. The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses. This size was calculated based on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT). When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4_encode_operation() copies the full encoded response into the undersized replay buffer via read_bytes_from_xdr_buf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory. This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial. We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large. Instead, fix this by checking the encoded response length against NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the response is too large, set rp_buflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original request. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@kernel.org Reported-by: Nicholas Carlini Tested-by: Nicholas Carlini Signed-off-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit db4a9f99b12a7ee1c19d86c83a3b752c7effa6c6 Author: Chuck Lever Date: Thu Feb 19 16:50:17 2026 -0500 NFSD: Hold net reference for the lifetime of /proc/fs/nfs/exports fd commit e7fcf179b82d3a3730fd8615da01b087cc654d0b upstream. The /proc/fs/nfs/exports proc entry is created at module init and persists for the module's lifetime. exports_proc_open() captures the caller's current network namespace and stores its svc_export_cache in seq->private, but takes no reference on the namespace. If the namespace is subsequently torn down (e.g. container destruction after the opener does setns() to a different namespace), nfsd_net_exit() calls nfsd_export_shutdown() which frees the cache. Subsequent reads on the still-open fd dereference the freed cache_detail, walking a freed hash table. Hold a reference on the struct net for the lifetime of the open file descriptor. This prevents nfsd_net_exit() from running -- and thus prevents nfsd_export_shutdown() from freeing the cache -- while any exports fd is open. cache_detail already stores its net pointer (cd->net, set by cache_create_net()), so exports_release() can retrieve it without additional per-file storage. Reported-by: Misbah Anjum N Closes: https://lore.kernel.org/linux-nfs/dcd371d3a95815a84ba7de52cef447b8@linux.ibm.com/ Fixes: 96d851c4d28d ("nfsd: use proper net while reading "exports" file") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Reviewed-by: NeilBrown Tested-by: Olga Kornievskaia Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 2829e80d29b627886d12b5ea40856d56b516e67d Author: Chuck Lever Date: Thu Feb 19 16:50:16 2026 -0500 NFSD: Defer sub-object cleanup in export put callbacks commit 48db892356d6cb80f6942885545de4a6dd8d2a29 upstream. svc_export_put() calls path_put() and auth_domain_put() immediately when the last reference drops, before the RCU grace period. RCU readers in e_show() and c_show() access both ex_path (via seq_path/d_path) and ex_client->name (via seq_escape) without holding a reference. If cache_clean removes the entry and drops the last reference concurrently, the sub-objects are freed while still in use, producing a NULL pointer dereference in d_path. Commit 2530766492ec ("nfsd: fix UAF when access ex_uuid or ex_stats") moved kfree of ex_uuid and ex_stats into the call_rcu callback, but left path_put() and auth_domain_put() running before the grace period because both may sleep and call_rcu callbacks execute in softirq context. Replace call_rcu/kfree_rcu with queue_rcu_work(), which defers the callback until after the RCU grace period and executes it in process context where sleeping is permitted. This allows path_put() and auth_domain_put() to be moved into the deferred callback alongside the other resource releases. Apply the same fix to expkey_put(), which has the identical pattern with ek_path and ek_client. A dedicated workqueue scopes the shutdown drain to only NFSD export release work items; flushing the shared system_unbound_wq would stall on unrelated work from other subsystems. nfsd_export_shutdown() uses rcu_barrier() followed by flush_workqueue() to ensure all deferred release callbacks complete before the export caches are destroyed. Reported-by: Misbah Anjum N Closes: https://lore.kernel.org/linux-nfs/dcd371d3a95815a84ba7de52cef447b8@linux.ibm.com/ Fixes: c224edca7af0 ("nfsd: no need get cache ref when protected by rcu") Fixes: 1b10f0b603c0 ("SUNRPC: no need get cache ref when protected by rcu") Cc: stable@vger.kernel.org Reviwed-by: Jeff Layton Reviewed-by: NeilBrown Tested-by: Olga Kornievskaia Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 40bc25e6515199f46a679f0f15eb5c8654303593 Author: Alexandre Frade Date: Thu Mar 19 18:17:32 2026 +0000 Linux 6.18.19-rt-xanmod1 Signed-off-by: Alexandre Frade commit f8727ea54c2b482362ab94a1236a5cb9dea27e2b Merge: b6f4f5d1d0bc 8c86bc38bc32 Author: Alexandre Frade Date: Thu Mar 19 18:16:34 2026 +0000 Merge branch '6.18' into 6.18-rt commit 8c86bc38bc32e7af7425eaa9f6160588013258e9 Author: Alexandre Frade Date: Thu Mar 19 18:12:35 2026 +0000 Linux 6.18.19-xanmod1 Signed-off-by: Alexandre Frade commit aeeb1cca8fa7f05324bc9b6a67bcd8127a0f51d6 Merge: e8a59ed2e982 4aea1dc4cad1 Author: Alexandre Frade Date: Thu Mar 19 18:11:01 2026 +0000 Merge tag 'v6.18.19' into 6.18 This is the 6.18.19 stable release commit 4aea1dc4cad17cd146072e13b1fd404f32b8b3ef Author: Greg Kroah-Hartman Date: Thu Mar 19 16:08:51 2026 +0100 Linux 6.18.19 Link: https://lore.kernel.org/r/20260317162959.345812316@linuxfoundation.org Tested-by: Peter Schneider Tested-by: Miguel Ojeda Tested-by: Jeffrin Jose T Tested-by: Shung-Hsi Yu Tested-by: Jon Hunter Tested-by: Ron Economos Link: https://lore.kernel.org/r/20260318122621.714862892@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Peter Schneider Tested-by: Pavel Machek (CIP) Tested-by: Jon Hunter Tested-by: Ron Economos Tested-by: Wentao Guan Tested-by: Barry K. Nathan Tested-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 224404f54036e33fe9968d1f69f29bf4bae0df7c Author: Christian Loehle Date: Fri Mar 6 10:49:18 2026 +0000 bpf: drop kthread_exit from noreturn_deny commit 7fe44c4388146bdbb3c5932d81a26d9fa0fd3ec9 upstream. kthread_exit became a macro to do_exit in commit 28aaa9c39945 ("kthread: consolidate kthread exit paths to prevent use-after-free"), so there is no kthread_exit function BTF ID to resolve. Remove it from noreturn_deny to avoid resolve_btfids unresolved symbol warnings. Signed-off-by: Christian Loehle Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9fd37b636bc2dc680ffcee0e1edea908b8b6ee7c Author: John Ripple Date: Mon Sep 15 11:45:43 2025 -0600 drm/bridge: ti-sn65dsi86: Add support for DisplayPort mode with HPD commit 9133bc3f0564890218cbba6cc7e81ebc0841a6f1 upstream. Add support for DisplayPort to the bridge, which entails the following: - Get and use an interrupt for HPD; - Properly clear all status bits in the interrupt handler; Signed-off-by: John Ripple Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20250915174543.2564994-1-john.ripple@keysight.com Signed-off-by: Greg Kroah-Hartman commit 24fda228496c634f6ff2e712e3b129259e2afdd1 Author: SeongJae Park Date: Tue Mar 17 11:24:50 2026 -0400 mm/damon/core: disallow non-power of two min_region_sz [ Upstream commit c80f46ac228b48403866d65391ad09bdf0e8562a ] DAMON core uses min_region_sz parameter value as the DAMON region alignment. The alignment is made using ALIGN() and ALIGN_DOWN(), which support only the power of two alignments. But DAMON core API callers can set min_region_sz to an arbitrary number. Users can also set it indirectly, using addr_unit. When the alignment is not properly set, DAMON behavior becomes difficult to expect and understand, makes it effectively broken. It doesn't cause a kernel crash-like significant issue, though. Fix the issue by disallowing min_region_sz input that is not a power of two. Add the check to damon_commit_ctx(), as all DAMON API callers who set min_region_sz uses the function. This can be a sort of behavioral change, but it does not break users, for the following reasons. As the symptom is making DAMON effectively broken, it is not reasonable to believe there are real use cases of non-power of two min_region_sz. There is no known use case or issue reports from the setup, either. In future, if we find real use cases of non-power of two alignments and we can support it with low enough overhead, we can consider moving the restriction. But, for now, simply disallowing the corner case should be good enough as a hot fix. Link: https://lkml.kernel.org/r/20260214214124.87689-1-sj@kernel.org Fixes: d8f867fa0825 ("mm/damon: add damon_ctx->min_sz_region") Signed-off-by: SeongJae Park Cc: Quanmin Yan Cc: [6.18+] Signed-off-by: Andrew Morton [ min_region_sz => min_sz_region ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b0d0903594dd68bb9156236955019acb49ca51a4 Author: Jens Axboe Date: Mon Mar 9 14:35:49 2026 -0600 io_uring/eventfd: use ctx->rings_rcu for flags checking Commit 177c69432161f6e4bab07ccacf8a1748a6898a6b upstream. Similarly to what commit e78f7b70e837 did for local task work additions, use ->rings_rcu under RCU rather than dereference ->rings directly. See that commit for more details. Cc: stable@vger.kernel.org Fixes: 79cfe9e59c2a ("io_uring/register: add IORING_REGISTER_RESIZE_RINGS") Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 7cc4530b3e952d4a5947e1e55d06620d8845d4f5 Author: Jens Axboe Date: Mon Mar 9 14:21:37 2026 -0600 io_uring: ensure ctx->rings is stable for task work flags manipulation Commit 96189080265e6bb5dde3a4afbaf947af493e3f82 upstream. If DEFER_TASKRUN | SETUP_TASKRUN is used and task work is added while the ring is being resized, it's possible for the OR'ing of IORING_SQ_TASKRUN to happen in the small window of swapping into the new rings and the old rings being freed. Prevent this by adding a 2nd ->rings pointer, ->rings_rcu, which is protected by RCU. The task work flags manipulation is inside RCU already, and if the resize ring freeing is done post an RCU synchronize, then there's no need to add locking to the fast path of task work additions. Note: this is only done for DEFER_TASKRUN, as that's the only setup mode that supports ring resizing. If this ever changes, then they too need to use the io_ctx_mark_taskrun() helper. Link: https://lore.kernel.org/io-uring/20260309062759.482210-1-naup96721@gmail.com/ Cc: stable@vger.kernel.org Fixes: 79cfe9e59c2a ("io_uring/register: add IORING_REGISTER_RESIZE_RINGS") Reported-by: Hao-Yu Yang Suggested-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit ae3831b44f477de048287493e184fc3ff913b624 Author: Eric Biggers Date: Tue Mar 10 13:16:36 2026 -0700 net/tcp-md5: Fix MAC comparison to be constant-time commit 46d0d6f50dab706637f4c18a470aac20a21900d3 upstream. To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this. Fixes: cfb6eeb4c860 ("[TCP]: MD5 Signature Option (RFC2385) support.") Fixes: 658ddaaf6694 ("tcp: md5: RST: getting md5 key from listener") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Link: https://patch.msgid.link/20260302203409.13388-1-ebiggers@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ce2a263bc57c11c9906990356a5790097e3e1925 Author: Eric Biggers Date: Tue Mar 10 12:56:46 2026 -0700 lib/crypto: tests: Depend on library options rather than selecting them commit 4478e8eeb87120c11e90041864c2233238b2155a upstream. The convention for KUnit tests is to have the test kconfig options visible only when the code they depend on is already enabled. This way only the tests that are relevant to the particular kernel build can be enabled, either manually or via KUNIT_ALL_TESTS. Update lib/crypto/tests/Kconfig to follow that convention, i.e. depend on the corresponding library options rather than selecting them. This fixes an issue where enabling KUNIT_ALL_TESTS enabled non-test code. This does mean that it becomes a bit more difficult to enable *all* the crypto library tests (which is what I do as a maintainer of the code), since doing so will now require enabling other options that select the libraries. Regardless, we should follow the standard KUnit convention. I'll also add a .kunitconfig file that does enable all these options. Note: currently most of the crypto library options are selected by visible options in crypto/Kconfig, which can be used to enable them without too much trouble. If in the future we end up with more cases like CRYPTO_LIB_CURVE25519 which is selected only by WIREGUARD (thus making CRYPTO_LIB_CURVE25519_KUNIT_TEST effectively depend on WIREGUARD after this commit), we could consider adding a new kconfig option that enables all the library code specifically for testing. Reported-by: Geert Uytterhoeven Closes: https://lore.kernel.org/r/CAMuHMdULzMdxuTVfg8_4jdgzbzjfx-PHkcgbGSthcUx_sHRNMg@mail.gmail.com Fixes: 4dcf6caddaa0 ("lib/crypto: tests: Add KUnit tests for SHA-224 and SHA-256") Fixes: 571eaeddb67d ("lib/crypto: tests: Add KUnit tests for SHA-384 and SHA-512") Fixes: 6dd4d9f7919e ("lib/crypto: tests: Add KUnit tests for Poly1305") Fixes: 66b130607908 ("lib/crypto: tests: Add KUnit tests for SHA-1 and HMAC-SHA1") Fixes: d6b6aac0cdb4 ("lib/crypto: tests: Add KUnit tests for MD5 and HMAC-MD5") Fixes: afc4e4a5f122 ("lib/crypto: tests: Migrate Curve25519 self-test to KUnit") Fixes: 6401fd334ddf ("lib/crypto: tests: Add KUnit tests for BLAKE2b") Fixes: 15c64c47e484 ("lib/crypto: tests: Add SHA3 kunit tests") Fixes: b3aed551b3fc ("lib/crypto: tests: Add KUnit tests for POLYVAL") Fixes: ed894faccb8d ("lib/crypto: tests: Add KUnit tests for ML-DSA verification") Fixes: 7246fe6cd644 ("lib/crypto: tests: Add KUnit tests for NH") Cc: stable@vger.kernel.org Reviewed-by: David Gow Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260226191749.39397-1-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 93c0a22fec914ec4b697e464895a0f594e29fb28 Author: Eric Biggers Date: Tue Mar 10 12:52:14 2026 -0700 ksmbd: Compare MACs in constant time commit c5794709bc9105935dbedef8b9cf9c06f2b559fa upstream. To prevent timing attacks, MAC comparisons need to be constant-time. Replace the memcmp() with the correct function, crypto_memneq(). Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 4af5dfb8dca3a6ad18feb6b2adcfffb4dc874e50 Author: Eric Biggers Date: Tue Mar 10 12:50:20 2026 -0700 smb: client: Compare MACs in constant time commit 26bc83b88bbbf054f0980a4a42047a8d1e210e4c upstream. To prevent timing attacks, MAC comparisons need to be constant-time. Replace the memcmp() with the correct function, crypto_memneq(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Acked-by: Paulo Alcantara (Red Hat) Signed-off-by: Eric Biggers Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 97ea8f3bbdaef375aa371b305ba8f1cd80835257 Author: Nathan Chancellor Date: Mon Mar 9 13:43:49 2026 -0400 kbuild: Leave objtool binary around with 'make clean' [ Upstream commit fdb12c8a24a453bdd6759979b6ef1e04ebd4beb4 ] The difference between 'make clean' and 'make mrproper' is documented in 'make help' as: clean - Remove most generated files but keep the config and enough build support to build external modules mrproper - Remove all generated files + config + various backup files After commit 68b4fe32d737 ("kbuild: Add objtool to top-level clean target"), running 'make clean' then attempting to build an external module with the resulting build directory fails with $ make ARCH=x86_64 O=build clean $ make -C build M=... MO=... ... /bin/sh: line 1: .../build/tools/objtool/objtool: No such file or directory as 'make clean' removes the objtool binary. Split the objtool clean target into mrproper and clean like Kbuild does and remove all generated artifacts with 'make clean' except for the objtool binary, which is removed with 'make mrproper'. To avoid a small race when running the objtool clean target through both objtool_mrproper and objtool_clean when running 'make mrproper', modify objtool's clean up find command to avoid using find's '-delete' command by piping the files into 'xargs rm -f' like the rest of Kbuild does. Cc: stable@vger.kernel.org Fixes: 68b4fe32d737 ("kbuild: Add objtool to top-level clean target") Reported-by: Michal Suchanek Closes: https://lore.kernel.org/20260225112633.6123-1-msuchanek@suse.de/ Reported-by: Rainer Fiebig Closes: https://lore.kernel.org/62d12399-76e5-3d40-126a-7490b4795b17@mailbox.org/ Acked-by: Josh Poimboeuf Acked-by: Peter Zijlstra (Intel) Reviewed-by: Nicolas Schier Tested-by: Nicolas Schier Link: https://patch.msgid.link/20260227-avoid-objtool-binary-removal-clean-v1-1-122f3e55eae9@kernel.org Signed-off-by: Nathan Chancellor [ Context ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ba3bca40f9f25c053f69413e5f4a41dd0fd762bf Author: Sean Christopherson Date: Mon Mar 16 15:11:53 2026 -0400 KVM: SVM: Set/clear CR8 write interception when AVIC is (de)activated [ Upstream commit 87d0f901a9bd8ae6be57249c737f20ac0cace93d ] Explicitly set/clear CR8 write interception when AVIC is (de)activated to fix a bug where KVM leaves the interception enabled after AVIC is activated. E.g. if KVM emulates INIT=>WFS while AVIC is deactivated, CR8 will remain intercepted in perpetuity. On its own, the dangling CR8 intercept is "just" a performance issue, but combined with the TPR sync bug fixed by commit d02e48830e3f ("KVM: SVM: Sync TPR from LAPIC into VMCB::V_TPR even if AVIC is active"), the danging intercept is fatal to Windows guests as the TPR seen by hardware gets wildly out of sync with reality. Note, VMX isn't affected by the bug as TPR_THRESHOLD is explicitly ignored when Virtual Interrupt Delivery is enabled, i.e. when APICv is active in KVM's world. I.e. there's no need to trigger update_cr8_intercept(), this is firmly an SVM implementation flaw/detail. WARN if KVM gets a CR8 write #VMEXIT while AVIC is active, as KVM should never enter the guest with AVIC enabled and CR8 writes intercepted. Fixes: 3bbf3565f48c ("svm: Do not intercept CR8 when enable AVIC") Cc: stable@vger.kernel.org Cc: Jim Mattson Cc: Naveen N Rao (AMD) Cc: Maciej S. Szmigiero Reviewed-by: Naveen N Rao (AMD) Reviewed-by: Jim Mattson Link: https://patch.msgid.link/20260203190711.458413-3-seanjc@google.com Signed-off-by: Sean Christopherson [Squash fix to avic_deactivate_vmcb. - Paolo] Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0ff26b41c882ce5066ec3a4fdae3091ccd67cdf0 Author: Naveen N Rao Date: Mon Mar 16 15:11:52 2026 -0400 KVM: SVM: Add a helper to look up the max physical ID for AVIC [ Upstream commit f2f6e67a56dc88fea7e9b10c4e79bb01d97386b7 ] To help with a future change, add a helper to look up the maximum physical ID depending on the vCPU AVIC mode. No functional change intended. Suggested-by: Sean Christopherson Signed-off-by: Naveen N Rao (AMD) Link: https://lore.kernel.org/r/0ab9bf5e20a3463a4aa3a5ea9bbbac66beedf1d1.1757009416.git.naveen@kernel.org Signed-off-by: Sean Christopherson Stable-dep-of: 87d0f901a9bd ("KVM: SVM: Set/clear CR8 write interception when AVIC is (de)activated") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ba28a0dcc41ae2b89fe147e3b8d8a22464a01861 Author: Naveen N Rao Date: Mon Mar 16 15:11:51 2026 -0400 KVM: SVM: Limit AVIC physical max index based on configured max_vcpu_ids [ Upstream commit 574ef752d4aea04134bc121294d717f4422c2755 ] KVM allows VMMs to specify the maximum possible APIC ID for a virtual machine through KVM_CAP_MAX_VCPU_ID capability so as to limit data structures related to APIC/x2APIC. Utilize the same to set the AVIC physical max index in the VMCB, similar to VMX. This helps hardware limit the number of entries to be scanned in the physical APIC ID table speeding up IPI broadcasts for virtual machines with smaller number of vCPUs. Unlike VMX, SVM AVIC requires a single page to be allocated for the Physical APIC ID table and the Logical APIC ID table, so retain the existing approach of allocating those during VM init. Signed-off-by: Naveen N Rao (AMD) Link: https://lore.kernel.org/r/adb07ccdb3394cd79cb372ba6bcc69a4e4d4ef54.1757009416.git.naveen@kernel.org Signed-off-by: Sean Christopherson Stable-dep-of: 87d0f901a9bd ("KVM: SVM: Set/clear CR8 write interception when AVIC is (de)activated") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b7493f48c3dba75674a4ee505b4afa8fe5102457 Author: Marc Zyngier Date: Mon Mar 16 16:17:16 2026 -0400 KVM: arm64: Eagerly init vgic dist/redist on vgic creation [ Upstream commit ac6769c8f948dff33265c50e524aebf9aa6f1be0 ] If vgic_allocate_private_irqs_locked() fails for any odd reason, we exit kvm_vgic_create() early, leaving dist->rd_regions uninitialised. kvm_vgic_dist_destroy() then comes along and walks into the weeds trying to free the RDs. Got to love this stuff. Solve it by moving all the static initialisation early, and make sure that if we fail halfway, we're in a reasonable shape to perform the rest of the teardown. While at it, reset the vgic model on failure, just in case... Reported-by: syzbot+f6a46b038fc243ac0175@syzkaller.appspotmail.com Tested-by: syzbot+f6a46b038fc243ac0175@syzkaller.appspotmail.com Fixes: b3aa9283c0c50 ("KVM: arm64: vgic: Hoist SGI/PPI alloc from vgic_init() to kvm_create_vgic()") Link: https://lore.kernel.org/r/69a2d58c.050a0220.3a55be.003b.GAE@google.com Link: https://patch.msgid.link/20260228164559.936268-1-maz@kernel.org Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2a01a93ed2266863d271efba9940cf24c4143279 Author: Sascha Bischoff Date: Mon Mar 16 16:17:15 2026 -0400 KVM: arm64: gic: Set vgic_model before initing private IRQs [ Upstream commit 9435c1e1431003e23aa34ef8e46c30d09c3dbcb5 ] Different GIC types require the private IRQs to be initialised differently. GICv5 is the culprit as it supports both a different number of private IRQs, and all of these are PPIs (there are no SGIs). Moreover, as GICv5 uses the top bits of the interrupt ID to encode the type, the intid also needs to computed differently. Up until now, the GIC model has been set after initialising the private IRQs for a VCPU. Move this earlier to ensure that the GIC model is available when configuring the private IRQs. While we're at it, also move the setting of the in_kernel flag and implementation revision to keep them grouped together as before. Signed-off-by: Sascha Bischoff Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/20260128175919.3828384-7-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier Stable-dep-of: ac6769c8f948 ("KVM: arm64: Eagerly init vgic dist/redist on vgic creation") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8d02bbfb09003d288241430de9969e45bc9d9fec Author: Shawn Lin Date: Tue Mar 17 08:04:53 2026 -0400 mmc: dw_mmc-rockchip: Fix runtime PM support for internal phase support [ Upstream commit 6465a8bbb0f6ad98aeb66dc9ea19c32c193a610b ] RK3576 is the first platform to introduce internal phase support, and subsequent platforms are expected to adopt a similar design. In this architecture, runtime suspend powers off the attached power domain, which resets registers, including vendor-specific ones such as SDMMC_TIMING_CON0, SDMMC_TIMING_CON1, and SDMMC_MISC_CON. These registers must be saved and restored, a requirement that falls outside the scope of the dw_mmc core. Fixes: 59903441f5e4 ("mmc: dw_mmc-rockchip: Add internal phase support") Signed-off-by: Shawn Lin Tested-by: Marco Schirrmeister Reviewed-by: Heiko Stuebner Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5b58ba042e2379f4c01da3211fd17dbdc983c2ac Author: Shawn Lin Date: Tue Mar 17 08:04:52 2026 -0400 mmc: dw_mmc-rockchip: Add memory clock auto-gating support [ Upstream commit ff6f0286c896f062853552097220dd93961be9c4 ] Per design recommendations, the memory clock can be gated when there is no in-flight transfer, which helps save power. This feature is introduced alongside internal phase support, and this patch enables it. Signed-off-by: Shawn Lin Signed-off-by: Ulf Hansson Stable-dep-of: 6465a8bbb0f6 ("mmc: dw_mmc-rockchip: Fix runtime PM support for internal phase support") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4c3a860b96e720e3823b3ccbf3fe04a0e3926051 Author: Shenghao Yang Date: Tue Mar 17 10:28:47 2026 -0400 drm/gud: fix NULL crtc dereference on display disable [ Upstream commit 7149be786da012afc6bae293d38f8c1fff1fb90d ] gud_plane_atomic_update() currently handles both crtc state and framebuffer updates - the complexity has led to a few accidental NULL pointer dereferences. Commit dc2d5ddb193e ("drm/gud: fix NULL fb and crtc dereferences on USB disconnect") [1] fixed an earlier dereference but planes can also be disabled in non-hotplug paths (e.g. display disables via the desktop environment). The drm_dev_enter() call would not cause an early return in those and subsequently oops on dereferencing crtc: BUG: kernel NULL pointer dereference, address: 00000000000005c8 CPU: 6 UID: 1000 PID: 3473 Comm: kwin_wayland Not tainted 6.18.2-200.vanilla.gud.fc42.x86_64 #1 PREEMPT(lazy) RIP: 0010:gud_plane_atomic_update+0x148/0x470 [gud] drm_atomic_helper_commit_planes+0x28e/0x310 drm_atomic_helper_commit_tail+0x2a/0x70 commit_tail+0xf1/0x150 drm_atomic_helper_commit+0x13c/0x180 drm_atomic_commit+0xb1/0xe0 info ? __pfx___drm_printfn_info+0x10/0x10 drm_mode_atomic_ioctl+0x70f/0x7c0 ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 drm_ioctl_kernel+0xae/0x100 drm_ioctl+0x2a8/0x550 ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 __x64_sys_ioctl+0x97/0xe0 do_syscall_64+0x7e/0x7f0 ? __ct_user_enter+0x56/0xd0 ? do_syscall_64+0x158/0x7f0 ? __ct_user_enter+0x56/0xd0 ? do_syscall_64+0x158/0x7f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Split out crtc handling from gud_plane_atomic_update() into atomic_enable() and atomic_disable() functions to delegate crtc state transitioning work to the DRM helpers. To preserve the gud state commit sequence [2], switch to the runtime PM version of drm_atomic_helper_commit_tail() which ensures that crtcs are enabled (hence sending the GUD_REQ_SET_CONTROLLER_ENABLE and GUD_REQ_SET_DISPLAY_ENABLE requests) before a framebuffer update is sent. [1] https://lore.kernel.org/all/20251231055039.44266-1-me@shenghaoyang.info/ [2] https://github.com/notro/gud/wiki/GUD-Protocol#display-state Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202601142159.0v8ilfVs-lkp@intel.com/ Fixes: 73cfd166e045 ("drm/gud: Replace simple display pipe with DRM atomic helpers") Cc: # 6.19.x Cc: # 6.18.x Signed-off-by: Shenghao Yang Reviewed-by: Thomas Zimmermann Acked-by: Ruben Wauters Signed-off-by: Ruben Wauters Link: https://patch.msgid.link/20260222054551.80864-1-me@shenghaoyang.info Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 51aa99e59d7f579a71252963b2e936c24f4c6f8f Author: Ruben Wauters Date: Tue Mar 17 10:28:46 2026 -0400 drm/gud: rearrange gud_probe() to prepare for function splitting [ Upstream commit b9e5e9d2c187b849e050d59823e8c834f78475ab ] gud_probe() is currently very large and does many things, including pipeline setup and feature detection, as well as having USB functions. This patch re-orders the code in gud_probe() to make it more organised and easier to split apart in the future. Signed-off-by: Ruben Wauters Reviewed-by: Thomas Zimmermann Link: https://lore.kernel.org/r/20251020140147.5017-1-rubenru09@aol.com/ Stable-dep-of: 7149be786da0 ("drm/gud: fix NULL crtc dereference on display disable") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 94b6d0ba4b640ba23bb6c708a59316e74e5ede63 Author: Thomas Hellström Date: Tue Feb 10 12:56:53 2026 +0100 mm: Fix a hmm_range_fault() livelock / starvation problem commit b570f37a2ce480be26c665345c5514686a8a0274 upstream. If hmm_range_fault() fails a folio_trylock() in do_swap_page, trying to acquire the lock of a device-private folio for migration, to ram, the function will spin until it succeeds grabbing the lock. However, if the process holding the lock is depending on a work item to be completed, which is scheduled on the same CPU as the spinning hmm_range_fault(), that work item might be starved and we end up in a livelock / starvation situation which is never resolved. This can happen, for example if the process holding the device-private folio lock is stuck in migrate_device_unmap()->lru_add_drain_all() sinc lru_add_drain_all() requires a short work-item to be run on all online cpus to complete. A prerequisite for this to happen is: a) Both zone device and system memory folios are considered in migrate_device_unmap(), so that there is a reason to call lru_add_drain_all() for a system memory folio while a folio lock is held on a zone device folio. b) The zone device folio has an initial mapcount > 1 which causes at least one migration PTE entry insertion to be deferred to try_to_migrate(), which can happen after the call to lru_add_drain_all(). c) No or voluntary only preemption. This all seems pretty unlikely to happen, but indeed is hit by the "xe_exec_system_allocator" igt test. Resolve this by waiting for the folio to be unlocked if the folio_trylock() fails in do_swap_page(). Rename migration_entry_wait_on_locked() to softleaf_entry_wait_unlock() and update its documentation to indicate the new use-case. Future code improvements might consider moving the lru_add_drain_all() call in migrate_device_unmap() to be called *after* all pages have migration entries inserted. That would eliminate also b) above. v2: - Instead of a cond_resched() in hmm_range_fault(), eliminate the problem by waiting for the folio to be unlocked in do_swap_page() (Alistair Popple, Andrew Morton) v3: - Add a stub migration_entry_wait_on_locked() for the !CONFIG_MIGRATION case. (Kernel Test Robot) v4: - Rename migrate_entry_wait_on_locked() to softleaf_entry_wait_on_locked() and update docs (Alistair Popple) v5: - Add a WARN_ON_ONCE() for the !CONFIG_MIGRATION version of softleaf_entry_wait_on_locked(). - Modify wording around function names in the commit message (Andrew Morton) Suggested-by: Alistair Popple Fixes: 1afaeb8293c9 ("mm/migrate: Trylock device page in do_swap_page") Cc: Ralph Campbell Cc: Christoph Hellwig Cc: Jason Gunthorpe Cc: Jason Gunthorpe Cc: Leon Romanovsky Cc: Andrew Morton Cc: Matthew Brost Cc: John Hubbard Cc: Alistair Popple Cc: linux-mm@kvack.org Cc: Signed-off-by: Thomas Hellström Cc: # v6.15+ Reviewed-by: John Hubbard #v3 Reviewed-by: Alistair Popple Link: https://patch.msgid.link/20260210115653.92413-1-thomas.hellstrom@linux.intel.com (cherry picked from commit a69d1ab971a624c6f112cea61536569d579c3215) Signed-off-by: Rodrigo Vivi Signed-off-by: Thomas Hellström Signed-off-by: Greg Kroah-Hartman commit fffce2310e6886b44b95fa005f2084e818adbec7 Author: Keith Busch Date: Thu Mar 5 12:40:56 2026 -0800 cxl/acpi: Fix CXL_ACPI and CXL_PMEM Kconfig tristate mismatch commit 93d0fcdddc9e7be9d4f42acbe57bc90dbb0fe75d upstream. Commit e7e222ad73d9 ("cxl: Move devm_cxl_add_nvdimm_bridge() to cxl_pmem.ko") moves devm_cxl_add_nvdimm_bridge() into the cxl_pmem file, which has independent config compile options for built-in or module. The call from cxl_acpi_probe() is guarded by IS_ENABLED(CONFIG_CXL_PMEM), which evaluates to true for both =y and =m. When CONFIG_CXL_PMEM=m, a built-in cxl_acpi attempts to reference a symbol exported by a module, which fails to link. CXL_PMEM cannot simply be promoted to =y in this configuration because it depends on LIBNVDIMM, which may itself be =m. Add a Kconfig dependency to prevent CXL_ACPI from being built-in when CXL_PMEM is a module. This contrains CXL_ACPI to =m when CXL_PMEM=m, while still allowing CXL_ACPI to be freely configured when CXL_PMEM is either built-in or disabled. [ dj: Fix up commit reference formatting. ] Fixes: e7e222ad73d9 ("cxl: Move devm_cxl_add_nvdimm_bridge() to cxl_pmem.ko") Signed-off-by: Keith Busch Reviewed-by: Jonathan Cameron Reviewed-by: Dan Williams Link: https://patch.msgid.link/20260305204057.1516948-1-kbusch@meta.com Signed-off-by: Dave Jiang Signed-off-by: Greg Kroah-Hartman commit 003df94bcc9227e8e930abd03ac7f63ac10033dc Author: Adrian Hunter Date: Fri Mar 6 09:24:45 2026 +0200 i3c: mipi-i3c-hci: Correct RING_CTRL_ABORT handling in DMA dequeue commit b795e68bf3073d67bebbb5a44d93f49efc5b8cc7 upstream. The logic used to abort the DMA ring contains several flaws: 1. The driver unconditionally issues a ring abort even when the ring has already stopped. 2. The completion used to wait for abort completion is never re-initialized, resulting in incorrect wait behavior. 3. The abort sequence unintentionally clears RING_CTRL_ENABLE, which resets hardware ring pointers and disrupts the controller state. 4. If the ring is already stopped, the abort operation should be considered successful without attempting further action. Fix the abort handling by checking whether the ring is running before issuing an abort, re-initializing the completion when needed, ensuring that RING_CTRL_ENABLE remains asserted during abort, and treating an already stopped ring as a successful condition. Fixes: 9ad9a52cce282 ("i3c/master: introduce the mipi-i3c-hci driver") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260306072451.11131-9-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit b684b420a5bb0ea1b0e13abfdb8ce41c5266e62e Author: Adrian Hunter Date: Fri Mar 6 09:24:43 2026 +0200 i3c: mipi-i3c-hci: Fix race in DMA ring dequeue commit 1dca8aee80eea76d2aae21265de5dd64f6ba0f09 upstream. The HCI DMA dequeue path (hci_dma_dequeue_xfer()) may be invoked for multiple transfers that timeout around the same time. However, the function is not serialized and can race with itself. When a timeout occurs, hci_dma_dequeue_xfer() stops the ring, processes incomplete transfers, and then restarts the ring. If another timeout triggers a parallel call into the same function, the two instances may interfere with each other - stopping or restarting the ring at unexpected times. Add a mutex so that hci_dma_dequeue_xfer() is serialized with respect to itself. Fixes: 9ad9a52cce282 ("i3c/master: introduce the mipi-i3c-hci driver") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260306072451.11131-7-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit a21d7633358861ef10ed534b9f0445cc6bb22af7 Author: Adrian Hunter Date: Fri Mar 6 09:24:46 2026 +0200 i3c: mipi-i3c-hci: Add missing TID field to no-op command descriptor commit ec3cfd835f7c4bbd23bc9ad909d2fdc772a578bb upstream. The internal control command descriptor used for no-op commands includes a Transaction ID (TID) field, but the no-op command constructed in hci_dma_dequeue_xfer() omitted it. As a result, the hardware receives a no-op descriptor without the expected TID. This bug has gone unnoticed because the TID is currently not validated in the no-op completion path, but the descriptor format requires it to be present. Add the missing TID field when generating a no-op descriptor so that its layout matches the defined command structure. Fixes: 9ad9a52cce282 ("i3c/master: introduce the mipi-i3c-hci driver") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260306072451.11131-10-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 57f99dc660e698bce132f885956ec105a8444c8d Author: Adrian Hunter Date: Fri Mar 6 09:24:47 2026 +0200 i3c: mipi-i3c-hci: Restart DMA ring correctly after dequeue abort commit b6d586431ae20d5157ee468d0ef62ad26798ef13 upstream. The DMA dequeue path attempts to restart the ring after aborting an in-flight transfer, but the current sequence is incomplete. The controller must be brought out of the aborted state and the ring control registers must be programmed in the correct order: first clearing ABORT, then re-enabling the ring and asserting RUN_STOP to resume operation. Add the missing controller resume step and update the ring control writes so that the ring is restarted using the proper sequence. Fixes: 9ad9a52cce282 ("i3c/master: introduce the mipi-i3c-hci driver") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260306072451.11131-11-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit d986d51a83f5c7dce0b4e8e0535e80339a2e62fc Author: Adrian Hunter Date: Fri Mar 6 09:24:41 2026 +0200 i3c: mipi-i3c-hci: Consolidate spinlocks commit fa12bb903bc3ed1826e355d267fe134bde95e23c upstream. The MIPI I3C HCI driver currently uses separate spinlocks for different contexts (PIO vs. DMA rings). This split is unnecessary and complicates upcoming fixes. The driver does not support concurrent PIO and DMA operation, and it only supports a single DMA ring, so a single lock is sufficient for all paths. Introduce a unified spinlock in struct i3c_hci, switch both PIO and DMA code to use it, and remove the per-context locks. No functional change is intended in this patch. Fixes: 9ad9a52cce282 ("i3c/master: introduce the mipi-i3c-hci driver") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260306072451.11131-5-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 74a4f77bbf786c9cc714fb8c0fea0d0c00a79705 Author: Adrian Hunter Date: Fri Mar 6 09:24:40 2026 +0200 i3c: mipi-i3c-hci: Factor out DMA mapping from queuing path commit f3bcbfe1b8b0b836b772927f75f8cb6e759eb00a upstream. Prepare for fixing a race in the DMA ring enqueue path when handling parallel transfers. Move all DMA mapping out of hci_dma_queue_xfer() and into a new helper that performs the mapping up front. This refactoring allows the upcoming fix to extend the spinlock coverage around the enqueue operation without performing DMA mapping under the spinlock. No functional change is intended in this patch. Fixes: 9ad9a52cce282 ("i3c/master: introduce the mipi-i3c-hci driver") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260306072451.11131-4-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 478a99a9618290b41299a6b6b1e84556d0e24ae7 Author: Adrian Hunter Date: Fri Mar 6 09:24:38 2026 +0200 i3c: mipi-i3c-hci: Use ETIMEDOUT instead of ETIME for timeout errors commit 4167b8914463132654e01e16259847d097f8a7f7 upstream. The MIPI I3C HCI driver currently returns -ETIME for various timeout conditions, while other I3C master drivers consistently use -ETIMEDOUT for the same class of errors. Align the HCI driver with the rest of the subsystem by replacing all uses of -ETIME with -ETIMEDOUT. Fixes: 9ad9a52cce282 ("i3c/master: introduce the mipi-i3c-hci driver") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260306072451.11131-2-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit ad9da7d39cecd3e92f54149ea0ebca390f33fe69 Author: Yasin Lee Date: Fri Feb 13 23:14:44 2026 +0800 iio: proximity: hx9023s: Protect against division by zero in set_samp_freq commit a318cfc0853706f1d6ce682dba660bc455d674ef upstream. Avoid division by zero when sampling frequency is unspecified. Fixes: 60df548277b7 ("iio: proximity: Add driver support for TYHX's HX9023S capacitive proximity sensor") Signed-off-by: Yasin Lee Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 05723a2c4b09dddc258fc7c496b7750c729d3fd9 Author: Yasin Lee Date: Fri Feb 13 23:14:43 2026 +0800 iio: proximity: hx9023s: fix assignment order for __counted_by commit 585b90c0161ab77416fe3acdbdc55b978e33e16c upstream. Initialize fw_size before copying firmware data into the flexible array member to match the __counted_by() annotation. This fixes the incorrect assignment order that triggers runtime safety checks. Fixes: e9ed97be4fcc ("iio: proximity: hx9023s: Added firmware file parsing functionality") Signed-off-by: Yasin Lee Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 70b455484a661ed6da5a3f6c8273d77dd95d4af6 Author: Jean-Baptiste Maneyrol Date: Fri Jan 30 17:10:23 2026 +0100 iio: imu: inv_icm42600: fix odr switch when turning buffer off commit ffd32db8263d2d785a2c419486a450dc80693235 upstream. ODR switch is done in 2 steps when FIFO is on : change the ODR register value and acknowledge change when reading the FIFO ODR change flag. When we are switching odr and turning buffer off just afterward, we are losing the FIFO ODR change flag and ODR switch is blocked. Fix the issue by force applying any waiting ODR change when turning buffer off. Fixes: ec74ae9fd37c ("iio: imu: inv_icm42600: add accurate timestamping") Signed-off-by: Jean-Baptiste Maneyrol Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit b5a6825579a7ca5e2958521a9ce6d8e37cab9409 Author: Jean-Baptiste Maneyrol Date: Fri Jan 30 16:38:47 2026 +0100 iio: imu: inv_icm42600: fix odr switch to the same value commit c9f3a593137d862d424130343e77d4b5260a4f5a upstream. ODR switch is done in 2 steps when FIFO is on : change the ODR register value and acknowledge change when reading the FIFO ODR change flag. When we are switching to the same odr value, we end up waiting for a FIFO ODR flag that is never happening. Fix the issue by doing nothing and exiting properly when we are switching to the same ODR value. Fixes: ec74ae9fd37c ("iio: imu: inv_icm42600: add accurate timestamping") Signed-off-by: Jean-Baptiste Maneyrol Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit aae572ddc28578af476cce7da3faec0395ef0bf0 Author: Antoniu Miclaus Date: Fri Jan 30 13:30:20 2026 +0200 iio: light: bh1780: fix PM runtime leak on error path commit dd72e6c3cdea05cad24e99710939086f7a113fb5 upstream. Move pm_runtime_put_autosuspend() before the error check to ensure the PM runtime reference count is always decremented after pm_runtime_get_sync(), regardless of whether the read operation succeeds or fails. Fixes: 1f0477f18306 ("iio: light: new driver for the ROHM BH1780") Signed-off-by: Antoniu Miclaus Reviewed-by: Linus Walleij Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit a8714d2d0df4e0f5a89b27e3993ea665a68e1b01 Author: Antoniu Miclaus Date: Mon Feb 16 11:57:55 2026 +0200 iio: gyro: mpu3050-i2c: fix pm_runtime error handling commit 91f950b4cbb1aa9ea4eb3999f1463e8044b717fb upstream. The return value of pm_runtime_get_sync() is not checked, and the function always returns success. This allows I2C mux operations to proceed even when the device fails to resume. Use pm_runtime_resume_and_get() and propagate its return value to properly handle resume failures. Fixes: 3904b28efb2c ("iio: gyro: Add driver for the MPU-3050 gyroscope") Signed-off-by: Antoniu Miclaus Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit ba19dd366528b961430f5195c2e382420703074f Author: Radu Sabau Date: Fri Feb 20 16:16:41 2026 +0200 iio: imu: adis: Fix NULL pointer dereference in adis_init commit 9990cd4f8827bd1ae3fb6eb7407630d8d463c430 upstream. The adis_init() function dereferences adis->ops to check if the individual function pointers (write, read, reset) are NULL, but does not first check if adis->ops itself is NULL. Drivers like adis16480, adis16490, adis16545 and others do not set custom ops and rely on adis_init() assigning the defaults. Since struct adis is zero-initialized by devm_iio_device_alloc(), adis->ops is NULL when adis_init() is called, causing a NULL pointer dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 pc : adis_init+0xc0/0x118 Call trace: adis_init+0xc0/0x118 adis16480_probe+0xe0/0x670 Fix this by checking if adis->ops is NULL before dereferencing it, falling through to assign the default ops in that case. Fixes: 3b29bcee8f6f ("iio: imu: adis: Add custom ops struct") Signed-off-by: Radu Sabau Reviewed-by: Andy Shevchenko Reviewed-by: Antoniu Miclaus Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 42685cf96e28262e0b84d74447f3d99f3f6a72e0 Author: Antoniu Miclaus Date: Mon Feb 16 11:57:56 2026 +0200 iio: gyro: mpu3050-core: fix pm_runtime error handling commit acc3949aab3e8094641a9c7c2768de1958c88378 upstream. The return value of pm_runtime_get_sync() is not checked, allowing the driver to access hardware that may fail to resume. The device usage count is also unconditionally incremented. Use pm_runtime_resume_and_get() which propagates errors and avoids incrementing the usage count on failure. In preenable, add pm_runtime_put_autosuspend() on set_8khz_samplerate() failure since postdisable does not run when preenable fails. Fixes: 3904b28efb2c ("iio: gyro: Add driver for the MPU-3050 gyroscope") Reviewed-by: Linus Walleij Signed-off-by: Antoniu Miclaus Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit c7ae426705b0102338957b3648229a1b32a4eb9a Author: Nuno Sá Date: Mon Feb 16 13:24:27 2026 +0000 iio: buffer: Fix wait_queue not being removed commit 064234044056c93a3719d6893e6e5a26a94a61b6 upstream. In the edge case where the IIO device is unregistered while we're buffering, we were directly returning an error without removing the wait queue. Instead, set 'ret' and break out of the loop. Fixes: 9eeee3b0bf19 ("iio: Add output buffer support") Signed-off-by: Nuno Sá Reviewed-by: David Lechner Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit c528dc22d58b714e50ebe8d656a0d7350743d219 Author: Chris Spencer Date: Thu Feb 5 14:55:45 2026 +0000 iio: chemical: bme680: Fix measurement wait duration calculation commit f55b9510cd9437da3a0efa08b089caeb47595ff1 upstream. This function refers to the Bosch BME680 API as the source of the calculation, but one of the constants does not match the Bosch implementation. This appears to be a simple transposition of two digits, resulting in a wait time that is too short. This can cause the following 'device measurement cycle incomplete' check to occasionally fail, returning EBUSY to user space. Adjust the constant to match the Bosch implementation and resolve the EBUSY errors. Fixes: 4241665e6ea0 ("iio: chemical: bme680: Fix sensor data read operation") Link: https://github.com/boschsensortec/BME68x_SensorAPI/blob/v4.4.8/bme68x.c#L521 Signed-off-by: Chris Spencer Acked-by: Vasileios Amoiridis Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 7c5edf1025ddb68337dcf6dfafb41ec0cf4e21c1 Author: Lukas Schmid Date: Mon Feb 2 21:15:35 2026 +0100 iio: potentiometer: mcp4131: fix double application of wiper shift commit 85e4614524dca6c0a43874f475a17de2b9725648 upstream. The MCP4131 wiper address is shifted twice when preparing the SPI command in mcp4131_write_raw(). The address is already shifted when assigned to the local variable "address", but is then shifted again when written to data->buf[0]. This results in an incorrect command being sent to the device and breaks wiper writes to the second channel. Remove the second shift and use the pre-shifted address directly when composing the SPI transfer. Fixes: 22d199a53910 ("iio: potentiometer: add driver for Microchip MCP413X/414X/415X/416X/423X/424X/425X/426X") Signed-off-by: Lukas Schmid # Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit b8a26d21c7dba086fd3753da168785ba74803e0c Author: Antoniu Miclaus Date: Tue Feb 10 18:49:50 2026 +0200 iio: magnetometer: tlv493d: remove erroneous shift in X-axis data commit 82ee91d6b15f06b6094eea2c26afe0032fe8e177 upstream. TLV493D_BX2_MAG_X_AXIS_LSB is defined as GENMASK(7, 4). FIELD_GET() already right-shifts bits [7:4] to [3:0], so the additional >> 4 discards most of the X-axis low nibble. The Y and Z axes correctly omit this extra shift. Remove it. Fixes: 106511d280c7 ("iio: magnetometer: add support for Infineon TLV493D 3D Magentic sensor") Signed-off-by: Antoniu Miclaus Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 90e978ace598567e6e30de79805bddf37cf892ac Author: Antoniu Miclaus Date: Thu Feb 12 14:46:07 2026 +0200 iio: chemical: sps30_i2c: fix buffer size in sps30_i2c_read_meas() commit 216345f98cae7fcc84f49728c67478ac00321c87 upstream. sizeof(num) evaluates to sizeof(size_t) (8 bytes on 64-bit) instead of the intended __be32 element size (4 bytes). Use sizeof(*meas) to correctly match the buffer element type. Fixes: 8f3f13085278 ("iio: sps30: separate core and interface specific code") Signed-off-by: Antoniu Miclaus Acked-by: Tomasz Duszynski Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit eddba110685f8120f9cdf9bfd93ebe87a8bb527b Author: Antoniu Miclaus Date: Thu Feb 12 14:46:08 2026 +0200 iio: chemical: sps30_serial: fix buffer size in sps30_serial_read_meas() commit c3914ce1963c4db25e186112c90fa5d2361e9e0a upstream. sizeof(num) evaluates to sizeof(size_t) which is 8 bytes on 64-bit, but the buffer elements are only 4 bytes. The same function already uses sizeof(*meas) on line 312, making the mismatch evident. Use sizeof(*meas) consistently. Fixes: b2e171f5a5c6 ("iio: sps30: add support for serial interface") Signed-off-by: Antoniu Miclaus Acked-by: Tomasz Duszynski Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 73dd9acb5b20bf67dad5544a786dd8565f4e0ce3 Author: SeungJu Cheon Date: Sat Jan 24 04:47:58 2026 +0900 iio: frequency: adf4377: Fix duplicated soft reset mask commit 6c8bf4b604a8a6346ca71f1c027fa01c2c2e04cb upstream. The regmap_read_poll_timeout() uses ADF4377_0000_SOFT_RESET_R_MSK twice instead of checking both SOFT_RESET_MSK (bit 0) and SOFT_RESET_R_MSK (bit 7). This causes an incomplete reset status check. The code first sets both SOFT_RESET and SOFT_RESET_R bits to 1 via regmap_update_bits(), then polls for them to be cleared. Since we set both bits before polling, we should be waiting for both to clear. Fix by using both masks as done in regmap_update_bits() above. Fixes: eda549e2e524 ("iio: frequency: adf4377: add support for ADF4377") Signed-off-by: SeungJu Cheon Cc: Stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 1b2d9e23452bd8adf280f47a5bf043216bb19c67 Author: Oleksij Rempel Date: Wed Feb 4 15:00:33 2026 +0100 iio: dac: ds4424: reject -128 RAW value commit 5187e03b817c26c1c3bcb2645a612ea935c4be89 upstream. The DS442x DAC uses sign-magnitude encoding, so -128 cannot be represented in hardware (7-bit magnitude). Previously, passing -128 resulted in a truncated value that programmed 0mA (magnitude 0) instead of the expected maximum negative current, effectively failing silently. Reject -128 to avoid producing the wrong current. Fixes: d632a2bd8ffc ("iio: dac: ds4422/ds4424 dac driver") Cc: stable@vger.kernel.org Signed-off-by: Oleksij Rempel Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 014a021075c5890d00559675fe7433374d7854dd Author: Filipe Manana Date: Fri Feb 27 00:02:33 2026 +0000 btrfs: abort transaction on failure to update root in the received subvol ioctl commit 0f475ee0ebce5c9492b260027cd95270191675fa upstream. If we failed to update the root we don't abort the transaction, which is wrong since we already used the transaction to remove an item from the uuid tree. Fixes: dd5f9615fc5c ("Btrfs: maintain subvolume items in the UUID tree") CC: stable@vger.kernel.org # 3.12+ Reviewed-by: Anand Jain Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 5e1ab71f74a1e61f1254dff128a764fdebaec0b8 Author: Bart Van Assche Date: Wed Feb 25 11:59:58 2026 -0800 btrfs: add missing RCU unlock in error path in try_release_subpage_extent_buffer() commit b2840e33127ce0eea880504b7f133e780f567a9b upstream. Call rcu_read_lock() before exiting the loop in try_release_subpage_extent_buffer() because there is a rcu_read_unlock() call past the loop. This has been detected by the Clang thread-safety analyzer. Fixes: ad580dfa388f ("btrfs: fix subpage deadlock in try_release_subpage_extent_buffer()") CC: stable@vger.kernel.org # 6.18+ Reviewed-by: Qu Wenruo Reviewed-by: Boris Burkov Signed-off-by: Bart Van Assche Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit d11aefe654a04fc41996d254748d6a38b6b0a7be Author: Filipe Manana Date: Thu Feb 26 23:41:07 2026 +0000 btrfs: fix transaction abort on set received ioctl due to item overflow commit 87f2c46003fce4d739138aab4af1942b1afdadac upstream. If the set received ioctl fails due to an item overflow when attempting to add the BTRFS_UUID_KEY_RECEIVED_SUBVOL we have to abort the transaction since we did some metadata updates before. This means that if a user calls this ioctl with the same received UUID field for a lot of subvolumes, we will hit the overflow, trigger the transaction abort and turn the filesystem into RO mode. A malicious user could exploit this, and this ioctl does not even requires that a user has admin privileges (CAP_SYS_ADMIN), only that he/she owns the subvolume. Fix this by doing an early check for item overflow before starting a transaction. This is also race safe because we are holding the subvol_sem semaphore in exclusive (write) mode. A test case for fstests will follow soon. Fixes: dd5f9615fc5c ("Btrfs: maintain subvolume items in the UUID tree") CC: stable@vger.kernel.org # 3.12+ Reviewed-by: Anand Jain Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 9273175bf16c83f3ec93aa242d78c9b5db452d4d Author: Filipe Manana Date: Thu Feb 26 11:05:43 2026 +0000 btrfs: fix transaction abort on file creation due to name hash collision commit 2d1ababdedd4ba38867c2500eb7f95af5ddeeef7 upstream. If we attempt to create several files with names that result in the same hash, we have to pack them in same dir item and that has a limit inherent to the leaf size. However if we reach that limit, we trigger a transaction abort and turns the filesystem into RO mode. This allows for a malicious user to disrupt a system, without the need to have administration privileges/capabilities. Reproducer: $ cat exploit-hash-collisions.sh #!/bin/bash DEV=/dev/sdi MNT=/mnt/sdi # Use smallest node size to make the test faster and require fewer file # names that result in hash collision. mkfs.btrfs -f --nodesize 4K $DEV mount $DEV $MNT # List of names that result in the same crc32c hash for btrfs. declare -a names=( 'foobar' '%a8tYkxfGMLWRGr55QSeQc4PBNH9PCLIvR6jZnkDtUUru1t@RouaUe_L:@xGkbO3nCwvLNYeK9vhE628gss:T$yZjZ5l-Nbd6CbC$M=hqE-ujhJICXyIxBvYrIU9-TDC' 'AQci3EUB%shMsg-N%frgU:02ByLs=IPJU0OpgiWit5nexSyxZDncY6WB:=zKZuk5Zy0DD$Ua78%MelgBuMqaHGyKsJUFf9s=UW80PcJmKctb46KveLSiUtNmqrMiL9-Y0I_l5Fnam04CGIg=8@U:Z' 'CvVqJpJzueKcuA$wqwePfyu7VxuWNN3ho$p0zi2H8QFYK$7YlEqOhhb%:hHgjhIjW5vnqWHKNP4' 'ET:vk@rFU4tsvMB0$C_p=xQHaYZjvoF%-BTc%wkFW8yaDAPcCYoR%x$FH5O:' 'HwTon%v7SGSP4FE08jBwwiu5aot2CFKXHTeEAa@38fUcNGOWvE@Mz6WBeDH_VooaZ6AgsXPkVGwy9l@@ZbNXabUU9csiWrrOp0MWUdfi$EZ3w9GkIqtz7I_eOsByOkBOO' 'Ij%2VlFGXSuPvxJGf5UWy6O@1svxGha%b@=%wjkq:CIgE6u7eJOjmQY5qTtxE2Rjbis9@us' 'KBkjG5%9R8K9sOG8UTnAYjxLNAvBmvV5vz3IiZaPmKuLYO03-6asI9lJ_j4@6Xo$KZicaLWJ3Pv8XEwVeUPMwbHYWwbx0pYvNlGMO9F:ZhHAwyctnGy%_eujl%WPd4U2BI7qooOSr85J-C2V$LfY' 'NcRfDfuUQ2=zP8K3CCF5dFcpfiOm6mwenShsAb_F%n6GAGC7fT2JFFn:c35X-3aYwoq7jNX5$ZJ6hI3wnZs$7KgGi7wjulffhHNUxAT0fRRLF39vJ@NvaEMxsMO' 'Oj42AQAEzRoTxa5OuSKIr=A_lwGMy132v4g3Pdq1GvUG9874YseIFQ6QU' 'Ono7avN5GjC:_6dBJ_' 'WHmN2gnmaN-9dVDy4aWo:yNGFzz8qsJyJhWEWcud7$QzN2D9R0efIWWEdu5kwWr73NZm4=@CoCDxrrZnRITr-kGtU_cfW2:%2_am' 'WiFnuTEhAG9FEC6zopQmj-A-$LDQ0T3WULz%ox3UZAPybSV6v1Z$b4L_XBi4M4BMBtJZpz93r9xafpB77r:lbwvitWRyo$odnAUYlYMmU4RvgnNd--e=I5hiEjGLETTtaScWlQp8mYsBovZwM2k' 'XKyH=OsOAF3p%uziGF_ZVr$ivrvhVgD@1u%5RtrV-gl_vqAwHkK@x7YwlxX3qT6WKKQ%PR56NrUBU2dOAOAdzr2=5nJuKPM-T-$ZpQfCL7phxQbUcb:BZOTPaFExc-qK-gDRCDW2' 'd3uUR6OFEwZr%ns1XH_@tbxA@cCPmbBRLdyh7p6V45H$P2$F%w0RqrD3M0g8aGvWpoTFMiBdOTJXjD:JF7=h9a_43xBywYAP%r$SPZi%zDg%ql-KvkdUCtF9OLaQlxmd' 'ePTpbnit%hyNm@WELlpKzNZYOzOTf8EQ$sEfkMy1VOfIUu3coyvIr13-Y7Sv5v-Ivax2Go_GQRFMU1b3362nktT9WOJf3SpT%z8sZmM3gvYQBDgmKI%%RM-G7hyrhgYflOw%z::ZRcv5O:lDCFm' 'evqk743Y@dvZAiG5J05L_ROFV@$2%rVWJ2%3nxV72-W7$e$-SK3tuSHA2mBt$qloC5jwNx33GmQUjD%akhBPu=VJ5g$xhlZiaFtTrjeeM5x7dt4cHpX0cZkmfImndYzGmvwQG:$euFYmXn$_2rA9mKZ' 'gkgUtnihWXsZQTEkrMAWIxir09k3t7jk_IK25t1:cy1XWN0GGqC%FrySdcmU7M8MuPO_ppkLw3=Dfr0UuBAL4%GFk2$Ma10V1jDRGJje%Xx9EV2ERaWKtjpwiZwh0gCSJsj5UL7CR8RtW5opCVFKGGy8Cky' 'hNgsG_8lNRik3PvphqPm0yEH3P%%fYG:kQLY=6O-61Wa6nrV_WVGR6TLB09vHOv%g4VQRP8Gzx7VXUY1qvZyS' 'isA7JVzN12xCxVPJZ_qoLm-pTBuhjjHMvV7o=F:EaClfYNyFGlsfw-Kf%uxdqW-kwk1sPl2vhbjyHU1A6$hz' 'kiJ_fgcdZFDiOptjgH5PN9-PSyLO4fbk_:u5_2tz35lV_iXiJ6cx7pwjTtKy-XGaQ5IefmpJ4N_ZqGsqCsKuqOOBgf9LkUdffHet@Wu' 'lvwtxyhE9:%Q3UxeHiViUyNzJsy:fm38pg_b6s25JvdhOAT=1s0$pG25x=LZ2rlHTszj=gN6M4zHZYr_qrB49i=pA--@WqWLIuX7o1S_SfS@2FSiUZN' 'rC24cw3UBDZ=5qJBUMs9e$=S4Y94ni%Z8639vnrGp=0Hv4z3dNFL0fBLmQ40=EYIY:Z=SLc@QLMSt2zsss2ZXrP7j4=' 'uwGl2s-fFrf@GqS=DQqq2I0LJSsOmM%xzTjS:lzXguE3wChdMoHYtLRKPvfaPOZF2fER@j53evbKa7R%A7r4%YEkD=kicJe@SFiGtXHbKe4gCgPAYbnVn' 'UG37U6KKua2bgc:IHzRs7BnB6FD:2Mt5Cc5NdlsW%$1tyvnfz7S27FvNkroXwAW:mBZLA1@qa9WnDbHCDmQmfPMC9z-Eq6QT0jhhPpqyymaD:R02ghwYo%yx7SAaaq-:x33LYpei$5g8DMl3C' 'y2vjek0FE1PDJC0qpfnN:x8k2wCFZ9xiUF2ege=JnP98R%wxjKkdfEiLWvQzmnW' '8-HCSgH5B%K7P8_jaVtQhBXpBk:pE-$P7ts58U0J@iR9YZntMPl7j$s62yAJO@_9eanFPS54b=UTw$94C-t=HLxT8n6o9P=QnIxq-f1=Ne2dvhe6WbjEQtc' 'YPPh:IFt2mtR6XWSmjHptXL_hbSYu8bMw-JP8@PNyaFkdNFsk$M=xfL6LDKCDM-mSyGA_2MBwZ8Dr4=R1D%7-mCaaKGxb990jzaagRktDTyp' '9hD2ApKa_t_7x-a@GCG28kY:7$M@5udI1myQ$x5udtggvagmCQcq9QXWRC5hoB0o-_zHQUqZI5rMcz_kbMgvN5jr63LeYA4Cj-c6F5Ugmx6DgVf@2Jqm%MafecpgooqreJ53P-QTS' ) # Now create files with all those names in the same parent directory. # It should not fail since a 4K leaf has enough space for them. for name in "${names[@]}"; do touch $MNT/$name done # Now add one more file name that causes a crc32c hash collision. # This should fail, but it should not turn the filesystem into RO mode # (which could be exploited by malicious users) due to a transaction # abort. touch $MNT/'W6tIm-VK2@BGC@IBfcgg6j_p:pxp_QUqtWpGD5Ok_GmijKOJJt' # Check that we are able to create another file, with a name that does not cause # a crc32c hash collision. echo -n "hello world" > $MNT/baz # Unmount and mount again, verify file baz exists and with the right content. umount $MNT mount $DEV $MNT echo "File baz content: $(cat $MNT/baz)" umount $MNT When running the reproducer: $ ./exploit-hash-collisions.sh (...) touch: cannot touch '/mnt/sdi/W6tIm-VK2@BGC@IBfcgg6j_p:pxp_QUqtWpGD5Ok_GmijKOJJt': Value too large for defined data type ./exploit-hash-collisions.sh: line 57: /mnt/sdi/baz: Read-only file system cat: /mnt/sdi/baz: No such file or directory File baz content: And the transaction abort stack trace in dmesg/syslog: $ dmesg (...) [758240.509761] ------------[ cut here ]------------ [758240.510668] BTRFS: Transaction aborted (error -75) [758240.511577] WARNING: fs/btrfs/inode.c:6854 at btrfs_create_new_inode+0x805/0xb50 [btrfs], CPU#6: touch/888644 [758240.513513] Modules linked in: btrfs dm_zero (...) [758240.523221] CPU: 6 UID: 0 PID: 888644 Comm: touch Tainted: G W 6.19.0-rc8-btrfs-next-225+ #1 PREEMPT(full) [758240.524621] Tainted: [W]=WARN [758240.525037] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [758240.526331] RIP: 0010:btrfs_create_new_inode+0x80b/0xb50 [btrfs] [758240.527093] Code: 0f 82 cf (...) [758240.529211] RSP: 0018:ffffce64418fbb48 EFLAGS: 00010292 [758240.529935] RAX: 00000000ffffffd3 RBX: 0000000000000000 RCX: 00000000ffffffb5 [758240.531040] RDX: 0000000d04f33e06 RSI: 00000000ffffffb5 RDI: ffffffffc0919dd0 [758240.531920] RBP: ffffce64418fbc10 R08: 0000000000000000 R09: 00000000ffffffb5 [758240.532928] R10: 0000000000000000 R11: ffff8e52c0000000 R12: ffff8e53eee7d0f0 [758240.533818] R13: ffff8e57f70932a0 R14: ffff8e5417629568 R15: 0000000000000000 [758240.534664] FS: 00007f1959a2a740(0000) GS:ffff8e5b27cae000(0000) knlGS:0000000000000000 [758240.535821] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [758240.536644] CR2: 00007f1959b10ce0 CR3: 000000012a2cc005 CR4: 0000000000370ef0 [758240.537517] Call Trace: [758240.537828] [758240.538099] btrfs_create_common+0xbf/0x140 [btrfs] [758240.538760] path_openat+0x111a/0x15b0 [758240.539252] do_filp_open+0xc2/0x170 [758240.539699] ? preempt_count_add+0x47/0xa0 [758240.540200] ? __virt_addr_valid+0xe4/0x1a0 [758240.540800] ? __check_object_size+0x1b3/0x230 [758240.541661] ? alloc_fd+0x118/0x180 [758240.542315] do_sys_openat2+0x70/0xd0 [758240.543012] __x64_sys_openat+0x50/0xa0 [758240.543723] do_syscall_64+0x50/0xf20 [758240.544462] entry_SYSCALL_64_after_hwframe+0x76/0x7e [758240.545397] RIP: 0033:0x7f1959abc687 [758240.546019] Code: 48 89 fa (...) [758240.548522] RSP: 002b:00007ffe16ff8690 EFLAGS: 00000202 ORIG_RAX: 0000000000000101 [758240.566278] RAX: ffffffffffffffda RBX: 00007f1959a2a740 RCX: 00007f1959abc687 [758240.567068] RDX: 0000000000000941 RSI: 00007ffe16ffa333 RDI: ffffffffffffff9c [758240.567860] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [758240.568707] R10: 00000000000001b6 R11: 0000000000000202 R12: 0000561eec7c4b90 [758240.569712] R13: 0000561eec7c311f R14: 00007ffe16ffa333 R15: 0000000000000000 [758240.570758] [758240.571040] ---[ end trace 0000000000000000 ]--- [758240.571681] BTRFS: error (device sdi state A) in btrfs_create_new_inode:6854: errno=-75 unknown [758240.572899] BTRFS info (device sdi state EA): forced readonly Fix this by checking for hash collision, and if the adding a new name is possible, early in btrfs_create_new_inode() before we do any tree updates, so that we don't need to abort the transaction if we cannot add the new name due to the leaf size limit. A test case for fstests will be sent soon. Fixes: caae78e03234 ("btrfs: move common inode creation code into btrfs_create_new_inode()") CC: stable@vger.kernel.org # 6.1+ Reviewed-by: Boris Burkov Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit bac55dde8efa457e769c934fd88a63f2141ba238 Author: Filipe Manana Date: Mon Feb 23 16:19:31 2026 +0000 btrfs: fix transaction abort when snapshotting received subvolumes commit e1b18b959025e6b5dbad668f391f65d34b39595a upstream. Currently a user can trigger a transaction abort by snapshotting a previously received snapshot a bunch of times until we reach a BTRFS_UUID_KEY_RECEIVED_SUBVOL item overflow (the maximum item size we can store in a leaf). This is very likely not common in practice, but if it happens, it turns the filesystem into RO mode. The snapshot, send and set_received_subvol and subvol_setflags (used by receive) don't require CAP_SYS_ADMIN, just inode_owner_or_capable(). A malicious user could use this to turn a filesystem into RO mode and disrupt a system. Reproducer script: $ cat test.sh #!/bin/bash DEV=/dev/sdi MNT=/mnt/sdi # Use smallest node size to make the test faster. mkfs.btrfs -f --nodesize 4K $DEV mount $DEV $MNT # Create a subvolume and set it to RO so that it can be used for send. btrfs subvolume create $MNT/sv touch $MNT/sv/foo btrfs property set $MNT/sv ro true # Send and receive the subvolume into snaps/sv. mkdir $MNT/snaps btrfs send $MNT/sv | btrfs receive $MNT/snaps # Now snapshot the received subvolume, which has a received_uuid, a # lot of times to trigger the leaf overflow. total=500 for ((i = 1; i <= $total; i++)); do echo -ne "\rCreating snapshot $i/$total" btrfs subvolume snapshot -r $MNT/snaps/sv $MNT/snaps/sv_$i > /dev/null done echo umount $MNT When running the test: $ ./test.sh (...) Create subvolume '/mnt/sdi/sv' At subvol /mnt/sdi/sv At subvol sv Creating snapshot 496/500ERROR: Could not create subvolume: Value too large for defined data type Creating snapshot 497/500ERROR: Could not create subvolume: Read-only file system Creating snapshot 498/500ERROR: Could not create subvolume: Read-only file system Creating snapshot 499/500ERROR: Could not create subvolume: Read-only file system Creating snapshot 500/500ERROR: Could not create subvolume: Read-only file system And in dmesg/syslog: $ dmesg (...) [251067.627338] BTRFS warning (device sdi): insert uuid item failed -75 (0x4628b21c4ac8d898, 0x2598bee2b1515c91) type 252! [251067.629212] ------------[ cut here ]------------ [251067.630033] BTRFS: Transaction aborted (error -75) [251067.630871] WARNING: fs/btrfs/transaction.c:1907 at create_pending_snapshot.cold+0x52/0x465 [btrfs], CPU#10: btrfs/615235 [251067.632851] Modules linked in: btrfs dm_zero (...) [251067.644071] CPU: 10 UID: 0 PID: 615235 Comm: btrfs Tainted: G W 6.19.0-rc8-btrfs-next-225+ #1 PREEMPT(full) [251067.646165] Tainted: [W]=WARN [251067.646733] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [251067.648735] RIP: 0010:create_pending_snapshot.cold+0x55/0x465 [btrfs] [251067.649984] Code: f0 48 0f (...) [251067.653313] RSP: 0018:ffffce644908fae8 EFLAGS: 00010292 [251067.653987] RAX: 00000000ffffff01 RBX: ffff8e5639e63a80 RCX: 00000000ffffffd3 [251067.655042] RDX: ffff8e53faa76b00 RSI: 00000000ffffffb5 RDI: ffffffffc0919750 [251067.656077] RBP: ffffce644908fbd8 R08: 0000000000000000 R09: ffffce644908f820 [251067.657068] R10: ffff8e5adc1fffa8 R11: 0000000000000003 R12: ffff8e53c0431bd0 [251067.658050] R13: ffff8e5414593600 R14: ffff8e55efafd000 R15: 00000000ffffffb5 [251067.659019] FS: 00007f2a4944b3c0(0000) GS:ffff8e5b27dae000(0000) knlGS:0000000000000000 [251067.660115] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [251067.660943] CR2: 00007ffc5aa57898 CR3: 00000005813a2003 CR4: 0000000000370ef0 [251067.661972] Call Trace: [251067.662292] [251067.662653] create_pending_snapshots+0x97/0xc0 [btrfs] [251067.663413] btrfs_commit_transaction+0x26e/0xc00 [btrfs] [251067.664257] ? btrfs_qgroup_convert_reserved_meta+0x35/0x390 [btrfs] [251067.665238] ? _raw_spin_unlock+0x15/0x30 [251067.665837] ? record_root_in_trans+0xa2/0xd0 [btrfs] [251067.666531] btrfs_mksubvol+0x330/0x580 [btrfs] [251067.667145] btrfs_mksnapshot+0x74/0xa0 [btrfs] [251067.667827] __btrfs_ioctl_snap_create+0x194/0x1d0 [btrfs] [251067.668595] btrfs_ioctl_snap_create_v2+0x107/0x130 [btrfs] [251067.669479] btrfs_ioctl+0x1580/0x2690 [btrfs] [251067.670093] ? count_memcg_events+0x6d/0x180 [251067.670849] ? handle_mm_fault+0x1a0/0x2a0 [251067.671652] __x64_sys_ioctl+0x92/0xe0 [251067.672406] do_syscall_64+0x50/0xf20 [251067.673129] entry_SYSCALL_64_after_hwframe+0x76/0x7e [251067.674096] RIP: 0033:0x7f2a495648db [251067.674812] Code: 00 48 89 (...) [251067.678227] RSP: 002b:00007ffc5aa57840 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [251067.679691] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f2a495648db [251067.681145] RDX: 00007ffc5aa588b0 RSI: 0000000050009417 RDI: 0000000000000004 [251067.682511] RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000 [251067.683842] R10: 000000000000000a R11: 0000000000000246 R12: 00007ffc5aa59910 [251067.685176] R13: 00007ffc5aa588b0 R14: 0000000000000004 R15: 0000000000000006 [251067.686524] [251067.686972] ---[ end trace 0000000000000000 ]--- [251067.687890] BTRFS: error (device sdi state A) in create_pending_snapshot:1907: errno=-75 unknown [251067.689049] BTRFS info (device sdi state EA): forced readonly [251067.689054] BTRFS warning (device sdi state EA): Skipping commit of aborted transaction. [251067.690119] BTRFS: error (device sdi state EA) in cleanup_transaction:2043: errno=-75 unknown [251067.702028] BTRFS info (device sdi state EA): last unmount of filesystem 46dc3975-30a2-4a69-a18f-418b859cccda Fix this by ignoring -EOVERFLOW errors from btrfs_uuid_tree_add() in the snapshot creation code when attempting to add the BTRFS_UUID_KEY_RECEIVED_SUBVOL item. This is OK because it's not critical and we are still able to delete the snapshot, as snapshot/subvolume deletion ignores if a BTRFS_UUID_KEY_RECEIVED_SUBVOL is missing (see inode.c:btrfs_delete_subvolume()). As for send/receive, we can still do send/receive operations since it always peeks the first root ID in the existing BTRFS_UUID_KEY_RECEIVED_SUBVOL (it could peek any since all snapshots have the same content), and even if the key is missing, it falls back to searching by BTRFS_UUID_KEY_SUBVOL key. A test case for fstests will be sent soon. Fixes: dd5f9615fc5c ("Btrfs: maintain subvolume items in the UUID tree") CC: stable@vger.kernel.org # 3.12+ Reviewed-by: Boris Burkov Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 9b753ece265242069dfbd9673b62f11b61b8c4f4 Author: Henrique Carvalho Date: Wed Mar 11 20:17:23 2026 -0300 smb: client: fix iface port assignment in parse_server_interfaces commit d4c7210d2f3ea481a6481f03040a64d9077a6172 upstream. parse_server_interfaces() initializes interface socket addresses with CIFS_PORT. When the mount uses a non-default port this overwrites the configured destination port. Later, cifs_chan_update_iface() copies this sockaddr into server->dstaddr, causing reconnect attempts to use the wrong port after server interface updates. Use the existing port from server->dstaddr instead. Cc: stable@vger.kernel.org Fixes: fe856be475f7 ("CIFS: parse and store info on iface queries") Tested-by: Dr. Thomas Orgis Reviewed-by: Enzo Matsumiya Signed-off-by: Henrique Carvalho Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 92e64f1852f455f57d0850989e57c30d7fac7d95 Author: Bharath SM Date: Mon Mar 9 16:00:49 2026 +0530 smb: client: fix in-place encryption corruption in SMB2_write() commit d78840a6a38d312dc1a51a65317bb67e46f0b929 upstream. SMB2_write() places write payload in iov[1..n] as part of rq_iov. smb3_init_transform_rq() pointer-shares rq_iov, so crypt_message() encrypts iov[1] in-place, replacing the original plaintext with ciphertext. On a replayable error, the retry sends the same iov[1] which now contains ciphertext instead of the original data, resulting in corruption. The corruption is most likely to be observed when connections are unstable, as reconnects trigger write retries that re-send the already-encrypted data. This affects SFU mknod, MF symlinks, etc. On kernels before 6.10 (prior to the netfs conversion), sync writes also used this path and were similarly affected. The async write path wasn't unaffected as it uses rq_iter which gets deep-copied. Fix by moving the write payload into rq_iter via iov_iter_kvec(), so smb3_init_transform_rq() deep-copies it before encryption. Cc: stable@vger.kernel.org #6.3+ Acked-by: Henrique Carvalho Acked-by: Shyam Prasad N Acked-by: Paulo Alcantara (Red Hat) Signed-off-by: Bharath SM Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 9509b659ca7ebe52752b5c3d805c24f9df8fa570 Author: Paulo Alcantara Date: Sat Mar 7 18:20:16 2026 -0300 smb: client: fix atomic open with O_DIRECT & O_SYNC commit 4a7d2729dc99437dbb880a64c47828c0d191b308 upstream. When user application requests O_DIRECT|O_SYNC along with O_CREAT on open(2), CREATE_NO_BUFFER and CREATE_WRITE_THROUGH bits were missed in CREATE request when performing an atomic open, thus leading to potentially data integrity issues. Fix this by setting those missing bits in CREATE request when O_DIRECT|O_SYNC has been specified in cifs_do_create(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Paulo Alcantara (Red Hat) Reviewed-by: David Howells Acked-by: Henrique Carvalho Cc: Tom Talpey Cc: linux-cifs@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit bfbf1f286f6820976f85a13fd563665a5d4c16cf Author: Josh Law Date: Thu Mar 12 19:11:42 2026 +0000 lib/bootconfig: check bounds before writing in __xbc_open_brace() commit 560f763baa0f2c9a44da4294c06af071405ac46f upstream. The bounds check for brace_index happens after the array write. While the current call pattern prevents an actual out-of-bounds access (the previous call would have returned an error), the write-before-check pattern is fragile and would become a real out-of-bounds write if the error return were ever not propagated. Move the bounds check before the array write so the function is self-contained and safe regardless of caller behavior. Link: https://lore.kernel.org/all/20260312191143.28719-3-objecting@objecting.org/ Fixes: ead1e19ad905 ("lib/bootconfig: Fix a bug of breaking existing tree nodes") Cc: stable@vger.kernel.org Signed-off-by: Josh Law Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman commit 6e736a18cfbd518514c6fb82f2a46082bffd6394 Author: Josh Law Date: Thu Mar 12 19:11:43 2026 +0000 lib/bootconfig: fix snprintf truncation check in xbc_node_compose_key_after() commit 1120a36bb1e9b9e22de75ecb4ef0b998f73a97f1 upstream. snprintf() returns the number of characters that would have been written excluding the NUL terminator. Output is truncated when the return value is >= the buffer size, not just > the buffer size. When ret == size, the current code takes the non-truncated path, advancing buf by ret and reducing size to 0. This is wrong because the output was actually truncated (the last character was replaced by NUL). Fix by using >= so the truncation path is taken correctly. Link: https://lore.kernel.org/all/20260312191143.28719-4-objecting@objecting.org/ Fixes: 76db5a27a827 ("bootconfig: Add Extra Boot Config support") Cc: stable@vger.kernel.org Signed-off-by: Josh Law Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman commit 12d2b443b8606050fe43c85b7ac55ee4865cb883 Author: Masami Hiramatsu (Google) Date: Fri Mar 13 23:04:11 2026 +0900 kprobes: Remove unneeded warnings from __arm_kprobe_ftrace() commit 5ef268cb7a0aac55521fd9881f1939fa94a8988e upstream. Remove unneeded warnings for handled errors from __arm_kprobe_ftrace() because all caller handled the error correctly. Link: https://lore.kernel.org/all/177261531182.1312989.8737778408503961141.stgit@mhiramat.tok.corp.google.com/ Reported-by: Zw Tang Closes: https://lore.kernel.org/all/CAPHJ_V+J6YDb_wX2nhXU6kh466Dt_nyDSas-1i_Y8s7tqY-Mzw@mail.gmail.com/ Fixes: 9c89bb8e3272 ("kprobes: treewide: Cleanup the error messages for kprobes") Cc: stable@vger.kernel.org Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman commit 11712c4eb384098db4cb08792e223c818b908c1a Author: Shashank Balaji Date: Fri Mar 6 14:46:28 2026 +0900 x86/apic: Disable x2apic on resume if the kernel expects so commit 8cc7dd77a1466f0ec58c03478b2e735a5b289b96 upstream. When resuming from s2ram, firmware may re-enable x2apic mode, which may have been disabled by the kernel during boot either because it doesn't support IRQ remapping or for other reasons. This causes the kernel to continue using the xapic interface, while the hardware is in x2apic mode, which causes hangs. This happens on defconfig + bare metal + s2ram. Fix this in lapic_resume() by disabling x2apic if the kernel expects it to be disabled, i.e. when x2apic_mode = 0. The ACPI v6.6 spec, Section 16.3 [1] says firmware restores either the pre-sleep configuration or initial boot configuration for each CPU, including MSR state: When executing from the power-on reset vector as a result of waking from an S2 or S3 sleep state, the platform firmware performs only the hardware initialization required to restore the system to either the state the platform was in prior to the initial operating system boot, or to the pre-sleep configuration state. In multiprocessor systems, non-boot processors should be placed in the same state as prior to the initial operating system boot. (further ahead) If this is an S2 or S3 wake, then the platform runtime firmware restores minimum context of the system before jumping to the waking vector. This includes: CPU configuration. Platform runtime firmware restores the pre-sleep configuration or initial boot configuration of each CPU (MSR, MTRR, firmware update, SMBase, and so on). Interrupts must be disabled (for IA-32 processors, disabled by CLI instruction). (and other things) So at least as per the spec, re-enablement of x2apic by the firmware is allowed if "x2apic on" is a part of the initial boot configuration. [1] https://uefi.org/specs/ACPI/6.6/16_Waking_and_Sleeping.html#initialization [ bp: Massage. ] Fixes: 6e1cb38a2aef ("x64, x2apic/intr-remap: add x2apic support, including enabling interrupt-remapping") Co-developed-by: Rahul Bukte Signed-off-by: Rahul Bukte Signed-off-by: Shashank Balaji Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Thomas Gleixner Reviewed-by: Sohil Mehta Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260306-x2apic-fix-v2-1-bee99c12efa3@sony.com Signed-off-by: Greg Kroah-Hartman commit 9f9157ee67b32b82a5d16bdbe3e73e248afed23a Author: Junxiao Bi Date: Wed Mar 4 08:46:03 2026 -0800 scsi: core: Fix error handling for scsi_alloc_sdev() commit 4ce7ada40c008fa21b7e52ab9d04e8746e2e9325 upstream. After scsi_sysfs_device_initialize() was called, error paths must call __scsi_remove_device(). Fixes: 1ac22c8eae81 ("scsi: core: Fix refcount leak for tagset_refcnt") Cc: stable@vger.kernel.org Signed-off-by: Junxiao Bi Reviewed-by: John Garry Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260304164603.51528-1-junxiao.bi@oracle.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit d24330cf241f8d33248f88061a325f67df8644b9 Author: Josh Law Date: Thu Mar 12 19:11:41 2026 +0000 lib/bootconfig: fix off-by-one in xbc_verify_tree() unclosed brace error commit 39ebc8d7f561e1b64eca87353ef9b18e2825e591 upstream. __xbc_open_brace() pushes entries with post-increment (open_brace[brace_index++]), so brace_index always points one past the last valid entry. xbc_verify_tree() reads open_brace[brace_index] to report which brace is unclosed, but this is one past the last pushed entry and contains stale/zero data, causing the error message to reference the wrong node. Use open_brace[brace_index - 1] to correctly identify the unclosed brace. brace_index is known to be > 0 here since we are inside the if (brace_index) guard. Link: https://lore.kernel.org/all/20260312191143.28719-2-objecting@objecting.org/ Fixes: ead1e19ad905 ("lib/bootconfig: Fix a bug of breaking existing tree nodes") Cc: stable@vger.kernel.org Signed-off-by: Josh Law Reviewed-by: Steven Rostedt (Google) Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman commit d2beb819045e4e6c1224fd10d343c1a0352a136f Author: Hari Bathini Date: Tue Mar 3 23:40:26 2026 +0530 powerpc64/bpf: fix the address returned by bpf_get_func_ip commit 157820264ac3dadfafffad63184b883eb28f9ae0 upstream. bpf_get_func_ip() helper function returns the address of the traced function. It relies on the IP address stored at ctx - 16 by the bpf trampoline. On 64-bit powerpc, this address is recovered from LR accounting for OOL trampoline. But the address stored here was off by 4-bytes. Ensure the address is the actual start of the traced function. Reported-by: Abhishek Dubey Fixes: d243b62b7bd3 ("powerpc64/bpf: Add support for bpf trampolines") Cc: stable@vger.kernel.org Tested-by: Venkat Rao Bagalkote Signed-off-by: Hari Bathini Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260303181031.390073-3-hbathini@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 2ce9b27946125dc625e25e41aba04bbafe22992c Author: Hari Bathini Date: Tue Mar 3 23:40:30 2026 +0530 powerpc64/bpf: fix kfunc call support commit 01b6ac72729610ae732ca2a66e3a642e23f6cd60 upstream. Commit 61688a82e047 ("powerpc/bpf: enable kfunc call") inadvertently enabled kfunc call support for 32-bit powerpc but that support will not be possible until ABI mismatch between 32-bit powerpc and eBPF is handled in 32-bit powerpc JIT code. Till then, advertise support only for 64-bit powerpc. Also, in powerpc ABI, caller needs to extend the arguments properly based on signedness. The JIT code is responsible for handling this explicitly for kfunc calls as verifier can't handle this for each architecture-specific ABI needs. But this was not taken care of while kfunc call support was enabled for powerpc. Fix it by handling this with bpf_jit_find_kfunc_model() and using zero_extend() & sign_extend() helper functions. Fixes: 61688a82e047 ("powerpc/bpf: enable kfunc call") Cc: stable@vger.kernel.org Signed-off-by: Hari Bathini Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260303181031.390073-7-hbathini@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 4b89984f72742ae9dfa1376c1e6c9b687c94c3a7 Author: Nam Cao Date: Mon Mar 2 01:39:48 2026 +0100 powerpc/pseries: Correct MSI allocation tracking commit 35e4f2a17eb40288f9bcdb09549fa04a63a96279 upstream. The per-device MSI allocation calculation in pseries_irq_domain_alloc() is clearly wrong. It can still happen to work when nr_irqs is 1. Correct it. Fixes: c0215e2d72de ("powerpc/pseries: Fix MSI-X allocation failure when quota is exceeded") Cc: stable@vger.kernel.org Signed-off-by: Nam Cao Reviewed-by: Mahesh Salgaonkar Reviewed-by: Nilay Shroff [maddy: Fixed Nilay's reviewed-by tag] Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260302003948.1452016-1-namcao@linutronix.de Signed-off-by: Greg Kroah-Hartman commit f7eda676386c575b8b9383f6719c62488b2e8ae4 Author: Stefan Haberland Date: Tue Mar 10 15:23:30 2026 +0100 s390/dasd: Copy detected format information to secondary device commit 4c527c7e030672efd788d0806d7a68972a7ba3c1 upstream. During online processing for a DASD device an IO operation is started to determine the format of the device. CDL format contains specifically sized blocks at the beginning of the disk. For a PPRC secondary device no real IO operation is possible therefore this IO request can not be started and this step is skipped for online processing of secondary devices. This is generally fine since the secondary is a copy of the primary device. In case of an additional partition detection that is run after a swap operation the format information is needed to properly drive partition detection IO. Currently the information is not passed leading to IO errors during partition detection and a wrongly detected partition table which in turn might lead to data corruption on the disk with the wrong partition table. Fix by passing the format information from primary to secondary device. Fixes: 413862caad6f ("s390/dasd: add copy pair swap capability") Cc: stable@vger.kernel.org #6.1 Reviewed-by: Jan Hoeppner Acked-by: Eduard Shishkin Signed-off-by: Stefan Haberland Link: https://patch.msgid.link/20260310142330.4080106-3-sth@linux.ibm.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit fe9cd8c8ee3593a7286a479511123c0301a5e5cc Author: Stefan Haberland Date: Tue Mar 10 15:23:29 2026 +0100 s390/dasd: Move quiesce state with pprc swap commit 40e9cd4ae8ec43b107ed2bff422a8fa39dcf4e4b upstream. Quiesce and resume is a mechanism to suspend operations on DASD devices. In the context of a controlled copy pair swap operation, the quiesce operation is usually issued before the actual swap and a resume afterwards. During the swap operation, the underlying device is exchanged. Therefore, the quiesce flag must be moved to the secondary device to ensure a consistent quiesce state after the swap. The secondary device itself cannot be suspended separately because there is no separate block device representation for it. Fixes: 413862caad6f ("s390/dasd: add copy pair swap capability") Cc: stable@vger.kernel.org #6.1 Reviewed-by: Jan Hoeppner Signed-off-by: Stefan Haberland Link: https://patch.msgid.link/20260310142330.4080106-2-sth@linux.ibm.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 950a76e82e05afe0e42cdc202645da77ed56b1cb Author: Harald Freudenberger Date: Fri Feb 27 14:30:51 2026 +0100 s390/zcrypt: Enable AUTOSEL_DOM for CCA serialnr sysfs attribute commit 598bbefa8032cc58b564a81d1ad68bd815c8dc0f upstream. The serialnr sysfs attribute for CCA cards when queried always used the default domain for sending the request down to the card. If for any reason exactly this default domain is disabled then the attribute code fails to retrieve the CCA info and the sysfs entry shows an empty string. Works as designed but the serial number is a card attribute and thus it does not matter which domain is used for the query. So if there are other domains on this card available, these could be used. So extend the code to use AUTOSEL_DOM for the domain value to address any online domain within the card for querying the cca info and thus show the serialnr as long as there is one domain usable regardless of the default domain setting. Fixes: 8f291ebf3270 ("s390/zcrypt: enable card/domain autoselect on ep11 cprbs") Suggested-by: Ingo Franzki Signed-off-by: Harald Freudenberger Reviewed-by: Ingo Franzki Cc: stable@vger.kernel.org Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 997967adf10ce26c3e7bd89598b3ded62b943052 Author: Tejun Heo Date: Sat Mar 7 04:53:32 2026 -1000 sched_ext: Fix enqueue_task_scx() truncation of upper enqueue flags commit 57ccf5ccdc56954f2a91a7f66684fd31c566bde5 upstream. enqueue_task_scx() takes int enq_flags from the sched_class interface. SCX enqueue flags starting at bit 32 (SCX_ENQ_PREEMPT and above) are silently truncated when passed through activate_task(). extra_enq_flags was added as a workaround - storing high bits in rq->scx.extra_enq_flags and OR-ing them back in enqueue_task_scx(). However, the OR target is still the int parameter, so the high bits are lost anyway. The current impact is limited as the only affected flag is SCX_ENQ_PREEMPT which is informational to the BPF scheduler - its loss means the scheduler doesn't know about preemption but doesn't cause incorrect behavior. Fix by renaming the int parameter to core_enq_flags and introducing a u64 enq_flags local that merges both sources. All downstream functions already take u64 enq_flags. Fixes: f0e1a0643a59 ("sched_ext: Implement BPF extensible scheduler class") Cc: stable@vger.kernel.org # v6.12+ Acked-by: Andrea Righi Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit a35be7a17c7b134dc21e0f4bb9d945bcccdbf317 Author: Long Li Date: Thu Mar 5 16:49:22 2026 +0800 xfs: ensure dquot item is deleted from AIL only after log shutdown commit 186ac39b8a7d3ec7ce9c5dd45e5c2730177f375c upstream. In xfs_qm_dqflush(), when a dquot flush fails due to corruption (the out_abort error path), the original code removed the dquot log item from the AIL before calling xfs_force_shutdown(). This ordering introduces a subtle race condition that can lead to data loss after a crash. The AIL tracks the oldest dirty metadata in the journal. The position of the tail item in the AIL determines the log tail LSN, which is the oldest LSN that must be preserved for crash recovery. When an item is removed from the AIL, the log tail can advance past the LSN of that item. The race window is as follows: if the dquot item happens to be at the tail of the log, removing it from the AIL allows the log tail to advance. If a concurrent log write is sampling the tail LSN at the same time and subsequently writes a complete checkpoint (i.e., one containing a commit record) to disk before the shutdown takes effect, the journal will no longer protect the dquot's last modification. On the next mount, log recovery will not replay the dquot changes, even though they were never written back to disk, resulting in silent data loss. Fix this by calling xfs_force_shutdown() before xfs_trans_ail_delete() in the out_abort path. Once the log is shut down, no new log writes can complete with an updated tail LSN, making it safe to remove the dquot item from the AIL. Cc: stable@vger.kernel.org Fixes: b707fffda6a3 ("xfs: abort consistently on dquot flush failure") Signed-off-by: Long Li Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 446a1f5bb64ba38adb93cb043ff0f7b85e8937ca Author: Darrick J. Wong Date: Wed Mar 4 20:26:20 2026 -0800 xfs: fix undersized l_iclog_roundoff values commit 52a8a1ba883defbfe3200baa22cf4cd21985d51a upstream. If the superblock doesn't list a log stripe unit, we set the incore log roundoff value to 512. This leads to corrupt logs and unmountable filesystems in generic/617 on a disk with 4k physical sectors... XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c XFS (sda1): Torn write (CRC failure) detected at log block 0x318e. Truncating head block from 0x3197. XFS (sda1): failed to locate log tail XFS (sda1): log mount/recovery failed: error -74 XFS (sda1): log mount failed XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c XFS (sda1): Ending clean mount ...on the current xfsprogs for-next which has a broken mkfs. xfs_info shows this... meta-data=/dev/sda1 isize=512 agcount=4, agsize=644992 blks = sectsz=4096 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=1 = reflink=1 bigtime=1 inobtcount=1 nrext64=1 = exchange=1 metadir=1 data = bsize=4096 blocks=2579968, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=1 log =internal log bsize=4096 blocks=16384, version=2 = sectsz=4096 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 = rgcount=0 rgsize=268435456 extents = zoned=0 start=0 reserved=0 ...observe that the log section has sectsz=4096 sunit=0, which means that the roundoff factor is 512, not 4096 as you'd expect. We should fix mkfs not to generate broken filesystems, but anyone can fuzz the ondisk superblock so we should be more cautious. I think the inadequate logic predates commit a6a65fef5ef8d0, but that's clearly going to require a different backport. Cc: stable@vger.kernel.org # v5.14 Fixes: a6a65fef5ef8d0 ("xfs: log stripe roundoff is a property of the log") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit ca504d2601b3b112fe09ccaddfcaf84d2916d81c Author: Carlos Maiolino Date: Wed Mar 4 19:54:27 2026 +0100 xfs: fix returned valued from xfs_defer_can_append commit 54fcd2f95f8d216183965a370ec69e1aab14f5da upstream. xfs_defer_can_append returns a bool, it shouldn't be returning a NULL. Found by code inspection. Fixes: 4dffb2cbb483 ("xfs: allow pausing of pending deferred work items") Cc: # v6.8 Signed-off-by: Carlos Maiolino Reviewed-by: Darrick J. Wong Acked-by: Souptick Joarder Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 2b4492d9ed0f2c4e71c0e70d9bffcb1aeab04a6e Author: Long Li Date: Tue Mar 10 20:32:33 2026 +0800 xfs: fix integer overflow in bmap intent sort comparator commit 362c490980867930a098b99f421268fbd7ca05fd upstream. xfs_bmap_update_diff_items() sorts bmap intents by inode number using a subtraction of two xfs_ino_t (uint64_t) values, with the result truncated to int. This is incorrect when two inode numbers differ by more than INT_MAX (2^31 - 1), which is entirely possible on large XFS filesystems. Fix this by replacing the subtraction with cmp_int(). Cc: # v4.9 Fixes: 9f3afb57d5f1 ("xfs: implement deferred bmbt map/unmap operations") Signed-off-by: Long Li Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 316cc7b63fd580f1a215e3f96769cdb70e577ea2 Author: Shyam Prasad N Date: Wed Mar 11 10:48:54 2026 +0530 cifs: make default value of retrans as zero commit e3beefd3af09f8e460ddaf39063d3d7664d7ab59 upstream. When retrans mount option was introduced, the default value was set as 1. However, in the light of some bugs that this has exposed recently we should change it to 0 and retain the old behaviour before this option was introduced. Cc: Reviewed-by: Bharath SM Signed-off-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 50ad880db3013c6fee0ef13781762a39e2e7ef83 Author: Jens Axboe Date: Thu Mar 12 08:59:25 2026 -0600 io_uring/kbuf: check if target buffer list is still legacy on recycle commit c2c185be5c85d37215397c8e8781abf0a69bec1f upstream. There's a gap between when the buffer was grabbed and when it potentially gets recycled, where if the list is empty, someone could've upgraded it to a ring provided type. This can happen if the request is forced via io-wq. The legacy recycling is missing checking if the buffer_list still exists, and if it's of the correct type. Add those checks. Cc: stable@vger.kernel.org Fixes: c7fb19428d67 ("io_uring: add support for ring mapped supplied buffers") Reported-by: Keenan Dong Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 950bda065b05e6001f71c0a698a638095bedf702 Author: Laurent Vivier Date: Wed Mar 4 14:43:38 2026 +0100 qmi_wwan: allow max_mtu above hard_mtu to control rx_urb_size commit 55f854dd5bdd8e19b936a00ef1f8d776ac32c7b0 upstream. Commit c7159e960f14 ("usbnet: limit max_mtu based on device's hard_mtu") capped net->max_mtu to the device's hard_mtu in usbnet_probe(). While this correctly prevents oversized packets on standard USB network devices, it breaks the qmi_wwan driver. qmi_wwan relies on userspace (e.g. ModemManager) setting a large MTU on the wwan0 interface to configure rx_urb_size via usbnet_change_mtu(). QMI modems negotiate USB transfer sizes of 16,383 or 32,767 bytes, and the USB receive buffers must be sized accordingly. With max_mtu capped to hard_mtu (~1500 bytes), userspace can no longer raise the MTU, the receive buffers remain small, and download speeds drop from >300 Mbps to ~0.8 Mbps. Introduce a FLAG_NOMAXMTU driver flag that allows individual usbnet drivers to opt out of the max_mtu cap. Set this flag in qmi_wwan's driver_info structures to restore the previous behavior for QMI devices, while keeping the safety fix in place for all other usbnet drivers. Fixes: c7159e960f14 ("usbnet: limit max_mtu based on device's hard_mtu") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/lkml/CAPh3n803k8JcBPV5qEzUB-oKzWkAs-D5CU7z=Vd_nLRCr5ZqQg@mail.gmail.com/ Reported-by: Koen Vandeputte Tested-by: Daniele Palmas Signed-off-by: Laurent Vivier Link: https://patch.msgid.link/20260304134338.1785002-1-lvivier@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8738dcc844fff7d0157ee775230e95df3b1884d7 Author: Paul Moses Date: Mon Mar 9 17:35:10 2026 +0000 net-shapers: don't free reply skb after genlmsg_reply() commit 57885276cc16a2e2b76282c808a4e84cbecb3aae upstream. genlmsg_reply() hands the reply skb to netlink, and netlink_unicast() consumes it on all return paths, whether the skb is queued successfully or freed on an error path. net_shaper_nl_get_doit() and net_shaper_nl_cap_get_doit() currently jump to free_msg after genlmsg_reply() fails and call nlmsg_free(msg), which can hit the same skb twice. Return the genlmsg_reply() error directly and keep free_msg only for pre-reply failures. Fixes: 4b623f9f0f59 ("net-shapers: implement NL get operation") Fixes: 553ea9f1efd6 ("net: shaper: implement introspection support") Cc: stable@vger.kernel.org Signed-off-by: Paul Moses Link: https://patch.msgid.link/20260309173450.538026-2-p@1g4.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit eb613e3d38abb1a845f19c008448190ecae47dbc Author: Calvin Owens Date: Fri Mar 6 19:19:25 2026 -0800 tracing: Fix trace_buf_size= cmdline parameter with sizes >= 2G commit d008ba8be8984760e36d7dcd4adbd5a41a645708 upstream. Some of the sizing logic through tracer_alloc_buffers() uses int internally, causing unexpected behavior if the user passes a value that does not fit in an int (on my x86 machine, the result is uselessly tiny buffers). Fix by plumbing the parameter's real type (unsigned long) through to the ring buffer allocation functions, which already use unsigned long. It has always been possible to create larger ring buffers via the sysfs interface: this only affects the cmdline parameter. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Link: https://patch.msgid.link/bff42a4288aada08bdf74da3f5b67a2c28b761f8.1772852067.git.calvin@wbinvd.org Fixes: 73c5162aa362 ("tracing: keep ring buffer to minimum size till used") Signed-off-by: Calvin Owens Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 18bef795332b0d5b5256d780a4d576a34c0217e0 Author: Andrei-Alexandru Tachici Date: Mon Mar 2 11:27:34 2026 +0100 tracing: Fix enabling multiple events on the kernel command line and bootconfig commit 3b1679e086bb869ca02722f6bd29b3573a6a0e7e upstream. Multiple events can be enabled on the kernel command line via a comma separator. But if the are specified one at a time, then only the last event is enabled. This is because the event names are saved in a temporary buffer, and each call by the init cmdline code will reset that buffer. This also affects names in the boot config file, as it may call the callback multiple times with an example of: kernel.trace_event = ":mod:rproc_qcom_common", ":mod:qrtr", ":mod:qcom_aoss" Change the cmdline callback function to append a comma and the next value if the temporary buffer already has content. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Link: https://patch.msgid.link/20260302-trace-events-allow-multiple-modules-v1-1-ce4436e37fb8@oss.qualcomm.com Signed-off-by: Andrei-Alexandru Tachici Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 9ecea60f132dac7138fc141cb7796e87d8ea5870 Author: Abhinav Kumar Date: Thu Mar 5 18:17:07 2026 +0800 drm/msm/dpu: Correct the SA8775P intr_underrun/intr_underrun index commit 4ce71cea574658f5c5c7412b1a3cc54efe4f9b50 upstream. The intr_underrun and intr_vsync indices have been swapped, just simply corrects them. Cc: stable@vger.kernel.org Fixes: b139c80d181c ("drm/msm/dpu: Add SA8775P support") Signed-off-by: Abhinav Kumar Signed-off-by: Yongxing Mou Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/709209/ Link: https://lore.kernel.org/r/20260305-mdss_catalog-v5-2-06678ac39ac7@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Greg Kroah-Hartman commit 38f1640db7f8bf57b9e09c5b0b8b205a598f1b3e Author: Mario Limonciello Date: Thu Mar 5 09:06:11 2026 -0600 drm/amd: Fix a few more NULL pointer dereference in device cleanup commit 72ecb1dae72775fa9fea0159d8445d620a0a2295 upstream. I found a few more paths that cleanup fails due to a NULL version pointer on unsupported hardware. Add NULL checks as applicable. Fixes: 39fc2bc4da00 ("drm/amdgpu: Protect GPU register accesses in powergated state in some paths") Reviewed-by: Alex Deucher Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit f5a05f8414fc10f307eb965f303580c7778f8dd2) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit a751a1230533f550f1b6c056e04c646b394e41ff Author: Thomas Fourier Date: Thu Feb 26 10:57:11 2026 +0100 drm/msm: Fix dma_free_attrs() buffer size commit e4eb6e4dd6348dd00e19c2275e3fbaed304ca3bd upstream. The gpummu->table buffer is alloc'd with size TABLE_SIZE + 32 in a2xx_gpummu_new() but freed with size TABLE_SIZE in a2xx_gpummu_destroy(). Change the free size to match the allocation. Fixes: c2052a4e5c99 ("drm/msm: implement a2xx mmu") Cc: Signed-off-by: Thomas Fourier Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/707340/ Message-ID: <20260226095714.12126-2-fourier.thomas@gmail.com> Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit 0189bf176dbe6e07cde08a6121108eda3bd18b06 Author: Jouni Högander Date: Wed Mar 4 13:30:08 2026 +0200 drm/i915/psr: Repeat Selective Update area alignment commit 1be2fca84f520105413d0d89ed04bb0ff742ab16 upstream. Currently we are aligning Selective Update area to cover cursor fully if needed only once. It may happen that cursor is in Selective Update area after pipe alignment and after that covering cursor plane only partially. Fix this by looping alignment as long as alignment isn't needed anymore. v2: - do not unecessarily loop if cursor was already fully covered - rename aligned as su_area_changed Fixes: 1bff93b8bc27 ("drm/i915/psr: Extend SU area to cover cursor fully if needed") Cc: # v6.9+ Signed-off-by: Jouni Högander Reviewed-by: Ankit Nautiyal Link: https://patch.msgid.link/20260304113011.626542-2-jouni.hogander@intel.com (cherry picked from commit 681e12440d8b110350a5709101169f319e10ccbb) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit eae4bf4107571283031db96ce132e951615e2ae4 Author: Janusz Krzysztofik Date: Tue Feb 24 10:49:06 2026 +0100 drm/i915: Fix potential overflow of shmem scatterlist length commit 029ae067431ab9d0fca479bdabe780fa436706ea upstream. When a scatterlists table of a GEM shmem object of size 4 GB or more is populated with pages allocated from a folio, unsigned int .length attribute of a scatterlist may get overflowed if total byte length of pages allocated to that single scatterlist happens to reach or cross the 4GB limit. As a consequence, users of the object may suffer from hitting unexpected, premature end of the object's backing pages. [278.780187] ------------[ cut here ]------------ [278.780377] WARNING: CPU: 1 PID: 2326 at drivers/gpu/drm/i915/i915_mm.c:55 remap_sg+0x199/0x1d0 [i915] ... [278.780654] CPU: 1 UID: 0 PID: 2326 Comm: gem_mmap_offset Tainted: G S U 6.17.0-rc1-CI_DRM_16981-ged823aaa0607+ #1 PREEMPT(voluntary) [278.780656] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [278.780658] Hardware name: Intel Corporation Meteor Lake Client Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918 01/31/2024 [278.780659] RIP: 0010:remap_sg+0x199/0x1d0 [i915] ... [278.780786] Call Trace: [278.780787] [278.780788] ? __apply_to_page_range+0x3e6/0x910 [278.780795] ? __pfx_remap_sg+0x10/0x10 [i915] [278.780906] apply_to_page_range+0x14/0x30 [278.780908] remap_io_sg+0x14d/0x260 [i915] [278.781013] vm_fault_cpu+0xd2/0x330 [i915] [278.781137] __do_fault+0x3a/0x1b0 [278.781140] do_fault+0x322/0x640 [278.781143] __handle_mm_fault+0x938/0xfd0 [278.781150] handle_mm_fault+0x12c/0x300 [278.781152] ? lock_mm_and_find_vma+0x4b/0x760 [278.781155] do_user_addr_fault+0x2d6/0x8e0 [278.781160] exc_page_fault+0x96/0x2c0 [278.781165] asm_exc_page_fault+0x27/0x30 ... That issue was apprehended by the author of a change that introduced it, and potential risk even annotated with a comment, but then never addressed. When adding folio pages to a scatterlist table, take care of byte length of any single scatterlist not exceeding max_segment. Fixes: 0b62af28f249b ("i915: convert shmem_sg_free_table() to use a folio_batch") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14809 Cc: Matthew Wilcox (Oracle) Cc: Andrew Morton Cc: stable@vger.kernel.org # v6.5+ Signed-off-by: Janusz Krzysztofik Reviewed-by: Andi Shyti Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260224094944.2447913-2-janusz.krzysztofik@linux.intel.com (cherry picked from commit 06249b4e691a75694c014a61708c007fb5755f60) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit 46275c56e747578db46d4c545d564dbb94d51497 Author: Luca Ceresoli Date: Thu Feb 26 17:16:45 2026 +0100 drm/bridge: ti-sn65dsi83: halve horizontal syncs for dual LVDS output commit d0d727746944096a6681dc6adb5f123fc5aa018d upstream. Dual LVDS output (available on the SN65DSI84) requires HSYNC_PULSE_WIDTH and HORIZONTAL_BACK_PORCH to be divided by two with respect to the values used for single LVDS output. While not clearly stated in the datasheet, this is needed according to the DSI Tuner [0] output. It also makes sense intuitively because in dual LVDS output two pixels at a time are output and so the output clock is half of the pixel clock. Some dual-LVDS panels refuse to show any picture without this fix. Divide by two HORIZONTAL_FRONT_PORCH too, even though this register is used only for test pattern generation which is not currently implemented by this driver. [0] https://www.ti.com/tool/DSI-TUNER Fixes: ceb515ba29ba ("drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver") Cc: stable@vger.kernel.org Reviewed-by: Marek Vasut Link: https://patch.msgid.link/20260226-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v1-2-2e15f5a9a6a0@bootlin.com Signed-off-by: Luca Ceresoli Signed-off-by: Greg Kroah-Hartman commit 818ebb298a753c5b789237372f30728d7940b617 Author: Luca Ceresoli Date: Thu Feb 26 17:16:44 2026 +0100 drm/bridge: ti-sn65dsi83: fix CHA_DSI_CLK_RANGE rounding commit 2f22702dc0fee06a240404e0f7ead5b789b253d8 upstream. The DSI frequency must be in the range: (CHA_DSI_CLK_RANGE * 5 MHz) <= DSI freq < ((CHA_DSI_CLK_RANGE + 1) * 5 MHz) So the register value should point to the lower range value, but DIV_ROUND_UP() rounds the division to the higher range value, resulting in an excess of 1 (unless the frequency is an exact multiple of 5 MHz). For example for a 437100000 MHz clock CHA_DSI_CLK_RANGE should be 87 (0x57): (87 * 5 = 435) <= 437.1 < (88 * 5 = 440) but current code returns 88 (0x58). Fix the computation by removing the DIV_ROUND_UP(). Fixes: ceb515ba29ba ("drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver") Cc: stable@vger.kernel.org Reviewed-by: Marek Vasut Link: https://patch.msgid.link/20260226-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v1-1-2e15f5a9a6a0@bootlin.com Signed-off-by: Luca Ceresoli Signed-off-by: Greg Kroah-Hartman commit 43025c941aced9a9009f9ff20eea4eb78c61deb8 Author: Mario Limonciello Date: Wed Mar 4 14:07:40 2026 -0600 drm/amd: Fix NULL pointer dereference in device cleanup commit 062ea905fff7756b2e87143ffccaece5cdb44267 upstream. When GPU initialization fails due to an unsupported HW block IP blocks may have a NULL version pointer. During cleanup in amdgpu_device_fini_hw, the code calls amdgpu_device_set_pg_state and amdgpu_device_set_cg_state which iterate over all IP blocks and access adev->ip_blocks[i].version without NULL checks, leading to a kernel NULL pointer dereference. Add NULL checks for adev->ip_blocks[i].version in both amdgpu_device_set_cg_state and amdgpu_device_set_pg_state to prevent dereferencing NULL pointers during GPU teardown when initialization has failed. Fixes: 39fc2bc4da00 ("drm/amdgpu: Protect GPU register accesses in powergated state in some paths") Reviewed-by: Alex Deucher Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit b7ac77468cda92eecae560b05f62f997a12fe2f2) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 57579312e0e87dffa2aeca9acd4ba2ec25da999d Author: Mario Limonciello Date: Tue Mar 10 11:58:22 2026 -0500 drm/amd: Set num IP blocks to 0 if discovery fails commit 3646ff28780b4c52c5b5081443199e7a430110e5 upstream. If discovery has failed for any reason (such as no support for a block) then there is no need to unwind all the IP blocks in fini. In this condition there can actually be failures during the unwind too. Reset num_ip_blocks to zero during failure path and skip the unnecessary cleanup path. Suggested-by: Lijo Lazar Reviewed-by: Lijo Lazar Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit fae5984296b981c8cc3acca35b701c1f332a6cd8) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 7885eb335d8f9e9942925d57e300a85e3f82ded4 Author: Alysa Liu Date: Thu Feb 5 11:21:45 2026 -0500 drm/amdgpu: Fix use-after-free race in VM acquire commit 2c1030f2e84885cc58bffef6af67d5b9d2e7098f upstream. Replace non-atomic vm->process_info assignment with cmpxchg() to prevent race when parent/child processes sharing a drm_file both try to acquire the same VM after fork(). Reviewed-by: Harish Kasiviswanathan Signed-off-by: Alysa Liu Signed-off-by: Alex Deucher (cherry picked from commit c7c573275ec20db05be769288a3e3bb2250ec618) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 33c3a4db31719d414f0622659ca086b708270c9f Author: Yang Wang Date: Wed Feb 25 22:51:06 2026 -0500 drm/amd/pm: remove invalid gpu_metrics.energy_accumulator on smu v13.0.x commit 68785c5e79e0fc1eacf63026fbba32be3867f410 upstream. v1: The metrics->EnergyAccumulator field has been deprecated on newer pmfw. v2: add smu 13.0.0/13.0.7/13.0.10 support. Signed-off-by: Yang Wang Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 8de9edb35976fa56565dc8fbb5d1310e8e10187c) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 6c58a9fdb0d0e1011aa02455d26d6ebea251979b Author: Bastien Curutchet (Schneider Electric) Date: Mon Mar 9 14:15:43 2026 +0100 net: dsa: microchip: Fix error path in PTP IRQ setup commit 99c8c16a4aad0b37293cae213e15957c573cf79b upstream. If request_threaded_irq() fails during the PTP message IRQ setup, the newly created IRQ mapping is never disposed. Indeed, the ksz_ptp_irq_setup()'s error path only frees the mappings that were successfully set up. Dispose the newly created mapping if the associated request_threaded_irq() fails at setup. Cc: stable@vger.kernel.org Fixes: d0b8fec8ae505 ("net: dsa: microchip: Fix symetry in ksz_ptp_msg_irq_{setup/free}()") Signed-off-by: Bastien Curutchet (Schneider Electric) Reviewed-by: Simon Horman Reviewed-by: Vladimir Oltean Link: https://patch.msgid.link/20260309-ksz-ptp-irq-fix-v1-1-757b3b985955@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8efd5dcd31e22a9308b16b107a052fcd568c0a99 Author: Fan Wu Date: Mon Mar 9 13:24:09 2026 +0000 net: ethernet: arc: emac: quiesce interrupts before requesting IRQ commit 2503d08f8a2de618e5c3a8183b250ff4a2e2d52c upstream. Normal RX/TX interrupts are enabled later, in arc_emac_open(), so probe should not see interrupt delivery in the usual case. However, hardware may still present stale or latched interrupt status left by firmware or the bootloader. If probe later unwinds after devm_request_irq() has installed the handler, such a stale interrupt can still reach arc_emac_intr() during teardown and race with release of the associated net_device. Avoid that window by putting the device into a known quiescent state before requesting the IRQ: disable all EMAC interrupt sources and clear any pending EMAC interrupt status bits. This keeps the change hardware-focused and minimal, while preventing spurious IRQ delivery from leftover state. Fixes: e4f2379db6c6 ("ethernet/arc/arc_emac - Add new driver") Cc: stable@vger.kernel.org Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260309132409.584966-1-fanwu01@zju.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b70c4e5e711931cdd56e6e905737b72f1e649189 Author: Jian Zhang Date: Thu Mar 5 14:06:55 2026 +0800 net: ncsi: fix skb leak in error paths commit 5c3398a54266541610c8d0a7082e654e9ff3e259 upstream. Early return paths in NCSI RX and AEN handlers fail to release the received skb, resulting in a memory leak. Specifically, ncsi_aen_handler() returns on invalid AEN packets without consuming the skb. Similarly, ncsi_rcv_rsp() exits early when failing to resolve the NCSI device, response handler, or request, leaving the skb unfreed. CC: stable@vger.kernel.org Fixes: 7a82ecf4cfb8 ("net/ncsi: NCSI AEN packet handler") Fixes: 138635cc27c9 ("net/ncsi: NCSI response packet handler") Signed-off-by: Jian Zhang Link: https://patch.msgid.link/20260305060656.3357250-1-zhangjian.3032@bytedance.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ab5ebab9664214ba41a7633cb4e72f128204f924 Author: Mehul Rao Date: Fri Mar 6 18:38:20 2026 -0500 net: nexthop: fix percpu use-after-free in remove_nh_grp_entry commit b2662e7593e94ae09b1cf7ee5f09160a3612bcb2 upstream. When removing a nexthop from a group, remove_nh_grp_entry() publishes the new group via rcu_assign_pointer() then immediately frees the removed entry's percpu stats with free_percpu(). However, the synchronize_net() grace period in the caller remove_nexthop_from_groups() runs after the free. RCU readers that entered before the publish still see the old group and can dereference the freed stats via nh_grp_entry_stats_inc() -> get_cpu_ptr(nhge->stats), causing a use-after-free on percpu memory. Fix by deferring the free_percpu() until after synchronize_net() in the caller. Removed entries are chained via nh_list onto a local deferred free list. After the grace period completes and all RCU readers have finished, the percpu stats are safely freed. Fixes: f4676ea74b85 ("net: nexthop: Add nexthop group entry stats") Cc: stable@vger.kernel.org Signed-off-by: Mehul Rao Reviewed-by: Eric Dumazet Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260306233821.196789-1-mehulrao@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3224990fb16a831aabc50b67c74f5d0074ce80dd Author: Johan Hovold Date: Thu Mar 5 11:45:49 2026 +0100 net: mctp: fix device leak on probe failure commit 224a0d284c3caf1951302d1744a714784febed71 upstream. Driver core holds a reference to the USB interface and its parent USB device while the interface is bound to a driver and there is no need to take additional references unless the structures are needed after disconnect. This driver takes a reference to the USB device during probe but does not to release it on probe failures. Drop the redundant device reference to fix the leak, reduce cargo culting, make it easier to spot drivers where an extra reference is needed, and reduce the risk of further memory leaks. Fixes: 0791c0327a6e ("net: mctp: Add MCTP USB transport driver") Cc: stable@vger.kernel.org # 6.15 Signed-off-by: Johan Hovold Acked-by: Jeremy Kerr Link: https://patch.msgid.link/20260305104549.16110-1-johan@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1d6abf145615dbfe267ce3b0a271f95e3780e18e Author: Namjae Jeon Date: Sat Mar 7 11:32:31 2026 +0900 ksmbd: fix use-after-free by using call_rcu() for oplock_info commit 1dfd062caa165ec9d7ee0823087930f3ab8a6294 upstream. ksmbd currently frees oplock_info immediately using kfree(), even though it is accessed under RCU read-side critical sections in places like opinfo_get() and proc_show_files(). Since there is no RCU grace period delay between nullifying the pointer and freeing the memory, a reader can still access oplock_info structure after it has been freed. This can leads to a use-after-free especially in opinfo_get() where atomic_inc_not_zero() is called on already freed memory. Fix this by switching to deferred freeing using call_rcu(). Fixes: 18b4fac5ef17 ("ksmbd: fix use-after-free in smb_break_all_levII_oplock()") Cc: stable@vger.kernel.org Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 8f5b1a7cb009a93c48e9e334a2f59a660f9afc07 Author: Marios Makassikis Date: Tue Mar 3 11:14:32 2026 +0100 smb: server: fix use-after-free in smb2_open() commit 1e689a56173827669a35da7cb2a3c78ed5c53680 upstream. The opinfo pointer obtained via rcu_dereference(fp->f_opinfo) is dereferenced after rcu_read_unlock(), creating a use-after-free window. Cc: stable@vger.kernel.org Signed-off-by: Marios Makassikis Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit dbbd328cf58261ca239756fe1c0d10c9518d3399 Author: Namjae Jeon Date: Mon Mar 2 12:55:02 2026 +0900 ksmbd: fix use-after-free in smb_lazy_parent_lease_break_close() commit eac3361e3d5dd8067b3258c69615888eb45e9f25 upstream. opinfo pointer obtained via rcu_dereference(fp->f_opinfo) is being accessed after rcu_read_unlock() has been called. This creates a race condition where the memory could be freed by a concurrent writer between the unlock and the subsequent pointer dereferences (opinfo->is_lease, etc.), leading to a use-after-free. Fixes: 5fb282ba4fef ("ksmbd: fix possible null-deref in smb_lazy_parent_lease_break_close") Cc: stable@vger.kernel.org Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 146691daf293c5781a75e408043ee8891e60ae4a Author: Hao Li Date: Thu Feb 26 19:51:37 2026 +0800 memcg: fix slab accounting in refill_obj_stock() trylock path commit dccd5ee2625d50239510bcd73ed78559005e00a3 upstream. In the trylock path of refill_obj_stock(), mod_objcg_mlstate() should use the real alloc/free bytes (i.e., nr_acct) for accounting, rather than nr_bytes. The user-visible impact is that the NR_SLAB_RECLAIMABLE_B and NR_SLAB_UNRECLAIMABLE_B stats can end up being incorrect. For example, if a user allocates a 6144-byte object, then before this fix efill_obj_stock() calls mod_objcg_mlstate(..., nr_bytes=2048), even though it should account for 6144 bytes (i.e., nr_acct). When the user later frees the same object with kfree(), refill_obj_stock() calls mod_objcg_mlstate(..., nr_bytes=6144). This ends up adding 6144 to the stats, but it should be applying -6144 (i.e., nr_acct) since the object is being freed. Link: https://lkml.kernel.org/r/20260226115145.62903-1-hao.li@linux.dev Fixes: 200577f69f29 ("memcg: objcg stock trylock without irq disabling") Signed-off-by: Hao Li Acked-by: Shakeel Butt Acked-by: Johannes Weiner Cc: Michal Hocko Cc: Muchun Song Cc: Roman Gushchin Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 159aebd20e0e98acb2fedeceb6a27d97cb6a86a0 Author: Vlastimil Babka Date: Wed Feb 11 10:42:30 2026 +0100 slab: distinguish lock and trylock for sheaf_flush_main() commit 48647d3f9a644d1e81af6558102d43cdb260597b upstream. sheaf_flush_main() can be called from __pcs_replace_full_main() where it's fine if the trylock fails, and pcs_flush_all() where it's not expected to and for some flush callers (when destroying the cache or memory hotremove) it would be actually a problem if it failed and left the main sheaf not flushed. The flush callers can however safely use local_lock() instead of trylock. The trylock failure should not happen in practice on !PREEMPT_RT, but can happen on PREEMPT_RT. The impact is limited in practice because when a trylock fails in the kmem_cache_destroy() path, it means someone is using the cache while destroying it, which is a bug on its own. The memory hotremove path is unlikely to be employed in a production RT config, but it's possible. To fix this, split the function into sheaf_flush_main() (using local_lock()) and sheaf_try_flush_main() (using local_trylock()) where both call __sheaf_flush_main_batch() to flush a single batch of objects. This will also allow lockdep to verify our context assumptions. The problem was raised in an off-list question by Marcelo. Fixes: 2d517aa09bbc ("slab: add opt-in caching layer of percpu sheaves") Cc: stable@vger.kernel.org Reported-by: Marcelo Tosatti Signed-off-by: Vlastimil Babka Reviewed-by: Harry Yoo Reviewed-by: Hao Li Link: https://patch.msgid.link/20260211-b4-sheaf-flush-v1-1-4e7f492f0055@suse.cz Signed-off-by: Vlastimil Babka (SUSE) Signed-off-by: Greg Kroah-Hartman commit 8938a9c60d9aea3cffad3b47adf1149641f4e74e Author: Vasily Gorbik Date: Mon Mar 2 19:03:34 2026 +0100 s390/xor: Fix xor_xc_5() inline assembly commit 5f25805303e201f3afaff0a90f7c7ce257468704 upstream. xor_xc_5() contains a larl 1,2f that is not used by the asm and is not declared as a clobber. This can corrupt a compiler-allocated value in %r1 and lead to miscompilation. Remove the instruction. Fixes: 745600ed6965 ("s390/lib: Use exrl instead of ex in xor functions") Cc: stable@vger.kernel.org Reviewed-by: Juergen Christ Reviewed-by: Heiko Carstens Reviewed-by: Sven Schnelle Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 1a34999922ba6c95df6e3ba5c82624f61323f82b Author: Dillon Varone Date: Wed Feb 18 14:34:28 2026 -0500 drm/amd/display: Fallback to boot snapshot for dispclk commit 30d937f63bd19bbcaafa4b892eb251f8bbbf04ef upstream. [WHY & HOW] If the dentist is unavailable, fallback to reading CLKIP via the boot snapshot to get the current dispclk. Reviewed-by: Nicholas Kazlauskas Signed-off-by: Dillon Varone Signed-off-by: Alex Hung Cc: Mario Limonciello Cc: Alex Deucher Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 2ab77600d1e55a042c02437326d3c7563e853c6c) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b9a944d0a1d3a61abe05579d561810ca34050e3d Author: Heiko Carstens Date: Mon Mar 2 14:34:58 2026 +0100 s390/xor: Fix xor_xc_2() inline assembly constraints commit f775276edc0c505dc0f782773796c189f31a1123 upstream. The inline assembly constraints for xor_xc_2() are incorrect. "bytes", "p1", and "p2" are input operands, while all three of them are modified within the inline assembly. Given that the function consists only of this inline assembly it seems unlikely that this may cause any problems, however fix this in any case. Fixes: 2cfc5f9ce7f5 ("s390/xor: optimized xor routing using the XC instruction") Cc: stable@vger.kernel.org Signed-off-by: Heiko Carstens Reviewed-by: Vasily Gorbik Link: https://lore.kernel.org/r/20260302133500.1560531-2-hca@linux.ibm.com Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 87f0349beaacab2ac60c4a1b6dcff254cef7d5a0 Author: Maximilian Pezzullo Date: Wed Mar 4 08:22:59 2026 +0100 ata: libata-core: Disable LPM on ST1000DM010-2EP102 commit b3b1d3ae1d87bc9398fb715c945968bf4c75a09a upstream. According to a user report, the ST1000DM010-2EP102 has problems with LPM, causing random system freezes. The drive belongs to the same BarraCuda family as the ST2000DM008-2FR102 which has the same issue. Cc: stable@vger.kernel.org Fixes: 7627a0edef54 ("ata: ahci: Drop low power policy board type") Reported-by: Filippo Baiamonte Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221163 Signed-off-by: Maximilian Pezzullo Reviewed-by: Damien Le Moal Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit a547ffcb9b1d58f885ee9078c0da94acdbc464ee Author: Heiko Carstens Date: Mon Mar 2 14:35:00 2026 +0100 s390/stackleak: Fix __stackleak_poison() inline assembly constraint commit 674c5ff0f440a051ebf299d29a4c013133d81a65 upstream. The __stackleak_poison() inline assembly comes with a "count" operand where the "d" constraint is used. "count" is used with the exrl instruction and "d" means that the compiler may allocate any register from 0 to 15. If the compiler would allocate register 0 then the exrl instruction would not or the value of "count" into the executed instruction - resulting in a stackframe which is only partially poisoned. Use the correct "a" constraint, which excludes register 0 from register allocation. Fixes: 2a405f6bb3a5 ("s390/stackleak: provide fast __stackleak_poison() implementation") Cc: stable@vger.kernel.org Signed-off-by: Heiko Carstens Reviewed-by: Vasily Gorbik Link: https://lore.kernel.org/r/20260302133500.1560531-4-hca@linux.ibm.com Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit d0e63feca3808c15a1e8d58df0c98fb60b7da4ed Author: Ashish Kalra Date: Fri Feb 6 21:26:45 2026 +0000 crypto: ccp - allow callers to use HV-Fixed page API when SEV is disabled commit 8168a7b72bdee3790b126f63bd30306759206b15 upstream. When SEV is disabled, the HV-Fixed page allocation call fails, which in turn causes SFS initialization to fail. Fix the HV-Fixed API so callers (for example, SFS) can use it even when SEV is disabled by performing normal page allocation and freeing. Fixes: e09701dcdd9c ("crypto: ccp - Add new HV-Fixed page allocation/free API") Cc: stable@vger.kernel.org Signed-off-by: Ashish Kalra Reviewed-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit a4d0e2c416db0bbc421a0e9767a9c48d6d9d2599 Author: Maíra Canal Date: Thu Feb 12 11:49:44 2026 -0300 pmdomain: bcm: bcm2835-power: Fix broken reset status read commit 550bae2c0931dbb664a61b08c21cf156f0a5362a upstream. bcm2835_reset_status() has a misplaced parenthesis on every PM_READ() call. Since PM_READ(reg) expands to readl(power->base + (reg)), the expression: PM_READ(PM_GRAFX & PM_V3DRSTN) computes the bitwise AND of the register offset PM_GRAFX with the bitmask PM_V3DRSTN before using the result as a register offset, reading from the wrong MMIO address instead of the intended PM_GRAFX register. The same issue affects the PM_IMAGE cases. Fix by moving the closing parenthesis so PM_READ() receives only the register offset, and the bitmask is applied to the value returned by the read. Fixes: 670c672608a1 ("soc: bcm: bcm2835-pm: Add support for power domains under a new binding.") Signed-off-by: Maíra Canal Reviewed-by: Florian Fainelli Reviewed-by: Stefan Wahren Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit f29b08755103faafee7ed8ab2d021087a1f52d14 Author: Franz Schnyder Date: Wed Feb 18 11:25:14 2026 +0100 regulator: pf9453: Respect IRQ trigger settings from firmware commit 2d85ecd6fb0eb2fee0ffa040ec1ddea57b09bc38 upstream. The datasheet specifies, that the IRQ_B pin is pulled low when any unmasked interrupt bit status is changed, and it is released high once the application processor reads the INT1 register. As it specifies a level-low behavior, it should not force a falling-edge interrupt. Remove the IRQF_TRIGGER_FALLING to not force the falling-edge interrupt and instead rely on the flag from the device tree. Fixes: 0959b6706325 ("regulator: pf9453: add PMIC PF9453 support") Cc: stable@vger.kernel.org Signed-off-by: Franz Schnyder Link: https://patch.msgid.link/20260218102518.238943-2-fra.schnyder@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 4387b2cc9a630466098cbd1416ab4f8092a59fae Author: Pavel Begunkov Date: Mon Mar 2 14:32:04 2026 +0000 io_uring/net: reject SEND_VECTORIZED when unsupported commit c36e28becd0586ac98318fd335e5e91d19cd2623 upstream. IORING_SEND_VECTORIZED with registered buffers is not implemented but could be. Don't silently ignore the flag in this case but reject it with an error. It only affects sendzc as normal sends don't support registered buffers. Fixes: 6f02527729bd3 ("io_uring/net: Allow to do vectorized send") Cc: stable@vger.kernel.org Signed-off-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 823fb431e4af8e38146d89a1c79b64a85fe12c37 Author: Helge Deller Date: Tue Mar 3 23:36:11 2026 +0100 parisc: Check kernel mapping earlier at bootup commit 17c144f1104bfc29a3ce3f7d0931a1bfb7a3558c upstream. The check if the initial mapping is sufficient needs to happen much earlier during bootup. Move this test directly to the start_parisc() function and use native PDC iodc functions to print the warning, because panic() and printk() are not functional yet. This fixes boot when enabling various KALLSYSMS options which need much more space. Signed-off-by: Helge Deller Cc: # v6.0+ Signed-off-by: Greg Kroah-Hartman commit 6f92a7a8b48a523f910ef25dd83808710724f59b Author: Piotr Jaroszynski Date: Thu Mar 5 15:26:29 2026 -0800 arm64: contpte: fix set_access_flags() no-op check for SMMU/ATS faults commit 97c5550b763171dbef61e6239cab372b9f9cd4a2 upstream. contpte_ptep_set_access_flags() compared the gathered ptep_get() value against the requested entry to detect no-ops. ptep_get() ORs AF/dirty from all sub-PTEs in the CONT block, so a dirty sibling can make the target appear already-dirty. When the gathered value matches entry, the function returns 0 even though the target sub-PTE still has PTE_RDONLY set in hardware. For a CPU with FEAT_HAFDBS this gathered view is fine, since hardware may set AF/dirty on any sub-PTE and CPU TLB behavior is effectively gathered across the CONT range. But page-table walkers that evaluate each descriptor individually (e.g. a CPU without DBM support, or an SMMU without HTTU, or with HA/HD disabled in CD.TCR) can keep faulting on the unchanged target sub-PTE, causing an infinite fault loop. Gathering can therefore cause false no-ops when only a sibling has been updated: - write faults: target still has PTE_RDONLY (needs PTE_RDONLY cleared) - read faults: target still lacks PTE_AF Fix by checking each sub-PTE against the requested AF/dirty/write state (the same bits consumed by __ptep_set_access_flags()), using raw per-PTE values rather than the gathered ptep_get() view, before returning no-op. Keep using the raw target PTE for the write-bit unfold decision. Per Arm ARM (DDI 0487) D8.7.1 ("The Contiguous bit"), any sub-PTE in a CONT range may become the effective cached translation and software must maintain consistent attributes across the range. Fixes: 4602e5757bcc ("arm64/mm: wire up PTE_CONT for user mappings") Cc: Ryan Roberts Cc: Catalin Marinas Cc: Will Deacon Cc: Jason Gunthorpe Cc: John Hubbard Cc: Zi Yan Cc: Breno Leitao Cc: stable@vger.kernel.org Reviewed-by: Alistair Popple Reviewed-by: James Houghton Reviewed-by: Ryan Roberts Reviewed-by: Catalin Marinas Tested-by: Breno Leitao Signed-off-by: Piotr Jaroszynski Acked-by: Balbir Singh Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 396dec23e902492ad1b7d73b74e2f2a52d2e0776 Author: Helge Deller Date: Wed Mar 4 22:24:18 2026 +0100 parisc: Fix initial page table creation for boot commit 8475d8fe21ec9c7eb2faca555fbc5b68cf0d2597 upstream. The KERNEL_INITIAL_ORDER value defines the initial size (usually 32 or 64 MB) of the page table during bootup. Up until now the whole area was initialized with PTE entries, but there was no check if we filled too many entries. Change the code to fill up with so many entries that the "_end" symbol can be reached by the kernel, but not more entries than actually fit into the initial PTE tables. Signed-off-by: Helge Deller Cc: # v6.0+ Signed-off-by: Greg Kroah-Hartman commit 857473efe9341f1d63eb1df3bf97afbe42e748b5 Author: Pavel Begunkov Date: Wed Mar 4 12:37:43 2026 +0000 io_uring/zcrx: use READ_ONCE with user shared RQEs commit 531bb98a030cc1073bd7ed9a502c0a3a781e92ee upstream. Refill queue entries are shared with the user space, use READ_ONCE when reading them. Fixes: 34a3e60821ab9 ("io_uring/zcrx: implement zerocopy receive pp memory provider"); Cc: stable@vger.kernel.org Signed-off-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 73a7a345816946d276ad2c46c8bb771de67cfc46 Author: Sanman Pradhan Date: Wed Mar 4 15:51:17 2026 -0800 hwmon: (pmbus/q54sj108a2) fix stack overflow in debugfs read commit 25dd70a03b1f5f3aa71e1a5091ecd9cd2a13ee43 upstream. The q54sj108a2_debugfs_read function suffers from a stack buffer overflow due to incorrect arguments passed to bin2hex(). The function currently passes 'data' as the destination and 'data_char' as the source. Because bin2hex() converts each input byte into two hex characters, a 32-byte block read results in 64 bytes of output. Since 'data' is only 34 bytes (I2C_SMBUS_BLOCK_MAX + 2), this writes 30 bytes past the end of the buffer onto the stack. Additionally, the arguments were swapped: it was reading from the zero-initialized 'data_char' and writing to 'data', resulting in all-zero output regardless of the actual I2C read. Fix this by: 1. Expanding 'data_char' to 66 bytes to safely hold the hex output. 2. Correcting the bin2hex() argument order and using the actual read count. 3. Using a pointer to select the correct output buffer for the final simple_read_from_buffer call. Fixes: d014538aa385 ("hwmon: (pmbus) Driver for Delta power supplies Q54SJ108A2") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan Link: https://lore.kernel.org/r/20260304235116.1045-1-sanman.p211993@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 439b5fb7280a37d00bc76eeef4301d77897d6afb Author: Catalin Marinas Date: Fri Feb 27 18:53:06 2026 +0000 arm64: mm: Add PTE_DIRTY back to PAGE_KERNEL* to fix kexec/hibernation commit c25c4aa3f79a488cc270507935a29c07dc6bddfc upstream. Commit 143937ca51cc ("arm64, mm: avoid always making PTE dirty in pte_mkwrite()") changed pte_mkwrite_novma() to only clear PTE_RDONLY when PTE_DIRTY is set. This was to allow writable-clean PTEs for swap pages that haven't actually been written. However, this broke kexec and hibernation for some platforms. Both go through trans_pgd_create_copy() -> _copy_pte(), which calls pte_mkwrite_novma() to make the temporary linear-map copy fully writable. With the updated pte_mkwrite_novma(), read-only kernel pages (without PTE_DIRTY) remain read-only in the temporary mapping. While such behaviour is fine for user pages where hardware DBM or trapping will make them writeable, subsequent in-kernel writes by the kexec relocation code will fault. Add PTE_DIRTY back to all _PAGE_KERNEL* protection definitions. This was the case prior to 5.4, commit aa57157be69f ("arm64: Ensure VM_WRITE|VM_SHARED ptes are clean by default"). With the kernel linear-map PTEs always having PTE_DIRTY set, pte_mkwrite_novma() correctly clears PTE_RDONLY. Fixes: 143937ca51cc ("arm64, mm: avoid always making PTE dirty in pte_mkwrite()") Signed-off-by: Catalin Marinas Cc: stable@vger.kernel.org Reported-by: Jianpeng Chang Link: https://lore.kernel.org/r/20251204062722.3367201-1-jianpeng.chang.cn@windriver.com Cc: Will Deacon Cc: Huang, Ying Cc: Guenter Roeck Reviewed-by: Huang Ying Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit ad8fa5bff53f5d1f8394f996850da8ce070eaee3 Author: Dave Airlie Date: Tue Feb 24 13:17:50 2026 +1000 nouveau/dpcd: return EBUSY for aux xfer if the device is asleep commit 8f3c6f08ababad2e3bdd239728cf66a9949446b4 upstream. If we have runtime suspended, and userspace wants to use /dev/drm_dp_* then just tell it the device is busy instead of crashing in the GSP code. WARNING: CPU: 2 PID: 565741 at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c:164 r535_gsp_msgq_wait+0x9a/0xb0 [nouveau] CPU: 2 UID: 0 PID: 565741 Comm: fwupd Not tainted 6.18.10-200.fc43.x86_64 #1 PREEMPT(lazy) Hardware name: LENOVO 20QTS0PQ00/20QTS0PQ00, BIOS N2OET65W (1.52 ) 08/05/2024 RIP: 0010:r535_gsp_msgq_wait+0x9a/0xb0 [nouveau] This is a simple fix to get backported. We should probably engineer a proper power domain solution to wake up devices and keep them awake while fw updates are happening. Cc: stable@vger.kernel.org Fixes: 8894f4919bc4 ("drm/nouveau: register a drm_dp_aux channel for each dp connector") Reviewed-by: Lyude Paul Signed-off-by: Dave Airlie Link: https://patch.msgid.link/20260224031750.791621-1-airlied@gmail.com Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 6e6e28898e0153b9ac945ab10c08539c03d85673 Author: Helge Deller Date: Tue Mar 3 23:36:10 2026 +0100 parisc: Increase initial mapping to 64 MB with KALLSYMS commit 8e732934fb81282be41602550e7e07baf265e972 upstream. The 32MB initial kernel mapping can become too small when CONFIG_KALLSYMS is used. Increase the mapping to 64 MB in this case. Signed-off-by: Helge Deller Cc: # v6.0+ Signed-off-by: Greg Kroah-Hartman commit 5737b279a28b6c4d1b973dade9935cba4667dff2 Author: Shawn Lin Date: Wed Feb 25 10:55:01 2026 +0800 pmdomain: rockchip: Fix PD_VCODEC for RK3588 commit 0fb59eaca18f1254ecdce34354eec3cb1b3b5e10 upstream. >From the RK3588 TRM Table 7-1 RK3588 Voltage Domain and Power Domain Summary, PD_RKVDEC0/1 and PD_VENC0/1 rely on VD_VCODEC which require extra voltages to be applied, otherwise it breaks RK3588-evb1-v10 board after vdec support landed[1]. The panic looks like below: rockchip-pm-domain fd8d8000.power-management:power-controller: failed to set domain 'rkvdec0' on, val=0 rockchip-pm-domain fd8d8000.power-management:power-controller: failed to set domain 'rkvdec1' on, val=0 ... Hardware name: Rockchip RK3588S EVB1 V10 Board (DT) Workqueue: pm genpd_power_off_work_fn Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x40/0x84 dump_stack+0x18/0x24 vpanic+0x1ec/0x4fc vpanic+0x0/0x4fc check_panic_on_warn+0x0/0x94 arm64_serror_panic+0x6c/0x78 do_serror+0xc4/0xcc el1h_64_error_handler+0x3c/0x5c el1h_64_error+0x6c/0x70 regmap_mmio_read32le+0x18/0x24 (P) regmap_bus_reg_read+0xfc/0x130 regmap_read+0x188/0x1ac regmap_read+0x54/0x78 rockchip_pd_power+0xcc/0x5f0 rockchip_pd_power_off+0x1c/0x4c genpd_power_off+0x84/0x120 genpd_power_off+0x1b4/0x260 genpd_power_off_work_fn+0x38/0x58 process_scheduled_works+0x194/0x2c4 worker_thread+0x2ac/0x3d8 kthread+0x104/0x124 ret_from_fork+0x10/0x20 SMP: stopping secondary CPUs Kernel Offset: disabled CPU features: 0x3000000,000e0005,40230521,0400720b Memory Limit: none ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]--- Chaoyi pointed out the PD_VCODEC is the parent of PD_RKVDEC0/1 and PD_VENC0/1, so checking the PD_VCODEC is enough. [1] https://lore.kernel.org/linux-rockchip/20251020212009.8852-2-detlev.casanova@collabora.com/ Fixes: db6df2e3fc16 ("pmdomain: rockchip: add regulator support") Cc: stable@vger.kernel.org Suggested-by: Chaoyi Chen Signed-off-by: Shawn Lin Reviewed-by: Chaoyi Chen Reviewed-by: Sebastian Reichel Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit e9b0a6ffe8b953166ecaf6e9ea8bf8c44bbea0c5 Author: Matt Roper Date: Fri Feb 27 08:43:41 2026 -0800 drm/xe/xe2_hpg: Correct implementation of Wa_16025250150 commit 89865e6dc8487b627302bdced3f965cd0c406835 upstream. Wa_16025250150 asks us to set five register fields of the register to 0x1 each. However we were just OR'ing this into the existing register value (which has a default of 0x4 for each nibble-sized field) resulting in final field values of 0x5 instead of the desired 0x1. Correct the RTP programming (use FIELD_SET instead of SET) to ensure each field is assigned to exactly the value we want. Cc: Aradhya Bhatia Cc: Tejas Upadhyay Cc: stable@vger.kernel.org # v6.16+ Fixes: 7654d51f1fd8 ("drm/xe/xe2hpg: Add Wa_16025250150") Reviewed-by: Ngai-Mint Kwan Link: https://patch.msgid.link/20260227164341.3600098-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper (cherry picked from commit d139209ef88e48af1f6731cd45440421c757b6b5) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 2ab9f2531d37775cd79228c1f5d80e6bd08d11d3 Author: Sven Eckelmann Date: Mon Feb 16 11:20:29 2026 +0100 batman-adv: Avoid double-rtnl_lock ELP metric worker commit cfc83a3c71517b59c1047db57da31e26a9dc2f33 upstream. batadv_v_elp_get_throughput() might be called when the RTNL lock is already held. This could be problematic when the work queue item is cancelled via cancel_delayed_work_sync() in batadv_v_elp_iface_disable(). In this case, an rtnl_lock() would cause a deadlock. To avoid this, rtnl_trylock() was used in this function to skip the retrieval of the ethtool information in case the RTNL lock was already held. But for cfg80211 interfaces, batadv_get_real_netdev() was called - which also uses rtnl_lock(). The approach for __ethtool_get_link_ksettings() must also be used instead and the lockless version __batadv_get_real_netdev() has to be called. Cc: stable@vger.kernel.org Fixes: 8c8ecc98f5c6 ("batman-adv: Drop unmanaged ELP metric worker") Reported-by: Christian Schmidbauer Signed-off-by: Sven Eckelmann Tested-by: Sören Skaarup Signed-off-by: Simon Wunderlich Signed-off-by: Greg Kroah-Hartman commit a269cbdc442f8658bca35383e34b9d0b0ff95a1c Author: Eric Biggers Date: Mon Mar 2 12:36:00 2026 -0800 net/tcp-ao: Fix MAC comparison to be constant-time commit 67edfec516d30d3e62925c397be4a1e5185802fc upstream. To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this. Fixes: 0a3a809089eb ("net/tcp: Verify inbound TCP-AO signed segments") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Reviewed-by: Dmitry Safonov <0x7f454c46@gmail.com> Link: https://patch.msgid.link/20260302203600.13561-1-ebiggers@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 12db29803c19e345a23c17609cb0292f7e5e8cf8 Author: Huiwen He Date: Tue Feb 24 10:35:44 2026 +0800 tracing: Fix syscall events activation by ensuring refcount hits zero commit 0a663b764dbdf135a126284f454c9f01f95a87d4 upstream. When multiple syscall events are specified in the kernel command line (e.g., trace_event=syscalls:sys_enter_openat,syscalls:sys_enter_close), they are often not captured after boot, even though they appear enabled in the tracing/set_event file. The issue stems from how syscall events are initialized. Syscall tracepoints require the global reference count (sys_tracepoint_refcount) to transition from 0 to 1 to trigger the registration of the syscall work (TIF_SYSCALL_TRACEPOINT) for tasks, including the init process (pid 1). The current implementation of early_enable_events() with disable_first=true used an interleaved sequence of "Disable A -> Enable A -> Disable B -> Enable B". If multiple syscalls are enabled, the refcount never drops to zero, preventing the 0->1 transition that triggers actual registration. Fix this by splitting early_enable_events() into two distinct phases: 1. Disable all events specified in the buffer. 2. Enable all events specified in the buffer. This ensures the refcount hits zero before re-enabling, allowing syscall events to be properly activated during early boot. The code is also refactored to use a helper function to avoid logic duplication between the disable and enable phases. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Link: https://patch.msgid.link/20260224023544.1250787-1-hehuiwen@kylinos.cn Fixes: ce1039bd3a89 ("tracing: Fix enabling of syscall events on the command line") Signed-off-by: Huiwen He Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit f6e7c4f406b681957a36f9e3edbe2956247ef36b Author: Jakub Staniszewski Date: Tue Jan 13 20:38:17 2026 +0100 ice: fix retry for AQ command 0x06EE commit fb4903b3354aed4a2301180cf991226f896c87ed upstream. Executing ethtool -m can fail reporting a netlink I/O error while firmware link management holds the i2c bus used to communicate with the module. According to Intel(R) Ethernet Controller E810 Datasheet Rev 2.8 [1] Section 3.3.10.4 Read/Write SFF EEPROM (0x06EE) request should to be retried upon receiving EBUSY from firmware. Commit e9c9692c8a81 ("ice: Reimplement module reads used by ethtool") implemented it only for part of ice_get_module_eeprom(), leaving all other calls to ice_aq_sff_eeprom() vulnerable to returning early on getting EBUSY without retrying. Remove the retry loop from ice_get_module_eeprom() and add Admin Queue (AQ) command with opcode 0x06EE to the list of commands that should be retried on receiving EBUSY from firmware. Cc: stable@vger.kernel.org Fixes: e9c9692c8a81 ("ice: Reimplement module reads used by ethtool") Signed-off-by: Jakub Staniszewski Co-developed-by: Dawid Osuchowski Signed-off-by: Dawid Osuchowski Reviewed-by: Aleksandr Loktionov Reviewed-by: Przemek Kitszel Link: https://www.intel.com/content/www/us/en/content-details/613875/intel-ethernet-controller-e810-datasheet.html [1] Reviewed-by: Paul Menzel Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit 678d5802556b3c2b3067b5f7d95e77aef94bddd4 Author: Long Li Date: Thu Feb 26 11:28:33 2026 -0800 net: mana: Ring doorbell at 4 CQ wraparounds commit dabffd08545ffa1d7183bc45e387860984025291 upstream. MANA hardware requires at least one doorbell ring every 8 wraparounds of the CQ. The driver rings the doorbell as a form of flow control to inform hardware that CQEs have been consumed. The NAPI poll functions mana_poll_tx_cq() and mana_poll_rx_cq() can poll up to CQE_POLLING_BUFFER (512) completions per call. If the CQ has fewer than 512 entries, a single poll call can process more than 4 wraparounds without ringing the doorbell. The doorbell threshold check also uses ">" instead of ">=", delaying the ring by one extra CQE beyond 4 wraparounds. Combined, these issues can cause the driver to exceed the 8-wraparound hardware limit, leading to missed completions and stalled queues. Fix this by capping the number of CQEs polled per call to 4 wraparounds of the CQ in both TX and RX paths. Also change the doorbell threshold from ">" to ">=" so the doorbell is rung as soon as 4 wraparounds are reached. Cc: stable@vger.kernel.org Fixes: 58a63729c957 ("net: mana: Fix doorbell out of order violation and avoid unnecessary doorbell rings") Signed-off-by: Long Li Reviewed-by: Haiyang Zhang Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260226192833.1050807-1-longli@microsoft.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8bde543d2a5f935ba2a6a6325a2e02f8a9256fbe Author: Ariel Silver Date: Sat Feb 21 15:26:00 2026 +0100 media: dvb-net: fix OOB access in ULE extension header tables commit 24d87712727a5017ad142d63940589a36cd25647 upstream. The ule_mandatory_ext_handlers[] and ule_optional_ext_handlers[] tables in handle_one_ule_extension() are declared with 255 elements (valid indices 0-254), but the index htype is derived from network-controlled data as (ule_sndu_type & 0x00FF), giving a range of 0-255. When htype equals 255, an out-of-bounds read occurs on the function pointer table, and the OOB value may be called as a function pointer. Add a bounds check on htype against the array size before either table is accessed. Out-of-range values now cause the SNDU to be discarded. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Ariel Silver Signed-off-by: Ariel Silver Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 9e16152a7e337475e8f62493080e8b92cce2b5ff Author: Christian Brauner Date: Thu Feb 26 14:50:12 2026 +0100 selftests: fix mntns iteration selftests commit 4c7b2ec23cc5d880e3ffe35e8c2aad686b67723a upstream. Now that we changed permission checking make sure that we reflect that in the selftests. Link: https://patch.msgid.link/20260226-work-visibility-fixes-v1-4-d2c2853313bd@kernel.org Fixes: 9d87b1067382 ("selftests: add tests for mntns iteration") Reviewed-by: Jeff Layton Cc: stable@kernel.org # v6.14+ Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit ace46763b282dd0cb7719470473f5c248f27e3c7 Author: Andy Shevchenko Date: Mon Feb 23 19:06:51 2026 +0100 pinctrl: cy8c95x0: Don't miss reading the last bank registers commit b6c3af46c26f2d07c10a1452adc34b821719327e upstream. When code had been changed to use for_each_set_clump8(), it mistakenly switched from chip->nport to chip->tpin since the cy8c9540 and cy8c9560 have a 4-pin gap. This, in particular, led to the missed read of the last bank interrupt status register and hence missing interrupts on those pins. Restore the upper limit in for_each_set_clump8() to take into consideration that gap. Fixes: 83e29a7a1fdf ("pinctrl: cy8c95x0; Switch to use for_each_set_clump8()") Cc: stable@vger.kernel.org Signed-off-by: Andy Shevchenko Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 4dd2d9cf563c54e09d5f7eacf95c5b8f538b513b Author: Luka Gejak Date: Tue Feb 24 14:26:47 2026 +0100 staging: rtl8723bs: fix potential out-of-bounds read in rtw_restruct_wmm_ie commit a75281626fc8fa6dc6c9cc314ee423e8bc45203b upstream. The current code checks 'i + 5 < in_len' at the end of the if statement. However, it accesses 'in_ie[i + 5]' before that check, which can lead to an out-of-bounds read. Move the length check to the beginning of the conditional to ensure the index is within bounds before accessing the array. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable Signed-off-by: Luka Gejak Reviewed-by: Dan Carpenter Link: https://patch.msgid.link/20260224132647.11642-2-luka.gejak@linux.dev Signed-off-by: Greg Kroah-Hartman commit 6d62fa548387e159a21ea95132c09bfc96d336ed Author: Greg Kroah-Hartman Date: Mon Feb 23 14:31:35 2026 +0100 staging: rtl8723bs: properly validate the data in rtw_get_ie_ex() commit f0109b9d3e1e455429279d602f6276e34689750a upstream. Just like in commit 154828bf9559 ("staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser"), we don't trust the data in the frame so we should check the length better before acting on it Cc: stable Assisted-by: gkh_clanker_2000 Tested-by: Navaneeth K Reviewed-by: Navaneeth K Link: https://patch.msgid.link/2026022336-arrange-footwork-6e54@gregkh Signed-off-by: Greg Kroah-Hartman commit ea535b9894d77edd01b456a3ac944ef8c9842e90 Author: Artem Lytkin Date: Mon Feb 16 20:20:38 2026 +0000 staging: sm750fb: add missing pci_release_region on error and removal commit 8225489ddb900656cc21573b4e1b00c9181fd777 upstream. hw_sm750_map() calls pci_request_region() but never releases the region on error paths or in lynxfb_pci_remove(). This causes a resource leak that prevents the PCI region from being mapped again after driver removal or a failed probe. A TODO comment in the code acknowledges this missing cleanup. Restructure the error handling in hw_sm750_map() to properly release the PCI region on ioremap failures, and add pci_release_region() to lynxfb_pci_remove(). Signed-off-by: Artem Lytkin Cc: stable Link: https://patch.msgid.link/20260216202038.1828-1-iprintercanon@gmail.com Signed-off-by: Greg Kroah-Hartman commit 6b9cb42cfdb36834210693eb9ba99d55fb3cbee9 Author: Harry Yoo Date: Mon Mar 9 16:22:19 2026 +0900 mm/slab: fix an incorrect check in obj_exts_alloc_size() commit 8dafa9f5900c4855a65dbfee51e3bd00636deee1 upstream. obj_exts_alloc_size() prevents recursive allocation of slabobj_ext array from the same cache, to avoid creating slabs that are never freed. There is one mistake that returns the original size when memory allocation profiling is disabled. The assumption was that memcg-triggered slabobj_ext allocation is always served from KMALLOC_CGROUP type. But this is wrong [1]: when the caller specifies both __GFP_RECLAIMABLE and __GFP_ACCOUNT with SLUB_TINY enabled, the allocation is served from normal kmalloc. This is because kmalloc_type() prioritizes __GFP_RECLAIMABLE over __GFP_ACCOUNT, and SLUB_TINY aliases KMALLOC_RECLAIM with KMALLOC_NORMAL. As a result, the recursion guard is bypassed and the problematic slabs can be created. Fix this by removing the mem_alloc_profiling_enabled() check entirely. The remaining is_kmalloc_normal() check is still sufficient to detect whether the cache is of KMALLOC_NORMAL type and avoid bumping the size if it's not. Without SLUB_TINY, no functional change intended. With SLUB_TINY, allocations with __GFP_ACCOUNT|__GFP_RECLAIMABLE now allocate a larger array if the sizes equal. Reported-by: Zw Tang Fixes: 280ea9c3154b ("mm/slab: avoid allocating slabobj_ext array from its own slab") Closes: https://lore.kernel.org/linux-mm/CAPHJ_VKuMKSke8b11AZQw1PTSFN4n2C0gFxC6xGOG0ZLHgPmnA@mail.gmail.com [1] Cc: stable@vger.kernel.org Signed-off-by: Harry Yoo Link: https://patch.msgid.link/20260309072219.22653-1-harry.yoo@oracle.com Tested-by: Zw Tang Signed-off-by: Vlastimil Babka (SUSE) Signed-off-by: Greg Kroah-Hartman commit ce0aa47c963b8c3e5beace89e2b5a665a64b5b6b Author: Raul Pazemecxas De Andrade Date: Mon Feb 23 17:10:59 2026 -0800 mm/damon/core: clear walk_control on inactive context in damos_walk() commit d210fdcac9c0d1380eab448aebc93f602c1cd4e6 upstream. damos_walk() sets ctx->walk_control to the caller-provided control structure before checking whether the context is running. If the context is inactive (damon_is_running() returns false), the function returns -EINVAL without clearing ctx->walk_control. This leaves a dangling pointer to a stack-allocated structure that will be freed when the caller returns. This is structurally identical to the bug fixed in commit f9132fbc2e83 ("mm/damon/core: remove call_control in inactive contexts") for damon_call(), which had the same pattern of linking a control object and returning an error without unlinking it. The dangling walk_control pointer can cause: 1. Use-after-free if the context is later started and kdamond    dereferences ctx->walk_control (e.g., in damos_walk_cancel()    which writes to control->canceled and calls complete()) 2. Permanent -EBUSY from subsequent damos_walk() calls, since the    stale pointer is non-NULL Nonetheless, the real user impact is quite restrictive. The use-after-free is impossible because there is no damos_walk() callers who starts the context later. The permanent -EBUSY can actually confuse users, as DAMON is not running. But the symptom is kept only while the context is turned off. Turning it on again will make DAMON internally uses a newly generated damon_ctx object that doesn't have the invalid damos_walk_control pointer, so everything will work fine again. Fix this by clearing ctx->walk_control under walk_control_lock before returning -EINVAL, mirroring the fix pattern from f9132fbc2e83. Link: https://lkml.kernel.org/r/20260224011102.56033-1-sj@kernel.org Fixes: bf0eaba0ff9c ("mm/damon/core: implement damos_walk()") Reported-by: Raul Pazemecxas De Andrade Closes: https://lore.kernel.org/CPUPR80MB8171025468965E583EF2490F956CA@CPUPR80MB8171.lamprd80.prod.outlook.com Signed-off-by: Raul Pazemecxas De Andrade Signed-off-by: SeongJae Park Reviewed-by: SeongJae Park Cc: [6.14+] Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 7c19757394ddf5dd954ab8bd968abf7a82343b69 Author: Jedrzej Jagielski Date: Wed Dec 10 12:26:51 2025 +0100 ixgbevf: fix link setup issue commit feae40a6a178bb525a15f19288016e5778102a99 upstream. It may happen that VF spawned for E610 adapter has problem with setting link up. This happens when ixgbevf supporting mailbox API 1.6 cooperates with PF driver which doesn't support this version of API, and hence doesn't support new approach for getting PF link data. In that case VF asks PF to provide link data but as PF doesn't support it, returns -EOPNOTSUPP what leads to early bail from link configuration sequence. Avoid such situation by using legacy VFLINKS approach whenever negotiated API version is less than 1.6. To reproduce the issue just create VF and set its link up - adapter must be any from the E610 family, ixgbevf must support API 1.6 or higher while ixgbevf must not. Fixes: 53f0eb62b4d2 ("ixgbevf: fix getting link speed data for E610 devices") Reviewed-by: Aleksandr Loktionov Reviewed-by: Piotr Kwapulinski Reviewed-by: Paul Menzel Cc: stable@vger.kernel.org Signed-off-by: Jedrzej Jagielski Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit 216176bcfd2bd4a83685d76d827e5ca34706ed8d Author: Eric Biggers Date: Mon Feb 23 19:37:51 2026 -0800 kunit: irq: Ensure timer doesn't fire too frequently commit 201ceb94aa1def0024a7c18ce643e5f65026be06 upstream. Fix a bug where kunit_run_irq_test() could hang if the system is too slow. This was noticed with the crypto library tests in certain VMs. Specifically, if kunit_irq_test_timer_func() and the associated hrtimer code took over 5us to run, then the CPU would spend all its time executing that code in hardirq context. As a result, the task executing kunit_run_irq_test() never had a chance to run, exit the loop, and cancel the timer. To fix it, make kunit_irq_test_timer_func() increase the timer interval when the other contexts aren't having a chance to run. Fixes: 950a81224e8b ("lib/crypto: tests: Add hash-test-template.h and gen-hash-testvecs.py") Cc: stable@vger.kernel.org Reviewed-by: David Gow Link: https://lore.kernel.org/r/20260224033751.97615-1-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit decd9942655db9c7ba7782309c51d6647e787ee1 Author: Jakub Staniszewski Date: Tue Jan 13 20:38:16 2026 +0100 ice: reintroduce retry mechanism for indirect AQ commit 326256c0a72d4877cec1d4df85357da106233128 upstream. Add retry mechanism for indirect Admin Queue (AQ) commands. To do so we need to keep the command buffer. This technically reverts commit 43a630e37e25 ("ice: remove unused buffer copy code in ice_sq_send_cmd_retry()"), but combines it with a fix in the logic by using a kmemdup() call, making it more robust and less likely to break in the future due to programmer error. Cc: Michal Schmidt Cc: stable@vger.kernel.org Fixes: 3056df93f7a8 ("ice: Re-send some AQ commands, as result of EBUSY AQ error") Signed-off-by: Jakub Staniszewski Co-developed-by: Dawid Osuchowski Signed-off-by: Dawid Osuchowski Reviewed-by: Aleksandr Loktionov Reviewed-by: Przemek Kitszel Reviewed-by: Paul Menzel Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit ca19f8f51064f5e3bef08e5ee3674e12817eff8e Author: Darrick J. Wong Date: Mon Mar 2 09:30:02 2026 -0800 iomap: reject delalloc mappings during writeback commit d320f160aa5ff36cdf83c645cca52b615e866e32 upstream. Filesystems should never provide a delayed allocation mapping to writeback; they're supposed to allocate the space before replying. This can lead to weird IO errors and crashes in the block layer if the filesystem is being malicious, or if it hadn't set iomap->dev because it's a delalloc mapping. Fix this by failing writeback on delalloc mappings. Currently no filesystems actually misbehave in this manner, but we ought to be stricter about things like that. Cc: stable@vger.kernel.org # v5.5 Fixes: 598ecfbaa742ac ("iomap: lift the xfs writeback code to iomap") Signed-off-by: Darrick J. Wong Link: https://patch.msgid.link/20260302173002.GL13829@frogsfrogsfrogs Reviewed-by: Christoph Hellwig Reviewed-by: Carlos Maiolino Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit 7bdf00ed75c477252578068dba19934cd825f20a Author: Mark Harmstone Date: Fri Feb 20 12:53:17 2026 +0000 btrfs: fix chunk map leak in btrfs_map_block() after btrfs_chunk_map_num_copies() commit f15fb3d41543244d1179f423da4a4832a55bc050 upstream. Fix a chunk map leak in btrfs_map_block(): if we return early with -EINVAL, we're not freeing the chunk map that we've just looked up. Fixes: 0ae653fbec2b ("btrfs: reduce chunk_map lookups in btrfs_map_block()") CC: stable@vger.kernel.org # 6.12+ Reviewed-by: Filipe Manana Signed-off-by: Mark Harmstone Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit f42b4afdd1f89b1415d4260040af4b636c01b7a6 Author: Marc Zyngier Date: Fri Feb 6 15:48:16 2026 +0000 irqchip/gic-v3-its: Limit number of per-device MSIs to the range the ITS supports commit ce9e40a9a5e5cff0b1b0d2fa582b3d71a8ce68e8 upstream. The ITS driver blindly assumes that EventIDs are in abundant supply, to the point where it never checks how many the hardware actually supports. It turns out that some pretty esoteric integrations make it so that only a few bits are available, all the way down to a single bit. Enforce the advertised limitation at the point of allocating the device structure, and hope that the endpoint driver can deal with such limitation. Fixes: 84a6a2e7fc18d ("irqchip: GICv3: ITS: device allocation and configuration") Signed-off-by: Marc Zyngier Signed-off-by: Thomas Gleixner Reviewed-by: Robin Murphy Reviewed-by: Zenghui Yu Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260206154816.3582887-1-maz@kernel.org Signed-off-by: Greg Kroah-Hartman commit 32752c3e81498b106da64a141379eb94f493fe6f Author: Andy Shevchenko Date: Tue Feb 10 14:58:22 2026 +0100 device property: Allow secondary lookup in fwnode_get_next_child_node() commit 2692c614f8f05929d692b3dbfd3faef1f00fbaf0 upstream. When device_get_child_node_count() got split to the fwnode and device respective APIs, the fwnode didn't inherit the ability to traverse over the secondary fwnode. Hence any user, that switches from device to fwnode API misses this feature. In particular, this was revealed by the commit 1490cbb9dbfd ("device property: Split fwnode_get_child_node_count()") that effectively broke the GPIO enumeration on Intel Galileo boards. Fix this by moving the secondary lookup from device to fwnode API. Note, in general no device_*() API should go into the depth of the fwnode implementation. Fixes: 114dbb4fa7c4 ("drivers property: When no children in primary, try secondary") Cc: stable@vger.kernel.org Signed-off-by: Andy Shevchenko Reviewed-by: Rafael J. Wysocki (Intel) Reviewed-by: Sakari Ailus Link: https://patch.msgid.link/20260210135822.47335-1-andriy.shevchenko@linux.intel.com Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 019debe5851d7355bea9ff0248cc317878924d8f Author: Kuniyuki Iwashima Date: Sat Jan 24 04:18:41 2026 +0000 nfsd: Fix cred ref leak in nfsd_nl_listener_set_doit(). commit 92978c83bb4eef55d02a6c990c01c423131eefa7 upstream. nfsd_nl_listener_set_doit() uses get_current_cred() without put_cred(). As we can see from other callers, svc_xprt_create_from_sa() does not require the extra refcount. nfsd_nl_listener_set_doit() is always in the process context, sendmsg(), and current->cred does not go away. Let's use current_cred() in nfsd_nl_listener_set_doit(). Fixes: 16a471177496 ("NFSD: add listener-{set,get} netlink command") Cc: stable@vger.kernel.org Signed-off-by: Kuniyuki Iwashima Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit db377ed4ecca4db4aa6566b5689ea44dfaf668c9 Author: Catalin Marinas Date: Mon Feb 23 17:45:31 2026 +0000 arm64: gcs: Honour mprotect(PROT_NONE) on shadow stack mappings commit 47a8aad135ac1aed04b7b0c0a8157fd208075827 upstream. vm_get_page_prot() short-circuits the protection_map[] lookup for a VM_SHADOW_STACK mapping since it uses a different PIE index from the typical read/write/exec permissions. However, the side effect is that it also ignores mprotect(PROT_NONE) by creating an accessible PTE. Special-case the !(vm_flags & VM_ACCESS_FLAGS) flags to use the protection_map[VM_NONE] permissions instead. No GCS attributes are required for an inaccessible PTE. Signed-off-by: Catalin Marinas Fixes: 6497b66ba694 ("arm64/mm: Map pages for guarded control stack") Cc: stable@vger.kernel.org Cc: Mark Brown Cc: Will Deacon Cc: David Hildenbrand Reviewed-by: David Hildenbrand (Arm) Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 584926c26f0b704785e9bdeec29ca4265c1a9957 Author: Jiri Olsa Date: Wed Feb 25 12:12:49 2026 +0100 bpf: Fix kprobe_multi cookies access in show_fdinfo callback commit ad6fface76da42721c15e8fb281570aaa44a2c01 upstream. We don't check if cookies are available on the kprobe_multi link before accessing them in show_fdinfo callback, we should. Cc: stable@vger.kernel.org Fixes: da7e9c0a7fbc ("bpf: Add show_fdinfo for kprobe_multi") Signed-off-by: Jiri Olsa Link: https://lore.kernel.org/r/20260225111249.186230-1-jolsa@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit 415aed08de0eebf6aa2180a0e7f28d5a3f2eab96 Author: Alexander Gordeev Date: Tue Feb 24 07:41:07 2026 +0100 s390/pfault: Fix virtual vs physical address confusion commit d879ac6756b662a085a743e76023c768c3241579 upstream. When Linux is running as guest, runs a user space process and the user space process accesses a page that the host has paged out, the guest gets a pfault interrupt and schedules a different process. Without this mechanism the host would have to suspend the whole virtual CPU until the page has been paged in. To setup the pfault interrupt the real address of parameter list should be passed to DIAGNOSE 0x258, but a virtual address is passed instead. That has a performance impact, since the pfault setup never succeeds, the interrupt is never delivered to a guest and the whole virtual CPU is suspended as result. Cc: stable@vger.kernel.org Fixes: c98d2ecae08f ("s390/mm: Uncouple physical vs virtual address spaces") Reported-by: Claudio Imbrenda Reviewed-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit af65cd1853599394b94201c08bed7a46717db478 Author: Shuicheng Lin Date: Thu Feb 19 23:35:18 2026 +0000 drm/xe/sync: Cleanup partially initialized sync on parse failure commit 1bfd7575092420ba5a0b944953c95b74a5646ff8 upstream. xe_sync_entry_parse() can allocate references (syncobj, fence, chain fence, or user fence) before hitting a later failure path. Several of those paths returned directly, leaving partially initialized state and leaking refs. Route these error paths through a common free_sync label and call xe_sync_entry_cleanup(sync) before returning the error. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Matthew Brost Signed-off-by: Shuicheng Lin Reviewed-by: Matthew Brost Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260219233516.2938172-5-shuicheng.lin@intel.com (cherry picked from commit f939bdd9207a5d1fc55cced5459858480686ce22) Cc: stable@vger.kernel.org Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 58e6e3d39c286d60785302ede8e8d4b9dbabb408 Author: Corey Minyard Date: Fri Feb 13 00:15:04 2026 -0600 ipmi:si: Fix check for a misbehaving BMC commit cae66f1a1dcd23e17da5a015ef9d731129f9d2dd upstream. There is a race on checking the state in the sender, it needs to be checked under a lock. But you also need a check to avoid issues with a misbehaving BMC for run to completion mode. So leave the check at the beginning for run to completion, and add a check under the lock to avoid the race. Reported-by: Rafael J. Wysocki Fixes: bc3a9d217755 ("ipmi:si: Gracefully handle if the BMC is non-functional") Cc: stable@vger.kernel.org # 4.18 Signed-off-by: Corey Minyard Reviewed-by: Rafael J. Wysocki (Intel) Signed-off-by: Greg Kroah-Hartman commit 19e1931841e44a022f7631f867e8af4b930198ae Author: Bartosz Golaszewski Date: Thu Feb 19 10:51:33 2026 +0100 gpiolib: normalize the return value of gc->get() on behalf of buggy drivers commit ec2cceadfae72304ca19650f9cac4b2a97b8a2fc upstream. Commit 86ef402d805d ("gpiolib: sanitize the return value of gpio_chip::get()") started checking the return value of the .get() callback in struct gpio_chip. Now - almost a year later - it turns out that there are quite a few drivers in tree that can break with this change. Partially revert it: normalize the return value in GPIO core but also emit a warning. Cc: stable@vger.kernel.org Fixes: 86ef402d805d ("gpiolib: sanitize the return value of gpio_chip::get()") Reported-by: Dmitry Torokhov Closes: https://lore.kernel.org/all/aZSkqGTqMp_57qC7@google.com/ Reviewed-by: Linus Walleij Reviewed-by: Dmitry Torokhov Link: https://patch.msgid.link/20260219-gpiolib-set-normalize-v2-1-f84630e45796@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 32cca65189823f93ba89677a96b106e902b2dc9b Author: Jouni Högander Date: Thu Feb 12 08:27:31 2026 +0200 drm/i915/alpm: ALPM disable fixes commit eb4a7139e97374f42b7242cc754e77f1623fbcd5 upstream. PORT_ALPM_CTL is supposed to be written only before link training. Remove writing it from ALPM disable. Also clearing ALPM_CTL_ALPM_AUX_LESS_ENABLE and is not about disabling ALPM but switching to AUX-Wake ALPM. Stop touching this bit on ALPM disable. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7153 Fixes: 1ccbf135862b ("drm/i915/psr: Enable ALPM on source side for eDP Panel replay") Cc: Animesh Manna Cc: Jani Nikula Cc: # v6.10+ Signed-off-by: Jouni Högander Reviewed-by: Michał Grzelak Link: https://patch.msgid.link/20260212062731.397801-1-jouni.hogander@intel.com (cherry picked from commit 008304c9ae75c772d3460040de56e12112cdf5e6) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 214b6bde0e941a34ba877cf2f26f85d62fb5d598 Author: Dave Airlie Date: Thu Nov 21 11:46:01 2024 +1000 nouveau/gsp: drop WARN_ON in ACPI probes commit 9478c166c46934160135e197b049b5a05753f2ad upstream. These WARN_ONs seem to trigger a lot, and we don't seem to have a plan to fix them, so just drop them, as they are most likely harmless. Cc: stable@vger.kernel.org Fixes: 176fdcbddfd2 ("drm/nouveau/gsp/r535: add support for booting GSP-RM") Signed-off-by: Dave Airlie Link: https://patch.msgid.link/20241121014601.229391-1-airlied@gmail.com Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 9b7855110fd75d6cbe5514b36d3b7944176992c1 Author: Corey Minyard Date: Fri Feb 6 09:59:32 2026 -0600 ipmi:si: Handle waiting messages when BMC failure detected commit 52c9ee202edd21d0599ac3b5a6fe1da2a2f053e5 upstream. If a BMC failure is detected, the current message is returned with an error. However, if there was a waiting message, it would not be handled. Add a check for the waiting message after handling the current message. Suggested-by: Guenter Roeck Reported-by: Rafael J. Wysocki Closes: https://lore.kernel.org/linux-acpi/CAK8fFZ58fidGUCHi5WFX0uoTPzveUUDzT=k=AAm4yWo3bAuCFg@mail.gmail.com/ Fixes: bc3a9d217755 ("ipmi:si: Gracefully handle if the BMC is non-functional") Cc: stable@vger.kernel.org # 4.18 Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman commit bc001cd1a48240c388804b3e438ae3e1c1a5bb48 Author: Franz Schnyder Date: Fri Feb 6 13:37:36 2026 +0100 drm/bridge: ti-sn65dsi86: Enable HPD polling if IRQ is not used commit 0b87d51690dd5131cbe9fbd23746b037aab89815 upstream. Fallback to polling to detect hotplug events on systems without interrupts. On systems where the interrupt line of the bridge is not connected, the bridge cannot notify hotplug events. Only add the DRM_BRIDGE_OP_HPD flag if an interrupt has been registered otherwise remain in polling mode. Fixes: 55e8ff842051 ("drm/bridge: ti-sn65dsi86: Add HPD for DisplayPort connector type") Cc: stable@vger.kernel.org # 6.16: 9133bc3f0564: drm/bridge: ti-sn65dsi86: Add Signed-off-by: Franz Schnyder Reviewed-by: Douglas Anderson [dianders: Adjusted Fixes/stable line based on discussion] Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20260206123758.374555-1-fra.schnyder@gmail.com Signed-off-by: Greg Kroah-Hartman commit e6d779654cda63d632bd8dfcdcabd125057e30a5 Author: Osama Abdelkader Date: Mon Feb 9 19:41:14 2026 +0100 drm/bridge: samsung-dsim: Fix memory leak in error path commit 803ec1faf7c1823e6e3b1f2aaa81be18528c9436 upstream. In samsung_dsim_host_attach(), drm_bridge_add() is called to add the bridge. However, if samsung_dsim_register_te_irq() or pdata->host_ops->attach() fails afterwards, the function returns without removing the bridge, causing a memory leak. Fix this by adding proper error handling with goto labels to ensure drm_bridge_remove() is called in all error paths. Also ensure that samsung_dsim_unregister_te_irq() is called if the attach operation fails after the TE IRQ has been registered. samsung_dsim_unregister_te_irq() function is moved without changes to be before samsung_dsim_host_attach() to avoid forward declaration. Fixes: e7447128ca4a ("drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge") Cc: stable@vger.kernel.org Signed-off-by: Osama Abdelkader Reviewed-by: Luca Ceresoli Link: https://patch.msgid.link/20260209184115.10937-1-osama.abdelkader@gmail.com Signed-off-by: Luca Ceresoli Signed-off-by: Greg Kroah-Hartman commit 1df500f363bc878c5ee10ac6598e0335e6729aa9 Author: Corey Minyard Date: Fri Feb 6 10:33:52 2026 -0600 ipmi:si: Use a long timeout when the BMC is misbehaving commit c3bb3295637cc9bf514f690941ca9a385bf30113 upstream. If the driver goes into HOSED state, don't reset the timeout to the short timeout in the timeout handler. Reported-by: Igor Raits Closes: https://lore.kernel.org/linux-acpi/CAK8fFZ58fidGUCHi5WFX0uoTPzveUUDzT=k=AAm4yWo3bAuCFg@mail.gmail.com/ Fixes: bc3a9d217755 ("ipmi:si: Gracefully handle if the BMC is non-functional") Cc: stable@vger.kernel.org # 4.18 Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman commit 68d7fcb6a451c8dc0c94e6e14308229ea0a99e8d Author: Corey Minyard Date: Thu Feb 12 21:52:48 2026 -0600 ipmi:si: Don't block module unload if the BMC is messed up commit f895e5df80316a308c2f7d64d13a78494630ea05 upstream. If the BMC is in a bad state, don't bother waiting for queues messages since there can't be any. Otherwise the unload is blocked until the BMC is back in a good state. Reported-by: Rafael J. Wysocki Fixes: bc3a9d217755 ("ipmi:si: Gracefully handle if the BMC is non-functional") Cc: stable@vger.kernel.org # 4.18 Signed-off-by: Corey Minyard Reviewed-by: Rafael J. Wysocki (Intel) Signed-off-by: Greg Kroah-Hartman commit 06ef2ba582c68daa6bdaaef82827734d9f07b8fd Author: Mario Limonciello Date: Wed Feb 25 10:51:16 2026 -0600 drm/amd: Disable MES LR compute W/A commit 6b0d812971370c64b837a2db4275410f478272fe upstream. A workaround was introduced in commit 1fb710793ce2 ("drm/amdgpu: Enable MES lr_compute_wa by default") to help with some hangs observed in gfx1151. This WA didn't fully fix the issue. It was actually fixed by adjusting the VGPR size to the correct value that matched the hardware in commit b42f3bf9536c ("drm/amdkfd: bump minimum vgpr size for gfx1151"). There are reports of instability on other products with newer GC microcode versions, and I believe they're caused by this workaround. As we don't need the workaround any more, remove it. Fixes: b42f3bf9536c ("drm/amdkfd: bump minimum vgpr size for gfx1151") Acked-by: Alex Deucher Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 9973e64bd6ee7642860a6f3b6958cbf14e89cabd) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b1d10508da559da2e0ca9cca6505094a7df948e1 Author: Sunil Khatri Date: Tue Feb 24 12:13:09 2026 +0530 drm/amdgpu: add upper bound check on user inputs in wait ioctl commit 64ac7c09fc44985ec9bb6a9db740899fa40ca613 upstream. Huge input values in amdgpu_userq_wait_ioctl can lead to a OOM and could be exploited. So check these input value against AMDGPU_USERQ_MAX_HANDLES which is big enough value for genuine use cases and could potentially avoid OOM. v2: squash in Srini's fix Signed-off-by: Sunil Khatri Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit fcec012c664247531aed3e662f4280ff804d1476) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 762f47e2b824383d5be65eee2c40a1269b7d50c8 Author: Tvrtko Ursulin Date: Mon Feb 23 12:41:30 2026 +0000 drm/amdgpu/userq: Fix reference leak in amdgpu_userq_wait_ioctl commit 49abfa812617a7f2d0132c70d23ac98b389c6ec1 upstream. Drop reference to syncobj and timeline fence when aborting the ioctl due output array being too small. Reviewed-by: Alex Deucher Signed-off-by: Tvrtko Ursulin Fixes: a292fdecd728 ("drm/amdgpu: Implement userqueue signal/wait IOCTL") Cc: Arunpravin Paneer Selvam Cc: Christian König Cc: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 68951e9c3e6bb22396bc42ef2359751c8315dd27) Cc: # v6.16+ Signed-off-by: Greg Kroah-Hartman commit 6fff5204d8aa26b1be50b6427f833bd3e8899c4f Author: Sunil Khatri Date: Fri Feb 20 13:47:58 2026 +0530 drm/amdgpu: add upper bound check on user inputs in signal ioctl commit ea78f8c68f4f6211c557df49174c54d167821962 upstream. Huge input values in amdgpu_userq_signal_ioctl can lead to a OOM and could be exploited. So check these input value against AMDGPU_USERQ_MAX_HANDLES which is big enough value for genuine use cases and could potentially avoid OOM. Signed-off-by: Sunil Khatri Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit be267e15f99bc97cbe202cd556717797cdcf79a5) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 6bfda7ce56e7d14a677b7bcd6c7a5009cc29aa88 Author: David Arcari Date: Tue Feb 24 07:21:06 2026 -0500 cpufreq: intel_pstate: Fix NULL pointer dereference in update_cpu_qos_request() commit ab39cc4cb8ceecdc2b61747433e7237f1ac2b789 upstream. The update_cpu_qos_request() function attempts to initialize the 'freq' variable by dereferencing 'cpudata' before verifying if the 'policy' is valid. This issue occurs on systems booted with the "nosmt" parameter, where all_cpu_data[cpu] is NULL for the SMT sibling threads. As a result, any call to update_qos_requests() will result in a NULL pointer dereference as the code will attempt to access pstate.turbo_freq using the NULL cpudata pointer. Also, pstate.turbo_freq may be updated by intel_pstate_get_hwp_cap() after initializing the 'freq' variable, so it is better to defer the 'freq' until intel_pstate_get_hwp_cap() has been called. Fix this by deferring the 'freq' assignment until after the policy and driver_data have been validated. Fixes: ae1bdd23b99f ("cpufreq: intel_pstate: Adjust frequency percentage computations") Reported-by: Jirka Hladky Closes: https://lore.kernel.org/all/CAE4VaGDfiPvz3AzrwrwM4kWB3SCkMci25nPO8W1JmTBd=xHzZg@mail.gmail.com/ Signed-off-by: David Arcari Cc: 6.18+ # 6.18+ [ rjw: Added one paragraph to the changelog ] Link: https://patch.msgid.link/20260224122106.228116-1-darcari@redhat.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 4729c7b00a347fd37d0cbc265b85f2884c3e06b6 Author: Christian Brauner Date: Thu Feb 26 10:43:55 2026 +0100 kthread: consolidate kthread exit paths to prevent use-after-free commit 28aaa9c39945b7925a1cc1d513c8f21ed38f5e4f upstream. Guillaume reported crashes via corrupted RCU callback function pointers during KUnit testing. The crash was traced back to the pidfs rhashtable conversion which replaced the 24-byte rb_node with an 8-byte rhash_head in struct pid, shrinking it from 160 to 144 bytes. struct kthread (without CONFIG_BLK_CGROUP) is also 144 bytes. With CONFIG_SLAB_MERGE_DEFAULT and SLAB_HWCACHE_ALIGN both round up to 192 bytes and share the same slab cache. struct pid.rcu.func and struct kthread.affinity_node both sit at offset 0x78. When a kthread exits via make_task_dead() it bypasses kthread_exit() and misses the affinity_node cleanup. free_kthread_struct() frees the memory while the node is still linked into the global kthread_affinity_list. A subsequent list_del() by another kthread writes through dangling list pointers into the freed and reused memory, corrupting the pid's rcu.func pointer. Instead of patching free_kthread_struct() to handle the missed cleanup, consolidate all kthread exit paths. Turn kthread_exit() into a macro that calls do_exit() and add kthread_do_exit() which is called from do_exit() for any task with PF_KTHREAD set. This guarantees that kthread-specific cleanup always happens regardless of the exit path - make_task_dead(), direct do_exit(), or kthread_exit(). Replace __to_kthread() with a new tsk_is_kthread() accessor in the public header. Export do_exit() since module code using the kthread_exit() macro now needs it directly. Reported-by: Guillaume Tucker Tested-by: Guillaume Tucker Tested-by: Mark Brown Tested-by: David Gow Cc: Link: https://lore.kernel.org/all/20260224-mittlerweile-besessen-2738831ae7f6@brauner Co-developed-by: Linus Torvalds Fixes: 4d13f4304fa4 ("kthread: Implement preferred affinity") Signed-off-by: Linus Torvalds Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit 8a259a5c70ddc358b50a0ffc711ad750aee0404f Author: Axel Rasmussen Date: Tue Feb 24 16:24:34 2026 -0800 Revert "ptdesc: remove references to folios from __pagetable_ctor() and pagetable_dtor()" commit 2d28ed588f8d7d0d41b0a4fad7f0d05e4bbf1797 upstream. This change swapped out mod_node_page_state for lruvec_stat_add_folio. But, these two APIs are not interchangeable: the lruvec version also increments memcg stats, in addition to "global" pgdat stats. So after this change, the "pagetables" memcg stat in memory.stat always yields "0", which is a userspace visible regression. I tried to look for a refactor where we add a variant of lruvec_stat_mod_folio which takes a pgdat and a memcg instead of a folio, to try to adhere to the spirit of the original patch. But at the end of the day this just means we have to call folio_memcg(ptdesc_folio(ptdesc)) anyway, which doesn't really accomplish much. This regression is visible in master as well as 6.18 stable, so CC stable too. Link: https://lkml.kernel.org/r/20260225002434.2953895-1-axelrasmussen@google.com Fixes: f0c92726e89f ("ptdesc: remove references to folios from __pagetable_ctor() and pagetable_dtor()") Signed-off-by: Axel Rasmussen Acked-by: Shakeel Butt Acked-by: Johannes Weiner Reviewed-by: Vishal Moola (Oracle) Cc: David Hildenbrand Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Matthew Wilcox (Oracle) Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Roman Gushchin Cc: Muchun Song Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit ae931283b2f377426396bac8f7857502801cdbc2 Author: Xu Yang Date: Mon Mar 9 15:43:12 2026 +0800 Revert "tcpm: allow looking for role_sw device in the main node" commit 6b275bfaa16be3fb1689fa6794e445ecd127a1b4 upstream. This reverts commit 1366cd228b0c67b60a2c0c26ef37fe9f7cfedb7f. The fwnode_usb_role_switch_get() returns NULL only if no connection is found, returns ERR_PTR(-EPROBE_DEFER) if connection is found but deferred probe is needed, or a valid pointer of usb_role_switch. When switching from a NULL check to IS_ERR_OR_NULL(), usb_role_switch_get() returns NULL and overwrites the ERR_PTR(-EPROBE_DEFER) returned by fwnode_usb_role_switch_get(). This causes the deferred probe indication to be lost, preventing the USB role switch from ever being retrieved. Fixes: 1366cd228b0c ("tcpm: allow looking for role_sw device in the main node") Cc: stable Signed-off-by: Xu Yang Tested-by: Arnaud Ferraris Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260309074313.2809867-2-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman commit 21a13db8d449b9c7eda4471da7f12417602dbbc7 Author: Xingui Yang Date: Thu Mar 5 14:40:39 2026 +0800 scsi: hisi_sas: Fix NULL pointer exception during user_scan() [ Upstream commit 8ddc0c26916574395447ebf4cff684314f6873a9 ] user_scan() invokes updated sas_user_scan() for channel 0, and if successful, iteratively scans remaining channels (1 to shost->max_channel) via scsi_scan_host_selected() in commit 37c4e72b0651 ("scsi: Fix sas_user_scan() to handle wildcard and multi-channel scans"). However, hisi_sas supports only one channel, and the current value of max_channel is 1. sas_user_scan() for channel 1 will trigger the following NULL pointer exception: [ 441.554662] Unable to handle kernel NULL pointer dereference at virtual address 00000000000008b0 [ 441.554699] Mem abort info: [ 441.554710] ESR = 0x0000000096000004 [ 441.554718] EC = 0x25: DABT (current EL), IL = 32 bits [ 441.554723] SET = 0, FnV = 0 [ 441.554726] EA = 0, S1PTW = 0 [ 441.554730] FSC = 0x04: level 0 translation fault [ 441.554735] Data abort info: [ 441.554737] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 441.554742] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 441.554747] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 441.554752] user pgtable: 4k pages, 48-bit VAs, pgdp=00000828377a6000 [ 441.554757] [00000000000008b0] pgd=0000000000000000, p4d=0000000000000000 [ 441.554769] Internal error: Oops: 0000000096000004 [#1] SMP [ 441.629589] Modules linked in: arm_spe_pmu arm_smmuv3_pmu tpm_tis_spi hisi_uncore_sllc_pmu hisi_uncore_pa_pmu hisi_uncore_l3c_pmu hisi_uncore_hha_pmu hisi_uncore_ddrc_pmu hisi_uncore_cpa_pmu hns3_pmu hisi_ptt hisi_pcie_pmu tpm_tis_core spidev spi_hisi_sfc_v3xx hisi_uncore_pmu spi_dw_mmio fuse hclge hclge_common hisi_sec2 hisi_hpre hisi_zip hisi_qm hns3 hisi_sas_v3_hw sm3_ce sbsa_gwdt hnae3 hisi_sas_main uacce hisi_dma i2c_hisi dm_mirror dm_region_hash dm_log dm_mod [ 441.670819] CPU: 46 UID: 0 PID: 6994 Comm: bash Kdump: loaded Not tainted 7.0.0-rc2+ #84 PREEMPT [ 441.691327] pstate: 81400009 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 441.698277] pc : sas_find_dev_by_rphy+0x44/0x118 [ 441.702896] lr : sas_find_dev_by_rphy+0x3c/0x118 [ 441.707502] sp : ffff80009abbba40 [ 441.710805] x29: ffff80009abbba40 x28: ffff082819a40008 x27: ffff082810c37c08 [ 441.717930] x26: ffff082810c37c28 x25: ffff082819a40290 x24: ffff082810c37c00 [ 441.725054] x23: 0000000000000000 x22: 0000000000000001 x21: ffff082819a40000 [ 441.732179] x20: ffff082819a40290 x19: 0000000000000000 x18: 0000000000000020 [ 441.739304] x17: 0000000000000000 x16: ffffb5dad6bda690 x15: 00000000ffffffff [ 441.746428] x14: ffff082814c3b26c x13: 00000000ffffffff x12: ffff082814c3b26a [ 441.753553] x11: 00000000000000c0 x10: 000000000000003a x9 : ffffb5dad5ea94f4 [ 441.760678] x8 : 000000000000003a x7 : ffff80009abbbab0 x6 : 0000000000000030 [ 441.767802] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 441.774926] x2 : ffff08280f35a300 x1 : ffffb5dad7127180 x0 : 0000000000000000 [ 441.782053] Call trace: [ 441.784488] sas_find_dev_by_rphy+0x44/0x118 (P) [ 441.789095] sas_target_alloc+0x24/0xb0 [ 441.792920] scsi_alloc_target+0x290/0x330 [ 441.797010] __scsi_scan_target+0x88/0x258 [ 441.801096] scsi_scan_channel+0x74/0xb8 [ 441.805008] scsi_scan_host_selected+0x170/0x188 [ 441.809615] sas_user_scan+0xfc/0x148 [ 441.813267] store_scan+0x10c/0x180 [ 441.816743] dev_attr_store+0x20/0x40 [ 441.820398] sysfs_kf_write+0x84/0xa8 [ 441.824054] kernfs_fop_write_iter+0x130/0x1c8 [ 441.828487] vfs_write+0x2c0/0x370 [ 441.831880] ksys_write+0x74/0x118 [ 441.835271] __arm64_sys_write+0x24/0x38 [ 441.839182] invoke_syscall+0x50/0x120 [ 441.842919] el0_svc_common.constprop.0+0xc8/0xf0 [ 441.847611] do_el0_svc+0x24/0x38 [ 441.850913] el0_svc+0x38/0x158 [ 441.854043] el0t_64_sync_handler+0xa0/0xe8 [ 441.858214] el0t_64_sync+0x1ac/0x1b0 [ 441.861865] Code: aa1303e0 97ff70a8 34ffff80 d10a4273 (f9445a75) [ 441.867946] ---[ end trace 0000000000000000 ]--- Therefore, set max_channel to 0. Fixes: e21fe3a52692 ("scsi: hisi_sas: add initialisation for v3 pci-based controller") Signed-off-by: Xingui Yang Signed-off-by: Yihang Li Link: https://patch.msgid.link/20260305064039.4096775-1-liyihang9@huawei.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b17211b512cbf0e07de27e1932428ee6c20df910 Author: Wang Shuaiwei Date: Sat Mar 7 11:51:28 2026 +0800 scsi: ufs: core: Fix SError in ufshcd_rtc_work() during UFS suspend [ Upstream commit b0bd84c39289ef6a6c3827dd52c875659291970a ] In __ufshcd_wl_suspend(), cancel_delayed_work_sync() is called to cancel the UFS RTC work, but it is placed after ufshcd_vops_suspend(hba, pm_op, POST_CHANGE). This creates a race condition where ufshcd_rtc_work() can still be running while ufshcd_vops_suspend() is executing. When UFSHCD_CAP_CLK_GATING is not supported, the condition !hba->clk_gating.active_reqs is always true, causing ufshcd_update_rtc() to be executed. Since ufshcd_vops_suspend() typically performs clock gating operations, executing ufshcd_update_rtc() at that moment triggers an SError. The kernel panic trace is as follows: Kernel panic - not syncing: Asynchronous SError Interrupt Call trace: dump_backtrace+0xec/0x128 show_stack+0x18/0x28 dump_stack_lvl+0x40/0xa0 dump_stack+0x18/0x24 panic+0x148/0x374 nmi_panic+0x3c/0x8c arm64_serror_panic+0x64/0x8c do_serror+0xc4/0xc8 el1h_64_error_handler+0x34/0x4c el1h_64_error+0x68/0x6c el1_interrupt+0x20/0x58 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x68/0x6c ktime_get+0xc4/0x12c ufshcd_mcq_sq_stop+0x4c/0xec ufshcd_mcq_sq_cleanup+0x64/0x1dc ufshcd_clear_cmd+0x38/0x134 ufshcd_issue_dev_cmd+0x298/0x4d0 ufshcd_exec_dev_cmd+0x1a4/0x1c4 ufshcd_query_attr+0xbc/0x19c ufshcd_rtc_work+0x10c/0x1c8 process_scheduled_works+0x1c4/0x45c worker_thread+0x32c/0x3e8 kthread+0x120/0x1d8 ret_from_fork+0x10/0x20 Fix this by moving cancel_delayed_work_sync() before the call to ufshcd_vops_suspend(hba, pm_op, PRE_CHANGE), ensuring the UFS RTC work is fully completed or cancelled at that point. Cc: Bean Huo Fixes: 6bf999e0eb41 ("scsi: ufs: core: Add UFS RTC support") Reviewed-by: Bart Van Assche Signed-off-by: Wang Shuaiwei Link: https://patch.msgid.link/20260307035128.3419687-1-wangshuaiwei1@xiaomi.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 98074e16742ae87fb82e234b419783c5ffc9baea Author: Viktor Malik Date: Mon Mar 9 15:40:45 2026 +0100 powerpc, perf: Check that current->mm is alive before getting user callchain [ Upstream commit e9bbfb4bfa86c6b5515b868d6982ac60505d7e39 ] It may happen that mm is already released, which leads to kernel panic. This adds the NULL check for current->mm, similarly to commit 20afc60f892d ("x86, perf: Check that current->mm is alive before getting user callchain"). I was getting this panic when running a profiling BPF program (profile.py from bcc-tools): [26215.051935] Kernel attempted to read user page (588) - exploit attempt? (uid: 0) [26215.051950] BUG: Kernel NULL pointer dereference on read at 0x00000588 [26215.051952] Faulting instruction address: 0xc00000000020fac0 [26215.051957] Oops: Kernel access of bad area, sig: 11 [#1] [...] [26215.052049] Call Trace: [26215.052050] [c000000061da6d30] [c00000000020fc10] perf_callchain_user_64+0x2d0/0x490 (unreliable) [26215.052054] [c000000061da6dc0] [c00000000020f92c] perf_callchain_user+0x1c/0x30 [26215.052057] [c000000061da6de0] [c0000000005ab2a0] get_perf_callchain+0x100/0x360 [26215.052063] [c000000061da6e70] [c000000000573bc8] bpf_get_stackid+0x88/0xf0 [26215.052067] [c000000061da6ea0] [c008000000042258] bpf_prog_16d4ab9ab662f669_do_perf_event+0xf8/0x274 [...] In addition, move storing the top-level stack entry to generic perf_callchain_user to make sure the top-evel entry is always captured, even if current->mm is NULL. Fixes: 20002ded4d93 ("perf_counter: powerpc: Add callchain support") Signed-off-by: Viktor Malik Tested-by: Qiao Zhao Tested-by: Venkat Rao Bagalkote Reviewed-by: Saket Kumar Bhaskar [Maddy: fixed message to avoid checkpatch format style error] Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260309144045.169427-1-vmalik@redhat.com Signed-off-by: Sasha Levin commit 9e84113ea6ec22775a3bd8dbfae471906233f5da Author: Adrian Ng Ho Yin Date: Fri Feb 13 14:00:48 2026 +0800 i3c: dw-i3c-master: Set SIR_REJECT in DAT on device attach and reattach [ Upstream commit f311a05784634febd299f03476b80f3f18489767 ] The DesignWare I3C master controller ACKs IBIs as soon as a valid Device Address Table (DAT) entry is present. This can create a race between device attachment (after DAA) and the point where the client driver enables IBIs via i3c_device_enable_ibi(). Set DEV_ADDR_TABLE_SIR_REJECT in the DAT entry during attach_i3c_dev() and reattach_i3c_dev() so that IBIs are rejected by default. The bit is managed thereafter by the existing dw_i3c_master_set_sir_enabled() function, which clears it in enable_ibi() after ENEC is issued, and restores it in disable_ibi() after DISEC. Fixes: 1dd728f5d4d4 ("i3c: master: Add driver for Synopsys DesignWare IP") Signed-off-by: Adrian Ng Ho Yin Reviewed-by: Frank Li Link: https://patch.msgid.link/53f5b8cbdd8af789ec38b95b02873f32f9182dd6.1770962368.git.adrianhoyin.ng@altera.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 2d845604ca4fb0b020f6ed9e968dee4bd5dd420a Author: Steven Rostedt Date: Fri Mar 6 21:24:03 2026 -0500 time/jiffies: Mark jiffies_64_to_clock_t() notrace [ Upstream commit 755a648e78f12574482d4698d877375793867fa1 ] The trace_clock_jiffies() function that handles the "uptime" clock for tracing calls jiffies_64_to_clock_t(). This causes the function tracer to constantly recurse when the tracing clock is set to "uptime". Mark it notrace to prevent unnecessary recursion when using the "uptime" clock. Fixes: 58d4e21e50ff3 ("tracing: Fix wraparound problems in "uptime" trace clock") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260306212403.72270bb2@robin Signed-off-by: Sasha Levin commit 2e8e9aea8cd5a9fdcd450ebb5e4f56b2056b3c6a Author: Geoffrey D. Bennett Date: Sat Feb 21 02:33:45 2026 +1030 ALSA: usb-audio: Improve Focusrite sample rate filtering [ Upstream commit 24d2d3c5f94007a5a0554065ab7349bb69e28bcb ] Replace the bLength == 10 max_rate check in focusrite_valid_sample_rate() with filtering that also examines the bmControls VAL_ALT_SETTINGS bit. When VAL_ALT_SETTINGS is readable, the device uses strict per-altsetting rate filtering (only the highest rate pair for that altsetting is valid). When it is not readable, all rates up to max_rate are valid. For devices without the bLength == 10 Format Type descriptor extension but with VAL_ALT_SETTINGS readable and multiple altsettings (only seen in Scarlett 18i8 3rd Gen playback), fall back to the Focusrite convention: alt 1 = 48kHz, alt 2 = 96kHz, alt 3 = 192kHz. This produces correct rate tables for all tested Focusrite devices (all Scarlett 2nd, 3rd, and 4th Gen, Clarett+, and Vocaster) using only USB descriptors, allowing QUIRK_FLAG_VALIDATE_RATES to be removed for Focusrite in the next commit. Signed-off-by: Geoffrey D. Bennett Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/7e18c1f393a6ecb6fc75dd867a2c4dbe135e3e22.1771594828.git.g@b4.vu Signed-off-by: Sasha Levin commit 097cd68f46686391a98f2618188f0cb7b7570de2 Author: Max Kellermann Date: Tue Feb 24 14:26:57 2026 +0100 ceph: fix memory leaks in ceph_mdsc_build_path() commit 040d159a45ded7f33201421a81df0aa2a86e5a0b upstream. Add __putname() calls to error code paths that did not free the "path" pointer obtained by __getname(). If ownership of this pointer is not passed to the caller via path_info.path, the function must free it before returning. Cc: stable@vger.kernel.org Fixes: 3fd945a79e14 ("ceph: encode encrypted name in ceph_mdsc_build_path and dentry release") Fixes: 550f7ca98ee0 ("ceph: give up on paths longer than PATH_MAX") Signed-off-by: Max Kellermann Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 7335e21830b8d32b0b13de9564bd2894c5b5850a Author: Hristo Venev Date: Wed Feb 25 19:07:56 2026 +0200 ceph: do not skip the first folio of the next object in writeback commit 081a0b78ef30f5746cda3e92e28b4d4ae92901d1 upstream. When `ceph_process_folio_batch` encounters a folio past the end of the current object, it should leave it in the batch so that it is picked up in the next iteration. Removing the folio from the batch means that it does not get written back and remains dirty instead. This makes `fsync()` silently skip some of the data, delays capability release, and breaks coherence with `O_DIRECT`. The link below contains instructions for reproducing the bug. Cc: stable@vger.kernel.org Fixes: ce80b76dd327 ("ceph: introduce ceph_process_folio_batch() method") Link: https://tracker.ceph.com/issues/75156 Signed-off-by: Hristo Venev Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 7db008e85a5d17b64bc5390b828bf457ae91a415 Author: Max Kellermann Date: Fri Sep 5 23:15:30 2025 +0200 ceph: fix i_nlink underrun during async unlink commit ce0123cbb4a40a2f1bbb815f292b26e96088639f upstream. During async unlink, we drop the `i_nlink` counter before we receive the completion (that will eventually update the `i_nlink`) because "we assume that the unlink will succeed". That is not a bad idea, but it races against deletions by other clients (or against the completion of our own unlink) and can lead to an underrun which emits a WARNING like this one: WARNING: CPU: 85 PID: 25093 at fs/inode.c:407 drop_nlink+0x50/0x68 Modules linked in: CPU: 85 UID: 3221252029 PID: 25093 Comm: php-cgi8.1 Not tainted 6.14.11-cm4all1-ampere #655 Hardware name: Supermicro ARS-110M-NR/R12SPD-A, BIOS 1.1b 10/17/2023 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drop_nlink+0x50/0x68 lr : ceph_unlink+0x6c4/0x720 sp : ffff80012173bc90 x29: ffff80012173bc90 x28: ffff086d0a45aaf8 x27: ffff0871d0eb5680 x26: ffff087f2a64a718 x25: 0000020000000180 x24: 0000000061c88647 x23: 0000000000000002 x22: ffff07ff9236d800 x21: 0000000000001203 x20: ffff07ff9237b000 x19: ffff088b8296afc0 x18: 00000000f3c93365 x17: 0000000000070000 x16: ffff08faffcbdfe8 x15: ffff08faffcbdfec x14: 0000000000000000 x13: 45445f65645f3037 x12: 34385f6369706f74 x11: 0000a2653104bb20 x10: ffffd85f26d73290 x9 : ffffd85f25664f94 x8 : 00000000000000c0 x7 : 0000000000000000 x6 : 0000000000000002 x5 : 0000000000000081 x4 : 0000000000000481 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff08727d3f91e8 Call trace: drop_nlink+0x50/0x68 (P) vfs_unlink+0xb0/0x2e8 do_unlinkat+0x204/0x288 __arm64_sys_unlinkat+0x3c/0x80 invoke_syscall.constprop.0+0x54/0xe8 do_el0_svc+0xa4/0xc8 el0_svc+0x18/0x58 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x154/0x158 In ceph_unlink(), a call to ceph_mdsc_submit_request() submits the CEPH_MDS_OP_UNLINK to the MDS, but does not wait for completion. Meanwhile, between this call and the following drop_nlink() call, a worker thread may process a CEPH_CAP_OP_IMPORT, CEPH_CAP_OP_GRANT or just a CEPH_MSG_CLIENT_REPLY (the latter of which could be our own completion). These will lead to a set_nlink() call, updating the `i_nlink` counter to the value received from the MDS. If that new `i_nlink` value happens to be zero, it is illegal to decrement it further. But that is exactly what ceph_unlink() will do then. The WARNING can be reproduced this way: 1. Force async unlink; only the async code path is affected. Having no real clue about Ceph internals, I was unable to find out why the MDS wouldn't give me the "Fxr" capabilities, so I patched get_caps_for_async_unlink() to always succeed. (Note that the WARNING dump above was found on an unpatched kernel, without this kludge - this is not a theoretical bug.) 2. Add a sleep call after ceph_mdsc_submit_request() so the unlink completion gets handled by a worker thread before drop_nlink() is called. This guarantees that the `i_nlink` is already zero before drop_nlink() runs. The solution is to skip the counter decrement when it is already zero, but doing so without a lock is still racy (TOCTOU). Since ceph_fill_inode() and handle_cap_grant() both hold the `ceph_inode_info.i_ceph_lock` spinlock while set_nlink() runs, this seems like the proper lock to protect the `i_nlink` updates. I found prior art in NFS and SMB (using `inode.i_lock`) and AFS (using `afs_vnode.cb_lock`). All three have the zero check as well. Cc: stable@vger.kernel.org Fixes: 2ccb45462aea ("ceph: perform asynchronous unlink if we have sufficient caps") Signed-off-by: Max Kellermann Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit bdf614c81081b6c23bf271fa2bcc3e501ca27348 Author: Ilya Dryomov Date: Sun Mar 8 17:57:23 2026 +0100 libceph: admit message frames only in CEPH_CON_S_OPEN state commit a5a373705081d7cc6363e16990e2361b0b362314 upstream. Similar checks are performed for all control frames, but an early check for message frames was missing. process_message() is already set up to terminate the loop in case the state changes while con->ops->dispatch() handler is being executed. Cc: stable@vger.kernel.org Signed-off-by: Ilya Dryomov Reviewed-by: Alex Markuze Reviewed-by: Viacheslav Dubeyko Signed-off-by: Greg Kroah-Hartman commit ba0a4df8c563536857dcbf7b4dbd0f2a15f57ace Author: Raphael Zimmer Date: Thu Feb 26 16:07:31 2026 +0100 libceph: Use u32 for non-negative values in ceph_monmap_decode() commit 770444611f047dbfd4517ec0bc1b179d40c2f346 upstream. This patch fixes unnecessary implicit conversions that change signedness of blob_len and num_mon in ceph_monmap_decode(). Currently blob_len and num_mon are (signed) int variables. They are used to hold values that are always non-negative and get assigned in ceph_decode_32_safe(), which is meant to assign u32 values. Both variables are subsequently used as unsigned values, and the value of num_mon is further assigned to monmap->num_mon, which is of type u32. Therefore, both variables should be of type u32. This is especially relevant for num_mon. If the value read from the incoming message is very large, it is interpreted as a negative value, and the check for num_mon > CEPH_MAX_MON does not catch it. This leads to the attempt to allocate a very large chunk of memory for monmap, which will most likely fail. In this case, an unnecessary attempt to allocate memory is performed, and -ENOMEM is returned instead of -EINVAL. Cc: stable@vger.kernel.org Signed-off-by: Raphael Zimmer Reviewed-by: Viacheslav Dubeyko Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 69fe5af33fa3806f398d21c081d73c66e5523bc2 Author: Ilya Dryomov Date: Sun Mar 8 17:38:00 2026 +0100 libceph: prevent potential out-of-bounds reads in process_message_header() commit 69fb5d91bba44ecf7eb80530b85fa4fb028921d5 upstream. If the message frame is (maliciously) corrupted in a way that the length of the control segment ends up being less than the size of the message header or a different frame is made to look like a message frame, out-of-bounds reads may ensue in process_message_header(). Perform an explicit bounds check before decoding the message header. Cc: stable@vger.kernel.org Reported-by: Raphael Zimmer Signed-off-by: Ilya Dryomov Reviewed-by: Alex Markuze Reviewed-by: Viacheslav Dubeyko Signed-off-by: Greg Kroah-Hartman commit fc4d944dbaee92ab8d660e81e1469b4bb79f47f3 Author: Ilya Dryomov Date: Sun Mar 8 20:01:27 2026 +0100 libceph: reject preamble if control segment is empty commit c4c22b846eceff05b1129b8844a80310e55a7f87 upstream. While head_onwire_len() has a branch to handle ctrl_len == 0 case, prepare_read_control() always sets up a kvec for the CRC meaning that a non-empty control segment is effectively assumed. All frames that clients deal with meet that assumption, so let's make it official and treat the preamble with an empty control segment as malformed. Cc: stable@vger.kernel.org Signed-off-by: Ilya Dryomov Reviewed-by: Alex Markuze Signed-off-by: Greg Kroah-Hartman commit f9da5c1bbac5c8e33259fe00ed7347438fffa969 Author: Raphael Zimmer Date: Tue Mar 10 15:28:15 2026 +0100 libceph: Fix potential out-of-bounds access in ceph_handle_auth_reply() commit b282c43ed156ae15ea76748fc15cd5c39dc9ab72 upstream. This patch fixes an out-of-bounds access in ceph_handle_auth_reply() that can be triggered by a message of type CEPH_MSG_AUTH_REPLY. In ceph_handle_auth_reply(), the value of the payload_len field of such a message is stored in a variable of type int. A value greater than INT_MAX leads to an integer overflow and is interpreted as a negative value. This leads to decrementing the pointer address by this value and subsequently accessing it because ceph_decode_need() only checks that the memory access does not exceed the end address of the allocation. This patch fixes the issue by changing the data type of payload_len to u32. Additionally, the data type of result_msg_len is changed to u32, as it is also a variable holding a non-negative length. Also, an additional layer of sanity checks is introduced, ensuring that directly after reading it from the message, payload_len and result_msg_len are not greater than the overall segment length. BUG: KASAN: slab-out-of-bounds in ceph_handle_auth_reply+0x642/0x7a0 [libceph] Read of size 4 at addr ffff88811404df14 by task kworker/20:1/262 CPU: 20 UID: 0 PID: 262 Comm: kworker/20:1 Not tainted 6.19.2 #5 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: ceph-msgr ceph_con_workfn [libceph] Call Trace: dump_stack_lvl+0x76/0xa0 print_report+0xd1/0x620 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? kasan_complete_mode_report_info+0x72/0x210 kasan_report+0xe7/0x130 ? ceph_handle_auth_reply+0x642/0x7a0 [libceph] ? ceph_handle_auth_reply+0x642/0x7a0 [libceph] __asan_report_load_n_noabort+0xf/0x20 ceph_handle_auth_reply+0x642/0x7a0 [libceph] mon_dispatch+0x973/0x23d0 [libceph] ? apparmor_socket_recvmsg+0x6b/0xa0 ? __pfx_mon_dispatch+0x10/0x10 [libceph] ? __kasan_check_write+0x14/0x30i ? mutex_unlock+0x7f/0xd0 ? __pfx_mutex_unlock+0x10/0x10 ? __pfx_do_recvmsg+0x10/0x10 [libceph] ceph_con_process_message+0x1f1/0x650 [libceph] process_message+0x1e/0x450 [libceph] ceph_con_v2_try_read+0x2e48/0x6c80 [libceph] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [libceph] ? save_fpregs_to_fpstate+0xb0/0x230 ? raw_spin_rq_unlock+0x17/0xa0 ? finish_task_switch.isra.0+0x13b/0x760 ? __switch_to+0x385/0xda0 ? __kasan_check_write+0x14/0x30 ? mutex_lock+0x8d/0xe0 ? __pfx_mutex_lock+0x10/0x10 ceph_con_workfn+0x248/0x10c0 [libceph] process_one_work+0x629/0xf80 ? __kasan_check_write+0x14/0x30 worker_thread+0x87f/0x1570 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __pfx_try_to_wake_up+0x10/0x10 ? kasan_print_address_stack_frame+0x1f7/0x280 ? __pfx_worker_thread+0x10/0x10 kthread+0x396/0x830 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? __pfx_kthread+0x10/0x10 ? __kasan_check_write+0x14/0x30 ? recalc_sigpending+0x180/0x210 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3f7/0x610 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x385/0xda0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 [ idryomov: replace if statements with ceph_decode_need() for payload_len and result_msg_len ] Cc: stable@vger.kernel.org Signed-off-by: Raphael Zimmer Reviewed-by: Viacheslav Dubeyko Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 8be8911f590813e6f90bc6407ced1b23e50bc5da Author: Max Kellermann Date: Tue Feb 24 14:10:29 2026 +0100 ceph: add a bunch of missing ceph_path_info initializers commit 43323a5934b660afae687e8e4e95ac328615a5c4 upstream. ceph_mdsc_build_path() must be called with a zero-initialized ceph_path_info parameter, or else the following ceph_mdsc_free_path_info() may crash. Example crash (on Linux 6.18.12): virt_to_cache: Object is not a Slab page! WARNING: CPU: 184 PID: 2871736 at mm/slub.c:6732 kmem_cache_free+0x316/0x400 [...] Call Trace: [...] ceph_open+0x13d/0x3e0 do_dentry_open+0x134/0x480 vfs_open+0x2a/0xe0 path_openat+0x9a3/0x1160 [...] cache_from_obj: Wrong slab cache. names_cache but object is from ceph_inode_info WARNING: CPU: 184 PID: 2871736 at mm/slub.c:6746 kmem_cache_free+0x2dd/0x400 [...] kernel BUG at mm/slub.c:634! Oops: invalid opcode: 0000 [#1] SMP NOPTI RIP: 0010:__slab_free+0x1a4/0x350 Some of the ceph_mdsc_build_path() callers had initializers, but others had not, even though they were all added by commit 15f519e9f883 ("ceph: fix race condition validating r_parent before applying state"). The ones without initializer are suspectible to random crashes. (I can imagine it could even be possible to exploit this bug to elevate privileges.) Unfortunately, these Ceph functions are undocumented and its semantics can only be derived from the code. I see that ceph_mdsc_build_path() initializes the structure only on success, but not on error. Calling ceph_mdsc_free_path_info() after a failed ceph_mdsc_build_path() call does not even make sense, but that's what all callers do, and for it to be safe, the structure must be zero-initialized. The least intrusive approach to fix this is therefore to add initializers everywhere. Cc: stable@vger.kernel.org Fixes: 15f519e9f883 ("ceph: fix race condition validating r_parent before applying state") Signed-off-by: Max Kellermann Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit cae928e3178c75602c21d67e21255d73e7e9ed4f Author: Masami Hiramatsu (Google) Date: Fri Mar 13 23:14:14 2026 +0900 kprobes: avoid crash when rmmod/insmod after ftrace killed commit e113f0b46d19626ec15388bcb91432c9a4fd6261 upstream. After we hit ftrace is killed by some errors, the kernel crash if we remove modules in which kprobe probes. BUG: unable to handle page fault for address: fffffbfff805000d PGD 817fcc067 P4D 817fcc067 PUD 817fc8067 PMD 101555067 PTE 0 Oops: Oops: 0000 [#1] SMP KASAN PTI CPU: 4 UID: 0 PID: 2012 Comm: rmmod Tainted: G W OE Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE RIP: 0010:kprobes_module_callback+0x89/0x790 RSP: 0018:ffff88812e157d30 EFLAGS: 00010a02 RAX: 1ffffffff805000d RBX: dffffc0000000000 RCX: ffffffff86a8de90 RDX: ffffed1025c2af9b RSI: 0000000000000008 RDI: ffffffffc0280068 RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed1025c2af9a R10: ffff88812e157cd7 R11: 205d323130325420 R12: 0000000000000002 R13: ffffffffc0290488 R14: 0000000000000002 R15: ffffffffc0280040 FS: 00007fbc450dd740(0000) GS:ffff888420331000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffbfff805000d CR3: 000000010f624000 CR4: 00000000000006f0 Call Trace: notifier_call_chain+0xc6/0x280 blocking_notifier_call_chain+0x60/0x90 __do_sys_delete_module.constprop.0+0x32a/0x4e0 do_syscall_64+0x5d/0xfa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e This is because the kprobe on ftrace does not correctly handles the kprobe_ftrace_disabled flag set by ftrace_kill(). To prevent this error, check kprobe_ftrace_disabled in __disarm_kprobe_ftrace() and skip all ftrace related operations. Link: https://lore.kernel.org/all/176473947565.1727781.13110060700668331950.stgit@mhiramat.tok.corp.google.com/ Reported-by: Ye Bin Closes: https://lore.kernel.org/all/20251125020536.2484381-1-yebin@huaweicloud.com/ Fixes: ae6aa16fdc16 ("kprobes: introduce ftrace based optimization") Cc: stable@vger.kernel.org Signed-off-by: Masami Hiramatsu (Google) Acked-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 2754e7b3d64748643df867d1ea6fec522914b635 Author: Mehul Rao Date: Tue Mar 10 13:07:30 2026 -0400 tipc: fix divide-by-zero in tipc_sk_filter_connect() commit 6c5a9baa15de240e747263aba435a0951da8d8d2 upstream. A user can set conn_timeout to any value via setsockopt(TIPC_CONN_TIMEOUT), including values less than 4. When a SYN is rejected with TIPC_ERR_OVERLOAD and the retry path in tipc_sk_filter_connect() executes: delay %= (tsk->conn_timeout / 4); If conn_timeout is in the range [0, 3], the integer division yields 0, and the modulo operation triggers a divide-by-zero exception, causing a kernel oops/panic. Fix this by clamping conn_timeout to a minimum of 4 at the point of use in tipc_sk_filter_connect(). Oops: divide error: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 119 Comm: poc-F144 Not tainted 7.0.0-rc2+ RIP: 0010:tipc_sk_filter_rcv (net/tipc/socket.c:2236 net/tipc/socket.c:2362) Call Trace: tipc_sk_backlog_rcv (include/linux/instrumented.h:82 include/linux/atomic/atomic-instrumented.h:32 include/net/sock.h:2357 net/tipc/socket.c:2406) __release_sock (include/net/sock.h:1185 net/core/sock.c:3213) release_sock (net/core/sock.c:3797) tipc_connect (net/tipc/socket.c:2570) __sys_connect (include/linux/file.h:62 include/linux/file.h:83 net/socket.c:2098) Fixes: 6787927475e5 ("tipc: buffer overflow handling in listener socket") Cc: stable@vger.kernel.org Signed-off-by: Mehul Rao Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20260310170730.28841-1-mehulrao@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 22b05abb17e3c6ef45035141fe3d26f815ff9d30 Author: Ravi Hothi Date: Fri Feb 27 20:15:34 2026 +0530 ASoC: qcom: qdsp6: Fix q6apm remove ordering during ADSP stop and start commit d6db827b430bdcca3976cebca7bd69cca03cde2c upstream. During ADSP stop and start, the kernel crashes due to the order in which ASoC components are removed. On ADSP stop, the q6apm-audio .remove callback unloads topology and removes PCM runtimes during ASoC teardown. This deletes the RTDs that contain the q6apm DAI components before their removal pass runs, leaving those components still linked to the card and causing crashes on the next rebind. Fix this by ensuring that all dependent (child) components are removed first, and the q6apm component is removed last. [ 48.105720] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0 [ 48.114763] Mem abort info: [ 48.117650] ESR = 0x0000000096000004 [ 48.121526] EC = 0x25: DABT (current EL), IL = 32 bits [ 48.127010] SET = 0, FnV = 0 [ 48.130172] EA = 0, S1PTW = 0 [ 48.133415] FSC = 0x04: level 0 translation fault [ 48.138446] Data abort info: [ 48.141422] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 48.147079] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 48.152354] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 48.157859] user pgtable: 4k pages, 48-bit VAs, pgdp=00000001173cf000 [ 48.164517] [00000000000000d0] pgd=0000000000000000, p4d=0000000000000000 [ 48.171530] Internal error: Oops: 0000000096000004 [#1] SMP [ 48.177348] Modules linked in: q6prm_clocks q6apm_lpass_dais q6apm_dai snd_q6dsp_common q6prm snd_q6apm 8021q garp mrp stp llc snd_soc_hdmi_codec apr pdr_interface phy_qcom_edp fastrpc qcom_pd_mapper rpmsg_ctrl qrtr_smd rpmsg_char qcom_pdr_msg qcom_iris v4l2_mem2mem videobuf2_dma_contig ath11k_pci msm ubwc_config at24 ath11k videobuf2_memops mac80211 ocmem videobuf2_v4l2 libarc4 drm_gpuvm mhi qrtr videodev drm_exec snd_soc_sc8280xp gpu_sched videobuf2_common nvmem_qcom_spmi_sdam snd_soc_qcom_sdw drm_dp_aux_bus qcom_q6v5_pas qcom_spmi_temp_alarm snd_soc_qcom_common rtc_pm8xxx qcom_pon drm_display_helper cec qcom_pil_info qcom_stats soundwire_bus drm_client_lib mc dispcc0_sa8775p videocc_sa8775p qcom_q6v5 camcc_sa8775p snd_soc_dmic phy_qcom_sgmii_eth snd_soc_max98357a i2c_qcom_geni snd_soc_core dwmac_qcom_ethqos llcc_qcom icc_bwmon qcom_sysmon snd_compress qcom_refgen_regulator coresight_stm stmmac_platform snd_pcm_dmaengine qcom_common coresight_tmc stmmac coresight_replicator qcom_glink_smem coresight_cti stm_core [ 48.177444] coresight_funnel snd_pcm ufs_qcom phy_qcom_qmp_usb gpi phy_qcom_snps_femto_v2 coresight phy_qcom_qmp_ufs qcom_wdt gpucc_sa8775p pcs_xpcs mdt_loader qcom_ice icc_osm_l3 qmi_helpers snd_timer snd soundcore display_connector qcom_rng nvmem_reboot_mode drm_kms_helper phy_qcom_qmp_pcie sha256 cfg80211 rfkill socinfo fuse drm backlight ipv6 [ 48.301059] CPU: 2 UID: 0 PID: 293 Comm: kworker/u32:2 Not tainted 6.19.0-rc6-dirty #10 PREEMPT [ 48.310081] Hardware name: Qualcomm Technologies, Inc. Lemans EVK (DT) [ 48.316782] Workqueue: pdr_notifier_wq pdr_notifier_work [pdr_interface] [ 48.323672] pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 48.330825] pc : mutex_lock+0xc/0x54 [ 48.334514] lr : soc_dapm_shutdown_dapm+0x44/0x174 [snd_soc_core] [ 48.340794] sp : ffff800084ddb7b0 [ 48.344207] x29: ffff800084ddb7b0 x28: ffff00009cd9cf30 x27: ffff00009cd9cc00 [ 48.351544] x26: ffff000099610190 x25: ffffa31d2f19c810 x24: ffffa31d2f185098 [ 48.358869] x23: ffff800084ddb7f8 x22: 0000000000000000 x21: 00000000000000d0 [ 48.366198] x20: ffff00009ba6c338 x19: ffff00009ba6c338 x18: 00000000ffffffff [ 48.373528] x17: 000000040044ffff x16: ffffa31d4ae6dca8 x15: 072007740775076f [ 48.380853] x14: 0765076d07690774 x13: 00313a323a656369 x12: 767265733a637673 [ 48.388182] x11: 00000000000003f9 x10: ffffa31d4c7dea98 x9 : 0000000000000001 [ 48.395519] x8 : ffff00009a2aadc0 x7 : 0000000000000003 x6 : 0000000000000000 [ 48.402854] x5 : 0000000000000000 x4 : 0000000000000028 x3 : ffff000ef397a698 [ 48.410180] x2 : ffff00009a2aadc0 x1 : 0000000000000000 x0 : 00000000000000d0 [ 48.417506] Call trace: [ 48.420025] mutex_lock+0xc/0x54 (P) [ 48.423712] snd_soc_dapm_shutdown+0x44/0xbc [snd_soc_core] [ 48.429447] soc_cleanup_card_resources+0x30/0x2c0 [snd_soc_core] [ 48.435719] snd_soc_bind_card+0x4dc/0xcc0 [snd_soc_core] [ 48.441278] snd_soc_add_component+0x27c/0x2c8 [snd_soc_core] [ 48.447192] snd_soc_register_component+0x9c/0xf4 [snd_soc_core] [ 48.453371] devm_snd_soc_register_component+0x64/0xc4 [snd_soc_core] [ 48.459994] apm_probe+0xb4/0x110 [snd_q6apm] [ 48.464479] apr_device_probe+0x24/0x40 [apr] [ 48.468964] really_probe+0xbc/0x298 [ 48.472651] __driver_probe_device+0x78/0x12c [ 48.477132] driver_probe_device+0x40/0x160 [ 48.481435] __device_attach_driver+0xb8/0x134 [ 48.486011] bus_for_each_drv+0x80/0xdc [ 48.489964] __device_attach+0xa8/0x1b0 [ 48.493916] device_initial_probe+0x50/0x54 [ 48.498219] bus_probe_device+0x38/0xa0 [ 48.502170] device_add+0x590/0x760 [ 48.505761] device_register+0x20/0x30 [ 48.509623] of_register_apr_devices+0x1d8/0x318 [apr] [ 48.514905] apr_pd_status+0x2c/0x54 [apr] [ 48.519114] pdr_notifier_work+0x8c/0xe0 [pdr_interface] [ 48.524570] process_one_work+0x150/0x294 [ 48.528692] worker_thread+0x2d8/0x3d8 [ 48.532551] kthread+0x130/0x204 [ 48.535874] ret_from_fork+0x10/0x20 [ 48.539559] Code: d65f03c0 d5384102 d503201f d2800001 (c8e17c02) [ 48.545823] ---[ end trace 0000000000000000 ]--- Fixes: 5477518b8a0e ("ASoC: qdsp6: audioreach: add q6apm support") Cc: stable@vger.kernel.org Signed-off-by: Ravi Hothi Reviewed-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260227144534.278568-1-ravi.hothi@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 0e06cc511c61cff1591e5435a207759adcc76b6d Author: Penghe Geng Date: Thu Feb 19 15:29:54 2026 -0500 mmc: core: Avoid bitfield RMW for claim/retune flags commit 901084c51a0a8fb42a3f37d2e9c62083c495f824 upstream. Move claimed and retune control flags out of the bitfield word to avoid unrelated RMW side effects in asynchronous contexts. The host->claimed bit shared a word with retune flags. Writes to claimed in __mmc_claim_host() or retune_now in mmc_mq_queue_rq() can overwrite other bits when concurrent updates happen in other contexts, triggering spurious WARN_ON(!host->claimed). Convert claimed, can_retune, retune_now and retune_paused to bool to remove shared-word coupling. Fixes: 6c0cedd1ef952 ("mmc: core: Introduce host claiming by context") Fixes: 1e8e55b67030c ("mmc: block: Add CQE support") Cc: stable@vger.kernel.org Suggested-by: Adrian Hunter Signed-off-by: Penghe Geng Acked-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 45785772d538bba251cc46df31fade25364e9afc Author: Alexander Potapenko Date: Fri Feb 13 10:54:10 2026 +0100 mm/kfence: disable KFENCE upon KASAN HW tags enablement commit 09833d99db36d74456a4d13eb29c32d56ff8f2b6 upstream. KFENCE does not currently support KASAN hardware tags. As a result, the two features are incompatible when enabled simultaneously. Given that MTE provides deterministic protection and KFENCE is a sampling-based debugging tool, prioritize the stronger hardware protections. Disable KFENCE initialization and free the pre-allocated pool if KASAN hardware tags are detected to ensure the system maintains the security guarantees provided by MTE. Link: https://lkml.kernel.org/r/20260213095410.1862978-1-glider@google.com Fixes: 0ce20dd84089 ("mm: add Kernel Electric-Fence infrastructure") Signed-off-by: Alexander Potapenko Suggested-by: Marco Elver Reviewed-by: Marco Elver Cc: Andrey Konovalov Cc: Andrey Ryabinin Cc: Dmitry Vyukov Cc: Ernesto Martinez Garcia Cc: Greg KH Cc: Kees Cook Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 24743b77cae330ccf263d8c37e95a2c3ded51d14 Author: Felix Gu Date: Tue Jan 20 22:26:46 2026 +0800 mmc: mmci: Fix device_node reference leak in of_get_dml_pipe_index() commit af12e64ae0661546e8b4f5d30d55c5f53a11efe7 upstream. When calling of_parse_phandle_with_args(), the caller is responsible to call of_node_put() to release the reference of device node. In of_get_dml_pipe_index(), it does not release the reference. Fixes: 9cb15142d0e3 ("mmc: mmci: Add qcom dml support to the driver.") Signed-off-by: Felix Gu Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 63826cf08446861697eefbcbe2d1ee118348f5e3 Author: Alexander Potapenko Date: Fri Feb 20 15:49:40 2026 +0100 mm/kfence: fix KASAN hardware tag faults during late enablement commit d155aab90fffa00f93cea1f107aef0a3d548b2ff upstream. When KASAN hardware tags are enabled, re-enabling KFENCE late (via /sys/module/kfence/parameters/sample_interval) causes KASAN faults. This happens because the KFENCE pool and metadata are allocated via the page allocator, which tags the memory, while KFENCE continues to access it using untagged pointers during initialization. Use __GFP_SKIP_KASAN for late KFENCE pool and metadata allocations to ensure the memory remains untagged, consistent with early allocations from memblock. To support this, add __GFP_SKIP_KASAN to the allowlist in __alloc_contig_verify_gfp_mask(). Link: https://lkml.kernel.org/r/20260220144940.2779209-1-glider@google.com Fixes: 0ce20dd84089 ("mm: add Kernel Electric-Fence infrastructure") Signed-off-by: Alexander Potapenko Suggested-by: Ernesto Martinez Garcia Cc: Andrey Konovalov Cc: Andrey Ryabinin Cc: Dmitry Vyukov Cc: Greg KH Cc: Kees Cook Cc: Marco Elver Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 6dc0919dc78201aacac193c7a433c1ec99b8bbcb Author: Kalesh Singh Date: Thu Feb 19 15:36:56 2026 -0800 mm/tracing: rss_stat: ensure curr is false from kthread context commit 079c24d5690262e83ee476e2a548e416f3237511 upstream. The rss_stat trace event allows userspace tools, like Perfetto [1], to inspect per-process RSS metric changes over time. The curr field was introduced to rss_stat in commit e4dcad204d3a ("rss_stat: add support to detect RSS updates of external mm"). Its intent is to indicate whether the RSS update is for the mm_struct of the current execution context; and is set to false when operating on a remote mm_struct (e.g., via kswapd or a direct reclaimer). However, an issue arises when a kernel thread temporarily adopts a user process's mm_struct. Kernel threads do not have their own mm_struct and normally have current->mm set to NULL. To operate on user memory, they can "borrow" a memory context using kthread_use_mm(), which sets current->mm to the user process's mm. This can be observed, for example, in the USB Function Filesystem (FFS) driver. The ffs_user_copy_worker() handles AIO completions and uses kthread_use_mm() to copy data to a user-space buffer. If a page fault occurs during this copy, the fault handler executes in the kthread's context. At this point, current is the kthread, but current->mm points to the user process's mm. Since the rss_stat event (from the page fault) is for that same mm, the condition current->mm == mm becomes true, causing curr to be incorrectly set to true when the trace event is emitted. This is misleading because it suggests the mm belongs to the kthread, confusing userspace tools that track per-process RSS changes and corrupting their mm_id-to-process association. Fix this by ensuring curr is always false when the trace event is emitted from a kthread context by checking for the PF_KTHREAD flag. Link: https://lkml.kernel.org/r/20260219233708.1971199-1-kaleshsingh@google.com Link: https://perfetto.dev/ [1] Fixes: e4dcad204d3a ("rss_stat: add support to detect RSS updates of external mm") Signed-off-by: Kalesh Singh Acked-by: Zi Yan Acked-by: SeongJae Park Reviewed-by: Pedro Falcato Cc: "David Hildenbrand (Arm)" Cc: Joel Fernandes Cc: Lorenzo Stoakes Cc: Minchan Kim Cc: Steven Rostedt Cc: Suren Baghdasaryan Cc: [5.10+] Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit e584cb58a2ea7ff4d3a4bc43d5ca512ed3ecb77d Author: Kuen-Han Tsai Date: Mon Mar 9 20:04:52 2026 +0800 usb: gadget: f_ncm: Fix net_device lifecycle with device_move commit ec35c1969650e7cb6c8a91020e568ed46e3551b0 upstream. The network device outlived its parent gadget device during disconnection, resulting in dangling sysfs links and null pointer dereference problems. A prior attempt to solve this by removing SET_NETDEV_DEV entirely [1] was reverted due to power management ordering concerns and a NO-CARRIER regression. A subsequent attempt to defer net_device allocation to bind [2] broke 1:1 mapping between function instance and network device, making it impossible for configfs to report the resolved interface name. This results in a regression where the DHCP server fails on pmOS. Use device_move to reparent the net_device between the gadget device and /sys/devices/virtual/ across bind/unbind cycles. This preserves the network interface across USB reconnection, allowing the DHCP server to retain their binding. Introduce gether_attach_gadget()/gether_detach_gadget() helpers and use __free(detach_gadget) macro to undo attachment on bind failure. The bind_count ensures device_move executes only on the first bind. [1] https://lore.kernel.org/lkml/f2a4f9847617a0929d62025748384092e5f35cce.camel@crapouillou.net/ [2] https://lore.kernel.org/linux-usb/795ea759-7eaf-4f78-81f4-01ffbf2d7961@ixit.cz/ Fixes: 40d133d7f542 ("usb: gadget: f_ncm: convert to new function interface with backward compatibility") Cc: stable Signed-off-by: Kuen-Han Tsai Link: https://patch.msgid.link/20260309-f-ncm-revert-v2-7-ea2afbc7d9b2@google.com Signed-off-by: Greg Kroah-Hartman commit ef7d456d1e887f429943231daad12eec837e6509 Author: Kuen-Han Tsai Date: Mon Mar 9 20:04:51 2026 +0800 Revert "usb: gadget: u_ether: add gether_opts for config caching" commit 3131c1aff7cdffb96239f06f98e16188cbc2083f upstream. This reverts commit e065c6a7e46c2ee9c677fdbf50035323d2de1215. This commit is being reverted as part of a series-wide revert. By deferring the net_device allocation to the bind() phase, a single function instance will spawn multiple network devices if it is symlinked to multiple USB configurations. This causes regressions for userspace tools (like the postmarketOS DHCP daemon) that rely on reading the interface name (e.g., "usb0") from configfs. Currently, configfs returns the template "usb%d", causing the userspace network setup to fail. Crucially, because this patch breaks the 1:1 mapping between the function instance and the network device, this naming issue cannot simply be patched. Configfs only exposes a single 'ifname' attribute per instance, making it impossible to accurately report the actual interface name when multiple underlying network devices can exist for that single instance. All configurations tied to the same function instance are meant to share a single network device. Revert this change to restore the 1:1 mapping by allocating the network device at the instance level (alloc_inst). Reported-by: David Heidelberg Closes: https://lore.kernel.org/linux-usb/70b558ea-a12e-4170-9b8e-c951131249af@ixit.cz/ Fixes: 56a512a9b410 ("usb: gadget: f_ncm: align net_device lifecycle with bind/unbind") Cc: stable Signed-off-by: Kuen-Han Tsai Link: https://patch.msgid.link/20260309-f-ncm-revert-v2-6-ea2afbc7d9b2@google.com Signed-off-by: Greg Kroah-Hartman commit 05dc0c098ca1198cb3561ccc71421b7e64f49a74 Author: Kuen-Han Tsai Date: Mon Mar 9 20:04:48 2026 +0800 Revert "usb: gadget: f_ncm: align net_device lifecycle with bind/unbind" commit 37893bc5de2460c543ec1aa8250c37a305234054 upstream. This reverts commit 56a512a9b4107079f68701e7d55da8507eb963d9. This commit is being reverted as part of a series-wide revert. By deferring the net_device allocation to the bind() phase, a single function instance will spawn multiple network devices if it is symlinked to multiple USB configurations. This causes regressions for userspace tools (like the postmarketOS DHCP daemon) that rely on reading the interface name (e.g., "usb0") from configfs. Currently, configfs returns the template "usb%d", causing the userspace network setup to fail. Crucially, because this patch breaks the 1:1 mapping between the function instance and the network device, this naming issue cannot simply be patched. Configfs only exposes a single 'ifname' attribute per instance, making it impossible to accurately report the actual interface name when multiple underlying network devices can exist for that single instance. All configurations tied to the same function instance are meant to share a single network device. Revert this change to restore the 1:1 mapping by allocating the network device at the instance level (alloc_inst). Reported-by: David Heidelberg Closes: https://lore.kernel.org/linux-usb/70b558ea-a12e-4170-9b8e-c951131249af@ixit.cz/ Fixes: 56a512a9b410 ("usb: gadget: f_ncm: align net_device lifecycle with bind/unbind") Cc: stable Signed-off-by: Kuen-Han Tsai Link: https://patch.msgid.link/20260309-f-ncm-revert-v2-3-ea2afbc7d9b2@google.com Signed-off-by: Greg Kroah-Hartman commit d2a08ea03830ba2bf5a5379a480e50963cba99a6 Author: Kuen-Han Tsai Date: Mon Mar 9 20:04:49 2026 +0800 Revert "usb: gadget: u_ether: Add auto-cleanup helper for freeing net_device" commit 46662d3a1ad40282ba9f753cccc6f909ec4468cc upstream. This reverts commit 0c0981126b99288ed354d3d414c8a5fd42ac9e25. This commit is being reverted as part of a series-wide revert. By deferring the net_device allocation to the bind() phase, a single function instance will spawn multiple network devices if it is symlinked to multiple USB configurations. This causes regressions for userspace tools (like the postmarketOS DHCP daemon) that rely on reading the interface name (e.g., "usb0") from configfs. Currently, configfs returns the template "usb%d", causing the userspace network setup to fail. Crucially, because this patch breaks the 1:1 mapping between the function instance and the network device, this naming issue cannot simply be patched. Configfs only exposes a single 'ifname' attribute per instance, making it impossible to accurately report the actual interface name when multiple underlying network devices can exist for that single instance. All configurations tied to the same function instance are meant to share a single network device. Revert this change to restore the 1:1 mapping by allocating the network device at the instance level (alloc_inst). Reported-by: David Heidelberg Closes: https://lore.kernel.org/linux-usb/70b558ea-a12e-4170-9b8e-c951131249af@ixit.cz/ Fixes: 56a512a9b410 ("usb: gadget: f_ncm: align net_device lifecycle with bind/unbind") Cc: stable Signed-off-by: Kuen-Han Tsai Link: https://patch.msgid.link/20260309-f-ncm-revert-v2-4-ea2afbc7d9b2@google.com Signed-off-by: Greg Kroah-Hartman commit 56cb551d2a33d19bc2ad9a0a47c47143ebe547ff Author: Kuen-Han Tsai Date: Mon Mar 9 20:04:47 2026 +0800 Revert "usb: legacy: ncm: Fix NPE in gncm_bind" commit f2524c0e6ff0a5f72f1e1a32441c69d3b56430c4 upstream. This reverts commit fde0634ad9856b3943a2d1a8cc8de174a63ac840. This commit is being reverted as part of a series-wide revert. By deferring the net_device allocation to the bind() phase, a single function instance will spawn multiple network devices if it is symlinked to multiple USB configurations. This causes regressions for userspace tools (like the postmarketOS DHCP daemon) that rely on reading the interface name (e.g., "usb0") from configfs. Currently, configfs returns the template "usb%d", causing the userspace network setup to fail. Crucially, because this patch breaks the 1:1 mapping between the function instance and the network device, this naming issue cannot simply be patched. Configfs only exposes a single 'ifname' attribute per instance, making it impossible to accurately report the actual interface name when multiple underlying network devices can exist for that single instance. All configurations tied to the same function instance are meant to share a single network device. Revert this change to restore the 1:1 mapping by allocating the network device at the instance level (alloc_inst). Reported-by: David Heidelberg Closes: https://lore.kernel.org/linux-usb/70b558ea-a12e-4170-9b8e-c951131249af@ixit.cz/ Fixes: 56a512a9b410 ("usb: gadget: f_ncm: align net_device lifecycle with bind/unbind") Cc: stable Signed-off-by: Kuen-Han Tsai Link: https://patch.msgid.link/20260309-f-ncm-revert-v2-2-ea2afbc7d9b2@google.com Signed-off-by: Greg Kroah-Hartman commit 8a607bae3a0a41220e166e00bf71fda2c7cd7f96 Author: Kuen-Han Tsai Date: Mon Mar 9 20:04:46 2026 +0800 Revert "usb: gadget: f_ncm: Fix atomic context locking issue" commit 11199720fac2debbe718aec11e026ab3330dc80d upstream. This reverts commit 0d6c8144ca4d93253de952a5ea0028c19ed7ab68. This commit is being reverted as part of a series-wide revert. By deferring the net_device allocation to the bind() phase, a single function instance will spawn multiple network devices if it is symlinked to multiple USB configurations. This causes regressions for userspace tools (like the postmarketOS DHCP daemon) that rely on reading the interface name (e.g., "usb0") from configfs. Currently, configfs returns the template "usb%d", causing the userspace network setup to fail. Crucially, because this patch breaks the 1:1 mapping between the function instance and the network device, this naming issue cannot simply be patched. Configfs only exposes a single 'ifname' attribute per instance, making it impossible to accurately report the actual interface name when multiple underlying network devices can exist for that single instance. All configurations tied to the same function instance are meant to share a single network device. Revert this change to restore the 1:1 mapping by allocating the network device at the instance level (alloc_inst). Reported-by: David Heidelberg Closes: https://lore.kernel.org/linux-usb/70b558ea-a12e-4170-9b8e-c951131249af@ixit.cz/ Fixes: 56a512a9b410 ("usb: gadget: f_ncm: align net_device lifecycle with bind/unbind") Cc: stable Signed-off-by: Kuen-Han Tsai Link: https://patch.msgid.link/20260309-f-ncm-revert-v2-1-ea2afbc7d9b2@google.com Signed-off-by: Greg Kroah-Hartman commit be5738d19bed244ede84da45bc45395bcb1d99e0 Author: Kuen-Han Tsai Date: Sat Feb 21 22:48:15 2026 +0800 usb: legacy: ncm: Fix NPE in gncm_bind commit fde0634ad9856b3943a2d1a8cc8de174a63ac840 upstream. Commit 56a512a9b410 ("usb: gadget: f_ncm: align net_device lifecycle with bind/unbind") deferred the allocation of the net_device. This change leads to a NULL pointer dereference in the legacy NCM driver as it attempts to access the net_device before it's fully instantiated. Store the provided qmult, host_addr, and dev_addr into the struct ncm_opts->net_opts during gncm_bind(). These values will be properly applied to the net_device when it is allocated and configured later in the binding process by the NCM function driver. Fixes: 56a512a9b410 ("usb: gadget: f_ncm: align net_device lifecycle with bind/unbind") Cc: stable@kernel.org Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202602181727.fd76c561-lkp@intel.com Signed-off-by: Kuen-Han Tsai Link: https://patch.msgid.link/20260221-legacy-ncm-v2-1-dfb891d76507@google.com Signed-off-by: Greg Kroah-Hartman commit e533a44fb1b337d14f772585b67328bee2e0b5e3 Author: Kuen-Han Tsai Date: Sat Feb 21 22:48:16 2026 +0800 usb: gadget: f_ncm: Fix atomic context locking issue commit 0d6c8144ca4d93253de952a5ea0028c19ed7ab68 upstream. The ncm_set_alt function was holding a mutex to protect against races with configfs, which invokes the might-sleep function inside an atomic context. Remove the struct net_device pointer from the f_ncm_opts structure to eliminate the contention. The connection state is now managed by a new boolean flag to preserve the use-after-free fix from commit 6334b8e4553c ("usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error"). BUG: sleeping function called from invalid context Call Trace: dump_stack_lvl+0x83/0xc0 dump_stack+0x14/0x16 __might_resched+0x389/0x4c0 __might_sleep+0x8e/0x100 ... __mutex_lock+0x6f/0x1740 ... ncm_set_alt+0x209/0xa40 set_config+0x6b6/0xb40 composite_setup+0x734/0x2b40 ... Fixes: 56a512a9b410 ("usb: gadget: f_ncm: align net_device lifecycle with bind/unbind") Cc: stable@kernel.org Signed-off-by: Kuen-Han Tsai Link: https://patch.msgid.link/20260221-legacy-ncm-v2-2-dfb891d76507@google.com Signed-off-by: Greg Kroah-Hartman commit 679d9535aeb15c10bce89c44102004b96624d706 Author: Jiasheng Jiang Date: Thu Feb 19 02:38:34 2026 +0000 usb: gadget: f_tcm: Fix NULL pointer dereferences in nexus handling commit b9fde507355342a2d64225d582dc8b98ff5ecb19 upstream. The `tpg->tpg_nexus` pointer in the USB Target driver is dynamically managed and tied to userspace configuration via ConfigFS. It can be NULL if the USB host sends requests before the nexus is fully established or immediately after it is dropped. Currently, functions like `bot_submit_command()` and the data transfer paths retrieve `tv_nexus = tpg->tpg_nexus` and immediately dereference `tv_nexus->tvn_se_sess` without any validation. If a malicious or misconfigured USB host sends a BOT (Bulk-Only Transport) command during this race window, it triggers a NULL pointer dereference, leading to a kernel panic (local DoS). This exposes an inconsistent API usage within the module, as peer functions like `usbg_submit_command()` and `bot_send_bad_response()` correctly implement a NULL check for `tv_nexus` before proceeding. Fix this by bringing consistency to the nexus handling. Add the missing `if (!tv_nexus)` checks to the vulnerable BOT command and request processing paths, aborting the command gracefully with an error instead of crashing the system. Fixes: c52661d60f63 ("usb-gadget: Initial merge of target module for UASP + BOT") Cc: stable Signed-off-by: Jiasheng Jiang Reviewed-by: Thinh Nguyen Link: https://patch.msgid.link/20260219023834.17976-1-jiashengjiangcool@gmail.com Signed-off-by: Greg Kroah-Hartman commit b7fed917f84e484e06c5e9926746d0b524e3a93e Author: Ziyi Guo Date: Mon Feb 9 15:19:37 2026 +0000 usb: image: mdc800: kill download URB on timeout commit 1be3b77de4eb89af8ae2fd6610546be778e25589 upstream. mdc800_device_read() submits download_urb and waits for completion. If the timeout fires and the device has not responded, the function returns without killing the URB, leaving it active. A subsequent read() resubmits the same URB while it is still in-flight, triggering the WARN in usb_submit_urb(): "URB submitted while active" Check the return value of wait_event_timeout() and kill the URB if it indicates timeout, ensuring the URB is complete before its status is inspected or the URB is resubmitted. Similar to - commit 372c93131998 ("USB: yurex: fix control-URB timeout handling") - commit b98d5000c505 ("media: rc: iguanair: handle timeouts") Signed-off-by: Ziyi Guo Cc: stable Link: https://patch.msgid.link/20260209151937.2247202-1-n7l8m4@u.northwestern.edu Signed-off-by: Greg Kroah-Hartman commit 513041c71356d46372bbdecfe84be06f63c90b28 Author: Junzhong Pan Date: Fri Mar 6 11:30:09 2026 +0800 usb: gadget: uvc: fix interval_duration calculation commit 56135c0c60b07729401af9d329fa9c0eded845a6 upstream. To correctly convert bInterval as interval_duration: interval_duration = 2^(bInterval-1) * frame_interval Current code uses a wrong left shift operand, computing 2^bInterval instead of 2^(bInterval-1). Fixes: 010dc57cb516 ("usb: gadget: uvc: fix interval_duration calculation") Cc: stable Signed-off-by: Junzhong Pan Reviewed-by: Xu Yang Link: https://patch.msgid.link/20260306-fix-uvc-interval-v1-1-9a2df6859859@linux.spacemit.com Signed-off-by: Greg Kroah-Hartman commit 4cc30a5fc883287d312134f01b80ab231c01c77c Author: Oliver Neukum Date: Mon Feb 9 15:20:48 2026 +0100 usb: mdc800: handle signal and read racing commit 2d6d260e9a3576256fe9ef6d1f7930c9ec348723 upstream. If a signal arrives after a read has partially completed, we need to return the number of bytes read. -EINTR is correct only if that number is zero. Signed-off-by: Oliver Neukum Cc: stable Link: https://patch.msgid.link/20260209142048.1503791-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit c0b28a042174c22dc5571ff5de54cce736f853dc Author: John Keeping Date: Fri Feb 27 11:15:39 2026 +0000 usb: gadget: f_hid: fix SuperSpeed descriptors commit 7f58b4148ef5d8ee0fb7d8113dcc38ff5374babc upstream. When adding dynamic configuration for bInterval, the value was removed from the static SuperSpeed endpoint descriptors but was not set from the configured value in hidg_bind(). Thus at SuperSpeed the interrupt endpoints have bInterval as zero which is not valid per the USB specification. Add the missing setting for SuperSpeed endpoints. Fixes: ea34925f5b2ee ("usb: gadget: hid: allow dynamic interval configuration via configfs") Cc: stable Signed-off-by: John Keeping Acked-by: Peter Korsgaard Link: https://patch.msgid.link/20260227111540.431521-1-jkeeping@inmusicbrands.com Signed-off-by: Greg Kroah-Hartman commit 0b7d11fd6e742ecc0b1eca44b4f0b93140c74bae Author: Fan Wu Date: Tue Mar 3 07:33:44 2026 +0000 usb: renesas_usbhs: fix use-after-free in ISR during device removal commit 3cbc242b88c607f55da3d0d0d336b49bf1e20412 upstream. In usbhs_remove(), the driver frees resources (including the pipe array) while the interrupt handler (usbhs_interrupt) is still registered. If an interrupt fires after usbhs_pipe_remove() but before the driver is fully unbound, the ISR may access freed memory, causing a use-after-free. Fix this by calling devm_free_irq() before freeing resources. This ensures the interrupt handler is both disabled and synchronized (waits for any running ISR to complete) before usbhs_pipe_remove() is called. Fixes: f1407d5c6624 ("usb: renesas_usbhs: Add Renesas USBHS common code") Cc: stable Suggested-by: Alan Stern Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260303073344.34577-1-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit 67ed312124bb1b61858778ac0b985b48961c862a Author: Oliver Neukum Date: Wed Mar 4 14:01:12 2026 +0100 usb: class: cdc-wdm: fix reordering issue in read code path commit 8df672bfe3ec2268c2636584202755898e547173 upstream. Quoting the bug report: Due to compiler optimization or CPU out-of-order execution, the desc->length update can be reordered before the memmove. If this happens, wdm_read() can see the new length and call copy_to_user() on uninitialized memory. This also violates LKMM data race rules [1]. Fix it by using WRITE_ONCE and memory barriers. Fixes: afba937e540c9 ("USB: CDC WDM driver") Cc: stable Signed-off-by: Oliver Neukum Closes: https://lore.kernel.org/linux-usb/CALbr=LbrUZn_cfp7CfR-7Z5wDTHF96qeuM=3fO2m-q4cDrnC4A@mail.gmail.com/ Reported-by: Gui-Dong Han Reviewed-by: Gui-Dong Han Link: https://patch.msgid.link/20260304130116.1721682-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit 64f3d75633aedc12bdff220e9a4337177430bd9d Author: Alan Stern Date: Tue Feb 17 22:10:32 2026 -0500 USB: core: Limit the length of unkillable synchronous timeouts commit 1015c27a5e1a63efae2b18a9901494474b4d1dc3 upstream. The usb_control_msg(), usb_bulk_msg(), and usb_interrupt_msg() APIs in usbcore allow unlimited timeout durations. And since they use uninterruptible waits, this leaves open the possibility of hanging a task for an indefinitely long time, with no way to kill it short of unplugging the target device. To prevent this sort of problem, enforce a maximum limit on the length of these unkillable timeouts. The limit chosen here, somewhat arbitrarily, is 60 seconds. On many systems (although not all) this is short enough to avoid triggering the kernel's hung-task detector. In addition, clear up the ambiguity of negative timeout values by treating them the same as 0, i.e., using the maximum allowed timeout. Signed-off-by: Alan Stern Link: https://lore.kernel.org/linux-usb/3acfe838-6334-4f6d-be7c-4bb01704b33d@rowland.harvard.edu/ Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") CC: stable@vger.kernel.org Link: https://patch.msgid.link/15fc9773-a007-47b0-a703-df89a8cf83dd@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman commit 6cb7dc91f057dd8ce44f6caa2995d8e22784ed0a Author: Alan Stern Date: Tue Feb 17 22:09:22 2026 -0500 USB: usbtmc: Use usb_bulk_msg_killable() with user-specified timeouts commit 7784caa413a89487dd14dd5c41db8753483b2acb upstream. The usbtmc driver accepts timeout values specified by the user in an ioctl command, and uses these timeouts for some usb_bulk_msg() calls. Since the user can specify arbitrarily long timeouts and usb_bulk_msg() uses unkillable waits, call usb_bulk_msg_killable() instead to avoid the possibility of the user hanging a kernel thread indefinitely. Reported-by: syzbot+25ba18e2c5040447585d@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/8e1c7ac5-e076-44b0-84b8-1b34b20f0ae1@suse.com/T/#t Tested-by: syzbot+25ba18e2c5040447585d@syzkaller.appspotmail.com Signed-off-by: Alan Stern Fixes: 048c6d88a021 ("usb: usbtmc: Add ioctls to set/get usb timeout") CC: stable@vger.kernel.org Link: https://patch.msgid.link/81c6fc24-0607-40f1-8c20-5270dab2fad5@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman commit f7e115af48745808d1ffc21d3569078c3c163e34 Author: Alan Stern Date: Tue Feb 17 22:07:47 2026 -0500 USB: usbcore: Introduce usb_bulk_msg_killable() commit 416909962e7cdf29fd01ac523c953f37708df93d upstream. The synchronous message API in usbcore (usb_control_msg(), usb_bulk_msg(), and so on) uses uninterruptible waits. However, drivers may call these routines in the context of a user thread, which means it ought to be possible to at least kill them. For this reason, introduce a new usb_bulk_msg_killable() function which behaves the same as usb_bulk_msg() except for using wait_for_completion_killable_timeout() instead of wait_for_completion_timeout(). The same can be done later for usb_control_msg() later on, if it turns out to be needed. Signed-off-by: Alan Stern Suggested-by: Oliver Neukum Link: https://lore.kernel.org/linux-usb/3acfe838-6334-4f6d-be7c-4bb01704b33d@rowland.harvard.edu/ Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") CC: stable@vger.kernel.org Link: https://patch.msgid.link/248628b4-cc83-4e81-a620-3ce4e0376d41@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman commit ac207d57bbb0671a9e79c6956b4af1fe6103acc8 Author: RD Babiera Date: Tue Mar 10 20:41:05 2026 +0000 usb: typec: altmode/displayport: set displayport signaling rate in configure message commit e8557acfa079a54b59a21f447c82a31aec7717df upstream. dp_altmode_configure sets the signaling rate to the current configuration's rate and then shifts the value to the Select Configuration bitfield. On the initial configuration, dp->data.conf is 0 to begin with, so the signaling rate field is never set, which leads to some DisplayPort Alt Mode partners sending NAK to the Configure message. Set the signaling rate to the capabilities supported by both the port and the port partner. If the cable supports DisplayPort Alt Mode, then include its capabilities as well. Fixes: a17fae8fc38e ("usb: typec: Add Displayport Alternate Mode 2.1 Support") Cc: stable Signed-off-by: RD Babiera Acked-by: Heikki Krogerus Link: https://patch.msgid.link/20260310204106.3939862-2-rdbabiera@google.com Signed-off-by: Greg Kroah-Hartman commit 8c9521a5877e5871d7f09f4f2ab5ddd6e9e6648c Author: Xu Yang Date: Mon Mar 9 15:43:13 2026 +0800 usb: roles: get usb role switch from parent only for usb-b-connector commit 8345b1539faa49fcf9c9439c3cbd97dac6eca171 upstream. usb_role_switch_is_parent() was walking up to the parent node and checking for the "usb-role-switch" property regardless of the type of the passed fwnode. This could cause unrelated device nodes to be probed as potential role switch parent, leading to spurious matches and "-EPROBE_DEFER" being returned infinitely. Till now only Type-B connector node will have a parent node which may present "usb-role-switch" property and register the role switch device. For Type-C connector node, its parent node will always be a Type-C chip device which will never register the role switch device. However, it may still present a non-boolean "usb-role-switch = <&usb_controller>" property for historical compatibility. So restrict the helper to only operate on Type-B connector when attempting to get the role switch from parent node. Fixes: 6fadd72943b8 ("usb: roles: get usb-role-switch from parent") Cc: stable Signed-off-by: Xu Yang Tested-by: Arnaud Ferraris Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260309074313.2809867-3-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman commit 9459b5731cd8b68b04c91316f71c2377162bfb2b Author: Marc Zyngier Date: Sun Mar 1 12:44:40 2026 +0000 usb: cdc-acm: Restore CAP_BRK functionnality to CH343 commit 14ae24cba291bddfdc296bbcbfd00cd09d0498ef upstream. The CH343 USB/serial adapter is as buggy as it is popular (very). One of its quirks is that despite being capable of signalling a BREAK condition, it doesn't advertise it. This used to work nonetheless until 66aad7d8d3ec5 ("usb: cdc-acm: return correct error code on unsupported break") applied some reasonable restrictions, preventing breaks from being emitted on devices that do not advertise CAP_BRK. Add a quirk for this particular device, so that breaks can still be produced on some of my machines attached to my console server. Fixes: 66aad7d8d3ec5 ("usb: cdc-acm: return correct error code on unsupported break") Signed-off-by: Marc Zyngier Cc: stable Cc: Oliver Neukum Cc: Greg Kroah-Hartman Acked-by: Oliver Neukum Link: https://patch.msgid.link/20260301124440.1192752-1-maz@kernel.org Signed-off-by: Greg Kroah-Hartman commit 82f7b4350b9d959e6e17b6de7124b41aaa90edad Author: Gabor Juhos Date: Wed Feb 18 21:21:07 2026 +0100 usb: core: don't power off roothub PHYs if phy_set_mode() fails commit e293015ba76eb96ce4ebed7e3b2cb1a7d319f3e9 upstream. Remove the error path from the usb_phy_roothub_set_mode() function. The code is clearly wrong, because phy_set_mode() calls can't be balanced with phy_power_off() calls. Additionally, the usb_phy_roothub_set_mode() function is called only from usb_add_hcd() before it powers on the PHYs, so powering off those makes no sense anyway. Presumably, the code is copy-pasted from the phy_power_on() function without adjusting the error handling. Cc: stable@vger.kernel.org # v5.1+ Fixes: b97a31348379 ("usb: core: comply to PHY framework") Signed-off-by: Gabor Juhos Reviewed-by: Miquel Raynal Link: https://patch.msgid.link/20260218-usb-phy-poweroff-fix-v1-1-66e6831e860e@gmail.com Signed-off-by: Greg Kroah-Hartman commit 1a99da68a5a9c29054ee050bd4094c3fc928b5b8 Author: Greg Kroah-Hartman Date: Mon Feb 23 13:19:43 2026 +0100 usb: misc: uss720: properly clean up reference in uss720_probe() commit 45dba8011efac11a2f360383221b541f5ea53ce5 upstream. If get_1284_register() fails, the usb device reference count is incorrect and needs to be properly dropped before returning. That will happen when the kref is dropped in the call to destroy_priv(), so jump to that error path instead of returning directly. Cc: stable Assisted-by: gkh_clanker_2000 Link: https://patch.msgid.link/2026022342-smokiness-stove-d792@gregkh Signed-off-by: Greg Kroah-Hartman commit 69f090f5e7298fd0689aa2785ff3e1958565f350 Author: Heikki Krogerus Date: Mon Mar 9 14:02:04 2026 +0100 usb: dwc3: pci: add support for the Intel Nova Lake -H commit 17ab4d4078e22be7fd8fd6fc710c15c085a4cb1b upstream. This patch adds the necessary PCI ID for Intel Nova Lake -H devices. Signed-off-by: Heikki Krogerus Cc: stable Acked-by: Thinh Nguyen Link: https://patch.msgid.link/20260309130204.208661-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit a41d3d9202e951995cfac6248c565423079c71fa Author: Oliver Neukum Date: Mon Feb 9 15:37:20 2026 +0100 usb: yurex: fix race in probe commit 7a875c09899ba0404844abfd8f0d54cdc481c151 upstream. The bbu member of the descriptor must be set to the value standing for uninitialized values before the URB whose completion handler sets bbu is submitted. Otherwise there is a window during which probing can overwrite already retrieved data. Cc: stable Signed-off-by: Oliver Neukum Link: https://patch.msgid.link/20260209143720.1507500-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit cd41e0d1df8fcf5eae294657da52b50d1ce03246 Author: Dayu Jiang Date: Thu Mar 5 00:36:38 2026 +0200 usb: xhci: Prevent interrupt storm on host controller error (HCE) commit d6d5febd12452b7fd951fdd15c3ec262f01901a4 upstream. The xHCI controller reports a Host Controller Error (HCE) in UAS Storage Device plug/unplug scenarios on Android devices. HCE is checked in xhci_irq() function and causes an interrupt storm (since the interrupt isn’t cleared), leading to severe system-level faults. When the xHC controller reports HCE in the interrupt handler, the driver only logs a warning and assumes xHC activity will stop as stated in xHCI specification. An interrupt storm does however continue on some hosts even after HCE, and only ceases after manually disabling xHC interrupt and stopping the controller by calling xhci_halt(). Add xhci_halt() to xhci_irq() function where STS_HCE status is checked, mirroring the existing error handling pattern used for STS_FATAL errors. This only fixes the interrupt storm. Proper HCE recovery requires resetting and re-initializing the xHC. CC: stable@vger.kernel.org Signed-off-by: Dayu Jiang Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20260304223639.3882398-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit c65f1b840ab8ce72ba68f1b63bab7960f8fdfa89 Author: Zilin Guan Date: Thu Mar 5 00:36:37 2026 +0200 usb: xhci: Fix memory leak in xhci_disable_slot() commit c1c8550e70401159184130a1afc6261db01fc0ce upstream. xhci_alloc_command() allocates a command structure and, when the second argument is true, also allocates a completion structure. Currently, the error handling path in xhci_disable_slot() only frees the command structure using kfree(), causing the completion structure to leak. Use xhci_free_command() instead of kfree(). xhci_free_command() correctly frees both the command structure and the associated completion structure. Since the command structure is allocated with zero-initialization, command->in_ctx is NULL and will not be erroneously freed by xhci_free_command(). This bug was found using an experimental static analysis tool we are developing. 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, but we plan to open-source it after our research is published. The bug was originally detected on v6.13-rc1 using our static analysis tool, and we have verified that the issue persists in the latest mainline kernel. We performed build testing on x86_64 with allyesconfig using GCC=11.4.0. Since triggering these error paths in xhci_disable_slot() requires specific hardware conditions or abnormal state, we were unable to construct a test case to reliably trigger these specific error paths at runtime. Fixes: 7faac1953ed1 ("xhci: avoid race between disable slot command and host runtime suspend") CC: stable@vger.kernel.org Signed-off-by: Zilin Guan Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20260304223639.3882398-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 8043f1c3c89dd6f492053544d29c45a1cb2c3498 Author: Vyacheslav Vahnenko Date: Fri Mar 13 15:36:38 2026 +0300 USB: ezcap401 needs USB_QUIRK_NO_BOS to function on 10gbs usb speed commit d0d9b1f4f5391e6a00cee81d73ed2e8f98446d5f upstream. Add USB_QUIRK_NO_BOS for ezcap401 capture card, without it dmesg will show "unable to get BOS descriptor or descriptor too short" and "unable to read config index 0 descriptor/start: -71" errors and device will not able to work at full speed at 10gbs Signed-off-by: Vyacheslav Vahnenko Cc: stable Link: https://patch.msgid.link/20260313123638.20481-1-vahnenko2003@gmail.com Signed-off-by: Greg Kroah-Hartman commit ba3b951b7f7ae94c1bd0bc63135d4bd7e3ca31d1 Author: Christoffer Sandberg Date: Fri Mar 6 18:28:14 2026 +0100 usb/core/quirks: Add Huawei ME906S-device to wakeup quirk commit 0326ff28d56b4fa202de36ffc8462a354f383a64 upstream. Similar to other Huawei LTE modules using this quirk, this version with another vid/pid suffers from spurious wakeups. Setting the quirk fixes the issue for this device as well. Cc: stable Signed-off-by: Christoffer Sandberg Signed-off-by: Werner Sembach Link: https://patch.msgid.link/20260306172817.2098898-1-wse@tuxedocomputers.com Signed-off-by: Greg Kroah-Hartman commit e2554ffa8c2528ba6d163ea0d3d1083e78278ba6 Author: A1RM4X Date: Wed Feb 4 14:26:48 2026 -0500 USB: add QUIRK_NO_BOS for video capture several devices commit 93cd0d664661f58f7e7bed7373714ab2ace41734 upstream. Several USB capture devices also need the USB_QUIRK_NO_BOS set for them to work properly, odds are they are all the same chip inside, just different vendor/product ids. This fixes up: - ASUS TUF 4K PRO - Avermedia Live Gamer Ultra 2.1 (GC553G2) - UGREEN 35871 to now run at full speed (10 Gbps/4K 60 fps mode.) Link: https://lore.kernel.org/r/CACy+XB-f-51xGpNQFCSm5pE_momTQLu=BaZggHYU1DiDmFX=ug@mail.gmail.com Cc: stable Signed-off-by: A1RM4X Signed-off-by: Greg Kroah-Hartman commit 213e82ccdea58fa978ccd6a3e1fbb7292bfec046 Author: Marc Zyngier Date: Thu Mar 5 13:27:51 2026 +0000 KVM: arm64: pkvm: Fallback to level-3 mapping on host stage-2 fault commit 8531d5a83d8eb8affb5c0249b466c28d94192603 upstream. If, for any odd reason, we cannot converge to mapping size that is completely contained in a memblock region, we fail to install a S2 mapping and go back to the faulting instruction. Rince, repeat. This happens when faulting in regions that are smaller than a page or that do not have PAGE_SIZE-aligned boundaries (as witnessed on an O6 board that refuses to boot in protected mode). In this situation, fallback to using a PAGE_SIZE mapping anyway -- it isn't like we can go any lower. Fixes: e728e705802fe ("KVM: arm64: Adjust range correctly during host stage-2 faults") Link: https://lore.kernel.org/r/86wlzr77cn.wl-maz@kernel.org Cc: stable@vger.kernel.org Cc: Quentin Perret Reviewed-by: Quentin Perret Link: https://patch.msgid.link/20260305132751.2928138-1-maz@kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit c513bbd7da534f964d975086394cb3d65a34e574 Author: Sean Christopherson Date: Tue Feb 3 11:07:09 2026 -0800 KVM: SVM: Initialize AVIC VMCB fields if AVIC is enabled with in-kernel APIC commit 3989a6d036c8ec82c0de3614bed23a1dacd45de5 upstream. Initialize all per-vCPU AVIC control fields in the VMCB if AVIC is enabled in KVM and the VM has an in-kernel local APIC, i.e. if it's _possible_ the vCPU could activate AVIC at any point in its lifecycle. Configuring the VMCB if and only if AVIC is active "works" purely because of optimizations in kvm_create_lapic() to speculatively set apicv_active if AVIC is enabled *and* to defer updates until the first KVM_RUN. In quotes because KVM likely won't do the right thing if kvm_apicv_activated() is false, i.e. if a vCPU is created while APICv is inhibited at the VM level for whatever reason. E.g. if the inhibit is *removed* before KVM_REQ_APICV_UPDATE is handled in KVM_RUN, then __kvm_vcpu_update_apicv() will elide calls to vendor code due to seeing "apicv_active == activate". Cleaning up the initialization code will also allow fixing a bug where KVM incorrectly leaves CR8 interception enabled when AVIC is activated without creating a mess with respect to whether AVIC is activated or not. Cc: stable@vger.kernel.org Fixes: 67034bb9dd5e ("KVM: SVM: Add irqchip_split() checks before enabling AVIC") Fixes: 6c3e4422dd20 ("svm: Add support for dynamic APICv") Reviewed-by: Naveen N Rao (AMD) Reviewed-by: Jim Mattson Link: https://patch.msgid.link/20260203190711.458413-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit b058c30cdf7d5921a67b35da9cbc3944f7c5bb8a Author: Jim Mattson Date: Thu Feb 5 15:15:26 2026 -0800 KVM: x86: Introduce KVM_X86_QUIRK_VMCS12_ALLOW_FREEZE_IN_SMM commit e2ffe85b6d2bb7780174b87aa4468a39be17eb81 upstream. Add KVM_X86_QUIRK_VMCS12_ALLOW_FREEZE_IN_SMM to allow L1 to set FREEZE_IN_SMM in vmcs12's GUEST_IA32_DEBUGCTL field, as permitted prior to commit 6b1dd26544d0 ("KVM: VMX: Preserve host's DEBUGCTLMSR_FREEZE_IN_SMM while running the guest"). Enable the quirk by default for backwards compatibility (like all quirks); userspace can disable it via KVM_CAP_DISABLE_QUIRKS2 for consistency with the constraints on WRMSR(IA32_DEBUGCTL). Note that the quirk only bypasses the consistency check. The vmcs02 bit is still owned by the host, and PMCs are not frozen during virtualized SMM. In particular, if a host administrator decides that PMCs should not be frozen during physical SMM, then L1 has no say in the matter. Fixes: 095686e6fcb4 ("KVM: nVMX: Check vmcs12->guest_ia32_debugctl on nested VM-Enter") Cc: stable@vger.kernel.org Signed-off-by: Jim Mattson Link: https://patch.msgid.link/20260205231537.1278753-1-jmattson@google.com [sean: tag for stable@, clean-up and fix goofs in the comment and docs] Signed-off-by: Sean Christopherson [Rename quirk. - Paolo] Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 686c8f16112c832e3bdbb000646e50c6b88da0c5 Author: Marc Zyngier Date: Sun Feb 22 13:35:13 2026 +0000 KVM: arm64: Fix protected mode handling of pages larger than 4kB commit 08f97454b7fa39bfcf82524955c771d2d693d6fe upstream. Since 3669ddd8fa8b5 ("KVM: arm64: Add a range to pkvm_mappings"), pKVM tracks the memory that has been mapped into a guest in a side data structure. Crucially, it uses it to find out whether a page has already been mapped, and therefore refuses to map it twice. So far, so good. However, this very patch completely breaks non-4kB page support, with guests being unable to boot. The most obvious symptom is that we take the same fault repeatedly, and not making forward progress. A quick investigation shows that this is because of the above rejection code. As it turns out, there are multiple issues at play: - while the HPFAR_EL2 register gives you the faulting IPA minus the bottom 12 bits, it will still give you the extra bits that are part of the page offset for anything larger than 4kB, even for a level-3 mapping - pkvm_pgtable_stage2_map() assumes that the address passed as a parameter is aligned to the size of the intended mapping - the faulting address is only aligned for a non-page mapping When the planets are suitably aligned (pun intended), the guest faults on a page by accessing it past the bottom 4kB, and extra bits get set in the HPFAR_EL2 register. If this results in a page mapping (which is likely with large granule sizes), nothing aligns it further down, and pkvm_mapping_iter_first() finds an intersection that doesn't really exist. We assume this is a spurious fault and return -EAGAIN. And again... This doesn't hit outside of the protected code, as the page table code always aligns the IPA down to a page boundary, hiding the issue for everyone else. Fix it by always forcing the alignment on vma_pagesize, irrespective of the value of vma_pagesize. Fixes: 3669ddd8fa8b5 ("KVM: arm64: Add a range to pkvm_mappings") Reviewed-by: Fuad Tabba Tested-by: Fuad Tabba Signed-off-by: Marc Zyngier Link: https://https://patch.msgid.link/20260222141000.3084258-1-maz@kernel.org Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e0f582406c3e4bed39b68c0800805faa4b448467 Author: Zhang Heng Date: Wed Mar 4 14:32:55 2026 +0800 ASoC: amd: yc: Add DMI quirk for ASUS EXPERTBOOK PM1503CDA commit 325291b20f8a6f14b9c82edbf5d12e4e71f6adaa upstream. Add a DMI quirk for the ASUS EXPERTBOOK PM1503CDA fixing the issue where the internal microphone was not detected. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221070 Cc: stable@vger.kernel.org Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260304063255.139331-1-zhangheng@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 08da6c7ed70f0c0fe4c216a32c65294f598be992 Author: Pedro Falcato Date: Thu Mar 5 14:53:12 2026 +0000 ata: libata-core: Add BRIDGE_OK quirk for QEMU drives commit b92b0075ee1870f78f59ab1f7da7dbfdd718ad7a upstream. Currently, whenever you boot with a QEMU drive over an AHCI interface, you get: [ 1.632121] ata1.00: applying bridge limits This happens due to the kernel not believing the given drive is SATA, since word 93 of IDENTIFY (ATA_ID_HW_CONFIG) is non-zero. The result is a pretty severe limit in max_hw_sectors_kb, which limits our IO sizes. QEMU has set word 93 erroneously for SATA drives but does not, in any way, emulate any of these real hardware details. There is no PATA drive and no SATA cable. As such, add a BRIDGE_OK quirk for QEMU HARDDISK. Special care is taken to limit this quirk to "2.5+", to allow for fixed future versions. This results in the max_hw_sectors being limited solely by the controller interface's limits. Which, for AHCI controllers, takes it from 128KB to 32767KB. Cc: stable@vger.kernel.org Signed-off-by: Pedro Falcato Reviewed-by: Damien Le Moal Reviewed-by: Hannes Reinecke Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit f90768ed813bf7aa20836f3722086caa1f04ae23 Author: Alexandre Courbot Date: Tue Feb 24 11:25:34 2026 +0900 rust: str: make NullTerminatedFormatter public commit 3ac88a9948792b092a4b11323e2abd1ecbe0cc68 upstream. If `CONFIG_BLOCK` is disabled, the following warnings are displayed during build: warning: struct `NullTerminatedFormatter` is never constructed --> ../rust/kernel/str.rs:667:19 | 667 | pub(crate) struct NullTerminatedFormatter<'a> { | ^^^^^^^^^^^^^^^^^^^^^^^ | = note: `#[warn(dead_code)]` (part of `#[warn(unused)]`) on by default warning: associated function `new` is never used --> ../rust/kernel/str.rs:673:19 | 671 | impl<'a> NullTerminatedFormatter<'a> { | ------------------------------------ associated function in this implementation 672 | /// Create a new [`Self`] instance. 673 | pub(crate) fn new(buffer: &'a mut [u8]) -> Option> { Fix them by making `NullTerminatedFormatter` public, as it could be useful for drivers anyway. Fixes: cdde7a1951ff ("rust: str: introduce `NullTerminatedFormatter`") Signed-off-by: Alexandre Courbot Reviewed-by: Alice Ryhl Reviewed-by: Andreas Hindborg Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260224-nullterminatedformatter-v1-1-5bef7b9b3d4c@nvidia.com Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 887098159d70559b537fa3333b1ff8c747f91748 Author: Miguel Ojeda Date: Thu Mar 12 12:10:14 2026 +0100 rust: kbuild: allow `unused_features` commit 592c61f3bfceaa29f8275696bd67c3dfad7ef72e upstream. Starting with the upcoming Rust 1.96.0 (to be released 2026-05-28), `rustc` introduces the new lint `unused_features` [1], which warns [2]: warning: feature `used_with_arg` is declared but not used --> :1:93 | 1 | #![feature(asm_const,asm_goto,arbitrary_self_types,lint_reasons,offset_of_nested,raw_ref_op,used_with_arg)] | ^^^^^^^^^^^^^ | = note: `#[warn(unused_features)]` (part of `#[warn(unused)]`) on by default The original goal of using `-Zcrate-attr` automatically was that there is a consistent set of features enabled and managed globally for all Rust kernel code (modulo exceptions like the `rust/` crated). While we could require crates to enable features manually (even if we still keep the `-Zallow-features=` list, i.e. removing the `-Zcrate-attr` list), it is not really worth making all developers worry about it just for a new lint. The features are expected to eventually become stable anyway (most already did), and thus having to remove features in every file that may use them is not worth it either. Thus just allow the new lint globally. The lint actually existed for a long time, which is why `rustc` does not complain about an unknown lint in the stable versions we support, but it was "disabled" years ago [3], and now it was made to work again. For extra context, the new implementation of the lint has already been improved to avoid linting about features that became stable thanks to Benno's report and the ensuing discussion [4] [5], but while that helps, it is still the case that we may have features enabled that are not used for one reason or another in a particular crate. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/pull/152164 [1] Link: https://github.com/Rust-for-Linux/pin-init/pull/114 [2] Link: https://github.com/rust-lang/rust/issues/44232 [3] Link: https://github.com/rust-lang/rust/issues/153523 [4] Link: https://github.com/rust-lang/rust/pull/153610 [5] Reviewed-by: Benno Lossin Reviewed-by: Gary Guo Link: https://patch.msgid.link/20260312111014.74198-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit dd109e3442817bc03ad1f3ffd541092f8c428141 Author: Alice Ryhl Date: Tue Feb 24 18:16:39 2026 +0000 rust_binder: call set_notification_done() without proc lock commit 2e303f0febb65a434040774b793ba8356698802b upstream. Consider the following sequence of events on a death listener: 1. The remote process dies and sends a BR_DEAD_BINDER message. 2. The local process invokes the BC_CLEAR_DEATH_NOTIFICATION command. 3. The local process then invokes the BC_DEAD_BINDER_DONE. Then, the kernel will reply to the BC_DEAD_BINDER_DONE command with a BR_CLEAR_DEATH_NOTIFICATION_DONE reply using push_work_if_looper(). However, this can result in a deadlock if the current thread is not a looper. This is because dead_binder_done() still holds the proc lock during set_notification_done(), which called push_work_if_looper(). Normally, push_work_if_looper() takes the thread lock, which is fine to take under the proc lock. But if the current thread is not a looper, then it falls back to delivering the reply to the process work queue, which involves taking the proc lock. Since the proc lock is already held, this is a deadlock. Fix this by releasing the proc lock during set_notification_done(). It was not intentional that it was held during that function to begin with. I don't think this ever happens in Android because BC_DEAD_BINDER_DONE is only invoked in response to BR_DEAD_BINDER messages, and the kernel always delivers BR_DEAD_BINDER to a looper. So there's no scenario where Android userspace will call BC_DEAD_BINDER_DONE on a non-looper thread. Cc: stable Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver") Reported-by: syzbot+c8287e65a57a89e7fb72@syzkaller.appspotmail.com Tested-by: syzbot+c8287e65a57a89e7fb72@syzkaller.appspotmail.com Signed-off-by: Alice Ryhl Reviewed-by: Gary Guo Reviewed-by: Andreas Hindborg Link: https://patch.msgid.link/20260224-binder-dead-binder-done-proc-lock-v1-1-bbe1b8a6e74a@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit e19afb53f7723b3bd22224f2b0c7dcfa70bb973f Author: Alice Ryhl Date: Wed Feb 18 11:53:27 2026 +0000 rust_binder: avoid reading the written value in offsets array commit 4cb9e13fec0de7c942f5f927469beb8e48ddd20f upstream. When sending a transaction, its offsets array is first copied into the target proc's vma, and then the values are read back from there. This is normally fine because the vma is a read-only mapping, so the target process cannot change the value under us. However, if the target process somehow gains the ability to write to its own vma, it could change the offset before it's read back, causing the kernel to misinterpret what the sender meant. If the sender happens to send a payload with a specific shape, this could in the worst case lead to the receiver being able to privilege escalate into the sender. The intent is that gaining the ability to change the read-only vma of your own process should not be exploitable, so remove this TOCTOU read even though it's unexploitable without another Binder bug. Cc: stable Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver") Reported-by: Jann Horn Reviewed-by: Jann Horn Signed-off-by: Alice Ryhl Acked-by: Liam R. Howlett Link: https://patch.msgid.link/20260218-binder-vma-check-v2-2-60f9d695a990@google.com Signed-off-by: Greg Kroah-Hartman commit 20a01f20d1f4064d90a8627aa41b5987f0220bb9 Author: Alice Ryhl Date: Wed Feb 18 11:53:26 2026 +0000 rust_binder: check ownership before using vma commit 8ef2c15aeae07647f530d30f6daaf79eb801bcd1 upstream. When installing missing pages (or zapping them), Rust Binder will look up the vma in the mm by address, and then call vm_insert_page (or zap_page_range_single). However, if the vma is closed and replaced with a different vma at the same address, this can lead to Rust Binder installing pages into the wrong vma. By installing the page into a writable vma, it becomes possible to write to your own binder pages, which are normally read-only. Although you're not supposed to be able to write to those pages, the intent behind the design of Rust Binder is that even if you get that ability, it should not lead to anything bad. Unfortunately, due to another bug, that is not the case. To fix this, store a pointer in vm_private_data and check that the vma returned by vma_lookup() has the right vm_ops and vm_private_data before trying to use the vma. This should ensure that Rust Binder will refuse to interact with any other VMA. The plan is to introduce more vma abstractions to avoid this unsafe access to vm_ops and vm_private_data, but for now let's start with the simplest possible fix. C Binder performs the same check in a slightly different way: it provides a vm_ops->close that sets a boolean to true, then checks that boolean after calling vma_lookup(), but this is more fragile than the solution in this patch. (We probably still want to do both, but the vm_ops->close callback will be added later as part of the follow-up vma API changes.) It's still possible to remap the vma so that pages appear in the right vma, but at the wrong offset, but this is a separate issue and will be fixed when Rust Binder gets a vm_ops->close callback. Cc: stable Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver") Reported-by: Jann Horn Reviewed-by: Jann Horn Signed-off-by: Alice Ryhl Acked-by: Danilo Krummrich Acked-by: Liam R. Howlett Link: https://patch.msgid.link/20260218-binder-vma-check-v2-1-60f9d695a990@google.com Signed-off-by: Greg Kroah-Hartman commit edf685946c4acbe57cb96f8d5f3c07e9a2e973c8 Author: Carlos Llamas Date: Tue Feb 10 23:28:20 2026 +0000 rust_binder: fix oneway spam detection commit 4fc87c240b8f30e22b7ebaae29d57105589e1c0b upstream. The spam detection logic in TreeRange was executed before the current request was inserted into the tree. So the new request was not being factored in the spam calculation. Fix this by moving the logic after the new range has been inserted. Also, the detection logic for ArrayRange was missing altogether which meant large spamming transactions could get away without being detected. Fix this by implementing an equivalent low_oneway_space() in ArrayRange. Note that I looked into centralizing this logic in RangeAllocator but iterating through 'state' and 'size' got a bit too complicated (for me) and I abandoned this effort. Cc: stable Cc: Alice Ryhl Fixes: eafedbc7c050 ("rust_binder: add Rust Binder driver") Signed-off-by: Carlos Llamas Reviewed-by: Alice Ryhl Link: https://patch.msgid.link/20260210232949.3770644-1-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman commit 3e89ddbaaea2fb536a15a8308698e9e7b6207a9e Author: Oleksij Rempel Date: Thu Mar 5 15:34:28 2026 +0100 net: usb: lan78xx: skip LTM configuration for LAN7850 commit d9cc0e440f0664f6f3e2c26e39ab9dd5f3badba7 upstream. Do not configure Latency Tolerance Messaging (LTM) on USB 2.0 hardware. The LAN7850 is a High-Speed (USB 2.0) only device and does not support SuperSpeed features like LTM. Currently, the driver unconditionally attempts to configure LTM registers during initialization. On the LAN7850, these registers do not exist, resulting in writes to invalid or undocumented memory space. This issue was identified during a port to the regmap API with strict register validation enabled. While no functional issues or crashes have been observed from these invalid writes, bypassing LTM initialization on the LAN7850 ensures the driver strictly adheres to the hardware's valid register map. Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver") Cc: stable@vger.kernel.org Signed-off-by: Oleksij Rempel Link: https://patch.msgid.link/20260305143429.530909-4-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 20ce2bd1c1848414c5d3520d301ed3f5751ed634 Author: Oleksij Rempel Date: Thu Mar 5 15:34:29 2026 +0100 net: usb: lan78xx: fix WARN in __netif_napi_del_locked on disconnect commit 312c816c6bc30342bc30dca0d6db617ab4d3ae4e upstream. Remove redundant netif_napi_del() call from disconnect path. A WARN may be triggered in __netif_napi_del_locked() during USB device disconnect: WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350 This happens because netif_napi_del() is called in the disconnect path while NAPI is still enabled. However, it is not necessary to call netif_napi_del() explicitly, since unregister_netdev() will handle NAPI teardown automatically and safely. Removing the redundant call avoids triggering the warning. Full trace: lan78xx 1-1:1.0 enu1: Failed to read register index 0x000000c4. ret = -ENODEV lan78xx 1-1:1.0 enu1: Failed to set MAC down with error -ENODEV lan78xx 1-1:1.0 enu1: Link is Down lan78xx 1-1:1.0 enu1: Failed to read register index 0x00000120. ret = -ENODEV ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350 Modules linked in: flexcan can_dev fuse CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 6.16.0-rc2-00624-ge926949dab03 #9 PREEMPT Hardware name: SKOV IMX8MP CPU revC - bd500 (DT) Workqueue: usb_hub_wq hub_event pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __netif_napi_del_locked+0x2b4/0x350 lr : __netif_napi_del_locked+0x7c/0x350 sp : ffffffc085b673c0 x29: ffffffc085b673c0 x28: ffffff800b7f2000 x27: ffffff800b7f20d8 x26: ffffff80110bcf58 x25: ffffff80110bd978 x24: 1ffffff0022179eb x23: ffffff80110bc000 x22: ffffff800b7f5000 x21: ffffff80110bc000 x20: ffffff80110bcf38 x19: ffffff80110bcf28 x18: dfffffc000000000 x17: ffffffc081578940 x16: ffffffc08284cee0 x15: 0000000000000028 x14: 0000000000000006 x13: 0000000000040000 x12: ffffffb0022179e8 x11: 1ffffff0022179e7 x10: ffffffb0022179e7 x9 : dfffffc000000000 x8 : 0000004ffdde8619 x7 : ffffff80110bcf3f x6 : 0000000000000001 x5 : ffffff80110bcf38 x4 : ffffff80110bcf38 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 1ffffff0022179e7 x0 : 0000000000000000 Call trace: __netif_napi_del_locked+0x2b4/0x350 (P) lan78xx_disconnect+0xf4/0x360 usb_unbind_interface+0x158/0x718 device_remove+0x100/0x150 device_release_driver_internal+0x308/0x478 device_release_driver+0x1c/0x30 bus_remove_device+0x1a8/0x368 device_del+0x2e0/0x7b0 usb_disable_device+0x244/0x540 usb_disconnect+0x220/0x758 hub_event+0x105c/0x35e0 process_one_work+0x760/0x17b0 worker_thread+0x768/0xce8 kthread+0x3bc/0x690 ret_from_fork+0x10/0x20 irq event stamp: 211604 hardirqs last enabled at (211603): [] _raw_spin_unlock_irqrestore+0x84/0x98 hardirqs last disabled at (211604): [] el1_dbg+0x24/0x80 softirqs last enabled at (211296): [] handle_softirqs+0x820/0xbc8 softirqs last disabled at (210993): [] __do_softirq+0x18/0x20 ---[ end trace 0000000000000000 ]--- lan78xx 1-1:1.0 enu1: failed to kill vid 0081/0 Fixes: e110bc825897 ("net: usb: lan78xx: Convert to PHYLINK for improved PHY and MAC management") Cc: stable@vger.kernel.org Signed-off-by: Oleksij Rempel Link: https://patch.msgid.link/20260305143429.530909-5-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f62ec1babb2ae1529e4a2c9ea79e78ae8df3e479 Author: Oleksij Rempel Date: Thu Mar 5 15:34:27 2026 +0100 net: usb: lan78xx: fix TX byte statistics for small packets commit 50988747c30df47b73b787f234f746027cb7ec6c upstream. Account for hardware auto-padding in TX byte counters to reflect actual wire traffic. The LAN7850 hardware automatically pads undersized frames to the minimum Ethernet frame length (ETH_ZLEN, 60 bytes). However, the driver tracks the network statistics based on the unpadded socket buffer length. This results in the tx_bytes counter under-reporting the actual physical bytes placed on the Ethernet wire for small packets (like short ARP or ICMP requests). Use max_t() to ensure the transmission statistics accurately account for the hardware-generated padding. Fixes: d383216a7efe ("lan78xx: Introduce Tx URB processing improvements") Cc: stable@vger.kernel.org Signed-off-by: Oleksij Rempel Link: https://patch.msgid.link/20260305143429.530909-3-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit fa41007be691ba40af7faf74e1e5da3234e90b33 Author: Oleksij Rempel Date: Thu Mar 5 15:34:26 2026 +0100 net: usb: lan78xx: fix silent drop of packets with checksum errors commit e4f774a0cc955ce762aec91c66915a6e15087ab7 upstream. Do not drop packets with checksum errors at the USB driver level; pass them to the network stack. Previously, the driver dropped all packets where the 'Receive Error Detected' (RED) bit was set, regardless of the specific error type. This caused packets with only IP or TCP/UDP checksum errors to be dropped before reaching the kernel, preventing the network stack from accounting for them or performing software fallback. Add a mask for hard hardware errors to safely drop genuinely corrupt frames, while allowing checksum-errored frames to pass with their ip_summed field explicitly set to CHECKSUM_NONE. Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver") Cc: stable@vger.kernel.org Signed-off-by: Oleksij Rempel Link: https://patch.msgid.link/20260305143429.530909-2-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 00293f362712b791b5d6489def51889c13b7ec17 Author: Marc Kleine-Budde Date: Thu Feb 19 13:57:34 2026 +0100 can: gs_usb: gs_can_open(): always configure bitrates before starting device commit 2df6162785f31f1bbb598cfc3b08e4efc88f80b6 upstream. So far the driver populated the struct can_priv::do_set_bittiming() and struct can_priv::fd::do_set_data_bittiming() callbacks. Before bringing up the interface, user space has to configure the bitrates. With these callbacks the configuration is directly forwarded into the CAN hardware. Then the interface can be brought up. An ifdown-ifup cycle (without changing the bit rates) doesn't re-configure the bitrates in the CAN hardware. This leads to a problem with the CANable-2.5 [1] firmware, which resets the configured bit rates during ifdown. To fix the problem remove both bit timing callbacks and always configure the bitrates in the struct net_device_ops::ndo_open() callback. [1] https://github.com/Elmue/CANable-2.5-firmware-Slcan-and-Candlelight Cc: stable@vger.kernel.org Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Link: https://patch.msgid.link/20260219-gs_usb-always-configure-bitrates-v2-1-671f8ba5b0a5@pengutronix.de Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 3d542cf3c4c854cdf5d58049771f68926b9eb2b9 Author: Takashi Iwai Date: Mon Mar 9 11:46:27 2026 +0100 ALSA: usb-audio: Check endpoint numbers at parsing Scarlett2 mixer interfaces commit df1d8abf36ca3681c21a6809eaa9a1e01ef897a6 upstream. The Scarlett2 mixer quirk in USB-audio driver may hit a NULL dereference when a malformed USB descriptor is passed, since it assumes the presence of an endpoint in the parsed interface in scarlett2_find_fc_interface(), as reported by fuzzer. For avoiding the NULL dereference, just add the sanity check of bNumEndpoints and skip the invalid interface. Reported-by: syzbot+8f29539ef9a1c8334f42@syzkaller.appspotmail.com Closes: https://lore.kernel.org/69acbbe1.050a0220.310d8.0001.GAE@google.com Reported-by: syzbot+ae893a8901067fde2741@syzkaller.appspotmail.com Closes: https://lore.kernel.org/69acf72a.050a0220.310d8.0004.GAE@google.com Cc: Link: https://patch.msgid.link/20260309104632.141895-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4a758e9a1f5ed722f83c4dd35f867fe811553bcb Author: Mehul Rao Date: Thu Mar 5 14:35:07 2026 -0500 ALSA: pcm: fix use-after-free on linked stream runtime in snd_pcm_drain() commit 9b1dbd69ba6f8f8c69bc7b77c2ce3b9c6ed05ba6 upstream. In the drain loop, the local variable 'runtime' is reassigned to a linked stream's runtime (runtime = s->runtime at line 2157). After releasing the stream lock at line 2169, the code accesses runtime->no_period_wakeup, runtime->rate, and runtime->buffer_size (lines 2170-2178) — all referencing the linked stream's runtime without any lock or refcount protecting its lifetime. A concurrent close() on the linked stream's fd triggers snd_pcm_release_substream() → snd_pcm_drop() → pcm_release_private() → snd_pcm_unlink() → snd_pcm_detach_substream() → kfree(runtime). No synchronization prevents kfree(runtime) from completing while the drain path dereferences the stale pointer. Fix by caching the needed runtime fields (no_period_wakeup, rate, buffer_size) into local variables while still holding the stream lock, and using the cached values after the lock is released. Fixes: f2b3614cefb6 ("ALSA: PCM - Don't check DMA time-out too shortly") Cc: stable@vger.kernel.org Signed-off-by: Mehul Rao Link: https://patch.msgid.link/20260305193508.311096-1-mehulrao@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6eaaa67d6998f6c30c462b140db8c062e07ec473 Author: Cheng-Yang Chou Date: Tue Mar 3 22:35:30 2026 +0800 sched_ext: Remove redundant css_put() in scx_cgroup_init() commit 1336b579f6079fb8520be03624fcd9ba443c930b upstream. The iterator css_for_each_descendant_pre() walks the cgroup hierarchy under cgroup_lock(). It does not increment the reference counts on yielded css structs. According to the cgroup documentation, css_put() should only be used to release a reference obtained via css_get() or css_tryget_online(). Since the iterator does not use either of these to acquire a reference, calling css_put() in the error path of scx_cgroup_init() causes a refcount underflow. Remove the unbalanced css_put() to prevent a potential Use-After-Free (UAF) vulnerability. Fixes: 819513666966 ("sched_ext: Add cgroup support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Cheng-Yang Chou Reviewed-by: Andrea Righi Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 86ceaccfdfa16dad05addb33dc206e03589bcfd1 Author: Qingye Zhao Date: Wed Feb 11 09:24:04 2026 +0000 cgroup: fix race between task migration and iteration commit 5ee01f1a7343d6a3547b6802ca2d4cdce0edacb1 upstream. When a task is migrated out of a css_set, cgroup_migrate_add_task() first moves it from cset->tasks to cset->mg_tasks via: list_move_tail(&task->cg_list, &cset->mg_tasks); If a css_task_iter currently has it->task_pos pointing to this task, css_set_move_task() calls css_task_iter_skip() to keep the iterator valid. However, since the task has already been moved to ->mg_tasks, the iterator is advanced relative to the mg_tasks list instead of the original tasks list. As a result, remaining tasks on cset->tasks, as well as tasks queued on cset->mg_tasks, can be skipped by iteration. Fix this by calling css_set_skip_task_iters() before unlinking task->cg_list from cset->tasks. This advances all active iterators to the next task on cset->tasks, so iteration continues correctly even when a task is concurrently being migrated. This race is hard to hit in practice without instrumentation, but it can be reproduced by artificially slowing down cgroup_procs_show(). For example, on an Android device a temporary /sys/kernel/cgroup/cgroup_test knob can be added to inject a delay into cgroup_procs_show(), and then: 1) Spawn three long-running tasks (PIDs 101, 102, 103). 2) Create a test cgroup and move the tasks into it. 3) Enable a large delay via /sys/kernel/cgroup/cgroup_test. 4) In one shell, read cgroup.procs from the test cgroup. 5) Within the delay window, in another shell migrate PID 102 by writing it to a different cgroup.procs file. Under this setup, cgroup.procs can intermittently show only PID 101 while skipping PID 103. Once the migration completes, reading the file again shows all tasks as expected. Note that this change does not allow removing the existing css_set_skip_task_iters() call in css_set_move_task(). The new call in cgroup_migrate_add_task() only handles iterators that are racing with migration while the task is still on cset->tasks. Iterators may also start after the task has been moved to cset->mg_tasks. If we dropped css_set_skip_task_iters() from css_set_move_task(), such iterators could keep task_pos pointing to a migrating task, causing css_task_iter_advance() to malfunction on the destination css_set, up to and including crashes or infinite loops. The race window between migration and iteration is very small, and css_task_iter is not on a hot path. In the worst case, when an iterator is positioned on the first thread of the migrating process, cgroup_migrate_add_task() may have to skip multiple tasks via css_set_skip_task_iters(). However, this only happens when migration and iteration actually race, so the performance impact is negligible compared to the correctness fix provided here. Fixes: b636fd38dc40 ("cgroup: Implement css_task_iter_skip()") Cc: stable@vger.kernel.org # v5.2+ Signed-off-by: Qingye Zhao Reviewed-by: Michal Koutný Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 1051eb2f53886ec7e36896dfa356884d7212443a Author: Perry Yuan Date: Wed Jan 28 13:54:31 2026 +0800 drm/amdgpu: ensure no_hw_access is visible before MMIO commit 31b153315b8702d0249aa44d83d9fbf42c5c7a79 upstream. Add a full memory barrier after clearing no_hw_access in amdgpu_device_mode1_reset() so subsequent PCI state restore access cannot observe stale state on other CPUs. Fixes: 7edb503fe4b6 ("drm/amd/pm: Disable MMIO access during SMU Mode 1 reset") Signed-off-by: Perry Yuan Reviewed-by: Yifan Zhang Signed-off-by: Alex Deucher Cc: Simon Liebold Signed-off-by: Greg Kroah-Hartman commit 3428dc5520c811e66622b2f5fa43341bf9a1f8b3 Author: Seungjin Bae Date: Sat Feb 28 05:43:25 2026 -0500 usb: gadget: f_mass_storage: Fix potential integer overflow in check_command_size_in_blocks() [ Upstream commit 8479891d1f04a8ce55366fe4ca361ccdb96f02e1 ] The `check_command_size_in_blocks()` function calculates the data size in bytes by left shifting `common->data_size_from_cmnd` by the block size (`common->curlun->blkbits`). However, it does not validate whether this shift operation will cause an integer overflow. Initially, the block size is set up in `fsg_lun_open()` , and the `common->data_size_from_cmnd` is set up in `do_scsi_command()`. During initialization, there is no integer overflow check for the interaction between two variables. So if a malicious USB host sends a SCSI READ or WRITE command requesting a large amount of data (`common->data_size_from_cmnd`), the left shift operation can wrap around. This results in a truncated data size, which can bypass boundary checks and potentially lead to memory corruption or out-of-bounds accesses. Fix this by using the check_shl_overflow() macro to safely perform the shift and catch any overflows. Fixes: 144974e7f9e3 ("usb: gadget: mass_storage: support multi-luns with different logic block size") Signed-off-by: Seungjin Bae Reviewed-by: Alan Stern Link: https://patch.msgid.link/20260228104324.1696455-2-eeodqql09@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 678f1212f77bf490a918d3d7b7f4e3001c9c1285 Author: Andreas Kemnade Date: Wed Dec 31 22:14:16 2025 +0100 iio: imu: inv-mpu9150: fix irq ack preventing irq storms [ Upstream commit d23d763e00ace4e9c59f8d33e0713d401133ba88 ] IRQ needs to be acked. for some odd reasons, reading from irq status does not reliable help, enable acking from any register to be on the safe side and read the irq status register. Comments in the code indicate a known unreliability with that register. The blamed commit was tested with mpu6050 in lg,p895 and lg,p880 according to Tested-bys. But with the MPU9150 in the Epson Moverio BT-200 this leads to irq storms without properly acking the irq. Fixes: 0a3b517c8089 ("iio: imu: inv_mpu6050: fix interrupt status read for old buggy chips") Signed-off-by: Andreas Kemnade Acked-by: Jean-Baptiste Maneyrol Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 86f00a9e50b4a1b0e0c7b40a90ccd26d07cdfa31 Author: Eric Dumazet Date: Thu Mar 12 04:39:08 2026 +0000 net: prevent NULL deref in ip[6]tunnel_xmit() [ Upstream commit c38b8f5f791ecce13ab77e2257f8fd2444ba80f6 ] Blamed commit missed that both functions can be called with dev == NULL. Also add unlikely() hints for these conditions that only fuzzers can hit. Fixes: 6f1a9140ecda ("net: add xmit recursion limit to tunnel xmit functions") Signed-off-by: Eric Dumazet CC: Weiming Shi Link: https://patch.msgid.link/20260312043908.2790803-1-edumazet@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 7065d73a78ba79b69ac623e25e0d14ec73412635 Author: Alok Tiwari Date: Tue Mar 10 11:48:17 2026 -0700 octeontx2-af: devlink: fix NIX RAS reporter to use RAS interrupt status [ Upstream commit 87f7dff3ec75b91def0024ebaaf732457f47a63b ] The NIX RAS health report path uses nix_af_rvu_err when handling the NIX_AF_RVU_RAS case, so the report prints the ERR interrupt status rather than the RAS interrupt status. Use nix_af_rvu_ras for the NIX_AF_RVU_RAS report. Fixes: 5ed66306eab6 ("octeontx2-af: Add devlink health reporters for NIX") Signed-off-by: Alok Tiwari Link: https://patch.msgid.link/20260310184824.1183651-2-alok.a.tiwari@oracle.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c9d6bf8d139a98cc01dfc6d02864a46126b8af76 Author: Alok Tiwari Date: Tue Mar 10 11:48:16 2026 -0700 octeontx2-af: devlink: fix NIX RAS reporter recovery condition [ Upstream commit dc26ca99b835e21e76a58b1463b84adb0ca34f58 ] The NIX RAS health reporter recovery routine checks nix_af_rvu_int to decide whether to re-enable NIX_AF_RAS interrupts. This is the RVU interrupt status field and is unrelated to RAS events, so the recovery flow may incorrectly skip re-enabling NIX_AF_RAS interrupts. Check nix_af_rvu_ras instead before writing NIX_AF_RAS_ENA_W1S. Fixes: 5ed66306eab6 ("octeontx2-af: Add devlink health reporters for NIX") Signed-off-by: Alok Tiwari Link: https://patch.msgid.link/20260310184824.1183651-1-alok.a.tiwari@oracle.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8ded073fc8cdcf0e644faf0acbae545b38232a86 Author: Chintan Vankar Date: Tue Mar 10 21:39:40 2026 +0530 net: ethernet: ti: am65-cpsw-nuss: Fix rx_filter value for PTP support [ Upstream commit 840c9d13cb1ca96683a5307ee8e221be163a2c1e ] The "rx_filter" member of "hwtstamp_config" structure is an enum field and does not support bitwise OR combination of multiple filter values. It causes error while linuxptp application tries to match rx filter version. Fix this by storing the requested filter type in a new port field. Fixes: 97248adb5a3b ("net: ti: am65-cpsw: Update hw timestamping filter for PTPv1 RX packets") Signed-off-by: Chintan Vankar Link: https://patch.msgid.link/20260310160940.109822-1-c-vankar@ti.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c1d06ccbee468955807f20abab49b4a0d894fa75 Author: Vadim Fedorenko Date: Thu Oct 16 15:25:09 2025 +0000 net: ti: am65-cpsw: move hw timestamping to ndo callback [ Upstream commit ed5d5928bd54f66af19b71ad342ebf0947d50674 ] Migrate driver to new API for HW timestamping. Reviewed-by: Simon Horman Reviewed-by: Jacob Keller Signed-off-by: Vadim Fedorenko Link: https://patch.msgid.link/20251016152515.3510991-2-vadim.fedorenko@linux.dev Signed-off-by: Jakub Kicinski Stable-dep-of: 840c9d13cb1c ("net: ethernet: ti: am65-cpsw-nuss: Fix rx_filter value for PTP support") Signed-off-by: Sasha Levin commit 59489ce60d7412ed82fb1d8002faa3102dcd4916 Author: Shiraz Saleem Date: Mon Mar 9 10:24:43 2026 -0700 net/mana: Null service_wq on setup error to prevent double destroy [ Upstream commit 87c2302813abc55c46485711a678e3c312b00666 ] In mana_gd_setup() error path, set gc->service_wq to NULL after destroy_workqueue() to match the cleanup in mana_gd_cleanup(). This prevents a use-after-free if the workqueue pointer is checked after a failed setup. Fixes: f975a0955276 ("net: mana: Fix double destroy_workqueue on service rescan PCI path") Signed-off-by: Shiraz Saleem Signed-off-by: Konstantin Taranov Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260309172443.688392-1-kotaranov@linux.microsoft.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 103e4fedb47845703a84cd17152184b78505ee54 Author: Sabrina Dubroca Date: Tue Mar 10 22:59:16 2026 +0100 neighbour: restore protocol != 0 check in pneigh update [ Upstream commit cbada1048847a348797aec63a1d8056621cbe653 ] Prior to commit dc2a27e524ac ("neighbour: Update pneigh_entry in pneigh_create()."), a pneigh's protocol was updated only when the value of the NDA_PROTOCOL attribute was non-0. While moving the code, that check was removed. This is a small change of user-visible behavior, and inconsistent with the (non-proxy) neighbour behavior. Fixes: dc2a27e524ac ("neighbour: Update pneigh_entry in pneigh_create().") Signed-off-by: Sabrina Dubroca Reviewed-by: David Ahern Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/38c61de1bb032871a886aff9b9b52fe1cdd4cada.1772894876.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f7f12d551d611c9ed098eb0b54ca7d473641985d Author: Marek Behún Date: Wed Mar 11 12:12:37 2026 +0100 net: dsa: realtek: Fix LED group port bit for non-zero LED group [ Upstream commit e8f0dc024ce55451ebd54bad975134ba802e4fcc ] The rtl8366rb_led_group_port_mask() function always returns LED port bit in LED group 0; the switch statement returns the same thing in all non-default cases. This means that the driver does not currently support configuring LEDs in non-zero LED groups. Fix this. Fixes: 32d617005475a71e ("net: dsa: realtek: add LED drivers for rtl8366rb") Signed-off-by: Marek Behún Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260311111237.29002-1-kabel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 95faa1459b83fa544191e82ccc73856f03b7741f Author: Ricardo B. Marlière Date: Sat Mar 7 17:50:54 2026 -0300 net: bonding: Fix nd_tbl NULL dereference when IPv6 is disabled [ Upstream commit 30021e969d48e5819d5ae56936c2f34c0f7ce997 ] When booting with the 'ipv6.disable=1' parameter, the nd_tbl is never initialized because inet6_init() exits before ndisc_init() is called which initializes it. If bonding ARP/NS validation is enabled, an IPv6 NS/NA packet received on a slave can reach bond_validate_na(), which calls bond_has_this_ip6(). That path calls ipv6_chk_addr() and can crash in __ipv6_chk_addr_and_flags(). BUG: kernel NULL pointer dereference, address: 00000000000005d8 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:__ipv6_chk_addr_and_flags+0x69/0x170 Call Trace: ipv6_chk_addr+0x1f/0x30 bond_validate_na+0x12e/0x1d0 [bonding] ? __pfx_bond_handle_frame+0x10/0x10 [bonding] bond_rcv_validate+0x1a0/0x450 [bonding] bond_handle_frame+0x5e/0x290 [bonding] ? srso_alias_return_thunk+0x5/0xfbef5 __netif_receive_skb_core.constprop.0+0x3e8/0xe50 ? srso_alias_return_thunk+0x5/0xfbef5 ? update_cfs_rq_load_avg+0x1a/0x240 ? srso_alias_return_thunk+0x5/0xfbef5 ? __enqueue_entity+0x5e/0x240 __netif_receive_skb_one_core+0x39/0xa0 process_backlog+0x9c/0x150 __napi_poll+0x30/0x200 ? srso_alias_return_thunk+0x5/0xfbef5 net_rx_action+0x338/0x3b0 handle_softirqs+0xc9/0x2a0 do_softirq+0x42/0x60 __local_bh_enable_ip+0x62/0x70 __dev_queue_xmit+0x2d3/0x1000 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? packet_parse_headers+0x10a/0x1a0 packet_sendmsg+0x10da/0x1700 ? kick_pool+0x5f/0x140 ? srso_alias_return_thunk+0x5/0xfbef5 ? __queue_work+0x12d/0x4f0 __sys_sendto+0x1f3/0x220 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x101/0xf80 ? exc_page_fault+0x6e/0x170 ? srso_alias_return_thunk+0x5/0xfbef5 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this by checking ipv6_mod_enabled() before dispatching IPv6 packets to bond_na_rcv(). If IPv6 is disabled, return early from bond_rcv_validate() and avoid the path to ipv6_chk_addr(). Suggested-by: Fernando Fernandez Mancera Fixes: 4e24be018eb9 ("bonding: add new parameter ns_targets") Signed-off-by: Ricardo B. Marlière Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260307-net-nd_tbl_fixes-v4-2-e2677e85628c@suse.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 84c1adb60fdbaa79984562b4bd4ef08d36d1795f Author: Chuck Lever Date: Tue Mar 10 13:59:51 2026 -0400 perf synthetic-events: Fix stale build ID in module MMAP2 records [ Upstream commit 35b16a7a2c4fc458304447128b86514ce9f70f3c ] perf_event__synthesize_modules() allocates a single union perf_event and reuses it across every kernel module callback. After the first module is processed, perf_record_mmap2__read_build_id() sets PERF_RECORD_MISC_MMAP_BUILD_ID in header.misc and writes that module's build ID into the event. On subsequent iterations the callback overwrites start, len, pid, and filename for the next module but never clears the stale build ID fields or the MMAP_BUILD_ID flag. When perf_record_mmap2__read_build_id() runs for the second module it sees the flag, reads the stale build ID into a dso_id, and __dso__improve_id() permanently poisons the DSO with the wrong build ID. Every module after the first therefore receives the first module's build ID in its MMAP2 record. On a system with the sunrpc and nfsd modules loaded, this causes perf script and perf report to show [unknown] for all module symbols. The latent bug has existed since commit d9f2ecbc5e47fca7 ("perf dso: Move build_id to dso_id") introduced the PERF_RECORD_MISC_MMAP_BUILD_ID check in perf_record_mmap2__read_build_id(). Commit 53b00ff358dc75b1 ("perf record: Make --buildid-mmap the default") then exposed it to all users by making the MMAP2-with-build-ID path the default. Both commits were merged in the same series. Clear the MMAP_BUILD_ID flag and zero the build_id union before each call to perf_record_mmap2__read_build_id() so that every module starts with a clean slate. Fixes: d9f2ecbc5e47fca7 ("perf dso: Move build_id to dso_id") Reviewed-by: Ian Rogers Signed-off-by: Chuck Lever Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 529c985da1b277b36dc99aad660f96dc70f3c467 Author: Philip Yang Date: Tue Dec 9 15:13:23 2025 -0500 drm/amdkfd: Unreserve bo if queue update failed [ Upstream commit 2ce75a0b7e1bfddbcb9bc8aeb2e5e7fa99971acf ] Error handling path should unreserve bo then return failed. Fixes: 305cd109b761 ("drm/amdkfd: Validate user queue update") Signed-off-by: Philip Yang Reviewed-by: Alex Sierra Signed-off-by: Alex Deucher (cherry picked from commit c24afed7de9ecce341825d8ab55a43a254348b33) Signed-off-by: Sasha Levin commit b3b56d60fee163fe2cf08ce933b07cd2b8d98736 Author: Casey Connolly Date: Fri Mar 6 18:47:07 2026 +0100 ASoC: detect empty DMI strings [ Upstream commit a9683730e8b1d632674f81844ed03ddfbe4821c0 ] Some bootloaders like recent versions of U-Boot may install some DMI properties with empty values rather than not populate them. This manages to make its way through the validator and cleanup resulting in a rogue hyphen being appended to the card longname. Fixes: 4e01e5dbba96 ("ASoC: improve the DMI long card code in asoc-core") Signed-off-by: Casey Connolly Link: https://patch.msgid.link/20260306174707.283071-2-casey.connolly@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 790851ecc983c719fa2e6adb17b02f3acc1d217d Author: Chen Ni Date: Tue Mar 10 10:42:46 2026 +0800 ASoC: amd: acp3x-rt5682-max9836: Add missing error check for clock acquisition [ Upstream commit 53f3a900e9a383d47af7253076e19f510c5708d0 ] The acp3x_5682_init() function did not check the return value of clk_get(), which could lead to dereferencing error pointers in rt5682_clk_enable(). Fix this by: 1. Changing clk_get() to the device-managed devm_clk_get(). 2. Adding proper IS_ERR() checks for both clock acquisitions. Fixes: 6b8e4e7db3cd ("ASoC: amd: Add machine driver for Raven based platform") Signed-off-by: Chen Ni Link: https://patch.msgid.link/20260310024246.2153827-1-nichen@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9a3106a81fc3c9b53147e4902d01990c43a9c37e Author: Ben Dooks Date: Wed Mar 11 10:58:35 2026 +0000 ACPI: OSL: fix __iomem type on return from acpi_os_map_generic_address() [ Upstream commit 393815f57651101f1590632092986d1d5a3a41bd ] The pointer returned from acpi_os_map_generic_address() is tagged with __iomem, so make the rv it is returned to also of void __iomem * type. Fixes the following sparse warning: drivers/acpi/osl.c:1686:20: warning: incorrect type in assignment (different address spaces) drivers/acpi/osl.c:1686:20: expected void *rv drivers/acpi/osl.c:1686:20: got void [noderef] __iomem * Fixes: 6915564dc5a8 ("ACPI: OSL: Change the type of acpi_os_map_generic_address() return value") Signed-off-by: Ben Dooks [ rjw: Subject tweak, added Fixes tag ] Link: https://patch.msgid.link/20260311105835.463030-1-ben.dooks@codethink.co.uk Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit e987bc1d2e8d4c995f9bfee618e0cb6750930551 Author: Nicolai Buchwitz Date: Tue Mar 10 06:49:35 2026 +0100 net: bcmgenet: fix broken EEE by converting to phylib-managed state [ Upstream commit 908c344d5cfac4160f49715da9efacdf5b6a28bd ] The bcmgenet EEE implementation is broken in several ways. phy_support_eee() is never called, so the PHY never advertises EEE and phylib never sets phydev->enable_tx_lpi. bcmgenet_mac_config() checks priv->eee.eee_enabled to decide whether to enable the MAC LPI logic, but that field is never initialised to true, so the MAC never enters Low Power Idle even when EEE is negotiated - wasting the power savings EEE is designed to provide. The only way to get EEE working at all is a manual 'ethtool --set-eee eth0 eee on' after every link-up, and even then bcmgenet_get_eee() immediately clobbers the reported state because phy_ethtool_get_eee() overwrites eee_enabled and tx_lpi_enabled with the uninitialised PHY eee_cfg values. Finally, bcmgenet_mac_config() is only called on link-up, so EEE is never disabled in hardware on link-down. Fix all of this by removing the MAC-side EEE state tracking (priv->eee) and aligning with the pattern used by other non-phylink MAC drivers such as FEC. Call phy_support_eee() in bcmgenet_mii_probe() so the PHY advertises EEE link modes and phylib tracks negotiation state. Move the EEE hardware control to bcmgenet_mii_setup(), which is called on every link event, and drive it directly from phydev->enable_tx_lpi - the flag phylib sets when EEE is negotiated and the user has not disabled it. This enables EEE automatically once the link partner agrees and disables it cleanly on link-down. Make bcmgenet_get_eee() and bcmgenet_set_eee() pure passthroughs to phy_ethtool_get_eee() and phy_ethtool_set_eee(), with the MAC hardware register read/written for tx_lpi_timer. Drop struct ethtool_keee eee from struct bcmgenet_priv. Fixes: fe0d4fd9285e ("net: phy: Keep track of EEE configuration") Link: https://lore.kernel.org/netdev/d352039f-4cbb-41e6-9aeb-0b4f3941b54c@lunn.ch/ Suggested-by: Andrew Lunn Signed-off-by: Nicolai Buchwitz Reviewed-by: Florian Fainelli Tested-by: Florian Fainelli Link: https://patch.msgid.link/20260310054935.1238594-1-nb@tipi-net.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 53480725b1395ae2803ed2c4755be0afcc8009b5 Author: Jakub Kicinski Date: Mon Mar 9 17:39:07 2026 -0700 page_pool: store detach_time as ktime_t to avoid false-negatives [ Upstream commit 28b225282d44e2ef40e7f46cfdbd5d1b20b8874f ] While testing other changes in vng I noticed that nl_netdev.page_pool_check flakes. This never happens in real CI. Turns out vng may boot and get to that test in less than a second. page_pool_detached() records the detach time in seconds, so if vng is fast enough detach time is set to 0. Other code treats 0 as "not detached". detach_time is only used to report the state to the user, so it's not a huge deal in practice but let's fix it. Store the raw ktime_t (nanoseconds) instead. A nanosecond value of 0 is practically impossible. Acked-by: Jesper Dangaard Brouer Fixes: 69cb4952b6f6 ("net: page_pool: report when page pool was destroyed") Link: https://patch.msgid.link/20260310003907.3540019-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 30e87ade8d678c25a8546cf38c0b498fa5cb27d3 Author: Matt Vollrath Date: Tue Feb 24 18:28:33 2026 -0500 e1000/e1000e: Fix leak in DMA error cleanup [ Upstream commit e94eaef11142b01f77bf8ba4d0b59720b7858109 ] If an error is encountered while mapping TX buffers, the driver should unmap any buffers already mapped for that skb. Because count is incremented after a successful mapping, it will always match the correct number of unmappings needed when dma_error is reached. Decrementing count before the while loop in dma_error causes an off-by-one error. If any mapping was successful before an unsuccessful mapping, exactly one DMA mapping would leak. In these commits, a faulty while condition caused an infinite loop in dma_error: Commit 03b1320dfcee ("e1000e: remove use of skb_dma_map from e1000e driver") Commit 602c0554d7b0 ("e1000: remove use of skb_dma_map from e1000 driver") Commit c1fa347f20f1 ("e1000/e1000e/igb/igbvf/ixgb/ixgbe: Fix tests of unsigned in *_tx_map()") fixed the infinite loop, but introduced the off-by-one error. This issue may still exist in the igbvf driver, but I did not address it in this patch. Fixes: c1fa347f20f1 ("e1000/e1000e/igb/igbvf/ixgb/ixgbe: Fix tests of unsigned in *_tx_map()") Assisted-by: Claude:claude-4.6-opus Signed-off-by: Matt Vollrath Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 981e2805e48fcd299dee3e1ea4e390b7d56c2afc Author: Alok Tiwari Date: Mon Nov 10 11:13:38 2025 -0800 i40e: fix src IP mask checks and memcpy argument names in cloud filter [ Upstream commit e809085f492842ce7a519c9ef72d40f4bca89c13 ] Fix following issues in the IPv4 and IPv6 cloud filter handling logic in both the add and delete paths: - The source-IP mask check incorrectly compares mask.src_ip[0] against tcf.dst_ip[0]. Update it to compare against tcf.src_ip[0]. This likely goes unnoticed because the check is in an "else if" path that only executes when dst_ip is not set, most cloud filter use cases focus on destination-IP matching, and the buggy condition can accidentally evaluate true in some cases. - memcpy() for the IPv4 source address incorrectly uses ARRAY_SIZE(tcf.dst_ip) instead of ARRAY_SIZE(tcf.src_ip), although both arrays are the same size. - The IPv4 memcpy operations used ARRAY_SIZE(tcf.dst_ip) and ARRAY_SIZE (tcf.src_ip), Update these to use sizeof(cfilter->ip.v4.dst_ip) and sizeof(cfilter->ip.v4.src_ip) to ensure correct and explicit copy size. - In the IPv6 delete path, memcmp() uses sizeof(src_ip6) when comparing dst_ip6 fields. Replace this with sizeof(dst_ip6) to make the intent explicit, even though both fields are struct in6_addr. Fixes: e284fc280473 ("i40e: Add and delete cloud filter") Signed-off-by: Alok Tiwari Reviewed-by: Aleksandr Loktionov Reviewed-by: Paul Menzel Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 75e0a631c3a130ead05ea363e6d8ed672bc7872b Author: Petr Oros Date: Wed Feb 11 20:18:55 2026 +0100 iavf: fix incorrect reset handling in callbacks [ Upstream commit fdadbf6e84c44df8dbb85cfdd38bc10e4431501d ] Three driver callbacks schedule a reset and wait for its completion: ndo_change_mtu(), ethtool set_ringparam(), and ethtool set_channels(). Waiting for reset in ndo_change_mtu() and set_ringparam() was added by commit c2ed2403f12c ("iavf: Wait for reset in callbacks which trigger it") to fix a race condition where adding an interface to bonding immediately after MTU or ring parameter change failed because the interface was still in __RESETTING state. The same commit also added waiting in iavf_set_priv_flags(), which was later removed by commit 53844673d555 ("iavf: kill "legacy-rx" for good"). Waiting in set_channels() was introduced earlier by commit 4e5e6b5d9d13 ("iavf: Fix return of set the new channel count") to ensure the PF has enough time to complete the VF reset when changing channel count, and to return correct error codes to userspace. Commit ef490bbb2267 ("iavf: Add net_shaper_ops support") added net_shaper_ops to iavf, which required reset_task to use _locked NAPI variants (napi_enable_locked, napi_disable_locked) that need the netdev instance lock. Later, commit 7e4d784f5810 ("net: hold netdev instance lock during rtnetlink operations") and commit 2bcf4772e45a ("net: ethtool: try to protect all callback with netdev instance lock") started holding the netdev instance lock during ndo and ethtool callbacks for drivers with net_shaper_ops. Finally, commit 120f28a6f314 ("iavf: get rid of the crit lock") replaced the driver's crit_lock with netdev_lock in reset_task, causing incorrect behavior: the callback holds netdev_lock and waits for reset_task, but reset_task needs the same lock: Thread 1 (callback) Thread 2 (reset_task) ------------------- --------------------- netdev_lock() [blocked on workqueue] ndo_change_mtu() or ethtool op iavf_schedule_reset() iavf_wait_for_reset() iavf_reset_task() waiting... netdev_lock() <- blocked This does not strictly deadlock because iavf_wait_for_reset() uses wait_event_interruptible_timeout() with a 5-second timeout. The wait eventually times out, the callback returns an error to userspace, and after the lock is released reset_task completes the reset. This leads to incorrect behavior: userspace sees an error even though the configuration change silently takes effect after the timeout. Fix this by extracting the reset logic from iavf_reset_task() into a new iavf_reset_step() function that expects netdev_lock to be already held. The three callbacks now call iavf_reset_step() directly instead of scheduling the work and waiting, performing the reset synchronously in the caller's context which already holds netdev_lock. This eliminates both the incorrect error reporting and the need for iavf_wait_for_reset(), which is removed along with the now-unused reset_waitqueue. The workqueue-based iavf_reset_task() becomes a thin wrapper that acquires netdev_lock and calls iavf_reset_step(), preserving its use for PF-initiated resets. The callbacks may block for several seconds while iavf_reset_step() polls hardware registers, but this is acceptable since netdev_lock is a per-device mutex and only serializes operations on the same interface. v3: - Remove netif_running() guard from iavf_set_channels(). Unlike set_ringparam where descriptor counts are picked up by iavf_open() directly, num_req_queues is only consumed during iavf_reinit_interrupt_scheme() in the reset path. Skipping the reset on a down device would silently discard the channel count change. - Remove dead reset_waitqueue code (struct field, init, and all wake_up calls) since iavf_wait_for_reset() was the only consumer. Fixes: 120f28a6f314 ("iavf: get rid of the crit lock") Reviewed-by: Jacob Keller Signed-off-by: Petr Oros Reviewed-by: Przemek Kitszel Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 1b034f2429ce6b45ce74dc266175d277acafc5c4 Author: Petr Oros Date: Thu Jan 29 10:57:23 2026 +0100 iavf: fix PTP use-after-free during reset [ Upstream commit efc54fb13d79117a825fef17364315a58682c7ec ] Commit 7c01dbfc8a1c5f ("iavf: periodically cache PHC time") introduced a worker to cache PHC time, but failed to stop it during reset or disable. This creates a race condition where `iavf_reset_task()` or `iavf_disable_vf()` free adapter resources (AQ) while the worker is still running. If the worker triggers `iavf_queue_ptp_cmd()` during teardown, it accesses freed memory/locks, leading to a crash. Fix this by calling `iavf_ptp_release()` before tearing down the adapter. This ensures `ptp_clock_unregister()` synchronously cancels the worker and cleans up the chardev before the backing resources are destroyed. Fixes: 7c01dbfc8a1c5f ("iavf: periodically cache PHC time") Signed-off-by: Petr Oros Reviewed-by: Ivan Vecera Acked-by: Jacob Keller Reviewed-by: Vadim Fedorenko Reviewed-by: Paul Menzel Reviewed-by: Aleksandr Loktionov Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 98b36857f35847cd273d38079c2b94d71fdd176d Author: Nikolay Aleksandrov Date: Fri Feb 13 10:48:41 2026 +0200 drivers: net: ice: fix devlink parameters get without irdma [ Upstream commit bd98c6204d1195973b1760fe45860863deb6200c ] If CONFIG_IRDMA isn't enabled but there are ice NICs in the system, the driver will prevent full devlink dev param show dump because its rdma get callbacks return ENODEV and stop the dump. For example: $ devlink dev param show pci/0000:82:00.0: name msix_vec_per_pf_max type generic values: cmode driverinit value 2 name msix_vec_per_pf_min type generic values: cmode driverinit value 2 kernel answers: No such device Returning EOPNOTSUPP allows the dump to continue so we can see all devices' devlink parameters. Fixes: c24a65b6a27c ("iidc/ice/irdma: Update IDC to support multiple consumers") Signed-off-by: Nikolay Aleksandrov Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit b56c49897bdac5cb49e3495ef421c391628ee9bb Author: Sungwoo Kim Date: Sat Mar 7 14:46:36 2026 -0500 nvme-pci: Fix race bug in nvme_poll_irqdisable() [ Upstream commit fc71f409b22ca831a9f87a2712eaa09ef2bb4a5e ] In the following scenario, pdev can be disabled between (1) and (3) by (2). This sets pdev->msix_enabled = 0. Then, pci_irq_vector() will return MSI-X IRQ(>15) for (1) whereas return INTx IRQ(<=15) for (2). This causes IRQ warning because it tries to enable INTx IRQ that has never been disabled before. To fix this, save IRQ number into a local variable and ensure disable_irq() and enable_irq() operate on the same IRQ number. Even if pci_free_irq_vectors() frees the IRQ concurrently, disable_irq() and enable_irq() on a stale IRQ number is still valid and safe, and the depth accounting reamins balanced. task 1: nvme_poll_irqdisable() disable_irq(pci_irq_vector(pdev, nvmeq->cq_vector)) ...(1) enable_irq(pci_irq_vector(pdev, nvmeq->cq_vector)) ...(3) task 2: nvme_reset_work() nvme_dev_disable() pdev->msix_enable = 0; ...(2) crash log: ------------[ cut here ]------------ Unbalanced enable for IRQ 10 WARNING: kernel/irq/manage.c:753 at __enable_irq+0x102/0x190 kernel/irq/manage.c:753, CPU#1: kworker/1:0H/26 Modules linked in: CPU: 1 UID: 0 PID: 26 Comm: kworker/1:0H Not tainted 6.19.0-dirty #9 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blk_mq_timeout_work RIP: 0010:__enable_irq+0x107/0x190 kernel/irq/manage.c:753 Code: ff df 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 79 48 8d 3d 2e 7a 3f 05 41 8b 74 24 2c <67> 48 0f b9 3a e8 ef b9 21 00 5b 41 5c 5d e9 46 54 66 03 e8 e1 b9 RSP: 0018:ffffc900001bf550 EFLAGS: 00010046 RAX: 0000000000000007 RBX: 0000000000000000 RCX: ffffffffb20c0e90 RDX: 0000000000000000 RSI: 000000000000000a RDI: ffffffffb74b88f0 RBP: ffffc900001bf560 R08: ffff88800197cf00 R09: 0000000000000001 R10: 0000000000000003 R11: 0000000000000003 R12: ffff8880012a6000 R13: 1ffff92000037eae R14: 000000000000000a R15: 0000000000000293 FS: 0000000000000000(0000) GS:ffff8880b49f7000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555da4a25fa8 CR3: 00000000208e8000 CR4: 00000000000006f0 Call Trace: enable_irq+0x121/0x1e0 kernel/irq/manage.c:797 nvme_poll_irqdisable+0x162/0x1c0 drivers/nvme/host/pci.c:1494 nvme_timeout+0x965/0x14b0 drivers/nvme/host/pci.c:1744 blk_mq_rq_timed_out block/blk-mq.c:1653 [inline] blk_mq_handle_expired+0x227/0x2d0 block/blk-mq.c:1721 bt_iter+0x2fc/0x3a0 block/blk-mq-tag.c:292 __sbitmap_for_each_set include/linux/sbitmap.h:269 [inline] sbitmap_for_each_set include/linux/sbitmap.h:290 [inline] bt_for_each block/blk-mq-tag.c:324 [inline] blk_mq_queue_tag_busy_iter+0x969/0x1e80 block/blk-mq-tag.c:536 blk_mq_timeout_work+0x627/0x870 block/blk-mq.c:1763 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 irq event stamp: 74478 hardirqs last enabled at (74477): [] __raw_spin_unlock_irq include/linux/spinlock_api_smp.h:159 [inline] hardirqs last enabled at (74477): [] _raw_spin_unlock_irq+0x2c/0x60 kernel/locking/spinlock.c:202 hardirqs last disabled at (74478): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline] hardirqs last disabled at (74478): [] _raw_spin_lock_irqsave+0x85/0xa0 kernel/locking/spinlock.c:162 softirqs last enabled at (74304): [] __do_softirq kernel/softirq.c:656 [inline] softirqs last enabled at (74304): [] invoke_softirq kernel/softirq.c:496 [inline] softirqs last enabled at (74304): [] __irq_exit_rcu+0xdc/0x120 kernel/softirq.c:723 softirqs last disabled at (74287): [] __do_softirq kernel/softirq.c:656 [inline] softirqs last disabled at (74287): [] invoke_softirq kernel/softirq.c:496 [inline] softirqs last disabled at (74287): [] __irq_exit_rcu+0xdc/0x120 kernel/softirq.c:723 ---[ end trace 0000000000000000 ]--- Fixes: fa059b856a59 (nvme-pci: Simplify nvme_poll_irqdisable) Acked-by: Chao Shi Acked-by: Weidong Zhu Acked-by: Dave Tian Reviewed-by: Christoph Hellwig Signed-off-by: Sungwoo Kim Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 328c551f0cc81ee776b186b86cc6e5253bb6fda7 Author: Sungwoo Kim Date: Sun Mar 8 14:20:59 2026 -0400 nvme-pci: Fix slab-out-of-bounds in nvme_dbbuf_set [ Upstream commit b4e78f1427c7d6859229ae9616df54e1fc05a516 ] dev->online_queues is a count incremented in nvme_init_queue. Thus, valid indices are 0 through dev->online_queues − 1. This patch fixes the loop condition to ensure the index stays within the valid range. Index 0 is excluded because it is the admin queue. KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_free drivers/nvme/host/pci.c:377 [inline] BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c:404 Read of size 2 at addr ffff88800592a574 by task kworker/u8:5/74 CPU: 0 UID: 0 PID: 74 Comm: kworker/u8:5 Not tainted 6.19.0-dirty #10 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: nvme-reset-wq nvme_reset_work Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xea/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xce/0x5d0 mm/kasan/report.c:482 kasan_report+0xdc/0x110 mm/kasan/report.c:595 __asan_report_load2_noabort+0x18/0x20 mm/kasan/report_generic.c:379 nvme_dbbuf_free drivers/nvme/host/pci.c:377 [inline] nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c:404 nvme_reset_work+0x36b/0x8c0 drivers/nvme/host/pci.c:3252 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 Allocated by task 34 on cpu 1 at 4.241550s: kasan_save_stack+0x2c/0x60 mm/kasan/common.c:57 kasan_save_track+0x1c/0x70 mm/kasan/common.c:78 kasan_save_alloc_info+0x3c/0x50 mm/kasan/generic.c:570 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xb5/0xc0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5657 [inline] __kmalloc_node_noprof+0x2bf/0x8d0 mm/slub.c:5663 kmalloc_array_node_noprof include/linux/slab.h:1075 [inline] nvme_pci_alloc_dev drivers/nvme/host/pci.c:3479 [inline] nvme_probe+0x2f1/0x1820 drivers/nvme/host/pci.c:3534 local_pci_probe+0xef/0x1c0 drivers/pci/pci-driver.c:324 pci_call_probe drivers/pci/pci-driver.c:392 [inline] __pci_device_probe drivers/pci/pci-driver.c:417 [inline] pci_device_probe+0x743/0x920 drivers/pci/pci-driver.c:451 call_driver_probe drivers/base/dd.c:583 [inline] really_probe+0x29b/0xb70 drivers/base/dd.c:661 __driver_probe_device+0x3b0/0x4a0 drivers/base/dd.c:803 driver_probe_device+0x56/0x1f0 drivers/base/dd.c:833 __driver_attach_async_helper+0x155/0x340 drivers/base/dd.c:1159 async_run_entry_fn+0xa6/0x4b0 kernel/async.c:129 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 The buggy address belongs to the object at ffff88800592a000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 244 bytes to the right of allocated 1152-byte region [ffff88800592a000, ffff88800592a480) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5928 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0xfffffc0000040(head|node=0|zone=1|lastcpupid=0x1fffff) page_type: f5(slab) raw: 000fffffc0000040 ffff888001042000 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000080008 00000000f5000000 0000000000000000 head: 000fffffc0000040 ffff888001042000 0000000000000000 dead000000000001 head: 0000000000000000 0000000000080008 00000000f5000000 0000000000000000 head: 000fffffc0000003 ffffea0000164a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88800592a400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88800592a480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88800592a500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff88800592a580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800592a600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Fixes: 0f0d2c876c96 (nvme: free sq/cq dbbuf pointers when dbbuf set fails) Acked-by: Chao Shi Acked-by: Weidong Zhu Acked-by: Dave Tian Signed-off-by: Sungwoo Kim Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 3cf2d7ca4828940c2d2a6091827a42811c82ef10 Author: Rafael J. Wysocki Date: Sat Mar 7 17:12:05 2026 +0100 sched: idle: Make skipping governor callbacks more consistent [ Upstream commit d557640e4ce589a24dca5ca7ce3b9680f471325f ] If the cpuidle governor .select() callback is skipped because there is only one idle state in the cpuidle driver, the .reflect() callback should be skipped as well, at least for consistency (if not for correctness), so do it. Fixes: e5c9ffc6ae1b ("cpuidle: Skip governor when only one idle state is available") Signed-off-by: Rafael J. Wysocki Reviewed-by: Christian Loehle Reviewed-by: Aboorva Devarajan Reviewed-by: Frederic Weisbecker Link: https://patch.msgid.link/12857700.O9o76ZdvQC@rafael.j.wysocki Signed-off-by: Sasha Levin commit a422159d766ad1875f4283682c46a0a771ac8e53 Author: Chen Ni Date: Fri Mar 6 12:10:52 2026 +0800 perf ftrace: Fix hashmap__new() error checking [ Upstream commit be34705aa527872e5ce83927b7bc9307ba8095ca ] The hashmap__new() function never returns NULL, it returns error pointers. Fix the error checking to match. Additionally, set ftrace->profile_hash to NULL on error, and return the exact error code from hashmap__new(). Fixes: 0f223813edd051a5 ("perf ftrace: Add 'profile' command") Suggested-by: Ian Rogers Signed-off-by: Chen Ni Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit f7e52a24e5b76b66ce7cb7304870082218dcf861 Author: Peng Fan Date: Tue Mar 10 12:25:53 2026 +0800 regulator: pca9450: Correct probed name for PCA9452 [ Upstream commit 21b3fb7dc19caa488d285e3c47999f7f1a179334 ] An incorrect device name was logged for PCA9452 because the dev_info() ternary omitted PCA9452 and fell through to "pca9450bc". Introduce a type_name and set it per device type so the probed message matches the actual PMIC. While here, make the PCA9451A case explicit. No functional changes. Fixes: 017b76fb8e5b6 ("regulator: pca9450: Add PMIC pca9452 support") Signed-off-by: Peng Fan Link: https://patch.msgid.link/20260310-pca9450-irq-v1-2-36adf52c2c55@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 55ca06f54f57f03208a9ab0aa3939a130de3ed90 Author: Martijn de Gouw Date: Mon Nov 17 21:22:14 2025 +0100 regulator: pca9450: Add support for setting debounce settings [ Upstream commit d9d0be59be2580f2c5e4b7217aafb980e8c371cf ] Make the different debounce timers configurable from the devicetree. Depending on the board design, these have to be set different than the default register values. Signed-off-by: Martijn de Gouw Link: https://patch.msgid.link/20251117202215.1936139-2-martijn.de.gouw@prodrive-technologies.com Signed-off-by: Mark Brown Stable-dep-of: 21b3fb7dc19c ("regulator: pca9450: Correct probed name for PCA9452") Signed-off-by: Sasha Levin commit ec1427731244d846d507a35626a81cdaa656ba5e Author: Peng Fan Date: Tue Mar 10 12:25:52 2026 +0800 regulator: pca9450: Correct interrupt type [ Upstream commit 5d0efaf47ee90ac60efae790acee3a3ed99ebf80 ] Kernel warning on i.MX8MP-EVK when doing module test: irq: type mismatch, failed to map hwirq-3 for gpio@30200000! Per PCA945[X] specification: The IRQ_B pin is pulled low when any unmasked interrupt bit status is changed and it is released high once application processor read INT1 register. So the interrupt should be configured as IRQF_TRIGGER_LOW, not IRQF_TRIGGER_FALLING. Fixes: 0935ff5f1f0a4 ("regulator: pca9450: add pca9450 pmic driver") Signed-off-by: Peng Fan Link: https://patch.msgid.link/20260310-pca9450-irq-v1-1-36adf52c2c55@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0b6803777c0038ad1efff857600a2e16ab2093b5 Author: Chen Ni Date: Fri Mar 6 11:56:48 2026 +0800 perf annotate: Fix hashmap__new() error checking [ Upstream commit bf29cb3641b80bac759c3332b02e0b270e16bf94 ] The hashmap__new() function never returns NULL, it returns error pointers. Fix the error checking to match. Additionally, set src->samples to NULL to prevent any later code from accidentally using the error pointer. Fixes: d3e7cad6f36d9e80 ("perf annotate: Add a hashmap for symbol histogram") Reviewed-by: Ian Rogers Signed-off-by: Chen Ni Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Tianyou Li Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit f5ef97c13165542480a6ffdbe6f09f40bbb7cbf1 Author: Yuan Tan Date: Mon Mar 9 03:41:46 2026 -0700 netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels [ Upstream commit 329f0b9b48ee6ab59d1ab72fef55fe8c6463a6cf ] IDLETIMER revision 0 rules reuse existing timers by label and always call mod_timer() on timer->timer. If the label was created first by revision 1 with XT_IDLETIMER_ALARM, the object uses alarm timer semantics and timer->timer is never initialized. Reusing that object from revision 0 causes mod_timer() on an uninitialized timer_list, triggering debugobjects warnings and possible panic when panic_on_warn=1. Fix this by rejecting revision 0 rule insertion when an existing timer with the same label is of ALARM type. Fixes: 68983a354a65 ("netfilter: xtables: Add snapshot of hardidletimer target") Co-developed-by: Yifan Wu Signed-off-by: Yifan Wu Co-developed-by: Juefei Pu Signed-off-by: Juefei Pu Signed-off-by: Yuan Tan Signed-off-by: Xin Liu Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 05018cd9370f77bb18fbf6e15ff33c7a06f10b3c Author: Hyunwoo Kim Date: Sun Mar 8 02:23:34 2026 +0900 netfilter: nfnetlink_cthelper: fix OOB read in nfnl_cthelper_dump_table() [ Upstream commit 6dcee8496d53165b2d8a5909b3050b62ae71fe89 ] nfnl_cthelper_dump_table() has a 'goto restart' that jumps to a label inside the for loop body. When the "last" helper saved in cb->args[1] is deleted between dump rounds, every entry fails the (cur != last) check, so cb->args[1] is never cleared. The for loop finishes with cb->args[0] == nf_ct_helper_hsize, and the 'goto restart' jumps back into the loop body bypassing the bounds check, causing an 8-byte out-of-bounds read on nf_ct_helper_hash[nf_ct_helper_hsize]. The 'goto restart' block was meant to re-traverse the current bucket when "last" is no longer found, but it was placed after the for loop instead of inside it. Move the block into the for loop body so that the restart only occurs while cb->args[0] is still within bounds. BUG: KASAN: slab-out-of-bounds in nfnl_cthelper_dump_table+0x9f/0x1b0 Read of size 8 at addr ffff888104ca3000 by task poc_cthelper/131 Call Trace: nfnl_cthelper_dump_table+0x9f/0x1b0 netlink_dump+0x333/0x880 netlink_recvmsg+0x3e2/0x4b0 sock_recvmsg+0xde/0xf0 __sys_recvfrom+0x150/0x200 __x64_sys_recvfrom+0x76/0x90 do_syscall_64+0xc3/0x6e0 Allocated by task 1: __kvmalloc_node_noprof+0x21b/0x700 nf_ct_alloc_hashtable+0x65/0xd0 nf_conntrack_helper_init+0x21/0x60 nf_conntrack_init_start+0x18d/0x300 nf_conntrack_standalone_init+0x12/0xc0 Fixes: 12f7a505331e ("netfilter: add user-space connection tracking helper infrastructure") Signed-off-by: Hyunwoo Kim Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 9853d94b82d303fc4ac37d592a23a154096ecd41 Author: Hyunwoo Kim Date: Sun Mar 8 02:24:06 2026 +0900 netfilter: nfnetlink_queue: fix entry leak in bridge verdict error path [ Upstream commit f1ba83755d81c6fc66ac7acd723d238f974091e9 ] nfqnl_recv_verdict() calls find_dequeue_entry() to remove the queue entry from the queue data structures, taking ownership of the entry. For PF_BRIDGE packets, it then calls nfqa_parse_bridge() to parse VLAN attributes. If nfqa_parse_bridge() returns an error (e.g. NFQA_VLAN present but NFQA_VLAN_TCI missing), the function returns immediately without freeing the dequeued entry or its sk_buff. This leaks the nf_queue_entry, its associated sk_buff, and all held references (net_device refcounts, struct net refcount). Repeated triggering exhausts kernel memory. Fix this by dropping the entry via nfqnl_reinject() with NF_DROP verdict on the error path, consistent with other error handling in this file. Fixes: 8d45ff22f1b4 ("netfilter: bridge: nf queue verdict to use NFQA_VLAN and NFQA_L2HDR") Reviewed-by: David Dull Signed-off-by: Hyunwoo Kim Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit bc18551c6169eac5ed813778d3e3e484002dbbe5 Author: David Dull Date: Sat Mar 7 20:26:21 2026 +0200 netfilter: x_tables: guard option walkers against 1-byte tail reads [ Upstream commit cfe770220ac2dbd3e104c6b45094037455da81d4 ] When the last byte of options is a non-single-byte option kind, walkers that advance with i += op[i + 1] ? : 1 can read op[i + 1] past the end of the option area. Add an explicit i == optlen - 1 check before dereferencing op[i + 1] in xt_tcpudp and xt_dccp option walkers. Fixes: 2e4e6a17af35 ("[NETFILTER] x_tables: Abstraction layer for {ip,ip6,arp}_tables") Signed-off-by: David Dull Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit e047f6fbb975f685d6c9fcef95b3b7787a79b46d Author: Jenny Guanni Qu Date: Fri Mar 6 19:12:38 2026 +0000 netfilter: nft_set_pipapo: fix stack out-of-bounds read in pipapo_drop() [ Upstream commit d6d8cd2db236a9dd13dbc2d05843b3445cc964b5 ] pipapo_drop() passes rulemap[i + 1].n to pipapo_unmap() as the to_offset argument on every iteration, including the last one where i == m->field_count - 1. This reads one element past the end of the stack-allocated rulemap array (declared as rulemap[NFT_PIPAPO_MAX_FIELDS] with NFT_PIPAPO_MAX_FIELDS == 16). Although pipapo_unmap() returns early when is_last is true without using the to_offset value, the argument is evaluated at the call site before the function body executes, making this a genuine out-of-bounds stack read confirmed by KASAN: BUG: KASAN: stack-out-of-bounds in pipapo_drop+0x50c/0x57c [nf_tables] Read of size 4 at addr ffff8000810e71a4 This frame has 1 object: [32, 160) 'rulemap' The buggy address is at offset 164 -- exactly 4 bytes past the end of the rulemap array. Pass 0 instead of rulemap[i + 1].n on the last iteration to avoid the out-of-bounds read. Fixes: 3c4287f62044 ("nf_tables: Add set type for arbitrary concatenation of ranges") Signed-off-by: Jenny Guanni Qu Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit de47a88c6b807910f05703fb6605f7efdaa11417 Author: Florian Westphal Date: Thu Mar 5 21:32:00 2026 +0100 netfilter: nf_tables: always walk all pending catchall elements [ Upstream commit 7cb9a23d7ae40a702577d3d8bacb7026f04ac2a9 ] During transaction processing we might have more than one catchall element: 1 live catchall element and 1 pending element that is coming as part of the new batch. If the map holding the catchall elements is also going away, its required to toggle all catchall elements and not just the first viable candidate. Otherwise, we get: WARNING: ./include/net/netfilter/nf_tables.h:1281 at nft_data_release+0xb7/0xe0 [nf_tables], CPU#2: nft/1404 RIP: 0010:nft_data_release+0xb7/0xe0 [nf_tables] [..] __nft_set_elem_destroy+0x106/0x380 [nf_tables] nf_tables_abort_release+0x348/0x8d0 [nf_tables] nf_tables_abort+0xcf2/0x3ac0 [nf_tables] nfnetlink_rcv_batch+0x9c9/0x20e0 [..] Fixes: 628bd3e49cba ("netfilter: nf_tables: drop map element references from preparation phase") Reported-by: Yiming Qian Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 6d2a95c6890577cc3eab2b20018e16850d7fb094 Author: Phil Sutter Date: Thu Mar 5 13:01:44 2026 +0100 netfilter: nf_tables: Fix for duplicate device in netdev hooks [ Upstream commit b7cdc5a97d02c943f4bdde4d5767ad0c13cad92b ] When handling NETDEV_REGISTER notification, duplicate device registration must be avoided since the device may have been added by nft_netdev_hook_alloc() already when creating the hook. Suggested-by: Florian Westphal Reported-by: syzbot+bb9127e278fa198e110c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=bb9127e278fa198e110c Fixes: a331b78a5525 ("netfilter: nf_tables: Respect NETDEV_REGISTER events") Tested-by: Helen Koike Signed-off-by: Phil Sutter Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 8a57deeb256069f262957d8012418559ff66c385 Author: Weiming Shi Date: Sat Mar 7 00:01:34 2026 +0800 net: add xmit recursion limit to tunnel xmit functions [ Upstream commit 6f1a9140ecda3baba3d945b9a6155af4268aafc4 ] Tunnel xmit functions (iptunnel_xmit, ip6tunnel_xmit) lack their own recursion limit. When a bond device in broadcast mode has GRE tap interfaces as slaves, and those GRE tunnels route back through the bond, multicast/broadcast traffic triggers infinite recursion between bond_xmit_broadcast() and ip_tunnel_xmit()/ip6_tnl_xmit(), causing kernel stack overflow. The existing XMIT_RECURSION_LIMIT (8) in the no-qdisc path is not sufficient because tunnel recursion involves route lookups and full IP output, consuming much more stack per level. Use a lower limit of 4 (IP_TUNNEL_RECURSION_LIMIT) to prevent overflow. Add recursion detection using dev_xmit_recursion helpers directly in iptunnel_xmit() and ip6tunnel_xmit() to cover all IPv4/IPv6 tunnel paths including UDP encapsulated tunnels (VXLAN, Geneve, etc.). Move dev_xmit_recursion helpers from net/core/dev.h to public header include/linux/netdevice.h so they can be used by tunnel code. BUG: KASAN: stack-out-of-bounds in blake2s.constprop.0+0xe7/0x160 Write of size 32 at addr ffff88810033fed0 by task kworker/0:1/11 Workqueue: mld mld_ifc_work Call Trace: __build_flow_key.constprop.0 (net/ipv4/route.c:515) ip_rt_update_pmtu (net/ipv4/route.c:1073) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:84) ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847) gre_tap_xmit (net/ipv4/ip_gre.c:779) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279) bond_start_xmit (drivers/net/bonding/bond_main.c:5530) dev_hard_start_xmit (net/core/dev.c:3887) __dev_queue_xmit (net/core/dev.c:4841) ip_finish_output2 (net/ipv4/ip_output.c:237) ip_output (net/ipv4/ip_output.c:438) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:86) gre_tap_xmit (net/ipv4/ip_gre.c:779) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279) bond_start_xmit (drivers/net/bonding/bond_main.c:5530) dev_hard_start_xmit (net/core/dev.c:3887) __dev_queue_xmit (net/core/dev.c:4841) ip_finish_output2 (net/ipv4/ip_output.c:237) ip_output (net/ipv4/ip_output.c:438) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:86) ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847) gre_tap_xmit (net/ipv4/ip_gre.c:779) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279) bond_start_xmit (drivers/net/bonding/bond_main.c:5530) dev_hard_start_xmit (net/core/dev.c:3887) __dev_queue_xmit (net/core/dev.c:4841) mld_sendpack mld_ifc_work process_one_work worker_thread Fixes: 745e20f1b626 ("net: add a recursion limit in xmit path") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Link: https://patch.msgid.link/20260306160133.3852900-2-bestswngs@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f0679522f8ded6b3507ae171d6a48e3d2cfd7925 Author: Raju Rangoju Date: Fri Mar 6 16:46:28 2026 +0530 amd-xgbe: prevent CRC errors during RX adaptation with AN disabled [ Upstream commit 27a4dd0c702b3b2b9cf2c045d100cc2fe8720b81 ] When operating in 10GBASE-KR mode with auto-negotiation disabled and RX adaptation enabled, CRC errors can occur during the RX adaptation process. This happens because the driver continues transmitting and receiving packets while adaptation is in progress. Fix this by stopping TX/RX immediately when the link goes down and RX adaptation needs to be re-triggered, and only re-enabling TX/RX after adaptation completes and the link is confirmed up. Introduce a flag to track whether TX/RX was disabled for adaptation so it can be restored correctly. This prevents packets from being transmitted or received during the RX adaptation window and avoids CRC errors from corrupted frames. The flag tracking the data path state is synchronized with hardware state in xgbe_start() to prevent stale state after device restarts. This ensures that after a restart cycle (where xgbe_stop disables TX/RX and xgbe_start re-enables them), the flag correctly reflects that the data path is active. Fixes: 4f3b20bfbb75 ("amd-xgbe: add support for rx-adaptation") Signed-off-by: Raju Rangoju Link: https://patch.msgid.link/20260306111629.1515676-3-Raju.Rangoju@amd.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit cf51e5853398e0f33aab48f520718c79b45fa0e0 Author: Raju Rangoju Date: Fri Mar 6 16:46:27 2026 +0530 amd-xgbe: fix link status handling in xgbe_rx_adaptation [ Upstream commit 6485cb96be5cd0f4bf39554737ba11322cc9b053 ] The link status bit is latched low to allow detection of momentary link drops. If the status indicates that the link is already down, read it again to obtain the current state. Fixes: 4f3b20bfbb75 ("amd-xgbe: add support for rx-adaptation") Signed-off-by: Raju Rangoju Link: https://patch.msgid.link/20260306111629.1515676-2-Raju.Rangoju@amd.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 925a5ffd99cddd7a7e41d5ad120c7a2c6d50260f Author: Chengfeng Ye Date: Fri Mar 6 03:14:02 2026 +0000 mctp: route: hold key->lock in mctp_flow_prepare_output() [ Upstream commit 7d86aa41c073c4e7eb75fd2e674f1fd8f289728a ] mctp_flow_prepare_output() checks key->dev and may call mctp_dev_set_key(), but it does not hold key->lock while doing so. mctp_dev_set_key() and mctp_dev_release_key() are annotated with __must_hold(&key->lock), so key->dev access is intended to be serialized by key->lock. The mctp_sendmsg() transmit path reaches mctp_flow_prepare_output() via mctp_local_output() -> mctp_dst_output() without holding key->lock, so the check-and-set sequence is racy. Example interleaving: CPU0 CPU1 ---- ---- mctp_flow_prepare_output(key, devA) if (!key->dev) // sees NULL mctp_flow_prepare_output( key, devB) if (!key->dev) // still NULL mctp_dev_set_key(devB, key) mctp_dev_hold(devB) key->dev = devB mctp_dev_set_key(devA, key) mctp_dev_hold(devA) key->dev = devA // overwrites devB Now both devA and devB references were acquired, but only the final key->dev value is tracked for release. One reference can be lost, causing a resource leak as mctp_dev_release_key() would only decrease the reference on one dev. Fix by taking key->lock around the key->dev check and mctp_dev_set_key() call. Fixes: 67737c457281 ("mctp: Pass flow data & flow release events to drivers") Signed-off-by: Chengfeng Ye Link: https://patch.msgid.link/20260306031402.857224-1-dg573847474@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 6ac890f1d60ac3707ee8dae15a67d9a833e49956 Author: Jiayuan Chen Date: Fri Mar 6 10:15:07 2026 +0800 bonding: fix type confusion in bond_setup_by_slave() [ Upstream commit 950803f7254721c1c15858fbbfae3deaaeeecb11 ] kernel BUG at net/core/skbuff.c:2306! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:pskb_expand_head+0xa08/0xfe0 net/core/skbuff.c:2306 RSP: 0018:ffffc90004aff760 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff88807e3c8780 RCX: ffffffff89593e0e RDX: ffff88807b7c4900 RSI: ffffffff89594747 RDI: ffff88807b7c4900 RBP: 0000000000000820 R08: 0000000000000005 R09: 0000000000000000 R10: 00000000961a63e0 R11: 0000000000000000 R12: ffff88807e3c8780 R13: 00000000961a6560 R14: dffffc0000000000 R15: 00000000961a63e0 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe1a0ed8df0 CR3: 000000002d816000 CR4: 00000000003526f0 Call Trace: ipgre_header+0xdd/0x540 net/ipv4/ip_gre.c:900 dev_hard_header include/linux/netdevice.h:3439 [inline] packet_snd net/packet/af_packet.c:3028 [inline] packet_sendmsg+0x3ae5/0x53c0 net/packet/af_packet.c:3108 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa54/0xc30 net/socket.c:2592 ___sys_sendmsg+0x190/0x1e0 net/socket.c:2646 __sys_sendmsg+0x170/0x220 net/socket.c:2678 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe1a0e6c1a9 When a non-Ethernet device (e.g. GRE tunnel) is enslaved to a bond, bond_setup_by_slave() directly copies the slave's header_ops to the bond device: bond_dev->header_ops = slave_dev->header_ops; This causes a type confusion when dev_hard_header() is later called on the bond device. Functions like ipgre_header(), ip6gre_header(),all use netdev_priv(dev) to access their device-specific private data. When called with the bond device, netdev_priv() returns the bond's private data (struct bonding) instead of the expected type (e.g. struct ip_tunnel), leading to garbage values being read and kernel crashes. Fix this by introducing bond_header_ops with wrapper functions that delegate to the active slave's header_ops using the slave's own device. This ensures netdev_priv() in the slave's header functions always receives the correct device. The fix is placed in the bonding driver rather than individual device drivers, as the root cause is bond blindly inheriting header_ops from the slave without considering that these callbacks expect a specific netdev_priv() layout. The type confusion can be observed by adding a printk in ipgre_header() and running the following commands: ip link add dummy0 type dummy ip addr add 10.0.0.1/24 dev dummy0 ip link set dummy0 up ip link add gre1 type gre local 10.0.0.1 ip link add bond1 type bond mode active-backup ip link set gre1 master bond1 ip link set gre1 up ip link set bond1 up ip addr add fe80::1/64 dev bond1 Fixes: 1284cd3a2b74 ("bonding: two small fixes for IPoIB support") Suggested-by: Jay Vosburgh Reviewed-by: Eric Dumazet Signed-off-by: Jiayuan Chen Link: https://patch.msgid.link/20260306021508.222062-1-jiayuan.chen@linux.dev Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 474211fb4a1df0c5adff71a891d2384d72f83078 Author: Hangbin Liu Date: Fri Oct 17 03:41:53 2025 +0000 bonding: use common function to compute the features [ Upstream commit d4fde269a970666a30dd3abd0413273a06dd972d ] Use the new functon netdev_compute_master_upper_features() to compute the bonding features. Note that bond_compute_features() currently uses bond_for_each_slave() to traverse the lower devices list, and that is just a macro wrapper of netdev_for_each_lower_private(). We use similar helper netdev_for_each_lower_dev() in netdev_compute_master_upper_features() to iterate the slave device, as there is not need to get the private data. No functional change intended. Signed-off-by: Hangbin Liu Reviewed-by: Sabrina Dubroca Reviewed-by: Jiri Pirko Link: https://patch.msgid.link/20251017034155.61990-3-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: 950803f72547 ("bonding: fix type confusion in bond_setup_by_slave()") Signed-off-by: Sasha Levin commit 3c5de399a442700d53696274782e0ee6e5d99560 Author: Wenyuan Li <2063309626@qq.com> Date: Tue Mar 10 13:08:44 2026 +0800 can: hi311x: hi3110_open(): add check for hi3110_power_enable() return value [ Upstream commit 47bba09b14fa21712398febf36cb14fd4fc3bded ] In hi3110_open(), the return value of hi3110_power_enable() is not checked. If power enable fails, the device may not function correctly, while the driver still returns success. Add a check for the return value and propagate the error accordingly. Signed-off-by: Wenyuan Li <2063309626@qq.com> Link: https://patch.msgid.link/tencent_B5E2E7528BB28AA8A2A56E16C49BD58B8B07@qq.com Fixes: 57e83fb9b746 ("can: hi311x: Add Holt HI-311x CAN driver") [mkl: adjust subject, commit message and jump label] Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 1ec54187e1aa40a4cfa2b265e9a311179f24b98d Author: Haiyue Wang Date: Thu Mar 5 22:32:34 2026 +0800 mctp: i2c: fix skb memory leak in receive path [ Upstream commit e3f5e0f22cfc2371e7471c9fd5b4da78f9df7c69 ] When 'midev->allow_rx' is false, the newly allocated skb isn't consumed by netif_rx(), it needs to free the skb directly. Fixes: f5b8abf9fc3d ("mctp i2c: MCTP I2C binding driver") Signed-off-by: Haiyue Wang Link: https://patch.msgid.link/20260305143240.97592-1-haiyuewa@163.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 569e6e72c45788a5991444e5cbef0fed642006b9 Author: Pavan Chebbi Date: Fri Mar 6 14:58:54 2026 -0800 bnxt_en: Fix RSS table size check when changing ethtool channels [ Upstream commit 0d9a60a0618d255530ca56072c5f39eb58e1ed4a ] When changing channels, the current check in bnxt_set_channels() is not checking for non-default RSS contexts when the RSS table size changes. The current check for IFF_RXFH_CONFIGURED is only sufficient for the default RSS context. Expand the check to include the presence of any non-default RSS contexts. Allowing such change will result in incorrect configuration of the context's RSS table when the table size changes. Fixes: b3d0083caf9a ("bnxt_en: Support RSS contexts in ethtool .{get|set}_rxfh()") Reported-by: Björn Töpel Link: https://lore.kernel.org/netdev/20260303181535.2671734-1-bjorn@kernel.org/ Reviewed-by: Andy Gospodarek Signed-off-by: Pavan Chebbi Signed-off-by: Michael Chan Link: https://patch.msgid.link/20260306225854.3575672-1-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 35b58d3bc716ebb9ebd10fe1cac8c1177242511c Author: Shuangpeng Bai Date: Thu Mar 5 22:40:06 2026 -0500 serial: caif: hold tty->link reference in ldisc_open and ser_release [ Upstream commit 288598d80a068a0e9281de35bcb4ce495f189e2a ] A reproducer triggers a KASAN slab-use-after-free in pty_write_room() when caif_serial's TX path calls tty_write_room(). The faulting access is on tty->link->port. Hold an extra kref on tty->link for the lifetime of the caif_serial line discipline: get it in ldisc_open() and drop it in ser_release(), and also drop it on the ldisc_open() error path. With this change applied, the reproducer no longer triggers the UAF in my testing. Link: https://gist.github.com/shuangpengbai/c898debad6bdf170a84be7e6b3d8707f Link: https://lore.kernel.org/netdev/20260301220525.1546355-1-shuangpeng.kernel@gmail.com Fixes: e31d5a05948e ("caif: tty's are kref objects so take a reference") Signed-off-by: Shuangpeng Bai Reviewed-by: Jiayuan Chen Link: https://patch.msgid.link/20260306034006.3395740-1-shuangpeng.kernel@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ecb4ed7a723f02c81a0111a13ceeabb26f50f899 Author: Álvaro Fernández Rojas Date: Fri Mar 6 13:29:55 2026 +0100 net: sfp: improve Huawei MA5671a fixup [ Upstream commit 87d126852158467ab87d5cbc36ccfd3f15464a6c ] With the current sfp_fixup_ignore_tx_fault() fixup we ignore the TX_FAULT signal, but we also need to apply sfp_fixup_ignore_los() in order to be able to communicate with the module even if the fiber isn't connected for configuration purposes. This is needed for all the MA5671a firmwares, excluding the FS modded firmware. Fixes: 2069624dac19 ("net: sfp: Add tx-fault workaround for Huawei MA5671A SFP ONT") Signed-off-by: Álvaro Fernández Rojas Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260306125139.213637-1-noltari@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ce0b8fd5e35545b352113282a43959e512f7fe03 Author: Sen Wang Date: Sun Mar 8 23:21:09 2026 -0500 ASoC: simple-card-utils: fix graph_util_is_ports0() for DT overlays [ Upstream commit 4185b95f8a42d92d68c49289b4644546b51e252b ] graph_util_is_ports0() identifies DPCM front-end (ports@0) vs back-end (ports@1) by calling of_get_child_by_name() to find the first "ports" child and comparing pointers. This relies on child iteration order matching DTS source order. When the DPCM topology comes from a DT overlay, __of_attach_node() inserts new children at the head of the sibling list, reversing the order. of_get_child_by_name() then returns ports@1 instead of ports@0, causing all front-end links to be classified as back-ends. The card registers with no PCM devices. Fix this by matching the unit address directly from the node name instead of relying on sibling order. Fixes: 92939252458f ("ASoC: simple-card-utils: add asoc_graph_is_ports0()") Signed-off-by: Sen Wang Acked-by: Kuninori Morimoto Link: https://patch.msgid.link/20260309042109.2576612-1-sen@ti.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7d33e6140945482a07f8089ee86e13e02553ffdb Author: matteo.cotifava Date: Mon Mar 9 22:54:12 2026 +0100 ASoC: soc-core: flush delayed work before removing DAIs and widgets [ Upstream commit 95bc5c225513fc3c4ce169563fb5e3929fbb938b ] When a sound card is unbound while a PCM stream is open, a use-after-free can occur in snd_soc_dapm_stream_event(), called from the close_delayed_work workqueue handler. During unbind, snd_soc_unbind_card() flushes delayed work and then calls soc_cleanup_card_resources(). Inside cleanup, snd_card_disconnect_sync() releases all PCM file descriptors, and the resulting PCM close path can call snd_soc_dapm_stream_stop() which schedules new delayed work with a pmdown_time timer delay. Since this happens after the flush in snd_soc_unbind_card(), the new work is not caught. soc_remove_link_components() then frees DAPM widgets before this work fires, leading to the use-after-free. The existing flush in soc_free_pcm_runtime() also cannot help as it runs after soc_remove_link_components() has already freed the widgets. Add a flush in soc_cleanup_card_resources() after snd_card_disconnect_sync() (after which no new PCM closes can schedule further delayed work) and before soc_remove_link_dais() and soc_remove_link_components() (which tear down the structures the delayed work accesses). Fixes: e894efef9ac7 ("ASoC: core: add support to card rebind") Signed-off-by: Matteo Cotifava Link: https://patch.msgid.link/20260309215412.545628-3-cotifavamatteo@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a4aa08c820f4f971824026585505c2d32de5386f Author: matteo.cotifava Date: Mon Mar 9 22:54:11 2026 +0100 ASoC: soc-core: drop delayed_work_pending() check before flush [ Upstream commit 3c99c9f0ed60582c1c9852b685d78d5d3a50de63 ] The delayed_work_pending() check before flush_delayed_work() in soc_free_pcm_runtime() is unnecessary and racy. flush_delayed_work() is safe to call unconditionally - it is a no-op when no work is pending. Remove the check. The original check was added by commit 9c9b65203492 ("ASoC: core: only flush inited work during free") but delayed_work_pending() followed by flush_delayed_work() has a time-of-check/time-of-use window where work can become pending between the two calls. Fixes: 9c9b65203492 ("ASoC: core: only flush inited work during free") Signed-off-by: Matteo Cotifava Link: https://patch.msgid.link/20260309215412.545628-2-cotifavamatteo@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b6051f2bdd4bd3dde85b68558edd3a6843489221 Author: Felix Gu Date: Tue Mar 10 02:01:34 2026 +0800 spi: rockchip-sfc: Fix double-free in remove() callback [ Upstream commit 111e2863372c322e836e0c896f6dd9cf4ee08c71 ] The driver uses devm_spi_register_controller() for registration, which automatically unregisters the controller via devm cleanup when the device is removed. The manual call to spi_unregister_controller() in the remove() callback can lead to a double-free. And to make sure controller is unregistered before DMA buffer is unmapped, switch to use spi_register_controller() in probe(). Fixes: 8011709906d0 ("spi: rockchip-sfc: Support pm ops") Signed-off-by: Felix Gu Link: https://patch.msgid.link/20260310-sfc-v2-1-67fab04b097f@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0a83d6c9e149a176340190fa9cbadf2266db4c9a Author: Felix Gu Date: Fri Mar 6 01:24:32 2026 +0800 spi: amlogic: spifc-a4: Fix DMA mapping error handling [ Upstream commit b20b437666e1cb26a7c499d1664e8f2a0ac67000 ] Fix three bugs in aml_sfc_dma_buffer_setup() error paths: 1. Unnecessary goto: When the first DMA mapping (sfc->daddr) fails, nothing needs cleanup. Use direct return instead of goto. 2. Double-unmap bug: When info DMA mapping failed, the code would unmap sfc->daddr inline, then fall through to out_map_data which would unmap it again, causing a double-unmap. 3. Wrong unmap size: The out_map_info label used datalen instead of infolen when unmapping sfc->iaddr, which could lead to incorrect DMA sync behavior. Fixes: 4670db6f32e9 ("spi: amlogic: add driver for Amlogic SPI Flash Controller") Signed-off-by: Felix Gu Link: https://patch.msgid.link/20260306-spifc-a4-v1-1-f22c9965f64a@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fc7735caf016a38261f0edb3144baeba5d84f2e9 Author: David Lechner Date: Sat Feb 28 22:30:30 2026 -0600 drm/sitronix/st7586: fix bad pixel data due to byte swap [ Upstream commit 46d8a07b4ae262e2fec6ce2aa454e06243661265 ] Correctly set dbi->write_memory_bpw for the ST7586 driver. This driver is for a monochrome display that has an unusual data format, so the default value set in mipi_dbi_spi_init() is not correct simply because this controller is non-standard. Previously, we were using dbi->swap_bytes to make the same sort of workaround, but it was removed in the same commit that added dbi->write_memory_bpw, so we need to use the latter now to have the correct behavior. This fixes every 3 columns of pixels being swapped on the display. There are 3 pixels per byte, so the byte swap caused this effect. Fixes: df3fb27a74a4 ("drm/mipi-dbi: Make bits per word configurable for pixel transfers") Acked-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Signed-off-by: David Lechner Link: https://patch.msgid.link/20260228-drm-mipi-dbi-fix-st7586-byte-swap-v1-1-e78f6c24cd28@baylibre.com Signed-off-by: Sasha Levin commit c34ebd7b24ea70be3c6fdb6936f79f593f37df60 Author: Vivian Wang Date: Thu Mar 5 14:39:39 2026 +0800 net: spacemit: Fix error handling in emac_tx_mem_map() [ Upstream commit 86292155bea578ebab0ca3b65d4d87ecd8a0e9ea ] The DMA mappings were leaked on mapping error. Free them with the existing emac_free_tx_buf() function. Fixes: bfec6d7f2001 ("net: spacemit: Add K1 Ethernet MAC") Signed-off-by: Vivian Wang Link: https://patch.msgid.link/20260305-k1-ethernet-more-fixes-v2-2-e4e434d65055@iscas.ac.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 045545790fea76f02360e91ebd12aca5a0055827 Author: Vivian Wang Date: Thu Mar 5 14:39:38 2026 +0800 net: spacemit: Fix error handling in emac_alloc_rx_desc_buffers() [ Upstream commit 3aa1417803c1833cbd5bacb7e6a6489a196f2519 ] Even if we get a dma_mapping_error() while mapping an RX buffer, we should still update rx_ring->head to ensure that the buffers we were able to allocate and map are used. Fix this by breaking out to the existing code after the loop, analogous to the existing handling for skb allocation failure. Fixes: bfec6d7f2001 ("net: spacemit: Add K1 Ethernet MAC") Signed-off-by: Vivian Wang Link: https://patch.msgid.link/20260305-k1-ethernet-more-fixes-v2-1-e4e434d65055@iscas.ac.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d55fa7cd4b19ba91b34b307d769c149e56ad0a75 Author: Miaoqian Lin Date: Thu Mar 5 12:31:01 2026 +0000 rxrpc, afs: Fix missing error pointer check after rxrpc_kernel_lookup_peer() [ Upstream commit 4245a79003adf30e67f8e9060915bd05cb31d142 ] rxrpc_kernel_lookup_peer() can also return error pointers in addition to NULL, so just checking for NULL is not sufficient. Fix this by: (1) Changing rxrpc_kernel_lookup_peer() to return -ENOMEM rather than NULL on allocation failure. (2) Making the callers in afs use IS_ERR() and PTR_ERR() to pass on the error code returned. Fixes: 72904d7b9bfb ("rxrpc, afs: Allow afs to pin rxrpc_peer objects") Signed-off-by: Miaoqian Lin Co-developed-by: David Howells Signed-off-by: David Howells cc: Marc Dionne cc: Simon Horman cc: linux-afs@lists.infradead.org Link: https://patch.msgid.link/368272.1772713861@warthog.procyon.org.uk Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0bad9c86edd22dec4df83c2b29872d66fd8a2ff4 Author: Weiming Shi Date: Wed Mar 4 12:42:18 2026 +0800 net/sched: teql: fix NULL pointer dereference in iptunnel_xmit on TEQL slave xmit [ Upstream commit 0cc0c2e661af418bbf7074179ea5cfffc0a5c466 ] teql_master_xmit() calls netdev_start_xmit(skb, slave) to transmit through slave devices, but does not update skb->dev to the slave device beforehand. When a gretap tunnel is a TEQL slave, the transmit path reaches iptunnel_xmit() which saves dev = skb->dev (still pointing to teql0 master) and later calls iptunnel_xmit_stats(dev, pkt_len). This function does: get_cpu_ptr(dev->tstats) Since teql_master_setup() does not set dev->pcpu_stat_type to NETDEV_PCPU_STAT_TSTATS, the core network stack never allocates tstats for teql0, so dev->tstats is NULL. get_cpu_ptr(NULL) computes NULL + __per_cpu_offset[cpu], resulting in a page fault. BUG: unable to handle page fault for address: ffff8880e6659018 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 68bc067 P4D 68bc067 PUD 0 Oops: Oops: 0002 [#1] SMP KASAN PTI RIP: 0010:iptunnel_xmit (./include/net/ip_tunnels.h:664 net/ipv4/ip_tunnel_core.c:89) Call Trace: ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847) __gre_xmit (net/ipv4/ip_gre.c:478) gre_tap_xmit (net/ipv4/ip_gre.c:779) teql_master_xmit (net/sched/sch_teql.c:319) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) neigh_direct_output (net/core/neighbour.c:1660) ip_finish_output2 (net/ipv4/ip_output.c:237) __ip_finish_output.part.0 (net/ipv4/ip_output.c:315) ip_mc_output (net/ipv4/ip_output.c:369) ip_send_skb (net/ipv4/ip_output.c:1508) udp_send_skb (net/ipv4/udp.c:1195) udp_sendmsg (net/ipv4/udp.c:1485) inet_sendmsg (net/ipv4/af_inet.c:859) __sys_sendto (net/socket.c:2206) Fix this by setting skb->dev = slave before calling netdev_start_xmit(), so that tunnel xmit functions see the correct slave device with properly allocated tstats. Fixes: 039f50629b7f ("ip_tunnel: Move stats update to iptunnel_xmit()") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Link: https://patch.msgid.link/20260304044216.3517851-3-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c74557495efb4bd0adefdfc8678ecdbc82a06da3 Author: Dragos Tatulea Date: Thu Mar 5 16:26:34 2026 +0200 net/mlx5e: RX, Fix XDP multi-buf frag counting for legacy RQ [ Upstream commit a6413e6f6c9d9bb9833324cb3753582f7bc0f2fa ] XDP multi-buf programs can modify the layout of the XDP buffer when the program calls bpf_xdp_pull_data() or bpf_xdp_adjust_tail(). The referenced commit in the fixes tag corrected the assumption in the mlx5 driver that the XDP buffer layout doesn't change during a program execution. However, this fix introduced another issue: the dropped fragments still need to be counted on the driver side to avoid page fragment reference counting issues. Such issue can be observed with the test_xdp_native_adjst_tail_shrnk_data selftest when using a payload of 3600 and shrinking by 256 bytes (an upcoming selftest patch): the last fragment gets released by the XDP code but doesn't get tracked by the driver. This results in a negative pp_ref_count during page release and the following splat: WARNING: include/net/page_pool/helpers.h:297 at mlx5e_page_release_fragmented.isra.0+0x4a/0x50 [mlx5_core], CPU#12: ip/3137 Modules linked in: [...] CPU: 12 UID: 0 PID: 3137 Comm: ip Not tainted 6.19.0-rc3+ #12 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5e_page_release_fragmented.isra.0+0x4a/0x50 [mlx5_core] [...] Call Trace: mlx5e_dealloc_rx_wqe+0xcb/0x1a0 [mlx5_core] mlx5e_free_rx_descs+0x7f/0x110 [mlx5_core] mlx5e_close_rq+0x50/0x60 [mlx5_core] mlx5e_close_queues+0x36/0x2c0 [mlx5_core] mlx5e_close_channel+0x1c/0x50 [mlx5_core] mlx5e_close_channels+0x45/0x80 [mlx5_core] mlx5e_safe_switch_params+0x1a5/0x230 [mlx5_core] mlx5e_change_mtu+0xf3/0x2f0 [mlx5_core] netif_set_mtu_ext+0xf1/0x230 do_setlink.isra.0+0x219/0x1180 rtnl_newlink+0x79f/0xb60 rtnetlink_rcv_msg+0x213/0x3a0 netlink_rcv_skb+0x48/0xf0 netlink_unicast+0x24a/0x350 netlink_sendmsg+0x1ee/0x410 __sock_sendmsg+0x38/0x60 ____sys_sendmsg+0x232/0x280 ___sys_sendmsg+0x78/0xb0 __sys_sendmsg+0x5f/0xb0 [...] do_syscall_64+0x57/0xc50 This patch fixes the issue by doing page frag counting on all the original XDP buffer fragments for all relevant XDP actions (XDP_TX , XDP_REDIRECT and XDP_PASS). This is basically reverting to the original counting before the commit in the fixes tag. As frag_page is still pointing to the original tail, the nr_frags parameter to xdp_update_skb_frags_info() needs to be calculated in a different way to reflect the new nr_frags. Fixes: afd5ba577c10 ("net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for legacy RQ") Signed-off-by: Dragos Tatulea Signed-off-by: Tariq Toukan Reviewed-by: Amery Hung Link: https://patch.msgid.link/20260305142634.1813208-6-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7d7342a18fadcdb70a63b3c930dc63528ce51832 Author: Dragos Tatulea Date: Thu Mar 5 16:26:33 2026 +0200 net/mlx5e: RX, Fix XDP multi-buf frag counting for striding RQ [ Upstream commit db25c42c2e1f9c0d136420fff5e5700f7e771a6f ] XDP multi-buf programs can modify the layout of the XDP buffer when the program calls bpf_xdp_pull_data() or bpf_xdp_adjust_tail(). The referenced commit in the fixes tag corrected the assumption in the mlx5 driver that the XDP buffer layout doesn't change during a program execution. However, this fix introduced another issue: the dropped fragments still need to be counted on the driver side to avoid page fragment reference counting issues. The issue was discovered by the drivers/net/xdp.py selftest, more specifically the test_xdp_native_tx_mb: - The mlx5 driver allocates a page_pool page and initializes it with a frag counter of 64 (pp_ref_count=64) and the internal frag counter to 0. - The test sends one packet with no payload. - On RX (mlx5e_skb_from_cqe_mpwrq_nonlinear()), mlx5 configures the XDP buffer with the packet data starting in the first fragment which is the page mentioned above. - The XDP program runs and calls bpf_xdp_pull_data() which moves the header into the linear part of the XDP buffer. As the packet doesn't contain more data, the program drops the tail fragment since it no longer contains any payload (pp_ref_count=63). - mlx5 device skips counting this fragment. Internal frag counter remains 0. - mlx5 releases all 64 fragments of the page but page pp_ref_count is 63 => negative reference counting error. Resulting splat during the test: WARNING: CPU: 0 PID: 188225 at ./include/net/page_pool/helpers.h:297 mlx5e_page_release_fragmented.isra.0+0xbd/0xe0 [mlx5_core] Modules linked in: [...] CPU: 0 UID: 0 PID: 188225 Comm: ip Not tainted 6.18.0-rc7_for_upstream_min_debug_2025_12_08_11_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5e_page_release_fragmented.isra.0+0xbd/0xe0 [mlx5_core] [...] Call Trace: mlx5e_free_rx_mpwqe+0x20a/0x250 [mlx5_core] mlx5e_dealloc_rx_mpwqe+0x37/0xb0 [mlx5_core] mlx5e_free_rx_descs+0x11a/0x170 [mlx5_core] mlx5e_close_rq+0x78/0xa0 [mlx5_core] mlx5e_close_queues+0x46/0x2a0 [mlx5_core] mlx5e_close_channel+0x24/0x90 [mlx5_core] mlx5e_close_channels+0x5d/0xf0 [mlx5_core] mlx5e_safe_switch_params+0x2ec/0x380 [mlx5_core] mlx5e_change_mtu+0x11d/0x490 [mlx5_core] mlx5e_change_nic_mtu+0x19/0x30 [mlx5_core] netif_set_mtu_ext+0xfc/0x240 do_setlink.isra.0+0x226/0x1100 rtnl_newlink+0x7a9/0xba0 rtnetlink_rcv_msg+0x220/0x3c0 netlink_rcv_skb+0x4b/0xf0 netlink_unicast+0x255/0x380 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 ____sys_sendmsg+0x1e8/0x240 ___sys_sendmsg+0x7c/0xb0 [...] __sys_sendmsg+0x5f/0xb0 do_syscall_64+0x55/0xc70 The problem applies for XDP_PASS as well which is handled in a different code path in the driver. This patch fixes the issue by doing page frag counting on all the original XDP buffer fragments for all relevant XDP actions (XDP_TX , XDP_REDIRECT and XDP_PASS). This is basically reverting to the original counting before the commit in the fixes tag. As frag_page is still pointing to the original tail, the nr_frags parameter to xdp_update_skb_frags_info() needs to be calculated in a different way to reflect the new nr_frags. Fixes: 87bcef158ac1 ("net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for striding RQ") Signed-off-by: Dragos Tatulea Cc: Amery Hung Reviewed-by: Nimrod Oren Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260305142634.1813208-5-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ce1b19dd0684eeb68a124c11085bd611260b36d9 Author: Gal Pressman Date: Thu Mar 5 16:26:32 2026 +0200 net/mlx5e: Fix DMA FIFO desync on error CQE SQ recovery [ Upstream commit 1633111d69053512d099658d4a05fc736fab36b0 ] In case of a TX error CQE, a recovery flow is triggered, mlx5e_reset_txqsq_cc_pc() resets dma_fifo_cc to 0 but not dma_fifo_pc, desyncing the DMA FIFO producer and consumer. After recovery, the producer pushes new DMA entries at the old dma_fifo_pc, while the consumer reads from position 0. This causes us to unmap stale DMA addresses from before the recovery. The DMA FIFO is a purely software construct with no HW counterpart. At the point of reset, all WQEs have been flushed so dma_fifo_cc is already equal to dma_fifo_pc. There is no need to reset either counter, similar to how skb_fifo pc/cc are untouched. Remove the 'dma_fifo_cc = 0' reset. This fixes the following WARNING: WARNING: CPU: 0 PID: 0 at drivers/iommu/dma-iommu.c:1240 iommu_dma_unmap_page+0x79/0x90 Modules linked in: mlx5_vdpa vringh vdpa bonding mlx5_ib mlx5_vfio_pci ipip mlx5_fwctl tunnel4 mlx5_core ib_ipoib geneve ip6_gre ip_gre gre nf_tables ip6_tunnel rdma_ucm ib_uverbs ib_umad vfio_pci vfio_pci_core act_mirred act_skbedit act_vlan vhost_net vhost tap ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress vhost_iotlb iptable_raw tunnel6 vfio_iommu_type1 vfio openvswitch nsh rpcsec_gss_krb5 auth_rpcgss oid_registry xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter overlay zram zsmalloc rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core fuse [last unloaded: nf_tables] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5_for_upstream_min_debug_2024_12_30_21_33 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:iommu_dma_unmap_page+0x79/0x90 Code: 2b 4d 3b 21 72 26 4d 3b 61 08 73 20 49 89 d8 44 89 f9 5b 4c 89 f2 4c 89 e6 48 89 ef 5d 41 5c 41 5d 41 5e 41 5f e9 c7 ae 9e ff <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00 Call Trace: ? __warn+0x7d/0x110 ? iommu_dma_unmap_page+0x79/0x90 ? report_bug+0x16d/0x180 ? handle_bug+0x4f/0x90 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? iommu_dma_unmap_page+0x79/0x90 ? iommu_dma_unmap_page+0x2e/0x90 dma_unmap_page_attrs+0x10d/0x1b0 mlx5e_tx_wi_dma_unmap+0xbe/0x120 [mlx5_core] mlx5e_poll_tx_cq+0x16d/0x690 [mlx5_core] mlx5e_napi_poll+0x8b/0xac0 [mlx5_core] __napi_poll+0x24/0x190 net_rx_action+0x32a/0x3b0 ? mlx5_eq_comp_int+0x7e/0x270 [mlx5_core] ? notifier_call_chain+0x35/0xa0 handle_softirqs+0xc9/0x270 irq_exit_rcu+0x71/0xd0 common_interrupt+0x7f/0xa0 asm_common_interrupt+0x22/0x40 Fixes: db75373c91b0 ("net/mlx5e: Recover Send Queue (SQ) from error state") Signed-off-by: Gal Pressman Reviewed-by: Dragos Tatulea Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260305142634.1813208-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cbd8494fdd6cc72c04ac2f9e2e01a7f3f2448016 Author: Carolina Jubran Date: Thu Mar 5 16:26:31 2026 +0200 net/mlx5: Fix peer miss rules host disabled checks [ Upstream commit 76324e4041c0efb4808702b05426d7a0a7d8df5b ] The check on mlx5_esw_host_functions_enabled(esw->dev) for adding VF peer miss rules is incorrect. These rules match traffic from peer's VFs, so the local device's host function status is irrelevant. Remove this check to ensure peer VF traffic is properly handled regardless of local host configuration. Also fix the PF peer miss rule deletion to be symmetric with the add path, so only attempt to delete the rule if it was actually created. Fixes: 520369ef43a8 ("net/mlx5: Support disabling host PFs") Signed-off-by: Carolina Jubran Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260305142634.1813208-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 835778685f157b4fd4683b670cfe4010265bac60 Author: Patrisious Haddad Date: Thu Mar 5 16:26:30 2026 +0200 net/mlx5: Fix crash when moving to switchdev mode [ Upstream commit 24b2795f9683e092dc22a68f487e7aaaf2ddafea ] When moving to switchdev mode when the device doesn't support IPsec, we try to clean up the IPsec resources anyway which causes the crash below, fix that by correctly checking for IPsec support before trying to clean up its resources. [27642.515799] WARNING: arch/x86/mm/fault.c:1276 at do_user_addr_fault+0x18a/0x680, CPU#4: devlink/6490 [27642.517159] Modules linked in: xt_conntrack xt_MASQUERADE ip6table_nat ip6table_filter ip6_tables iptable_nat nf_nat xt_addrtype rpcsec_gss_krb5 auth_rpcgss oid_registry overlay mlx5_fwctl nfnetlink zram zsmalloc mlx5_ib fuse rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_core ib_core [27642.521358] CPU: 4 UID: 0 PID: 6490 Comm: devlink Not tainted 6.19.0-rc5_for_upstream_min_debug_2026_01_14_16_47 #1 NONE [27642.522923] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [27642.524528] RIP: 0010:do_user_addr_fault+0x18a/0x680 [27642.525362] Code: ff 0f 84 75 03 00 00 48 89 ee 4c 89 e7 e8 5e b9 22 00 49 89 c0 48 85 c0 0f 84 a8 02 00 00 f7 c3 60 80 00 00 74 22 31 c9 eb ae <0f> 0b 48 83 c4 10 48 89 ea 48 89 de 4c 89 f7 5b 5d 41 5c 41 5d 41 [27642.528166] RSP: 0018:ffff88810770f6b8 EFLAGS: 00010046 [27642.529038] RAX: 0000000000000000 RBX: 0000000000000002 RCX: ffff88810b980f00 [27642.530158] RDX: 00000000000000a0 RSI: 0000000000000002 RDI: ffff88810770f728 [27642.531270] RBP: 00000000000000a0 R08: 0000000000000000 R09: 0000000000000000 [27642.532383] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888103f3c4c0 [27642.533499] R13: 0000000000000000 R14: ffff88810770f728 R15: 0000000000000000 [27642.534614] FS: 00007f197c741740(0000) GS:ffff88856a94c000(0000) knlGS:0000000000000000 [27642.535915] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [27642.536858] CR2: 00000000000000a0 CR3: 000000011334c003 CR4: 0000000000172eb0 [27642.537982] Call Trace: [27642.538466] [27642.538907] exc_page_fault+0x76/0x140 [27642.539583] asm_exc_page_fault+0x22/0x30 [27642.540282] RIP: 0010:_raw_spin_lock_irqsave+0x10/0x30 [27642.541134] Code: 07 85 c0 75 11 ba ff 00 00 00 f0 0f b1 17 75 06 b8 01 00 00 00 c3 31 c0 c3 90 0f 1f 44 00 00 53 9c 5b fa 31 c0 ba 01 00 00 00 0f b1 17 75 05 48 89 d8 5b c3 89 c6 e8 7e 02 00 00 48 89 d8 5b [27642.543936] RSP: 0018:ffff88810770f7d8 EFLAGS: 00010046 [27642.544803] RAX: 0000000000000000 RBX: 0000000000000202 RCX: ffff888113ad96d8 [27642.545916] RDX: 0000000000000001 RSI: ffff88810770f818 RDI: 00000000000000a0 [27642.547027] RBP: 0000000000000098 R08: 0000000000000400 R09: ffff88810b980f00 [27642.548140] R10: 0000000000000001 R11: ffff888101845a80 R12: 00000000000000a8 [27642.549263] R13: ffffffffa02a9060 R14: 00000000000000a0 R15: ffff8881130d8a40 [27642.550379] complete_all+0x20/0x90 [27642.551010] mlx5e_ipsec_disable_events+0xb6/0xf0 [mlx5_core] [27642.552022] mlx5e_nic_disable+0x12d/0x220 [mlx5_core] [27642.552929] mlx5e_detach_netdev+0x66/0xf0 [mlx5_core] [27642.553822] mlx5e_netdev_change_profile+0x5b/0x120 [mlx5_core] [27642.554821] mlx5e_vport_rep_load+0x419/0x590 [mlx5_core] [27642.555757] ? xa_load+0x53/0x90 [27642.556361] __esw_offloads_load_rep+0x54/0x70 [mlx5_core] [27642.557328] mlx5_esw_offloads_rep_load+0x45/0xd0 [mlx5_core] [27642.558320] esw_offloads_enable+0xb4b/0xc90 [mlx5_core] [27642.559247] mlx5_eswitch_enable_locked+0x34e/0x4f0 [mlx5_core] [27642.560257] ? mlx5_rescan_drivers_locked+0x222/0x2d0 [mlx5_core] [27642.561284] mlx5_devlink_eswitch_mode_set+0x5ac/0x9c0 [mlx5_core] [27642.562334] ? devlink_rate_set_ops_supported+0x21/0x3a0 [27642.563220] devlink_nl_eswitch_set_doit+0x67/0xe0 [27642.564026] genl_family_rcv_msg_doit+0xe0/0x130 [27642.564816] genl_rcv_msg+0x183/0x290 [27642.565466] ? __devlink_nl_pre_doit.isra.0+0x160/0x160 [27642.566329] ? devlink_nl_eswitch_get_doit+0x290/0x290 [27642.567181] ? devlink_nl_pre_doit_parent_dev_optional+0x20/0x20 [27642.568147] ? genl_family_rcv_msg_dumpit+0xf0/0xf0 [27642.568966] netlink_rcv_skb+0x4b/0xf0 [27642.569629] genl_rcv+0x24/0x40 [27642.570215] netlink_unicast+0x255/0x380 [27642.570901] ? __alloc_skb+0xfa/0x1e0 [27642.571560] netlink_sendmsg+0x1f3/0x420 [27642.572249] __sock_sendmsg+0x38/0x60 [27642.572911] __sys_sendto+0x119/0x180 [27642.573561] ? __sys_recvmsg+0x5c/0xb0 [27642.574227] __x64_sys_sendto+0x20/0x30 [27642.574904] do_syscall_64+0x55/0xc10 [27642.575554] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [27642.576391] RIP: 0033:0x7f197c85e807 [27642.577050] Code: c7 c0 ff ff ff ff eb be 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 80 3d 45 08 0d 00 00 41 89 ca 74 10 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 69 c3 55 48 89 e5 53 48 83 ec 38 44 89 4d d0 [27642.579846] RSP: 002b:00007ffebd4e2248 EFLAGS: 00000202 ORIG_RAX: 000000000000002c [27642.581082] RAX: ffffffffffffffda RBX: 000055cfcd9cd2a0 RCX: 00007f197c85e807 [27642.582200] RDX: 0000000000000038 RSI: 000055cfcd9cd490 RDI: 0000000000000003 [27642.583320] RBP: 00007ffebd4e2290 R08: 00007f197c942200 R09: 000000000000000c [27642.584437] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 [27642.585555] R13: 000055cfcd9cd490 R14: 00007ffebd4e45d1 R15: 000055cfcd9cd2a0 [27642.586671] [27642.587121] ---[ end trace 0000000000000000 ]--- [27642.587910] BUG: kernel NULL pointer dereference, address: 00000000000000a0 Fixes: 664f76be38a1 ("net/mlx5: Fix IPsec cleanup over MPV device") Signed-off-by: Patrisious Haddad Reviewed-by: Leon Romanovsky Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260305142634.1813208-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4a7838bebc38374f74baaf88bf2cf8d439a92923 Author: Cosmin Ratiu Date: Thu Mar 5 10:10:19 2026 +0200 net/mlx5: Fix deadlock between devlink lock and esw->wq [ Upstream commit aed763abf0e905b4b8d747d1ba9e172961572f57 ] esw->work_queue executes esw_functions_changed_event_handler -> esw_vfs_changed_event_handler and acquires the devlink lock. .eswitch_mode_set (acquires devlink lock in devlink_nl_pre_doit) -> mlx5_devlink_eswitch_mode_set -> mlx5_eswitch_disable_locked -> mlx5_eswitch_event_handler_unregister -> flush_workqueue deadlocks when esw_vfs_changed_event_handler executes. Fix that by no longer flushing the work to avoid the deadlock, and using a generation counter to keep track of work relevance. This avoids an old handler manipulating an esw that has undergone one or more mode changes: - the counter is incremented in mlx5_eswitch_event_handler_unregister. - the counter is read and passed to the ephemeral mlx5_host_work struct. - the work handler takes the devlink lock and bails out if the current generation is different than the one it was scheduled to operate on. - mlx5_eswitch_cleanup does the final draining before destroying the wq. No longer flushing the workqueue has the side effect of maybe no longer cancelling pending vport_change_handler work items, but that's ok since those are disabled elsewhere: - mlx5_eswitch_disable_locked disables the vport eq notifier. - mlx5_esw_vport_disable disarms the HW EQ notification and marks vport->enabled under state_lock to false to prevent pending vport handler from doing anything. - mlx5_eswitch_cleanup destroys the workqueue and makes sure all events are disabled/finished. Fixes: f1bc646c9a06 ("net/mlx5: Use devl_ API in mlx5_esw_offloads_devlink_port_register") Signed-off-by: Cosmin Ratiu Reviewed-by: Moshe Shemesh Reviewed-by: Dragos Tatulea Reviewed-by: Simon Horman Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260305081019.1811100-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6aaf15f376b0e6c1a92947913797d63cfaf58bea Author: Hangbin Liu Date: Wed Mar 4 15:13:54 2026 +0800 bonding: handle BOND_LINK_FAIL, BOND_LINK_BACK as valid link states [ Upstream commit 3348be7978f450ede0c308a4e8416ac716cf1015 ] Before the fixed commit, we check slave->new_link during commit state, which values are only BOND_LINK_{NOCHANGE, UP, DOWN}. After the commit, we start using slave->link_new_state, which state also could be BOND_LINK_{FAIL, BACK}. For example, when we set updelay/downdelay, after a failover, the slave->link_new_state could be set to BOND_LINK_{FAIL, BACK} in bond_miimon_inspect(). And later in bond_miimon_commit(), it will treat it as invalid and print an error, which would cause confusion for users. [ 106.440254] bond0: (slave veth2): link status down for interface, disabling it in 200 ms [ 106.440265] bond0: (slave veth2): invalid new link 1 on slave [ 106.648276] bond0: (slave veth2): link status definitely down, disabling slave [ 107.480271] bond0: (slave veth2): link status up, enabling it in 200 ms [ 107.480288] bond0: (slave veth2): invalid new link 3 on slave [ 107.688302] bond0: (slave veth2): link status definitely up, 10000 Mbps full duplex Let's handle BOND_LINK_{FAIL, BACK} as valid link states. Fixes: 1899bb325149 ("bonding: fix state transition issue in link monitoring") Signed-off-by: Hangbin Liu Link: https://patch.msgid.link/20260304-b4-bond_updelay-v1-2-f72eb2e454d0@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ab1bcadc7e517287ad01fb3931ef8a2ce3853e73 Author: Hangbin Liu Date: Wed Mar 4 15:13:53 2026 +0800 bonding: do not set usable_slaves for broadcast mode [ Upstream commit 45fc134bcfadde456639c1b1e206e6918d69a553 ] After commit e0caeb24f538 ("net: bonding: update the slave array for broadcast mode"), broadcast mode will also set all_slaves and usable_slaves during bond_enslave(). But if we also set updelay, during enslave, the slave init state will be BOND_LINK_BACK. And later bond_update_slave_arr() will alloc usable_slaves but add nothing. This will cause bond_miimon_inspect() to have ignore_updelay always true. So the updelay will be always ignored. e.g. [ 6.498368] bond0: (slave veth2): link status definitely down, disabling slave [ 7.536371] bond0: (slave veth2): link status up, enabling it in 0 ms [ 7.536402] bond0: (slave veth2): link status definitely up, 10000 Mbps full duplex To fix it, we can either always call bond_update_slave_arr() on every place when link changes. Or, let's just not set usable_slaves for broadcast mode. Fixes: e0caeb24f538 ("net: bonding: update the slave array for broadcast mode") Reported-by: Liang Li Signed-off-by: Hangbin Liu Link: https://patch.msgid.link/20260304-b4-bond_updelay-v1-1-f72eb2e454d0@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2ee3645e0f3f4343ccdec769d584c85359537c12 Author: Yang Wang Date: Tue Mar 3 21:14:10 2026 -0500 drm/amd/pm: add missing od setting PP_OD_FEATURE_ZERO_FAN_BIT for smu v14 [ Upstream commit 9d4837a26149355ffe3a1f80de80531eafdd3353 ] add missing od setting PP_OD_FEATURE_ZERO_FAN_BIT for smu v14.0.2/14.0.3 Fixes: 9710b84e2a6a ("drm/amd/pm: add overdrive support on smu v14.0.2/3") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5018 Signed-off-by: Yang Wang Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 1b5cf07d80bb16d1593579ccdb23f08ea4262c14) Signed-off-by: Sasha Levin commit 4c32155265b67a876a5ab0e36819f17659e7b8a5 Author: Yang Wang Date: Tue Mar 3 21:10:11 2026 -0500 drm/amd/pm: add missing od setting PP_OD_FEATURE_ZERO_FAN_BIT for smu v13 [ Upstream commit cb47c882c31334aadc13ace80781728ed22a05ee ] add missing od setting PP_OD_FEATURE_ZERO_FAN_BIT for smu v13.0.0/13.0.7 Fixes: cfffd980bf21 ("drm/amd/pm: add zero RPM OD setting support for SMU13") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5018 Signed-off-by: Yang Wang Acked-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 576a10797b607ee9e4068218daf367b481564120) Signed-off-by: Sasha Levin commit 6b4a1ff808851acf59eff53163b7809bb026eca4 Author: Pengyu Luo Date: Sat Mar 7 00:32:38 2026 +0800 drm/msm/dsi: fix pclk rate calculation for bonded dsi [ Upstream commit e4eb11b34d6c84f398d8f08d7cb4d6c38e739dd2 ] Recently, we round up new_hdisplay once at most, for bonded dsi, we may need twice, since they are independent links, we should round up each half separately. This also aligns with the hdisplay we program later in dsi_timing_setup() Example: full_hdisplay = 1904, dsc_bpp = 8, bpc = 8 new_full_hdisplay = DIV_ROUND_UP(1904 * 8, 8 * 3) = 635 if we use half display new_half_hdisplay = DIV_ROUND_UP(952 * 8, 8 * 3) = 318 new_full_display = 636 Fixes: 7c9e4a554d4a ("drm/msm/dsi: Reduce pclk rate for compression") Signed-off-by: Pengyu Luo Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/709716/ Link: https://lore.kernel.org/r/20260306163255.215456-1-mitltlatltl@gmail.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 5f5d956b2ce007d0955bf3b4714897308d797fdc Author: Mieczyslaw Nalewaj Date: Tue Mar 3 17:25:12 2026 -0300 net: dsa: realtek: rtl8365mb: remove ifOutDiscards from rx_packets [ Upstream commit f76a93241d71fbba8425e3967097b498c29264ed ] rx_packets should report the number of frames successfully received: unicast + multicast + broadcast. Subtracting ifOutDiscards (a TX counter) is incorrect and can undercount RX packets. RX drops are already reported via rx_dropped (e.g. etherStatsDropEvents), so there is no need to adjust rx_packets. This patch removes the subtraction of ifOutDiscards from rx_packets in rtl8365mb_stats_update(). Link: https://lore.kernel.org/netdev/878777925.105015.1763423928520@mail.yahoo.com/ Fixes: 4af2950c50c8 ("net: dsa: realtek-smi: add rtl8365mb subdriver for RTL8365MB-VC") Signed-off-by: Mieczyslaw Nalewaj Signed-off-by: Luiz Angelo Daros de Luca Reviewed-by: Simon Horman Acked-by: Linus Walleij Link: https://patch.msgid.link/20260303-realtek_namiltd_fix2-v1-1-bfa433d3401e@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 98754dda67296db78250f6eecc447e7b2423a2c8 Author: Krzysztof Kozlowski Date: Wed Feb 25 18:34:20 2026 +0100 dt-bindings: display/msm: qcom,sm8750-mdss: Fix model typo [ Upstream commit 4355b13d46f696d687f42b982efed7570e03e532 ] Fix obvious model typo (SM8650->SM8750) in the description. Signed-off-by: Krzysztof Kozlowski Fixes: 6b93840116df ("dt-bindings: display/msm: qcom,sm8750-mdss: Add SM8750") Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/707192/ Link: https://lore.kernel.org/r/20260225173419.125565-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 676826aeddb57b5eb9ca267d7fc5538389becc7d Author: Peter Collingbourne Date: Wed Mar 4 11:06:12 2026 -0800 perf disasm: Fix off-by-one bug in outside check [ Upstream commit b3ce769203a99d6f3c6d6269ec09232a8c5da422 ] If a branch target points to one past the end of a function, the branch should be treated as a branch to another function. This can happen e.g. with a tail call to a function that is laid out immediately after the caller. Fixes: 751b1783da784299 ("perf annotate: Mark jumps to outher functions with the call arrow") Reviewed-by: Ian Rogers Signed-off-by: Peter Collingbourne Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Bill Wendling Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Justin Stitt Cc: Mark Rutland Cc: Namhyung Kim Cc: Nathan Chancellor Cc: Nick Desaulniers Cc: Peter Zijlstra Link: https://linux-review.googlesource.com/id/Ide471112e82d68177e0faf08ca411d9fcf0a7bdf Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit ce69c1b75374605675560d5ccd6a416f4d2a9c0d Author: Breno Leitao Date: Thu Mar 5 08:15:37 2026 -0800 workqueue: Use POOL_BH instead of WQ_BH when checking pool flags [ Upstream commit f42f9091be9e5ff57567a3945cfcdd498f475348 ] pr_cont_worker_id() checks pool->flags against WQ_BH, which is a workqueue-level flag (defined in workqueue.h). Pool flags use a separate namespace with POOL_* constants (defined in workqueue.c). The correct constant is POOL_BH. Both WQ_BH and POOL_BH are defined as (1 << 0) so this has no behavioral impact, but it is semantically wrong and inconsistent with every other pool-level BH check in the file. Fixes: 4cb1ef64609f ("workqueue: Implement BH workqueues to eventually replace tasklets") Signed-off-by: Breno Leitao Acked-by: Song Liu Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit a39b75c3f4226b0c53c70947f1dc0e88af718d57 Author: Sun YangKai Date: Mon Feb 9 20:53:39 2026 +0800 btrfs: hold space_info->lock when clearing periodic reclaim ready [ Upstream commit b8883b61f2fc50dcf22938cbed40fec05020552f ] btrfs_set_periodic_reclaim_ready() requires space_info->lock to be held, as enforced by lockdep_assert_held(). However, btrfs_reclaim_sweep() was calling it after do_reclaim_sweep() returns, at which point space_info->lock is no longer held. Fix this by explicitly acquiring space_info->lock before clearing the periodic reclaim ready flag in btrfs_reclaim_sweep(). Reported-by: Chris Mason Link: https://lore.kernel.org/linux-btrfs/20260208182556.891815-1-clm@meta.com/ Fixes: 19eff93dc738 ("btrfs: fix periodic reclaim condition") Reviewed-by: Boris Burkov Signed-off-by: Sun YangKai Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 8127b5fec04757c2a41ed65bca0b3266968efd3b Author: Eric Badger Date: Mon Feb 23 10:28:55 2026 -0800 xprtrdma: Decrement re_receiving on the early exit paths [ Upstream commit 7b6275c80a0c81c5f8943272292dfe67730ce849 ] In the event that rpcrdma_post_recvs() fails to create a work request (due to memory allocation failure, say) or otherwise exits early, we should decrement ep->re_receiving before returning. Otherwise we will hang in rpcrdma_xprt_drain() as re_receiving will never reach zero and the completion will never be triggered. On a system with high memory pressure, this can appear as the following hung task: INFO: task kworker/u385:17:8393 blocked for more than 122 seconds. Tainted: G S E 6.19.0 #3 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u385:17 state:D stack:0 pid:8393 tgid:8393 ppid:2 task_flags:0x4248060 flags:0x00080000 Workqueue: xprtiod xprt_autoclose [sunrpc] Call Trace: __schedule+0x48b/0x18b0 ? ib_post_send_mad+0x247/0xae0 [ib_core] schedule+0x27/0xf0 schedule_timeout+0x104/0x110 __wait_for_common+0x98/0x180 ? __pfx_schedule_timeout+0x10/0x10 wait_for_completion+0x24/0x40 rpcrdma_xprt_disconnect+0x444/0x460 [rpcrdma] xprt_rdma_close+0x12/0x40 [rpcrdma] xprt_autoclose+0x5f/0x120 [sunrpc] process_one_work+0x191/0x3e0 worker_thread+0x2e3/0x420 ? __pfx_worker_thread+0x10/0x10 kthread+0x10d/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x273/0x2b0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Fixes: 15788d1d1077 ("xprtrdma: Do not refresh Receive Queue while it is draining") Signed-off-by: Eric Badger Reviewed-by: Chuck Lever Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 2871bb923ff8fdb0db99f59a8a00462e513c7200 Author: Pengyu Luo Date: Sat Feb 14 18:51:28 2026 +0800 drm/msm/dsi: fix hdisplay calculation when programming dsi registers [ Upstream commit ac47870fd795549f03d57e0879fc730c79119f4b ] Recently, the hdisplay calculation is working for 3:1 compressed ratio only. If we have a video panel with DSC BPP = 8, and BPC = 10, we still use the default bits_per_pclk = 24, then we get the wrong hdisplay. We can draw the conclusion by cross-comparing the calculation with the calculation in dsi_adjust_pclk_for_compression(). Since CMD mode does not use this, we can remove !(msm_host->mode_flags & MIPI_DSI_MODE_VIDEO) safely. Fixes: efcbd6f9cdeb ("drm/msm/dsi: Enable widebus for DSI") Signed-off-by: Pengyu Luo Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/704822/ Link: https://lore.kernel.org/r/20260214105145.105308-1-mitltlatltl@gmail.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 203c792cb4315360d49973ae2e57feeb6d3dcf7e Author: Roberto Bergantinos Corpas Date: Thu Feb 19 13:04:40 2026 +0100 nfs: return EISDIR on nfs3_proc_create if d_alias is a dir [ Upstream commit 410666a298c34ebd57256fde6b24c96bd23059a2 ] If we found an alias through nfs3_do_create/nfs_add_or_obtain /d_splice_alias which happens to be a dir dentry, we don't return any error, and simply forget about this alias, but the original dentry we were adding and passed as parameter remains negative. This later causes an oops on nfs_atomic_open_v23/finish_open since we supply a negative dentry to do_dentry_open. This has been observed running lustre-racer, where dirs and files are created/removed concurrently with the same name and O_EXCL is not used to open files (frequent file redirection). While d_splice_alias typically returns a directory alias or NULL, we explicitly check d_is_dir() to ensure that we don't attempt to perform file operations (like finish_open) on a directory inode, which triggers the observed oops. Fixes: 7c6c5249f061 ("NFS: add atomic_open for NFSv3 to handle O_TRUNC correctly.") Reviewed-by: Olga Kornievskaia Reviewed-by: Scott Mayhew Signed-off-by: Roberto Bergantinos Corpas Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 28a72f653832a10e05bcadee042f5c7e6396582f Author: Guenter Roeck Date: Thu Feb 26 21:54:21 2026 -0800 smb/server: Fix another refcount leak in smb2_open() [ Upstream commit c15e7c62feb3751cbdd458555819df1d70374890 ] If ksmbd_override_fsids() fails, we jump to err_out2. At that point, fp is NULL because it hasn't been assigned dh_info.fp yet, so ksmbd_fd_put(work, fp) will not be called. However, dh_info.fp was already inserted into the session file table by ksmbd_reopen_durable_fd(), so it will leak in the session file table until the session is closed. Move fp = dh_info.fp; ahead of the ksmbd_override_fsids() check to fix the problem. Found by an experimental AI code review agent at Google. Fixes: c8efcc786146a ("ksmbd: add support for durable handles v1/v2") Signed-off-by: Guenter Roeck Reviewed-by: ChenXiaoSong Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit f426a493db33d083f428aa619bccc884033dcfcc Author: J. Neuschäfer Date: Tue Mar 3 16:31:42 2026 +0100 powerpc: 83xx: km83xx: Fix keymile vendor prefix [ Upstream commit 691417ffe7821721e0a28bd25ad8c0dc0d4ae4ad ] When kmeter.c was refactored into km83xx.c in 2011, the "keymile" vendor prefix was changed to upper-case "Keymile". The devicetree at arch/powerpc/boot/dts/kmeter1.dts never underwent the same change, suggesting that this was simply a mistake. Fixes: 93e2b95c81042d ("powerpc/83xx: rename and update kmeter1") Signed-off-by: J. Neuschäfer Reviewed-by: Heiko Schocher Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260303-keymile-v1-1-463a11e71702@posteo.net Signed-off-by: Sasha Levin commit ba021fb575084f5bb69e58a0774862e5007b5d58 Author: Tzung-Bi Shih Date: Fri Feb 6 03:30:33 2026 +0000 remoteproc: mediatek: Unprepare SCP clock during system suspend [ Upstream commit 35c3f72a2d55dbf52f28f4ecae51c76be1acf545 ] Prior to commit d935187cfb27 ("remoteproc: mediatek: Break lock dependency to prepare_lock"), `scp->clk` was prepared and enabled only when it needs to communicate with the SCP. The commit d935187cfb27 moved the prepare operation to remoteproc's prepare(), keeping the clock prepared as long as the SCP is running. The power consumption due to the prolonged clock preparation can be negligible when the system is running, as SCP is designed to be a very power efficient processor. However, the clock remains prepared even when the system enters system suspend. This prevents the underlying clock controller (and potentially the parent PLLs) from shutting down, which increases power consumption and may block the system from entering deep sleep states. Add suspend and resume callbacks. Unprepare the clock in suspend() if it was active and re-prepare it in resume() to ensure the clock is properly disabled during system suspend, while maintaining the "always prepared" semantics while the system is active. The driver doesn't implement .attach() callback, hence it only checks for RPROC_RUNNING. Fixes: d935187cfb27 ("remoteproc: mediatek: Break lock dependency to prepare_lock") Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20260206033034.3031781-1-tzungbi@kernel.org Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit bf39fed5f22cba1d3f0ac029efd6e692df34e76e Author: Bjorn Andersson Date: Fri Feb 20 15:11:48 2026 -0600 remoteproc: sysmon: Correct subsys_name_len type in QMI request [ Upstream commit da994db94e60f9a9411108ddf4d1836147ad4c9c ] The QMI message encoder has up until recently read a single byte (as elem_size == 1), but with the introduction of big endian support it's become apparent that this field is expected to be a full u32 - regardless of the size of the length in the encoded message (which is what elem_size specifies). The result is that the encoder now reads past the length byte and rejects the unreasonably large length formed when including the following 3 bytes from the subsys_name array. Fix this by changing to the expected type. Fixes: 1fb82ee806d1 ("remoteproc: qcom: Introduce sysmon") Signed-off-by: Bjorn Andersson Reviewed-by: Chris Lew Link: https://lore.kernel.org/r/20260220-qmi-encode-invalid-length-v2-1-5674be35ab29@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit b7b634be76582804600e2541121bf57d96011330 Author: Sourabh Jain Date: Fri Feb 27 22:48:01 2026 +0530 powerpc/crash: adjust the elfcorehdr size [ Upstream commit 04e707cb77c272cb0bb2e2e3c5c7f844d804a089 ] With crash hotplug support enabled, additional memory is allocated to the elfcorehdr kexec segment to accommodate resources added during memory hotplug events. However, the kdump FDT is not updated with the same size, which can result in elfcorehdr corruption in the kdump kernel. Update elf_headers_sz (the kimage member representing the size of the elfcorehdr kexec segment) to reflect the total memory allocated for the elfcorehdr segment instead of the elfcorehdr buffer size at the time of kdump load. This allows of_kexec_alloc_and_setup_fdt() to reserve the full elfcorehdr memory in the kdump FDT and prevents elfcorehdr corruption. Fixes: 849599b702ef8 ("powerpc/crash: add crash memory hotplug support") Reviewed-by: Hari Bathini Signed-off-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260227171801.2238847-1-sourabhjain@linux.ibm.com Signed-off-by: Sasha Levin commit c171a5f799546be6c1236da52308d7eee2aa72be Author: Sourabh Jain Date: Wed Dec 24 20:42:57 2025 +0530 powerpc/kexec/core: use big-endian types for crash variables [ Upstream commit 20197b967a6a29dab81495f25a988515bda84cfe ] Use explicit word-sized big-endian types for kexec and crash related variables. This makes the endianness unambiguous and avoids type mismatches that trigger sparse warnings. The change addresses sparse warnings like below (seen on both 32-bit and 64-bit builds): CHECK ../arch/powerpc/kexec/core.c sparse: expected unsigned int static [addressable] [toplevel] [usertype] crashk_base sparse: got restricted __be32 [usertype] sparse: warning: incorrect type in assignment (different base types) sparse: expected unsigned int static [addressable] [toplevel] [usertype] crashk_size sparse: got restricted __be32 [usertype] sparse: warning: incorrect type in assignment (different base types) sparse: expected unsigned long long static [addressable] [toplevel] mem_limit sparse: got restricted __be32 [usertype] sparse: warning: incorrect type in assignment (different base types) sparse: expected unsigned int static [addressable] [toplevel] [usertype] kernel_end sparse: got restricted __be32 [usertype] No functional change intended. Fixes: ea961a828fe7 ("powerpc: Fix endian issues in kexec and crash dump code") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202512221405.VHPKPjnp-lkp@intel.com/ Signed-off-by: Sourabh Jain Tested-by: Venkat Rao Bagalkote Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20251224151257.28672-1-sourabhjain@linux.ibm.com Signed-off-by: Sasha Levin commit d5697cf3b91d8917f739efe7e0fa0630cb694eea Author: Ben Collins Date: Mon Apr 21 22:36:46 2025 -0400 kexec: Include kernel-end even without crashkernel [ Upstream commit 38c64dfe0af12778953846df5f259e913275cfe5 ] Certain versions of kexec don't even work without kernel-end being added to the device-tree. Add it even if crash-kernel is disabled. Signed-off-by: Ben Collins Reviewed-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/2025042122-inescapable-mandrill-8a5ff2@boujee-and-buff Stable-dep-of: 20197b967a6a ("powerpc/kexec/core: use big-endian types for crash variables") Signed-off-by: Sasha Levin commit b3c074a394c66bbc4943d2d2bab546f7959365f5 Author: Christophe Leroy (CS GROUP) Date: Tue Feb 3 08:30:41 2026 +0100 powerpc/uaccess: Fix inline assembly for clang build on PPC32 [ Upstream commit 0ee95a1d458630272d0415d0ffa9424fcb606c90 ] Test robot reports the following error with clang-16.0.6: In file included from kernel/rseq.c:75: include/linux/rseq_entry.h:141:3: error: invalid operand for instruction unsafe_get_user(offset, &ucs->post_commit_offset, efault); ^ include/linux/uaccess.h:608:2: note: expanded from macro 'unsafe_get_user' arch_unsafe_get_user(x, ptr, local_label); \ ^ arch/powerpc/include/asm/uaccess.h:518:2: note: expanded from macro 'arch_unsafe_get_user' __get_user_size_goto(__gu_val, __gu_addr, sizeof(*(p)), e); \ ^ arch/powerpc/include/asm/uaccess.h:284:2: note: expanded from macro '__get_user_size_goto' __get_user_size_allowed(x, ptr, size, __gus_retval); \ ^ arch/powerpc/include/asm/uaccess.h:275:10: note: expanded from macro '__get_user_size_allowed' case 8: __get_user_asm2(x, (u64 __user *)ptr, retval); break; \ ^ arch/powerpc/include/asm/uaccess.h:258:4: note: expanded from macro '__get_user_asm2' " li %1+1,0\n" \ ^ :7:5: note: instantiated into assembly here li 31+1,0 ^ 1 error generated. On PPC32, for 64 bits vars a pair of registers is used. Usually the lower register in the pair is the high part and the higher register is the low part. GCC uses r3/r4 ... r11/r12 ... r14/r15 ... r30/r31 In older kernel code inline assembly was using %1 and %1+1 to represent 64 bits values. However here it looks like clang uses r31 as high part, allthough r32 doesn't exist hence the error. Allthoug %1+1 should work, most places now use %L1 instead of %1+1, so let's do the same here. With that change, the build doesn't fail anymore and a disassembly shows clang uses r17/r18 and r31/r14 pair when GCC would have used r16/r17 and r30/r31: Disassembly of section .fixup: 00000000 <.fixup>: 0: 38 a0 ff f2 li r5,-14 4: 3a 20 00 00 li r17,0 8: 3a 40 00 00 li r18,0 c: 48 00 00 00 b c <.fixup+0xc> c: R_PPC_REL24 .text+0xbc 10: 38 a0 ff f2 li r5,-14 14: 3b e0 00 00 li r31,0 18: 39 c0 00 00 li r14,0 1c: 48 00 00 00 b 1c <.fixup+0x1c> 1c: R_PPC_REL24 .text+0x144 Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202602021825.otcItxGi-lkp@intel.com/ Fixes: c20beffeec3c ("powerpc/uaccess: Use flexible addressing with __put_user()/__get_user()") Signed-off-by: Christophe Leroy (CS GROUP) Acked-by: Nathan Chancellor Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/8ca3a657a650e497a96bfe7acde2f637dadab344.1770103646.git.chleroy@kernel.org Signed-off-by: Sasha Levin commit 71c57e74baa069db500bf6f49e4ba0caabf0f974 Author: Takashi Iwai Date: Wed Feb 25 09:52:29 2026 +0100 ALSA: usb-audio: Check max frame size for implicit feedback mode, too [ Upstream commit 7cb2a5422f5bbdf1cf32eae0eda41000485b9346 ] When the packet sizes are taken from the capture stream in the implicit feedback mode, the sizes might be larger than the upper boundary defined by the descriptor. As already done for other transfer modes, we have to cap the sizes accordingly at sending, otherwise this would lead to an error in USB core at submission of URBs. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221076 Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260225085233.316306-3-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 31e6595fd1a0517cdcdc74740ac96e76f25ad312 Author: sguttula Date: Sat Feb 21 10:03:32 2026 +0530 drm/amdgpu/vcn5: Add SMU dpm interface type [ Upstream commit a5fe1a54513196e4bc8f9170006057dc31e7155e ] This will set AMDGPU_VCN_SMU_DPM_INTERFACE_* smu_type based on soc type and fixing ring timeout issue seen for DPM enabled case. Signed-off-by: sguttula Reviewed-by: Pratik Vishwakarma Signed-off-by: Alex Deucher (cherry picked from commit f0f23c315b38c55e8ce9484cf59b65811f350630) Signed-off-by: Sasha Levin commit 716fc404469128fbc919627f10e24d36813144de Author: Takashi Iwai Date: Wed Feb 25 09:52:30 2026 +0100 ALSA: usb-audio: Avoid implicit feedback mode on DIYINHK USB Audio 2.0 [ Upstream commit c5bf24c8aba1ff711226ee0f039ff01a5754692b ] Although DIYINHK USB Audio 2.0 (ID 20b1:2009) shows the implicit feedback source for the capture stream, this would cause several problems for the playback. Namely, the device can get wMaxPackSize 1024 for 24/32 bit format with 6 channels, and when a high sample rate like 352.8kHz or 384kHz is played, the packet size overflows the max limit. Also, the device has another two playback altsets, and those aren't properly handled with the implicit feedback. Since the device has been working well even before introducing the implicit feedback, we can assume that it works fine in the async mode. This patch adds the explicit skip of the implicit fb detection to make the playback running in the async mode. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221076 Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260225085233.316306-4-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 5faf0ce7d784a36e5199014770fa3a17c9e63cdd Author: wangshuaiwei Date: Tue Feb 24 14:32:28 2026 +0800 scsi: ufs: core: Fix shift out of bounds when MAXQ=32 [ Upstream commit 2f38fd99c0004676d835ae96ac4f3b54edc02c82 ] According to JESD223F, the maximum number of queues (MAXQ) is 32. When MCQ is enabled and ESI is disabled, nr_hw_queues=32 causes a shift overflow problem. Fix this by using 64-bit intermediate values to handle the nr_hw_queues=32 case safely. Signed-off-by: wangshuaiwei Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260224063228.50112-1-wangshuaiwei1@xiaomi.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f4f590c6c9df7453bbda2ef9170b1b09e42a124c Author: Peter Wang Date: Mon Feb 23 14:56:09 2026 +0800 scsi: ufs: core: Fix possible NULL pointer dereference in ufshcd_add_command_trace() [ Upstream commit 30df81f2228d65bddf492db3929d9fcaffd38fc5 ] The kernel log indicates a crash in ufshcd_add_command_trace, due to a NULL pointer dereference when accessing hwq->id. This can happen if ufshcd_mcq_req_to_hwq() returns NULL. This patch adds a NULL check for hwq before accessing its id field to prevent a kernel crash. Kernel log excerpt: [] notify_die+0x4c/0x8c [] __die+0x60/0xb0 [] die+0x4c/0xe0 [] die_kernel_fault+0x74/0x88 [] __do_kernel_fault+0x314/0x318 [] do_page_fault+0xa4/0x5f8 [] do_translation_fault+0x34/0x54 [] do_mem_abort+0x50/0xa8 [] el1_abort+0x3c/0x64 [] el1h_64_sync_handler+0x44/0xcc [] el1h_64_sync+0x80/0x88 [] ufshcd_add_command_trace+0x23c/0x320 [] ufshcd_compl_one_cqe+0xa4/0x404 [] ufshcd_mcq_poll_cqe_lock+0xac/0x104 [] ufs_mtk_mcq_intr+0x54/0x74 [ufs_mediatek_mod] [] __handle_irq_event_percpu+0xc8/0x348 [] handle_irq_event+0x3c/0xa8 [] handle_fasteoi_irq+0xf8/0x294 [] generic_handle_domain_irq+0x54/0x80 [] gic_handle_irq+0x1d4/0x330 [] call_on_irq_stack+0x44/0x68 [] do_interrupt_handler+0x78/0xd8 [] el1_interrupt+0x48/0xa8 [] el1h_64_irq_handler+0x14/0x24 [] el1h_64_irq+0x80/0x88 [] arch_local_irq_enable+0x4/0x1c [] cpuidle_enter+0x34/0x54 [] do_idle+0x1dc/0x2f8 [] cpu_startup_entry+0x30/0x3c [] secondary_start_kernel+0x134/0x1ac [] __secondary_switched+0xc4/0xcc Signed-off-by: Peter Wang Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260223065657.2432447-1-peter.wang@mediatek.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 87aa0f91ee49e8f1370bc25ca0d90c7bcc0aca9e Author: Charles Keepax Date: Mon Feb 23 09:36:16 2026 +0000 ASoC: cs42l43: Report insert for exotic peripherals [ Upstream commit 6510e1324bcdc8caf21f6d17efe27604c48f0d64 ] For some exotic peripherals the type detect can return a reserved value of 0x4. This will currently return an error and not report anything to user-space, update this to report the insert normally. Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20260223093616.3800350-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c072370ad67dd170fd9ec4a77041a624e440a0b6 Author: Azamat Almazbek uulu Date: Sat Feb 21 12:48:13 2026 +0100 ASoC: amd: yc: Add ASUS EXPERTBOOK BM1503CDA to quirk table [ Upstream commit 32fc4168fa56f6301d858c778a3d712774e9657e ] The ASUS ExpertBook BM1503CDA (Ryzen 5 7535U, Barcelo-R) has an internal DMIC connected through the AMD ACP (Audio CoProcessor) but is missing from the DMI quirk table, so the acp6x machine driver probe returns -ENODEV and no DMIC capture device is created. Add the DMI entry so the internal microphone works out of the box. Signed-off-by: Azamat Almazbek uulu Reviewed-by: Vijendar Mukunda Link: https://patch.msgid.link/20260221114813.5610-1-almazbek1608@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7035ef0f20babc348035df02ea4bd354c986fabf Author: Tomas Henzl Date: Tue Feb 10 20:18:50 2026 +0100 scsi: ses: Fix devices attaching to different hosts [ Upstream commit 70ca8caa96ce473647054f5c7b9dab5423902402 ] On a multipath SAS system some devices don't end up with correct symlinks from the SCSI device to its enclosure. Some devices even have enclosure links pointing to enclosures attached to different SCSI hosts. ses_match_to_enclosure() calls enclosure_for_each_device() which iterates over all enclosures on the system, not just enclosures attached to the current SCSI host. Replace the iteration with a direct call to ses_enclosure_find_by_addr(). Reviewed-by: David Jeffery Signed-off-by: Tomas Henzl Link: https://patch.msgid.link/20260210191850.36784-1-thenzl@redhat.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 8c61a746f7bb836089aa3379f0aa170dba486c0a Author: Sofia Schneider Date: Sun Feb 22 23:52:40 2026 -0300 ACPI: OSI: Add DMI quirk for Acer Aspire One D255 [ Upstream commit 5ede90206273ff156a778254f0f972a55e973c89 ] The screen backlight turns off during boot (specifically during udev device initialization) when returning true for _OSI("Windows 2009"). Analyzing the device's DSDT reveals that the firmware takes a different code path when Windows 7 is reported, which leads to the backlight shutoff. Add a DMI quirk to invoke dmi_disable_osi_win7 for this model. Signed-off-by: Sofia Schneider Link: https://patch.msgid.link/20260223025240.518509-1-sofia@schn.dev Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit e03d7bddf0eccd3847b4f470f3a71304e06218b8 Author: Ramanathan Choodamani Date: Thu Feb 5 15:12:16 2026 +0530 wifi: mac80211: set default WMM parameters on all links [ Upstream commit 2259d14499d16b115ef8d5d2ddc867e2be7cb5b5 ] Currently, mac80211 only initializes default WMM parameters on the deflink during do_open(). For MLO cases, this leaves the additional links without proper WMM defaults if hostapd does not supply per-link WMM parameters, leading to inconsistent QoS behavior across links. Set default WMM parameters for each link during ieee80211_vif_update_links(), because this ensures all individual links in an MLD have valid WMM settings during bring-up and behave consistently across different BSS. Signed-off-by: Ramanathan Choodamani Signed-off-by: Aishwarya R Link: https://patch.msgid.link/20260205094216.3093542-1-aishwarya.r@oss.qualcomm.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit af8f4be3b68ac8caa41c8e5ead0eeaf5e85e42d0 Author: Al Viro Date: Sat Feb 7 08:25:24 2026 +0000 unshare: fix unshare_fs() handling [ Upstream commit 6c4b2243cb6c0755159bd567130d5e12e7b10d9f ] There's an unpleasant corner case in unshare(2), when we have a CLONE_NEWNS in flags and current->fs hadn't been shared at all; in that case copy_mnt_ns() gets passed current->fs instead of a private copy, which causes interesting warts in proof of correctness] > I guess if private means fs->users == 1, the condition could still be true. Unfortunately, it's worse than just a convoluted proof of correctness. Consider the case when we have CLONE_NEWCGROUP in addition to CLONE_NEWNS (and current->fs->users == 1). We pass current->fs to copy_mnt_ns(), all right. Suppose it succeeds and flips current->fs->{pwd,root} to corresponding locations in the new namespace. Now we proceed to copy_cgroup_ns(), which fails (e.g. with -ENOMEM). We call put_mnt_ns() on the namespace created by copy_mnt_ns(), it's destroyed and its mount tree is dissolved, but... current->fs->root and current->fs->pwd are both left pointing to now detached mounts. They are pinning those, so it's not a UAF, but it leaves the calling process with unshare(2) failing with -ENOMEM _and_ leaving it with pwd and root on detached isolated mounts. The last part is clearly a bug. There is other fun related to that mess (races with pivot_root(), including the one between pivot_root() and fork(), of all things), but this one is easy to isolate and fix - treat CLONE_NEWNS as "allocate a new fs_struct even if it hadn't been shared in the first place". Sure, we could go for something like "if both CLONE_NEWNS *and* one of the things that might end up failing after copy_mnt_ns() call in create_new_namespaces() are set, force allocation of new fs_struct", but let's keep it simple - the cost of copy_fs_struct() is trivial. Another benefit is that copy_mnt_ns() with CLONE_NEWNS *always* gets a freshly allocated fs_struct, yet to be attached to anything. That seriously simplifies the analysis... FWIW, that bug had been there since the introduction of unshare(2) ;-/ Signed-off-by: Al Viro Link: https://patch.msgid.link/20260207082524.GE3183987@ZenIV Tested-by: Waiman Long Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 6407e8baef0ac1a3ccb546e54522d61660574b57 Author: Sean Rhodes Date: Thu Feb 19 20:14:26 2026 +0000 ALSA: hda/realtek: Fix speaker pop on Star Labs StarFighter [ Upstream commit 1cb3c20688fc8380c9b365d03aea7e84faf6a9fd ] On Star Labs StarFighter (Realtek ALC233/235), the internal speakers can emit an audible pop when entering or leaving runtime suspend. Mute the speaker output paths via snd_hda_gen_shutup_speakers() in the Realtek shutup callback before the codec is powered down. This is enough to avoid the pop without special EAPD handling. Test results: - runtime PM pop fixed - still reaches D3 (PCI 0000:00:1f.3 power_state=D3hot) - does not address pops on cold boot (G3 exit) or around display manager start/shutdown journalctl -k (boot): - snd_hda_codec_alc269 hdaudioC0D0: ALC233: picked fixup for PCI SSID 7017:2014 - snd_hda_codec_alc269 hdaudioC0D0: autoconfig for ALC233: line_outs=1 (0x1b/0x0/0x0/0x0/0x0) type:speaker Suggested-by: Takashi Iwai Tested-by: Sean Rhodes Signed-off-by: Sean Rhodes Link: https://patch.msgid.link/4d5fb71b132bb283fd41c622b8413770b2065242.1771532060.git.sean@starlabs.systems Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit e978a36f332ede78eb4de037b517db16265d420d Author: Ranjan Kumar Date: Thu Feb 12 12:30:26 2026 +0530 scsi: mpi3mr: Add NULL checks when resetting request and reply queues [ Upstream commit fa96392ebebc8fade2b878acb14cce0f71016503 ] The driver encountered a crash during resource cleanup when the reply and request queues were NULL due to freed memory. This issue occurred when the creation of reply or request queues failed, and the driver freed the memory first, but attempted to mem set the content of the freed memory, leading to a system crash. Add NULL pointer checks for reply and request queues before accessing the reply/request memory during cleanup Signed-off-by: Ranjan Kumar Link: https://patch.msgid.link/20260212070026.30263-1-ranjan.kumar@broadcom.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 379e19e820dd1c6145426b97467728b3b89c0b42 Author: Edward Adam Davis Date: Fri Feb 6 14:20:28 2026 +0800 fs: init flags_valid before calling vfs_fileattr_get [ Upstream commit cb184dd19154fc486fa3d9e02afe70a97e54e055 ] syzbot reported a uninit-value bug in [1]. Similar to the "*get" context where the kernel's internal file_kattr structure is initialized before calling vfs_fileattr_get(), we should use the same mechanism when using fa. [1] BUG: KMSAN: uninit-value in fuse_fileattr_get+0xeb4/0x1450 fs/fuse/ioctl.c:517 fuse_fileattr_get+0xeb4/0x1450 fs/fuse/ioctl.c:517 vfs_fileattr_get fs/file_attr.c:94 [inline] __do_sys_file_getattr fs/file_attr.c:416 [inline] Local variable fa.i created at: __do_sys_file_getattr fs/file_attr.c:380 [inline] __se_sys_file_getattr+0x8c/0xbd0 fs/file_attr.c:372 Reported-by: syzbot+7c31755f2cea07838b0c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=7c31755f2cea07838b0c Tested-by: syzbot+7c31755f2cea07838b0c@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Link: https://patch.msgid.link/tencent_B6C4583771D76766D71362A368696EC3B605@qq.com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 22e54d67b2f57c47e0b9a172e3a09f5a5f347616 Author: Won Jung Date: Wed Feb 11 15:01:05 2026 +0900 scsi: ufs: core: Reset urgent_bkops_lvl to allow runtime PM power mode [ Upstream commit 5b313760059c9df7d60aba7832279bcb81b4aec0 ] Ensures that UFS Runtime PM can achieve power saving after System PM suspend by resetting hba->urgent_bkops_lvl. Also modify the ufshcd_bkops_exception_event_handler to avoid setting urgent_bkops_lvl when status is 0, which helps maintain optimal power management. On UFS devices supporting UFSHCD_CAP_AUTO_BKOPS_SUSPEND, a BKOPS exception event can lead to a situation where UFS Runtime PM can't enter low-power mode states even after the BKOPS exception has been resolved. BKOPS exception with bkops status 0 occurs, the driver logs: "ufshcd_bkops_exception_event_handler: device raised urgent BKOPS exception for bkops status 0" When a BKOPS exception occurs, ufshcd_bkops_exception_event_handler() reads the BKOPS status and sets hba->urgent_bkops_lvl to BKOPS_STATUS_NO_OP(0). This allows the device to perform Runtime PM without changing the UFS power mode. (__ufshcd_wl_suspend(hba, UFS_RUNTIME_PM)) During system PM suspend, ufshcd_disable_auto_bkops() is called, disabling auto bkops. After UFS System PM Resume, when runtime PM attempts to suspend again, ufshcd_urgent_bkops() is invoked. Since hba->urgent_bkops_lvl remains at BKOPS_STATUS_NO_OP(0), ufshcd_enable_auto_bkops() is triggered. However, in ufshcd_bkops_ctrl(), the driver compares the current BKOPS status with hba->urgent_bkops_lvl, and only enables auto bkops if curr_status >= hba->urgent_bkops_lvl. Since both values are 0, the condition is met As a result, __ufshcd_wl_suspend(hba, UFS_RUNTIME_PM) skips power mode transitions and remains in an active state, preventing power saving even though no urgent BKOPS condition exists. Signed-off-by: Won Jung Reviewed-by: Peter Wang Link: https://patch.msgid.link/1891546521.01770806581968.JavaMail.epsvc@epcpadp2new Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 55d1e86cb0c90c07a8ed875eac204d232c2b7b77 Author: Piotr Mazek Date: Thu Feb 5 23:05:02 2026 +0100 ACPI: PM: Save NVS memory on Lenovo G70-35 [ Upstream commit 023cd6d90f8aa2ef7b72d84be84a18e61ecebd64 ] [821d6f0359b0614792ab8e2fb93b503e25a65079] prevented machines produced later than 2012 from saving NVS region to accelerate S3. Despite being made after 2012, Lenovo G70-35 still needs NVS memory saving during S3. A quirk is introduced for this platform. Signed-off-by: Piotr Mazek [ rjw: Subject adjustment ] Link: https://patch.msgid.link/GV2PPF3CD5B63CC2442EE3F76F8443EAD90D499A@GV2PPF3CD5B63CC.EURP251.PROD.OUTLOOK.COM Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit c2e73d8acd056347a70047e6be7cd98e0e811dfa Author: Jan Kiszka Date: Thu Jan 29 15:30:39 2026 +0100 scsi: storvsc: Fix scheduling while atomic on PREEMPT_RT [ Upstream commit 57297736c08233987e5d29ce6584c6ca2a831b12 ] This resolves the follow splat and lock-up when running with PREEMPT_RT enabled on Hyper-V: [ 415.140818] BUG: scheduling while atomic: stress-ng-iomix/1048/0x00000002 [ 415.140822] INFO: lockdep is turned off. [ 415.140823] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec ghash_clmulni_intel aesni_intel rapl binfmt_misc nls_ascii nls_cp437 vfat fat snd_pcm hyperv_drm snd_timer drm_client_lib drm_shmem_helper snd sg soundcore drm_kms_helper pcspkr hv_balloon hv_utils evdev joydev drm configfs efi_pstore nfnetlink vsock_loopback vmw_vsock_virtio_transport_common hv_sock vmw_vsock_vmci_transport vsock vmw_vmci efivarfs autofs4 ext4 crc16 mbcache jbd2 sr_mod sd_mod cdrom hv_storvsc serio_raw hid_generic scsi_transport_fc hid_hyperv scsi_mod hid hv_netvsc hyperv_keyboard scsi_common [ 415.140846] Preemption disabled at: [ 415.140847] [] storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc] [ 415.140854] CPU: 8 UID: 0 PID: 1048 Comm: stress-ng-iomix Not tainted 6.19.0-rc7 #30 PREEMPT_{RT,(full)} [ 415.140856] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/04/2024 [ 415.140857] Call Trace: [ 415.140861] [ 415.140861] ? storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc] [ 415.140863] dump_stack_lvl+0x91/0xb0 [ 415.140870] __schedule_bug+0x9c/0xc0 [ 415.140875] __schedule+0xdf6/0x1300 [ 415.140877] ? rtlock_slowlock_locked+0x56c/0x1980 [ 415.140879] ? rcu_is_watching+0x12/0x60 [ 415.140883] schedule_rtlock+0x21/0x40 [ 415.140885] rtlock_slowlock_locked+0x502/0x1980 [ 415.140891] rt_spin_lock+0x89/0x1e0 [ 415.140893] hv_ringbuffer_write+0x87/0x2a0 [ 415.140899] vmbus_sendpacket_mpb_desc+0xb6/0xe0 [ 415.140900] ? rcu_is_watching+0x12/0x60 [ 415.140902] storvsc_queuecommand+0x669/0xbe0 [hv_storvsc] [ 415.140904] ? HARDIRQ_verbose+0x10/0x10 [ 415.140908] ? __rq_qos_issue+0x28/0x40 [ 415.140911] scsi_queue_rq+0x760/0xd80 [scsi_mod] [ 415.140926] __blk_mq_issue_directly+0x4a/0xc0 [ 415.140928] blk_mq_issue_direct+0x87/0x2b0 [ 415.140931] blk_mq_dispatch_queue_requests+0x120/0x440 [ 415.140933] blk_mq_flush_plug_list+0x7a/0x1a0 [ 415.140935] __blk_flush_plug+0xf4/0x150 [ 415.140940] __submit_bio+0x2b2/0x5c0 [ 415.140944] ? submit_bio_noacct_nocheck+0x272/0x360 [ 415.140946] submit_bio_noacct_nocheck+0x272/0x360 [ 415.140951] ext4_read_bh_lock+0x3e/0x60 [ext4] [ 415.140995] ext4_block_write_begin+0x396/0x650 [ext4] [ 415.141018] ? __pfx_ext4_da_get_block_prep+0x10/0x10 [ext4] [ 415.141038] ext4_da_write_begin+0x1c4/0x350 [ext4] [ 415.141060] generic_perform_write+0x14e/0x2c0 [ 415.141065] ext4_buffered_write_iter+0x6b/0x120 [ext4] [ 415.141083] vfs_write+0x2ca/0x570 [ 415.141087] ksys_write+0x76/0xf0 [ 415.141089] do_syscall_64+0x99/0x1490 [ 415.141093] ? rcu_is_watching+0x12/0x60 [ 415.141095] ? finish_task_switch.isra.0+0xdf/0x3d0 [ 415.141097] ? rcu_is_watching+0x12/0x60 [ 415.141098] ? lock_release+0x1f0/0x2a0 [ 415.141100] ? rcu_is_watching+0x12/0x60 [ 415.141101] ? finish_task_switch.isra.0+0xe4/0x3d0 [ 415.141103] ? rcu_is_watching+0x12/0x60 [ 415.141104] ? __schedule+0xb34/0x1300 [ 415.141106] ? hrtimer_try_to_cancel+0x1d/0x170 [ 415.141109] ? do_nanosleep+0x8b/0x160 [ 415.141111] ? hrtimer_nanosleep+0x89/0x100 [ 415.141114] ? __pfx_hrtimer_wakeup+0x10/0x10 [ 415.141116] ? xfd_validate_state+0x26/0x90 [ 415.141118] ? rcu_is_watching+0x12/0x60 [ 415.141120] ? do_syscall_64+0x1e0/0x1490 [ 415.141121] ? do_syscall_64+0x1e0/0x1490 [ 415.141123] ? rcu_is_watching+0x12/0x60 [ 415.141124] ? do_syscall_64+0x1e0/0x1490 [ 415.141125] ? do_syscall_64+0x1e0/0x1490 [ 415.141127] ? irqentry_exit+0x140/0x7e0 [ 415.141129] entry_SYSCALL_64_after_hwframe+0x76/0x7e get_cpu() disables preemption while the spinlock hv_ringbuffer_write is using is converted to an rt-mutex under PREEMPT_RT. Signed-off-by: Jan Kiszka Tested-by: Florian Bezdeka Reviewed-by: Michael Kelley Tested-by: Michael Kelley Link: https://patch.msgid.link/0c7fb5cd-fb21-4760-8593-e04bade84744@siemens.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e8a59ed2e9827903de8376befefc4be535bc625d Author: Alexandre Frade Date: Sat Mar 14 17:20:06 2026 +0000 Linux 6.18.18-xanmod1 Signed-off-by: Alexandre Frade commit 516366bfa4890677f7a7fb266a04cf0aba9f63ae Merge: fb960c52c72f 3318f10fa289 Author: Alexandre Frade Date: Sat Mar 14 17:19:26 2026 +0000 Merge tag 'v6.18.18' into 6.18 This is the 6.18.18 stable release commit 3318f10fa28986dc5767444de585e00369c4ace3 Author: Greg Kroah-Hartman Date: Fri Mar 13 17:23:30 2026 +0100 Linux 6.18.18 Link: https://lore.kernel.org/r/20260312200326.246396673@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Shuah Khan Tested-by: Ron Economos Tested-by: Barry K. Nathan Tested-by: Jon Hunter Signed-off-by: Greg Kroah-Hartman commit 6c5e8f16b5e8e614e829aaf38619bdd79107bb0a Author: Niklas Cassel Date: Tue Mar 3 11:03:42 2026 +0100 ata: libata: cancel pending work after clearing deferred_qc commit aac9b27f7c1f2b2cf7f50a9ca633ecbbcaf22af9 upstream. Syzbot reported a WARN_ON() in ata_scsi_deferred_qc_work(), caused by ap->ops->qc_defer() returning non-zero before issuing the deferred qc. ata_scsi_schedule_deferred_qc() is called during each command completion. This function will check if there is a deferred QC, and if ap->ops->qc_defer() returns zero, meaning that it is possible to queue the deferred qc at this time (without being deferred), then it will queue the work which will issue the deferred qc. Once the work get to run, which can potentially be a very long time after the work was scheduled, there is a WARN_ON() if ap->ops->qc_defer() returns non-zero. While we hold the ap->lock both when assigning and clearing deferred_qc, and the work itself holds the ap->lock, the code currently does not cancel the work after clearing the deferred qc. This means that the following scenario can happen: 1) One or several NCQ commands are queued. 2) A non-NCQ command is queued, gets stored in ap->deferred_qc. 3) Last NCQ command gets completed, work is queued to issue the deferred qc. 4) Timeout or error happens, ap->deferred_qc is cleared. The queued work is currently NOT canceled. 5) Port is reset. 6) One or several NCQ commands are queued. 7) A non-NCQ command is queued, gets stored in ap->deferred_qc. 8) Work is finally run. Yet at this time, there is still NCQ commands in flight. The work in 8) really belongs to the non-NCQ command in 2), not to the non-NCQ command in 7). The reason why the work is executed when it is not supposed to, is because it was never canceled when ap->deferred_qc was cleared in 4). Thus, ensure that we always cancel the work after clearing ap->deferred_qc. Another potential fix would have been to let ata_scsi_deferred_qc_work() do nothing if ap->ops->qc_defer() returns non-zero. However, canceling the work when clearing ap->deferred_qc seems slightly more logical, as we hold the ap->lock when clearing ap->deferred_qc, so we know that the work cannot be holding the lock. (The function could be waiting for the lock, but that is okay since it will do nothing if ap->deferred_qc is not set.) Reported-by: syzbot+bcaf842a1e8ead8dfb89@syzkaller.appspotmail.com Fixes: 0ea84089dbf6 ("ata: libata-scsi: avoid Non-NCQ command starvation") Fixes: eddb98ad9364 ("ata: libata-eh: correctly handle deferred qc timeouts") Reviewed-by: Igor Pylypiv Reviewed-by: Damien Le Moal Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit 13bc2772414d68e94e273dea013181a986948ddf Author: John Johansen Date: Sun Mar 1 16:10:51 2026 -0800 apparmor: fix race between freeing data and fs accessing it commit 8e135b8aee5a06c52a4347a5a6d51223c6f36ba3 upstream. AppArmor was putting the reference to i_private data on its end after removing the original entry from the file system. However the inode can aand does live beyond that point and it is possible that some of the fs call back functions will be invoked after the reference has been put, which results in a race between freeing the data and accessing it through the fs. While the rawdata/loaddata is the most likely candidate to fail the race, as it has the fewest references. If properly crafted it might be possible to trigger a race for the other types stored in i_private. Fix this by moving the put of i_private referenced data to the correct place which is during inode eviction. Fixes: c961ee5f21b20 ("apparmor: convert from securityfs to apparmorfs for policy ns files") Reported-by: Qualys Security Advisory Reviewed-by: Georgia Garcia Reviewed-by: Maxime Bélair Reviewed-by: Cengiz Can Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit af782cc8871e3683ddd5a3cd2f7df526599863a9 Author: John Johansen Date: Tue Feb 24 10:20:02 2026 -0800 apparmor: fix race on rawdata dereference commit a0b7091c4de45a7325c8780e6934a894f92ac86b upstream. There is a race condition that leads to a use-after-free situation: because the rawdata inodes are not refcounted, an attacker can start open()ing one of the rawdata files, and at the same time remove the last reference to this rawdata (by removing the corresponding profile, for example), which frees its struct aa_loaddata; as a result, when seq_rawdata_open() is reached, i_private is a dangling pointer and freed memory is accessed. The rawdata inodes weren't refcounted to avoid a circular refcount and were supposed to be held by the profile rawdata reference. However during profile removal there is a window where the vfs and profile destruction race, resulting in the use after free. Fix this by moving to a double refcount scheme. Where the profile refcount on rawdata is used to break the circular dependency. Allowing for freeing of the rawdata once all inode references to the rawdata are put. Fixes: 5d5182cae401 ("apparmor: move to per loaddata files, instead of replicating in profiles") Reported-by: Qualys Security Advisory Reviewed-by: Georgia Garcia Reviewed-by: Maxime Bélair Reviewed-by: Cengiz Can Tested-by: Salvatore Bonaccorso Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit 623a9d211bbbb031bb1cbdb38b23487648167f8a Author: John Johansen Date: Fri Oct 17 01:53:00 2025 -0700 apparmor: fix differential encoding verification commit 39440b137546a3aa383cfdabc605fb73811b6093 upstream. Differential encoding allows loops to be created if it is abused. To prevent this the unpack should verify that a diff-encode chain terminates. Unfortunately the differential encode verification had two bugs. 1. it conflated states that had gone through check and already been marked, with states that were currently being checked and marked. This means that loops in the current chain being verified are treated as a chain that has already been verified. 2. the order bailout on already checked states compared current chain check iterators j,k instead of using the outer loop iterator i. Meaning a step backwards in states in the current chain verification was being mistaken for moving to an already verified state. Move to a double mark scheme where already verified states get a different mark, than the current chain being kept. This enables us to also drop the backwards verification check that was the cause of the second error as any already verified state is already marked. Fixes: 031dcc8f4e84 ("apparmor: dfa add support for state differential encoding") Reported-by: Qualys Security Advisory Tested-by: Salvatore Bonaccorso Reviewed-by: Georgia Garcia Reviewed-by: Cengiz Can Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit b60b3f7a35c46b2e0ca934f9c988b8fca06d76c6 Author: John Johansen Date: Fri Nov 7 08:36:04 2025 -0800 apparmor: fix unprivileged local user can do privileged policy management commit 6601e13e82841879406bf9f369032656f441a425 upstream. An unprivileged local user can load, replace, and remove profiles by opening the apparmorfs interfaces, via a confused deputy attack, by passing the opened fd to a privileged process, and getting the privileged process to write to the interface. This does require a privileged target that can be manipulated to do the write for the unprivileged process, but once such access is achieved full policy management is possible and all the possible implications that implies: removing confinement, DoS of system or target applications by denying all execution, by-passing the unprivileged user namespace restriction, to exploiting kernel bugs for a local privilege escalation. The policy management interface can not have its permissions simply changed from 0666 to 0600 because non-root processes need to be able to load policy to different policy namespaces. Instead ensure the task writing the interface has privileges that are a subset of the task that opened the interface. This is already done via policy for confined processes, but unconfined can delegate access to the opened fd, by-passing the usual policy check. Fixes: b7fd2c0340eac ("apparmor: add per policy ns .load, .replace, .remove interface files") Reported-by: Qualys Security Advisory Tested-by: Salvatore Bonaccorso Reviewed-by: Georgia Garcia Reviewed-by: Cengiz Can Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit 7998ab3010d2317643f91828f1853d954ef31387 Author: John Johansen Date: Wed Sep 10 06:22:17 2025 -0700 apparmor: Fix double free of ns_name in aa_replace_profiles() commit 5df0c44e8f5f619d3beb871207aded7c78414502 upstream. if ns_name is NULL after 1071 error = aa_unpack(udata, &lh, &ns_name); and if ent->ns_name contains an ns_name in 1089 } else if (ent->ns_name) { then ns_name is assigned the ent->ns_name 1095 ns_name = ent->ns_name; however ent->ns_name is freed at 1262 aa_load_ent_free(ent); and then again when freeing ns_name at 1270 kfree(ns_name); Fix this by NULLing out ent->ns_name after it is transferred to ns_name Fixes: 145a0ef21c8e9 ("apparmor: fix blob compression when ns is forced on a policy load ") Reported-by: Qualys Security Advisory Tested-by: Salvatore Bonaccorso Reviewed-by: Georgia Garcia Reviewed-by: Cengiz Can Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit 5a68e46dfe0c8c8ffc6f425ebc4cae6238566ecc Author: Massimiliano Pellizzer Date: Thu Jan 29 16:51:11 2026 +0100 apparmor: fix missing bounds check on DEFAULT table in verify_dfa() commit d352873bbefa7eb39995239d0b44ccdf8aaa79a4 upstream. The verify_dfa() function only checks DEFAULT_TABLE bounds when the state is not differentially encoded. When the verification loop traverses the differential encoding chain, it reads k = DEFAULT_TABLE[j] and uses k as an array index without validation. A malformed DFA with DEFAULT_TABLE[j] >= state_count, therefore, causes both out-of-bounds reads and writes. [ 57.179855] ================================================================== [ 57.180549] BUG: KASAN: slab-out-of-bounds in verify_dfa+0x59a/0x660 [ 57.180904] Read of size 4 at addr ffff888100eadec4 by task su/993 [ 57.181554] CPU: 1 UID: 0 PID: 993 Comm: su Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy) [ 57.181558] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 57.181563] Call Trace: [ 57.181572] [ 57.181577] dump_stack_lvl+0x5e/0x80 [ 57.181596] print_report+0xc8/0x270 [ 57.181605] ? verify_dfa+0x59a/0x660 [ 57.181608] kasan_report+0x118/0x150 [ 57.181620] ? verify_dfa+0x59a/0x660 [ 57.181623] verify_dfa+0x59a/0x660 [ 57.181627] aa_dfa_unpack+0x1610/0x1740 [ 57.181629] ? __kmalloc_cache_noprof+0x1d0/0x470 [ 57.181640] unpack_pdb+0x86d/0x46b0 [ 57.181647] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181653] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181656] ? aa_unpack_nameX+0x1a8/0x300 [ 57.181659] aa_unpack+0x20b0/0x4c30 [ 57.181662] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181664] ? stack_depot_save_flags+0x33/0x700 [ 57.181681] ? kasan_save_track+0x4f/0x80 [ 57.181683] ? kasan_save_track+0x3e/0x80 [ 57.181686] ? __kasan_kmalloc+0x93/0xb0 [ 57.181688] ? __kvmalloc_node_noprof+0x44a/0x780 [ 57.181693] ? aa_simple_write_to_buffer+0x54/0x130 [ 57.181697] ? policy_update+0x154/0x330 [ 57.181704] aa_replace_profiles+0x15a/0x1dd0 [ 57.181707] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181710] ? __kvmalloc_node_noprof+0x44a/0x780 [ 57.181712] ? aa_loaddata_alloc+0x77/0x140 [ 57.181715] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181717] ? _copy_from_user+0x2a/0x70 [ 57.181730] policy_update+0x17a/0x330 [ 57.181733] profile_replace+0x153/0x1a0 [ 57.181735] ? rw_verify_area+0x93/0x2d0 [ 57.181740] vfs_write+0x235/0xab0 [ 57.181745] ksys_write+0xb0/0x170 [ 57.181748] do_syscall_64+0x8e/0x660 [ 57.181762] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 57.181765] RIP: 0033:0x7f6192792eb2 Remove the MATCH_FLAG_DIFF_ENCODE condition to validate all DEFAULT_TABLE entries unconditionally. Fixes: 031dcc8f4e84 ("apparmor: dfa add support for state differential encoding") Reported-by: Qualys Security Advisory Tested-by: Salvatore Bonaccorso Reviewed-by: Georgia Garcia Reviewed-by: Cengiz Can Signed-off-by: Massimiliano Pellizzer Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit 0510d1ba0976f97f521feb2b75b0572ea5df3ceb Author: Massimiliano Pellizzer Date: Thu Jan 29 17:08:25 2026 +0100 apparmor: fix side-effect bug in match_char() macro usage commit 8756b68edae37ff546c02091989a4ceab3f20abd upstream. The match_char() macro evaluates its character parameter multiple times when traversing differential encoding chains. When invoked with *str++, the string pointer advances on each iteration of the inner do-while loop, causing the DFA to check different characters at each iteration and therefore skip input characters. This results in out-of-bounds reads when the pointer advances past the input buffer boundary. [ 94.984676] ================================================================== [ 94.985301] BUG: KASAN: slab-out-of-bounds in aa_dfa_match+0x5ae/0x760 [ 94.985655] Read of size 1 at addr ffff888100342000 by task file/976 [ 94.986319] CPU: 7 UID: 1000 PID: 976 Comm: file Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy) [ 94.986322] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 94.986329] Call Trace: [ 94.986341] [ 94.986347] dump_stack_lvl+0x5e/0x80 [ 94.986374] print_report+0xc8/0x270 [ 94.986384] ? aa_dfa_match+0x5ae/0x760 [ 94.986388] kasan_report+0x118/0x150 [ 94.986401] ? aa_dfa_match+0x5ae/0x760 [ 94.986405] aa_dfa_match+0x5ae/0x760 [ 94.986408] __aa_path_perm+0x131/0x400 [ 94.986418] aa_path_perm+0x219/0x2f0 [ 94.986424] apparmor_file_open+0x345/0x570 [ 94.986431] security_file_open+0x5c/0x140 [ 94.986442] do_dentry_open+0x2f6/0x1120 [ 94.986450] vfs_open+0x38/0x2b0 [ 94.986453] ? may_open+0x1e2/0x2b0 [ 94.986466] path_openat+0x231b/0x2b30 [ 94.986469] ? __x64_sys_openat+0xf8/0x130 [ 94.986477] do_file_open+0x19d/0x360 [ 94.986487] do_sys_openat2+0x98/0x100 [ 94.986491] __x64_sys_openat+0xf8/0x130 [ 94.986499] do_syscall_64+0x8e/0x660 [ 94.986515] ? count_memcg_events+0x15f/0x3c0 [ 94.986526] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986540] ? handle_mm_fault+0x1639/0x1ef0 [ 94.986551] ? vma_start_read+0xf0/0x320 [ 94.986558] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986561] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986563] ? fpregs_assert_state_consistent+0x50/0xe0 [ 94.986572] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986574] ? arch_exit_to_user_mode_prepare+0x9/0xb0 [ 94.986587] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986588] ? irqentry_exit+0x3c/0x590 [ 94.986595] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 94.986597] RIP: 0033:0x7fda4a79c3ea Fix by extracting the character value before invoking match_char, ensuring single evaluation per outer loop. Fixes: 074c1cd798cb ("apparmor: dfa move character match into a macro") Reported-by: Qualys Security Advisory Tested-by: Salvatore Bonaccorso Reviewed-by: Georgia Garcia Reviewed-by: Cengiz Can Signed-off-by: Massimiliano Pellizzer Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit d42b2b6bb77ca40ee34ab74ad79305840b5f315d Author: John Johansen Date: Tue Mar 3 11:08:02 2026 -0800 apparmor: fix: limit the number of levels of policy namespaces commit 306039414932c80f8420695a24d4fe10c84ccfb2 upstream. Currently the number of policy namespaces is not bounded relying on the user namespace limit. However policy namespaces aren't strictly tied to user namespaces and it is possible to create them and nest them arbitrarily deep which can be used to exhaust system resource. Hard cap policy namespaces to the same depth as user namespaces. Fixes: c88d4c7b049e8 ("AppArmor: core policy routines") Reported-by: Qualys Security Advisory Reviewed-by: Ryan Lee Reviewed-by: Cengiz Can Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit 7eade846e013cbe8d2dc4a484463aa19e6515c7f Author: Massimiliano Pellizzer Date: Tue Jan 13 09:09:43 2026 +0100 apparmor: replace recursive profile removal with iterative approach commit ab09264660f9de5d05d1ef4e225aa447c63a8747 upstream. The profile removal code uses recursion when removing nested profiles, which can lead to kernel stack exhaustion and system crashes. Reproducer: $ pf='a'; for ((i=0; i<1024; i++)); do echo -e "profile $pf { \n }" | apparmor_parser -K -a; pf="$pf//x"; done $ echo -n a > /sys/kernel/security/apparmor/.remove Replace the recursive __aa_profile_list_release() approach with an iterative approach in __remove_profile(). The function repeatedly finds and removes leaf profiles until the entire subtree is removed, maintaining the same removal semantic without recursion. Fixes: c88d4c7b049e ("AppArmor: core policy routines") Reported-by: Qualys Security Advisory Tested-by: Salvatore Bonaccorso Reviewed-by: Georgia Garcia Reviewed-by: Cengiz Can Signed-off-by: Massimiliano Pellizzer Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit 4f0889f2df1ab99224a5e1ac4e20437eea5fe38e Author: Massimiliano Pellizzer Date: Tue Jan 20 15:24:04 2026 +0100 apparmor: fix memory leak in verify_header commit e38c55d9f834e5b848bfed0f5c586aaf45acb825 upstream. The function sets `*ns = NULL` on every call, leaking the namespace string allocated in previous iterations when multiple profiles are unpacked. This also breaks namespace consistency checking since *ns is always NULL when the comparison is made. Remove the incorrect assignment. The caller (aa_unpack) initializes *ns to NULL once before the loop, which is sufficient. Fixes: dd51c8485763 ("apparmor: provide base for multiple profiles to be replaced at once") Reported-by: Qualys Security Advisory Tested-by: Salvatore Bonaccorso Reviewed-by: Georgia Garcia Reviewed-by: Cengiz Can Signed-off-by: Massimiliano Pellizzer Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit 0baadb0eece2c4d939db10d3c323b4652ac79a58 Author: Massimiliano Pellizzer Date: Thu Jan 15 15:30:50 2026 +0100 apparmor: validate DFA start states are in bounds in unpack_pdb commit 9063d7e2615f4a7ab321de6b520e23d370e58816 upstream. Start states are read from untrusted data and used as indexes into the DFA state tables. The aa_dfa_next() function call in unpack_pdb() will access dfa->tables[YYTD_ID_BASE][start], and if the start state exceeds the number of states in the DFA, this results in an out-of-bound read. ================================================================== BUG: KASAN: slab-out-of-bounds in aa_dfa_next+0x2a1/0x360 Read of size 4 at addr ffff88811956fb90 by task su/1097 ... Reject policies with out-of-bounds start states during unpacking to prevent the issue. Fixes: ad5ff3db53c6 ("AppArmor: Add ability to load extended policy") Reported-by: Qualys Security Advisory Tested-by: Salvatore Bonaccorso Reviewed-by: Georgia Garcia Reviewed-by: Cengiz Can Signed-off-by: Massimiliano Pellizzer Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit 380ad8b7c65ea7aa10ef2258297079ed5ac1f5b6 Author: Victor Nogueira Date: Wed Feb 25 10:43:48 2026 -0300 net/sched: Only allow act_ct to bind to clsact/ingress qdiscs and shared blocks commit 11cb63b0d1a0685e0831ae3c77223e002ef18189 upstream. As Paolo said earlier [1]: "Since the blamed commit below, classify can return TC_ACT_CONSUMED while the current skb being held by the defragmentation engine. As reported by GangMin Kim, if such packet is that may cause a UaF when the defrag engine later on tries to tuch again such packet." act_ct was never meant to be used in the egress path, however some users are attaching it to egress today [2]. Attempting to reach a middle ground, we noticed that, while most qdiscs are not handling TC_ACT_CONSUMED, clsact/ingress qdiscs are. With that in mind, we address the issue by only allowing act_ct to bind to clsact/ingress qdiscs and shared blocks. That way it's still possible to attach act_ct to egress (albeit only with clsact). [1] https://lore.kernel.org/netdev/674b8cbfc385c6f37fb29a1de08d8fe5c2b0fbee.1771321118.git.pabeni@redhat.com/ [2] https://lore.kernel.org/netdev/cc6bfb4a-4a2b-42d8-b9ce-7ef6644fb22b@ovn.org/ Reported-by: GangMin Kim Fixes: 3f14b377d01d ("net/sched: act_ct: fix skb leak and crash on ooo frags") CC: stable@vger.kernel.org Signed-off-by: Victor Nogueira Acked-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260225134349.1287037-1-victor@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 04d75529dc0f9be78786162ebab7424af4644df2 Author: Paul Moses Date: Mon Feb 23 15:05:44 2026 +0000 net/sched: act_gate: snapshot parameters with RCU on replace commit 62413a9c3cb183afb9bb6e94dd68caf4e4145f4c upstream. The gate action can be replaced while the hrtimer callback or dump path is walking the schedule list. Convert the parameters to an RCU-protected snapshot and swap updates under tcf_lock, freeing the previous snapshot via call_rcu(). When REPLACE omits the entry list, preserve the existing schedule so the effective state is unchanged. Fixes: a51c328df310 ("net: qos: introduce a gate control flow action") Cc: stable@vger.kernel.org Signed-off-by: Paul Moses Tested-by: Vladimir Oltean Acked-by: Jamal Hadi Salim Reviewed-by: Victor Nogueira Link: https://patch.msgid.link/20260223150512.2251594-2-p@1g4.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit fb960c52c72f9507118a176c8d8ec5c8d2619f23 Author: Alexandre Frade Date: Thu Mar 12 14:16:08 2026 +0000 Linux 6.18.17-xanmod1 Signed-off-by: Alexandre Frade commit a2e6144cf49cc351dafbdb56c35b824fcccf3722 Author: Masahito S Date: Mon Aug 4 01:49:31 2025 +0900 mm: Add working set protection for anon and clean file pages sysctl vm.workingset_protection=1 by default. Signed-off-by: Alexandre Frade commit 44dfb1863e21e05ac59be621de3a1a0f33b972fa Merge: 2d6f4902b79b 93ea7e1363fb Author: Alexandre Frade Date: Thu Mar 12 14:14:32 2026 +0000 Merge tag 'v6.18.17' into 6.18 Linux 6.18.17 commit 93ea7e1363fb25c108debc34b9be4a4a036ee6d4 Author: Sasha Levin Date: Thu Mar 12 07:14:22 2026 -0400 Linux 6.18.17 Tested-by: Brett A C Sheffield Tested-by: Jon Hunter Tested-by: Dileep malepu Tested-by: Jeffrin Jose T Tested-by: Florian Fainelli Tested-by: Ron Economos Tested-by: Peter Schneider Tested-by: Mark Brown Tested-by: Shuah Khan Tested-by: Barry K. Nathan Tested-by: Miguel Ojeda Signed-off-by: Sasha Levin commit 8a185304e42e0603f0c743b9f7ef2a8f82b286ce Author: Paul Chaignon Date: Fri Feb 27 22:42:45 2026 +0100 selftests/bpf: Avoid simplification of crafted bounds test [ Upstream commit 024cea2d647ed8ab942f19544b892d324dba42b4 ] The reg_bounds_crafted tests validate the verifier's range analysis logic. They focus on the actual ranges and thus ignore the tnum. As a consequence, they carry the assumption that the tested cases can be reproduced in userspace without using the tnum information. Unfortunately, the previous change the refinement logic breaks that assumption for one test case: (u64)2147483648 (u32) [4294967294; 0x100000000] The tested bytecode is shown below. Without our previous improvement, on the false branch of the condition, R7 is only known to have u64 range [0xfffffffe; 0x100000000]. With our improvement, and using the tnum information, we can deduce that R7 equals 0x100000000. 19: (bc) w0 = w6 ; R6=0x80000000 20: (bc) w0 = w7 ; R7=scalar(smin=umin=0xfffffffe,smax=umax=0x100000000,smin32=-2,smax32=0,var_off=(0x0; 0x1ffffffff)) 21: (be) if w6 <= w7 goto pc+3 ; R6=0x80000000 R7=0x100000000 R7's tnum is (0; 0x1ffffffff). On the false branch, regs_refine_cond_op refines R7's u32 range to [0; 0x7fffffff]. Then, __reg32_deduce_bounds refines the s32 range to 0 using u32 and finally also sets u32=0. From this, __reg_bound_offset improves the tnum to (0; 0x100000000). Finally, our previous patch uses this new tnum to deduce that it only intersect with u64=[0xfffffffe; 0x100000000] in a single value: 0x100000000. Because the verifier uses the tnum to reach this constant value, the selftest is unable to reproduce it by only simulating ranges. The solution implemented in this patch is to change the test case such that there is more than one overlap value between u64 and the tnum. The max. u64 value is thus changed from 0x100000000 to 0x300000000. Acked-by: Eduard Zingerman Signed-off-by: Paul Chaignon Link: https://lore.kernel.org/r/50641c6a7ef39520595dcafa605692427c1006ec.1772225741.git.paul.chaignon@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 63b548c8629967af036a8e39651bf45032e49f97 Author: Eduard Zingerman Date: Fri Mar 6 16:02:47 2026 -0800 bpf: collect only live registers in linked regs [ Upstream commit 2658a1720a1944fbaeda937000ad2b3c3dfaf1bb ] Fix an inconsistency between func_states_equal() and collect_linked_regs(): - regsafe() uses check_ids() to verify that cached and current states have identical register id mapping. - func_states_equal() calls regsafe() only for registers computed as live by compute_live_registers(). - clean_live_states() is supposed to remove dead registers from cached states, but it can skip states belonging to an iterator-based loop. - collect_linked_regs() collects all registers sharing the same id, ignoring the marks computed by compute_live_registers(). Linked registers are stored in the state's jump history. - backtrack_insn() marks all linked registers for an instruction as precise whenever one of the linked registers is precise. The above might lead to a scenario: - There is an instruction I with register rY known to be dead at I. - Instruction I is reached via two paths: first A, then B. - On path A: - There is an id link between registers rX and rY. - Checkpoint C is created at I. - Linked register set {rX, rY} is saved to the jump history. - rX is marked as precise at I, causing both rX and rY to be marked precise at C. - On path B: - There is no id link between registers rX and rY, otherwise register states are sub-states of those in C. - Because rY is dead at I, check_ids() returns true. - Current state is considered equal to checkpoint C, propagate_precision() propagates spurious precision mark for register rY along the path B. - Depending on a program, this might hit verifier_bug() in the backtrack_insn(), e.g. if rY ∈ [r1..r5] and backtrack_insn() spots a function call. The reproducer program is in the next patch. This was hit by sched_ext scx_lavd scheduler code. Changes in tests: - verifier_scalar_ids.c selftests need modification to preserve some registers as live for __msg() checks. - exceptions_assert.c adjusted to match changes in the verifier log, R0 is dead after conditional instruction and thus does not get range. - precise.c adjusted to match changes in the verifier log, register r9 is dead after comparison and it's range is not important for test. Reported-by: Emil Tsalapatis Fixes: 0fb3cf6110a5 ("bpf: use register liveness information for func_states_equal") Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260306-linked-regs-and-propagate-precision-v1-1-18e859be570d@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 2ce8ece5a78da67834db7728edc801889a64f643 Author: Guenter Roeck Date: Thu Mar 5 11:33:39 2026 -0800 tracing: Add NULL pointer check to trigger_data_free() [ Upstream commit 457965c13f0837a289c9164b842d0860133f6274 ] If trigger_data_alloc() fails and returns NULL, event_hist_trigger_parse() jumps to the out_free error path. While kfree() safely handles a NULL pointer, trigger_data_free() does not. This causes a NULL pointer dereference in trigger_data_free() when evaluating data->cmd_ops->set_filter. Fix the problem by adding a NULL pointer check to trigger_data_free(). The problem was found by an experimental code review agent based on gemini-3.1-pro while reviewing backports into v6.18.y. Cc: Miaoqian Lin Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Steven Rostedt (Google) Link: https://patch.msgid.link/20260305193339.2810953-1-linux@roeck-us.net Fixes: 0550069cc25f ("tracing: Properly process error handling in event_hist_trigger_parse()") Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Guenter Roeck Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 52decf013d5330e2b02ce971536a59ea0305460e Author: Yifan Wu Date: Thu Mar 5 09:36:37 2026 +0800 selftest/arm64: Fix sve2p1_sigill() to hwcap test [ Upstream commit d87c828daa7ead9763416f75cc416496969cf1dc ] The FEAT_SVE2p1 is indicated by ID_AA64ZFR0_EL1.SVEver. However, the BFADD requires the FEAT_SVE_B16B16, which is indicated by ID_AA64ZFR0_EL1.B16B16. This could cause the test to incorrectly fail on a CPU that supports FEAT_SVE2.1 but not FEAT_SVE_B16B16. LD1Q Gather load quadwords which is decoded from SVE encodings and implied by FEAT_SVE2p1. Fixes: c5195b027d29 ("kselftest/arm64: Add SVE 2.1 to hwcap test") Signed-off-by: Yifan Wu Reviewed-by: Mark Brown Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit d15ba004b3214a3a1e987f16d37e4ad30a858a6c Author: Guenter Roeck Date: Thu Mar 5 18:48:05 2026 -0800 ata: libata-eh: Fix detection of deferred qc timeouts [ Upstream commit ee0e6e69a772d601e152e5368a1da25d656122a8 ] If the ata_qc_for_each_raw() loop finishes without finding a matching SCSI command for any QC, the variable qc will hold a pointer to the last element examined, which has the tag i == ATA_MAX_QUEUE - 1. This qc can match the port deferred QC (ap->deferred_qc). If that happens, the condition qc == ap->deferred_qc evaluates to true despite the loop not breaking with a match on the SCSI command for this QC. In that case, the error handler mistakenly intercepts a command that has not been issued yet and that has not timed out, and thus erroneously returning a timeout error. Fix the problem by checking for i < ATA_MAX_QUEUE in addition to qc == ap->deferred_qc. The problem was found by an experimental code review agent based on gemini-3.1-pro while reviewing backports into v6.18.y. Assisted-by: Gemini:gemini-3.1-pro Fixes: eddb98ad9364 ("ata: libata-eh: correctly handle deferred qc timeouts") Signed-off-by: Guenter Roeck [cassel: modified commit log as suggested by Damien] Reviewed-by: Damien Le Moal Signed-off-by: Niklas Cassel Signed-off-by: Sasha Levin commit 98cd8b4d0b836d3edf70161f40efd9cbb8c8f252 Author: Larysa Zaremba Date: Thu Mar 5 12:12:50 2026 +0100 xdp: produce a warning when calculated tailroom is negative [ Upstream commit 8821e857759be9db3cde337ad328b71fe5c8a55f ] Many ethernet drivers report xdp Rx queue frag size as being the same as DMA write size. However, the only user of this field, namely bpf_xdp_frags_increase_tail(), clearly expects a truesize. Such difference leads to unspecific memory corruption issues under certain circumstances, e.g. in ixgbevf maximum DMA write size is 3 KB, so when running xskxceiver's XDP_ADJUST_TAIL_GROW_MULTI_BUFF, 6K packet fully uses all DMA-writable space in 2 buffers. This would be fine, if only rxq->frag_size was properly set to 4K, but value of 3K results in a negative tailroom, because there is a non-zero page offset. We are supposed to return -EINVAL and be done with it in such case, but due to tailroom being stored as an unsigned int, it is reported to be somewhere near UINT_MAX, resulting in a tail being grown, even if the requested offset is too much (it is around 2K in the abovementioned test). This later leads to all kinds of unspecific calltraces. [ 7340.337579] xskxceiver[1440]: segfault at 1da718 ip 00007f4161aeac9d sp 00007f41615a6a00 error 6 [ 7340.338040] xskxceiver[1441]: segfault at 7f410000000b ip 00000000004042b5 sp 00007f415bffecf0 error 4 [ 7340.338179] in libc.so.6[61c9d,7f4161aaf000+160000] [ 7340.339230] in xskxceiver[42b5,400000+69000] [ 7340.340300] likely on CPU 6 (core 0, socket 6) [ 7340.340302] Code: ff ff 01 e9 f4 fe ff ff 0f 1f 44 00 00 4c 39 f0 74 73 31 c0 ba 01 00 00 00 f0 0f b1 17 0f 85 ba 00 00 00 49 8b 87 88 00 00 00 <4c> 89 70 08 eb cc 0f 1f 44 00 00 48 8d bd f0 fe ff ff 89 85 ec fe [ 7340.340888] likely on CPU 3 (core 0, socket 3) [ 7340.345088] Code: 00 00 00 ba 00 00 00 00 be 00 00 00 00 89 c7 e8 31 ca ff ff 89 45 ec 8b 45 ec 85 c0 78 07 b8 00 00 00 00 eb 46 e8 0b c8 ff ff <8b> 00 83 f8 69 74 24 e8 ff c7 ff ff 8b 00 83 f8 0b 74 18 e8 f3 c7 [ 7340.404334] Oops: general protection fault, probably for non-canonical address 0x6d255010bdffc: 0000 [#1] SMP NOPTI [ 7340.405972] CPU: 7 UID: 0 PID: 1439 Comm: xskxceiver Not tainted 6.19.0-rc1+ #21 PREEMPT(lazy) [ 7340.408006] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014 [ 7340.409716] RIP: 0010:lookup_swap_cgroup_id+0x44/0x80 [ 7340.410455] Code: 83 f8 1c 73 39 48 ba ff ff ff ff ff ff ff 03 48 8b 04 c5 20 55 fa bd 48 21 d1 48 89 ca 83 e1 01 48 d1 ea c1 e1 04 48 8d 04 90 <8b> 00 48 83 c4 10 d3 e8 c3 cc cc cc cc 31 c0 e9 98 b7 dd 00 48 89 [ 7340.412787] RSP: 0018:ffffcc5c04f7f6d0 EFLAGS: 00010202 [ 7340.413494] RAX: 0006d255010bdffc RBX: ffff891f477895a8 RCX: 0000000000000010 [ 7340.414431] RDX: 0001c17e3fffffff RSI: 00fa070000000000 RDI: 000382fc7fffffff [ 7340.415354] RBP: 00fa070000000000 R08: ffffcc5c04f7f8f8 R09: ffffcc5c04f7f7d0 [ 7340.416283] R10: ffff891f4c1a7000 R11: ffffcc5c04f7f9c8 R12: ffffcc5c04f7f7d0 [ 7340.417218] R13: 03ffffffffffffff R14: 00fa06fffffffe00 R15: ffff891f47789500 [ 7340.418229] FS: 0000000000000000(0000) GS:ffff891ffdfaa000(0000) knlGS:0000000000000000 [ 7340.419489] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 7340.420286] CR2: 00007f415bfffd58 CR3: 0000000103f03002 CR4: 0000000000772ef0 [ 7340.421237] PKRU: 55555554 [ 7340.421623] Call Trace: [ 7340.421987] [ 7340.422309] ? softleaf_from_pte+0x77/0xa0 [ 7340.422855] swap_pte_batch+0xa7/0x290 [ 7340.423363] zap_nonpresent_ptes.constprop.0.isra.0+0xd1/0x270 [ 7340.424102] zap_pte_range+0x281/0x580 [ 7340.424607] zap_pmd_range.isra.0+0xc9/0x240 [ 7340.425177] unmap_page_range+0x24d/0x420 [ 7340.425714] unmap_vmas+0xa1/0x180 [ 7340.426185] exit_mmap+0xe1/0x3b0 [ 7340.426644] __mmput+0x41/0x150 [ 7340.427098] exit_mm+0xb1/0x110 [ 7340.427539] do_exit+0x1b2/0x460 [ 7340.427992] do_group_exit+0x2d/0xc0 [ 7340.428477] get_signal+0x79d/0x7e0 [ 7340.428957] arch_do_signal_or_restart+0x34/0x100 [ 7340.429571] exit_to_user_mode_loop+0x8e/0x4c0 [ 7340.430159] do_syscall_64+0x188/0x6b0 [ 7340.430672] ? __do_sys_clone3+0xd9/0x120 [ 7340.431212] ? switch_fpu_return+0x4e/0xd0 [ 7340.431761] ? arch_exit_to_user_mode_prepare.isra.0+0xa1/0xc0 [ 7340.432498] ? do_syscall_64+0xbb/0x6b0 [ 7340.433015] ? __handle_mm_fault+0x445/0x690 [ 7340.433582] ? count_memcg_events+0xd6/0x210 [ 7340.434151] ? handle_mm_fault+0x212/0x340 [ 7340.434697] ? do_user_addr_fault+0x2b4/0x7b0 [ 7340.435271] ? clear_bhb_loop+0x30/0x80 [ 7340.435788] ? clear_bhb_loop+0x30/0x80 [ 7340.436299] ? clear_bhb_loop+0x30/0x80 [ 7340.436812] ? clear_bhb_loop+0x30/0x80 [ 7340.437323] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 7340.437973] RIP: 0033:0x7f4161b14169 [ 7340.438468] Code: Unable to access opcode bytes at 0x7f4161b1413f. [ 7340.439242] RSP: 002b:00007ffc6ebfa770 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca [ 7340.440173] RAX: fffffffffffffe00 RBX: 00000000000005a1 RCX: 00007f4161b14169 [ 7340.441061] RDX: 00000000000005a1 RSI: 0000000000000109 RDI: 00007f415bfff990 [ 7340.441943] RBP: 00007ffc6ebfa7a0 R08: 0000000000000000 R09: 00000000ffffffff [ 7340.442824] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 7340.443707] R13: 0000000000000000 R14: 00007f415bfff990 R15: 00007f415bfff6c0 [ 7340.444586] [ 7340.444922] Modules linked in: rfkill intel_rapl_msr intel_rapl_common intel_uncore_frequency_common skx_edac_common nfit libnvdimm kvm_intel vfat fat kvm snd_pcm irqbypass rapl iTCO_wdt snd_timer intel_pmc_bxt iTCO_vendor_support snd ixgbevf virtio_net soundcore i2c_i801 pcspkr libeth_xdp net_failover i2c_smbus lpc_ich failover libeth virtio_balloon joydev 9p fuse loop zram lz4hc_compress lz4_compress 9pnet_virtio 9pnet netfs ghash_clmulni_intel serio_raw qemu_fw_cfg [ 7340.449650] ---[ end trace 0000000000000000 ]--- The issue can be fixed in all in-tree drivers, but we cannot just trust OOT drivers to not do this. Therefore, make tailroom a signed int and produce a warning when it is negative to prevent such mistakes in the future. Fixes: bf25146a5595 ("bpf: add frags support to the bpf_xdp_adjust_tail() API") Reviewed-by: Aleksandr Loktionov Reviewed-by: Toke Høiland-Jørgensen Acked-by: Martin KaFai Lau Signed-off-by: Larysa Zaremba Link: https://patch.msgid.link/20260305111253.2317394-10-larysa.zaremba@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 45a41aecf5e541ec4d195ab61ec774ab45b90004 Author: Larysa Zaremba Date: Thu Mar 5 12:12:49 2026 +0100 net: enetc: use truesize as XDP RxQ info frag_size [ Upstream commit f8e18abf183dbd636a8725532c7f5aa58957de84 ] The only user of frag_size field in XDP RxQ info is bpf_xdp_frags_increase_tail(). It clearly expects truesize instead of DMA write size. Different assumptions in enetc driver configuration lead to negative tailroom. Set frag_size to the same value as frame_sz. Fixes: 2768b2e2f7d2 ("net: enetc: register XDP RX queues with frag_size") Reviewed-by: Aleksandr Loktionov Reviewed-by: Vladimir Oltean Signed-off-by: Larysa Zaremba Link: https://patch.msgid.link/20260305111253.2317394-9-larysa.zaremba@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f1ac9d19721bdeead046b77dc21e4b7dbdcd8256 Author: Larysa Zaremba Date: Thu Mar 5 12:12:47 2026 +0100 i40e: use xdp.frame_sz as XDP RxQ info frag_size [ Upstream commit c69d22c6c46a1d792ba8af3d8d6356fdc0e6f538 ] The only user of frag_size field in XDP RxQ info is bpf_xdp_frags_increase_tail(). It clearly expects whole buffer size instead of DMA write size. Different assumptions in i40e driver configuration lead to negative tailroom. Set frag_size to the same value as frame_sz in shared pages mode, use new helper to set frag_size when AF_XDP ZC is active. Fixes: a045d2f2d03d ("i40e: set xdp_rxq_info::frag_size") Reviewed-by: Aleksandr Loktionov Signed-off-by: Larysa Zaremba Link: https://patch.msgid.link/20260305111253.2317394-7-larysa.zaremba@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b6176646c36d2fcffaab0ba9568d8ace085a91a4 Author: Larysa Zaremba Date: Thu Mar 5 12:12:46 2026 +0100 i40e: fix registering XDP RxQ info [ Upstream commit 8f497dc8a61429cc004720aa8e713743355d80cf ] Current way of handling XDP RxQ info in i40e has a problem, where frag_size is not updated when xsk_buff_pool is detached or when MTU is changed, this leads to growing tail always failing for multi-buffer packets. Couple XDP RxQ info registering with buffer allocations and unregistering with cleaning the ring. Fixes: a045d2f2d03d ("i40e: set xdp_rxq_info::frag_size") Reviewed-by: Aleksandr Loktionov Signed-off-by: Larysa Zaremba Link: https://patch.msgid.link/20260305111253.2317394-6-larysa.zaremba@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ff7f356cdbb474ef303f0239c7bb723ccd2f5271 Author: Larysa Zaremba Date: Thu Mar 5 12:12:43 2026 +0100 xsk: introduce helper to determine rxq->frag_size [ Upstream commit 16394d80539937d348dd3b9ea32415c54e67a81b ] rxq->frag_size is basically a step between consecutive strictly aligned frames. In ZC mode, chunk size fits exactly, but if chunks are unaligned, there is no safe way to determine accessible space to grow tailroom. Report frag_size to be zero, if chunks are unaligned, chunk_size otherwise. Fixes: 24ea50127ecf ("xsk: support mbuf on ZC RX") Reviewed-by: Aleksandr Loktionov Signed-off-by: Larysa Zaremba Link: https://patch.msgid.link/20260305111253.2317394-3-larysa.zaremba@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2a9e6ecf0e85840b1e7db73d0279af81ed446dc7 Author: Larysa Zaremba Date: Thu Mar 5 12:12:42 2026 +0100 xdp: use modulo operation to calculate XDP frag tailroom [ Upstream commit 88b6b7f7b216108a09887b074395fa7b751880b1 ] The current formula for calculating XDP tailroom in mbuf packets works only if each frag has its own page (if rxq->frag_size is PAGE_SIZE), this defeats the purpose of the parameter overall and without any indication leads to negative calculated tailroom on at least half of frags, if shared pages are used. There are not many drivers that set rxq->frag_size. Among them: * i40e and enetc always split page uniformly between frags, use shared pages * ice uses page_pool frags via libeth, those are power-of-2 and uniformly distributed across page * idpf has variable frag_size with XDP on, so current API is not applicable * mlx5, mtk and mvneta use PAGE_SIZE or 0 as frag_size for page_pool As for AF_XDP ZC, only ice, i40e and idpf declare frag_size for it. Modulo operation yields good results for aligned chunks, they are all power-of-2, between 2K and PAGE_SIZE. Formula without modulo fails when chunk_size is 2K. Buffers in unaligned mode are not distributed uniformly, so modulo operation would not work. To accommodate unaligned buffers, we could define frag_size as data + tailroom, and hence do not subtract offset when calculating tailroom, but this would necessitate more changes in the drivers. Define rxq->frag_size as an even portion of a page that fully belongs to a single frag. When calculating tailroom, locate the data start within such portion by performing a modulo operation on page offset. Fixes: bf25146a5595 ("bpf: add frags support to the bpf_xdp_adjust_tail() API") Acked-by: Jakub Kicinski Reviewed-by: Aleksandr Loktionov Signed-off-by: Larysa Zaremba Link: https://patch.msgid.link/20260305111253.2317394-2-larysa.zaremba@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cd888c3966672239f2e0707b846a5a936ac9038a Author: Jamal Hadi Salim Date: Wed Mar 4 09:06:02 2026 -0500 net/sched: act_ife: Fix metalist update behavior [ Upstream commit e2cedd400c3ec0302ffca2490e8751772906ac23 ] Whenever an ife action replace changes the metalist, instead of replacing the old data on the metalist, the current ife code is appending the new metadata. Aside from being innapropriate behavior, this may lead to an unbounded addition of metadata to the metalist which might cause an out of bounds error when running the encode op: [ 138.423369][ C1] ================================================================== [ 138.424317][ C1] BUG: KASAN: slab-out-of-bounds in ife_tlv_meta_encode (net/ife/ife.c:168) [ 138.424906][ C1] Write of size 4 at addr ffff8880077f4ffe by task ife_out_out_bou/255 [ 138.425778][ C1] CPU: 1 UID: 0 PID: 255 Comm: ife_out_out_bou Not tainted 7.0.0-rc1-00169-gfbdfa8da05b6 #624 PREEMPT(full) [ 138.425795][ C1] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 138.425800][ C1] Call Trace: [ 138.425804][ C1] [ 138.425808][ C1] dump_stack_lvl (lib/dump_stack.c:122) [ 138.425828][ C1] print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) [ 138.425839][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 138.425844][ C1] ? __virt_addr_valid (./arch/x86/include/asm/preempt.h:95 (discriminator 1) ./include/linux/rcupdate.h:975 (discriminator 1) ./include/linux/mmzone.h:2207 (discriminator 1) arch/x86/mm/physaddr.c:54 (discriminator 1)) [ 138.425853][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:168) [ 138.425859][ C1] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:597) [ 138.425868][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:168) [ 138.425878][ C1] kasan_check_range (mm/kasan/generic.c:186 (discriminator 1) mm/kasan/generic.c:200 (discriminator 1)) [ 138.425884][ C1] __asan_memset (mm/kasan/shadow.c:84 (discriminator 2)) [ 138.425889][ C1] ife_tlv_meta_encode (net/ife/ife.c:168) [ 138.425893][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:171) [ 138.425898][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 138.425903][ C1] ife_encode_meta_u16 (net/sched/act_ife.c:57) [ 138.425910][ C1] ? __pfx_do_raw_spin_lock (kernel/locking/spinlock_debug.c:114) [ 138.425916][ C1] ? __asan_memcpy (mm/kasan/shadow.c:105 (discriminator 3)) [ 138.425921][ C1] ? __pfx_ife_encode_meta_u16 (net/sched/act_ife.c:45) [ 138.425927][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 138.425931][ C1] tcf_ife_act (net/sched/act_ife.c:847 net/sched/act_ife.c:879) To solve this issue, fix the replace behavior by adding the metalist to the ife rcu data structure. Fixes: aa9fd9a325d51 ("sched: act: ife: update parameters via rcu handling") Reported-by: Ruitong Liu Tested-by: Ruitong Liu Co-developed-by: Victor Nogueira Signed-off-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260304140603.76500-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b3b5a037d520afe3d5276e653bc0ff516bbda34c Author: Jiayuan Chen Date: Wed Mar 4 19:38:13 2026 +0800 net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop [ Upstream commit 21ec92774d1536f71bdc90b0e3d052eff99cf093 ] When a standalone IPv6 nexthop object is created with a loopback device (e.g., "ip -6 nexthop add id 100 dev lo"), fib6_nh_init() misclassifies it as a reject route. This is because nexthop objects have no destination prefix (fc_dst=::), causing fib6_is_reject() to match any loopback nexthop. The reject path skips fib_nh_common_init(), leaving nhc_pcpu_rth_output unallocated. If an IPv4 route later references this nexthop, __mkroute_output() dereferences NULL nhc_pcpu_rth_output and panics. Simplify the check in fib6_nh_init() to only match explicit reject routes (RTF_REJECT) instead of using fib6_is_reject(). The loopback promotion heuristic in fib6_is_reject() is handled separately by ip6_route_info_create_nh(). After this change, the three cases behave as follows: 1. Explicit reject route ("ip -6 route add unreachable 2001:db8::/64"): RTF_REJECT is set, enters reject path, skips fib_nh_common_init(). No behavior change. 2. Implicit loopback reject route ("ip -6 route add 2001:db8::/32 dev lo"): RTF_REJECT is not set, takes normal path, fib_nh_common_init() is called. ip6_route_info_create_nh() still promotes it to reject afterward. nhc_pcpu_rth_output is allocated but unused, which is harmless. 3. Standalone nexthop object ("ip -6 nexthop add id 100 dev lo"): RTF_REJECT is not set, takes normal path, fib_nh_common_init() is called. nhc_pcpu_rth_output is properly allocated, fixing the crash when IPv4 routes reference this nexthop. Suggested-by: Ido Schimmel Fixes: 493ced1ac47c ("ipv4: Allow routes to use nexthop objects") Reported-by: syzbot+334190e097a98a1b81bb@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/698f8482.a70a0220.2c38d7.00ca.GAE@google.com/T/ Signed-off-by: Jiayuan Chen Reviewed-by: Ido Schimmel Reviewed-by: David Ahern Link: https://patch.msgid.link/20260304113817.294966-2-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fbbd2118982c55fb9b0a753ae0cf7194e77149fb Author: Fernando Fernandez Mancera Date: Wed Mar 4 13:03:57 2026 +0100 net: vxlan: fix nd_tbl NULL dereference when IPv6 is disabled [ Upstream commit 168ff39e4758897d2eee4756977d036d52884c7e ] When booting with the 'ipv6.disable=1' parameter, the nd_tbl is never initialized because inet6_init() exits before ndisc_init() is called which initializes it. If an IPv6 packet is injected into the interface, route_shortcircuit() is called and a NULL pointer dereference happens on neigh_lookup(). BUG: kernel NULL pointer dereference, address: 0000000000000380 Oops: Oops: 0000 [#1] SMP NOPTI [...] RIP: 0010:neigh_lookup+0x20/0x270 [...] Call Trace: vxlan_xmit+0x638/0x1ef0 [vxlan] dev_hard_start_xmit+0x9e/0x2e0 __dev_queue_xmit+0xbee/0x14e0 packet_sendmsg+0x116f/0x1930 __sys_sendto+0x1f5/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x12f/0x1590 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fix this by adding an early check on route_shortcircuit() when protocol is ETH_P_IPV6. Note that ipv6_mod_enabled() cannot be used here because VXLAN can be built-in even when IPv6 is built as a module. Fixes: e15a00aafa4b ("vxlan: add ipv6 route short circuit support") Signed-off-by: Fernando Fernandez Mancera Link: https://patch.msgid.link/20260304120357.9778-2-fmancera@suse.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 33dec6f10777d5a8f71c0a200f690da5ae3c2e55 Author: Fernando Fernandez Mancera Date: Wed Mar 4 13:03:56 2026 +0100 net: bridge: fix nd_tbl NULL dereference when IPv6 is disabled [ Upstream commit e5e890630533bdc15b26a34bb8e7ef539bdf1322 ] When booting with the 'ipv6.disable=1' parameter, the nd_tbl is never initialized because inet6_init() exits before ndisc_init() is called which initializes it. Then, if neigh_suppress is enabled and an ICMPv6 Neighbor Discovery packet reaches the bridge, br_do_suppress_nd() will dereference ipv6_stub->nd_tbl which is NULL, passing it to neigh_lookup(). This causes a kernel NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000268 Oops: 0000 [#1] PREEMPT SMP NOPTI [...] RIP: 0010:neigh_lookup+0x16/0xe0 [...] Call Trace: ? neigh_lookup+0x16/0xe0 br_do_suppress_nd+0x160/0x290 [bridge] br_handle_frame_finish+0x500/0x620 [bridge] br_handle_frame+0x353/0x440 [bridge] __netif_receive_skb_core.constprop.0+0x298/0x1110 __netif_receive_skb_one_core+0x3d/0xa0 process_backlog+0xa0/0x140 __napi_poll+0x2c/0x170 net_rx_action+0x2c4/0x3a0 handle_softirqs+0xd0/0x270 do_softirq+0x3f/0x60 Fix this by replacing IS_ENABLED(IPV6) call with ipv6_mod_enabled() in the callers. This is in essence disabling NS/NA suppression when IPv6 is disabled. Fixes: ed842faeb2bd ("bridge: suppress nd pkts on BR_NEIGH_SUPPRESS ports") Reported-by: Guruprasad C P Closes: https://lore.kernel.org/netdev/CAHXs0ORzd62QOG-Fttqa2Cx_A_VFp=utE2H2VTX5nqfgs7LDxQ@mail.gmail.com/ Signed-off-by: Fernando Fernandez Mancera Reviewed-by: Ido Schimmel Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260304120357.9778-1-fmancera@suse.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d3b1c4c70da560148ce22789214d03561b544a9d Author: Sun Jian Date: Wed Feb 25 19:14:50 2026 +0800 selftests/harness: order TEST_F and XFAIL_ADD constructors [ Upstream commit 6be2681514261324c8ee8a1c6f76cefdf700220f ] TEST_F() allocates and registers its struct __test_metadata via mmap() inside its constructor, and only then assigns the _##fixture_##test##_object pointer. XFAIL_ADD() runs in a constructor too and reads _##fixture_##test##_object to initialize xfail->test. If XFAIL_ADD runs first, xfail->test can be NULL and the expected failure will be reported as FAIL. Use constructor priorities to ensure TEST_F registration runs before XFAIL_ADD, without adding extra state or runtime lookups. Fixes: 2709473c9386 ("selftests: kselftest_harness: support using xfail") Signed-off-by: Sun Jian Link: https://patch.msgid.link/20260225111451.347923-1-sun.jian.kdev@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0168443a5db5bcd434783e7d2b182c77af10201b Author: Wake Liu Date: Wed Dec 24 16:41:20 2025 +0800 kselftest/harness: Use helper to avoid zero-size memset warning [ Upstream commit 19b8a76cd99bde6d299e60490f3e62b8d3df3997 ] When building kselftests with a toolchain that enables source fortification (e.g., Android's build environment, which uses -D_FORTIFY_SOURCE=3), a build failure occurs in tests that use an empty FIXTURE(). The root cause is that an empty fixture struct results in `sizeof(self_private)` evaluating to 0. The compiler's fortification checks then detect the `memset()` call with a compile-time constant size of 0, issuing a `-Wuser-defined-warnings` which is promoted to an error by `-Werror`. An initial attempt to guard the call with `if (sizeof(self_private) > 0)` was insufficient. The compiler's static analysis is aggressive enough to flag the `memset(..., 0)` pattern before evaluating the conditional, thus still triggering the error. To resolve this robustly, this change introduces a `static inline` helper function, `__kselftest_memset_safe()`. This function wraps the size check and the `memset()` call. By replacing the direct `memset()` in the `__TEST_F_IMPL` macro with a call to this helper, we create an abstraction boundary. This prevents the compiler's static analyzer from "seeing" the problematic pattern at the macro expansion site, resolving the build failure. Build Context: Compiler: Android (14488419, +pgo, +bolt, +lto, +mlgo, based on r584948) clang version 22.0.0 (https://android.googlesource.com/toolchain/llvm-project 2d65e4108033380e6fe8e08b1f1826cd2bfb0c99) Relevant Options: -O2 -Wall -Werror -D_FORTIFY_SOURCE=3 -target i686-linux-android10000 Test: m kselftest_futex_futex_requeue_pi Removed Gerrit Change-Id Shuah Khan Link: https://lore.kernel.org/r/20251224084120.249417-1-wakel@google.com Signed-off-by: Wake Liu Signed-off-by: Shuah Khan Stable-dep-of: 6be268151426 ("selftests/harness: order TEST_F and XFAIL_ADD constructors") Signed-off-by: Sasha Levin commit 6f95b59520278a72df9905db791b7ea31375fbc1 Author: Lorenzo Bianconi Date: Tue Mar 3 18:56:39 2026 +0100 net: ethernet: mtk_eth_soc: Reset prog ptr to old_prog in case of error in mtk_xdp_setup() [ Upstream commit 0abc73c8a40fd64ac1739c90bb4f42c418d27a5e ] Reset eBPF program pointer to old_prog and do not decrease its ref-count if mtk_open routine in mtk_xdp_setup() fails. Fixes: 7c26c20da5d42 ("net: ethernet: mtk_eth_soc: add basic XDP support") Suggested-by: Paolo Valerio Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260303-mtk-xdp-prog-ptr-fix-v2-1-97b6dbbe240f@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 500a50a301ce962b019ab95053ac70264fec2c21 Author: Florian Westphal Date: Tue Mar 3 16:31:32 2026 +0100 netfilter: nft_set_pipapo: split gc into unlink and reclaim phase [ Upstream commit 9df95785d3d8302f7c066050117b04cd3c2048c2 ] Yiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service). We must split GC in an unlink and a reclaim phase. We cannot queue elements for freeing until pointers have been swapped. Expired elements are still exposed to both the packet path and userspace dumpers via the live copy of the data structure. call_rcu() does not protect us: dump operations or element lookups starting after call_rcu has fired can still observe the free'd element, unless the commit phase has made enough progress to swap the clone and live pointers before any new reader has picked up the old version. This a similar approach as done recently for the rbtree backend in commit 35f83a75529a ("netfilter: nft_set_rbtree: don't gc elements on insert"). Fixes: 3c4287f62044 ("nf_tables: Add set type for arbitrary concatenation of ranges") Reported-by: Yiming Qian Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 9154945a6394029822bd08c24cef5a3f86d0424a Author: Pablo Neira Ayuso Date: Mon Mar 2 23:28:15 2026 +0100 netfilter: nf_tables: clone set on flush only [ Upstream commit fb7fb4016300ac622c964069e286dc83166a5d52 ] Syzbot with fault injection triggered a failing memory allocation with GFP_KERNEL which results in a WARN splat: iter.err WARNING: net/netfilter/nf_tables_api.c:845 at nft_map_deactivate+0x34e/0x3c0 net/netfilter/nf_tables_api.c:845, CPU#0: syz.0.17/5992 Modules linked in: CPU: 0 UID: 0 PID: 5992 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026 RIP: 0010:nft_map_deactivate+0x34e/0x3c0 net/netfilter/nf_tables_api.c:845 Code: 8b 05 86 5a 4e 09 48 3b 84 24 a0 00 00 00 75 62 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc e8 63 6d fa f7 90 <0f> 0b 90 43 +80 7c 35 00 00 0f 85 23 fe ff ff e9 26 fe ff ff 89 d9 RSP: 0018:ffffc900045af780 EFLAGS: 00010293 RAX: ffffffff89ca45bd RBX: 00000000fffffff4 RCX: ffff888028111e40 RDX: 0000000000000000 RSI: 00000000fffffff4 RDI: 0000000000000000 RBP: ffffc900045af870 R08: 0000000000400dc0 R09: 00000000ffffffff R10: dffffc0000000000 R11: fffffbfff1d141db R12: ffffc900045af7e0 R13: 1ffff920008b5f24 R14: dffffc0000000000 R15: ffffc900045af920 FS: 000055557a6a5500(0000) GS:ffff888125496000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb5ea271fc0 CR3: 000000003269e000 CR4: 00000000003526f0 Call Trace: __nft_release_table+0xceb/0x11f0 net/netfilter/nf_tables_api.c:12115 nft_rcv_nl_event+0xc25/0xdb0 net/netfilter/nf_tables_api.c:12187 notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85 blocking_notifier_call_chain+0x6a/0x90 kernel/notifier.c:380 netlink_release+0x123b/0x1ad0 net/netlink/af_netlink.c:761 __sock_release net/socket.c:662 [inline] sock_close+0xc3/0x240 net/socket.c:1455 Restrict set clone to the flush set command in the preparation phase. Add NFT_ITER_UPDATE_CLONE and use it for this purpose, update the rbtree and pipapo backends to only clone the set when this iteration type is used. As for the existing NFT_ITER_UPDATE type, update the pipapo backend to use the existing set clone if available, otherwise use the existing set representation. After this update, there is no need to clone a set that is being deleted, this includes bound anonymous set. An alternative approach to NFT_ITER_UPDATE_CLONE is to add a .clone interface and call it from the flush set path. Reported-by: syzbot+4924a0edc148e8b4b342@syzkaller.appspotmail.com Fixes: 3f1d886cc7c3 ("netfilter: nft_set_pipapo: move cloning of match info to insert/removal path") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 6826131c7674329335ca25df2550163eb8a1fd0c Author: Pablo Neira Ayuso Date: Mon Mar 2 23:12:37 2026 +0100 netfilter: nf_tables: unconditionally bump set->nelems before insertion [ Upstream commit def602e498a4f951da95c95b1b8ce8ae68aa733a ] In case that the set is full, a new element gets published then removed without waiting for the RCU grace period, while RCU reader can be walking over it already. To address this issue, add the element transaction even if set is full, but toggle the set_full flag to report -ENFILE so the abort path safely unwinds the set to its previous state. As for element updates, decrement set->nelems to restore it. A simpler fix is to call synchronize_rcu() in the error path. However, with a large batch adding elements to already maxed-out set, this could cause noticeable slowdown of such batches. Fixes: 35d0ac9070ef ("netfilter: nf_tables: fix set->nelems counting with no NLM_F_EXCL") Reported-by: Inseo An Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 6624d1727f3a52de96bc9817c1fa0bbe57d9326e Author: Sebastian Andrzej Siewior Date: Mon Mar 2 17:26:31 2026 +0100 net: Provide a PREEMPT_RT specific check for netdev_queue::_xmit_lock [ Upstream commit b824c3e16c1904bf80df489e293d1e3cbf98896d ] After acquiring netdev_queue::_xmit_lock the number of the CPU owning the lock is recorded in netdev_queue::xmit_lock_owner. This works as long as the BH context is not preemptible. On PREEMPT_RT the softirq context is preemptible and without the softirq-lock it is possible to have multiple user in __dev_queue_xmit() submitting a skb on the same CPU. This is fine in general but this means also that the current CPU is recorded as netdev_queue::xmit_lock_owner. This in turn leads to the recursion alert and the skb is dropped. Instead checking the for CPU number, that owns the lock, PREEMPT_RT can check if the lockowner matches the current task. Add netif_tx_owned() which returns true if the current context owns the lock by comparing the provided CPU number with the recorded number. This resembles the current check by negating the condition (the current check returns true if the lock is not owned). On PREEMPT_RT use rt_mutex_owner() to return the lock owner and compare the current task against it. Use the new helper in __dev_queue_xmit() and netif_local_xmit_active() which provides a similar check. Update comments regarding pairing READ_ONCE(). Reported-by: Bert Karwatzki Closes: https://lore.kernel.org/all/20260216134333.412332-1-spasswolf@web.de Fixes: 3253cb49cbad4 ("softirq: Allow to drop the softirq-BKL lock on PREEMPT_RT") Signed-off-by: Sebastian Andrzej Siewior Reported-by: Bert Karwatzki Signed-off-by: Sebastian Andrzej Siewior Link: https://patch.msgid.link/20260302162631.uGUyIqDT@linutronix.de Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c3e8c75fcb2ef63c99727eadddd2bb577c386506 Author: Ming Lei Date: Thu Mar 5 11:15:50 2026 +0800 block: use trylock to avoid lockdep circular dependency in sysfs [ Upstream commit ce8ee8583ed83122405eabaa8fb351be4d9dc65c ] Use trylock instead of blocking lock acquisition for update_nr_hwq_lock in queue_requests_store() and elv_iosched_store() to avoid circular lock dependency with kernfs active reference during concurrent disk deletion: update_nr_hwq_lock -> kn->active (via del_gendisk -> kobject_del) kn->active -> update_nr_hwq_lock (via sysfs write path) Return -EBUSY when the lock is not immediately available. Reported-and-tested-by: Yi Zhang Closes: https://lore.kernel.org/linux-block/CAHj4cs-em-4acsHabMdT=jJhXkCzjnprD-aQH1OgrZo4nTnmMw@mail.gmail.com/ Fixes: 626ff4f8ebcb ("blk-mq: convert to serialize updating nr_requests with update_nr_hwq_lock") Signed-off-by: Ming Lei Tested-by: Yi Zhang Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 6b0e35123ba459d3f8688b18eba824e73071a3fd Author: Ovidiu Panait Date: Tue Mar 3 14:58:28 2026 +0000 net: stmmac: Defer VLAN HW configuration when interface is down [ Upstream commit 2cd70e3968f505996d5fefdf7ca684f0f4575734 ] VLAN register accesses on the MAC side require the PHY RX clock to be active. When the network interface is down, the PHY is suspended and the RX clock is unavailable, causing VLAN operations to fail with timeouts. The VLAN core automatically removes VID 0 after the interface goes down and re-adds it when it comes back up, so these timeouts happen during normal interface down/up: # ip link set end1 down renesas-gbeth 15c40000.ethernet end1: Timeout accessing MAC_VLAN_Tag_Filter renesas-gbeth 15c40000.ethernet end1: failed to kill vid 0081/0 Adding VLANs while the interface is down also fails: # ip link add link end1 name end1.10 type vlan id 10 renesas-gbeth 15c40000.ethernet end1: Timeout accessing MAC_VLAN_Tag_Filter RTNETLINK answers: Device or resource busy To fix this, check if the interface is up before accessing VLAN registers. The software state is always kept up to date regardless of interface state. When the interface is brought up, stmmac_vlan_restore() is called to write the VLAN state to hardware. Fixes: ed64639bc1e0 ("net: stmmac: Add support for VLAN Rx filtering") Signed-off-by: Ovidiu Panait Link: https://patch.msgid.link/20260303145828.7845-5-ovidiu.panait.rb@renesas.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 15e8ef336895519ac38eb1e2774ad56240391930 Author: Ovidiu Panait Date: Tue Mar 3 14:58:27 2026 +0000 net: stmmac: Fix VLAN HW state restore [ Upstream commit bd7ad51253a76fb35886d01cfe9a37f0e4ed6709 ] When the network interface is opened or resumed, a DMA reset is performed, which resets all hardware state, including VLAN state. Currently, only the resume path is restoring the VLAN state via stmmac_restore_hw_vlan_rx_fltr(), but that is incomplete: the VLAN hash table and the VLAN_TAG control bits are not restored. Therefore, add stmmac_vlan_restore(), which restores the full VLAN state by updating both the HW filter entries and the hash table, and call it from both the open and resume paths. The VLAN restore is moved outside of phylink_rx_clk_stop_block/unblock in the resume path because receive clock stop is already disabled when stmmac supports VLAN. Also, remove the hash readback code in vlan_restore_hw_rx_fltr() that attempts to restore VTHM by reading VLAN_HASH_TABLE, as it always reads zero after DMA reset, making it dead code. Fixes: 3cd1cfcba26e ("net: stmmac: Implement VLAN Hash Filtering in XGMAC") Fixes: ed64639bc1e0 ("net: stmmac: Add support for VLAN Rx filtering") Signed-off-by: Ovidiu Panait Link: https://patch.msgid.link/20260303145828.7845-4-ovidiu.panait.rb@renesas.com Signed-off-by: Jakub Kicinski Stable-dep-of: 2cd70e3968f5 ("net: stmmac: Defer VLAN HW configuration when interface is down") Signed-off-by: Sasha Levin commit 8b8b97eaecae7f075493a7bc79fc97c313ee7596 Author: Ovidiu Panait Date: Tue Mar 3 14:58:26 2026 +0000 net: stmmac: Improve double VLAN handling [ Upstream commit e38200e361cbe331806dc454c76c11c7cd95e1b9 ] The double VLAN bits (EDVLP, ESVL, DOVLTC) are handled inconsistently between the two vlan_update_hash() implementations: - dwxgmac2_update_vlan_hash() explicitly clears the double VLAN bits when is_double is false, meaning that adding a 802.1Q VLAN will disable double VLAN mode: $ ip link add link eth0 name eth0.200 type vlan id 200 protocol 802.1ad $ ip link add link eth0 name eth0.100 type vlan id 100 # Double VLAN bits no longer set - vlan_update_hash() sets these bits and only clears them when the last VLAN has been removed, so double VLAN mode remains enabled even after all 802.1AD VLANs are removed. Address both issues by tracking the number of active 802.1AD VLANs in priv->num_double_vlans. Pass this count to stmmac_vlan_update() so both implementations correctly set the double VLAN bits when any 802.1AD VLAN is active, and clear them only when none remain. Also update vlan_update_hash() to explicitly clear the double VLAN bits when is_double is false, matching the dwxgmac2 behavior. Signed-off-by: Ovidiu Panait Link: https://patch.msgid.link/20260303145828.7845-3-ovidiu.panait.rb@renesas.com Signed-off-by: Jakub Kicinski Stable-dep-of: 2cd70e3968f5 ("net: stmmac: Defer VLAN HW configuration when interface is down") Signed-off-by: Sasha Levin commit d55a39435c20ba070e25b71b706208db768bad64 Author: Ovidiu Panait Date: Tue Mar 3 14:58:25 2026 +0000 net: stmmac: Fix error handling in VLAN add and delete paths [ Upstream commit 35dfedce442c4060cfe5b98368bc9643fb995716 ] stmmac_vlan_rx_add_vid() updates active_vlans and the VLAN hash register before writing the HW filter entry. If the filter write fails, it leaves a stale VID in active_vlans and the hash register. stmmac_vlan_rx_kill_vid() has the reverse problem: it clears active_vlans before removing the HW filter. On failure, the VID is gone from active_vlans but still present in the HW filter table. To fix this, reorder the operations to update the hash table first, then attempt the HW filter operation. If the HW filter fails, roll back both the active_vlans bitmap and the hash table by calling stmmac_vlan_update() again. Fixes: ed64639bc1e0 ("net: stmmac: Add support for VLAN Rx filtering") Signed-off-by: Ovidiu Panait Link: https://patch.msgid.link/20260303145828.7845-2-ovidiu.panait.rb@renesas.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit edc988613def90c5b558e025b1b423f48007be06 Author: Jakub Kicinski Date: Tue Mar 3 08:23:45 2026 -0800 nfc: rawsock: cancel tx_work before socket teardown [ Upstream commit d793458c45df2aed498d7f74145eab7ee22d25aa ] In rawsock_release(), cancel any pending tx_work and purge the write queue before orphaning the socket. rawsock_tx_work runs on the system workqueue and calls nfc_data_exchange which dereferences the NCI device. Without synchronization, tx_work can race with socket and device teardown when a process is killed (e.g. by SIGKILL), leading to use-after-free or leaked references. Set SEND_SHUTDOWN first so that if tx_work is already running it will see the flag and skip transmitting, then use cancel_work_sync to wait for any in-progress execution to finish, and finally purge any remaining queued skbs. Fixes: 23b7869c0fd0 ("NFC: add the NFC socket raw protocol") Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260303162346.2071888-6-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b3fdbc7f59cdfe7094bb1ca7e92957e4ced6b08e Author: Jakub Kicinski Date: Tue Mar 3 08:23:44 2026 -0800 nfc: nci: clear NCI_DATA_EXCHANGE before calling completion callback [ Upstream commit 0efdc02f4f6d52f8ca5d5889560f325a836ce0a8 ] Move clear_bit(NCI_DATA_EXCHANGE) before invoking the data exchange callback in nci_data_exchange_complete(). The callback (e.g. rawsock_data_exchange_complete) may immediately schedule another data exchange via schedule_work(tx_work). On a multi-CPU system, tx_work can run and reach nci_transceive() before the current nci_data_exchange_complete() clears the flag, causing test_and_set_bit(NCI_DATA_EXCHANGE) to return -EBUSY and the new transfer to fail. This causes intermittent flakes in nci/nci_dev in NIPA: # # RUN NCI.NCI1_0.t4t_tag_read ... # # t4t_tag_read: Test terminated by timeout # # FAIL NCI.NCI1_0.t4t_tag_read # not ok 3 NCI.NCI1_0.t4t_tag_read Fixes: 38f04c6b1b68 ("NFC: protect nci_data_exchange transactions") Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260303162346.2071888-5-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 91ff0d8c3464da7f0c43da38c195e60b660128bf Author: Jakub Kicinski Date: Tue Mar 3 08:23:43 2026 -0800 nfc: nci: complete pending data exchange on device close [ Upstream commit 66083581945bd5b8e99fe49b5aeb83d03f62d053 ] In nci_close_device(), complete any pending data exchange before closing. The data exchange callback (e.g. rawsock_data_exchange_complete) holds a socket reference. NIPA occasionally hits this leak: unreferenced object 0xff1100000f435000 (size 2048): comm "nci_dev", pid 3954, jiffies 4295441245 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 27 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 '..@............ backtrace (crc ec2b3c5): __kmalloc_noprof+0x4db/0x730 sk_prot_alloc.isra.0+0xe4/0x1d0 sk_alloc+0x36/0x760 rawsock_create+0xd1/0x540 nfc_sock_create+0x11f/0x280 __sock_create+0x22d/0x630 __sys_socket+0x115/0x1d0 __x64_sys_socket+0x72/0xd0 do_syscall_64+0x117/0xfc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Fixes: 38f04c6b1b68 ("NFC: protect nci_data_exchange transactions") Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260303162346.2071888-4-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9d448bbab724b94d6c561e1f314656f5b88a7cb3 Author: Jakub Kicinski Date: Tue Mar 3 08:23:41 2026 -0800 nfc: nci: free skb on nci_transceive early error paths [ Upstream commit 7bd4b0c4779f978a6528c9b7937d2ca18e936e2c ] nci_transceive() takes ownership of the skb passed by the caller, but the -EPROTO, -EINVAL, and -EBUSY error paths return without freeing it. Due to issues clearing NCI_DATA_EXCHANGE fixed by subsequent changes the nci/nci_dev selftest hits the error path occasionally in NIPA, and kmemleak detects leaks: unreferenced object 0xff11000015ce6a40 (size 640): comm "nci_dev", pid 3954, jiffies 4295441246 hex dump (first 32 bytes): 6b 6b 6b 6b 00 a4 00 0c 02 e1 03 6b 6b 6b 6b 6b kkkk.......kkkkk 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk backtrace (crc 7c40cc2a): kmem_cache_alloc_node_noprof+0x492/0x630 __alloc_skb+0x11e/0x5f0 alloc_skb_with_frags+0xc6/0x8f0 sock_alloc_send_pskb+0x326/0x3f0 nfc_alloc_send_skb+0x94/0x1d0 rawsock_sendmsg+0x162/0x4c0 do_syscall_64+0x117/0xfc0 Fixes: 6a2968aaf50c ("NFC: basic NCI protocol implementation") Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260303162346.2071888-2-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a77a5423e9c632d8c9eaa480ebf5367ecb16f646 Author: Bobby Eshleman Date: Mon Mar 2 16:32:56 2026 -0800 net: devmem: use READ_ONCE/WRITE_ONCE on binding->dev [ Upstream commit 40bf00ec2ee271df5ba67593991760adf8b5d0ed ] binding->dev is protected on the write-side in mp_dmabuf_devmem_uninstall() against concurrent writes, but due to the concurrent bare reads in net_devmem_get_binding() and validate_xmit_unreadable_skb() it should be wrapped in a READ_ONCE/WRITE_ONCE pair to make sure no compiler optimizations play with the underlying register in unforeseen ways. Doesn't present a critical bug because the known compiler optimizations don't result in bad behavior. There is no tearing on u64, and load omissions/invented loads would only break if additional binding->dev references were inlined together (they aren't right now). This just more strictly follows the linux memory model (i.e., "Lock-Protected Writes With Lockless Reads" in tools/memory-model/Documentation/access-marking.txt). Fixes: bd61848900bf ("net: devmem: Implement TX path") Signed-off-by: Bobby Eshleman Link: https://patch.msgid.link/20260302-devmem-membar-fix-v2-1-5b33c9cbc28b@meta.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4596f44d4f5b93710508da5c736c2f27835bfab1 Author: Eric Dumazet Date: Wed Mar 4 01:56:40 2026 +0000 net_sched: sch_fq: clear q->band_pkt_count[] in fq_reset() [ Upstream commit a4c2b8be2e5329e7fac6e8f64ddcb8958155cfcb ] When/if a NIC resets, queues are deactivated by dev_deactivate_many(), then reactivated when the reset operation completes. fq_reset() removes all the skbs from various queues. If we do not clear q->band_pkt_count[], these counters keep growing and can eventually reach sch->limit, preventing new packets to be queued. Many thanks to Praveen for discovering the root cause. Fixes: 29f834aa326e ("net_sched: sch_fq: add 3 bands and WRR scheduling") Diagnosed-by: Praveen Kaligineedi Signed-off-by: Eric Dumazet Reviewed-by: Neal Cardwell Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260304015640.961780-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1c46edf20f82ed1b9b41620ca6fb5fc80fb8c7dc Author: Ian Ray Date: Mon Mar 2 18:32:37 2026 +0200 net: nfc: nci: Fix zero-length proprietary notifications [ Upstream commit f7d92f11bd33a6eb49c7c812255ef4ab13681f0f ] NCI NFC controllers may have proprietary OIDs with zero-length payload. One example is: drivers/nfc/nxp-nci/core.c, NXP_NCI_RF_TXLDO_ERROR_NTF. Allow a zero length payload in proprietary notifications *only*. Before: -- >8 -- kernel: nci: nci_recv_frame: len 3 -- >8 -- After: -- >8 -- kernel: nci: nci_recv_frame: len 3 kernel: nci: nci_ntf_packet: NCI RX: MT=ntf, PBF=0, GID=0x1, OID=0x23, plen=0 kernel: nci: nci_ntf_packet: unknown ntf opcode 0x123 kernel: nfc nfc0: NFC: RF transmitter couldn't start. Bad power and/or configuration? -- >8 -- After fixing the hardware: -- >8 -- kernel: nci: nci_recv_frame: len 27 kernel: nci: nci_ntf_packet: NCI RX: MT=ntf, PBF=0, GID=0x1, OID=0x5, plen=24 kernel: nci: nci_rf_intf_activated_ntf_packet: rf_discovery_id 1 -- >8 -- Fixes: d24b03535e5e ("nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet") Signed-off-by: Ian Ray Link: https://patch.msgid.link/20260302163238.140576-1-ian.ray@gehealthcare.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit eae2f14ab2efccdb7480fae7d42c4b0116ef8805 Author: Eric Dumazet Date: Mon Mar 2 20:55:27 2026 +0000 tcp: secure_seq: add back ports to TS offset [ Upstream commit 165573e41f2f66ef98940cf65f838b2cb575d9d1 ] This reverts 28ee1b746f49 ("secure_seq: downgrade to per-host timestamp offsets") tcp_tw_recycle went away in 2017. Zhouyan Deng reported off-path TCP source port leakage via SYN cookie side-channel that can be fixed in multiple ways. One of them is to bring back TCP ports in TS offset randomization. As a bonus, we perform a single siphash() computation to provide both an ISN and a TS offset. Fixes: 28ee1b746f49 ("secure_seq: downgrade to per-host timestamp offsets") Reported-by: Zhouyan Deng Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Acked-by: Florian Westphal Link: https://patch.msgid.link/20260302205527.1982836-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8314944cc3bdeaa5a73e6f8a8cf0d94822e625cb Author: Koichiro Den Date: Sat Feb 28 23:53:07 2026 +0900 net: sched: avoid qdisc_reset_all_tx_gt() vs dequeue race for lockless qdiscs [ Upstream commit 7f083faf59d14c04e01ec05a7507f036c965acf8 ] When shrinking the number of real tx queues, netif_set_real_num_tx_queues() calls qdisc_reset_all_tx_gt() to flush qdiscs for queues which will no longer be used. qdisc_reset_all_tx_gt() currently serializes qdisc_reset() with qdisc_lock(). However, for lockless qdiscs, the dequeue path is serialized by qdisc_run_begin/end() using qdisc->seqlock instead, so qdisc_reset() can run concurrently with __qdisc_run() and free skbs while they are still being dequeued, leading to UAF. This can easily be reproduced on e.g. virtio-net by imposing heavy traffic while frequently changing the number of queue pairs: iperf3 -ub0 -c $peer -t 0 & while :; do ethtool -L eth0 combined 1 ethtool -L eth0 combined 2 done With KASAN enabled, this leads to reports like: BUG: KASAN: slab-use-after-free in __qdisc_run+0x133f/0x1760 ... Call Trace: ... __qdisc_run+0x133f/0x1760 __dev_queue_xmit+0x248f/0x3550 ip_finish_output2+0xa42/0x2110 ip_output+0x1a7/0x410 ip_send_skb+0x2e6/0x480 udp_send_skb+0xb0a/0x1590 udp_sendmsg+0x13c9/0x1fc0 ... Allocated by task 1270 on cpu 5 at 44.558414s: ... alloc_skb_with_frags+0x84/0x7c0 sock_alloc_send_pskb+0x69a/0x830 __ip_append_data+0x1b86/0x48c0 ip_make_skb+0x1e8/0x2b0 udp_sendmsg+0x13a6/0x1fc0 ... Freed by task 1306 on cpu 3 at 44.558445s: ... kmem_cache_free+0x117/0x5e0 pfifo_fast_reset+0x14d/0x580 qdisc_reset+0x9e/0x5f0 netif_set_real_num_tx_queues+0x303/0x840 virtnet_set_channels+0x1bf/0x260 [virtio_net] ethnl_set_channels+0x684/0xae0 ethnl_default_set_doit+0x31a/0x890 ... Serialize qdisc_reset_all_tx_gt() against the lockless dequeue path by taking qdisc->seqlock for TCQ_F_NOLOCK qdiscs, matching the serialization model already used by dev_reset_queue(). Additionally clear QDISC_STATE_NON_EMPTY after reset so the qdisc state reflects an empty queue, avoiding needless re-scheduling. Fixes: 6b3ba9146fe6 ("net: sched: allow qdiscs to handle locking") Signed-off-by: Koichiro Den Link: https://patch.msgid.link/20260228145307.3955532-1-den@valinux.co.jp Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d9d4ed40b3be3c0cd4856b994eb3106ecef4f38f Author: Olivier Sobrie Date: Wed Mar 4 22:20:39 2026 +0100 hwmon: (max6639) fix inverted polarity [ Upstream commit 170a4b21f49b3dcff3115b4c90758f0a0d77375a ] According to MAX6639 documentation: D1: PWM Output Polarity. PWM output is low at 100% duty cycle when this bit is set to zero. PWM output is high at 100% duty cycle when this bit is set to 1. Up to commit 0f33272b60ed ("hwmon: (max6639) : Update hwmon init using info structure"), the polarity was set to high (0x2) when no platform data was set. After the patch, the polarity register wasn't set anymore if no platform data was specified. Nowadays, since commit 7506ebcd662b ("hwmon: (max6639) : Configure based on DT property"), it is always set to low which doesn't match with the comment above and change the behavior compared to versions prior 0f33272b60ed. Fixes: 0f33272b60ed ("hwmon: (max6639) : Update hwmon init using info structure") Signed-off-by: Olivier Sobrie Link: https://lore.kernel.org/r/20260304212039.570274-1-olivier@sobrie.be Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit de4ea10ae6b42116f90f54db875b8b3e603896ca Author: Miroslav Lichvar Date: Wed Feb 25 09:51:35 2026 +0100 timekeeping: Fix timex status validation for auxiliary clocks [ Upstream commit e48a869957a70cc39b4090cd27c36a86f8db9b92 ] The timekeeping_validate_timex() function validates the timex status of an auxiliary system clock even when the status is not to be changed, which causes unexpected errors for applications that make read-only clock_adjtime() calls, or set some other timex fields, but without clearing the status field. Do the AUX-specific status validation only when the modes field contains ADJ_STATUS, i.e. the application is actually trying to change the status. This makes the AUX-specific clock_adjtime() behavior consistent with CLOCK_REALTIME. Fixes: 4eca49d0b621 ("timekeeping: Prepare do_adtimex() for auxiliary clocks") Signed-off-by: Miroslav Lichvar Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260225085231.276751-1-mlichvar@redhat.com Signed-off-by: Sasha Levin commit 5a501379a010690ae9ae88bef62a1bae1aca32e6 Author: Sungwoo Kim Date: Fri Feb 27 19:19:28 2026 -0500 nvme: fix memory allocation in nvme_pr_read_keys() [ Upstream commit c3320153769f05fd7fe9d840cb555dd3080ae424 ] nvme_pr_read_keys() takes num_keys from userspace and uses it to calculate the allocation size for rse via struct_size(). The upper limit is PR_KEYS_MAX (64K). A malicious or buggy userspace can pass a large num_keys value that results in a 4MB allocation attempt at most, causing a warning in the page allocator when the order exceeds MAX_PAGE_ORDER. To fix this, use kvzalloc() instead of kzalloc(). This bug has the same reasoning and fix with the patch below: https://lore.kernel.org/linux-block/20251212013510.3576091-1-kartikey406@gmail.com/ Warning log: WARNING: mm/page_alloc.c:5216 at __alloc_frozen_pages_noprof+0x5aa/0x2300 mm/page_alloc.c:5216, CPU#1: syz-executor117/272 Modules linked in: CPU: 1 UID: 0 PID: 272 Comm: syz-executor117 Not tainted 6.19.0 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:__alloc_frozen_pages_noprof+0x5aa/0x2300 mm/page_alloc.c:5216 Code: ff 83 bd a8 fe ff ff 0a 0f 86 69 fb ff ff 0f b6 1d f9 f9 c4 04 80 fb 01 0f 87 3b 76 30 ff 83 e3 01 75 09 c6 05 e4 f9 c4 04 01 <0f> 0b 48 c7 85 70 fe ff ff 00 00 00 00 e9 8f fd ff ff 31 c0 e9 0d RSP: 0018:ffffc90000fcf450 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1ffff920001f9ea0 RDX: 0000000000000000 RSI: 000000000000000b RDI: 0000000000040dc0 RBP: ffffc90000fcf648 R08: ffff88800b6c3380 R09: 0000000000000001 R10: ffffc90000fcf840 R11: ffff88807ffad280 R12: 0000000000000000 R13: 0000000000040dc0 R14: 0000000000000001 R15: ffffc90000fcf620 FS: 0000555565db33c0(0000) GS:ffff8880be26c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002000000c CR3: 0000000003b72000 CR4: 00000000000006f0 Call Trace: alloc_pages_mpol+0x236/0x4d0 mm/mempolicy.c:2486 alloc_frozen_pages_noprof+0x149/0x180 mm/mempolicy.c:2557 ___kmalloc_large_node+0x10c/0x140 mm/slub.c:5598 __kmalloc_large_node_noprof+0x25/0xc0 mm/slub.c:5629 __do_kmalloc_node mm/slub.c:5645 [inline] __kmalloc_noprof+0x483/0x6f0 mm/slub.c:5669 kmalloc_noprof include/linux/slab.h:961 [inline] kzalloc_noprof include/linux/slab.h:1094 [inline] nvme_pr_read_keys+0x8f/0x4c0 drivers/nvme/host/pr.c:245 blkdev_pr_read_keys block/ioctl.c:456 [inline] blkdev_common_ioctl+0x1b71/0x29b0 block/ioctl.c:730 blkdev_ioctl+0x299/0x700 block/ioctl.c:786 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x1bf/0x220 fs/ioctl.c:583 x64_sys_call+0x1280/0x21b0 mnt/fuzznvme_1/fuzznvme/linux-build/v6.19/./arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x71/0x330 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fb893d3108d Code: 28 c3 e8 46 1e 00 00 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffff61f2f38 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffff61f3138 RCX: 00007fb893d3108d RDX: 0000000020000040 RSI: 00000000c01070ce RDI: 0000000000000003 RBP: 0000000000000001 R08: 0000000000000000 R09: 00007ffff61f3138 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007ffff61f3128 R14: 00007fb893dae530 R15: 0000000000000001 Fixes: 5fd96a4e15de (nvme: Add pr_ops read_keys support) Acked-by: Chao Shi Acked-by: Weidong Zhu Acked-by: Dave Tian Reviewed-by: Christoph Hellwig Reviewed-by: Hannes Reinecke Signed-off-by: Sungwoo Kim Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 76f327fa4f1b79a89c543eda09133b76a8ad99c8 Author: Stefan Hajnoczi Date: Mon Dec 1 16:43:27 2025 -0500 nvme: reject invalid pr_read_keys() num_keys values [ Upstream commit 38ec8469f39e0e96e7dd9b76f05e0f8eb78be681 ] The pr_read_keys() interface has a u32 num_keys parameter. The NVMe Reservation Report command has a u32 maximum length. Reject num_keys values that are too large to fit. This will become important when pr_read_keys() is exposed to untrusted userspace via an ioctl. Signed-off-by: Stefan Hajnoczi Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Reviewed-by: Martin K. Petersen Signed-off-by: Jens Axboe Stable-dep-of: c3320153769f ("nvme: fix memory allocation in nvme_pr_read_keys()") Signed-off-by: Sasha Levin commit 05e3f01974d09d1b746dedf4144f708b5033e76f Author: Shuicheng Lin Date: Wed Feb 4 17:28:11 2026 +0000 drm/xe/reg_sr: Fix leak on xa_store failure [ Upstream commit 3091723785def05ebfe6a50866f87a044ae314ba ] Free the newly allocated entry when xa_store() fails to avoid a memory leak on the error path. v2: use goto fail_free. (Bala) Fixes: e5283bd4dfec ("drm/xe/reg_sr: Remove register pool") Cc: Balasubramani Vivekanandan Cc: Matt Roper Signed-off-by: Shuicheng Lin Reviewed-by: Matt Roper Link: https://patch.msgid.link/20260204172810.1486719-2-shuicheng.lin@intel.com Signed-off-by: Matt Roper (cherry picked from commit 6bc6fec71ac45f52db609af4e62bdb96b9f5fadb) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 3c8852cff2bb8c5bf76e8c4c97c8b73fb3d3fd0d Author: Zhanjun Dong Date: Fri Feb 20 17:53:08 2026 -0500 drm/xe/gsc: Fix GSC proxy cleanup on early initialization failure [ Upstream commit b3368ecca9538b88ddf982ea99064860fd5add97 ] xe_gsc_proxy_remove undoes what is done in both xe_gsc_proxy_init and xe_gsc_proxy_start; however, if we fail between those 2 calls, it is possible that the HW forcewake access hasn't been initialized yet and so we hit errors when the cleanup code tries to write GSC register. To avoid that, split the cleanup in 2 functions so that the HW cleanup is only called if the HW setup was completed successfully. Since the HW cleanup (interrupt disabling) is now removed from xe_gsc_proxy_remove, the cleanup on error paths in xe_gsc_proxy_start must be updated to disable interrupts before returning. Fixes: ff6cd29b690b ("drm/xe: Cleanup unwind of gt initialization") Signed-off-by: Zhanjun Dong Reviewed-by: Daniele Ceraolo Spurio Signed-off-by: Daniele Ceraolo Spurio Link: https://patch.msgid.link/20260220225308.101469-1-zhanjun.dong@intel.com (cherry picked from commit 2b37c401b265c07b46408b5cb36a4b757c9b5060) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 1c72e7b0b442ce21a1348d9b8237cfddb67048eb Author: Charles Haithcock Date: Fri Feb 27 18:41:15 2026 -0700 i2c: i801: Revert "i2c: i801: replace acpi_lock with I2C bus lock" [ Upstream commit cfc69c2e6c699c96949f7b0455195b0bfb7dc715 ] This reverts commit f707d6b9e7c18f669adfdb443906d46cfbaaa0c1. Under rare circumstances, multiple udev threads can collect i801 device info on boot and walk i801_acpi_io_handler somewhat concurrently. The first will note the area is reserved by acpi to prevent further touches. This ultimately causes the area to be deregistered. The second will enter i801_acpi_io_handler after the area is unregistered but before a check can be made that the area is unregistered. i2c_lock_bus relies on the now unregistered area containing lock_ops to lock the bus. The end result is a kernel panic on boot with the following backtrace; [ 14.971872] ioatdma 0000:09:00.2: enabling device (0100 -> 0102) [ 14.971873] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 14.971880] #PF: supervisor read access in kernel mode [ 14.971884] #PF: error_code(0x0000) - not-present page [ 14.971887] PGD 0 P4D 0 [ 14.971894] Oops: 0000 [#1] PREEMPT SMP PTI [ 14.971900] CPU: 5 PID: 956 Comm: systemd-udevd Not tainted 5.14.0-611.5.1.el9_7.x86_64 #1 [ 14.971905] Hardware name: XXXXXXXXXXXXXXXXXXXXXXX BIOS 1.20.10.SV91 01/30/2023 [ 14.971908] RIP: 0010:i801_acpi_io_handler+0x2d/0xb0 [i2c_i801] [ 14.971929] Code: 00 00 49 8b 40 20 41 57 41 56 4d 8b b8 30 04 00 00 49 89 ce 41 55 41 89 d5 41 54 49 89 f4 be 02 00 00 00 55 4c 89 c5 53 89 fb <48> 8b 00 4c 89 c7 e8 18 61 54 e9 80 bd 80 04 00 00 00 75 09 4c 3b [ 14.971933] RSP: 0018:ffffbaa841483838 EFLAGS: 00010282 [ 14.971938] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9685e01ba568 [ 14.971941] RDX: 0000000000000008 RSI: 0000000000000002 RDI: 0000000000000000 [ 14.971944] RBP: ffff9685ca22f028 R08: ffff9685ca22f028 R09: ffff9685ca22f028 [ 14.971948] R10: 000000000000000b R11: 0000000000000580 R12: 0000000000000580 [ 14.971951] R13: 0000000000000008 R14: ffff9685e01ba568 R15: ffff9685c222f000 [ 14.971954] FS: 00007f8287c0ab40(0000) GS:ffff96a47f940000(0000) knlGS:0000000000000000 [ 14.971959] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 14.971963] CR2: 0000000000000000 CR3: 0000000168090001 CR4: 00000000003706f0 [ 14.971966] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 14.971968] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 14.971972] Call Trace: [ 14.971977] [ 14.971981] ? show_trace_log_lvl+0x1c4/0x2df [ 14.971994] ? show_trace_log_lvl+0x1c4/0x2df [ 14.972003] ? acpi_ev_address_space_dispatch+0x16e/0x3c0 [ 14.972014] ? __die_body.cold+0x8/0xd [ 14.972021] ? page_fault_oops+0x132/0x170 [ 14.972028] ? exc_page_fault+0x61/0x150 [ 14.972036] ? asm_exc_page_fault+0x22/0x30 [ 14.972045] ? i801_acpi_io_handler+0x2d/0xb0 [i2c_i801] [ 14.972061] acpi_ev_address_space_dispatch+0x16e/0x3c0 [ 14.972069] ? __pfx_i801_acpi_io_handler+0x10/0x10 [i2c_i801] [ 14.972085] acpi_ex_access_region+0x5b/0xd0 [ 14.972093] acpi_ex_field_datum_io+0x73/0x2e0 [ 14.972100] acpi_ex_read_data_from_field+0x8e/0x230 [ 14.972106] acpi_ex_resolve_node_to_value+0x23d/0x310 [ 14.972114] acpi_ds_evaluate_name_path+0xad/0x110 [ 14.972121] acpi_ds_exec_end_op+0x321/0x510 [ 14.972127] acpi_ps_parse_loop+0xf7/0x680 [ 14.972136] acpi_ps_parse_aml+0x17a/0x3d0 [ 14.972143] acpi_ps_execute_method+0x137/0x270 [ 14.972150] acpi_ns_evaluate+0x1f4/0x2e0 [ 14.972158] acpi_evaluate_object+0x134/0x2f0 [ 14.972164] acpi_evaluate_integer+0x50/0xe0 [ 14.972173] ? vsnprintf+0x24b/0x570 [ 14.972181] acpi_ac_get_state.part.0+0x23/0x70 [ 14.972189] get_ac_property+0x4e/0x60 [ 14.972195] power_supply_show_property+0x90/0x1f0 [ 14.972205] add_prop_uevent+0x29/0x90 [ 14.972213] power_supply_uevent+0x109/0x1d0 [ 14.972222] dev_uevent+0x10e/0x2f0 [ 14.972228] uevent_show+0x8e/0x100 [ 14.972236] dev_attr_show+0x19/0x40 [ 14.972246] sysfs_kf_seq_show+0x9b/0x100 [ 14.972253] seq_read_iter+0x120/0x4b0 [ 14.972262] ? selinux_file_permission+0x106/0x150 [ 14.972273] vfs_read+0x24f/0x3a0 [ 14.972284] ksys_read+0x5f/0xe0 [ 14.972291] do_syscall_64+0x5f/0xe0 ... The kernel panic is mitigated by setting limiting the count of udev children to 1. Revert to using the acpi_lock to continue protecting marking the area as owned by firmware without relying on a lock in a potentially unmapped region of memory. Fixes: f707d6b9e7c1 ("i2c: i801: replace acpi_lock with I2C bus lock") Signed-off-by: Charles Haithcock [wsa: added Fixes-tag and updated comment stating the importance of the lock] Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit da09dfc90cb7ed1ab40d675234382f151eeb0563 Author: Yujie Liu Date: Fri Feb 27 16:24:52 2026 +0800 drm/sched: Fix kernel-doc warning for drm_sched_job_done() [ Upstream commit 61ded1083b264ff67ca8c2de822c66b6febaf9a8 ] There is a kernel-doc warning for the scheduler: Warning: drivers/gpu/drm/scheduler/sched_main.c:367 function parameter 'result' not described in 'drm_sched_job_done' Fix the warning by describing the undocumented error code. Fixes: 539f9ee4b52a ("drm/scheduler: properly forward fence errors") Signed-off-by: Yujie Liu [phasta: Flesh out commit message] Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20260227082452.1802922-1-yujie.liu@intel.com Signed-off-by: Sasha Levin commit 5649775b3ebf269e27b3836281fea3b7ac94d4c0 Author: Raju Rangoju Date: Mon Mar 2 09:51:24 2026 +0530 amd-xgbe: fix sleep while atomic on suspend/resume [ Upstream commit e2f27363aa6d983504c6836dd0975535e2e9dba0 ] The xgbe_powerdown() and xgbe_powerup() functions use spinlocks (spin_lock_irqsave) while calling functions that may sleep: - napi_disable() can sleep waiting for NAPI polling to complete - flush_workqueue() can sleep waiting for pending work items This causes a "BUG: scheduling while atomic" error during suspend/resume cycles on systems using the AMD XGBE Ethernet controller. The spinlock protection in these functions is unnecessary as these functions are called from suspend/resume paths which are already serialized by the PM core Fix this by removing the spinlock. Since only code that takes this lock is xgbe_powerdown() and xgbe_powerup(), remove it completely. Fixes: c5aa9e3b8156 ("amd-xgbe: Initial AMD 10GbE platform driver") Signed-off-by: Raju Rangoju Link: https://patch.msgid.link/20260302042124.1386445-1-Raju.Rangoju@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7e4ad34a8889a6a9e0f6cc7c55d02161fe31a199 Author: Yung Chih Su Date: Mon Mar 2 14:02:47 2026 +0800 net: ipv4: fix ARM64 alignment fault in multipath hash seed [ Upstream commit 4ee7fa6cf78ff26d783d39e2949d14c4c1cd5e7f ] `struct sysctl_fib_multipath_hash_seed` contains two u32 fields (user_seed and mp_seed), making it an 8-byte structure with a 4-byte alignment requirement. In `fib_multipath_hash_from_keys()`, the code evaluates the entire struct atomically via `READ_ONCE()`: mp_seed = READ_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed).mp_seed; While this silently works on GCC by falling back to unaligned regular loads which the ARM64 kernel tolerates, it causes a fatal kernel panic when compiled with Clang and LTO enabled. Commit e35123d83ee3 ("arm64: lto: Strengthen READ_ONCE() to acquire when CONFIG_LTO=y") strengthens `READ_ONCE()` to use Load-Acquire instructions (`ldar` / `ldapr`) to prevent compiler reordering bugs under Clang LTO. Since the macro evaluates the full 8-byte struct, Clang emits a 64-bit `ldar` instruction. ARM64 architecture strictly requires `ldar` to be naturally aligned, thus executing it on a 4-byte aligned address triggers a strict Alignment Fault (FSC = 0x21). Fix the read side by moving the `READ_ONCE()` directly to the `u32` member, which emits a safe 32-bit `ldar Wn`. Furthermore, Eric Dumazet pointed out that `WRITE_ONCE()` on the entire struct in `proc_fib_multipath_hash_set_seed()` is also flawed. Analysis shows that Clang splits this 8-byte write into two separate 32-bit `str` instructions. While this avoids an alignment fault, it destroys atomicity and exposes a tear-write vulnerability. Fix this by explicitly splitting the write into two 32-bit `WRITE_ONCE()` operations. Finally, add the missing `READ_ONCE()` when reading `user_seed` in `proc_fib_multipath_hash_seed()` to ensure proper pairing and concurrency safety. Fixes: 4ee2a8cace3f ("net: ipv4: Add a sysctl to set multipath hash seed") Signed-off-by: Yung Chih Su Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260302060247.7066-1-yuuchihsu@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0b5a7826020706057cc5a9d9009e667027f221ee Author: Jakub Kicinski Date: Sun Mar 1 11:45:48 2026 -0800 ipv6: fix NULL pointer deref in ip6_rt_get_dev_rcu() [ Upstream commit 2ffb4f5c2ccb2fa1c049dd11899aee7967deef5a ] l3mdev_master_dev_rcu() can return NULL when the slave device is being un-slaved from a VRF. All other callers deal with this, but we lost the fallback to loopback in ip6_rt_pcpu_alloc() -> ip6_rt_get_dev_rcu() with commit 4832c30d5458 ("net: ipv6: put host and anycast routes on device with address"). KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f] RIP: 0010:ip6_rt_pcpu_alloc (net/ipv6/route.c:1418) Call Trace: ip6_pol_route (net/ipv6/route.c:2318) fib6_rule_lookup (net/ipv6/fib6_rules.c:115) ip6_route_output_flags (net/ipv6/route.c:2607) vrf_process_v6_outbound (drivers/net/vrf.c:437) I was tempted to rework the un-slaving code to clear the flag first and insert synchronize_rcu() before we remove the upper. But looks like the explicit fallback to loopback_dev is an established pattern. And I guess avoiding the synchronize_rcu() is nice, too. Fixes: 4832c30d5458 ("net: ipv6: put host and anycast routes on device with address") Reviewed-by: David Ahern Link: https://patch.msgid.link/20260301194548.927324-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5566a9eeb00e5317426559aa848a711913477a6a Author: ZhangGuoDong Date: Tue Mar 3 15:13:12 2026 +0000 smb/client: fix buffer size for smb311_posix_qinfo in SMB311_posix_query_info() [ Upstream commit 9621b996e4db1dbc2b3dc5d5910b7d6179397320 ] SMB311_posix_query_info() is currently unused, but it may still be used in some stable versions, so these changes are submitted as a separate patch. Use `sizeof(struct smb311_posix_qinfo)` instead of sizeof its pointer, so the allocated buffer matches the actual struct size. Fixes: b1bc1874b885 ("smb311: Add support for SMB311 query info (non-compounded)") Reported-by: ChenXiaoSong Signed-off-by: ZhangGuoDong Reviewed-by: ChenXiaoSong Signed-off-by: Steve French Signed-off-by: Sasha Levin commit b751369b03c8a386bc73a4b94bb8c0210fc0682b Author: ZhangGuoDong Date: Tue Mar 3 15:13:11 2026 +0000 smb/client: fix buffer size for smb311_posix_qinfo in smb2_compound_op() [ Upstream commit 12c43a062acb0ac137fc2a4a106d4d084b8c5416 ] Use `sizeof(struct smb311_posix_qinfo)` instead of sizeof its pointer, so the allocated buffer matches the actual struct size. Fixes: 6a5f6592a0b6 ("SMB311: Add support for query info using posix extensions (level 100)") Reported-by: ChenXiaoSong Signed-off-by: ZhangGuoDong Reviewed-by: ChenXiaoSong Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 3eeddb80191f7626ec1ef742bfff51ec3b0fa5c2 Author: Lang Xu Date: Tue Mar 3 17:52:17 2026 +0800 bpf: Fix a UAF issue in bpf_trampoline_link_cgroup_shim [ Upstream commit 56145d237385ca0e7ca9ff7b226aaf2eb8ef368b ] The root cause of this bug is that when 'bpf_link_put' reduces the refcount of 'shim_link->link.link' to zero, the resource is considered released but may still be referenced via 'tr->progs_hlist' in 'cgroup_shim_find'. The actual cleanup of 'tr->progs_hlist' in 'bpf_shim_tramp_link_release' is deferred. During this window, another process can cause a use-after-free via 'bpf_trampoline_link_cgroup_shim'. Based on Martin KaFai Lau's suggestions, I have created a simple patch. To fix this: Add an atomic non-zero check in 'bpf_trampoline_link_cgroup_shim'. Only increment the refcount if it is not already zero. Testing: I verified the fix by adding a delay in 'bpf_shim_tramp_link_release' to make the bug easier to trigger: static void bpf_shim_tramp_link_release(struct bpf_link *link) { /* ... */ if (!shim_link->trampoline) return; + msleep(100); WARN_ON_ONCE(bpf_trampoline_unlink_prog(&shim_link->link, shim_link->trampoline, NULL)); bpf_trampoline_put(shim_link->trampoline); } Before the patch, running a PoC easily reproduced the crash(almost 100%) with a call trace similar to KaiyanM's report. After the patch, the bug no longer occurs even after millions of iterations. Fixes: 69fd337a975c ("bpf: per-cgroup lsm flavor") Reported-by: Kaiyan Mei Closes: https://lore.kernel.org/bpf/3c4ebb0b.46ff8.19abab8abe2.Coremail.kaiyanm@hust.edu.cn/ Signed-off-by: Lang Xu Signed-off-by: Martin KaFai Lau Link: https://patch.msgid.link/279EEE1BA1DDB49D+20260303095217.34436-1-xulang@uniontech.com Signed-off-by: Sasha Levin commit ba47e33717642da00b5144ec9220b04c61d32a00 Author: Vivek Behera Date: Thu Jan 22 15:16:52 2026 +0100 igb: Fix trigger of incorrect irq in igb_xsk_wakeup [ Upstream commit d4c13ab36273a8c318ba06799793cc1f5d9c6fa1 ] The current implementation in the igb_xsk_wakeup expects the Rx and Tx queues to share the same irq. This would lead to triggering of incorrect irq in split irq configuration. This patch addresses this issue which could impact environments with 2 active cpu cores or when the number of queues is reduced to 2 or less cat /proc/interrupts | grep eno2 167: 0 0 0 0 IR-PCI-MSIX-0000:08:00.0 0-edge eno2 168: 0 0 0 0 IR-PCI-MSIX-0000:08:00.0 1-edge eno2-rx-0 169: 0 0 0 0 IR-PCI-MSIX-0000:08:00.0 2-edge eno2-rx-1 170: 0 0 0 0 IR-PCI-MSIX-0000:08:00.0 3-edge eno2-tx-0 171: 0 0 0 0 IR-PCI-MSIX-0000:08:00.0 4-edge eno2-tx-1 Furthermore it uses the flags input argument to trigger either rx, tx or both rx and tx irqs as specified in the ndo_xsk_wakeup api documentation Fixes: 80f6ccf9f116 ("igb: Introduce XSK data structures and helpers") Signed-off-by: Vivek Behera Reviewed-by: Aleksandr Loktionov Suggested-by: Maciej Fijalkowski Acked-by: Maciej Fijalkowski Tested-by: Saritha Sanigani (A Contingent Worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 2199e190cf6bb1835a8224c3ab441099e53022bc Author: Kohei Enju Date: Tue Feb 10 15:57:14 2026 +0000 iavf: fix netdev->max_mtu to respect actual hardware limit [ Upstream commit b84852170153671bb0fa6737a6e48370addd8e1a ] iavf sets LIBIE_MAX_MTU as netdev->max_mtu, ignoring vf_res->max_mtu from PF [1]. This allows setting an MTU beyond the actual hardware limit, causing TX queue timeouts [2]. Set correct netdev->max_mtu using vf_res->max_mtu from the PF. Note that currently PF drivers such as ice/i40e set the frame size in vf_res->max_mtu, not MTU. Convert vf_res->max_mtu to MTU before setting netdev->max_mtu. [1] # ip -j -d link show $DEV | jq '.[0].max_mtu' 16356 [2] iavf 0000:00:05.0 enp0s5: NETDEV WATCHDOG: CPU: 1: transmit queue 0 timed out 5692 ms iavf 0000:00:05.0 enp0s5: NIC Link is Up Speed is 10 Gbps Full Duplex iavf 0000:00:05.0 enp0s5: NETDEV WATCHDOG: CPU: 6: transmit queue 3 timed out 5312 ms iavf 0000:00:05.0 enp0s5: NIC Link is Up Speed is 10 Gbps Full Duplex ... Fixes: 5fa4caff59f2 ("iavf: switch to Page Pool") Signed-off-by: Kohei Enju Reviewed-by: Alexander Lobakin Reviewed-by: Simon Horman Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 0138d1cdb19fa49181a5aaba32427f1787cb3935 Author: Michal Swiatkowski Date: Wed Feb 11 10:11:40 2026 +0100 libie: don't unroll if fwlog isn't supported [ Upstream commit 636cc3bd12f499c74eaf5dc9a7d5b832f1bb24ed ] The libie_fwlog_deinit() function can be called during driver unload even when firmware logging was never properly initialized. This led to call trace: [ 148.576156] Oops: Oops: 0000 [#1] SMP NOPTI [ 148.576167] CPU: 80 UID: 0 PID: 12843 Comm: rmmod Kdump: loaded Not tainted 6.17.0-rc7next-queue-3oct-01915-g06d79d51cf51 #1 PREEMPT(full) [ 148.576177] Hardware name: HPE ProLiant DL385 Gen10 Plus/ProLiant DL385 Gen10 Plus, BIOS A42 07/18/2020 [ 148.576182] RIP: 0010:__dev_printk+0x16/0x70 [ 148.576196] Code: 1f 44 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 41 55 41 54 49 89 d4 55 48 89 fd 53 48 85 f6 74 3c <4c> 8b 6e 50 48 89 f3 4d 85 ed 75 03 4c 8b 2e 48 89 df e8 f3 27 98 [ 148.576204] RSP: 0018:ffffd2fd7ea17a48 EFLAGS: 00010202 [ 148.576211] RAX: ffffd2fd7ea17aa0 RBX: ffff8eb288ae2000 RCX: 0000000000000000 [ 148.576217] RDX: ffffd2fd7ea17a70 RSI: 00000000000000c8 RDI: ffffffffb68d3d88 [ 148.576222] RBP: ffffffffb68d3d88 R08: 0000000000000000 R09: 0000000000000000 [ 148.576227] R10: 00000000000000c8 R11: ffff8eb2b1a49400 R12: ffffd2fd7ea17a70 [ 148.576231] R13: ffff8eb3141fb000 R14: ffffffffc1215b48 R15: ffffffffc1215bd8 [ 148.576236] FS: 00007f5666ba6740(0000) GS:ffff8eb2472b9000(0000) knlGS:0000000000000000 [ 148.576242] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 148.576247] CR2: 0000000000000118 CR3: 000000011ad17000 CR4: 0000000000350ef0 [ 148.576252] Call Trace: [ 148.576258] [ 148.576269] _dev_warn+0x7c/0x96 [ 148.576290] libie_fwlog_deinit+0x112/0x117 [libie_fwlog] [ 148.576303] ixgbe_remove+0x63/0x290 [ixgbe] [ 148.576342] pci_device_remove+0x42/0xb0 [ 148.576354] device_release_driver_internal+0x19c/0x200 [ 148.576365] driver_detach+0x48/0x90 [ 148.576372] bus_remove_driver+0x6d/0xf0 [ 148.576383] pci_unregister_driver+0x2e/0xb0 [ 148.576393] ixgbe_exit_module+0x1c/0xd50 [ixgbe] [ 148.576430] __do_sys_delete_module.isra.0+0x1bc/0x2e0 [ 148.576446] do_syscall_64+0x7f/0x980 It can be reproduced by trying to unload ixgbe driver in recovery mode. Fix that by checking if fwlog is supported before doing unroll. Fixes: 641585bc978e ("ixgbe: fwlog support for e610") Reviewed-by: Aleksandr Loktionov Signed-off-by: Michal Swiatkowski Reviewed-by: Simon Horman Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit b9333d41ee03a2405341aab6e82443b99391a8a4 Author: Larysa Zaremba Date: Wed Dec 3 14:29:48 2025 +0100 ice: fix adding AQ LLDP filter for VF [ Upstream commit eef33aa44935d001747ca97703c08dd6f9031162 ] The referenced commit came from a misunderstanding of the FW LLDP filter AQ (Admin Queue) command due to the error in the internal documentation. Contrary to the assumptions in the original commit, VFs can be added and deleted from this filter without any problems. Introduced dev_info message proved to be useful, so reverting the whole commit does not make sense. Without this fix, trusted VFs do not receive LLDP traffic, if there is an AQ LLDP filter on PF. When trusted VF attempts to add an LLDP multicast MAC address, the following message can be seen in dmesg on host: ice 0000:33:00.0: Failed to add Rx LLDP rule on VSI 20 error: -95 Revert checking VSI type when adding LLDP filter through AQ. Fixes: 4d5a1c4e6d49 ("ice: do not add LLDP-specific filter if not necessary") Reviewed-by: Aleksandr Loktionov Signed-off-by: Larysa Zaremba Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 1e077c65e02022cb7c772d9b08245a250c940845 Author: David Thomson Date: Tue Feb 24 09:37:11 2026 +0000 xen/acpi-processor: fix _CST detection using undersized evaluation buffer [ Upstream commit 8b57227d59a86fc06d4f09de08f98133680f2cae ] read_acpi_id() attempts to evaluate _CST using a stack buffer of sizeof(union acpi_object) (48 bytes), but _CST returns a nested Package of sub-Packages (one per C-state, each containing a register descriptor, type, latency, and power) requiring hundreds of bytes. The evaluation always fails with AE_BUFFER_OVERFLOW. On modern systems using FFH/MWAIT entry (where pblk is zero), this causes the function to return before setting the acpi_id_cst_present bit. In check_acpi_ids(), flags.power is then zero for all Phase 2 CPUs (physical CPUs beyond dom0's vCPU count), so push_cxx_to_hypervisor() is never called for them. On a system with dom0_max_vcpus=2 and 8 physical CPUs, only PCPUs 0-1 receive C-state data. PCPUs 2-7 are stuck in C0/C1 idle, unable to enter C2/C3. This costs measurable wall power (4W observed on an Intel Core Ultra 7 265K with Xen 4.20). The function never uses the _CST return value -- it only needs to know whether _CST exists. Replace the broken acpi_evaluate_object() call with acpi_has_method(), which correctly detects _CST presence using acpi_get_handle() without any buffer allocation. This brings C-state detection to parity with the P-state path, which already works correctly for Phase 2 CPUs. Fixes: 59a568029181 ("xen/acpi-processor: C and P-state driver that uploads said data to hypervisor.") Signed-off-by: David Thomson Reviewed-by: Jan Beulich Signed-off-by: Juergen Gross Message-ID: <20260224093707.19679-1-dt@linux-mail.net> Signed-off-by: Sasha Levin commit 6ce948fa54599f369ff7fe8b793a6aae4b0762b2 Author: Allison Henderson Date: Fri Feb 27 13:23:36 2026 -0700 net/rds: Fix circular locking dependency in rds_tcp_tune [ Upstream commit 6a877ececd6daa002a9a0002cd0fbca6592a9244 ] syzbot reported a circular locking dependency in rds_tcp_tune() where sk_net_refcnt_upgrade() is called while holding the socket lock: ====================================================== WARNING: possible circular locking dependency detected ====================================================== kworker/u10:8/15040 is trying to acquire lock: ffffffff8e9aaf80 (fs_reclaim){+.+.}-{0:0}, at: __kmalloc_cache_noprof+0x4b/0x6f0 but task is already holding lock: ffff88805a3c1ce0 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at: rds_tcp_tune+0xd7/0x930 The issue occurs because sk_net_refcnt_upgrade() performs memory allocation (via get_net_track() -> ref_tracker_alloc()) while the socket lock is held, creating a circular dependency with fs_reclaim. Fix this by moving sk_net_refcnt_upgrade() outside the socket lock critical section. This is safe because the fields modified by the sk_net_refcnt_upgrade() call (sk_net_refcnt, ns_tracker) are not accessed by any concurrent code path at this point. v2: - Corrected fixes tag - check patch line wrap nits - ai commentary nits Reported-by: syzbot+2e2cf5331207053b8106@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=2e2cf5331207053b8106 Fixes: 3a58f13a881e ("net: rds: acquire refcount on TCP sockets") Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260227202336.167757-1-achender@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ca795bf1230b653bce1e0fb0df43ca559c82e722 Author: Eric Dumazet Date: Fri Feb 27 17:26:03 2026 +0000 indirect_call_wrapper: do not reevaluate function pointer [ Upstream commit 710f5c76580306cdb9ec51fac8fcf6a8faff7821 ] We have an increasing number of READ_ONCE(xxx->function) combined with INDIRECT_CALL_[1234]() helpers. Unfortunately this forces INDIRECT_CALL_[1234]() to read xxx->function many times, which is not what we wanted. Fix these macros so that xxx->function value is not reloaded. $ scripts/bloat-o-meter -t vmlinux.0 vmlinux add/remove: 0/0 grow/shrink: 1/65 up/down: 122/-1084 (-962) Function old new delta ip_push_pending_frames 59 181 +122 ip6_finish_output 687 681 -6 __udp_enqueue_schedule_skb 1078 1072 -6 ioam6_output 2319 2312 -7 xfrm4_rcv_encap_finish2 64 56 -8 xfrm4_output 297 289 -8 vrf_ip_local_out 278 270 -8 vrf_ip6_local_out 278 270 -8 seg6_input_finish 64 56 -8 rpl_output 700 692 -8 ipmr_forward_finish 124 116 -8 ip_forward_finish 143 135 -8 ip6mr_forward2_finish 100 92 -8 ip6_forward_finish 73 65 -8 input_action_end_bpf 1091 1083 -8 dst_input 52 44 -8 __xfrm6_output 801 793 -8 __xfrm4_output 83 75 -8 bpf_input 500 491 -9 __tcp_check_space 530 521 -9 input_action_end_dt6 291 280 -11 vti6_tnl_xmit 1634 1622 -12 bpf_xmit 1203 1191 -12 rpl_input 497 483 -14 rawv6_send_hdrinc 1355 1341 -14 ndisc_send_skb 1030 1016 -14 ipv6_srh_rcv 1377 1363 -14 ip_send_unicast_reply 1253 1239 -14 ip_rcv_finish 226 212 -14 ip6_rcv_finish 300 286 -14 input_action_end_x_core 205 191 -14 input_action_end_x 355 341 -14 input_action_end_t 205 191 -14 input_action_end_dx6_finish 127 113 -14 input_action_end_dx4_finish 373 359 -14 input_action_end_dt4 426 412 -14 input_action_end_core 186 172 -14 input_action_end_b6_encap 292 278 -14 input_action_end_b6 198 184 -14 igmp6_send 1332 1318 -14 ip_sublist_rcv 864 848 -16 ip6_sublist_rcv 1091 1075 -16 ipv6_rpl_srh_rcv 1937 1920 -17 xfrm_policy_queue_process 1246 1228 -18 seg6_output_core 903 885 -18 mld_sendpack 856 836 -20 NF_HOOK 756 736 -20 vti_tunnel_xmit 1447 1426 -21 input_action_end_dx6 664 642 -22 input_action_end 1502 1480 -22 sock_sendmsg_nosec 134 111 -23 ip6mr_forward2 388 364 -24 sock_recvmsg_nosec 134 109 -25 seg6_input_core 836 810 -26 ip_send_skb 172 146 -26 ip_local_out 140 114 -26 ip6_local_out 140 114 -26 __sock_sendmsg 162 136 -26 __ip_queue_xmit 1196 1170 -26 __ip_finish_output 405 379 -26 ipmr_queue_fwd_xmit 373 346 -27 sock_recvmsg 173 145 -28 ip6_xmit 1635 1607 -28 xfrm_output_resume 1418 1389 -29 ip_build_and_send_pkt 625 591 -34 dst_output 504 432 -72 Total: Before=25217686, After=25216724, chg -0.00% Fixes: 283c16a2dfd3 ("indirect call wrappers: helpers to speed-up indirect calls of builtin") Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260227172603.1700433-1-edumazet@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 9612d91f617231e03c49cb9b0c02f975a3b4f51f Author: Lorenzo Bianconi Date: Thu Feb 26 20:11:16 2026 +0100 wifi: mt76: Fix possible oob access in mt76_connac2_mac_write_txwi_80211() [ Upstream commit 4e10a730d1b511ff49723371ed6d694dd1b2c785 ] Check frame length before accessing the mgmt fields in mt76_connac2_mac_write_txwi_80211 in order to avoid a possible oob access. Fixes: 577dbc6c656d ("mt76: mt7915: enable offloading of sequence number assignment") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260226-mt76-addba-req-oob-access-v1-3-b0f6d1ad4850@kernel.org [fix check to also cover mgmt->u.action.u.addba_req.capab, correct Fixes tag] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 2831a8c574545101e6d0df50785fccb16474eb3c Author: Lorenzo Bianconi Date: Thu Feb 26 20:11:15 2026 +0100 wifi: mt76: mt7925: Fix possible oob access in mt7925_mac_write_txwi_80211() [ Upstream commit c41a9abd6ae31d130e8f332e7c8800c4c866234b ] Check frame length before accessing the mgmt fields in mt7925_mac_write_txwi_80211 in order to avoid a possible oob access. Fixes: c948b5da6bbec ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260226-mt76-addba-req-oob-access-v1-2-b0f6d1ad4850@kernel.org Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit f4cdf6b43689e901a341e7147fcfb25057c38eae Author: Lorenzo Bianconi Date: Thu Feb 26 20:11:14 2026 +0100 wifi: mt76: mt7996: Fix possible oob access in mt7996_mac_write_txwi_80211() [ Upstream commit 60862846308627e9e15546bb647a00de44deb27b ] Check frame length before accessing the mgmt fields in mt7996_mac_write_txwi_80211 in order to avoid a possible oob access. Fixes: 98686cd21624c ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260226-mt76-addba-req-oob-access-v1-1-b0f6d1ad4850@kernel.org Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit fcef983ad88832f3aa83491a174c345de57afbbd Author: Bart Van Assche Date: Mon Feb 23 14:00:25 2026 -0800 wifi: wlcore: Fix a locking bug [ Upstream commit 72c6df8f284b3a49812ce2ac136727ace70acc7c ] Make sure that wl->mutex is locked before it is unlocked. This has been detected by the Clang thread-safety analyzer. Fixes: 45aa7f071b06 ("wlcore: Use generic runtime pm calls for wowlan elp configuration") Signed-off-by: Bart Van Assche Link: https://patch.msgid.link/20260223220102.2158611-26-bart.vanassche@linux.dev Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit f98c195052ab857f83ec6b76b0b6dea7183ef2ee Author: Bart Van Assche Date: Mon Feb 23 14:00:24 2026 -0800 wifi: cw1200: Fix locking in error paths [ Upstream commit d98c24617a831e92e7224a07dcaed2dd0b02af96 ] cw1200_wow_suspend() must only return with priv->conf_mutex locked if it returns zero. This mutex must be unlocked if an error is returned. Add mutex_unlock() calls to the error paths from which that call is missing. This has been detected by the Clang thread-safety analyzer. Fixes: a910e4a94f69 ("cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets") Signed-off-by: Bart Van Assche Link: https://patch.msgid.link/20260223220102.2158611-25-bart.vanassche@linux.dev Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 93e00a88951d688795260dcc90c172ae30f51a4b Author: Vimlesh Kumar Date: Fri Feb 27 09:14:00 2026 +0000 octeon_ep_vf: avoid compiler and IQ/OQ reordering [ Upstream commit 6c73126ecd1080351b468fe43353b2f705487f44 ] Utilize READ_ONCE and WRITE_ONCE APIs for IO queue Tx/Rx variable access to prevent compiler optimization and reordering. Additionally, ensure IO queue OUT/IN_CNT registers are flushed by performing a read-back after writing. The compiler could reorder reads/writes to pkts_pending, last_pkt_count, etc., causing stale values to be used when calculating packets to process or register updates to send to hardware. The Octeon hardware requires a read-back after writing to OUT_CNT/IN_CNT registers to ensure the write has been flushed through any posted write buffers before the interrupt resend bit is set. Without this, we have observed cases where the hardware didn't properly update its internal state. wmb/rmb only provides ordering guarantees but doesn't prevent the compiler from performing optimizations like caching in registers, load tearing etc. Fixes: 1cd3b407977c3 ("octeon_ep_vf: add Tx/Rx processing and interrupt support") Signed-off-by: Sathesh Edara Signed-off-by: Shinas Rasheed Signed-off-by: Vimlesh Kumar Link: https://patch.msgid.link/20260227091402.1773833-5-vimleshk@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 04a9f26d63d9591ed2c65dda4b148307e90a66d2 Author: Vimlesh Kumar Date: Fri Feb 27 09:13:59 2026 +0000 octeon_ep_vf: Relocate counter updates before NAPI [ Upstream commit 2ae7d20fb24f598f60faa8f6ecc856dac782261a ] Relocate IQ/OQ IN/OUT_CNTS updates to occur before NAPI completion. Moving the IQ/OQ counter updates before napi_complete_done ensures 1. Counter registers are updated before re-enabling interrupts. 2. Prevents a race where new packets arrive but counters aren't properly synchronized. Fixes: 1cd3b407977c3 ("octeon_ep_vf: add Tx/Rx processing and interrupt support") Signed-off-by: Sathesh Edara Signed-off-by: Shinas Rasheed Signed-off-by: Vimlesh Kumar Link: https://patch.msgid.link/20260227091402.1773833-4-vimleshk@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 986904ab1613fc5a9521638d3b7cead2c29f8f93 Author: Vimlesh Kumar Date: Fri Feb 27 09:13:58 2026 +0000 octeon_ep: avoid compiler and IQ/OQ reordering [ Upstream commit 43b3160cb639079a15daeb5f080120afbfbfc918 ] Utilize READ_ONCE and WRITE_ONCE APIs for IO queue Tx/Rx variable access to prevent compiler optimization and reordering. Additionally, ensure IO queue OUT/IN_CNT registers are flushed by performing a read-back after writing. The compiler could reorder reads/writes to pkts_pending, last_pkt_count, etc., causing stale values to be used when calculating packets to process or register updates to send to hardware. The Octeon hardware requires a read-back after writing to OUT_CNT/IN_CNT registers to ensure the write has been flushed through any posted write buffers before the interrupt resend bit is set. Without this, we have observed cases where the hardware didn't properly update its internal state. wmb/rmb only provides ordering guarantees but doesn't prevent the compiler from performing optimizations like caching in registers, load tearing etc. Fixes: 37d79d0596062 ("octeon_ep: add Tx/Rx processing and interrupt support") Signed-off-by: Sathesh Edara Signed-off-by: Shinas Rasheed Signed-off-by: Vimlesh Kumar Link: https://patch.msgid.link/20260227091402.1773833-3-vimleshk@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 142a789a51d5fde5d5f63297b459d9b57bfb4065 Author: Vimlesh Kumar Date: Fri Feb 27 09:13:57 2026 +0000 octeon_ep: Relocate counter updates before NAPI [ Upstream commit 18c04a808c436d629d5812ce883e3822a5f5a47f ] Relocate IQ/OQ IN/OUT_CNTS updates to occur before NAPI completion, and replace napi_complete with napi_complete_done. Moving the IQ/OQ counter updates before napi_complete_done ensures 1. Counter registers are updated before re-enabling interrupts. 2. Prevents a race where new packets arrive but counters aren't properly synchronized. napi_complete_done (vs napi_complete) allows for better interrupt coalescing. Fixes: 37d79d0596062 ("octeon_ep: add Tx/Rx processing and interrupt support") Signed-off-by: Sathesh Edara Signed-off-by: Shinas Rasheed Signed-off-by: Vimlesh Kumar Link: https://patch.msgid.link/20260227091402.1773833-2-vimleshk@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 0ace8027e41f6f094ef6c1aca42d2ed6cd7af54e Author: Jiayuan Chen Date: Thu Feb 26 16:03:01 2026 +0800 bpf/bonding: reject vlan+srcmac xmit_hash_policy change when XDP is loaded [ Upstream commit 479d589b40b836442bbdadc3fdb37f001bb67f26 ] bond_option_mode_set() already rejects mode changes that would make a loaded XDP program incompatible via bond_xdp_check(). However, bond_option_xmit_hash_policy_set() has no such guard. For 802.3ad and balance-xor modes, bond_xdp_check() returns false when xmit_hash_policy is vlan+srcmac, because the 802.1q payload is usually absent due to hardware offload. This means a user can: 1. Attach a native XDP program to a bond in 802.3ad/balance-xor mode with a compatible xmit_hash_policy (e.g. layer2+3). 2. Change xmit_hash_policy to vlan+srcmac while XDP remains loaded. This leaves bond->xdp_prog set but bond_xdp_check() now returning false for the same device. When the bond is later destroyed, dev_xdp_uninstall() calls bond_xdp_set(dev, NULL, NULL) to remove the program, which hits the bond_xdp_check() guard and returns -EOPNOTSUPP, triggering: WARN_ON(dev_xdp_install(dev, mode, bpf_op, NULL, 0, NULL)) Fix this by rejecting xmit_hash_policy changes to vlan+srcmac when an XDP program is loaded on a bond in 802.3ad or balance-xor mode. commit 39a0876d595b ("net, bonding: Disallow vlan+srcmac with XDP") introduced bond_xdp_check() which returns false for 802.3ad/balance-xor modes when xmit_hash_policy is vlan+srcmac. The check was wired into bond_xdp_set() to reject XDP attachment with an incompatible policy, but the symmetric path -- preventing xmit_hash_policy from being changed to an incompatible value after XDP is already loaded -- was left unguarded in bond_option_xmit_hash_policy_set(). Note: commit 094ee6017ea0 ("bonding: check xdp prog when set bond mode") later added a similar guard to bond_option_mode_set(), but bond_option_xmit_hash_policy_set() remained unprotected. Reported-by: syzbot+5a287bcdc08104bc3132@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6995aff6.050a0220.2eeac1.014e.GAE@google.com/T/ Fixes: 39a0876d595b ("net, bonding: Disallow vlan+srcmac with XDP") Signed-off-by: Jiayuan Chen Link: https://patch.msgid.link/20260226080306.98766-2-jiayuan.chen@linux.dev Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit d95de5acbf9ede56b7551bf4e91843dd52c66ec0 Author: Mieczyslaw Nalewaj Date: Sun Mar 1 18:13:14 2026 -0300 net: dsa: realtek: rtl8365mb: fix rtl8365mb_phy_ocp_write return value [ Upstream commit 7cbe98f7bef965241a5908d50d557008cf998aee ] Function rtl8365mb_phy_ocp_write() always returns 0, even when an error occurs during register access. This patch fixes the return value to propagate the actual error code from regmap operations. Link: https://lore.kernel.org/netdev/a2dfde3c-d46f-434b-9d16-1e251e449068@yahoo.com/ Fixes: 2796728460b8 ("net: dsa: realtek: rtl8365mb: serialize indirect PHY register access") Signed-off-by: Mieczyslaw Nalewaj Reviewed-by: Andrew Lunn Signed-off-by: Luiz Angelo Daros de Luca Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260301-realtek_namiltd_fix1-v1-1-43a6bb707f9c@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 01f5b85fa0daac7afa3b8fb71aa7146588c8a4fd Author: Shuvam Pandey Date: Thu Feb 26 21:14:10 2026 +0545 kunit: tool: copy caller args in run_kernel to prevent mutation [ Upstream commit 40804c4974b8df2adab72f6475d343eaff72b7f6 ] run_kernel() appended KUnit flags directly to the caller-provided args list. When exec_tests() calls run_kernel() repeatedly (e.g. with --run_isolated), each call mutated the same list, causing later runs to inherit stale filter_glob values and duplicate kunit.enable flags. Fix this by copying args at the start of run_kernel(). Add a regression test that calls run_kernel() twice with the same list and verifies the original remains unchanged. Fixes: ff9e09a3762f ("kunit: tool: support running each suite/test separately") Signed-off-by: Shuvam Pandey Reviewed-by: David Gow Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 3589cc8f56c124a1ea69722c231a52304d6ec0b4 Author: Alexandre Courbot Date: Tue Feb 24 19:37:56 2026 +0900 rust: kunit: fix warning when !CONFIG_PRINTK [ Upstream commit 7dd34dfc8dfa92a7244242098110388367996ac3 ] If `CONFIG_PRINTK` is not set, then the following warnings are issued during build: warning: unused variable: `args` --> ../rust/kernel/kunit.rs:16:12 | 16 | pub fn err(args: fmt::Arguments<'_>) { | ^^^^ help: if this is intentional, prefix it with an underscore: `_args` | = note: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default warning: unused variable: `args` --> ../rust/kernel/kunit.rs:32:13 | 32 | pub fn info(args: fmt::Arguments<'_>) { | ^^^^ help: if this is intentional, prefix it with an underscore: `_args` Fix this by adding a no-op assignment using `args` when `CONFIG_PRINTK` is not set. Fixes: a66d733da801 ("rust: support running Rust documentation tests as KUnit ones") Signed-off-by: Alexandre Courbot Reviewed-by: Alice Ryhl Reviewed-by: David Gow Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 7f971dfd48983074adc7bbcea3ee95ce7aad47cb Author: Shuicheng Lin Date: Wed Feb 25 01:34:49 2026 +0000 drm/xe/configfs: Free ctx_restore_mid_bb in release [ Upstream commit e377182f0266f46f02d01838e6bde67b9dac0d66 ] ctx_restore_mid_bb memory is allocated in wa_bb_store(), but xe_config_device_release() only frees ctx_restore_post_bb. Free ctx_restore_mid_bb[0].cs as well to avoid leaking the allocation when the configfs device is removed. Fixes: b30d5de3d40c ("drm/xe/configfs: Add mid context restore bb") Signed-off-by: Shuicheng Lin Reviewed-by: Nitin Gote Link: https://patch.msgid.link/20260225013448.3547687-2-shuicheng.lin@intel.com Signed-off-by: Matt Roper (cherry picked from commit a235e7d0098337c3f2d1e8f3610c719a589e115f) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 303b446f2e8f9cdebc822f1f72af385374d17d37 Author: Matthew Brost Date: Wed Jan 14 16:45:46 2026 -0800 drm/xe: Do not preempt fence signaling CS instructions [ Upstream commit cdc8a1e11f4d5b480ec750e28010c357185b95a6 ] If a batch buffer is complete, it makes little sense to preempt the fence signaling instructions in the ring, as the largest portion of the work (the batch buffer) is already done and fence signaling consists of only a few instructions. If these instructions are preempted, the GuC would need to perform a context switch just to signal the fence, which is costly and delays fence signaling. Avoid this scenario by disabling preemption immediately after the BB start instruction and re-enabling it after executing the fence signaling instructions. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Daniele Ceraolo Spurio Cc: Carlos Santa Signed-off-by: Matthew Brost Reviewed-by: Daniele Ceraolo Spurio Link: https://patch.msgid.link/20260115004546.58060-1-matthew.brost@intel.com (cherry picked from commit 2bcbf2dcde0c839a73af664a3c77d4e77d58a3eb) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 7196a1ff7b9a2ab6d973fe3c1dfc426d8d8ed4d2 Author: Julian Orth Date: Sun Mar 1 13:34:42 2026 +0100 drm/syncobj: Fix handle <-> fd ioctls with dirty stack [ Upstream commit 2e3649e237237258a08d75afef96648dd2b379f7 ] Consider the following application: #include #include #include #include int main(void) { int fd = open("/dev/dri/renderD128", O_RDWR); struct drm_syncobj_create arg1; ioctl(fd, DRM_IOCTL_SYNCOBJ_CREATE, &arg1); struct drm_syncobj_handle arg2; memset(&arg2, 1, sizeof(arg2)); // simulate dirty stack arg2.handle = arg1.handle; arg2.flags = 0; arg2.fd = 0; arg2.pad = 0; // arg2.point = 0; // userspace is required to set point to 0 ioctl(fd, DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD, &arg2); } The last ioctl returns EINVAL because args->point is not 0. However, userspace developed against older kernel versions is not aware of the new point field and might therefore not initialize it. The correct check would be if (args->flags & DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_TIMELINE) return -EINVAL; However, there might already be userspace that relies on this not returning an error as long as point == 0. Therefore use the more lenient check. Fixes: c2d3a7300695 ("drm/syncobj: Extend EXPORT_SYNC_FILE for timeline syncobjs") Signed-off-by: Julian Orth Reviewed-by: Christian König Signed-off-by: Christian König Link: https://lore.kernel.org/r/20260301-point-v1-1-21fc5fd98614@gmail.com Signed-off-by: Sasha Levin commit 95ed07644b2c6119f706484b87b7f43e6133f3b5 Author: Sebastian Krzyszkowiak Date: Sat Feb 21 17:28:04 2026 +0100 wifi: rsi: Don't default to -EOPNOTSUPP in rsi_mac80211_config [ Upstream commit d973b1039ccde6b241b438d53297edce4de45b5c ] This triggers a WARN_ON in ieee80211_hw_conf_init and isn't the expected behavior from the driver - other drivers default to 0 too. Fixes: 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers") Signed-off-by: Sebastian Krzyszkowiak Link: https://patch.msgid.link/20260221-rsi-config-ret-v1-1-9a8f805e2f31@puri.sm Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit d27f12c3f5e85efc479896af4a69eccb37f75e8e Author: Alban Bedel Date: Mon Feb 9 15:47:05 2026 +0100 can: mcp251x: fix deadlock in error path of mcp251x_open [ Upstream commit ab3f894de216f4a62adc3b57e9191888cbf26885 ] The mcp251x_open() function call free_irq() in its error path with the mpc_lock mutex held. But if an interrupt already occurred the interrupt handler will be waiting for the mpc_lock and free_irq() will deadlock waiting for the handler to finish. This issue is similar to the one fixed in commit 7dd9c26bd6cf ("can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open") but for the error path. To solve this issue move the call to free_irq() after the lock is released. Setting `priv->force_quit = 1` beforehand ensure that the IRQ handler will exit right away once it acquired the lock. Signed-off-by: Alban Bedel Link: https://patch.msgid.link/20260209144706.2261954-1-alban.bedel@lht.dlh.de Fixes: bf66f3736a94 ("can: mcp251x: Move to threaded interrupts instead of workqueues.") Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 8215ba7bc99e84e66fd6938874ec4330a9d96518 Author: Oliver Hartkopp Date: Wed Feb 18 11:58:06 2026 +0100 can: bcm: fix locking for bcm_op runtime updates [ Upstream commit c35636e91e392e1540949bbc67932167cb48bc3a ] Commit c2aba69d0c36 ("can: bcm: add locking for bcm_op runtime updates") added a locking for some variables that can be modified at runtime when updating the sending bcm_op with a new TX_SETUP command in bcm_tx_setup(). Usually the RX_SETUP only handles and filters incoming traffic with one exception: When the RX_RTR_FRAME flag is set a predefined CAN frame is sent when a specific RTR frame is received. Therefore the rx bcm_op uses bcm_can_tx() which uses the bcm_tx_lock that was only initialized in bcm_tx_setup(). Add the missing spin_lock_init() when allocating the bcm_op in bcm_rx_setup() to handle the RTR case properly. Fixes: c2aba69d0c36 ("can: bcm: add locking for bcm_op runtime updates") Reported-by: syzbot+5b11eccc403dd1cea9f8@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-can/699466e4.a70a0220.2c38d7.00ff.GAE@google.com/ Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260218-bcm_spin_lock_init-v1-1-592634c8a5b5@hartkopp.net Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit d8e38dc605c1aa66e4efa92260b75c84a483d2da Author: Raju Rangoju Date: Thu Feb 26 22:37:53 2026 +0530 amd-xgbe: fix MAC_TCR_SS register width for 2.5G and 10M speeds [ Upstream commit 9439a661c2e80485406ce2c90b107ca17858382d ] Extend the MAC_TCR_SS (Speed Select) register field width from 2 bits to 3 bits to properly support all speed settings. The MAC_TCR register's SS field encoding requires 3 bits to represent all supported speeds: - 0x00: 10Gbps (XGMII) - 0x02: 2.5Gbps (GMII) / 100Mbps - 0x03: 1Gbps / 10Mbps - 0x06: 2.5Gbps (XGMII) - P100a only With only 2 bits, values 0x04-0x07 cannot be represented, which breaks 2.5G XGMII mode on newer platforms and causes incorrect speed select values to be programmed. Fixes: 07445f3c7ca1 ("amd-xgbe: Add support for 10 Mbps speed") Co-developed-by: Guruvendra Punugupati Signed-off-by: Guruvendra Punugupati Signed-off-by: Raju Rangoju Link: https://patch.msgid.link/20260226170753.250312-1-Raju.Rangoju@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d5947c3d2d14c75be0437cba9377f01b57cfa297 Author: MD Danish Anwar Date: Thu Feb 26 15:53:56 2026 +0530 net: ti: icssg-prueth: Fix ping failure after offload mode setup when link speed is not 1G [ Upstream commit 147792c395db870756a0dc87ce656c75ae7ab7e8 ] When both eth interfaces with links up are added to a bridge or hsr interface, ping fails if the link speed is not 1Gbps (e.g., 100Mbps). The issue is seen because when switching to offload (bridge/hsr) mode, prueth_emac_restart() restarts the firmware and clears DRAM with memset_io(), setting all memory to 0. This includes PORT_LINK_SPEED_OFFSET which firmware reads for link speed. The value 0 corresponds to FW_LINK_SPEED_1G (0x00), so for 1Gbps links the default value is correct and ping works. For 100Mbps links, the firmware needs FW_LINK_SPEED_100M (0x01) but gets 0 instead, causing ping to fail. The function emac_adjust_link() is called to reconfigure, but it detects no state change (emac->link is still 1, speed/duplex match PHY) so new_state remains false and icssg_config_set_speed() is never called to correct the firmware speed value. The fix resets emac->link to 0 before calling emac_adjust_link() in prueth_emac_common_start(). This forces new_state=true, ensuring icssg_config_set_speed() is called to write the correct speed value to firmware memory. Fixes: 06feac15406f ("net: ti: icssg-prueth: Fix emac link speed handling") Signed-off-by: MD Danish Anwar Link: https://patch.msgid.link/20260226102356.2141871-1-danishanwar@ti.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7ea92ab075d809ec8a96669a5ecf00f752057875 Author: Jiayuan Chen Date: Wed Feb 25 20:32:40 2026 +0800 atm: lec: fix null-ptr-deref in lec_arp_clear_vccs [ Upstream commit 101bacb303e89dc2e0640ae6a5e0fb97c4eb45bb ] syzkaller reported a null-ptr-deref in lec_arp_clear_vccs(). This issue can be easily reproduced using the syzkaller reproducer. In the ATM LANE (LAN Emulation) module, the same atm_vcc can be shared by multiple lec_arp_table entries (e.g., via entry->vcc or entry->recv_vcc). When the underlying VCC is closed, lec_vcc_close() iterates over all ARP entries and calls lec_arp_clear_vccs() for each matched entry. For example, when lec_vcc_close() iterates through the hlists in priv->lec_arp_empty_ones or other ARP tables: 1. In the first iteration, for the first matched ARP entry sharing the VCC, lec_arp_clear_vccs() frees the associated vpriv (which is vcc->user_back) and sets vcc->user_back to NULL. 2. In the second iteration, for the next matched ARP entry sharing the same VCC, lec_arp_clear_vccs() is called again. It obtains a NULL vpriv from vcc->user_back (via LEC_VCC_PRIV(vcc)) and then attempts to dereference it via `vcc->pop = vpriv->old_pop`, leading to a null-ptr-deref crash. Fix this by adding a null check for vpriv before dereferencing it. If vpriv is already NULL, it means the VCC has been cleared by a previous call, so we can safely skip the cleanup and just clear the entry's vcc/recv_vcc pointers. The entire cleanup block (including vcc_release_async()) is placed inside the vpriv guard because a NULL vpriv indicates the VCC has already been fully released by a prior iteration — repeating the teardown would redundantly set flags and trigger callbacks on an already-closing socket. The Fixes tag points to the initial commit because the entry->vcc path has been vulnerable since the original code. The entry->recv_vcc path was later added by commit 8d9f73c0ad2f ("atm: fix a memory leak of vcc->user_back") with the same pattern, and both paths are fixed here. Reported-by: syzbot+72e3ea390c305de0e259@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68c95a83.050a0220.3c6139.0e5c.GAE@google.com/T/ Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Suggested-by: Dan Carpenter Reviewed-by: Simon Horman Signed-off-by: Jiayuan Chen Link: https://patch.msgid.link/20260225123250.189289-1-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 00f42ace446f1e4bf84988f2281131f52cd32796 Author: Guenter Roeck Date: Thu Feb 26 21:58:12 2026 -0800 dpaa2-switch: Fix interrupt storm after receiving bad if_id in IRQ handler [ Upstream commit 74badb9c20b1a9c02a95c735c6d3cd6121679c93 ] Commit 31a7a0bbeb00 ("dpaa2-switch: add bounds check for if_id in IRQ handler") introduces a range check for if_id to avoid an out-of-bounds access. If an out-of-bounds if_id is detected, the interrupt status is not cleared. This may result in an interrupt storm. Clear the interrupt status after detecting an out-of-bounds if_id to avoid the problem. Found by an experimental AI code review agent at Google. Fixes: 31a7a0bbeb00 ("dpaa2-switch: add bounds check for if_id in IRQ handler") Cc: Junrui Luo Signed-off-by: Guenter Roeck Reviewed-by: Ioana Ciornei Link: https://patch.msgid.link/20260227055812.1777915-1-linux@roeck-us.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6a674e0b19b0e508f2683d443a68f090837c593b Author: Nikhil P. Rao Date: Wed Feb 25 00:00:27 2026 +0000 xsk: Fix zero-copy AF_XDP fragment drop [ Upstream commit f7387d6579d65efd490a864254101cb665f2e7a7 ] AF_XDP should ensure that only a complete packet is sent to application. In the zero-copy case, if the Rx queue gets full as fragments are being enqueued, the remaining fragments are dropped. For the multi-buffer case, add a check to ensure that the Rx queue has enough space for all fragments of a packet before starting to enqueue them. Fixes: 24ea50127ecf ("xsk: support mbuf on ZC RX") Signed-off-by: Nikhil P. Rao Link: https://patch.msgid.link/20260225000456.107806-3-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 645c6d8376ad4913cbffe0e0c2cca0c4febbe596 Author: Nikhil P. Rao Date: Wed Feb 25 00:00:26 2026 +0000 xsk: Fix fragment node deletion to prevent buffer leak [ Upstream commit 60abb0ac11dccd6b98fd9182bc5f85b621688861 ] After commit b692bf9a7543 ("xsk: Get rid of xdp_buff_xsk::xskb_list_node"), the list_node field is reused for both the xskb pool list and the buffer free list, this causes a buffer leak as described below. xp_free() checks if a buffer is already on the free list using list_empty(&xskb->list_node). When list_del() is used to remove a node from the xskb pool list, it doesn't reinitialize the node pointers. This means list_empty() will return false even after the node has been removed, causing xp_free() to incorrectly skip adding the buffer to the free list. Fix this by using list_del_init() instead of list_del() in all fragment handling paths, this ensures the list node is reinitialized after removal, allowing the list_empty() to work correctly. Fixes: b692bf9a7543 ("xsk: Get rid of xdp_buff_xsk::xskb_list_node") Acked-by: Maciej Fijalkowski Signed-off-by: Nikhil P. Rao Link: https://patch.msgid.link/20260225000456.107806-2-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2fc623e178545a0805e3387781363f89a113f417 Author: Jakub Kicinski Date: Thu Feb 26 16:33:59 2026 -0800 tcp: give up on stronger sk_rcvbuf checks (for now) [ Upstream commit 026dfef287c07f37d4d4eef7a0b5a4bfdb29b32d ] We hit another corner case which leads to TcpExtTCPRcvQDrop Connections which send RPCs in the 20-80kB range over loopback experience spurious drops. The exact conditions for most of the drops I investigated are that: - socket exchanged >1MB of data so its not completely fresh - rcvbuf is around 128kB (default, hasn't grown) - there is ~60kB of data in rcvq - skb > 64kB arrives The sum of skb->len (!) of both of the skbs (the one already in rcvq and the arriving one) is larger than rwnd. My suspicion is that this happens because __tcp_select_window() rounds the rwnd up to (1 << wscale) if less than half of the rwnd has been consumed. Eric suggests that given the number of Fixes we already have pointing to 1d2fbaad7cd8 it's probably time to give up on it, until a bigger revamp of rmem management. Also while we could risk tweaking the rwnd math, there are other drops on workloads I investigated, after the commit in question, not explained by this phenomenon. Suggested-by: Eric Dumazet Link: https://lore.kernel.org/20260225122355.585fd57b@kernel.org Fixes: 1d2fbaad7cd8 ("tcp: stronger sk_rcvbuf checks") Reviewed-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260227003359.2391017-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b955350778b8715e1b7885179979b3a68221c0fb Author: Kuniyuki Iwashima Date: Fri Feb 27 03:55:35 2026 +0000 udp: Unhash auto-bound connected sk from 4-tuple hash table when disconnected. [ Upstream commit 6996a2d2d0a64808c19c98002aeb5d9d1b2df6a4 ] Let's say we bind() an UDP socket to the wildcard address with a non-zero port, connect() it to an address, and disconnect it from the address. bind() sets SOCK_BINDPORT_LOCK on sk->sk_userlocks (but not SOCK_BINDADDR_LOCK), and connect() calls udp_lib_hash4() to put the socket into the 4-tuple hash table. Then, __udp_disconnect() calls sk->sk_prot->rehash(sk). It computes a new hash based on the wildcard address and moves the socket to a new slot in the 4-tuple hash table, leaving a garbage in the chain that no packet hits. Let's remove such a socket from 4-tuple hash table when disconnected. Note that udp_sk(sk)->udp_portaddr_hash needs to be udpated after udp_hash4_dec(hslot2) in udp_unhash4(). Fixes: 78c91ae2c6de ("ipv4/udp: Add 4-tuple hash for connected socket") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260227035547.3321327-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f5fc6fead2775b7f2dc139fa2b49c54330de3ae0 Author: Eric Dumazet Date: Wed Feb 25 20:35:45 2026 +0000 inet: annotate data-races around isk->inet_num [ Upstream commit 29252397bcc1e0a1f85e5c3bee59c325f5c26341 ] UDP/TCP lookups are using RCU, thus isk->inet_num accesses should use READ_ONCE() and WRITE_ONCE() where needed. Fixes: 3ab5aee7fe84 ("net: Convert TCP & DCCP hash tables to use RCU / hlist_nulls") Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260225203545.1512417-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3d8f35e182c80390f35224af0d7bee924632789a Author: Keith Busch Date: Wed Feb 25 11:38:05 2026 -0800 nvme-multipath: fix leak on try_module_get failure [ Upstream commit 0f5197ea9a73a4c406c75e6d8af3a13f7f96ae89 ] We need to fall back to the synchronous removal if we can't get a reference on the module needed for the deferred removal. Fixes: 62188639ec16 ("nvme-multipath: introduce delayed removal of the multipath head node") Reviewed-by: Nilay Shroff Reviewed-by: John Garry Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 79cc5a4c311f661b1f1f1dc4d925c85aee2879aa Author: Chintan Vankar Date: Tue Feb 24 23:43:59 2026 +0530 net: ethernet: ti: am65-cpsw-nuss/cpsw-ale: Fix multicast entry handling in ALE table [ Upstream commit be11a537224d72b906db6b98510619770298c8a4 ] In the current implementation, flushing multicast entries in MAC mode incorrectly deletes entries for all ports instead of only the target port, disrupting multicast traffic on other ports. The cause is adding multicast entries by setting only host port bit, and not setting the MAC port bits. Fix this by setting the MAC port's bit in the port mask while adding the multicast entry. Also fix the flush logic to preserve the host port bit during removal of MAC port and free ALE entries when mask contains only host port. Fixes: 5c50a856d550 ("drivers: net: ethernet: cpsw: add multicast address to ALE table") Signed-off-by: Chintan Vankar Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260224181359.2055322-1-c-vankar@ti.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f17c1c4acbe2bd702abce73a847a04a196fab2c5 Author: Eric Dumazet Date: Wed Feb 25 13:15:47 2026 +0000 net: annotate data-races around sk->sk_{data_ready,write_space} [ Upstream commit 2ef2b20cf4e04ac8a6ba68493f8780776ff84300 ] skmsg (and probably other layers) are changing these pointers while other cpus might read them concurrently. Add corresponding READ_ONCE()/WRITE_ONCE() annotations for UDP, TCP and AF_UNIX. Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface") Reported-by: syzbot+87f770387a9e5dc6b79b@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/699ee9fc.050a0220.1cd54b.0009.GAE@google.com/ Signed-off-by: Eric Dumazet Cc: Daniel Borkmann Cc: John Fastabend Cc: Jakub Sitnicki Cc: Willem de Bruijn Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260225131547.1085509-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f30b95159a53e72529a9ca1667f11cd1970240a7 Author: Justin Tee Date: Thu Dec 4 12:26:13 2025 -0800 nvmet-fcloop: Check remoteport port_state before calling done callback [ Upstream commit dd677d0598387ea623820ab2bd0e029c377445a3 ] In nvme_fc_handle_ls_rqst_work, the lsrsp->done callback is only set when remoteport->port_state is FC_OBJSTATE_ONLINE. Otherwise, the nvme_fc_xmt_ls_rsp's LLDD call to lport->ops->xmt_ls_rsp is expected to fail and the nvme-fc transport layer itself will directly call nvme_fc_xmt_ls_rsp_free instead of relying on LLDD's done callback to free the lsrsp resources. Update the fcloop_t2h_xmt_ls_rsp routine to check remoteport->port_state. If online, then lsrsp->done callback will free the lsrsp. Else, return -ENODEV to signal the nvme-fc transport to handle freeing lsrsp. Cc: Ewan D. Milne Tested-by: Aristeu Rozanski Acked-by: Aristeu Rozanski Reviewed-by: Daniel Wagner Closes: https://lore.kernel.org/linux-nvme/21255200-a271-4fa0-b099-97755c8acd4c@work/ Fixes: 10c165af35d2 ("nvmet-fcloop: call done callback even when remote port is gone") Signed-off-by: Justin Tee Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 72d08d2839649d1c5efbe375751f4473fa4486af Author: David Howells Date: Thu Feb 26 13:32:33 2026 +0000 netfs: Fix unbuffered/DIO writes to dispatch subrequests in strict sequence [ Upstream commit a0b4c7a49137ed21279f354eb59f49ddae8dffc2 ] Fix netfslib such that when it's making an unbuffered or DIO write, to make sure that it sends each subrequest strictly sequentially, waiting till the previous one is 'committed' before sending the next so that we don't have pieces landing out of order and potentially leaving a hole if an error occurs (ENOSPC for example). This is done by copying in just those bits of issuing, collecting and retrying subrequests that are necessary to do one subrequest at a time. Retrying, in particular, is simpler because if the current subrequest needs retrying, the source iterator can just be copied again and the subrequest prepped and issued again without needing to be concerned about whether it needs merging with the previous or next in the sequence. Note that the issuing loop waits for a subrequest to complete right after issuing it, but this wait could be moved elsewhere allowing preparatory steps to be performed whilst the subrequest is in progress. In particular, once content encryption is available in netfslib, that could be done whilst waiting, as could cleanup of buffers that have been completed. Fixes: 153a9961b551 ("netfs: Implement unbuffered/DIO write support") Signed-off-by: David Howells Link: https://patch.msgid.link/58526.1772112753@warthog.procyon.org.uk Tested-by: Steve French Reviewed-by: Paulo Alcantara (Red Hat) cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 54b3701901afca7dbb55d72b0729af671abb9ab9 Author: Francesco Lavra Date: Tue Feb 10 19:09:32 2026 +0100 drm/solomon: Fix page start when updating rectangle in page addressing mode [ Upstream commit 36d9579fed6c9429aa172f77bd28c58696ce8e2b ] In page addressing mode, the pixel values of a dirty rectangle must be sent to the display controller one page at a time. The range of pages corresponding to a given rectangle is being incorrectly calculated as if the Y value of the top left coordinate of the rectangle was 0. This can result in rectangle updates being displayed on wrong parts of the screen. Fix the above issue by consolidating the start page calculation in a single place at the beginning of the update_rect function, and using the calculated value for all addressing modes. Fixes: b0daaa5cfaa5 ("drm/ssd130x: Support page addressing mode") Signed-off-by: Francesco Lavra Reviewed-by: Javier Martinez Canillas Link: https://patch.msgid.link/20260210180932.736502-1-flavra@baylibre.com Signed-off-by: Javier Martinez Canillas Signed-off-by: Sasha Levin commit ee8e4b7469b47999bb634c9afaa41880bfb7843f Author: Vitaly Lifshits Date: Tue Jan 6 16:14:20 2026 +0200 e1000e: clear DPG_EN after reset to avoid autonomous power-gating [ Upstream commit 0942fc6d324eb9c6b16187b2aa994c0823557f06 ] Panther Lake systems introduced an autonomous power gating feature for the integrated Gigabit Ethernet in shutdown state (S5) state. As part of it, the reset value of DPG_EN bit was changed to 1. Clear this bit after performing hardware reset to avoid errors such as Tx/Rx hangs, or packet loss/corruption. Fixes: 0c9183ce61bc ("e1000e: Add support for the next LOM generation") Signed-off-by: Vitaly Lifshits Reviewed-by: Aleksandr Loktionov Tested-by: Avigail Dahan Reviewed-by: Paul Menzel Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 9e0f091821571f0da387462803ee42f0bb157582 Author: Thomas Gleixner Date: Sat Feb 7 11:50:23 2026 +0100 i40e: Fix preempt count leak in napi poll tracepoint [ Upstream commit 4b3d54a85bd37ebf2d9836f0d0de775c0ff21af9 ] Using get_cpu() in the tracepoint assignment causes an obvious preempt count leak because nothing invokes put_cpu() to undo it: softirq: huh, entered softirq 3 NET_RX with preempt_count 00000100, exited with 00000101? This clearly has seen a lot of testing in the last 3+ years... Use smp_processor_id() instead. Fixes: 6d4d584a7ea8 ("i40e: Add i40e_napi_poll tracepoint") Signed-off-by: Thomas Gleixner Cc: Tony Nguyen Cc: Przemek Kitszel Cc: intel-wired-lan@lists.osuosl.org Cc: netdev@vger.kernel.org Reviewed-by: Joe Damato Reviewed-by: Aleksandr Loktionov Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit e9669c2d0535f241ffa9511e5127f1defd6f61db Author: Aaron Ma Date: Thu Jan 29 12:00:26 2026 +0800 ice: recap the VSI and QoS info after rebuild [ Upstream commit 6aa07e23dd3ccd35a0100c06fcb6b6c3b01e7965 ] Fix IRDMA hardware initialization timeout (-110) after resume by separating VSI-dependent configuration from RDMA resource allocation, ensuring VSI is rebuilt before IRDMA accesses it. After resume from suspend, IRDMA hardware initialization fails: ice: IRDMA hardware initialization FAILED init_state=4 status=-110 Separate RDMA initialization into two phases: 1. ice_init_rdma() - Allocate resources only (no VSI/QoS access, no plug) 2. ice_rdma_finalize_setup() - Assign VSI/QoS info and plug device This allows: - ice_init_rdma() to stay in ice_resume() (mirrors ice_deinit_rdma() in ice_suspend()) - VSI assignment deferred until after ice_vsi_rebuild() completes - QoS info updated after ice_dcb_rebuild() completes - Device plugged only when control queues, VSI, and DCB are all ready Fixes: bc69ad74867db ("ice: avoid IRQ collision to fix init failure on ACPI S3 resume") Reviewed-by: Aleksandr Loktionov Signed-off-by: Aaron Ma Reviewed-by: Simon Horman Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 4458f9f198f5effcc0879cd8ec2f3aa8b20f6707 Author: Sreedevi Joshi Date: Tue Jan 13 12:01:13 2026 -0600 idpf: Fix flow rule delete failure due to invalid validation [ Upstream commit 2c31557336a8e4d209ed8d4513cef2c0f15e7ef4 ] When deleting a flow rule using "ethtool -N delete ", idpf_sideband_action_ena() incorrectly validates fsp->ring_cookie even though ethtool doesn't populate this field for delete operations. The uninitialized ring_cookie may randomly match RX_CLS_FLOW_DISC or RX_CLS_FLOW_WAKE, causing validation to fail and preventing legitimate rule deletions. Remove the unnecessary sideband action enable check and ring_cookie validation during delete operations since action validation is not required when removing existing rules. Fixes: ada3e24b84a0 ("idpf: add flow steering support") Signed-off-by: Sreedevi Joshi Reviewed-by: Aleksandr Loktionov Reviewed-by: Simon Horman Reviewed-by: Paul Menzel Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit e7fca8b7fb6fae1a5c3a82b39da192e2dcb062bc Author: Brian Vazquez Date: Mon Jan 26 21:55:59 2026 +0000 idpf: change IRQ naming to match netdev and ethtool queue numbering [ Upstream commit 1500a8662d2d41d6bb03e034de45ddfe6d7d362d ] The code uses the vidx for the IRQ name but that doesn't match ethtool reporting nor netdev naming, this makes it hard to tune the device and associate queues with IRQs. Sequentially requesting irqs starting from '0' makes the output consistent. This commit changes the interrupt numbering but preserves the name format, maintaining ABI compatibility. Existing tools relying on the old numbering are already non-functional, as they lack a useful correlation to the interrupts. Before: ethtool -L eth1 tx 1 combined 3 grep . /proc/irq/*/*idpf*/../smp_affinity_list /proc/irq/67/idpf-Mailbox-0/../smp_affinity_list:0-55,112-167 /proc/irq/68/idpf-eth1-TxRx-1/../smp_affinity_list:0 /proc/irq/70/idpf-eth1-TxRx-3/../smp_affinity_list:1 /proc/irq/71/idpf-eth1-TxRx-4/../smp_affinity_list:2 /proc/irq/72/idpf-eth1-Tx-5/../smp_affinity_list:3 ethtool -S eth1 | grep -v ': 0' NIC statistics: tx_q-0_pkts: 1002 tx_q-1_pkts: 2679 tx_q-2_pkts: 1113 tx_q-3_pkts: 1192 <----- tx_q-3 vs idpf-eth1-Tx-5 rx_q-0_pkts: 1143 rx_q-1_pkts: 3172 rx_q-2_pkts: 1074 After: ethtool -L eth1 tx 1 combined 3 grep . /proc/irq/*/*idpf*/../smp_affinity_list /proc/irq/67/idpf-Mailbox-0/../smp_affinity_list:0-55,112-167 /proc/irq/68/idpf-eth1-TxRx-0/../smp_affinity_list:0 /proc/irq/70/idpf-eth1-TxRx-1/../smp_affinity_list:1 /proc/irq/71/idpf-eth1-TxRx-2/../smp_affinity_list:2 /proc/irq/72/idpf-eth1-Tx-3/../smp_affinity_list:3 ethtool -S eth1 | grep -v ': 0' NIC statistics: tx_q-0_pkts: 118 tx_q-1_pkts: 134 tx_q-2_pkts: 228 tx_q-3_pkts: 138 <--- tx_q-3 matches idpf-eth1-Tx-3 rx_q-0_pkts: 111 rx_q-1_pkts: 366 rx_q-2_pkts: 120 Fixes: d4d558718266 ("idpf: initialize interrupts and enable vport") Signed-off-by: Brian Vazquez Reviewed-by: Brett Creeley Reviewed-by: Aleksandr Loktionov Reviewed-by: Paul Menzel Reviewed-by: Eric Dumazet Tested-by: Samuel Salin Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 8f742f495ddbd9a87c467224bf1edcb997b63b34 Author: Li Li Date: Mon Jan 5 06:47:28 2026 +0000 idpf: increment completion queue next_to_clean in sw marker wait routine [ Upstream commit 712896ac4bce38a965a1c175f6e7804ed0381334 ] Currently, in idpf_wait_for_sw_marker_completion(), when an IDPF_TXD_COMPLT_SW_MARKER packet is found, the routine breaks out of the for loop and does not increment the next_to_clean counter. This causes the subsequent NAPI polls to run into the same IDPF_TXD_COMPLT_SW_MARKER packet again and print out the following: [ 23.261341] idpf 0000:05:00.0 eth1: Unknown TX completion type: 5 Instead, we should increment next_to_clean regardless when an IDPF_TXD_COMPLT_SW_MARKER packet is found. Tested: with the patch applied, we do not see the errors above from NAPI polls anymore. Fixes: 9d39447051a0 ("idpf: remove SW marker handling from NAPI") Signed-off-by: Li Li Reviewed-by: Aleksandr Loktionov Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit d146275655bbd1bb0aa21bbb5bcb68c44b177023 Author: Bart Van Assche Date: Mon Feb 23 14:00:14 2026 -0800 hwmon: (it87) Check the it87_lock() return value [ Upstream commit 07ed4f05bbfd2bc014974dcc4297fd3aa1cb88c0 ] Return early in it87_resume() if it87_lock() fails instead of ignoring the return value of that function. This patch suppresses a Clang thread-safety warning. Cc: Frank Crawford Cc: Guenter Roeck Cc: Jean Delvare Cc: linux-hwmon@vger.kernel.org Fixes: 376e1a937b30 ("hwmon: (it87) Add calls to smbus_enable/smbus_disable as required") Signed-off-by: Bart Van Assche Link: https://lore.kernel.org/r/20260223220102.2158611-15-bart.vanassche@linux.dev [groeck: Declare 'ret' at the beginning of it87_resume()] Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit ea07fcfbba4301839db3784f09955d9fa3e98090 Author: Felix Gu Date: Mon Feb 23 17:39:07 2026 +0800 pinctrl: cirrus: cs42l43: Fix double-put in cs42l43_pin_probe() [ Upstream commit fd5bed798f45eb3a178ad527b43ab92705faaf8a ] devm_add_action_or_reset() already invokes the action on failure, so the explicit put causes a double-put. Fixes: 9b07cdf86a0b ("pinctrl: cirrus: Fix fwnode leak in cs42l43_pin_probe()") Signed-off-by: Felix Gu Reviewed-by: Charles Keepax Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit acbcfe2f8e646cf0608321418bb5abacd707140b Author: Felix Gu Date: Thu Feb 19 00:51:22 2026 +0800 pinctrl: meson: amlogic-a4: Fix device node reference leak in aml_dt_node_to_map_pinmux() [ Upstream commit a2539b92e4b791c1ba482930b5e51b1591975461 ] The of_get_parent() function returns a device_node with an incremented reference count. Use the __free(device_node) cleanup attribute to ensure of_node_put() is automatically called when pnode goes out of scope, fixing a reference leak. Fixes: 6e9be3abb78c ("pinctrl: Add driver support for Amlogic SoCs") Signed-off-by: Felix Gu Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 6359d2d52c95f63f3cc1fd52ba06db8cecf69c5d Author: Conor Dooley Date: Tue Feb 3 16:17:07 2026 +0000 pinctrl: generic: move function to amlogic-am4 driver [ Upstream commit 9c5a40f2922a5a6d6b42e7b3d4c8e253918c07a1 ] pinconf_generic_dt_node_to_map_pinmux() is not actually a generic function, and really belongs in the amlogic-am4 driver. There are three reasons why. First, and least, of the reasons is that this function behaves differently to the other dt_node_to_map functions in a way that is not obvious from a first glance. This difference stems for the devicetree properties that the function is intended for use with, and how they are typically used. The other generic dt_node_to_map functions support platforms where the pins, groups and functions are described statically in the driver and require a function that will produce a mapping from dt nodes to these pre-established descriptions. No other code in the driver is require to be executed at runtime. pinconf_generic_dt_node_to_map_pinmux() on the other hand is intended for use with the pinmux property, where groups and functions are determined entirely from the devicetree. As a result, there are no statically defined groups and functions in the driver for this function to perform a mapping to. Other drivers that use the pinmux property (e.g. the k1) their dt_node_to_map function creates the groups and functions as the devicetree is parsed. Instead of that, pinconf_generic_dt_node_to_map_pinmux() requires that the devicetree is parsed twice, once by it and once at probe, so that the driver dynamically creates the groups and functions before the dt_node_to_map callback is executed. I don't believe this double parsing requirement is how developers would expect this to work and is not necessary given there are drivers that do not have this behaviour. Secondly and thirdly, the function bakes in some assumptions that only really match the amlogic platform about how the devicetree is constructed. These, to me, are problematic for something that claims to be generic. The other dt_node_to_map implementations accept a being called for either a node containing pin configuration properties or a node containing child nodes that each contain the configuration properties. IOW, they support the following two devicetree configurations: | cfg { | label: group { | pinmux = ; | config-item1; | }; | }; | label: cfg { | group1 { | pinmux = ; | config-item2; | }; | group2 { | pinmux = ; | config-item1; | }; | }; pinconf_generic_dt_node_to_map_pinmux() only supports the latter. The other assumption about devicetree configuration that the function makes is that the labeled node's parent is a "function node". The amlogic driver uses these "function nodes" to create the functions at probe time, and pinconf_generic_dt_node_to_map_pinmux() finds the parent of the node it is operating on's name as part of the mapping. IOW, it requires that the devicetree look like: | pinctrl@bla { | | func-foo { | label: group-default { | pinmuxes = ; | }; | }; | }; and couldn't be used if the nodes containing the pinmux and configuration properties are children of the pinctrl node itself: | pinctrl@bla { | | label: group-default { | pinmuxes = ; | }; | }; These final two reasons are mainly why I believe this is not suitable as a generic function, and should be moved into the driver that is the sole user and originator of the "generic" function. Signed-off-by: Conor Dooley Acked-by: Andy Shevchenko Signed-off-by: Linus Walleij Stable-dep-of: a2539b92e4b7 ("pinctrl: meson: amlogic-a4: Fix device node reference leak in aml_dt_node_to_map_pinmux()") Signed-off-by: Sasha Levin commit 2c091292ca421f1f5f47f7899d746856f88c9cd0 Author: Ian Ray Date: Tue Feb 17 13:51:51 2026 +0200 HID: multitouch: new class MT_CLS_EGALAX_P80H84 [ Upstream commit a2e70a89fa58133521b2deae4427d35776bda935 ] Fixes: f9e82295eec1 ("HID: multitouch: add eGalaxTouch P80H84 support") Signed-off-by: Ian Ray Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit ade03840f829dd01790c68abbe8f59c1cf3a3286 Author: Petr Pavlu Date: Wed Jan 7 13:22:57 2026 +0100 module: Remove duplicate freeing of lockdep classes [ Upstream commit a7b4bc094fbaa7dc7b7b91ae33549bbd7eefaac1 ] In the error path of load_module(), under the free_module label, the code calls lockdep_free_key_range() to release lock classes associated with the MOD_DATA, MOD_RODATA and MOD_RO_AFTER_INIT module regions, and subsequently invokes module_deallocate(). Since commit ac3b43283923 ("module: replace module_layout with module_memory"), the module_deallocate() function calls free_mod_mem(), which releases the lock classes as well and considers all module regions. Attempting to free these classes twice is unnecessary. Remove the redundant code in load_module(). Fixes: ac3b43283923 ("module: replace module_layout with module_memory") Signed-off-by: Petr Pavlu Reviewed-by: Daniel Gomez Reviewed-by: Aaron Tomlin Acked-by: Song Liu Acked-by: Peter Zijlstra (Intel) Signed-off-by: Sami Tolvanen Signed-off-by: Sasha Levin commit 55aefe1647a6a6a379b3b975790e8cbb8d61281f Author: Jonathan Teh Date: Mon Feb 16 01:01:29 2026 +0000 platform/x86: thinkpad_acpi: Fix errors reading battery thresholds [ Upstream commit 53e977b1d50c46f2c4ec3865cd13a822f58ad3cd ] Check whether the battery supports the relevant charge threshold before reading the value to silence these errors: thinkpad_acpi: acpi_evalf(BCTG, dd, ...) failed: AE_NOT_FOUND ACPI: \_SB_.PCI0.LPC_.EC__.HKEY: BCTG: evaluate failed thinkpad_acpi: acpi_evalf(BCSG, dd, ...) failed: AE_NOT_FOUND ACPI: \_SB_.PCI0.LPC_.EC__.HKEY: BCSG: evaluate failed when reading the charge thresholds via sysfs on platforms that do not support them such as the ThinkPad T400. Fixes: 2801b9683f74 ("thinkpad_acpi: Add support for battery thresholds") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=202619 Signed-off-by: Jonathan Teh Reviewed-by: Mark Pearson Link: https://patch.msgid.link/MI0P293MB01967B206E1CA6F337EBFB12926CA@MI0P293MB0196.ITAP293.PROD.OUTLOOK.COM Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 82f1bb0ad480f7cc53ff160b230cfdd1b5e8c863 Author: Maulik Shah Date: Mon Feb 9 09:33:44 2026 +0530 pinctrl: qcom: qcs615: Add missing dual edge GPIO IRQ errata flag [ Upstream commit 09a30b7a035f9f4ac918c8a9af89d70e43462152 ] Wakeup capable GPIOs uses PDC as parent IRQ chip and PDC on qcs615 do not support dual edge IRQs. Add missing wakeirq_dual_edge_errata configuration to enable workaround for dual edge GPIO IRQs. Fixes: b698f36a9d40 ("pinctrl: qcom: add the tlmm driver for QCS615 platform") Signed-off-by: Maulik Shah Reviewed-by: Dmitry Baryshkov Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 53eba152810ef0fff8567b13ea0f62d48e62df6b Author: Florian Eckert Date: Thu Feb 5 13:55:46 2026 +0100 pinctrl: equilibrium: fix warning trace on load [ Upstream commit 3e00b1b332e54ba50cca6691f628b9c06574024f ] The callback functions 'eqbr_irq_mask()' and 'eqbr_irq_ack()' are also called in the callback function 'eqbr_irq_mask_ack()'. This is done to avoid source code duplication. The problem, is that in the function 'eqbr_irq_mask()' also calles the gpiolib function 'gpiochip_disable_irq()' This generates the following warning trace in the log for every gpio on load. [ 6.088111] ------------[ cut here ]------------ [ 6.092440] WARNING: CPU: 3 PID: 1 at drivers/gpio/gpiolib.c:3810 gpiochip_disable_irq+0x39/0x50 [ 6.097847] Modules linked in: [ 6.097847] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.12.59+ #0 [ 6.097847] Tainted: [W]=WARN [ 6.097847] RIP: 0010:gpiochip_disable_irq+0x39/0x50 [ 6.097847] Code: 39 c6 48 19 c0 21 c6 48 c1 e6 05 48 03 b2 38 03 00 00 48 81 fe 00 f0 ff ff 77 11 48 8b 46 08 f6 c4 02 74 06 f0 80 66 09 fb c3 <0f> 0b 90 0f 1f 40 00 c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 [ 6.097847] RSP: 0000:ffffc9000000b830 EFLAGS: 00010046 [ 6.097847] RAX: 0000000000000045 RBX: ffff888001be02a0 RCX: 0000000000000008 [ 6.097847] RDX: ffff888001be9000 RSI: ffff888001b2dd00 RDI: ffff888001be02a0 [ 6.097847] RBP: ffffc9000000b860 R08: 0000000000000000 R09: 0000000000000000 [ 6.097847] R10: 0000000000000001 R11: ffff888001b2a154 R12: ffff888001be0514 [ 6.097847] R13: ffff888001be02a0 R14: 0000000000000008 R15: 0000000000000000 [ 6.097847] FS: 0000000000000000(0000) GS:ffff888041d80000(0000) knlGS:0000000000000000 [ 6.097847] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.097847] CR2: 0000000000000000 CR3: 0000000003030000 CR4: 00000000001026b0 [ 6.097847] Call Trace: [ 6.097847] [ 6.097847] ? eqbr_irq_mask+0x63/0x70 [ 6.097847] ? no_action+0x10/0x10 [ 6.097847] eqbr_irq_mask_ack+0x11/0x60 In an other driver (drivers/pinctrl/starfive/pinctrl-starfive-jh7100.c) the interrupt is not disabled here. To fix this, do not call the 'eqbr_irq_mask()' and 'eqbr_irq_ack()' function. Implement instead this directly without disabling the interrupts. Fixes: 52066a53bd11 ("pinctrl: equilibrium: Convert to immutable irq_chip") Signed-off-by: Florian Eckert Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 2c947684bdaaacb3ff63492b363dcf1edd292ce8 Author: Florian Eckert Date: Thu Feb 5 13:55:45 2026 +0100 pinctrl: equilibrium: rename irq_chip function callbacks [ Upstream commit 1f96b84835eafb3e6f366dc3a66c0e69504cec9d ] Renaming of the irq_chip callback functions to improve clarity. Signed-off-by: Florian Eckert Signed-off-by: Linus Walleij Stable-dep-of: 3e00b1b332e5 ("pinctrl: equilibrium: fix warning trace on load") Signed-off-by: Sasha Levin commit 9833ed224aad8c305aec9ce4a94d2ec6d498bc14 Author: Hao Yu Date: Mon Feb 23 01:03:31 2026 +0800 hwmon: (aht10) Fix initialization commands for AHT20 [ Upstream commit b7497b5a99f54ab8dcda5b14a308385b2fb03d8d ] According to the AHT20 datasheet (updated to V1.0 after the 2023.09 version), the initialization command for AHT20 is 0b10111110 (0xBE). The previous sequence (0xE1) used in earlier versions is no longer compatible with newer AHT20 sensors. Update the initialization command to ensure the sensor is properly initialized. While at it, use binary notation for DHT20_CMD_INIT to match the notation used in the datasheet. Fixes: d2abcb5cc885 ("hwmon: (aht10) Add support for compatible aht20") Signed-off-by: Hao Yu Link: https://lore.kernel.org/r/20260222170332.1616-3-haoyufine@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 9c1984180260b81650e075ab30d57e800f6a6fd2 Author: Akhilesh Patil Date: Sun Nov 2 15:13:20 2025 +0530 hwmon: (aht10) Add support for dht20 [ Upstream commit 3eaf1b631506e8de2cb37c278d5bc042521e82c1 ] Add support for dht20 temperature and humidity sensor from Aosong. Modify aht10 driver to handle different init command for dht20 sensor by adding init_cmd entry in the driver data. dht20 sensor is compatible with aht10 hwmon driver with this change. Tested on TI am62x SK board with dht20 sensor connected at i2c-2 port. Signed-off-by: Akhilesh Patil Link: https://lore.kernel.org/r/2025112-94320-906858@bhairav-test.ee.iitb.ac.in Signed-off-by: Guenter Roeck Stable-dep-of: b7497b5a99f5 ("hwmon: (aht10) Fix initialization commands for AHT20") Signed-off-by: Sasha Levin commit e159eb852aeee95443a9458ecb7d072bbb689913 Author: Ming Lei Date: Sat Jan 31 22:48:08 2026 +0800 nvme: fix admin queue leak on controller reset [ Upstream commit b84bb7bd913d8ca2f976ee6faf4a174f91c02b8d ] When nvme_alloc_admin_tag_set() is called during a controller reset, a previous admin queue may still exist. Release it properly before allocating a new one to avoid orphaning the old queue. This fixes a regression introduced by commit 03b3bcd319b3 ("nvme: fix admin request_queue lifetime"). Cc: Keith Busch Fixes: 03b3bcd319b3 ("nvme: fix admin request_queue lifetime"). Reported-and-tested-by: Yi Zhang Closes: https://lore.kernel.org/linux-block/CAHj4cs9wv3SdPo+N01Fw2SHBYDs9tj2M_e1-GdQOkRy=DsBB1w@mail.gmail.com/ Signed-off-by: Ming Lei Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 0381584929791c4b989fb0a36a466ae20aea1608 Author: Natalie Vock Date: Mon Feb 23 12:45:37 2026 +0100 drm/amd/display: Use GFP_ATOMIC in dc_create_stream_for_sink commit 28dfe4317541e57fe52f9a290394cd29c348228b upstream. This can be called while preemption is disabled, for example by dcn32_internal_validate_bw which is called with the FPU active. Fixes "BUG: scheduling while atomic" messages I encounter on my Navi31 machine. Signed-off-by: Natalie Vock Signed-off-by: Alex Deucher (cherry picked from commit b42dae2ebc5c84a68de63ec4ffdfec49362d53f1) Cc: stable@vger.kernel.org [ Context ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a5c070aaf796fef8b2bd2474c716a9d50c064e2f Author: Mariusz Skamra Date: Thu Feb 12 14:46:46 2026 +0100 Bluetooth: Fix CIS host feature condition commit 7cff9a40c6b0f72ccefdaf0ffe03cfac30348f51 upstream. This fixes the condition for sending the LE Set Host Feature command. The command is sent to indicate host support for Connected Isochronous Streams in this case. It has been observed that the system could not initialize BIS-only capable controllers because the controllers do not support the command. As per Core v6.2 | Vol 4, Part E, Table 3.1 the command shall be supported if CIS Central or CIS Peripheral is supported; otherwise, the command is optional. Fixes: 709788b154ca ("Bluetooth: hci_core: Fix using {cis,bis}_capable for current settings") Cc: stable@vger.kernel.org Signed-off-by: Mariusz Skamra Reviewed-by: Paul Menzel Signed-off-by: Luiz Augusto von Dentz [ iso_capable() => cis_capable() ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d8a286503553de6a1abdcac7fd506b0fa5d0ce82 Author: Russell King (Oracle) Date: Tue Feb 3 16:50:41 2026 +0000 net: stmmac: remove support for lpi_intr_o commit 14eb64db8ff07b58a35b98375f446d9e20765674 upstream. The dwmac databook for v3.74a states that lpi_intr_o is a sideband signal which should be used to ungate the application clock, and this signal is synchronous to the receive clock. The receive clock can run at 2.5, 25 or 125MHz depending on the media speed, and can stop under the control of the link partner. This means that the time it takes to clear is dependent on the negotiated media speed, and thus can be 8, 40, or 400ns after reading the LPI control and status register. It has been observed with some aggressive link partners, this clock can stop while lpi_intr_o is still asserted, meaning that the signal remains asserted for an indefinite period that the local system has no direct control over. The LPI interrupts will still be signalled through the main interrupt path in any case, and this path is not dependent on the receive clock. This, since we do not gate the application clock, and the chances of adding clock gating in the future are slim due to the clocks being ill-defined, lpi_intr_o serves no useful purpose. Remove the code which requests the interrupt, and all associated code. Reported-by: Ovidiu Panait Tested-by: Ovidiu Panait # Renesas RZ/V2H board Signed-off-by: Russell King (Oracle) Link: https://patch.msgid.link/E1vnJbt-00000007YYN-28nm@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman commit 999ff1af649cba1d6190cbc48317cc43f8211893 Author: Mario Limonciello Date: Mon Mar 9 07:24:45 2026 -0400 platform/x86: hp-bioscfg: Support allocations of larger data [ Upstream commit 916727cfdb72cd01fef3fa6746e648f8cb70e713 ] Some systems have much larger amounts of enumeration attributes than have been previously encountered. This can lead to page allocation failures when using kcalloc(). Switch over to using kvcalloc() to allow larger allocations. Fixes: 6b2770bfd6f92 ("platform/x86: hp-bioscfg: enum-attributes") Cc: stable@vger.kernel.org Reported-by: Paul Kerry Tested-by: Paul Kerry Closes: https://bugs.debian.org/1127612 Signed-off-by: Mario Limonciello Link: https://patch.msgid.link/20260225210646.59381-1-mario.limonciello@amd.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen [ kcalloc() => kvcalloc() ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0c578e8065c4b08d5635a4cbc0f6321df9d20f79 Author: Fedor Pchelkin Date: Tue Feb 24 20:49:44 2026 -0500 ksmbd: call ksmbd_vfs_kern_path_end_removing() on some error paths [ Upstream commit a09dc10d1353f0e92c21eae2a79af1c2b1ddcde8 ] There are two places where ksmbd_vfs_kern_path_end_removing() needs to be called in order to balance what the corresponding successful call to ksmbd_vfs_kern_path_start_removing() has done, i.e. drop inode locks and put the taken references. Otherwise there might be potential deadlocks and unbalanced locks which are caught like: BUG: workqueue leaked lock or atomic: kworker/5:21/0x00000000/7596 last function: handle_ksmbd_work 2 locks held by kworker/5:21/7596: #0: ffff8881051ae448 (sb_writers#3){.+.+}-{0:0}, at: ksmbd_vfs_kern_path_locked+0x142/0x660 #1: ffff888130e966c0 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: ksmbd_vfs_kern_path_locked+0x17d/0x660 CPU: 5 PID: 7596 Comm: kworker/5:21 Not tainted 6.1.162-00456-gc29b353f383b #138 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 Workqueue: ksmbd-io handle_ksmbd_work Call Trace: dump_stack_lvl+0x44/0x5b process_one_work.cold+0x57/0x5c worker_thread+0x82/0x600 kthread+0x153/0x190 ret_from_fork+0x22/0x30 Found by Linux Verification Center (linuxtesting.org). Fixes: d5fc1400a34b ("smb/server: avoid deadlock when linking with ReplaceIfExists") Cc: stable@vger.kernel.org Signed-off-by: Fedor Pchelkin Acked-by: Namjae Jeon Signed-off-by: Steve French [ ksmbd_vfs_kern_path_end_removing() -> ksmbd_vfs_kern_path_unlock() ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c08ec55617cb9674a060a3392ea08391ab2a4f74 Author: Corey Minyard Date: Tue Jan 27 07:22:35 2026 -0600 ipmi: Fix use-after-free and list corruption on sender error commit 594c11d0e1d445f580898a2b8c850f2e3f099368 upstream. The analysis from Breno: When the SMI sender returns an error, smi_work() delivers an error response but then jumps back to restart without cleaning up properly: 1. intf->curr_msg is not cleared, so no new message is pulled 2. newmsg still points to the message, causing sender() to be called again with the same message 3. If sender() fails again, deliver_err_response() is called with the same recv_msg that was already queued for delivery This causes list_add corruption ("list_add double add") because the recv_msg is added to the user_msgs list twice. Subsequently, the corrupted list leads to use-after-free when the memory is freed and reused, and eventually a NULL pointer dereference when accessing recv_msg->done. The buggy sequence: sender() fails -> deliver_err_response(recv_msg) // recv_msg queued for delivery -> goto restart // curr_msg not cleared! sender() fails again (same message!) -> deliver_err_response(recv_msg) // tries to queue same recv_msg -> LIST CORRUPTION Fix this by freeing the message and setting it to NULL on a send error. Also, always free the newmsg on a send error, otherwise it will leak. Reported-by: Breno Leitao Closes: https://lore.kernel.org/lkml/20260127-ipmi-v1-0-ba5cc90f516f@debian.org/ Fixes: 9cf93a8fa9513 ("ipmi: Allow an SMI sender to return an error") Cc: stable@vger.kernel.org # 4.18 Reviewed-by: Breno Leitao Signed-off-by: Corey Minyard Signed-off-by: Breno Leitao Signed-off-by: Greg Kroah-Hartman commit 3c3462e9ae3548fefe7bcf9bd7852b1122c3e62c Author: Alexander Stein Date: Tue Dec 16 09:49:30 2025 +0100 ASoC: fsl_xcvr: provide regmap names commit 08fd332eeb88515af4f1892d91f6ef4ea7558b71 upstream. This driver uses multiple regmaps, which will causes name conflicts in debugfs like: debugfs: '30cc0000.xcvr' already exists in 'regmap' Fix this by adding a name for the non-core regmap configurations. Signed-off-by: Alexander Stein Link: https://patch.msgid.link/20251216084931.553328-1-alexander.stein@ew.tq-group.com Signed-off-by: Mark Brown Signed-off-by: Fabio Estevam Signed-off-by: Greg Kroah-Hartman commit 227eb258c2cbe1c51275daea4cdb958a2bf21cbc Author: Alexander Stein Date: Tue Nov 25 11:13:33 2025 +0100 ASoC: fsl_xcvr: use dev_err_probe() replacing dev_err() + return commit 8ae28d04593a5fdddb16d3edcdabb8d1e4330d0b upstream. Use dev_err_probe() to simplify the code. This also silences -517 errors. Signed-off-by: Alexander Stein Link: https://patch.msgid.link/20251125101334.1596381-1-alexander.stein@ew.tq-group.com Signed-off-by: Mark Brown Signed-off-by: Fabio Estevam Signed-off-by: Greg Kroah-Hartman commit 3d46af0f8b288755d643385b502199f172d62ad6 Author: Thomas Weißschuh Date: Fri Feb 13 08:39:29 2026 +0100 ARM: clean up the memset64() C wrapper commit b52343d1cb47bb27ca32a3f4952cc2fd3cd165bf upstream. The current logic to split the 64-bit argument into its 32-bit halves is byte-order specific and a bit clunky. Use a union instead which is easier to read and works in all cases. GCC still generates the same machine code. While at it, rename the arguments of the __memset64() prototype to actually reflect their semantics. Signed-off-by: Thomas Weißschuh Signed-off-by: Linus Torvalds Reported-by: Ben Hutchings # for -stable Link: https://lore.kernel.org/all/1a11526ae3d8664f705b541b8d6ea57b847b49a8.camel@decadent.org.uk/ Suggested-by: https://lore.kernel.org/all/aZonkWMwpbFhzDJq@casper.infradead.org/ # for -stable Link: https://lore.kernel.org/all/aZonkWMwpbFhzDJq@casper.infradead.org/ Signed-off-by: Greg Kroah-Hartman commit 54e841a036064fd504eb609d4910b775a92d00cb Author: Greg Kroah-Hartman Date: Mon Mar 9 14:30:49 2026 +0100 Revert "netfilter: nft_set_rbtree: validate open interval overlap" This reverts commit 12b1681793e9b7552495290785a3570c539f409d which is commit 648946966a08e4cb1a71619e3d1b12bd7642de7b upstream. It is causing netfilter issues, so revert it for now. Link: https://lore.kernel.org/r/aaeEd8UqYQ33Af7_@chamomile Cc: Pablo Neira Ayuso Cc: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit 861aa1be41bc1ba3e13ef6a6f0b58a0626012fc4 Author: Nathan Chancellor Date: Wed Feb 25 15:02:51 2026 -0700 kbuild: Split .modinfo out from ELF_DETAILS commit 8678591b47469fe16357234efef9b260317b8be4 upstream. Commit 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped") added .modinfo to ELF_DETAILS while removing it from COMMON_DISCARDS, as it was needed in vmlinux.unstripped and ELF_DETAILS was present in all architecture specific vmlinux linker scripts. While this shuffle is fine for vmlinux, ELF_DETAILS and COMMON_DISCARDS may be used by other linker scripts, such as the s390 and x86 compressed boot images, which may not expect to have a .modinfo section. In certain circumstances, this could result in a bootloader failing to load the compressed kernel [1]. Commit ddc6cbef3ef1 ("s390/boot/vmlinux.lds.S: Ensure bzImage ends with SecureBoot trailer") recently addressed this for the s390 bzImage but the same bug remains for arm, parisc, and x86. The presence of .modinfo in the x86 bzImage was the root cause of the issue worked around with commit d50f21091358 ("kbuild: align modinfo section for Secureboot Authenticode EDK2 compat"). misc.c in arch/x86/boot/compressed includes lib/decompress_unzstd.c, which in turn includes lib/xxhash.c and its MODULE_LICENSE / MODULE_DESCRIPTION macros due to the STATIC definition. Split .modinfo out from ELF_DETAILS into its own macro and handle it in all vmlinux linker scripts. Discard .modinfo in the places where it was previously being discarded from being in COMMON_DISCARDS, as it has never been necessary in those uses. Cc: stable@vger.kernel.org Fixes: 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped") Reported-by: Ed W Closes: https://lore.kernel.org/587f25e0-a80e-46a5-9f01-87cb40cfa377@wildgooses.com/ [1] Tested-by: Ed W # x86_64 Link: https://patch.msgid.link/20260225-separate-modinfo-from-elf-details-v1-1-387ced6baf4b@kernel.org Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit bc2110c10128176c17b00669b8761332ce9ae1b1 Author: Matthieu Baerts (NGI0) Date: Tue Mar 3 11:56:06 2026 +0100 selftests: mptcp: join: check removing signal+subflow endp commit 1777f349ff41b62dfe27454b69c27b0bc99ffca5 upstream. This validates the previous commit: endpoints with both the signal and subflow flags should always be marked as used even if it was not possible to create new subflows due to the MPTCP PM limits. For this test, an extra endpoint is created with both the signal and the subflow flags, and limits are set not to create extra subflows. In this case, an ADD_ADDR is sent, but no subflows are created. Still, the local endpoint is marked as used, and no warning is fired when removing the endpoint, after having sent a RM_ADDR. The 'Fixes' tag here below is the same as the one from the previous commit: this patch here is not fixing anything wrong in the selftests, but it validates the previous fix for an issue introduced by this commit ID. Fixes: 85df533a787b ("mptcp: pm: do not ignore 'subflow' if 'signal' flag is also set") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260303-net-mptcp-misc-fixes-7-0-rc2-v1-5-4b5462b6f016@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 23ec7f54a9d6800077061d2139a1bc0fa3259629 Author: Matthieu Baerts (NGI0) Date: Tue Mar 3 11:56:04 2026 +0100 selftests: mptcp: join: check RM_ADDR not sent over same subflow commit 560edd99b5f58b2d4bbe3c8e51e1eed68d887b0e upstream. This validates the previous commit: RM_ADDR were sent over the first found active subflow which could be the same as the one being removed. It is more likely to loose this notification. For this check, RM_ADDR are explicitly dropped when trying to send them over the initial subflow, when removing the endpoint attached to it. If it is dropped, the test will complain because some RM_ADDR have not been received. Note that only the RM_ADDR are dropped, to allow the linked subflow to be quickly and cleanly closed. To only drop those RM_ADDR, a cBPF byte code is used. If the IPTables commands fail, that's OK, the tests will continue to pass, but not validate this part. This can be ignored: another subtest fully depends on such command, and will be marked as skipped. The 'Fixes' tag here below is the same as the one from the previous commit: this patch here is not fixing anything wrong in the selftests, but it validates the previous fix for an issue introduced by this commit ID. Fixes: 8dd5efb1f91b ("mptcp: send ack for rm_addr") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260303-net-mptcp-misc-fixes-7-0-rc2-v1-3-4b5462b6f016@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ee6ce81a24a418fc78f91a785c8b1ea8d7716ae3 Author: Paolo Abeni Date: Tue Mar 3 11:56:02 2026 +0100 selftests: mptcp: more stable simult_flows tests commit 8c09412e584d9bcc0e71d758ec1008d1c8d1a326 upstream. By default, the netem qdisc can keep up to 1000 packets under its belly to deal with the configured rate and delay. The simult flows test-case simulates very low speed links, to avoid problems due to slow CPUs and the TCP stack tend to transmit at a slightly higher rate than the (virtual) link constraints. All the above causes a relatively large amount of packets being enqueued in the netem qdiscs - the longer the transfer, the longer the queue - producing increasingly high TCP RTT samples and consequently increasingly larger receive buffer size due to DRS. When the receive buffer size becomes considerably larger than the needed size, the tests results can flake, i.e. because minimal inaccuracy in the pacing rate can lead to a single subflow usage towards the end of the connection for a considerable amount of data. Address the issue explicitly setting netem limits suitable for the configured link speeds and unflake all the affected tests. Fixes: 1a418cb8e888 ("mptcp: simult flow self-tests") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260303-net-mptcp-misc-fixes-7-0-rc2-v1-1-4b5462b6f016@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a64aa7db39392add5be09dffaedbf1f0ce5554df Author: Matthieu Baerts (NGI0) Date: Tue Mar 3 11:56:05 2026 +0100 mptcp: pm: in-kernel: always mark signal+subflow endp as used commit 579a752464a64cb5f9139102f0e6b90a1f595ceb upstream. Syzkaller managed to find a combination of actions that was generating this warning: msk->pm.local_addr_used == 0 WARNING: net/mptcp/pm_kernel.c:1071 at __mark_subflow_endp_available net/mptcp/pm_kernel.c:1071 [inline], CPU#1: syz.2.17/961 WARNING: net/mptcp/pm_kernel.c:1071 at mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_kernel.c:1103 [inline], CPU#1: syz.2.17/961 WARNING: net/mptcp/pm_kernel.c:1071 at mptcp_pm_nl_del_addr_doit+0x81d/0x8f0 net/mptcp/pm_kernel.c:1210, CPU#1: syz.2.17/961 Modules linked in: CPU: 1 UID: 0 PID: 961 Comm: syz.2.17 Not tainted 6.19.0-08368-gfafda3b4b06b #22 PREEMPT(full) Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.17.0-debian-1.17.0-1build1 04/01/2014 RIP: 0010:__mark_subflow_endp_available net/mptcp/pm_kernel.c:1071 [inline] RIP: 0010:mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_kernel.c:1103 [inline] RIP: 0010:mptcp_pm_nl_del_addr_doit+0x81d/0x8f0 net/mptcp/pm_kernel.c:1210 Code: 89 c5 e8 46 30 6f fe e9 21 fd ff ff 49 83 ed 80 e8 38 30 6f fe 4c 89 ef be 03 00 00 00 e8 db 49 df fe eb ac e8 24 30 6f fe 90 <0f> 0b 90 e9 1d ff ff ff e8 16 30 6f fe eb 05 e8 0f 30 6f fe e8 9a RSP: 0018:ffffc90001663880 EFLAGS: 00010293 RAX: ffffffff82de1a6c RBX: 0000000000000000 RCX: ffff88800722b500 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff8880158b22d0 R08: 0000000000010425 R09: ffffffffffffffff R10: ffffffff82de18ba R11: 0000000000000000 R12: ffff88800641a640 R13: ffff8880158b1880 R14: ffff88801ec3c900 R15: ffff88800641a650 FS: 00005555722c3500(0000) GS:ffff8880f909d000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f66346e0f60 CR3: 000000001607c000 CR4: 0000000000350ef0 Call Trace: genl_family_rcv_msg_doit+0x117/0x180 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x3a8/0x3f0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x16d/0x240 net/netlink/af_netlink.c:2550 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x3e9/0x4c0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x4aa/0x5b0 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0xc9/0xf0 net/socket.c:742 ____sys_sendmsg+0x272/0x3b0 net/socket.c:2592 ___sys_sendmsg+0x2de/0x320 net/socket.c:2646 __sys_sendmsg net/socket.c:2678 [inline] __do_sys_sendmsg net/socket.c:2683 [inline] __se_sys_sendmsg net/socket.c:2681 [inline] __x64_sys_sendmsg+0x110/0x1a0 net/socket.c:2681 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x143/0x440 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f66346f826d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffc83d8bdc8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6634985fa0 RCX: 00007f66346f826d RDX: 00000000040000b0 RSI: 0000200000000740 RDI: 0000000000000007 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6634985fa8 R13: 00007f6634985fac R14: 0000000000000000 R15: 0000000000001770 The actions that caused that seem to be: - Set the MPTCP subflows limit to 0 - Create an MPTCP endpoint with both the 'signal' and 'subflow' flags - Create a new MPTCP connection from a different address: an ADD_ADDR linked to the MPTCP endpoint will be sent ('signal' flag), but no subflows is initiated ('subflow' flag) - Remove the MPTCP endpoint In this case, msk->pm.local_addr_used has been kept to 0 -- because no subflows have been created -- but the corresponding bit in msk->pm.id_avail_bitmap has been cleared when the ADD_ADDR has been sent. This later causes a splat when removing the MPTCP endpoint because msk->pm.local_addr_used has been kept to 0. Now, if an endpoint has both the signal and subflow flags, but it is not possible to create subflows because of the limits or the c-flag case, then the local endpoint counter is still incremented: the endpoint is used at the end. This avoids issues later when removing the endpoint and calling __mark_subflow_endp_available(), which expects msk->pm.local_addr_used to have been previously incremented if the endpoint was marked as used according to msk->pm.id_avail_bitmap. Note that signal_and_subflow variable is reset to false when the limits and the c-flag case allows subflows creation. Also, local_addr_used is only incremented for non ID0 subflows. Fixes: 85df533a787b ("mptcp: pm: do not ignore 'subflow' if 'signal' flag is also set") Cc: stable@vger.kernel.org Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/613 Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260303-net-mptcp-misc-fixes-7-0-rc2-v1-4-4b5462b6f016@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 19a258d03d086514920ddf54cb1755d881d7c4d0 Author: Matthieu Baerts (NGI0) Date: Tue Mar 3 11:56:03 2026 +0100 mptcp: pm: avoid sending RM_ADDR over same subflow commit fb8d0bccb221080630efcd9660c9f9349e53cc9e upstream. RM_ADDR are sent over an active subflow, the first one in the subflows list. There is then a high chance the initial subflow is picked. With the in-kernel PM, when an endpoint is removed, a RM_ADDR is sent, then linked subflows are closed. This is done for each active MPTCP connection. MPTCP endpoints are likely removed because the attached network is no longer available or usable. In this case, it is better to avoid sending this RM_ADDR over the subflow that is going to be removed, but prefer sending it over another active and non stale subflow, if any. This modification avoids situations where the other end is not notified when a subflow is no longer usable: typically when the endpoint linked to the initial subflow is removed, especially on the server side. Fixes: 8dd5efb1f91b ("mptcp: send ack for rm_addr") Cc: stable@vger.kernel.org Reported-by: Frank Lorenz Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/612 Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260303-net-mptcp-misc-fixes-7-0-rc2-v1-2-4b5462b6f016@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 944a333c8e4d42256556c1d2ebb6d773a33e0dcd Author: Junxiao Bi Date: Mon Feb 23 15:27:28 2026 -0800 scsi: core: Fix refcount leak for tagset_refcnt commit 1ac22c8eae81366101597d48360718dff9b9d980 upstream. This leak will cause a hang when tearing down the SCSI host. For example, iscsid hangs with the following call trace: [130120.652718] scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured PID: 2528 TASK: ffff9d0408974e00 CPU: 3 COMMAND: "iscsid" #0 [ffffb5b9c134b9e0] __schedule at ffffffff860657d4 #1 [ffffb5b9c134ba28] schedule at ffffffff86065c6f #2 [ffffb5b9c134ba40] schedule_timeout at ffffffff86069fb0 #3 [ffffb5b9c134bab0] __wait_for_common at ffffffff8606674f #4 [ffffb5b9c134bb10] scsi_remove_host at ffffffff85bfe84b #5 [ffffb5b9c134bb30] iscsi_sw_tcp_session_destroy at ffffffffc03031c4 [iscsi_tcp] #6 [ffffb5b9c134bb48] iscsi_if_recv_msg at ffffffffc0292692 [scsi_transport_iscsi] #7 [ffffb5b9c134bb98] iscsi_if_rx at ffffffffc02929c2 [scsi_transport_iscsi] #8 [ffffb5b9c134bbf0] netlink_unicast at ffffffff85e551d6 #9 [ffffb5b9c134bc38] netlink_sendmsg at ffffffff85e554ef Fixes: 8fe4ce5836e9 ("scsi: core: Fix a use-after-free") Cc: stable@vger.kernel.org Signed-off-by: Junxiao Bi Reviewed-by: Mike Christie Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260223232728.93350-1-junxiao.bi@oracle.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 86163b98891aa9800f6103252e5acc7bb98afb91 Author: Paulo Alcantara Date: Thu Mar 5 21:57:06 2026 -0300 smb: client: fix oops due to uninitialised var in smb2_unlink() commit 048efe129a297256d3c2088cf8d79515ff5ec864 upstream. If SMB2_open_init() or SMB2_close_init() fails (e.g. reconnect), the iovs set @rqst will be left uninitialised, hence calling SMB2_open_free(), SMB2_close_free() or smb2_set_related() on them will oops. Fix this by initialising @close_iov and @open_iov before setting them in @rqst. Reported-by: Thiago Becker Fixes: 1cf9f2a6a544 ("smb: client: handle unlink(2) of files open by different clients") Signed-off-by: Paulo Alcantara (Red Hat) Cc: David Howells Cc: linux-cifs@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 2ef0fc3bf49db2b9df36d5f44508c9e384bfa2a1 Author: Thorsten Blum Date: Thu Feb 26 22:28:45 2026 +0100 smb: client: Don't log plaintext credentials in cifs_set_cifscreds commit 2f37dc436d4e61ff7ae0b0353cf91b8c10396e4d upstream. When debug logging is enabled, cifs_set_cifscreds() logs the key payload and exposes the plaintext username and password. Remove the debug log to avoid exposing credentials. Fixes: 8a8798a5ff90 ("cifs: fetch credentials out of keyring for non-krb5 auth multiuser mounts") Cc: stable@vger.kernel.org Acked-by: Paulo Alcantara (Red Hat) Signed-off-by: Thorsten Blum Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 134596a6e4be9eb025573c0472958d8cc7c97300 Author: Paulo Alcantara Date: Wed Feb 25 21:34:55 2026 -0300 smb: client: fix broken multichannel with krb5+signing commit d9d1e319b39ea685ede59319002d567c159d23c3 upstream. When mounting a share with 'multichannel,max_channels=n,sec=krb5i', the client was duplicating signing key for all secondary channels, thus making the server fail all commands sent from secondary channels due to bad signatures. Every channel has its own signing key, so when establishing a new channel with krb5 auth, make sure to use the new session key as the derived key to generate channel's signing key in SMB2_auth_kerberos(). Repro: $ mount.cifs //srv/share /mnt -o multichannel,max_channels=4,sec=krb5i $ sleep 5 $ umount /mnt $ dmesg ... CIFS: VFS: sign fail cmd 0x5 message id 0x2 CIFS: VFS: \\srv SMB signature verification returned error = -13 CIFS: VFS: sign fail cmd 0x5 message id 0x2 CIFS: VFS: \\srv SMB signature verification returned error = -13 CIFS: VFS: sign fail cmd 0x4 message id 0x2 CIFS: VFS: \\srv SMB signature verification returned error = -13 Reported-by: Xiaoli Feng Reviewed-by: Enzo Matsumiya Signed-off-by: Paulo Alcantara (Red Hat) Cc: David Howells Cc: linux-cifs@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 0786f9422cbf727011544a127a22131a554b466c Author: Henrique Carvalho Date: Sat Feb 21 01:59:44 2026 -0300 smb: client: fix cifs_pick_channel when channels are equally loaded commit 663c28469d3274d6456f206a6671c91493d85ff1 upstream. cifs_pick_channel uses (start % chan_count) when channels are equally loaded, but that can return a channel that failed the eligibility checks. Drop the fallback and return the scan-selected channel instead. If none is eligible, keep the existing behavior of using the primary channel. Signed-off-by: Henrique Carvalho Acked-by: Paulo Alcantara (Red Hat) Acked-by: Meetakshi Setiya Reviewed-by: Shyam Prasad N Cc: stable@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 5a34959a2ab1883981e7bf7ad64898f4e596a72a Author: Ethan Tidmore Date: Thu Feb 19 21:38:25 2026 -0600 xfs: Fix error pointer dereference commit cddfa648f1ab99e30e91455be19cd5ade26338c2 upstream. The function try_lookup_noperm() can return an error pointer and is not checked for one. Add checks for error pointer in xrep_adoption_check_dcache() and xrep_adoption_zap_dcache(). Detected by Smatch: fs/xfs/scrub/orphanage.c:449 xrep_adoption_check_dcache() error: 'd_child' dereferencing possible ERR_PTR() fs/xfs/scrub/orphanage.c:485 xrep_adoption_zap_dcache() error: 'd_child' dereferencing possible ERR_PTR() Fixes: 73597e3e42b4 ("xfs: ensure dentry consistency when the orphanage adopts a file") Cc: stable@vger.kernel.org # v6.16 Signed-off-by: Ethan Tidmore Reviewed-by: Darrick J. Wong Reviewed-by: Nirjhar Roy (IBM) Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit b135cd653d1b80636f88b746539c53f46ee74e21 Author: Darrick J. Wong Date: Wed Feb 18 15:25:36 2026 -0800 xfs: fix xfs_group release bug in xfs_dax_notify_dev_failure commit eb8550fb75a875657dc29e3925a40244ec6b6bd6 upstream. Chris Mason reports that his AI tools noticed that we were using xfs_perag_put and xfs_group_put to release the group reference returned by xfs_group_next_range. However, the iterator function returns an object with an active refcount, which means that we must use the correct function to release the active refcount, which is _rele. Cc: # v6.0 Fixes: 6f643c57d57c56 ("xfs: implement ->notify_failure() for XFS") Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 4e8935053ba389ae8d6685c10854d8021931bd89 Author: Christoph Böhmwalder Date: Fri Feb 20 12:39:37 2026 +0100 drbd: fix null-pointer dereference on local read error commit 0d195d3b205ca90db30d70d09d7bb6909aac178f upstream. In drbd_request_endio(), READ_COMPLETED_WITH_ERROR is passed to __req_mod() with a NULL peer_device: __req_mod(req, what, NULL, &m); The READ_COMPLETED_WITH_ERROR handler then unconditionally passes this NULL peer_device to drbd_set_out_of_sync(), which dereferences it, causing a null-pointer dereference. Fix this by obtaining the peer_device via first_peer_device(device), matching how drbd_req_destroy() handles the same situation. Cc: stable@vger.kernel.org Reported-by: Tuo Li Link: https://lore.kernel.org/linux-block/20260104165355.151864-1-islituo@gmail.com Signed-off-by: Christoph Böhmwalder Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit d1ef3aed4df2ef1fe46befd8f2da9a6ec5445508 Author: Lars Ellenberg Date: Thu Feb 19 15:20:12 2026 +0100 drbd: fix "LOGIC BUG" in drbd_al_begin_io_nonblock() commit ab140365fb62c0bdab22b2f516aff563b2559e3b upstream. Even though we check that we "should" be able to do lc_get_cumulative() while holding the device->al_lock spinlock, it may still fail, if some other code path decided to do lc_try_lock() with bad timing. If that happened, we logged "LOGIC BUG for enr=...", but still did not return an error. The rest of the code now assumed that this request has references for the relevant activity log extents. The implcations are that during an active resync, mutual exclusivity of resync versus application IO is not guaranteed. And a potential crash at this point may not realizs that these extents could have been target of in-flight IO and would need to be resynced just in case. Also, once the request completes, it will give up activity log references it does not even hold, which will trigger a BUG_ON(refcnt == 0) in lc_put(). Fix: Do not crash the kernel for a condition that is harmless during normal operation: also catch "e->refcnt == 0", not only "e == NULL" when being noisy about "al_complete_io() called on inactive extent %u\n". And do not try to be smart and "guess" whether something will work, then be surprised when it does not. Deal with the fact that it may or may not work. If it does not, remember a possible "partially in activity log" state (only possible for requests that cross extent boundaries), and return an error code from drbd_al_begin_io_nonblock(). A latter call for the same request will then resume from where we left off. Cc: stable@vger.kernel.org Signed-off-by: Lars Ellenberg Signed-off-by: Christoph Böhmwalder Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 01ee0bcc29864b78249308e8b35042b09bbf5fe3 Author: Phillip Lougher Date: Tue Feb 17 05:09:55 2026 +0000 Squashfs: check metadata block offset is within range commit fdb24a820a5832ec4532273282cbd4f22c291a0d upstream. Syzkaller reports a "general protection fault in squashfs_copy_data" This is ultimately caused by a corrupted index look-up table, which produces a negative metadata block offset. This is subsequently passed to squashfs_copy_data (via squashfs_read_metadata) where the negative offset causes an out of bounds access. The fix is to check that the offset is within range in squashfs_read_metadata. This will trap this and other cases. Link: https://lkml.kernel.org/r/20260217050955.138351-1-phillip@squashfs.org.uk Fixes: f400e12656ab ("Squashfs: cache operations") Reported-by: syzbot+a9747fe1c35a5b115d3f@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/699234e2.a70a0220.2c38d7.00e2.GAE@google.com/ Signed-off-by: Phillip Lougher Cc: Christian Brauner Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 0524ee56af2c9bfbad152a810f1ca95de8ca00d7 Author: Deepanshu Kartikey Date: Sat Feb 14 05:45:35 2026 +0530 mm: thp: deny THP for files on anonymous inodes commit dd085fe9a8ebfc5d10314c60452db38d2b75e609 upstream. file_thp_enabled() incorrectly allows THP for files on anonymous inodes (e.g. guest_memfd and secretmem). These files are created via alloc_file_pseudo(), which does not call get_write_access() and leaves inode->i_writecount at 0. Combined with S_ISREG(inode->i_mode) being true, they appear as read-only regular files when CONFIG_READ_ONLY_THP_FOR_FS is enabled, making them eligible for THP collapse. Anonymous inodes can never pass the inode_is_open_for_write() check since their i_writecount is never incremented through the normal VFS open path. The right thing to do is to exclude them from THP eligibility altogether, since CONFIG_READ_ONLY_THP_FOR_FS was designed for real filesystem files (e.g. shared libraries), not for pseudo-filesystem inodes. For guest_memfd, this allows khugepaged and MADV_COLLAPSE to create large folios in the page cache via the collapse path, but the guest_memfd fault handler does not support large folios. This triggers WARN_ON_ONCE(folio_test_large(folio)) in kvm_gmem_fault_user_mapping(). For secretmem, collapse_file() tries to copy page contents through the direct map, but secretmem pages are removed from the direct map. This can result in a kernel crash: BUG: unable to handle page fault for address: ffff88810284d000 RIP: 0010:memcpy_orig+0x16/0x130 Call Trace: collapse_file hpage_collapse_scan_file madvise_collapse Secretmem is not affected by the crash on upstream as the memory failure recovery handles the failed copy gracefully, but it still triggers confusing false memory failure reports: Memory failure: 0x106d96f: recovery action for clean unevictable LRU page: Recovered Check IS_ANON_FILE(inode) in file_thp_enabled() to deny THP for all anonymous inode files. Link: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44 Link: https://lore.kernel.org/linux-mm/CAEvNRgHegcz3ro35ixkDw39ES8=U6rs6S7iP0gkR9enr7HoGtA@mail.gmail.com Link: https://lkml.kernel.org/r/20260214001535.435626-1-kartikey406@gmail.com Fixes: 7fbb5e188248 ("mm: remove VM_EXEC requirement for THP eligibility") Signed-off-by: Deepanshu Kartikey Reported-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44 Tested-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com Tested-by: Lance Yang Acked-by: David Hildenbrand (Arm) Reviewed-by: Barry Song Reviewed-by: Ackerley Tng Tested-by: Ackerley Tng Reviewed-by: Lorenzo Stoakes Cc: Baolin Wang Cc: Dev Jain Cc: Fangrui Song Cc: Liam Howlett Cc: Nico Pache Cc: Ryan Roberts Cc: Yang Shi Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 9a5641024fbfd9b24fe65984ad85fea10a3ae438 Author: Prithvi Tambewagh Date: Mon Feb 16 11:50:02 2026 +0530 scsi: target: Fix recursive locking in __configfs_open_file() commit 14d4ac19d1895397532eec407433c5d74d9da53b upstream. In flush_write_buffer, &p->frag_sem is acquired and then the loaded store function is called, which, here, is target_core_item_dbroot_store(). This function called filp_open(), following which these functions were called (in reverse order), according to the call trace: down_read __configfs_open_file do_dentry_open vfs_open do_open path_openat do_filp_open file_open_name filp_open target_core_item_dbroot_store flush_write_buffer configfs_write_iter target_core_item_dbroot_store() tries to validate the new file path by trying to open the file path provided to it; however, in this case, the bug report shows: db_root: not a directory: /sys/kernel/config/target/dbroot indicating that the same configfs file was tried to be opened, on which it is currently working on. Thus, it is trying to acquire frag_sem semaphore of the same file of which it already holds the semaphore obtained in flush_write_buffer(), leading to acquiring the semaphore in a nested manner and a possibility of recursive locking. Fix this by modifying target_core_item_dbroot_store() to use kern_path() instead of filp_open() to avoid opening the file using filesystem-specific function __configfs_open_file(), and further modifying it to make this fix compatible. Reported-by: syzbot+f6e8174215573a84b797@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f6e8174215573a84b797 Tested-by: syzbot+f6e8174215573a84b797@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Prithvi Tambewagh Reviewed-by: Dmitry Bogdanov Link: https://patch.msgid.link/20260216062002.61937-1-activprithvi@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit cdd96641b64297a2db42676f051362b76280a58b Author: Qing Wang Date: Fri Feb 27 10:58:42 2026 +0800 tracing: Fix WARN_ON in tracing_buffers_mmap_close commit e39bb9e02b68942f8e9359d2a3efe7d37ae6be0e upstream. When a process forks, the child process copies the parent's VMAs but the user_mapped reference count is not incremented. As a result, when both the parent and child processes exit, tracing_buffers_mmap_close() is called twice. On the second call, user_mapped is already 0, causing the function to return -ENODEV and triggering a WARN_ON. Normally, this isn't an issue as the memory is mapped with VM_DONTCOPY set. But this is only a hint, and the application can call madvise(MADVISE_DOFORK) which resets the VM_DONTCOPY flag. When the application does that, it can trigger this issue on fork. Fix it by incrementing the user_mapped reference count without re-mapping the pages in the VMA's open callback. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Vincent Donnefort Cc: Lorenzo Stoakes Link: https://patch.msgid.link/20260227025842.1085206-1-wangqing7171@gmail.com Fixes: cf9f0f7c4c5bb ("tracing: Allow user-space mapping of the ring-buffer") Reported-by: syzbot+3b5dd2030fe08afdf65d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3b5dd2030fe08afdf65d Tested-by: syzbot+3b5dd2030fe08afdf65d@syzkaller.appspotmail.com Signed-off-by: Qing Wang Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 27c13c5bb0948e3b5c64e59f8a903231896fab9b Author: Kuniyuki Iwashima Date: Sat Jan 24 04:18:40 2026 +0000 nfsd: Fix cred ref leak in nfsd_nl_threads_set_doit(). commit 1cb968a2013ffa8112d52ebe605009ea1c6a582c upstream. syzbot reported memory leak of struct cred. [0] nfsd_nl_threads_set_doit() passes get_current_cred() to nfsd_svc(), but put_cred() is not called after that. The cred is finally passed down to _svc_xprt_create(), which calls get_cred() with the cred for struct svc_xprt. The ownership of the refcount by get_current_cred() is not transferred to anywhere and is just leaked. nfsd_svc() is also called from write_threads(), but it does not bump file->f_cred there. nfsd_nl_threads_set_doit() is called from sendmsg() and current->cred does not go away. Let's use current_cred() in nfsd_nl_threads_set_doit(). [0]: BUG: memory leak unreferenced object 0xffff888108b89480 (size 184): comm "syz-executor", pid 5994, jiffies 4294943386 hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 369454a7): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4958 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_noprof+0x412/0x580 mm/slub.c:5270 prepare_creds+0x22/0x600 kernel/cred.c:185 copy_creds+0x44/0x290 kernel/cred.c:286 copy_process+0x7a7/0x2870 kernel/fork.c:2086 kernel_clone+0xac/0x6e0 kernel/fork.c:2651 __do_sys_clone+0x7f/0xb0 kernel/fork.c:2792 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 924f4fb003ba ("NFSD: convert write_threads to netlink command") Cc: stable@vger.kernel.org Reported-by: syzbot+dd3b43aa0204089217ee@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/69744674.a00a0220.33ccc7.0000.GAE@google.com/ Tested-by: syzbot+dd3b43aa0204089217ee@syzkaller.appspotmail.com Signed-off-by: Kuniyuki Iwashima Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit a6677e23b313cd9fd03690c589c6452cb6fffb97 Author: Davide Caratti Date: Tue Feb 24 21:28:32 2026 +0100 net/sched: ets: fix divide by zero in the offload path commit e35626f610f3d2b7953ccddf6a77453da22b3a9e upstream. Offloading ETS requires computing each class' WRR weight: this is done by averaging over the sums of quanta as 'q_sum' and 'q_psum'. Using unsigned int, the same integer size as the individual DRR quanta, can overflow and even cause division by zero, like it happened in the following splat: Oops: divide error: 0000 [#1] SMP PTI CPU: 13 UID: 0 PID: 487 Comm: tc Tainted: G E 6.19.0-virtme #45 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 RIP: 0010:ets_offload_change+0x11f/0x290 [sch_ets] Code: e4 45 31 ff eb 03 41 89 c7 41 89 cb 89 ce 83 f9 0f 0f 87 b7 00 00 00 45 8b 08 31 c0 45 01 cc 45 85 c9 74 09 41 6b c4 64 31 d2 <41> f7 f2 89 c2 44 29 fa 45 89 df 41 83 fb 0f 0f 87 c7 00 00 00 44 RSP: 0018:ffffd0a180d77588 EFLAGS: 00010246 RAX: 00000000ffffff38 RBX: ffff8d3d482ca000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffd0a180d77660 RBP: ffffd0a180d77690 R08: ffff8d3d482ca2d8 R09: 00000000fffffffe R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffffe R13: ffff8d3d472f2000 R14: 0000000000000003 R15: 0000000000000000 FS: 00007f440b6c2740(0000) GS:ffff8d3dc9803000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000003cdd2000 CR3: 0000000007b58002 CR4: 0000000000172ef0 Call Trace: ets_qdisc_change+0x870/0xf40 [sch_ets] qdisc_create+0x12b/0x540 tc_modify_qdisc+0x6d7/0xbd0 rtnetlink_rcv_msg+0x168/0x6b0 netlink_rcv_skb+0x5c/0x110 netlink_unicast+0x1d6/0x2b0 netlink_sendmsg+0x22e/0x470 ____sys_sendmsg+0x38a/0x3c0 ___sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x111/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f440b81c77e Code: 4d 89 d8 e8 d4 bc 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 c3 83 e2 39 83 fa 08 75 e7 e8 13 ff ff ff 0f 1f 00 f3 0f 1e fa RSP: 002b:00007fff951e4c10 EFLAGS: 00000202 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000481820 RCX: 00007f440b81c77e RDX: 0000000000000000 RSI: 00007fff951e4cd0 RDI: 0000000000000003 RBP: 00007fff951e4c20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007fff951f4fa8 R13: 00000000699ddede R14: 00007f440bb01000 R15: 0000000000486980 Modules linked in: sch_ets(E) netdevsim(E) ---[ end trace 0000000000000000 ]--- RIP: 0010:ets_offload_change+0x11f/0x290 [sch_ets] Code: e4 45 31 ff eb 03 41 89 c7 41 89 cb 89 ce 83 f9 0f 0f 87 b7 00 00 00 45 8b 08 31 c0 45 01 cc 45 85 c9 74 09 41 6b c4 64 31 d2 <41> f7 f2 89 c2 44 29 fa 45 89 df 41 83 fb 0f 0f 87 c7 00 00 00 44 RSP: 0018:ffffd0a180d77588 EFLAGS: 00010246 RAX: 00000000ffffff38 RBX: ffff8d3d482ca000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffd0a180d77660 RBP: ffffd0a180d77690 R08: ffff8d3d482ca2d8 R09: 00000000fffffffe R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffffe R13: ffff8d3d472f2000 R14: 0000000000000003 R15: 0000000000000000 FS: 00007f440b6c2740(0000) GS:ffff8d3dc9803000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000003cdd2000 CR3: 0000000007b58002 CR4: 0000000000172ef0 Kernel panic - not syncing: Fatal exception Kernel Offset: 0x30000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]--- Fix this using 64-bit integers for 'q_sum' and 'q_psum'. Cc: stable@vger.kernel.org Fixes: d35eb52bd2ac ("net: sch_ets: Make the ETS qdisc offloadable") Signed-off-by: Davide Caratti Reviewed-by: Jamal Hadi Salim Reviewed-by: Petr Machata Link: https://patch.msgid.link/28504887df314588c7255e9911769c36f751edee.1771964872.git.dcaratti@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ca1684dd297bf0725c1d487cff80e615497accf6 Author: Catalin Marinas Date: Mon Feb 23 17:45:30 2026 +0000 arm64: gcs: Do not set PTE_SHARED on GCS mappings if FEAT_LPA2 is enabled commit 8a85b3131225a8c8143ba2ae29c0eef8c1f9117f upstream. When FEAT_LPA2 is enabled, bits 8-9 of the PTE replace the shareability attribute with bits 50-51 of the output address. The _PAGE_GCS{,_RO} definitions include the PTE_SHARED bits as 0b11 (this matches the other _PAGE_* definitions) but using this macro directly leads to the following panic when enabling GCS on a system/model with LPA2: Unable to handle kernel paging request at virtual address fffff1ffc32d8008 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 52-bit VAs, pgdp=0000000060f4d000 [fffff1ffc32d8008] pgd=100000006184b003, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 0 UID: 0 PID: 513 Comm: gcs_write_fault Tainted: G M 7.0.0-rc1 #1 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: QEMU QEMU Virtual Machine, BIOS 2025.02-8+deb13u1 11/08/2025 pstate: 03402005 (nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : zap_huge_pmd+0x168/0x468 lr : zap_huge_pmd+0x2c/0x468 sp : ffff800080beb660 x29: ffff800080beb660 x28: fff00000c2058180 x27: ffff800080beb898 x26: fff00000c2058180 x25: ffff800080beb820 x24: 00c800010b600f41 x23: ffffc1ffc30af1a8 x22: fff00000c2058180 x21: 0000ffff8dc00000 x20: fff00000c2bc6370 x19: ffff800080beb898 x18: ffff800080bebb60 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000007 x14: 000000000000000a x13: 0000aaaacbbbffff x12: 0000000000000000 x11: 0000ffff8ddfffff x10: 00000000000001fe x9 : 0000ffff8ddfffff x8 : 0000ffff8de00000 x7 : 0000ffff8da00000 x6 : fff00000c2bc6370 x5 : 0000ffff8da00000 x4 : 000000010b600000 x3 : ffffc1ffc0000000 x2 : fff00000c2058180 x1 : fffff1ffc32d8000 x0 : 000000c00010b600 Call trace: zap_huge_pmd+0x168/0x468 (P) unmap_page_range+0xd70/0x1560 unmap_single_vma+0x48/0x80 unmap_vmas+0x90/0x180 unmap_region+0x88/0xe4 vms_complete_munmap_vmas+0xf8/0x1e0 do_vmi_align_munmap+0x158/0x180 do_vmi_munmap+0xac/0x160 __vm_munmap+0xb0/0x138 vm_munmap+0x14/0x20 gcs_free+0x70/0x80 mm_release+0x1c/0xc8 exit_mm_release+0x28/0x38 do_exit+0x190/0x8ec do_group_exit+0x34/0x90 get_signal+0x794/0x858 arch_do_signal_or_restart+0x11c/0x3e0 exit_to_user_mode_loop+0x10c/0x17c el0_da+0x8c/0x9c el0t_64_sync_handler+0xd0/0xf0 el0t_64_sync+0x198/0x19c Code: aa1603e2 d34cfc00 cb813001 8b011861 (f9400420) Similarly to how the kernel handles protection_map[], use a gcs_page_prot variable to store the protection bits and clear PTE_SHARED if LPA2 is enabled. Also remove the unused PAGE_GCS{,_RO} macros. Signed-off-by: Catalin Marinas Fixes: 6497b66ba694 ("arm64/mm: Map pages for guarded control stack") Reported-by: Emanuele Rocca Cc: stable@vger.kernel.org Cc: Mark Brown Cc: Will Deacon Reviewed-by: David Hildenbrand (Arm) Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit a1850e2aef4d15405e7ff53fd51c4b3124d46182 Author: Srinivas Pandruvada Date: Tue Feb 24 16:17:52 2026 -0800 cpufreq: intel_pstate: Fix crash during turbo disable commit 6b050482ec40569429d963ac52afa878691b04c9 upstream. When the system is booted with kernel command line argument "nosmt" or "maxcpus" to limit the number of CPUs, disabling turbo via: echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo results in a crash: PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI ... RIP: 0010:store_no_turbo+0x100/0x1f0 ... This occurs because for_each_possible_cpu() returns CPUs even if they are not online. For those CPUs, all_cpu_data[] will be NULL. Since commit 973207ae3d7c ("cpufreq: intel_pstate: Rearrange max frequency updates handling code"), all_cpu_data[] is dereferenced even for CPUs which are not online, causing the NULL pointer dereference. To fix that, pass CPU number to intel_pstate_update_max_freq() and use all_cpu_data[] for those CPUs for which there is a valid cpufreq policy. Fixes: 973207ae3d7c ("cpufreq: intel_pstate: Rearrange max frequency updates handling code") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221068 Signed-off-by: Srinivas Pandruvada Cc: 6.16+ # 6.16+ Link: https://patch.msgid.link/20260225001752.890164-1-srinivas.pandruvada@linux.intel.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit a6f3e0fa8e862f220c26c2f27e5ddc42eb82ad3e Author: Jason Gunthorpe Date: Mon Feb 16 11:02:50 2026 -0400 RDMA/ionic: Fix kernel stack leak in ionic_create_cq() commit faa72102b178c7ae6c6afea23879e7c84fc59b4e upstream. struct ionic_cq_resp resp { __u32 cqid[2]; // offset 0 - PARTIALLY SET (see below) __u8 udma_mask; // offset 8 - SET (resp.udma_mask = vcq->udma_mask) __u8 rsvd[7]; // offset 9 - NEVER SET <- LEAK }; rsvd[7]: 7 bytes of stack memory leaked unconditionally. cqid[2]: The loop at line 1256 iterates over udma_idx but skips indices where !(vcq->udma_mask & BIT(udma_idx)). The array has 2 entries but udma_count could be 1, meaning cqid[1] might never be written via ionic_create_cq_common(). If udma_mask only has bit 0 set, cqid[1] (4 bytes) is also leaked. So potentially 11 bytes leaked. Cc: stable@vger.kernel.org Fixes: e8521822c733 ("RDMA/ionic: Register device ops for control path") Signed-off-by: Jason Gunthorpe Link: https://patch.msgid.link/4-v1-83e918d69e73+a9-rdma_udata_rc_jgg@nvidia.com Acked-by: Abhijit Gangurde Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman commit cfe962216c164fe2b1c1fb6ac925a7413f5abc84 Author: Jason Gunthorpe Date: Mon Feb 16 11:02:49 2026 -0400 RDMA/irdma: Fix kernel stack leak in irdma_create_user_ah() commit 74586c6da9ea222a61c98394f2fc0a604748438c upstream. struct irdma_create_ah_resp { // 8 bytes, no padding __u32 ah_id; // offset 0 - SET (uresp.ah_id = ah->sc_ah.ah_info.ah_idx) __u8 rsvd[4]; // offset 4 - NEVER SET <- LEAK }; rsvd[4]: 4 bytes of stack memory leaked unconditionally. Only ah_id is assigned before ib_respond_udata(). The reserved members of the structure were not zeroed. Cc: stable@vger.kernel.org Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Signed-off-by: Jason Gunthorpe Link: https://patch.msgid.link/3-v1-83e918d69e73+a9-rdma_udata_rc_jgg@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman commit deee46b37ebd8cc5ff810127883fca90f2412a7b Author: Jason Gunthorpe Date: Mon Feb 16 11:02:48 2026 -0400 IB/mthca: Add missed mthca_unmap_user_db() for mthca_create_srq() commit 117942ca43e2e3c3d121faae530989931b7f67e1 upstream. Fix a user triggerable leak on the system call failure path. Cc: stable@vger.kernel.org Fixes: ec34a922d243 ("[PATCH] IB/mthca: Add SRQ implementation") Signed-off-by: Jason Gunthorpe Link: https://patch.msgid.link/2-v1-83e918d69e73+a9-rdma_udata_rc_jgg@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman commit 2764dcb3c35de4410f642afc62cf979727470575 Author: Andrew Lunn Date: Sun Feb 22 16:26:01 2026 +0100 net: phy: register phy led_triggers during probe to avoid AB-BA deadlock commit c8dbdc6e380e7e96a51706db3e4b7870d8a9402d upstream. There is an AB-BA deadlock when both LEDS_TRIGGER_NETDEV and LED_TRIGGER_PHY are enabled: [ 1362.049207] [<8054e4b8>] led_trigger_register+0x5c/0x1fc <-- Trying to get lock "triggers_list_lock" via down_write(&triggers_list_lock); [ 1362.054536] [<80662830>] phy_led_triggers_register+0xd0/0x234 [ 1362.060329] [<8065e200>] phy_attach_direct+0x33c/0x40c [ 1362.065489] [<80651fc4>] phylink_fwnode_phy_connect+0x15c/0x23c [ 1362.071480] [<8066ee18>] mtk_open+0x7c/0xba0 [ 1362.075849] [<806d714c>] __dev_open+0x280/0x2b0 [ 1362.080384] [<806d7668>] __dev_change_flags+0x244/0x24c [ 1362.085598] [<806d7698>] dev_change_flags+0x28/0x78 [ 1362.090528] [<807150e4>] dev_ioctl+0x4c0/0x654 <-- Hold lock "rtnl_mutex" by calling rtnl_lock(); [ 1362.094985] [<80694360>] sock_ioctl+0x2f4/0x4e0 [ 1362.099567] [<802e9c4c>] sys_ioctl+0x32c/0xd8c [ 1362.104022] [<80014504>] syscall_common+0x34/0x58 Here LED_TRIGGER_PHY is registering LED triggers during phy_attach while holding RTNL and then taking triggers_list_lock. [ 1362.191101] [<806c2640>] register_netdevice_notifier+0x60/0x168 <-- Trying to get lock "rtnl_mutex" via rtnl_lock(); [ 1362.197073] [<805504ac>] netdev_trig_activate+0x194/0x1e4 [ 1362.202490] [<8054e28c>] led_trigger_set+0x1d4/0x360 <-- Hold lock "triggers_list_lock" by down_read(&triggers_list_lock); [ 1362.207511] [<8054eb38>] led_trigger_write+0xd8/0x14c [ 1362.212566] [<80381d98>] sysfs_kf_bin_write+0x80/0xbc [ 1362.217688] [<8037fcd8>] kernfs_fop_write_iter+0x17c/0x28c [ 1362.223174] [<802cbd70>] vfs_write+0x21c/0x3c4 [ 1362.227712] [<802cc0c4>] ksys_write+0x78/0x12c [ 1362.232164] [<80014504>] syscall_common+0x34/0x58 Here LEDS_TRIGGER_NETDEV is being enabled on an LED. It first takes triggers_list_lock and then RTNL. A classical AB-BA deadlock. phy_led_triggers_registers() does not require the RTNL, it does not make any calls into the network stack which require protection. There is also no requirement the PHY has been attached to a MAC, the triggers only make use of phydev state. This allows the call to phy_led_triggers_registers() to be placed elsewhere. PHY probe() and release() don't hold RTNL, so solving the AB-BA deadlock. Reported-by: Shiji Yang Closes: https://lore.kernel.org/all/OS7PR01MB13602B128BA1AD3FA38B6D1FFBC69A@OS7PR01MB13602.jpnprd01.prod.outlook.com/ Fixes: 06f502f57d0d ("leds: trigger: Introduce a NETDEV trigger") Cc: stable@vger.kernel.org Signed-off-by: Andrew Lunn Tested-by: Shiji Yang Link: https://patch.msgid.link/20260222152601.1978655-1-andrew@lunn.ch Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 07e0c80e17ef781799e7cd5c41a7bf44f1bf6a5f Author: Ankit Garg Date: Fri Feb 20 13:53:24 2026 -0800 gve: fix incorrect buffer cleanup in gve_tx_clean_pending_packets for QPL commit fb868db5f4bccd7a78219313ab2917429f715cea upstream. In DQ-QPL mode, gve_tx_clean_pending_packets() incorrectly uses the RDA buffer cleanup path. It iterates num_bufs times and attempts to unmap entries in the dma array. This leads to two issues: 1. The dma array shares storage with tx_qpl_buf_ids (union). Interpreting buffer IDs as DMA addresses results in attempting to unmap incorrect memory locations. 2. num_bufs in QPL mode (counting 2K chunks) can significantly exceed the size of the dma array, causing out-of-bounds access warnings (trace below is how we noticed this issue). UBSAN: array-index-out-of-bounds in drivers/net/ethernet/drivers/net/ethernet/google/gve/gve_tx_dqo.c:178:5 index 18 is out of range for type 'dma_addr_t[18]' (aka 'unsigned long long[18]') Workqueue: gve gve_service_task [gve] Call Trace: dump_stack_lvl+0x33/0xa0 __ubsan_handle_out_of_bounds+0xdc/0x110 gve_tx_stop_ring_dqo+0x182/0x200 [gve] gve_close+0x1be/0x450 [gve] gve_reset+0x99/0x120 [gve] gve_service_task+0x61/0x100 [gve] process_scheduled_works+0x1e9/0x380 Fix this by properly checking for QPL mode and delegating to gve_free_tx_qpl_bufs() to reclaim the buffers. Cc: stable@vger.kernel.org Fixes: a6fb8d5a8b69 ("gve: Tx path for DQO-QPL") Signed-off-by: Ankit Garg Reviewed-by: Jordan Rhee Reviewed-by: Harshitha Ramamurthy Signed-off-by: Joshua Washington Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260220215324.1631350-1-joshwash@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2b6c942a526635f5c61d2f000258e620da32d3a7 Author: Heitor Alves de Siqueira Date: Wed Feb 11 15:03:35 2026 -0300 Bluetooth: purge error queues in socket destructors commit 21e4271e65094172aadd5beb8caea95dd0fbf6d7 upstream. When TX timestamping is enabled via SO_TIMESTAMPING, SKBs may be queued into sk_error_queue and will stay there until consumed. If userspace never gets to read the timestamps, or if the controller is removed unexpectedly, these SKBs will leak. Fix by adding skb_queue_purge() calls for sk_error_queue in affected bluetooth destructors. RFCOMM does not currently use sk_error_queue. Fixes: 134f4b39df7b ("Bluetooth: add support for skb TX SND/COMPLETION timestamping") Reported-by: syzbot+7ff4013eabad1407b70a@syzkaller.appspotmail.com Closes: https://syzbot.org/bug?extid=7ff4013eabad1407b70a Cc: stable@vger.kernel.org Signed-off-by: Heitor Alves de Siqueira Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit cc6d5a3c0a854aeae00915fc5386570c86029c60 Author: Vahagn Vardanian Date: Mon Feb 23 00:00:00 2026 +0000 wifi: mac80211: fix NULL pointer dereference in mesh_rx_csa_frame() commit 017c1792525064a723971f0216e6ef86a8c7af11 upstream. In mesh_rx_csa_frame(), elems->mesh_chansw_params_ie is dereferenced at lines 1638 and 1642 without a prior NULL check: ifmsh->chsw_ttl = elems->mesh_chansw_params_ie->mesh_ttl; ... pre_value = le16_to_cpu(elems->mesh_chansw_params_ie->mesh_pre_value); The mesh_matches_local() check above only validates the Mesh ID, Mesh Configuration, and Supported Rates IEs. It does not verify the presence of the Mesh Channel Switch Parameters IE (element ID 118). When a received CSA action frame omits that IE, ieee802_11_parse_elems() leaves elems->mesh_chansw_params_ie as NULL, and the unconditional dereference causes a kernel NULL pointer dereference. A remote mesh peer with an established peer link (PLINK_ESTAB) can trigger this by sending a crafted SPECTRUM_MGMT/CHL_SWITCH action frame that includes a matching Mesh ID and Mesh Configuration IE but omits the Mesh Channel Switch Parameters IE. No authentication beyond the default open mesh peering is required. Crash confirmed on kernel 6.17.0-5-generic via mac80211_hwsim: BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:ieee80211_mesh_rx_queued_mgmt+0x143/0x2a0 [mac80211] CR2: 0000000000000000 Fix by adding a NULL check for mesh_chansw_params_ie after mesh_matches_local() returns, consistent with how other optional IEs are guarded throughout the mesh code. The bug has been present since v3.13 (released 2014-01-19). Fixes: 8f2535b92d68 ("mac80211: process the CSA frame for mesh accordingly") Cc: stable@vger.kernel.org Signed-off-by: Vahagn Vardanian Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit f35ceec54d48e227fa46f8f97fd100a77b8eab15 Author: Ariel Silver Date: Fri Feb 20 10:11:29 2026 +0000 wifi: mac80211: bounds-check link_id in ieee80211_ml_reconfiguration commit 162d331d833dc73a3e905a24c44dd33732af1fc5 upstream. link_id is taken from the ML Reconfiguration element (control & 0x000f), so it can be 0..15. link_removal_timeout[] has IEEE80211_MLD_MAX_NUM_LINKS (15) elements, so index 15 is out-of-bounds. Skip subelements with link_id >= IEEE80211_MLD_MAX_NUM_LINKS to avoid a stack out-of-bounds write. Fixes: 8eb8dd2ffbbb ("wifi: mac80211: Support link removal using Reconfiguration ML element") Reported-by: Ariel Silver Signed-off-by: Ariel Silver Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260220101129.1202657-1-Ariel.Silver@cybereason.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 584279ad9ff1e8e7c5494b9fce286201f7d1f9e2 Author: Daniil Dulov Date: Wed Feb 11 11:20:24 2026 +0300 wifi: cfg80211: cancel rfkill_block work in wiphy_unregister() commit 767d23ade706d5fa51c36168e92a9c5533c351a1 upstream. There is a use-after-free error in cfg80211_shutdown_all_interfaces found by syzkaller: BUG: KASAN: use-after-free in cfg80211_shutdown_all_interfaces+0x213/0x220 Read of size 8 at addr ffff888112a78d98 by task kworker/0:5/5326 CPU: 0 UID: 0 PID: 5326 Comm: kworker/0:5 Not tainted 6.19.0-rc2 #2 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: events cfg80211_rfkill_block_work Call Trace: dump_stack_lvl+0x116/0x1f0 print_report+0xcd/0x630 kasan_report+0xe0/0x110 cfg80211_shutdown_all_interfaces+0x213/0x220 cfg80211_rfkill_block_work+0x1e/0x30 process_one_work+0x9cf/0x1b70 worker_thread+0x6c8/0xf10 kthread+0x3c5/0x780 ret_from_fork+0x56d/0x700 ret_from_fork_asm+0x1a/0x30 The problem arises due to the rfkill_block work is not cancelled when wiphy is being unregistered. In order to fix the issue cancel the corresponding work in wiphy_unregister(). Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 1f87f7d3a3b4 ("cfg80211: add rfkill support") Cc: stable@vger.kernel.org Signed-off-by: Daniil Dulov Link: https://patch.msgid.link/20260211082024.1967588-1-d.dulov@aladdin.ru Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit ed7d30f90b77f73a47498686ede83f622b7e4f0d Author: Daniel Hodges Date: Fri Feb 6 14:53:56 2026 -0500 wifi: libertas: fix use-after-free in lbs_free_adapter() commit 03cc8f90d0537fcd4985c3319b4fafbf2e3fb1f0 upstream. The lbs_free_adapter() function uses timer_delete() (non-synchronous) for both command_timer and tx_lockup_timer before the structure is freed. This is incorrect because timer_delete() does not wait for any running timer callback to complete. If a timer callback is executing when lbs_free_adapter() is called, the callback will access freed memory since lbs_cfg_free() frees the containing structure immediately after lbs_free_adapter() returns. Both timer callbacks (lbs_cmd_timeout_handler and lbs_tx_lockup_handler) access priv->driver_lock, priv->cur_cmd, priv->dev, and other fields, which would all be use-after-free violations. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning. This bug was introduced in commit 8f641d93c38a ("libertas: detect TX lockups and reset hardware") where del_timer() was used instead of del_timer_sync() in the cleanup path. The command_timer has had the same issue since the driver was first written. Fixes: 8f641d93c38a ("libertas: detect TX lockups and reset hardware") Fixes: 954ee164f4f4 ("[PATCH] libertas: reorganize and simplify init sequence") Cc: stable@vger.kernel.org Signed-off-by: Daniel Hodges Link: https://patch.msgid.link/20260206195356.15647-1-git@danielhodges.dev Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 2f8ceeba670610d66f77def32011f48de951d781 Author: Johannes Berg Date: Tue Feb 17 13:05:26 2026 +0100 wifi: radiotap: reject radiotap with unknown bits commit c854758abe0b8d86f9c43dc060ff56a0ee5b31e0 upstream. The radiotap parser is currently only used with the radiotap namespace (not with vendor namespaces), but if the undefined field 18 is used, the alignment/size is unknown as well. In this case, iterator->_next_ns_data isn't initialized (it's only set for skipping vendor namespaces), and syzbot points out that we later compare against this uninitialized value. Fix this by moving the rejection of unknown radiotap fields down to after the in-namespace lookup, so it will really use iterator->_next_ns_data only for vendor namespaces, even in case undefined fields are present. Cc: stable@vger.kernel.org Fixes: 33e5a2f776e3 ("wireless: update radiotap parser") Reported-by: syzbot+b09c1af8764c0097bb19@syzkaller.appspotmail.com Closes: https://lore.kernel.org/r/69944a91.a70a0220.2c38d7.00fc.GAE@google.com Link: https://patch.msgid.link/20260217120526.162647-2-johannes@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit bf21bfd63e0139408985e7c9b05768684e64cf3b Author: Juhyung Park Date: Sun Feb 22 21:26:09 2026 +0900 ALSA: hda/realtek: add quirk for Samsung Galaxy Book Flex (NT950QCT-A38A) commit 9fb16a5c5ff93058851099a2b80a899b0c53fe3f upstream. Similar to other Samsung laptops, NT950QCT also requires the ALC298_FIXUP_SAMSUNG_AMP quirk applied. Cc: Signed-off-by: Juhyung Park Link: https://patch.msgid.link/20260222122609.281191-2-qkrwngud825@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 36facbc94803ca091748b2592bae1d67a46c56d5 Author: Panagiotis Foliadis Date: Sat Feb 21 19:40:58 2026 +0000 ALSA: hda/realtek: Add quirk for Acer Aspire V3-572G commit cbddd303416456db5ceeedaf9e262096f079e861 upstream. The Acer Aspire V3-572G has a combo jack (ALC283) but the BIOS sets pin 0x19 to 0x411111f0 (not connected), so the headset mic is not detected. Add a quirk to override pin 0x19 as a headset mic and enable headset mode. Cc: stable@vger.kernel.org Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221075 Suggested-by: Charalampos Mitrodimas Signed-off-by: Panagiotis Foliadis Reviewed-by: Charalampos Mitrodimas Link: https://patch.msgid.link/20260221-fix-detect-mic-v1-1-b6e427b5275d@posteo.net Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7eb2d1ce7b451833766564cd05dc74a7e81e9c7d Author: Juhyung Park Date: Sun Feb 22 21:26:08 2026 +0900 ALSA: hda/realtek: fix model name typo for Samsung Galaxy Book Flex (NT950QCG-X716) commit 43a44fb7f2fa163926b23149805e989ba2395db1 upstream. There's no product named "Samsung Galaxy Flex Book". Use the correct "Samsung Galaxy Book Flex" name. Link: https://www.samsung.com/sec/support/model/NT950QCG-X716 Link: https://www.samsung.com/us/computing/galaxy-books/galaxy-book-flex/galaxy-book-flex-15-6-qled-512gb-storage-s-pen-included-np950qcg-k01us Cc: Signed-off-by: Juhyung Park Link: https://patch.msgid.link/20260222122609.281191-1-qkrwngud825@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 27338f3360ef1a15a804e18ae6dac91b6f986d7c Author: Panagiotis Foliadis Date: Wed Feb 25 14:53:43 2026 +0000 ALSA: hda/intel: increase default bdl_pos_adj for Nvidia controllers commit e9fb2028f1eb563e653cff3b0d1c87c5e0203d45 upstream. The default bdl_pos_adj of 32 for Nvidia HDA controllers is insufficient on GA102 (and likely other recent Nvidia GPUs) after S3 suspend/resume. The controller's DMA timing degrades after resume, causing premature IRQ detection in azx_position_ok() which results in silent HDMI/DP audio output despite userspace reporting a valid playback state and correct ELD data. Increase bdl_pos_adj to 64 for AZX_DRIVER_NVIDIA, matching the value already used by Intel Apollo Lake for the same class of timing issue. Cc: stable@vger.kernel.org Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221069 Suggested-by: Charalampos Mitrodimas Signed-off-by: Panagiotis Foliadis Link: https://patch.msgid.link/20260225-nvidia-audio-fix-v1-1-b1383c37ec49@posteo.net Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1e5753ff4c2e86aa88516f97a224c90a3d0b133e Author: Jun Seo Date: Thu Feb 26 10:08:20 2026 +0900 ALSA: usb-audio: Use correct version for UAC3 header validation commit 54f9d645a5453d0bfece0c465d34aaf072ea99fa upstream. The entry of the validators table for UAC3 AC header descriptor is defined with the wrong protocol version UAC_VERSION_2, while it should have been UAC_VERSION_3. This results in the validator never matching for actual UAC3 devices (protocol == UAC_VERSION_3), causing their header descriptors to bypass validation entirely. A malicious USB device presenting a truncated UAC3 header could exploit this to cause out-of-bounds reads when the driver later accesses unvalidated descriptor fields. The bug was introduced in the same commit as the recently fixed UAC3 feature unit sub-type typo, and appears to be from the same copy-paste error when the UAC3 section was created from the UAC2 section. Fixes: 57f8770620e9 ("ALSA: usb-audio: More validations of descriptor units") Cc: Signed-off-by: Jun Seo Link: https://patch.msgid.link/20260226010820.36529-1-jun.seo.93@proton.me Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit be7e624f24df8c05b75716f7b5b13005d728041a Author: Rong Zhang Date: Tue Mar 3 01:32:59 2026 +0800 ALSA: doc: usb-audio: Add doc for QUIRK_FLAG_SKIP_IFACE_SETUP commit 93992667d0ab695ac30ceec91a516fd4bf725d75 upstream. QUIRK_FLAG_SKIP_IFACE_SETUP was introduced into usb-audio before without appropriate documentation, so add it. Fixes: 38c322068a26 ("ALSA: usb-audio: Add QUIRK_FLAG_SKIP_IFACE_SETUP") Cc: stable@vger.kernel.org Signed-off-by: Rong Zhang Link: https://patch.msgid.link/20260302173300.322673-1-i@rong.moe Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8d70dff4a2e271d70bc8cd14ee90a75bc759fb2d Author: Zhang Heng Date: Fri Feb 27 20:13:27 2026 +0800 ALSA: hda/realtek: Add quirk for HP Pavilion 15-eh1xxx to enable mute LED commit 068641bc9dc3d680d1ec4f6ee9199d4812041dff upstream. The HP Pavilion 15-eh1xxx series uses the HP mainboard 88D1 with ALC245 and needs the ALC245_FIXUP_HP_MUTE_LED_V1_COEFBIT quirk to make the mute led working. Link: https://bugzilla.kernel.org/show_bug.cgi?id=215978 Cc: Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260227121327.3751341-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5f935f1331071def9892955d5cf1db60e3f5606b Author: Kurt Borja Date: Sat Feb 7 12:16:34 2026 -0500 platform/x86: dell-wmi: Add audio/mic mute key codes commit 26a7601471f62b95d56a81c3a8ccb551b5a6630f upstream. Add audio/mic mute key codes found in Alienware m18 r1 AMD. Cc: stable@vger.kernel.org Tested-by: Olexa Bilaniuk Suggested-by: Olexa Bilaniuk Signed-off-by: Kurt Borja Acked-by: Pali Rohár Link: https://patch.msgid.link/20260207-mute-keys-v2-1-c55e5471c9c1@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit bf84193d91305eea54243e3fdbd31401d795010a Author: Kurt Borja Date: Thu Jan 29 12:19:24 2026 -0500 platform/x86: alienware-wmi-wmax: Add G-Mode support to m18 laptops commit bd5914caeb4b2de233992c31babccda88041b035 upstream. Alienware m18 laptops support G-Mode. Therefore, match them with G-Series quirks. Cc: stable@vger.kernel.org Tested-by: Olexa Bilaniuk Signed-off-by: Kurt Borja Link: https://patch.msgid.link/20260129-m18-gmode-v1-1-48be521487b9@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 5de34126fb2edf8ab7f25d677b132e92d8bf9ede Author: Thorsten Blum Date: Tue Mar 3 12:30:51 2026 +0100 platform/x86: dell-wmi-sysman: Don't hex dump plaintext password data commit d1a196e0a6dcddd03748468a0e9e3100790fc85c upstream. set_new_password() hex dumps the entire buffer, which contains plaintext password data, including current and new passwords. Remove the hex dump to avoid leaking credentials. Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Link: https://patch.msgid.link/20260303113050.58127-2-thorsten.blum@linux.dev Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit c42a92d685c4c49b6cd15bbee1376a2c3982495c Author: Tom Lendacky Date: Wed Feb 4 09:01:00 2026 -0600 x86/boot/sev: Move SEV decompressor variables into the .data section commit 4ca191cec17a997d0e3b2cd312f3a884288acc27 upstream. As part of the work to remove the dependency on calling into the decompressor code (startup_64()) for a UEFI boot, a call to rmpadjust() was removed from sev_enable() in favor of checking the value of the snp_vmpl variable. When booting through a non-UEFI path and calling startup_64(), the call to sev_enable() is performed before the BSS section is zeroed. With the removal of the rmpadjust() call and the corresponding check of the return code, the snp_vmpl variable is checked. Since the kernel is running at VMPL0, the snp_vmpl variable will not have been set and should be the default value of 0. However, since the call occurs before the BSS is zeroed, the snp_vmpl variable may not actually be zero, which will cause the guest boot to fail. Since the decompressor relocates itself, the BSS would need to be cleared both before and after the relocation, but this would, in effect, cause all of the changes to BSS variables before relocation to be lost after relocation. Instead, move the snp_vmpl variable into the .data section so that it is initialized and the value made safe during relocation. As a pre-caution against future changes, move other SEV-related decompressor variables into the .data section, too. Fixes: 68a501d7fd82 ("x86/boot: Drop redundant RMPADJUST in SEV SVSM presence check") Signed-off-by: Tom Lendacky Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Ard Biesheuvel Reviewed-by: Changyuan Lyu Tested-by: Kevin Hui Tested-by: Changyuan Lyu Cc: stable@vger.kernel.org Link: https://patch.msgid.link/5648b7de5b0a5d0dfef3785f9582b718678c6448.1770217260.git.thomas.lendacky@amd.com Signed-off-by: Greg Kroah-Hartman commit a586788a669b6187daf7a57955c956d21555ba92 Author: Kim Phillips Date: Tue Feb 3 16:24:03 2026 -0600 x86/sev: Allow IBPB-on-Entry feature for SNP guests commit 9073428bb204d921ae15326bb7d4558d9d269aab upstream. The SEV-SNP IBPB-on-Entry feature does not require a guest-side implementation. It was added in Zen5 h/w, after the first SNP Zen implementation, and thus was not accounted for when the initial set of SNP features were added to the kernel. In its abundant precaution, commit 8c29f0165405 ("x86/sev: Add SEV-SNP guest feature negotiation support") included SEV_STATUS' IBPB-on-Entry bit as a reserved bit, thereby masking guests from using the feature. Allow guests to make use of IBPB-on-Entry when supported by the hypervisor, as the bit is now architecturally defined and safe to expose. Fixes: 8c29f0165405 ("x86/sev: Add SEV-SNP guest feature negotiation support") Signed-off-by: Kim Phillips Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Nikunj A Dadhania Reviewed-by: Tom Lendacky Cc: stable@kernel.org Link: https://patch.msgid.link/20260203222405.4065706-2-kim.phillips@amd.com Signed-off-by: Greg Kroah-Hartman commit c7258d2010e6d979180fc0365c5e087ddba026eb Author: Jan Stancek Date: Wed Feb 25 20:30:23 2026 +0100 x86/boot: Handle relative CONFIG_EFI_SBAT_FILE file paths commit 3d1973a0c76a78a4728cff13648a188ed486cf44 upstream. CONFIG_EFI_SBAT_FILE can be a relative path. When compiling using a different output directory (O=) the build currently fails because it can't find the filename set in CONFIG_EFI_SBAT_FILE: arch/x86/boot/compressed/sbat.S: Assembler messages: arch/x86/boot/compressed/sbat.S:6: Error: file not found: kernel.sbat Add $(srctree) as include dir for sbat.o. [ bp: Massage commit message. ] Fixes: 61b57d35396a ("x86/efi: Implement support for embedding SBAT data for x86") Signed-off-by: Jan Stancek Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Vitaly Kuznetsov Cc: Link: https://patch.msgid.link/f4eda155b0cef91d4d316b4e92f5771cb0aa7187.1772047658.git.jstancek@redhat.com Signed-off-by: Greg Kroah-Hartman commit 87aeec43ccb920abd28416ec9d20ebda64a12a64 Author: Zide Chen Date: Mon Feb 9 16:52:25 2026 -0800 perf/x86/intel/uncore: Add per-scheduler IMC CAS count events commit 6a8a48644c4b804123e59dbfc5d6cd29a0194046 upstream. IMC on SPR and EMR does not support sub-channels. In contrast, CPUs that use gnr_uncores[] (e.g. Granite Rapids and Sierra Forest) implement two command schedulers (SCH0/SCH1) per memory channel, providing logically independent command and data paths. Do not reuse the spr_uncore_imc[] configuration for these CPUs. Instead, introduce a dedicated gnr_uncore_imc[] with per-scheduler events, so userspace can monitor SCH0 and SCH1 independently. On these CPUs, replace cas_count_{read,write} with cas_count_{read,write}_sch{0,1}. This may break existing userspace that relies on cas_count_{read,write}, prompting it to switch to the per-scheduler events, as the legacy event reports only partial traffic (SCH0). Fixes: 632c4bf6d007 ("perf/x86/intel/uncore: Support Granite Rapids") Fixes: cb4a6ccf3583 ("perf/x86/intel/uncore: Support Sierra Forest and Grand Ridge") Reported-by: Reinette Chatre Signed-off-by: Zide Chen Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dapeng Mi Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260210005225.20311-1-zide.chen@intel.com Signed-off-by: Greg Kroah-Hartman commit f9e9cc320854a76a39e7bc92d144554f3a727fad Author: Mike Rapoport (Microsoft) Date: Wed Feb 25 08:55:55 2026 +0200 x86/efi: defer freeing of boot services memory commit a4b0bf6a40f3c107c67a24fbc614510ef5719980 upstream. efi_free_boot_services() frees memory occupied by EFI_BOOT_SERVICES_CODE and EFI_BOOT_SERVICES_DATA using memblock_free_late(). There are two issue with that: memblock_free_late() should be used for memory allocated with memblock_alloc() while the memory reserved with memblock_reserve() should be freed with free_reserved_area(). More acutely, with CONFIG_DEFERRED_STRUCT_PAGE_INIT=y efi_free_boot_services() is called before deferred initialization of the memory map is complete. Benjamin Herrenschmidt reports that this causes a leak of ~140MB of RAM on EC2 t3a.nano instances which only have 512MB or RAM. If the freed memory resides in the areas that memory map for them is still uninitialized, they won't be actually freed because memblock_free_late() calls memblock_free_pages() and the latter skips uninitialized pages. Using free_reserved_area() at this point is also problematic because __free_page() accesses the buddy of the freed page and that again might end up in uninitialized part of the memory map. Delaying the entire efi_free_boot_services() could be problematic because in addition to freeing boot services memory it updates efi.memmap without any synchronization and that's undesirable late in boot when there is concurrency. More robust approach is to only defer freeing of the EFI boot services memory. Split efi_free_boot_services() in two. First efi_unmap_boot_services() collects ranges that should be freed into an array then efi_free_boot_services() later frees them after deferred init is complete. Link: https://lore.kernel.org/all/ec2aaef14783869b3be6e3c253b2dcbf67dbc12a.camel@kernel.crashing.org Fixes: 916f676f8dc0 ("x86, efi: Retain boot service code until after switching to virtual mode") Cc: Signed-off-by: Mike Rapoport (Microsoft) Reviewed-by: Benjamin Herrenschmidt Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit aaca71f8562fbca3fc275621194cfb7f1b3a39ea Author: Werner Sembach Date: Thu Jan 8 17:09:54 2026 +0100 HID: multitouch: Keep latency normal on deactivate for reactivation gesture commit ec3070f01fa30f2c5547d645dbb76174304bf0e4 upstream. Uniwill devices have a built in gesture in the touchpad to de- and reactivate it by double taping the upper left corner. This gesture stops working when latency is set to high, so this patch keeps the latency on normal. Cc: stable@vger.kernel.org Signed-off-by: Werner Sembach [jkosina@suse.com: change bit from 24 to 25] [jkosina@suse.com: update shortlog] Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit d1edc027a4b0bb4c7a2670b530590b4df6177011 Author: Tomasz Pakuła Date: Wed Feb 4 22:44:55 2026 +0100 HID: pidff: Fix condition effect bit clearing commit 97d5c8f5c09a604c4873c8348f58de3cea69a7df upstream. As reported by MPDarkGuy on discord, NULL pointer dereferences were happening because not all the conditional effects bits were cleared. Properly clear all conditional effect bits from ffbit Fixes: 7f3d7bc0df4b ("HID: pidff: Better quirk assigment when searching for fields") Cc: stable@vger.kernel.org # 6.18.x Signed-off-by: Tomasz Pakuła Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 20864e3e41c74cda253a9fa6b6fe093c1461a6a9 Author: Greg Kroah-Hartman Date: Thu Feb 19 15:33:54 2026 +0100 HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them commit ecfa6f34492c493a9a1dc2900f3edeb01c79946b upstream. In commit 2ff5baa9b527 ("HID: appleir: Fix potential NULL dereference at raw event handle"), we handle the fact that raw event callbacks can happen even for a HID device that has not been "claimed" causing a crash if a broken device were attempted to be connected to the system. Fix up the remaining in-tree HID drivers that forgot to add this same check to resolve the same issue. Cc: Jiri Kosina Cc: Benjamin Tissoires Cc: Bastien Nocera Cc: linux-input@vger.kernel.org Cc: stable Assisted-by: gkh_clanker_2000 Signed-off-by: Greg Kroah-Hartman Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit b9a6064179994b3c1a583e048b498203dbe35b88 Author: Greg Kroah-Hartman Date: Mon Feb 23 13:10:31 2026 +0100 can: usb: f81604: handle bulk write errors properly commit 51f94780720fa90c424f67e3e9784cb8ef8190e5 upstream. If a write urb fails then more needs to be done other than just logging the message, otherwise the transmission could be stalled. Properly increment the error counters and wake up the queues so that data will continue to flow. Cc: Ji-Ze Hong (Peter Hong) Cc: Marc Kleine-Budde Cc: Vincent Mailhol Cc: stable@kernel.org Assisted-by: gkh_clanker_2000 Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2026022334-slackness-dynamic-9195@gregkh Fixes: 88da17436973 ("can: usb: f81604: add Fintek F81604 support") Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 36ead57443146e6b730ce1f48ca3e9b17e19a3d2 Author: Greg Kroah-Hartman Date: Mon Feb 23 13:10:30 2026 +0100 can: usb: f81604: handle short interrupt urb messages properly commit 7299b1b39a255f6092ce4ec0b65f66e9d6a357af upstream. If an interrupt urb is received that is not the correct length, properly detect it and don't attempt to treat the data as valid. Cc: Ji-Ze Hong (Peter Hong) Cc: Marc Kleine-Budde Cc: Vincent Mailhol Cc: stable@kernel.org Assisted-by: gkh_clanker_2000 Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2026022331-opal-evaluator-a928@gregkh Fixes: 88da17436973 ("can: usb: f81604: add Fintek F81604 support") Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 18eee279e9b5bff0db1aca9475ae4bc12804f05c Author: Greg Kroah-Hartman Date: Mon Feb 23 17:39:20 2026 +0100 can: usb: etas_es58x: correctly anchor the urb in the read bulk callback commit 5eaad4f768266f1f17e01232ffe2ef009f8129b7 upstream. When submitting an urb, that is using the anchor pattern, it needs to be anchored before submitting it otherwise it could be leaked if usb_kill_anchored_urbs() is called. This logic is correctly done elsewhere in the driver, except in the read bulk callback so do that here also. Cc: Vincent Mailhol Cc: Marc Kleine-Budde Cc: stable@kernel.org Assisted-by: gkh_clanker_2000 Signed-off-by: Greg Kroah-Hartman Reviewed-by: Vincent Mailhol Tested-by: Vincent Mailhol Link: https://patch.msgid.link/2026022320-poser-stiffly-9d84@gregkh Fixes: 8537257874e9 ("can: etas_es58x: add core support for ETAS ES58X CAN USB interfaces") Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit aa9e0a7fe5efc2f74327fd37d828e9a51d9ff588 Author: Greg Kroah-Hartman Date: Mon Feb 23 17:30:20 2026 +0100 can: ucan: Fix infinite loop from zero-length messages commit 1e446fd0582ad8be9f6dafb115fc2e7245f9bea7 upstream. If a broken ucan device gets a message with the message length field set to 0, then the driver will loop for forever in ucan_read_bulk_callback(), hanging the system. If the length is 0, just skip the message and go on to the next one. This has been fixed in the kvaser_usb driver in the past in commit 0c73772cd2b8 ("can: kvaser_usb: leaf: Fix potential infinite loop in command parsers"), so there must be some broken devices out there like this somewhere. Cc: Marc Kleine-Budde Cc: Vincent Mailhol Cc: stable@kernel.org Assisted-by: gkh_clanker_2000 Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2026022319-huff-absurd-6a18@gregkh Fixes: 9f2d3eae88d2 ("can: ucan: add driver for Theobroma Systems UCAN devices") Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit f6d80b104f904a6da922907394eec66d3e2ffc57 Author: Greg Kroah-Hartman Date: Mon Feb 23 13:10:32 2026 +0100 can: usb: f81604: correctly anchor the urb in the read bulk callback commit 952caa5da10bed22be09612433964f6877ba0dde upstream. When submitting an urb, that is using the anchor pattern, it needs to be anchored before submitting it otherwise it could be leaked if usb_kill_anchored_urbs() is called. This logic is correctly done elsewhere in the driver, except in the read bulk callback so do that here also. Cc: Ji-Ze Hong (Peter Hong) Cc: Marc Kleine-Budde Cc: Vincent Mailhol Cc: stable@kernel.org Assisted-by: gkh_clanker_2000 Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2026022334-starlight-scaling-2cea@gregkh Fixes: 88da17436973 ("can: usb: f81604: add Fintek F81604 support") Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 1cf469026d4a2308eaa91d04dca4a900d07a5c2e Author: Greg Kroah-Hartman Date: Mon Feb 23 17:51:17 2026 +0100 can: ems_usb: ems_usb_read_bulk_callback(): check the proper length of a message commit 38a01c9700b0dcafe97dfa9dc7531bf4a245deff upstream. When looking at the data in a USB urb, the actual_length is the size of the buffer passed to the driver, not the transfer_buffer_length which is set by the driver as the max size of the buffer. When parsing the messages in ems_usb_read_bulk_callback() properly check the size both at the beginning of parsing the message to make sure it is big enough for the expected structure, and at the end of the message to make sure we don't overflow past the end of the buffer for the next message. Cc: Vincent Mailhol Cc: Marc Kleine-Budde Cc: stable@kernel.org Assisted-by: gkh_clanker_2000 Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2026022316-answering-strainer-a5db@gregkh Fixes: 702171adeed3 ("ems_usb: Added support for EMS CPC-USB/ARM7 CAN/USB interface") Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit c3f1672eaea68c5cb6e1ec081cdb92045453218f Author: Greg Kroah-Hartman Date: Mon Feb 23 13:58:48 2026 +0100 net: usb: pegasus: validate USB endpoints commit 11de1d3ae5565ed22ef1f89d73d8f2d00322c699 upstream. The pegasus driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints. Cc: Petko Manolov Cc: stable Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2026022347-legibly-attest-cc5c@gregkh Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 011684cd18349aa4c52167c8ac37a0524169f48c Author: Greg Kroah-Hartman Date: Mon Feb 23 13:59:26 2026 +0100 net: usb: kalmia: validate USB endpoints commit c58b6c29a4c9b8125e8ad3bca0637e00b71e2693 upstream. The kalmia driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints. Cc: stable Signed-off-by: Greg Kroah-Hartman Reviewed-by: Simon Horman Fixes: d40261236e8e ("net/usb: Add Samsung Kalmia driver for Samsung GT-B3730") Link: https://patch.msgid.link/2026022326-shack-headstone-ef6f@gregkh Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2795fc06e7652c0ba299d936c584d5e08b6b57a1 Author: Greg Kroah-Hartman Date: Mon Feb 23 14:00:06 2026 +0100 net: usb: kaweth: validate USB endpoints commit 4b063c002ca759d1b299988ee23f564c9609c875 upstream. The kaweth driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints. Cc: stable Signed-off-by: Greg Kroah-Hartman Reviewed-by: Simon Horman Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Link: https://patch.msgid.link/2026022305-substance-virtual-c728@gregkh Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 00477cab053dc4816b99141d8fcca7a479cfebeb Author: Greg Kroah-Hartman Date: Mon Feb 23 12:28:30 2026 +0100 nfc: pn533: properly drop the usb interface reference on disconnect commit 12133a483dfa832241fbbf09321109a0ea8a520e upstream. When the device is disconnected from the driver, there is a "dangling" reference count on the usb interface that was grabbed in the probe callback. Fix this up by properly dropping the reference after we are done with it. Cc: stable Signed-off-by: Greg Kroah-Hartman Reviewed-by: Simon Horman Fixes: c46ee38620a2 ("NFC: pn533: add NXP pn533 nfc device driver") Link: https://patch.msgid.link/2026022329-flashing-ought-7573@gregkh Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit cfd94642025e6f71c8f754bdec0800ee95e4f3dd Author: Jens Axboe Date: Tue Feb 24 11:51:16 2026 -0700 media: dvb-core: fix wrong reinitialization of ringbuffer on reopen commit bfbc0b5b32a8f28ce284add619bf226716a59bc0 upstream. dvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the DVR device. dvb_ringbuffer_init() calls init_waitqueue_head(), which reinitializes the waitqueue list head to empty. Since dmxdev->dvr_buffer.queue is a shared waitqueue (all opens of the same DVR device share it), this orphans any existing waitqueue entries from io_uring poll or epoll, leaving them with stale prev/next pointers while the list head is reset to {self, self}. The waitqueue and spinlock in dvr_buffer are already properly initialized once in dvb_dmxdev_init(). The open path only needs to reset the buffer data pointer, size, and read/write positions. Replace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct assignment of data/size and a call to dvb_ringbuffer_reset(), which properly resets pread, pwrite, and error with correct memory ordering without touching the waitqueue or spinlock. Cc: stable@vger.kernel.org Fixes: 34731df288a5f ("V4L/DVB (3501): Dmxdev: use dvb_ringbuffer") Reported-by: syzbot+ab12f0c08dd7ab8d057c@syzkaller.appspotmail.com Tested-by: syzbot+ab12f0c08dd7ab8d057c@syzkaller.appspotmail.com Link: https://lore.kernel.org/all/698a26d3.050a0220.3b3015.007d.GAE@google.com/ Signed-off-by: Jens Axboe Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3acc627f235a903289a16753056dc63a0bb2758a Author: Christian Brauner Date: Thu Jan 29 14:52:22 2026 +0100 namespace: fix proc mount iteration commit 4a403d7aa9074f527f064ef0806aaab38d14b07c upstream. The m->index isn't updated when m->show() overflows and retains its value before the current mount causing a restart to start at the same value. If that happens in short order to due a quickly expanding mount table this would cause the same mount to be shown again and again. Ensure that *pos always equals the mount id of the mount that was returned by start/next. On restart after overflow mnt_find_id_at(*pos) finds the exact mount. This should avoid duplicates, avoid skips and should handle concurrent modification just fine. Cc: Fixed: 2eea9ce4310d8 ("mounts: keep list of mounts in an rbtree") Link: https://patch.msgid.link/20260129-geleckt-treuhand-4bb940acacd9@brauner Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit a80161c20370df7b03d2bee00b43aa009e299ad7 Author: Jann Horn Date: Mon Feb 23 20:59:33 2026 +0100 eventpoll: Fix integer overflow in ep_loop_check_proc() commit fdcfce93073d990ed4b71752e31ad1c1d6e9d58b upstream. If a recursive call to ep_loop_check_proc() hits the `result = INT_MAX`, an integer overflow will occur in the calling ep_loop_check_proc() at `result = max(result, ep_loop_check_proc(ep_tovisit, depth + 1) + 1)`, breaking the recursion depth check. Fix it by using a different placeholder value that can't lead to an overflow. Reported-by: Guenter Roeck Fixes: f2e467a48287 ("eventpoll: Fix semi-unbounded recursion") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn Link: https://patch.msgid.link/20260223-epoll-int-overflow-v1-1-452f35132224@google.com Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit 14a1db2486fa282aa61db906e4775d9b747f9d8e Author: Ethan Nelson-Moore Date: Thu Feb 12 20:55:09 2026 -0800 net: arcnet: com20020-pci: fix support for 2.5Mbit cards [ Upstream commit c7d9be66b71af490446127c6ffcb66d6bb71b8b9 ] Commit 8c14f9c70327 ("ARCNET: add com20020 PCI IDs with metadata") converted the com20020-pci driver to use a card info structure instead of a single flag mask in driver_data. However, it failed to take into account that in the original code, driver_data of 0 indicates a card with no special flags, not a card that should not have any card info structure. This introduced a null pointer dereference when cards with no flags were probed. Commit bd6f1fd5d33d ("net: arcnet: com20020: Fix null-ptr-deref in com20020pci_probe()") then papered over this issue by rejecting cards with no driver_data instead of resolving the problem at its source. Fix the original issue by introducing a new card info structure for 2.5Mbit cards that does not set any flags and using it if no driver_data is present. Fixes: 8c14f9c70327 ("ARCNET: add com20020 PCI IDs with metadata") Fixes: bd6f1fd5d33d ("net: arcnet: com20020: Fix null-ptr-deref in com20020pci_probe()") Cc: stable@vger.kernel.org Reviewed-by: Simon Horman Signed-off-by: Ethan Nelson-Moore Link: https://patch.msgid.link/20260213045510.32368-1-enelsonmoore@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 9498fa25a0b0d8c095ce3d1f15d7864228692822 Author: Imre Deak Date: Mon Feb 9 15:38:16 2026 +0200 drm/i915/dp: Fix pipe BPP clamping due to HDR [ Upstream commit fe26ae6ac8b88fcdac5036b557c129a17fe520d2 ] The pipe BPP value shouldn't be set outside of the source's / sink's valid pipe BPP range, ensure this when increasing the minimum pipe BPP value to 30 due to HDR. While at it debug print if the HDR mode was requested for a connector by setting the corresponding HDR connector property. This indicates if the requested HDR mode could not be enabled, since the selected pipe BPP is below 30, due to a sink capability or link BW limit. v2: - Also handle the case where the sink could support the target 30 BPP only in DSC mode due to a BW limit, but the sink doesn't support DSC or 30 BPP as a DSC input BPP. (Chaitanya) - Debug print the connector's HDR mode in the link config dump, to indicate if a BPP >= 30 required by HDR couldn't be reached. (Ankit) - Add Closes: trailer. (Ankit) - Don't print the 30 BPP-outside of valid BPP range debug message if the min BPP is already > 30 (and so a target BPP >= 30 required for HDR is ensured). Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7052 Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15503 Fixes: ba49a4643cf53 ("drm/i915/dp: Set min_bpp limit to 30 in HDR mode") Cc: Chaitanya Kumar Borah Cc: # v6.18+ Reviewed-by: Ankit Nautiyal # v1 Reviewed-by: Chaitanya Kumar Borah Signed-off-by: Imre Deak Link: https://patch.msgid.link/20260209133817.395823-1-imre.deak@intel.com (cherry picked from commit 08b7ef16b6a03e8c966e286ee1ac608a6ffb3d4a) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin commit 99f617ea2ff017b0ba10d5371d83345331091afa Author: Imre Deak Date: Mon Dec 15 21:23:56 2025 +0200 drm/i915/dp: Fail state computation for invalid DSC source input BPP values [ Upstream commit 338465490cf7bd4a700ecd33e4855fee4622fa5f ] There is no reason to accept an invalid minimum/maximum DSC source input BPP value (i.e a minimum DSC input BPP value above the maximum pipe BPP or a maximum DSC input BPP value below the minimum pipe BPP value), fail the state computation in these cases. Reviewed-by: Vinod Govindapillai Signed-off-by: Imre Deak Link: https://patch.msgid.link/20251215192357.172201-17-imre.deak@intel.com Stable-dep-of: fe26ae6ac8b8 ("drm/i915/dp: Fix pipe BPP clamping due to HDR") Signed-off-by: Sasha Levin commit b05ed70feb668da5ed4f4c352f51497c56aad638 Author: Tiezhu Yang Date: Tue Feb 10 19:31:14 2026 +0800 LoongArch: Remove some extern variables in source files [ Upstream commit 0e6f596d6ac635e80bb265d587b2287ef8fa1cd6 ] There are declarations of the variable "eentry", "pcpu_handlers[]" and "exception_handlers[]" in asm/setup.h, the source files already include this header file directly or indirectly, so no need to declare them in the source files, just remove the code. Cc: stable@vger.kernel.org Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 079deecc2c9f5bef4c6cbec66f4076a5542370ba Author: Tiezhu Yang Date: Tue Feb 10 19:31:13 2026 +0800 LoongArch: Handle percpu handler address for ORC unwinder [ Upstream commit 055c7e75190e0be43037bd663a3f6aced194416e ] After commit 4cd641a79e69 ("LoongArch: Remove unnecessary checks for ORC unwinder"), the system can not boot normally under some configs (such as enable KASAN), there are many error messages "cannot find unwind pc". The kernel boots normally with the defconfig, so no problem found out at the first time. Here is one way to reproduce: cd linux make mrproper defconfig -j"$(nproc)" scripts/config -e KASAN make olddefconfig all -j"$(nproc)" sudo make modules_install sudo make install sudo reboot The address that can not unwind is not a valid kernel address which is between "pcpu_handlers[cpu]" and "pcpu_handlers[cpu] + vec_sz" due to the code of eentry was copied to the new area of pcpu_handlers[cpu] in setup_tlb_handler(), handle this special case to get the valid address to unwind normally. Cc: stable@vger.kernel.org Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit e7c58045ad8c267932105da091b6d21836128ea6 Author: Tiezhu Yang Date: Wed Dec 31 15:19:19 2025 +0800 LoongArch: Remove unnecessary checks for ORC unwinder [ Upstream commit 4cd641a79e69270a062777f64a0dd330abb9044a ] According to the following function definitions, __kernel_text_address() already checks __module_text_address(), so it should remove the check of __module_text_address() in bt_address() at least. int __kernel_text_address(unsigned long addr) { if (kernel_text_address(addr)) return 1; ... return 0; } int kernel_text_address(unsigned long addr) { bool no_rcu; int ret = 1; ... if (is_module_text_address(addr)) goto out; ... return ret; } bool is_module_text_address(unsigned long addr) { guard(rcu)(); return __module_text_address(addr) != NULL; } Furthermore, there are two checks of __kernel_text_address(), one is in bt_address() and the other is after calling bt_address(), it looks like redundant. Handle the exception address first and then use __kernel_text_address() to validate the calculated address for exception or the normal address in bt_address(), then it can remove the check of __kernel_text_address() after calling bt_address(). Just remove unnecessary checks, no functional changes intended. Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Stable-dep-of: 055c7e75190e ("LoongArch: Handle percpu handler address for ORC unwinder") Signed-off-by: Sasha Levin commit e653c0718cf573f9851ab07d31b4fa4c65bfdd6f Author: Harry Yoo Date: Tue Feb 10 17:19:00 2026 +0900 mm/slab: use prandom if !allow_spin [ Upstream commit a1e244a9f177894969c6cd5ebbc6d72c19fc4a7a ] When CONFIG_SLAB_FREELIST_RANDOM is enabled and get_random_u32() is called in an NMI context, lockdep complains because it acquires a local_lock: ================================ WARNING: inconsistent lock state 6.19.0-rc5-slab-for-next+ #325 Tainted: G N -------------------------------- inconsistent {INITIAL USE} -> {IN-NMI} usage. kunit_try_catch/8312 [HC2[2]:SC0[0]:HE0:SE1] takes: ffff88a02ec49cc0 (batched_entropy_u32.lock){-.-.}-{3:3}, at: get_random_u32+0x7f/0x2e0 {INITIAL USE} state was registered at: lock_acquire+0xd9/0x2f0 get_random_u32+0x93/0x2e0 __get_random_u32_below+0x17/0x70 cache_random_seq_create+0x121/0x1c0 init_cache_random_seq+0x5d/0x110 do_kmem_cache_create+0x1e0/0xa30 __kmem_cache_create_args+0x4ec/0x830 create_kmalloc_caches+0xe6/0x130 kmem_cache_init+0x1b1/0x660 mm_core_init+0x1d8/0x4b0 start_kernel+0x620/0xcd0 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0xf3/0x140 common_startup_64+0x13e/0x148 irq event stamp: 76 hardirqs last enabled at (75): [] exc_nmi+0x11a/0x240 hardirqs last disabled at (76): [] sysvec_irq_work+0x11/0x110 softirqs last enabled at (0): [] copy_process+0xc7a/0x2350 softirqs last disabled at (0): [<0000000000000000>] 0x0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(batched_entropy_u32.lock); lock(batched_entropy_u32.lock); *** DEADLOCK *** Fix this by using pseudo-random number generator if !allow_spin. This means kmalloc_nolock() users won't get truly random numbers, but there is not much we can do about it. Note that an NMI handler might interrupt prandom_u32_state() and change the random state, but that's safe. Link: https://lore.kernel.org/all/0c33bdee-6de8-4d9f-92ca-4f72c1b6fb9f@suse.cz Fixes: af92793e52c3 ("slab: Introduce kmalloc_nolock() and kfree_nolock().") Cc: stable@vger.kernel.org Signed-off-by: Harry Yoo Link: https://patch.msgid.link/20260210081900.329447-3-harry.yoo@oracle.com Signed-off-by: Vlastimil Babka Signed-off-by: Sasha Levin commit d3043852fffa5491db5f2ea7e28a107ab34e64ef Author: Vlastimil Babka Date: Wed Nov 5 10:05:32 2025 +0100 slub: remove CONFIG_SLUB_TINY specific code paths [ Upstream commit 31e0886fd57d426d18a239dd55e176032c9c1cb0 ] CONFIG_SLUB_TINY minimizes the SLUB's memory overhead in multiple ways, mainly by avoiding percpu caching of slabs and objects. It also reduces code size by replacing some code paths with simplified ones through ifdefs, but the benefits of that are smaller and would complicate the upcoming changes. Thus remove these code paths and associated ifdefs and simplify the code base. Link: https://patch.msgid.link/20251105-sheaves-cleanups-v1-4-b8218e1ac7ef@suse.cz Reviewed-by: Harry Yoo Signed-off-by: Vlastimil Babka Stable-dep-of: a1e244a9f177 ("mm/slab: use prandom if !allow_spin") Signed-off-by: Sasha Levin commit 58aef054b2908c0f0f9d3951c8057e0e2db32781 Author: Gui-Dong Han Date: Tue Feb 3 20:14:43 2026 +0800 hwmon: (max16065) Use READ/WRITE_ONCE to avoid compiler optimization induced race [ Upstream commit 007be4327e443d79c9dd9e56dc16c36f6395d208 ] Simply copying shared data to a local variable cannot prevent data races. The compiler is allowed to optimize away the local copy and re-read the shared memory, causing a Time-of-Check Time-of-Use (TOCTOU) issue if the data changes between the check and the usage. To enforce the use of the local variable, use READ_ONCE() when reading the shared data and WRITE_ONCE() when updating it. Apply these macros to the three identified locations (curr_sense, adc, and fault) where local variables are used for error validation, ensuring the value remains consistent. Reported-by: Ben Hutchings Closes: https://lore.kernel.org/all/6fe17868327207e8b850cf9f88b7dc58b2021f73.camel@decadent.org.uk/ Fixes: f5bae2642e3d ("hwmon: Driver for MAX16065 System Manager and compatibles") Fixes: b8d5acdcf525 ("hwmon: (max16065) Use local variable to avoid TOCTOU") Cc: stable@vger.kernel.org Signed-off-by: Gui-Dong Han Link: https://lore.kernel.org/r/20260203121443.5482-1-hanguidong02@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 378dff71efddd15f34124bf9d7c98cd69cd05286 Author: Mario Limonciello Date: Thu Feb 5 10:42:54 2026 -0600 drm/amd: Fix hang on amdgpu unload by using pci_dev_is_disconnected() [ Upstream commit f7afda7fcd169a9168695247d07ad94cf7b9798f ] The commit 6a23e7b4332c ("drm/amd: Clean up kfd node on surprise disconnect") introduced early KFD cleanup when drm_dev_is_unplugged() returns true. However, this causes hangs during normal module unload (rmmod amdgpu). The issue occurs because drm_dev_unplug() is called in amdgpu_pci_remove() for all removal scenarios, not just surprise disconnects. This was done intentionally in commit 39934d3ed572 ("Revert "drm/amdgpu: TA unload messages are not actually sent to psp when amdgpu is uninstalled"") to fix IGT PCI software unplug test failures. As a result, drm_dev_is_unplugged() returns true even during normal module unload, triggering the early KFD cleanup inappropriately. The correct check should distinguish between: - Actual surprise disconnect (eGPU unplugged): pci_dev_is_disconnected() returns true - Normal module unload (rmmod): pci_dev_is_disconnected() returns false Replace drm_dev_is_unplugged() with pci_dev_is_disconnected() to ensure the early cleanup only happens during true hardware disconnect events. Cc: stable@vger.kernel.org Reported-by: Cal Peake Closes: https://lore.kernel.org/all/b0c22deb-c0fa-3343-33cf-fd9a77d7db99@absolutedigital.net/ Fixes: 6a23e7b4332c ("drm/amd: Clean up kfd node on surprise disconnect") Acked-by: Alex Deucher Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 6c80b35076bcf4e2d43be0f81d61926211b8959d Author: Xuewen Yan Date: Wed Feb 4 13:25:09 2026 +0100 PM: sleep: core: Avoid bit field races related to work_in_progress [ Upstream commit 0491f3f9f664e7e0131eb4d2a8b19c49562e5c64 ] In all of the system suspend transition phases, the async processing of a device may be carried out in parallel with power.work_in_progress updates for the device's parent or suppliers and if it touches bit fields from the same group (for example, power.must_resume or power.wakeup_path), bit field corruption is possible. To avoid that, turn work_in_progress in struct dev_pm_info into a proper bool field and relocate it to save space. Fixes: aa7a9275ab81 ("PM: sleep: Suspend async parents after suspending children") Fixes: 443046d1ad66 ("PM: sleep: Make suspend of devices more asynchronous") Signed-off-by: Xuewen Yan Closes: https://lore.kernel.org/linux-pm/20260203063459.12808-1-xuewen.yan@unisoc.com/ Cc: All applicable [ rjw: Added subject and changelog ] Link: https://patch.msgid.link/CAB8ipk_VX2VPm706Jwa1=8NSA7_btWL2ieXmBgHr2JcULEP76g@mail.gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 5ec1d82f00b1c2d928304b8342b8c572cbcbe6fd Author: Naohiro Aota Date: Fri Jan 23 21:41:36 2026 +0900 btrfs: zoned: fixup last alloc pointer after extent removal for RAID0/10 [ Upstream commit 52ee9965d09b2c56a027613db30d1fb20d623861 ] When a block group is composed of a sequential write zone and a conventional zone, we recover the (pseudo) write pointer of the conventional zone using the end of the last allocated position. However, if the last extent in a block group is removed, the last extent position will be smaller than the other real write pointer position. Then, that will cause an error due to mismatch of the write pointers. We can fixup this case by moving the alloc_offset to the corresponding write pointer position. Fixes: 568220fa9657 ("btrfs: zoned: support RAID0/1/10 on top of raid stripe tree") CC: stable@vger.kernel.org # 6.12+ Reviewed-by: Johannes Thumshirn Signed-off-by: Naohiro Aota Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 4b508c53f3c50d8d85985214077a71778478c2cc Author: Miquel Sabaté Solà Date: Fri Oct 24 12:21:41 2025 +0200 btrfs: define the AUTO_KFREE/AUTO_KVFREE helper macros [ Upstream commit d00cbce0a7d5de5fc31bf60abd59b44d36806b6e ] These are two simple macros which ensure that a pointer is initialized to NULL and with the proper cleanup attribute for it. Signed-off-by: Miquel Sabaté Solà Reviewed-by: David Sterba Signed-off-by: David Sterba Stable-dep-of: 52ee9965d09b ("btrfs: zoned: fixup last alloc pointer after extent removal for RAID0/10") Signed-off-by: Sasha Levin commit d2cfea67b1b9552d47d6adf97ce323ee11f01ecc Author: Khushit Shah Date: Fri Jan 23 12:56:25 2026 +0000 KVM: x86: Add x2APIC "features" to control EOI broadcast suppression [ Upstream commit 6517dfbcc918f970a928d9dc17586904bac06893 ] Add two flags for KVM_CAP_X2APIC_API to allow userspace to control support for Suppress EOI Broadcasts when using a split IRQCHIP (I/O APIC emulated by userspace), which KVM completely mishandles. When x2APIC support was first added, KVM incorrectly advertised and "enabled" Suppress EOI Broadcast, without fully supporting the I/O APIC side of the equation, i.e. without adding directed EOI to KVM's in-kernel I/O APIC. That flaw was carried over to split IRQCHIP support, i.e. KVM advertised support for Suppress EOI Broadcasts irrespective of whether or not the userspace I/O APIC implementation supported directed EOIs. Even worse, KVM didn't actually suppress EOI broadcasts, i.e. userspace VMMs without support for directed EOI came to rely on the "spurious" broadcasts. KVM "fixed" the in-kernel I/O APIC implementation by completely disabling support for Suppress EOI Broadcasts in commit 0bcc3fb95b97 ("KVM: lapic: stop advertising DIRECTED_EOI when in-kernel IOAPIC is in use"), but didn't do anything to remedy userspace I/O APIC implementations. KVM's bogus handling of Suppress EOI Broadcast is problematic when the guest relies on interrupts being masked in the I/O APIC until well after the initial local APIC EOI. E.g. Windows with Credential Guard enabled handles interrupts in the following order: 1. Interrupt for L2 arrives. 2. L1 APIC EOIs the interrupt. 3. L1 resumes L2 and injects the interrupt. 4. L2 EOIs after servicing. 5. L1 performs the I/O APIC EOI. Because KVM EOIs the I/O APIC at step #2, the guest can get an interrupt storm, e.g. if the IRQ line is still asserted and userspace reacts to the EOI by re-injecting the IRQ, because the guest doesn't de-assert the line until step #4, and doesn't expect the interrupt to be re-enabled until step #5. Unfortunately, simply "fixing" the bug isn't an option, as KVM has no way of knowing if the userspace I/O APIC supports directed EOIs, i.e. suppressing EOI broadcasts would result in interrupts being stuck masked in the userspace I/O APIC due to step #5 being ignored by userspace. And fully disabling support for Suppress EOI Broadcast is also undesirable, as picking up the fix would require a guest reboot, *and* more importantly would change the virtual CPU model exposed to the guest without any buy-in from userspace. Add KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST and KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST flags to allow userspace to explicitly enable or disable support for Suppress EOI Broadcasts. This gives userspace control over the virtual CPU model exposed to the guest, as KVM should never have enabled support for Suppress EOI Broadcast without userspace opt-in. Not setting either flag will result in legacy quirky behavior for backward compatibility. Disallow fully enabling SUPPRESS_EOI_BROADCAST when using an in-kernel I/O APIC, as KVM's history/support is just as tragic. E.g. it's not clear that commit c806a6ad35bf ("KVM: x86: call irq notifiers with directed EOI") was entirely correct, i.e. it may have simply papered over the lack of Directed EOI emulation in the I/O APIC. Note, Suppress EOI Broadcasts is defined only in Intel's SDM, not in AMD's APM. But the bit is writable on some AMD CPUs, e.g. Turin, and KVM's ABI is to support Directed EOI (KVM's name) irrespective of guest CPU vendor. Fixes: 7543a635aa09 ("KVM: x86: Add KVM exit for IOAPIC EOIs") Closes: https://lore.kernel.org/kvm/7D497EF1-607D-4D37-98E7-DAF95F099342@nutanix.com Cc: stable@vger.kernel.org Suggested-by: David Woodhouse Signed-off-by: Khushit Shah Link: https://patch.msgid.link/20260123125657.3384063-1-khushit.shah@nutanix.com [sean: clean up minor formatting goofs and fix a comment typo] Co-developed-by: Sean Christopherson Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin commit c6db0f4a1659edc13445f3fadbbd205ee1a429d9 Author: Aksh Garg Date: Fri Jan 30 17:25:14 2026 +0530 PCI: dwc: ep: Fix resizable BAR support for multi-PF configurations [ Upstream commit 43d67ec26b329f8aea34ba9dff23d69b84a8e564 ] The resizable BAR support added by the commit 3a3d4cabe681 ("PCI: dwc: ep: Allow EPF drivers to configure the size of Resizable BARs") incorrectly configures the resizable BARs only for the first Physical Function (PF0) in EP mode. The resizable BAR configuration functions use generic dw_pcie_*_dbi() operations instead of physical function specific dw_pcie_ep_*_dbi() operations. This causes resizable BAR configuration to always target PF0 regardless of the requested function number. Additionally, dw_pcie_ep_init_non_sticky_registers() only initializes resizable BAR registers for PF0, leaving other PFs unconfigured during the execution of this function. Fix this by using physical function specific configuration space access operations throughout the resizable BAR code path and initializing registers for all the physical functions that support resizable BARs. Fixes: 3a3d4cabe681 ("PCI: dwc: ep: Allow EPF drivers to configure the size of Resizable BARs") Signed-off-by: Aksh Garg [mani: added stable tag] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Niklas Cassel Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260130115516.515082-2-a-garg7@ti.com Signed-off-by: Sasha Levin commit 7c0c4b7e84b7f35b3dc147cc537eac455869a64f Author: Qiang Yu Date: Wed Dec 24 02:10:46 2025 -0800 PCI: dwc: Remove duplicate dw_pcie_ep_hide_ext_capability() function [ Upstream commit 86291f774fe8524178446cb2c792939640b4970c ] Remove dw_pcie_ep_hide_ext_capability() and replace its usage with dw_pcie_remove_ext_capability(). Both functions serve the same purpose of hiding PCIe extended capabilities, but dw_pcie_remove_ext_capability() provides a cleaner API that doesn't require the caller to specify the previous capability ID. Suggested-by: Niklas Cassel Signed-off-by: Qiang Yu Signed-off-by: Manivannan Sadhasivam Tested-by: Niklas Cassel Link: https://patch.msgid.link/20251224-remove_dw_pcie_ep_hide_ext_capability-v1-1-4302c9cdc316@oss.qualcomm.com Stable-dep-of: 43d67ec26b32 ("PCI: dwc: ep: Fix resizable BAR support for multi-PF configurations") Signed-off-by: Sasha Levin commit 794b08c5012807c44030f1510cf34b068cd908b0 Author: Qiang Yu Date: Sun Nov 9 22:59:41 2025 -0800 PCI: dwc: Add new APIs to remove standard and extended Capability [ Upstream commit 0183562f1e824c0ca6c918309a0978e9a269af3e ] On some platforms, certain PCIe Capabilities may be present in hardware but are not fully implemented as defined in PCIe spec. These incomplete capabilities should be hidden from the PCI framework to prevent unexpected behavior. Introduce two APIs to remove a specific PCIe Capability and Extended Capability by updating the previous capability's next offset field to skip over the unwanted capability. These APIs allow RC drivers to easily hide unsupported or partially implemented capabilities from software. Co-developed-by: Wenbin Yao Signed-off-by: Wenbin Yao Signed-off-by: Qiang Yu Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20251109-remove_cap-v1-2-2208f46f4dc2@oss.qualcomm.com Stable-dep-of: 43d67ec26b32 ("PCI: dwc: ep: Fix resizable BAR support for multi-PF configurations") Signed-off-by: Sasha Levin commit 26f9e895616baed79091295605cab3b47e713cec Author: Qiang Yu Date: Sun Nov 9 22:59:40 2025 -0800 PCI: Add preceding capability position support in PCI_FIND_NEXT_*_CAP macros [ Upstream commit a2582e05e39adf9ab82a02561cd6f70738540ae0 ] Add support for finding the preceding capability position in PCI capability list by extending the capability finding macros with an additional parameter. This functionality is essential for modifying PCI capability list, as it provides the necessary information to update the "next" pointer of the predecessor capability when removing entries. Modify two macros to accept a new 'prev_ptr' parameter: - PCI_FIND_NEXT_CAP - Now accepts 'prev_ptr' parameter for standard capabilities - PCI_FIND_NEXT_EXT_CAP - Now accepts 'prev_ptr' parameter for extended capabilities When a capability is found, these macros: - Store the position of the preceding capability in *prev_ptr (if prev_ptr != NULL) - Maintain all existing functionality when prev_ptr is NULL Update current callers to accommodate this API change by passing NULL to 'prev_ptr' argument if they do not care about the preceding capability position. No functional changes to driver behavior result from this commit as it maintains the existing capability finding functionality while adding the infrastructure for future capability removal operations. Signed-off-by: Qiang Yu Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20251109-remove_cap-v1-1-2208f46f4dc2@oss.qualcomm.com Stable-dep-of: 43d67ec26b32 ("PCI: dwc: ep: Fix resizable BAR support for multi-PF configurations") Signed-off-by: Sasha Levin commit 7d610f643b04a3fe854e03861136760c22677a67 Author: Bence Csókás Date: Thu Aug 14 09:47:44 2025 +0200 ARM: dts: imx53-usbarmory: Replace license text comment with SPDX identifier [ Upstream commit faa6baa36497958dd8fd5561daa37249779446d7 ] Replace verbatim license text with a `SPDX-License-Identifier`. The comment header mis-attributes this license to be "X11", but the license text does not include the last line "Except as contained in this notice, the name of the X Consortium shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from the X Consortium.". Therefore, this license is actually equivalent to the SPDX "MIT" license (confirmed by text diffing). Cc: Andrej Rosano Signed-off-by: Bence Csókás Acked-by: Andrej Rosano Signed-off-by: Shawn Guo Stable-dep-of: 43d67ec26b32 ("PCI: dwc: ep: Fix resizable BAR support for multi-PF configurations") Signed-off-by: Sasha Levin commit f50c91272425b277dce6dd366cbaa094420f8683 Author: Nathan Chancellor Date: Wed Jan 14 16:27:11 2026 -0700 ACPI: APEI: GHES: Disable KASAN instrumentation when compile testing with clang < 18 [ Upstream commit b584bfbd7ec417f257f651cc00a90c66e31dfbf1 ] After a recent innocuous change to drivers/acpi/apei/ghes.c, building ARCH=arm64 allmodconfig with clang-17 or older (which has both CONFIG_KASAN=y and CONFIG_WERROR=y) fails with: drivers/acpi/apei/ghes.c:902:13: error: stack frame size (2768) exceeds limit (2048) in 'ghes_do_proc' [-Werror,-Wframe-larger-than] 902 | static void ghes_do_proc(struct ghes *ghes, | ^ A KASAN pass that removes unneeded stack instrumentation, enabled by default in clang-18 [1], drastically improves stack usage in this case. To avoid the warning in the common allmodconfig case when it can break the build, disable KASAN for ghes.o when compile testing with clang-17 and older. Disabling KASAN outright may hide legitimate runtime issues, so live with the warning in that case; the user can either increase the frame warning limit or disable -Werror, which they should probably do when debugging with KASAN anyways. Closes: https://github.com/ClangBuiltLinux/linux/issues/2148 Link: https://github.com/llvm/llvm-project/commit/51fbab134560ece663517bf1e8c2a30300d08f1a [1] Signed-off-by: Nathan Chancellor Cc: All applicable Link: https://patch.msgid.link/20260114-ghes-avoid-wflt-clang-older-than-18-v1-1-9c8248bfe4f4@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 0a654ac440c1289060692a9bd07c972e7181beef Author: Fabio M. De Francesco Date: Wed Jan 14 11:14:23 2026 +0100 ACPI: APEI: GHES: Add helper for CPER CXL protocol errors checks [ Upstream commit 70205869686212eb8e4cddf02bf87fd5fd597bc2 ] Move the CPER CXL protocol errors validity check out of cxl_cper_post_prot_err() to new cxl_cper_sec_prot_err_valid() and limit the serial number check only to CXL agents that are CXL devices (UEFI v2.10, Appendix N.2.13). Export the new symbol for reuse by ELOG. Reviewed-by: Dave Jiang Reviewed-by: Hanjun Guo Reviewed-by: Jonathan Cameron Signed-off-by: Fabio M. De Francesco [ rjw: Subject tweak ] Link: https://patch.msgid.link/20260114101543.85926-4-fabio.m.de.francesco@linux.intel.com Signed-off-by: Rafael J. Wysocki Stable-dep-of: b584bfbd7ec4 ("ACPI: APEI: GHES: Disable KASAN instrumentation when compile testing with clang < 18") Signed-off-by: Sasha Levin commit baf4b13a4efc89c29946c842f62d8da2323ca8ab Author: Johan Hovold Date: Fri Nov 21 17:40:03 2025 +0100 clk: tegra: tegra124-emc: fix device leak on set_rate() [ Upstream commit da61439c63d34ae6503d080a847f144d587e3a48 ] Make sure to drop the reference taken when looking up the EMC device and its driver data on first set_rate(). Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference. Fixes: 2db04f16b589 ("clk: tegra: Add EMC clock driver") Fixes: 6d6ef58c2470 ("clk: tegra: tegra124-emc: Fix missing put_device() call in emc_ensure_emc_driver") Cc: stable@vger.kernel.org # 4.2: 6d6ef58c2470 Cc: Mikko Perttunen Cc: Miaoqian Lin Signed-off-by: Johan Hovold Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit e5bdc2159f8b04f86aff35d36b24062588ff8092 Author: Shawn Lin Date: Mon Jan 5 16:15:29 2026 +0800 arm64: dts: rockchip: Fix rk3588 PCIe range mappings [ Upstream commit 46c56b737161060dfa468f25ae699749047902a2 ] The pcie bus address should be mapped 1:1 to the cpu side MMIO address, so that there is no same address allocated from normal system memory. Otherwise it's broken if the same address assigned to the EP for DMA purpose.Fix it to sync with the vendor BSP. Fixes: 0acf4fa7f187 ("arm64: dts: rockchip: add PCIe3 support for rk3588") Fixes: 8d81b77f4c49 ("arm64: dts: rockchip: add rk3588 PCIe2 support") Cc: stable@vger.kernel.org Cc: Sebastian Reichel Signed-off-by: Shawn Lin Link: https://patch.msgid.link/1767600929-195341-2-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 7f8f4acf392692cf879196807eccdf23521e5baf Author: Shawn Lin Date: Mon Jan 5 16:15:28 2026 +0800 arm64: dts: rockchip: Fix rk356x PCIe range mappings [ Upstream commit f63ea193a404481f080ca2958f73e9f364682db9 ] The pcie bus address should be mapped 1:1 to the cpu side MMIO address, so that there is no same address allocated from normal system memory. Otherwise it's broken if the same address assigned to the EP for DMA purpose.Fix it to sync with the vendor BSP. Fixes: 568a67e742df ("arm64: dts: rockchip: Fix rk356x PCIe register and range mappings") Fixes: 66b51ea7d70f ("arm64: dts: rockchip: Add rk3568 PCIe2x1 controller") Cc: stable@vger.kernel.org Cc: Andrew Powers-Holmes Signed-off-by: Shawn Lin Link: https://patch.msgid.link/1767600929-195341-1-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit e70d5feb10c5ba2bbf7ca400b8f39a2f82d653e8 Author: Jinhui Guo Date: Thu Jan 22 09:48:50 2026 +0800 iommu/vt-d: Skip dev-iotlb flush for inaccessible PCIe device without scalable mode [ Upstream commit 42662d19839f34735b718129ea200e3734b07e50 ] PCIe endpoints with ATS enabled and passed through to userspace (e.g., QEMU, DPDK) can hard-lock the host when their link drops, either by surprise removal or by a link fault. Commit 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected") adds pci_dev_is_disconnected() to devtlb_invalidation_with_pasid() so ATS invalidation is skipped only when the device is being safely removed, but it applies only when Intel IOMMU scalable mode is enabled. With scalable mode disabled or unsupported, a system hard-lock occurs when a PCIe endpoint's link drops because the Intel IOMMU waits indefinitely for an ATS invalidation that cannot complete. Call Trace: qi_submit_sync qi_flush_dev_iotlb __context_flush_dev_iotlb.part.0 domain_context_clear_one_cb pci_for_each_dma_alias device_block_translation blocking_domain_attach_dev iommu_deinit_device __iommu_group_remove_device iommu_release_device iommu_bus_notifier blocking_notifier_call_chain bus_notify device_del pci_remove_bus_device pci_stop_and_remove_bus_device pciehp_unconfigure_device pciehp_disable_slot pciehp_handle_presence_or_link_change pciehp_ist Commit 81e921fd3216 ("iommu/vt-d: Fix NULL domain on device release") adds intel_pasid_teardown_sm_context() to intel_iommu_release_device(), which calls qi_flush_dev_iotlb() and can also hard-lock the system when a PCIe endpoint's link drops. Call Trace: qi_submit_sync qi_flush_dev_iotlb __context_flush_dev_iotlb.part.0 intel_context_flush_no_pasid device_pasid_table_teardown pci_pasid_table_teardown pci_for_each_dma_alias intel_pasid_teardown_sm_context intel_iommu_release_device iommu_deinit_device __iommu_group_remove_device iommu_release_device iommu_bus_notifier blocking_notifier_call_chain bus_notify device_del pci_remove_bus_device pci_stop_and_remove_bus_device pciehp_unconfigure_device pciehp_disable_slot pciehp_handle_presence_or_link_change pciehp_ist Sometimes the endpoint loses connection without a link-down event (e.g., due to a link fault); killing the process (virsh destroy) then hard-locks the host. Call Trace: qi_submit_sync qi_flush_dev_iotlb __context_flush_dev_iotlb.part.0 domain_context_clear_one_cb pci_for_each_dma_alias device_block_translation blocking_domain_attach_dev __iommu_attach_device __iommu_device_set_domain __iommu_group_set_domain_internal iommu_detach_group vfio_iommu_type1_detach_group vfio_group_detach_container vfio_group_fops_release __fput pci_dev_is_disconnected() only covers safe-removal paths; pci_device_is_present() tests accessibility by reading vendor/device IDs and internally calls pci_dev_is_disconnected(). On a ConnectX-5 (8 GT/s, x2) this costs ~70 µs. Since __context_flush_dev_iotlb() is only called on {attach,release}_dev paths (not hot), add pci_device_is_present() there to skip inaccessible devices and avoid the hard-lock. Fixes: 37764b952e1b ("iommu/vt-d: Global devTLB flush when present context entry changed") Fixes: 81e921fd3216 ("iommu/vt-d: Fix NULL domain on device release") Cc: stable@vger.kernel.org Signed-off-by: Jinhui Guo Link: https://lore.kernel.org/r/20251211035946.2071-2-guojinhui.liam@bytedance.com Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 976c7a3750f71fee18b18ea9cb38652ea5cac437 Author: Minseong Kim Date: Wed Jan 21 10:02:02 2026 -0800 Input: synaptics_i2c - guard polling restart in resume [ Upstream commit 870c2e7cd881d7a10abb91f2b38135622d9f9f65 ] synaptics_i2c_resume() restarts delayed work unconditionally, even when the input device is not opened. Guard the polling restart by taking the input device mutex and checking input_device_enabled() before re-queuing the delayed work. Fixes: eef3e4cab72ea ("Input: add driver for Synaptics I2C touchpad") Signed-off-by: Minseong Kim Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260121063738.799967-1-ii4gsp@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 9f5158454eaeed7f3b5340f50d70004c8c5f7edb Author: Marco Crivellari Date: Thu Nov 6 15:19:54 2025 +0100 Input: synaptics_i2c - replace use of system_wq with system_dfl_wq [ Upstream commit b3ee88e27798f0e8dd3a81867804d693da74d57d ] Currently if a user enqueues a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. This patch continues the effort to refactor worqueue APIs, which has begun with the change introducing new workqueues and a new alloc_workqueue flag: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") This specific workload do not benefit from a per-cpu workqueue, so use the default unbound workqueue (system_dfl_wq) instead. Suggested-by: Tejun Heo Signed-off-by: Marco Crivellari Link: https://patch.msgid.link/20251106141955.218911-4-marco.crivellari@suse.com Signed-off-by: Dmitry Torokhov Stable-dep-of: 870c2e7cd881 ("Input: synaptics_i2c - guard polling restart in resume") Signed-off-by: Sasha Levin commit 1aa5833f29b88c16e9ad49a1782927754f3af742 Author: Dikshita Agarwal Date: Thu Dec 18 12:24:09 2025 +0530 media: iris: Add missing platform data entries for SM8750 [ Upstream commit bbef55f414100853d5bcea56a41f8b171bac8fcb ] Two platform-data fields for SM8750 were missed: - get_vpu_buffer_size = iris_vpu33_buf_size Without this, the driver fails to allocate the required internal buffers, leading to basic decode/encode failures during session bring-up. - max_core_mbps = ((7680 * 4320) / 256) * 60 Without this capability exposed, capability checks are incomplete and v4l2-compliance for encoder fails. Fixes: a5925a2ce077 ("media: iris: add VPU33 specific encoding buffer calculation") Fixes: a6882431a138 ("media: iris: Add support for ENUM_FRAMESIZES/FRAMEINTERVALS for encoder") Cc: stable@vger.kernel.org Signed-off-by: Dikshita Agarwal Reviewed-by: Vikash Garodia Reviewed-by: Konrad Dybcio Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 448a7662ae135b9881de46e4fbeaf3d31c090f57 Author: Dikshita Agarwal Date: Sun Nov 2 09:10:19 2025 +0530 media: iris: remove v4l2_m2m_ioctl_{de,en}coder_cmd API usage during STOP handling [ Upstream commit 8fc707d13df517222db12b465af4aa9df05c99e1 ] Currently v4l2_m2m_ioctl_{de,enc}coder_cmd is being invoked during STOP command handling. However, this is not required as the iris driver has its own drain and stop handling mechanism in place. Using the m2m command API in this context leads to incorrect behavior, where the LAST flag is prematurely attached to a capture buffer, when there are no buffers in m2m source queue. But, in this scenario even though the source buffers are returned to client, hardware might still need to process the pending capture buffers. Attaching LAST flag prematurely can result in the capture buffer being removed from the destination queue before the hardware has finished processing it, causing issues when the buffer is eventually returned by the hardware. To prevent this, remove the m2m API usage in stop handling. Fixes: d09100763bed ("media: iris: add support for drain sequence") Fixes: 75db90ae067d ("media: iris: Add support for drain sequence in encoder video device") Signed-off-by: Dikshita Agarwal Reviewed-by: Vikash Garodia Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 2698731d25823267c29190cb578da9296a0c0d7b Author: Zhang Yi Date: Sat Nov 29 18:32:35 2025 +0800 ext4: don't set EXT4_GET_BLOCKS_CONVERT when splitting before submitting I/O [ Upstream commit feaf2a80e78f89ee8a3464126077ba8683b62791 ] When allocating blocks during within-EOF DIO and writeback with dioread_nolock enabled, EXT4_GET_BLOCKS_PRE_IO was set to split an existing large unwritten extent. However, EXT4_GET_BLOCKS_CONVERT was set when calling ext4_split_convert_extents(), which may potentially result in stale data issues. Assume we have an unwritten extent, and then DIO writes the second half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range First, ext4_iomap_alloc() call ext4_map_blocks() with EXT4_GET_BLOCKS_PRE_IO, EXT4_GET_BLOCKS_UNWRIT_EXT and EXT4_GET_BLOCKS_CREATE flags set. ext4_map_blocks() find this extent and call ext4_split_convert_extents() with EXT4_GET_BLOCKS_CONVERT and the above flags set. Then, ext4_split_convert_extents() calls ext4_split_extent() with EXT4_EXT_MAY_ZEROOUT, EXT4_EXT_MARK_UNWRIT2 and EXT4_EXT_DATA_VALID2 flags set, and it calls ext4_split_extent_at() to split the second half with EXT4_EXT_DATA_VALID2, EXT4_EXT_MARK_UNWRIT1, EXT4_EXT_MAY_ZEROOUT and EXT4_EXT_MARK_UNWRIT2 flags set. However, ext4_split_extent_at() failed to insert extent since a temporary lack -ENOSPC. It zeroes out the first half but convert the entire on-disk extent to written since the EXT4_EXT_DATA_VALID2 flag set, but left the second half as unwritten in the extent status tree. [0000000000SSSSSS] data S: stale data, 0: zeroed [WWWWWWWWWWWWWWWW] on-disk extent W: written extent [WWWWWWWWWWUUUUUU] extent status tree Finally, if the DIO failed to write data to the disk, the stale data in the second half will be exposed once the cached extent entry is gone. Fix this issue by not passing EXT4_GET_BLOCKS_CONVERT when splitting an unwritten extent before submitting I/O, and make ext4_split_convert_extents() to zero out the entire extent range to zero for this case, and also mark the extent in the extent status tree for consistency. Fixes: b8a8684502a0 ("ext4: Introduce FALLOC_FL_ZERO_RANGE flag for fallocate") Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo Reviewed-by: Baokun Li Cc: stable@kernel.org Message-ID: <20251129103247.686136-4-yi.zhang@huaweicloud.com> Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit e56d023da3794ec804bc74d2054fe21ad55476fd Author: Yang Erkun Date: Wed Nov 12 16:45:38 2025 +0800 ext4: correct the comments place for EXT4_EXT_MAY_ZEROOUT [ Upstream commit cc742fd1d184bb2a11bacf50587d2c85290622e4 ] Move the comments just before we set EXT4_EXT_MAY_ZEROOUT in ext4_split_convert_extents. Signed-off-by: Yang Erkun Message-ID: <20251112084538.1658232-4-yangerkun@huawei.com> Signed-off-by: Theodore Ts'o Stable-dep-of: feaf2a80e78f ("ext4: don't set EXT4_GET_BLOCKS_CONVERT when splitting before submitting I/O") Signed-off-by: Sasha Levin commit 663efc5aac21f039c17383aed6861dda591ed6a0 Author: Oleg Nesterov Date: Sun Jan 11 16:00:37 2026 +0100 x86/uprobes: Fix XOL allocation failure for 32-bit tasks [ Upstream commit d55c571e4333fac71826e8db3b9753fadfbead6a ] This script #!/usr/bin/bash echo 0 > /proc/sys/kernel/randomize_va_space echo 'void main(void) {}' > TEST.c # -fcf-protection to ensure that the 1st endbr32 insn can't be emulated gcc -m32 -fcf-protection=branch TEST.c -o test bpftrace -e 'uprobe:./test:main {}' -c ./test "hangs", the probed ./test task enters an endless loop. The problem is that with randomize_va_space == 0 get_unmapped_area(TASK_SIZE - PAGE_SIZE) called by xol_add_vma() can not just return the "addr == TASK_SIZE - PAGE_SIZE" hint, this addr is used by the stack vma. arch_get_unmapped_area_topdown() doesn't take TIF_ADDR32 into account and in_32bit_syscall() is false, this leads to info.high_limit > TASK_SIZE. vm_unmapped_area() happily returns the high address > TASK_SIZE and then get_unmapped_area() returns -ENOMEM after the "if (addr > TASK_SIZE - len)" check. handle_swbp() doesn't report this failure (probably it should) and silently restarts the probed insn. Endless loop. I think that the right fix should change the x86 get_unmapped_area() paths to rely on TIF_ADDR32 rather than in_32bit_syscall(). Note also that if CONFIG_X86_X32_ABI=y, in_x32_syscall() falsely returns true in this case because ->orig_ax = -1. But we need a simple fix for -stable, so this patch just sets TS_COMPAT if the probed task is 32-bit to make in_ia32_syscall() true. Fixes: 1b028f784e8c ("x86/mm: Introduce mmap_compat_base() for 32-bit mmap()") Reported-by: Paulo Andrade Signed-off-by: Oleg Nesterov Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/all/aV5uldEvV7pb4RA8@redhat.com/ Cc: stable@vger.kernel.org Link: https://patch.msgid.link/aWO7Fdxn39piQnxu@redhat.com Signed-off-by: Sasha Levin commit f7df71d26b308a3588e240300740e11e844845cf Author: Peter Zijlstra Date: Fri Oct 24 12:31:10 2025 +0200 unwind_user/x86: Teach FP unwind about start of function [ Upstream commit ae25884ad749e7f6e0c3565513bdc8aa2554a425 ] When userspace is interrupted at the start of a function, before we get a chance to complete the frame, unwind will miss one caller. X86 has a uprobe specific fixup for this, add bits to the generic unwinder to support this. Suggested-by: Jens Remus Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20251024145156.GM4068168@noisy.programming.kicks-ass.net Stable-dep-of: d55c571e4333 ("x86/uprobes: Fix XOL allocation failure for 32-bit tasks") Signed-off-by: Sasha Levin commit b9537a51b65af020c44a33247fa81a5702b43446 Author: Josh Poimboeuf Date: Wed Aug 27 15:36:45 2025 -0400 unwind_user/x86: Enable frame pointer unwinding on x86 [ Upstream commit 49cf34c0815f93fb2ea3ab5cfbac1124bd9b45d0 ] Use ARCH_INIT_USER_FP_FRAME to describe how frame pointers are unwound on x86, and enable CONFIG_HAVE_UNWIND_USER_FP accordingly so the unwind_user interfaces can be used. Signed-off-by: Josh Poimboeuf Signed-off-by: Steven Rostedt (Google) Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20250827193828.347397433@kernel.org Stable-dep-of: d55c571e4333 ("x86/uprobes: Fix XOL allocation failure for 32-bit tasks") Signed-off-by: Sasha Levin commit 6f553dbbb25d66a81f2b23057b5e26be685e77f5 Author: Peter Zijlstra Date: Tue Sep 23 13:27:34 2025 +0200 unwind: Implement compat fp unwind [ Upstream commit c79dd946e370af3537edb854f210cba3a94b4516 ] It is important to be able to unwind compat tasks too. Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20250924080119.613695709@infradead.org Stable-dep-of: d55c571e4333 ("x86/uprobes: Fix XOL allocation failure for 32-bit tasks") Signed-off-by: Sasha Levin commit 5364f7bbd611a87cd123673e2549ab3e2e4a91ea Author: Peter Zijlstra Date: Tue Sep 23 13:04:09 2025 +0200 unwind: Simplify unwind_user_next_fp() alignment check [ Upstream commit 5578534e4b92350995a20068f2e6ea3186c62d7f ] 2^log_2(n) == n Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Steven Rostedt (Google) Link: https://patch.msgid.link/20250924080119.497867836@infradead.org Stable-dep-of: d55c571e4333 ("x86/uprobes: Fix XOL allocation failure for 32-bit tasks") Signed-off-by: Sasha Levin commit c45026c4135d4b336bd6a591b152a4c1570656be Author: Johan Hovold Date: Fri Nov 21 17:42:01 2025 +0100 drm/tegra: dsi: fix device leak on probe [ Upstream commit bfef062695570842cf96358f2f46f4c6642c6689 ] Make sure to drop the reference taken when looking up the companion (ganged) device and its driver data during probe(). Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference. Fixes: e94236cde4d5 ("drm/tegra: dsi: Add ganged mode support") Fixes: 221e3638feb8 ("drm/tegra: Fix reference leak in tegra_dsi_ganged_probe") Cc: stable@vger.kernel.org # 3.19: 221e3638feb8 Cc: Thierry Reding Signed-off-by: Johan Hovold Signed-off-by: Thierry Reding Link: https://patch.msgid.link/20251121164201.13188-1-johan@kernel.org Signed-off-by: Sasha Levin commit 1e88b5f854bdb469424132e0bb44793ad7a7c20a Author: Sean Christopherson Date: Thu Jan 8 19:06:57 2026 -0800 KVM: x86: Ignore -EBUSY when checking nested events from vcpu_block() [ Upstream commit ead63640d4e72e6f6d464f4e31f7fecb79af8869 ] Ignore -EBUSY when checking nested events after exiting a blocking state while L2 is active, as exiting to userspace will generate a spurious userspace exit, usually with KVM_EXIT_UNKNOWN, and likely lead to the VM's demise. Continuing with the wakeup isn't perfect either, as *something* has gone sideways if a vCPU is awakened in L2 with an injected event (or worse, a nested run pending), but continuing on gives the VM a decent chance of surviving without any major side effects. As explained in the Fixes commits, it _should_ be impossible for a vCPU to be put into a blocking state with an already-injected event (exception, IRQ, or NMI). Unfortunately, userspace can stuff MP_STATE and/or injected events, and thus put the vCPU into what should be an impossible state. Don't bother trying to preserve the WARN, e.g. with an anti-syzkaller Kconfig, as WARNs can (hopefully) be added in paths where _KVM_ would be violating x86 architecture, e.g. by WARNing if KVM attempts to inject an exception or interrupt while the vCPU isn't running. Cc: Alessandro Ratti Cc: stable@vger.kernel.org Fixes: 26844fee6ade ("KVM: x86: never write to memory from kvm_vcpu_check_block()") Fixes: 45405155d876 ("KVM: x86: WARN if a vCPU gets a valid wakeup that KVM can't yet inject") Link: https://syzkaller.appspot.com/text?tag=ReproC&x=10d4261a580000 Reported-by: syzbot+1522459a74d26b0ac33a@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/671bc7a7.050a0220.455e8.022a.GAE@google.com Link: https://patch.msgid.link/20260109030657.994759-1-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin commit 2dff8966a3a889dd9d248a7e15d963b4097efcc5 Author: Zilin Guan Date: Fri Nov 14 09:12:57 2025 +0000 media: tegra-video: Fix memory leak in __tegra_channel_try_format() [ Upstream commit 43e5302d22334f1183dec3e0d5d8007eefe2817c ] The state object allocated by __v4l2_subdev_state_alloc() must be freed with __v4l2_subdev_state_free() when it is no longer needed. In __tegra_channel_try_format(), two error paths return directly after v4l2_subdev_call() fails, without freeing the allocated 'sd_state' object. This violates the requirement and causes a memory leak. Fix this by introducing a cleanup label and using goto statements in the error paths to ensure that __v4l2_subdev_state_free() is always called before the function returns. Fixes: 56f64b82356b7 ("media: tegra-video: Use zero crop settings if subdev has no get_selection") Fixes: 1ebaeb09830f3 ("media: tegra-video: Add support for external sensor capture") Cc: stable@vger.kernel.org Signed-off-by: Zilin Guan Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 7fc4b49474c836cee7d9801abf05e0198fcbfa74 Author: Quentin Schulz Date: Mon Dec 15 17:36:15 2025 +0100 accel/rocket: fix unwinding in error path in rocket_probe [ Upstream commit 34f4495a7f72895776b81969639f527c99eb12b9 ] When rocket_core_init() fails (as could be the case with EPROBE_DEFER), we need to properly unwind by decrementing the counter we just incremented and if this is the first core we failed to probe, remove the rocket DRM device with rocket_device_fini() as well. This matches the logic in rocket_remove(). Failing to properly unwind results in out-of-bounds accesses. Fixes: 0810d5ad88a1 ("accel/rocket: Add job submission IOCTL") Cc: stable@vger.kernel.org Signed-off-by: Quentin Schulz Reviewed-by: Tomeu Vizoso Signed-off-by: Tomeu Vizoso Link: https://patch.msgid.link/20251215-rocket-error-path-v1-2-eec3bf29dc3b@cherry.de Signed-off-by: Sasha Levin commit 17463839162f659f06102e23bca922ba84fe7e9a Author: Quentin Schulz Date: Mon Dec 15 17:36:14 2025 +0100 accel/rocket: fix unwinding in error path in rocket_core_init [ Upstream commit f509a081f6a289f7c66856333b3becce7a33c97e ] When rocket_job_init() is called, iommu_group_get() has already been called, therefore we should call iommu_group_put() and make the iommu_group pointer NULL. This aligns with what's done in rocket_core_fini(). If pm_runtime_resume_and_get() somehow fails, not only should rocket_job_fini() be called but we should also unwind everything done before that, that is, disable PM, put the iommu_group, NULLify it and then call rocket_job_fini(). This is exactly what's done in rocket_core_fini() so let's call that function instead of duplicating the code. Fixes: 0810d5ad88a1 ("accel/rocket: Add job submission IOCTL") Cc: stable@vger.kernel.org Signed-off-by: Quentin Schulz Reviewed-by: Tomeu Vizoso Signed-off-by: Tomeu Vizoso Link: https://patch.msgid.link/20251215-rocket-error-path-v1-1-eec3bf29dc3b@cherry.de Signed-off-by: Sasha Levin commit b62076e780a2121903ecf9ffdfb89c64647cb7da Author: Kuen-Han Tsai Date: Tue Dec 30 18:13:16 2025 +0800 usb: gadget: f_ncm: align net_device lifecycle with bind/unbind [ Upstream commit 56a512a9b4107079f68701e7d55da8507eb963d9 ] Currently, the net_device is allocated in ncm_alloc_inst() and freed in ncm_free_inst(). This ties the network interface's lifetime to the configuration instance rather than the USB connection (bind/unbind). This decoupling causes issues when the USB gadget is disconnected where the underlying gadget device is removed. The net_device can outlive its parent, leading to dangling sysfs links and NULL pointer dereferences when accessing the freed gadget device. Problem 1: NULL pointer dereference on disconnect Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __pi_strlen+0x14/0x150 rtnl_fill_ifinfo+0x6b4/0x708 rtmsg_ifinfo_build_skb+0xd8/0x13c rtmsg_ifinfo+0x50/0xa0 __dev_notify_flags+0x4c/0x1f0 dev_change_flags+0x54/0x70 do_setlink+0x390/0xebc rtnl_newlink+0x7d0/0xac8 rtnetlink_rcv_msg+0x27c/0x410 netlink_rcv_skb+0x134/0x150 rtnetlink_rcv+0x18/0x28 netlink_unicast+0x254/0x3f0 netlink_sendmsg+0x2e0/0x3d4 Problem 2: Dangling sysfs symlinks console:/ # ls -l /sys/class/net/ncm0 lrwxrwxrwx ... /sys/class/net/ncm0 -> /sys/devices/platform/.../gadget.0/net/ncm0 console:/ # ls -l /sys/devices/platform/.../gadget.0/net/ncm0 ls: .../gadget.0/net/ncm0: No such file or directory Move the net_device allocation to ncm_bind() and deallocation to ncm_unbind(). This ensures the network interface exists only when the gadget function is actually bound to a configuration. To support pre-bind configuration (e.g., setting interface name or MAC address via configfs), cache user-provided options in f_ncm_opts using the gether_opts structure. Apply these cached settings to the net_device upon creation in ncm_bind(). Preserve the use-after-free fix from commit 6334b8e4553c ("usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error"). Check opts->net in ncm_set_alt() and ncm_disable() to ensure gether_disconnect() runs only if a connection was established. Fixes: 40d133d7f542 ("usb: gadget: f_ncm: convert to new function interface with backward compatibility") Cc: stable@kernel.org Signed-off-by: Kuen-Han Tsai Link: https://patch.msgid.link/20251230-ncm-refactor-v1-3-793e347bc7a7@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ca9ca411bbcf927f9dacc6476fd2d90b6c0271c2 Author: Kuen-Han Tsai Date: Tue Dec 30 18:13:15 2025 +0800 usb: gadget: u_ether: Add auto-cleanup helper for freeing net_device [ Upstream commit 0c0981126b99288ed354d3d414c8a5fd42ac9e25 ] The net_device in the u_ether framework currently requires explicit calls to unregister and free the device. Introduce gether_unregister_free_netdev() and the corresponding auto-cleanup macro. This ensures that if a net_device is registered, it is properly unregistered and the associated work queue is flushed before the memory is freed. This is a preparatory patch to simplify error handling paths in gadget drivers by removing the need for explicit goto labels for net_device cleanup. Signed-off-by: Kuen-Han Tsai Link: https://patch.msgid.link/20251230-ncm-refactor-v1-2-793e347bc7a7@google.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 56a512a9b410 ("usb: gadget: f_ncm: align net_device lifecycle with bind/unbind") Signed-off-by: Sasha Levin commit f222eb16d597eaa4dd4017760e80bed920c0f0d2 Author: Kuen-Han Tsai Date: Tue Dec 30 18:13:14 2025 +0800 usb: gadget: u_ether: add gether_opts for config caching [ Upstream commit e065c6a7e46c2ee9c677fdbf50035323d2de1215 ] Currently, the net_device is allocated when the function instance is created (e.g., in ncm_alloc_inst()). While this allows userspace to configure the device early, it decouples the net_device lifecycle from the actual USB connection state (bind/unbind). The goal is to defer net_device creation to the bind callback to properly align the lifecycle with its parent gadget device. However, deferring net_device allocation would prevent userspace from configuring parameters (like interface name or MAC address) before the net_device exists. Introduce a new structure, struct gether_opts, associated with the usb_function_instance, to cache settings independently of the net_device. These settings include the interface name pattern, MAC addresses (device and host), queue multiplier, and address assignment type. New helper functions are added: - gether_setup_opts_default(): Initializes struct gether_opts with defaults, including random MAC addresses. - gether_apply_opts(): Applies the cached options from a struct gether_opts to a valid net_device. To expose these options to userspace, new configfs macros (USB_ETHER_OPTS_ITEM and USB_ETHER_OPTS_ATTR_*) are defined in u_ether_configfs.h. These attributes are part of the function instance's configfs group. This refactoring is a preparatory step. It allows the subsequent patch to safely move the net_device allocation from the instance creation phase to the bind phase without losing the ability to pre-configure the interface via configfs. Signed-off-by: Kuen-Han Tsai Link: https://patch.msgid.link/20251230-ncm-refactor-v1-1-793e347bc7a7@google.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 56a512a9b410 ("usb: gadget: f_ncm: align net_device lifecycle with bind/unbind") Signed-off-by: Sasha Levin commit 7bdff9b9b0c65ac7105416fe3a40686832515e20 Author: Manivannan Sadhasivam Date: Thu Dec 18 22:21:44 2025 +0530 net: qrtr: Drop the MHI auto_queue feature for IPCR DL channels [ Upstream commit 51731792a25cb312ca94cdccfa139eb46de1b2ef ] MHI stack offers the 'auto_queue' feature, which allows the MHI stack to auto queue the buffers for the RX path (DL channel). Though this feature simplifies the client driver design, it introduces race between the client drivers and the MHI stack. For instance, with auto_queue, the 'dl_callback' for the DL channel may get called before the client driver is fully probed. This means, by the time the dl_callback gets called, the client driver's structures might not be initialized, leading to NULL ptr dereference. Currently, the drivers have to workaround this issue by initializing the internal structures before calling mhi_prepare_for_transfer_autoqueue(). But even so, there is a chance that the client driver's internal code path may call the MHI queue APIs before mhi_prepare_for_transfer_autoqueue() is called, leading to similar NULL ptr dereference. This issue has been reported on the Qcom X1E80100 CRD machines affecting boot. So to properly fix all these races, drop the MHI 'auto_queue' feature altogether and let the client driver (QRTR) manage the RX buffers manually. In the QRTR driver, queue the RX buffers based on the ring length during probe and recycle the buffers in 'dl_callback' once they are consumed. This also warrants removing the setting of 'auto_queue' flag from controller drivers. Currently, this 'auto_queue' feature is only enabled for IPCR DL channel. So only the QRTR client driver requires the modification. Fixes: 227fee5fc99e ("bus: mhi: core: Add an API for auto queueing buffers for DL channel") Fixes: 68a838b84eff ("net: qrtr: start MHI channel after endpoit creation") Reported-by: Johan Hovold Closes: https://lore.kernel.org/linux-arm-msm/ZyTtVdkCCES0lkl4@hovoldconsulting.com Suggested-by: Chris Lew Signed-off-by: Manivannan Sadhasivam Reviewed-by: Jeff Hugo Reviewed-by: Loic Poulain Acked-by: Jeff Johnson # drivers/net/wireless/ath/... Acked-by: Jeff Hugo Acked-by: Paolo Abeni Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251218-qrtr-fix-v2-1-c7499bfcfbe0@oss.qualcomm.com Signed-off-by: Sasha Levin commit ed9c15c7be25e35a7271ce529c65556196885efa Author: Niklas Cassel Date: Mon Dec 22 07:42:09 2025 +0100 Revert "PCI: dw-rockchip: Enumerate endpoints based on dll_link_up IRQ" [ Upstream commit 180c3cfe36786d261a55da52a161f9e279b19a6f ] This reverts commit 0e0b45ab5d770a748487ba0ae8f77d1fb0f0de3e. While this fake hotplugging was a nice idea, it has shown that this feature does not handle PCIe switches correctly: pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43 pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44 pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45 pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46 pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46 pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41]) pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46 During the initial scan, PCI core doesn't see the switch and since the Root Port is not hot plug capable, the secondary bus number gets assigned as the subordinate bus number. This means, the PCI core assumes that only one bus will appear behind the Root Port since the Root Port is not hot plug capable. This works perfectly fine for PCIe endpoints connected to the Root Port, since they don't extend the bus. However, if a PCIe switch is connected, then there is a problem when the downstream busses starts showing up and the PCI core doesn't extend the subordinate bus number and bridge resources after initial scan during boot. The long term plan is to migrate this driver to the upcoming pwrctrl APIs that are supposed to handle this problem elegantly. Suggested-by: Manivannan Sadhasivam Signed-off-by: Niklas Cassel Signed-off-by: Manivannan Sadhasivam Tested-by: Shawn Lin Acked-by: Shawn Lin Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251222064207.3246632-10-cassel@kernel.org Signed-off-by: Sasha Levin commit 15a66eb1b2c6c4fa7829e2fe70e244d675228472 Author: Shawn Lin Date: Fri Dec 12 09:33:25 2025 +0800 PCI: dw-rockchip: Change get_ltssm() to provide L1 Substates info [ Upstream commit f994bb8f1c94726e0124356ccd31c3c23a8a69f4 ] Rename rockchip_pcie_get_ltssm() to rockchip_pcie_get_ltssm_reg() and add rockchip_pcie_get_ltssm() to get_ltssm() callback in order to show the proper L1 Substates. The PCIE_CLIENT_LTSSM_STATUS[5:0] register returns the same LTSSM layout as enum dw_pcie_ltssm. So the driver just need to convey L1 PM Substates by returning the proper value defined in pcie-designware.h. cat /sys/kernel/debug/dwc_pcie_a40000000.pcie/ltssm_status L1_2 (0x142) Signed-off-by: Shawn Lin Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/1765503205-22184-2-git-send-email-shawn.lin@rock-chips.com Stable-dep-of: 180c3cfe3678 ("Revert "PCI: dw-rockchip: Enumerate endpoints based on dll_link_up IRQ"") Signed-off-by: Sasha Levin commit aad472c928c97acff0311963cd86a1443b1738fc Author: Shawn Lin Date: Fri Dec 12 09:33:24 2025 +0800 PCI: dwc: Add L1 Substates context to ltssm_status of debugfs [ Upstream commit 679ec639f29cbdaf36bd79bf3e98240fffa335ee ] DWC core couldn't distinguish LTSSM state among L1.0, L1.1 and L1.2. But the vendor glue driver may implement additional logic to convey this information. So add two pseudo definitions for vendor glue drivers to translate their internal L1 Substates for debugfs to show. Signed-off-by: Shawn Lin Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/1765503205-22184-1-git-send-email-shawn.lin@rock-chips.com Stable-dep-of: 180c3cfe3678 ("Revert "PCI: dw-rockchip: Enumerate endpoints based on dll_link_up IRQ"") Signed-off-by: Sasha Levin commit 80d3a201d7add957d0db040fa8052b0571ffe779 Author: Shawn Lin Date: Tue Nov 18 15:42:17 2025 -0600 PCI: dw-rockchip: Configure L1SS support [ Upstream commit b5e719f26107f4a7f82946dc5be92dceb9b443cb ] L1 PM Substates for RC mode require support in the dw-rockchip driver including proper handling of the CLKREQ# sideband signal. It is mostly handled by hardware, but software still needs to set the clkreq fields in the PCIE_CLIENT_POWER_CON register to match the hardware implementation. For more details, see section '18.6.6.4 L1 Substate' in the RK3568 TRM 1.1 Part 2, or section '11.6.6.4 L1 Substate' in the RK3588 TRM 1.0 Part2. [bhelgaas: set pci->l1ss_support so DWC core preserves L1SS Capability bits; drop corresponding code here, include updates from https://lore.kernel.org/r/aRRG8wv13HxOCqgA@ryzen] Signed-off-by: Shawn Lin Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/1761187883-150120-1-git-send-email-shawn.lin@rock-chips.com Link: https://patch.msgid.link/20251118214312.2598220-4-helgaas@kernel.org Stable-dep-of: 180c3cfe3678 ("Revert "PCI: dw-rockchip: Enumerate endpoints based on dll_link_up IRQ"") Signed-off-by: Sasha Levin commit b1f114b7a6fac1dd8a337eb4ecf1137c079efbb2 Author: Bjorn Helgaas Date: Tue Nov 18 15:42:15 2025 -0600 PCI: dwc: Advertise L1 PM Substates only if driver requests it [ Upstream commit a00bba406b5a682764ecb507e580ca8159196aa3 ] L1 PM Substates require the CLKREQ# signal and may also require device-specific support. If CLKREQ# is not supported or driver support is lacking, enabling L1.1 or L1.2 may cause errors when accessing devices, e.g., nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0x10 If the kernel is built with CONFIG_PCIEASPM_POWER_SUPERSAVE=y or users enable L1.x via sysfs, users may trip over these errors even if L1 Substates haven't been enabled by firmware or the driver. To prevent such errors, disable advertising the L1 PM Substates unless the driver sets "dw_pcie.l1ss_support" to indicate that it knows CLKREQ# is present and any device-specific configuration has been done. Set "dw_pcie.l1ss_support" in tegra194 (if DT includes the "supports-clkreq' property) and qcom (for cfg_2_7_0, cfg_1_9_0, cfg_1_34_0, and cfg_sc8280xp controllers) so they can continue to use L1 Substates. Based on Niklas's patch: https://patch.msgid.link/20251017163252.598812-2-cassel@kernel.org [bhelgaas: drop hiding for endpoints] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20251118214312.2598220-2-helgaas@kernel.org Stable-dep-of: 180c3cfe3678 ("Revert "PCI: dw-rockchip: Enumerate endpoints based on dll_link_up IRQ"") Signed-off-by: Sasha Levin commit 53abc9c61361379450a8ba744c3036c97d237899 Author: Siddharth Vadapalli Date: Mon Nov 17 17:02:06 2025 +0530 PCI: j721e: Add config guards for Cadence Host and Endpoint library APIs [ Upstream commit 4b361b1e92be255ff923453fe8db74086cc7cf66 ] Commit under Fixes enabled loadable module support for the driver under the assumption that it shall be the sole user of the Cadence Host and Endpoint library APIs. This assumption guarantees that we won't end up in a case where the driver is built-in and the library support is built as a loadable module. With the introduction of [1], this assumption is no longer valid. The SG2042 driver could be built as a loadable module, implying that the Cadence Host library is also selected as a loadable module. However, the pci-j721e.c driver could be built-in as indicated by CONFIG_PCI_J721E=y due to which the Cadence Endpoint library is built-in. Despite the library drivers being built as specified by their respective consumers, since the 'pci-j721e.c' driver has references to the Cadence Host library APIs as well, we run into a build error as reported at [0]. Fix this by adding config guards as a temporary workaround. The proper fix is to split the 'pci-j721e.c' driver into independent Host and Endpoint drivers as aligned at [2]. [0]: https://lore.kernel.org/r/202511111705.MZ7ls8Hm-lkp@intel.com/ [1]: commit 1c72774df028 ("PCI: sg2042: Add Sophgo SG2042 PCIe driver") [2]: https://lore.kernel.org/r/37f6f8ce-12b2-44ee-a94c-f21b29c98821@app.fastmail.com/ Fixes: a2790bf81f0f ("PCI: j721e: Add support to build as a loadable module") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202511111705.MZ7ls8Hm-lkp@intel.com/ Suggested-by: Arnd Bergmann Signed-off-by: Siddharth Vadapalli Signed-off-by: Manivannan Sadhasivam Reviewed-by: Arnd Bergmann Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251117113246.1460644-1-s-vadapalli@ti.com Signed-off-by: Sasha Levin commit ee7f2ce97b08254df11a3bccae3cfbc7087ce7f0 Author: Anand Moon Date: Tue Oct 28 21:12:23 2025 +0530 PCI: j721e: Use devm_clk_get_optional_enabled() to get and enable the clock [ Upstream commit 6fad11c61d0dbf87601ab9e2e37cba7a9a427f7b ] Use devm_clk_get_optional_enabled() helper instead of calling devm_clk_get_optional() and then clk_prepare_enable(). Assign the result of devm_clk_get_optional_enabled() directly to pcie->refclk to avoid using a local 'clk' variable. Signed-off-by: Anand Moon Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Siddharth Vadapalli Link: https://patch.msgid.link/20251028154229.6774-2-linux.amoon@gmail.com Stable-dep-of: 4b361b1e92be ("PCI: j721e: Add config guards for Cadence Host and Endpoint library APIs") Signed-off-by: Sasha Levin commit f69535b77fa0518ad39870c00dd2995439ed5c34 Author: Johan Hovold Date: Fri Nov 21 17:46:23 2025 +0100 memory: mtk-smi: fix device leak on larb probe [ Upstream commit 9dae65913b32d05dbc8ff4b8a6bf04a0e49a8eb6 ] Make sure to drop the reference taken when looking up the SMI device during larb probe on late probe failure (e.g. probe deferral) and on driver unbind. Fixes: cc8bbe1a8312 ("memory: mediatek: Add SMI driver") Fixes: 038ae37c510f ("memory: mtk-smi: add missing put_device() call in mtk_smi_device_link_common") Cc: stable@vger.kernel.org # 4.6: 038ae37c510f Cc: stable@vger.kernel.org # 4.6 Cc: Yong Wu Cc: Miaoqian Lin Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20251121164624.13685-3-johan@kernel.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit b44d090d6ca159d94b59ad4cc44ffdaca094df82 Author: Johan Hovold Date: Fri Nov 21 17:46:22 2025 +0100 memory: mtk-smi: fix device leaks on common probe [ Upstream commit 6cfa038bddd710f544076ea2ef7792fc82fbedd6 ] Make sure to drop the reference taken when looking up the SMI device during common probe on late probe failure (e.g. probe deferral) and on driver unbind. Fixes: 47404757702e ("memory: mtk-smi: Add device link for smi-sub-common") Fixes: 038ae37c510f ("memory: mtk-smi: add missing put_device() call in mtk_smi_device_link_common") Cc: stable@vger.kernel.org # 5.16: 038ae37c510f Cc: stable@vger.kernel.org # 5.16 Cc: Yong Wu Cc: Miaoqian Lin Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20251121164624.13685-2-johan@kernel.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit a67540127042c736faf614497a7480f197638464 Author: Yazen Ghannam Date: Tue Nov 11 14:53:57 2025 +0000 x86/acpi/boot: Correct acpi_is_processor_usable() check again [ Upstream commit adbf61cc47cb72b102682e690ad323e1eda652c2 ] ACPI v6.3 defined a new "Online Capable" MADT LAPIC flag. This bit is used in conjunction with the "Enabled" MADT LAPIC flag to determine if a CPU can be enabled/hotplugged by the OS after boot. Before the new bit was defined, the "Enabled" bit was explicitly described like this (ACPI v6.0 wording provided): "If zero, this processor is unusable, and the operating system support will not attempt to use it" This means that CPU hotplug (based on MADT) is not possible. Many BIOS implementations follow this guidance. They may include LAPIC entries in MADT for unavailable CPUs, but since these entries are marked with "Enabled=0" it is expected that the OS will completely ignore these entries. However, QEMU will do the same (include entries with "Enabled=0") for the purpose of allowing CPU hotplug within the guest. Comment from QEMU function pc_madt_cpu_entry(): /* ACPI spec says that LAPIC entry for non present * CPU may be omitted from MADT or it must be marked * as disabled. However omitting non present CPU from * MADT breaks hotplug on linux. So possible CPUs * should be put in MADT but kept disabled. */ Recent Linux topology changes broke the QEMU use case. A following fix for the QEMU use case broke bare metal topology enumeration. Rework the Linux MADT LAPIC flags check to allow the QEMU use case only for guests and to maintain the ACPI spec behavior for bare metal. Remove an unnecessary check added to fix a bare metal case introduced by the QEMU "fix". [ bp: Change logic as Michal suggested. ] [ mingo: Removed misapplied -stable tag. ] Fixes: fed8d8773b8e ("x86/acpi/boot: Correct acpi_is_processor_usable() check") Fixes: f0551af02130 ("x86/topology: Ignore non-present APIC IDs in a present package") Closes: https://lore.kernel.org/r/20251024204658.3da9bf3f.michal.pecio@gmail.com Reported-by: Michal Pecio Signed-off-by: Yazen Ghannam Signed-off-by: Borislav Petkov (AMD) Signed-off-by: Ingo Molnar Tested-by: Michal Pecio Tested-by: Ricardo Neri Link: https://lore.kernel.org/20251111145357.4031846-1-yazen.ghannam@amd.com Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 1b99c0e5b6bd802984c76bfdb12617f922f66b23 Author: Paul Chaignon Date: Fri Feb 27 22:35:02 2026 +0100 bpf: Improve bounds when tnum has a single possible value [ Upstream commit efc11a667878a1d655ff034a93a539debbfedb12 ] We're hitting an invariant violation in Cilium that sometimes leads to BPF programs being rejected and Cilium failing to start [1]. The following extract from verifier logs shows what's happening: from 201 to 236: R1=0 R6=ctx() R7=1 R9=scalar(smin=umin=smin32=umin32=3584,smax=umax=smax32=umax32=3840,var_off=(0xe00; 0x100)) R10=fp0 236: R1=0 R6=ctx() R7=1 R9=scalar(smin=umin=smin32=umin32=3584,smax=umax=smax32=umax32=3840,var_off=(0xe00; 0x100)) R10=fp0 ; if (magic == MARK_MAGIC_HOST || magic == MARK_MAGIC_OVERLAY || magic == MARK_MAGIC_ENCRYPT) @ bpf_host.c:1337 236: (16) if w9 == 0xe00 goto pc+45 ; R9=scalar(smin=umin=smin32=umin32=3585,smax=umax=smax32=umax32=3840,var_off=(0xe00; 0x100)) 237: (16) if w9 == 0xf00 goto pc+1 verifier bug: REG INVARIANTS VIOLATION (false_reg1): range bounds violation u64=[0xe01, 0xe00] s64=[0xe01, 0xe00] u32=[0xe01, 0xe00] s32=[0xe01, 0xe00] var_off=(0xe00, 0x0) We reach instruction 236 with two possible values for R9, 0xe00 and 0xf00. This is perfectly reflected in the tnum, but of course the ranges are less accurate and cover [0xe00; 0xf00]. Taking the fallthrough path at instruction 236 allows the verifier to reduce the range to [0xe01; 0xf00]. The tnum is however not updated. With these ranges, at instruction 237, the verifier is not able to deduce that R9 is always equal to 0xf00. Hence the fallthrough pass is explored first, the verifier refines the bounds using the assumption that R9 != 0xf00, and ends up with an invariant violation. This pattern of impossible branch + bounds refinement is common to all invariant violations seen so far. The long-term solution is likely to rely on the refinement + invariant violation check to detect dead branches, as started by Eduard. To fix the current issue, we need something with less refactoring that we can backport. This patch uses the tnum_step helper introduced in the previous patch to detect the above situation. In particular, three cases are now detected in the bounds refinement: 1. The u64 range and the tnum only overlap in umin. u64: ---[xxxxxx]----- tnum: --xx----------x- 2. The u64 range and the tnum only overlap in the maximum value represented by the tnum, called tmax. u64: ---[xxxxxx]----- tnum: xx-----x-------- 3. The u64 range and the tnum only overlap in between umin (excluded) and umax. u64: ---[xxxxxx]----- tnum: xx----x-------x- To detect these three cases, we call tnum_step(tnum, umin), which returns the smallest member of the tnum greater than umin, called tnum_next here. We're in case (1) if umin is part of the tnum and tnum_next is greater than umax. We're in case (2) if umin is not part of the tnum and tnum_next is equal to tmax. Finally, we're in case (3) if umin is not part of the tnum, tnum_next is inferior or equal to umax, and calling tnum_step a second time gives us a value past umax. This change implements these three cases. With it, the above bytecode looks as follows: 0: (85) call bpf_get_prandom_u32#7 ; R0=scalar() 1: (47) r0 |= 3584 ; R0=scalar(smin=0x8000000000000e00,umin=umin32=3584,smin32=0x80000e00,var_off=(0xe00; 0xfffffffffffff1ff)) 2: (57) r0 &= 3840 ; R0=scalar(smin=umin=smin32=umin32=3584,smax=umax=smax32=umax32=3840,var_off=(0xe00; 0x100)) 3: (15) if r0 == 0xe00 goto pc+2 ; R0=3840 4: (15) if r0 == 0xf00 goto pc+1 4: R0=3840 6: (95) exit In addition to the new selftests, this change was also verified with Agni [3]. For the record, the raw SMT is available at [4]. The property it verifies is that: If a concrete value x is contained in all input abstract values, after __update_reg_bounds, it will continue to be contained in all output abstract values. Link: https://github.com/cilium/cilium/issues/44216 [1] Link: https://pchaigno.github.io/test-verifier-complexity.html [2] Link: https://github.com/bpfverif/agni [3] Link: https://pastebin.com/raw/naCfaqNx [4] Fixes: 0df1a55afa83 ("bpf: Warn on internal verifier errors") Acked-by: Eduard Zingerman Tested-by: Marco Schirrmeister Co-developed-by: Harishankar Vishwanathan Signed-off-by: Harishankar Vishwanathan Signed-off-by: Paul Chaignon Link: https://lore.kernel.org/r/ef254c4f68be19bd393d450188946821c588565d.1772225741.git.paul.chaignon@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 50a4fab0887ea5beebaf743cd847cb0ba330084f Author: Harishankar Vishwanathan Date: Fri Feb 27 22:32:21 2026 +0100 bpf: Introduce tnum_step to step through tnum's members [ Upstream commit 76e954155b45294c502e3d3a9e15757c858ca55e ] This commit introduces tnum_step(), a function that, when given t, and a number z returns the smallest member of t larger than z. The number z must be greater or equal to the smallest member of t and less than the largest member of t. The first step is to compute j, a number that keeps all of t's known bits, and matches all unknown bits to z's bits. Since j is a member of the t, it is already a candidate for result. However, we want our result to be (minimally) greater than z. There are only two possible cases: (1) Case j <= z. In this case, we want to increase the value of j and make it > z. (2) Case j > z. In this case, we want to decrease the value of j while keeping it > z. (Case 1) j <= z t = xx11x0x0 z = 10111101 (189) j = 10111000 (184) ^ k (Case 1.1) Let's first consider the case where j < z. We will address j == z later. Since z > j, there had to be a bit position that was 1 in z and a 0 in j, beyond which all positions of higher significance are equal in j and z. Further, this position could not have been unknown in a, because the unknown positions of a match z. This position had to be a 1 in z and known 0 in t. Let k be position of the most significant 1-to-0 flip. In our example, k = 3 (starting the count at 1 at the least significant bit). Setting (to 1) the unknown bits of t in positions of significance smaller than k will not produce a result > z. Hence, we must set/unset the unknown bits at positions of significance higher than k. Specifically, we look for the next larger combination of 1s and 0s to place in those positions, relative to the combination that exists in z. We can achieve this by concatenating bits at unknown positions of t into an integer, adding 1, and writing the bits of that result back into the corresponding bit positions previously extracted from z. >From our example, considering only positions of significance greater than k: t = xx..x z = 10..1 + 1 ----- 11..0 This is the exact combination 1s and 0s we need at the unknown bits of t in positions of significance greater than k. Further, our result must only increase the value minimally above z. Hence, unknown bits in positions of significance smaller than k should remain 0. We finally have, result = 11110000 (240) (Case 1.2) Now consider the case when j = z, for example t = 1x1x0xxx z = 10110100 (180) j = 10110100 (180) Matching the unknown bits of the t to the bits of z yielded exactly z. To produce a number greater than z, we must set/unset the unknown bits in t, and *all* the unknown bits of t candidates for being set/unset. We can do this similar to Case 1.1, by adding 1 to the bits extracted from the masked bit positions of z. Essentially, this case is equivalent to Case 1.1, with k = 0. t = 1x1x0xxx z = .0.1.100 + 1 --------- .0.1.101 This is the exact combination of bits needed in the unknown positions of t. After recalling the known positions of t, we get result = 10110101 (181) (Case 2) j > z t = x00010x1 z = 10000010 (130) j = 10001011 (139) ^ k Since j > z, there had to be a bit position which was 0 in z, and a 1 in j, beyond which all positions of higher significance are equal in j and z. This position had to be a 0 in z and known 1 in t. Let k be the position of the most significant 0-to-1 flip. In our example, k = 4. Because of the 0-to-1 flip at position k, a member of t can become greater than z if the bits in positions greater than k are themselves >= to z. To make that member *minimally* greater than z, the bits in positions greater than k must be exactly = z. Hence, we simply match all of t's unknown bits in positions more significant than k to z's bits. In positions less significant than k, we set all t's unknown bits to 0 to retain minimality. In our example, in positions of greater significance than k (=4), t=x000. These positions are matched with z (1000) to produce 1000. In positions of lower significance than k, t=10x1. All unknown bits are set to 0 to produce 1001. The final result is: result = 10001001 (137) This concludes the computation for a result > z that is a member of t. The procedure for tnum_step() in this commit implements the idea described above. As a proof of correctness, we verified the algorithm against a logical specification of tnum_step. The specification asserts the following about the inputs t, z and output res that: 1. res is a member of t, and 2. res is strictly greater than z, and 3. there does not exist another value res2 such that 3a. res2 is also a member of t, and 3b. res2 is greater than z 3c. res2 is smaller than res We checked the implementation against this logical specification using an SMT solver. The verification formula in SMTLIB format is available at [1]. The verification returned an "unsat": indicating that no input assignment exists for which the implementation and the specification produce different outputs. In addition, we also automatically generated the logical encoding of the C implementation using Agni [2] and verified it against the same specification. This verification also returned an "unsat", confirming that the implementation is equivalent to the specification. The formula for this check is also available at [3]. Link: https://pastebin.com/raw/2eRWbiit [1] Link: https://github.com/bpfverif/agni [2] Link: https://pastebin.com/raw/EztVbBJ2 [3] Co-developed-by: Srinivas Narayana Signed-off-by: Srinivas Narayana Co-developed-by: Santosh Nagarakatte Signed-off-by: Santosh Nagarakatte Signed-off-by: Harishankar Vishwanathan Link: https://lore.kernel.org/r/93fdf71910411c0f19e282ba6d03b4c65f9c5d73.1772225741.git.paul.chaignon@gmail.com Signed-off-by: Alexei Starovoitov Stable-dep-of: efc11a667878 ("bpf: Improve bounds when tnum has a single possible value") Signed-off-by: Sasha Levin commit 4c03342e5ac532fb34d13a7b51dd7261dfc48963 Author: Tianci Cao Date: Wed Feb 4 19:15:02 2026 +0800 bpf: Add bitwise tracking for BPF_END [ Upstream commit 9d21199842247ab05c675fb9b6c6ca393a5c0024 ] This patch implements bitwise tracking (tnum analysis) for BPF_END (byte swap) operation. Currently, the BPF verifier does not track value for BPF_END operation, treating the result as completely unknown. This limits the verifier's ability to prove safety of programs that perform endianness conversions, which are common in networking code. For example, the following code pattern for port number validation: int test(struct pt_regs *ctx) { __u64 x = bpf_get_prandom_u32(); x &= 0x3f00; // Range: [0, 0x3f00], var_off: (0x0; 0x3f00) x = bswap16(x); // Should swap to range [0, 0x3f], var_off: (0x0; 0x3f) if (x > 0x3f) goto trap; return 0; trap: return *(u64 *)NULL; // Should be unreachable } Currently generates verifier output: 1: (54) w0 &= 16128 ; R0=scalar(smin=smin32=0,smax=umax=smax32=umax32=16128,var_off=(0x0; 0x3f00)) 2: (d7) r0 = bswap16 r0 ; R0=scalar() 3: (25) if r0 > 0x3f goto pc+2 ; R0=scalar(smin=smin32=0,smax=umax=smax32=umax32=63,var_off=(0x0; 0x3f)) Without this patch, even though the verifier knows `x` has certain bits set, after bswap16, it loses all tracking information and treats port as having a completely unknown value [0, 65535]. According to the BPF instruction set[1], there are 3 kinds of BPF_END: 1. `bswap(16|32|64)`: opcode=0xd7 (BPF_END | BPF_ALU64 | BPF_TO_LE) - do unconditional swap 2. `le(16|32|64)`: opcode=0xd4 (BPF_END | BPF_ALU | BPF_TO_LE) - on big-endian: do swap - on little-endian: truncation (16/32-bit) or no-op (64-bit) 3. `be(16|32|64)`: opcode=0xdc (BPF_END | BPF_ALU | BPF_TO_BE) - on little-endian: do swap - on big-endian: truncation (16/32-bit) or no-op (64-bit) Since BPF_END operations are inherently bit-wise permutations, tnum (bitwise tracking) offers the most efficient and precise mechanism for value analysis. By implementing `tnum_bswap16`, `tnum_bswap32`, and `tnum_bswap64`, we can derive exact `var_off` values concisely, directly reflecting the bit-level changes. Here is the overview of changes: 1. In `tnum_bswap(16|32|64)` (kernel/bpf/tnum.c): Call `swab(16|32|64)` function on the value and mask of `var_off`, and do truncation for 16/32-bit cases. 2. In `adjust_scalar_min_max_vals` (kernel/bpf/verifier.c): Call helper function `scalar_byte_swap`. - Only do byte swap when * alu64 (unconditional swap) OR * switching between big-endian and little-endian machines. - If need do byte swap: * Firstly call `tnum_bswap(16|32|64)` to update `var_off`. * Then reset the bound since byte swap scrambles the range. - For 16/32-bit cases, truncate dst register to match the swapped size. This enables better verification of networking code that frequently uses byte swaps for protocol processing, reducing false positive rejections. [1] https://www.kernel.org/doc/Documentation/bpf/standardization/instruction-set.rst Co-developed-by: Shenghao Yuan Signed-off-by: Shenghao Yuan Co-developed-by: Yazhou Tang Signed-off-by: Yazhou Tang Signed-off-by: Tianci Cao Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260204111503.77871-2-ziye@zju.edu.cn Signed-off-by: Alexei Starovoitov Stable-dep-of: efc11a667878 ("bpf: Improve bounds when tnum has a single possible value") Signed-off-by: Sasha Levin commit 6c10b019785dc282c5f45d21e4a3f468b8fd6476 Author: Jiayuan Chen Date: Wed Feb 25 20:14:56 2026 +0800 bpf: Fix race in devmap on PREEMPT_RT [ Upstream commit 1872e75375c40add4a35990de3be77b5741c252c ] On PREEMPT_RT kernels, the per-CPU xdp_dev_bulk_queue (bq) can be accessed concurrently by multiple preemptible tasks on the same CPU. The original code assumes bq_enqueue() and __dev_flush() run atomically with respect to each other on the same CPU, relying on local_bh_disable() to prevent preemption. However, on PREEMPT_RT, local_bh_disable() only calls migrate_disable() (when PREEMPT_RT_NEEDS_BH_LOCK is not set) and does not disable preemption, which allows CFS scheduling to preempt a task during bq_xmit_all(), enabling another task on the same CPU to enter bq_enqueue() and operate on the same per-CPU bq concurrently. This leads to several races: 1. Double-free / use-after-free on bq->q[]: bq_xmit_all() snapshots cnt = bq->count, then iterates bq->q[0..cnt-1] to transmit frames. If preempted after the snapshot, a second task can call bq_enqueue() -> bq_xmit_all() on the same bq, transmitting (and freeing) the same frames. When the first task resumes, it operates on stale pointers in bq->q[], causing use-after-free. 2. bq->count and bq->q[] corruption: concurrent bq_enqueue() modifying bq->count and bq->q[] while bq_xmit_all() is reading them. 3. dev_rx/xdp_prog teardown race: __dev_flush() clears bq->dev_rx and bq->xdp_prog after bq_xmit_all(). If preempted between bq_xmit_all() return and bq->dev_rx = NULL, a preempting bq_enqueue() sees dev_rx still set (non-NULL), skips adding bq to the flush_list, and enqueues a frame. When __dev_flush() resumes, it clears dev_rx and removes bq from the flush_list, orphaning the newly enqueued frame. 4. __list_del_clearprev() on flush_node: similar to the cpumap race, both tasks can call __list_del_clearprev() on the same flush_node, the second dereferences the prev pointer already set to NULL. The race between task A (__dev_flush -> bq_xmit_all) and task B (bq_enqueue -> bq_xmit_all) on the same CPU: Task A (xdp_do_flush) Task B (ndo_xdp_xmit redirect) ---------------------- -------------------------------- __dev_flush(flush_list) bq_xmit_all(bq) cnt = bq->count /* e.g. 16 */ /* start iterating bq->q[] */ <-- CFS preempts Task A --> bq_enqueue(dev, xdpf) bq->count == DEV_MAP_BULK_SIZE bq_xmit_all(bq, 0) cnt = bq->count /* same 16! */ ndo_xdp_xmit(bq->q[]) /* frames freed by driver */ bq->count = 0 <-- Task A resumes --> ndo_xdp_xmit(bq->q[]) /* use-after-free: frames already freed! */ Fix this by adding a local_lock_t to xdp_dev_bulk_queue and acquiring it in bq_enqueue() and __dev_flush(). These paths already run under local_bh_disable(), so use local_lock_nested_bh() which on non-RT is a pure annotation with no overhead, and on PREEMPT_RT provides a per-CPU sleeping lock that serializes access to the bq. Fixes: 3253cb49cbad ("softirq: Allow to drop the softirq-BKL lock on PREEMPT_RT") Reported-by: Sebastian Andrzej Siewior Reviewed-by: Sebastian Andrzej Siewior Signed-off-by: Jiayuan Chen Signed-off-by: Jiayuan Chen Link: https://lore.kernel.org/r/20260225121459.183121-3-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 7466ae2aeed483de80c5d8dea0913cf74038b652 Author: Jiayuan Chen Date: Wed Feb 25 20:14:55 2026 +0800 bpf: Fix race in cpumap on PREEMPT_RT [ Upstream commit 869c63d5975d55e97f6b168e885452b3da20ea47 ] On PREEMPT_RT kernels, the per-CPU xdp_bulk_queue (bq) can be accessed concurrently by multiple preemptible tasks on the same CPU. The original code assumes bq_enqueue() and __cpu_map_flush() run atomically with respect to each other on the same CPU, relying on local_bh_disable() to prevent preemption. However, on PREEMPT_RT, local_bh_disable() only calls migrate_disable() (when PREEMPT_RT_NEEDS_BH_LOCK is not set) and does not disable preemption, which allows CFS scheduling to preempt a task during bq_flush_to_queue(), enabling another task on the same CPU to enter bq_enqueue() and operate on the same per-CPU bq concurrently. This leads to several races: 1. Double __list_del_clearprev(): after bq->count is reset in bq_flush_to_queue(), a preempting task can call bq_enqueue() -> bq_flush_to_queue() on the same bq when bq->count reaches CPU_MAP_BULK_SIZE. Both tasks then call __list_del_clearprev() on the same bq->flush_node, the second call dereferences the prev pointer that was already set to NULL by the first. 2. bq->count and bq->q[] races: concurrent bq_enqueue() can corrupt the packet queue while bq_flush_to_queue() is processing it. The race between task A (__cpu_map_flush -> bq_flush_to_queue) and task B (bq_enqueue -> bq_flush_to_queue) on the same CPU: Task A (xdp_do_flush) Task B (cpu_map_enqueue) ---------------------- ------------------------ bq_flush_to_queue(bq) spin_lock(&q->producer_lock) /* flush bq->q[] to ptr_ring */ bq->count = 0 spin_unlock(&q->producer_lock) bq_enqueue(rcpu, xdpf) <-- CFS preempts Task A --> bq->q[bq->count++] = xdpf /* ... more enqueues until full ... */ bq_flush_to_queue(bq) spin_lock(&q->producer_lock) /* flush to ptr_ring */ spin_unlock(&q->producer_lock) __list_del_clearprev(flush_node) /* sets flush_node.prev = NULL */ <-- Task A resumes --> __list_del_clearprev(flush_node) flush_node.prev->next = ... /* prev is NULL -> kernel oops */ Fix this by adding a local_lock_t to xdp_bulk_queue and acquiring it in bq_enqueue() and __cpu_map_flush(). These paths already run under local_bh_disable(), so use local_lock_nested_bh() which on non-RT is a pure annotation with no overhead, and on PREEMPT_RT provides a per-CPU sleeping lock that serializes access to the bq. To reproduce, insert an mdelay(100) between bq->count = 0 and __list_del_clearprev() in bq_flush_to_queue(), then run reproducer provided by syzkaller. Fixes: 3253cb49cbad ("softirq: Allow to drop the softirq-BKL lock on PREEMPT_RT") Reported-by: syzbot+2b3391f44313b3983e91@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/69369331.a70a0220.38f243.009d.GAE@google.com/T/ Reviewed-by: Sebastian Andrzej Siewior Signed-off-by: Jiayuan Chen Signed-off-by: Jiayuan Chen Link: https://lore.kernel.org/r/20260225121459.183121-2-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit ecb4e02614b96fd3ad1b1c0538230d92d70f11b1 Author: Bjorn Helgaas Date: Fri Feb 27 06:10:08 2026 -0600 PCI: Correct PCI_CAP_EXP_ENDPOINT_SIZEOF_V2 value [ Upstream commit 39195990e4c093c9eecf88f29811c6de29265214 ] fb82437fdd8c ("PCI: Change capability register offsets to hex") incorrectly converted the PCI_CAP_EXP_ENDPOINT_SIZEOF_V2 value from decimal 52 to hex 0x32: -#define PCI_CAP_EXP_ENDPOINT_SIZEOF_V2 52 /* v2 endpoints with link end here */ +#define PCI_CAP_EXP_ENDPOINT_SIZEOF_V2 0x32 /* end of v2 EPs w/ link */ This broke PCI capabilities in a VMM because subsequent ones weren't DWORD-aligned. Change PCI_CAP_EXP_ENDPOINT_SIZEOF_V2 to the correct value of 0x34. fb82437fdd8c was from Baruch Siach , but this was not Baruch's fault; it's a mistake I made when applying the patch. Fixes: fb82437fdd8c ("PCI: Change capability register offsets to hex") Reported-by: David Woodhouse Closes: https://lore.kernel.org/all/3ae392a0158e9d9ab09a1d42150429dd8ca42791.camel@infradead.org Signed-off-by: Bjorn Helgaas Reviewed-by: Krzysztof Wilczyński Signed-off-by: Sasha Levin commit 878fddc519f75f430daeac956ca51cb511bf04ca Author: Alain Volmat Date: Tue Feb 24 16:09:22 2026 +0100 spi: stm32: fix missing pointer assignment in case of dma chaining [ Upstream commit e96493229a6399e902062213c6381162464cdd50 ] Commit c4f2c05ab029 ("spi: stm32: fix pointer-to-pointer variables usage") introduced a regression since dma descriptors generated as part of the stm32_spi_prepare_rx_dma_mdma_chaining function are not well propagated to the caller function, leading to mdma-dma chaining being no more functional. Fixes: c4f2c05ab029 ("spi: stm32: fix pointer-to-pointer variables usage") Signed-off-by: Alain Volmat Acked-by: Antonio Quartulli Link: https://patch.msgid.link/20260224-spi-stm32-chaining-fix-v1-1-5da7a4851b66@foss.st.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 130c436e71499252439f635e9278e372c2b03bac Author: David Carlier Date: Thu Feb 26 12:45:17 2026 +0000 sched_ext: Fix SCX_EFLAG_INITIALIZED being a no-op flag [ Upstream commit 749989b2d90ddc7dd253ad3b11a77cf882721acf ] SCX_EFLAG_INITIALIZED is the sole member of enum scx_exit_flags with no explicit value, so the compiler assigns it 0. This makes the bitwise OR in scx_ops_init() a no-op: sch->exit_info->flags |= SCX_EFLAG_INITIALIZED; /* |= 0 */ As a result, BPF schedulers cannot distinguish whether ops.init() completed successfully by inspecting exit_info->flags. Assign the value 1LLU << 0 so the flag is actually set. Fixes: f3aec2adce8d ("sched_ext: Add SCX_EFLAG_INITIALIZED to indicate successful ops.init()") Signed-off-by: David Carlier Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 4778033781b5ba96cb37985fb039df47814a95ef Author: T.J. Mercier Date: Tue Feb 24 16:33:48 2026 -0800 selftests/bpf: Fix OOB read in dmabuf_collector [ Upstream commit 6881af27f9ea0f5ca8f606f573ef5cc25ca31fe4 ] Dmabuf name allocations can be less than DMA_BUF_NAME_LEN characters, but bpf_probe_read_kernel always tries to read exactly that many bytes. If a name is less than DMA_BUF_NAME_LEN characters, bpf_probe_read_kernel will read past the end. bpf_probe_read_kernel_str stops at the first NUL terminator so use it instead, like iter_dmabuf_for_each already does. Fixes: ae5d2c59ecd7 ("selftests/bpf: Add test for dmabuf_iter") Reported-by: Jerome Lee Signed-off-by: T.J. Mercier Link: https://lore.kernel.org/r/20260225003349.113746-1-tjmercier@google.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 75d474702b2ba8b6bcb26eb3004dbc5e95ffd5d2 Author: Kohei Enju Date: Wed Feb 25 05:34:44 2026 +0000 bpf: Fix stack-out-of-bounds write in devmap [ Upstream commit b7bf516c3ecd9a2aae2dc2635178ab87b734fef1 ] get_upper_ifindexes() iterates over all upper devices and writes their indices into an array without checking bounds. Also the callers assume that the max number of upper devices is MAX_NEST_DEV and allocate excluded_devices[1+MAX_NEST_DEV] on the stack, but that assumption is not correct and the number of upper devices could be larger than MAX_NEST_DEV (e.g., many macvlans), causing a stack-out-of-bounds write. Add a max parameter to get_upper_ifindexes() to avoid the issue. When there are too many upper devices, return -EOVERFLOW and abort the redirect. To reproduce, create more than MAX_NEST_DEV(8) macvlans on a device with an XDP program attached using BPF_F_BROADCAST | BPF_F_EXCLUDE_INGRESS. Then send a packet to the device to trigger the XDP redirect path. Reported-by: syzbot+10cc7f13760b31bd2e61@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/698c4ce3.050a0220.340abe.000b.GAE@google.com/T/ Fixes: aeea1b86f936 ("bpf, devmap: Exclude XDP broadcast to master device") Reviewed-by: Toke Høiland-Jørgensen Signed-off-by: Kohei Enju Link: https://lore.kernel.org/r/20260225053506.4738-1-kohei@enjuk.jp Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 519b1ad91de5bf7a496f2b858e9212db6328e1de Author: Fuad Tabba Date: Thu Feb 26 07:55:25 2026 +0000 bpf, arm64: Force 8-byte alignment for JIT buffer to prevent atomic tearing [ Upstream commit ef06fd16d48704eac868441d98d4ef083d8f3d07 ] struct bpf_plt contains a u64 target field. Currently, the BPF JIT allocator requests an alignment of 4 bytes (sizeof(u32)) for the JIT buffer. Because the base address of the JIT buffer can be 4-byte aligned (e.g., ending in 0x4 or 0xc), the relative padding logic in build_plt() fails to ensure that target lands on an 8-byte boundary. This leads to two issues: 1. UBSAN reports misaligned-access warnings when dereferencing the structure. 2. More critically, target is updated concurrently via WRITE_ONCE() in bpf_arch_text_poke() while the JIT'd code executes ldr. On arm64, 64-bit loads/stores are only guaranteed to be single-copy atomic if they are 64-bit aligned. A misaligned target risks a torn read, causing the JIT to jump to a corrupted address. Fix this by increasing the allocation alignment requirement to 8 bytes (sizeof(u64)) in bpf_jit_binary_pack_alloc(). This anchors the base of the JIT buffer to an 8-byte boundary, allowing the relative padding math in build_plt() to correctly align the target field. Fixes: b2ad54e1533e ("bpf, arm64: Implement bpf_arch_text_poke() for arm64") Signed-off-by: Fuad Tabba Acked-by: Will Deacon Link: https://lore.kernel.org/r/20260226075525.233321-1-tabba@google.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 11d1d38087e72b42d6a723b418b89474f93b58ed Author: Takashi Iwai Date: Thu Feb 26 16:47:52 2026 +0100 ASoC: SDCA: Fix comments for sdca_irq_request() [ Upstream commit 71c1978ab6d2c6d48c31311855f1a85377c152ae ] The kernel-doc comments for sdca_irq_request() contained some typos that lead to build warnings with W=1. Let's correct them. Fixes: b126394d9ec6 ("ASoC: SDCA: Generic interrupt support") Acked-by: Mark Brown Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260226154753.1083320-1-tiwai@suse.de Signed-off-by: Sasha Levin commit 5413b1c94cfe5a394bda14145811590f54cf1e68 Author: Takashi Iwai Date: Thu Feb 26 16:43:49 2026 +0100 ALSA: usb: qcom: Correct parameter comment for uaudio_transfer_buffer_setup() [ Upstream commit 1d6452a0ce78cd3f4e48943b5ba21d273a658298 ] At fixing the memory leak of xfer buffer, we forgot to update the corresponding comment, too. This resulted in a kernel-doc warning with W=1. Let's correct it. Fixes: 5c7ef5001292 ("ALSA: qc_audio_offload: avoid leaking xfer_buf allocation") Link: https://patch.msgid.link/20260226154414.1081568-4-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 51c8bedb2d089c6920a5b7dd5a0f54ff95e73df6 Author: Mark Harmstone Date: Tue Feb 17 17:46:41 2026 +0000 btrfs: fix compat mask in error messages in btrfs_check_features() [ Upstream commit 587bb33b10bda645a1028c1737ad3992b3d7cf61 ] Commit d7f67ac9a928 ("btrfs: relax block-group-tree feature dependency checks") introduced a regression when it comes to handling unsupported incompat or compat_ro flags. Beforehand we only printed the flags that we didn't recognize, afterwards we printed them all, which is less useful. Fix the error handling so it behaves like it used to. Fixes: d7f67ac9a928 ("btrfs: relax block-group-tree feature dependency checks") Reviewed-by: Qu Wenruo Signed-off-by: Mark Harmstone Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 771c1e38385b00a2d0f8b0a80899f562097e24fb Author: Mark Harmstone Date: Tue Feb 17 17:32:39 2026 +0000 btrfs: print correct subvol num if active swapfile prevents deletion [ Upstream commit 1c7e9111f4e6d6d42bc47759c9af1ef91f03ac2c ] Fix the error message in btrfs_delete_subvolume() if we can't delete a subvolume because it has an active swapfile: we were printing the number of the parent rather than the target. Fixes: 60021bd754c6 ("btrfs: prevent subvol with swapfile from being deleted") Reviewed-by: Qu Wenruo Reviewed-by: Filipe Manana Signed-off-by: Mark Harmstone Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 136e814d11766eeb6dbcdc3400161781e0a8ae2c Author: Mark Harmstone Date: Tue Feb 17 17:46:13 2026 +0000 btrfs: fix warning in scrub_verify_one_metadata() [ Upstream commit 44e2fda66427a0442d8d2c0e6443256fb458ab6b ] Commit b471965fdb2d ("btrfs: fix replace/scrub failure with metadata_uuid") fixed the comparison in scrub_verify_one_metadata() to use metadata_uuid rather than fsid, but left the warning as it was. Fix it so it matches what we're doing. Fixes: b471965fdb2d ("btrfs: fix replace/scrub failure with metadata_uuid") Reviewed-by: Qu Wenruo Signed-off-by: Mark Harmstone Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit b178561ac38cd71fadef54da5d631fc9f663fb1a Author: Mark Harmstone Date: Tue Feb 17 14:39:46 2026 +0000 btrfs: fix objectid value in error message in check_extent_data_ref() [ Upstream commit a10172780526c2002e062102ad4f2aabac495889 ] Fix a copy-paste error in check_extent_data_ref(): we're printing root as in the message above, we should be printing objectid. Fixes: f333a3c7e832 ("btrfs: tree-checker: validate dref root and objectid") Reviewed-by: Qu Wenruo Signed-off-by: Mark Harmstone Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 845c0f1ab54ef17f9b3303d6015e4a65853ac4e4 Author: Mark Harmstone Date: Tue Feb 17 10:21:44 2026 +0000 btrfs: fix incorrect key offset in error message in check_dev_extent_item() [ Upstream commit 511dc8912ae3e929c1a182f5e6b2326516fd42a0 ] Fix the error message in check_dev_extent_item(), when an overlapping stripe is encountered. For dev extents, objectid is the disk number and offset the physical address, so prev_key->objectid should actually be prev_key->offset. (I can't take any credit for this one - this was discovered by Chris and his friend Claude.) Reported-by: Chris Mason Fixes: 008e2512dc56 ("btrfs: tree-checker: add dev extent item checks") Reviewed-by: Qu Wenruo Signed-off-by: Mark Harmstone Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 5ba7d61b5416dd1bdc6f2168a9de877d3b160ecc Author: Mark Harmstone Date: Tue Feb 17 18:25:42 2026 +0000 btrfs: fix error message order of parameters in btrfs_delete_delayed_dir_index() [ Upstream commit 3cf0f35779d364cf2003c617bb7f3f3e41023372 ] Fix the error message in btrfs_delete_delayed_dir_index() if __btrfs_add_delayed_item() fails: the message says root, inode, index, error, but we're actually passing index, root, inode, error. Fixes: adc1ef55dc04 ("btrfs: add details to error messages at btrfs_delete_delayed_dir_index()") Signed-off-by: Mark Harmstone Reviewed-by: Filipe Manana Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit d4f210de01eaccac61eee657f676045ef9771d07 Author: Miquel Sabaté Solà Date: Mon Feb 16 22:12:15 2026 +0100 btrfs: free pages on error in btrfs_uring_read_extent() [ Upstream commit 3f501412f2079ca14bf68a18d80a2b7a823f1f64 ] In this function the 'pages' object is never freed in the hopes that it is picked up by btrfs_uring_read_finished() whenever that executes in the future. But that's just the happy path. Along the way previous allocations might have gone wrong, or we might not get -EIOCBQUEUED from btrfs_encoded_read_regular_fill_pages(). In all these cases, we go to a cleanup section that frees all memory allocated by this function without assuming any deferred execution, and this also needs to happen for the 'pages' allocation. Fixes: 34310c442e17 ("btrfs: add io_uring command for encoded reads (ENCODED_READ ioctl)") Signed-off-by: Miquel Sabaté Solà Reviewed-by: Filipe Manana Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit c18c40e081c197da151ba6e916aadcace5e06e2c Author: Richard Fitzgerald Date: Thu Feb 26 11:17:28 2026 +0000 ALSA: hda: cs35l56: Fix signedness error in cs35l56_hda_posture_put() [ Upstream commit 003ce8c9b2ca28fbb4860651e76fb1c9a91f2ea1 ] In cs35l56_hda_posture_put() assign ucontrol->value.integer.value[0] to a long instead of an unsigned long. ucontrol->value.integer.value[0] is a long. This fixes the sparse warning: sound/hda/codecs/side-codecs/cs35l56_hda.c:256:20: warning: unsigned value that used to be signed checked against zero? sound/hda/codecs/side-codecs/cs35l56_hda.c:252:29: signed value source Signed-off-by: Richard Fitzgerald Fixes: 73cfbfa9caea8 ("ALSA: hda/cs35l56: Add driver for Cirrus Logic CS35L56 amplifier") Link: https://patch.msgid.link/20260226111728.1700431-1-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 73e8bdf14248136459753252a438177df7ed8c7c Author: Lijo Lazar Date: Tue Feb 24 10:18:51 2026 +0530 drm/amdgpu: Fix error handling in slot reset [ Upstream commit b57c4ec98c17789136a4db948aec6daadceb5024 ] If the device has not recovered after slot reset is called, it goes to out label for error handling. There it could make decision based on uninitialized hive pointer and could result in accessing an uninitialized list. Initialize the list and hive properly so that it handles the error situation and also releases the reset domain lock which is acquired during error_detected callback. Fixes: 732c6cefc1ec ("drm/amdgpu: Replace tmp_adev with hive in amdgpu_pci_slot_reset") Signed-off-by: Lijo Lazar Reviewed-by: Ce Sun Signed-off-by: Alex Deucher (cherry picked from commit bb71362182e59caa227e4192da5a612b09349696) Signed-off-by: Sasha Levin commit 5c42d9f8b004905eb441f0eab34662bdacf3192f Author: Bart Van Assche Date: Mon Feb 23 13:50:23 2026 -0800 drm/amdgpu: Fix locking bugs in error paths [ Upstream commit 480ad5f6ead4a47b969aab6618573cd6822bb6a4 ] Do not unlock psp->ras_context.mutex if it has not been locked. This has been detected by the Clang thread-safety analyzer. Cc: Alex Deucher Cc: Christian König Cc: YiPeng Chai Cc: Hawking Zhang Cc: amd-gfx@lists.freedesktop.org Fixes: b3fb79cda568 ("drm/amdgpu: add mutex to protect ras shared memory") Acked-by: Christian König Signed-off-by: Bart Van Assche Signed-off-by: Alex Deucher (cherry picked from commit 6fa01b4335978051d2cd80841728fd63cc597970) Signed-off-by: Sasha Levin commit 39ae59e5c1d880176c41ecc2694e0ae81335079d Author: Bart Van Assche Date: Mon Feb 23 14:00:07 2026 -0800 drm/amdgpu: Unlock a mutex before destroying it [ Upstream commit 5e0bcc7b88bcd081aaae6f481b10d9ab294fcb69 ] Mutexes must be unlocked before these are destroyed. This has been detected by the Clang thread-safety analyzer. Cc: Alex Deucher Cc: Christian König Cc: Yang Wang Cc: Hawking Zhang Cc: amd-gfx@lists.freedesktop.org Fixes: f5e4cc8461c4 ("drm/amdgpu: implement RAS ACA driver framework") Reviewed-by: Yang Wang Acked-by: Christian König Signed-off-by: Bart Van Assche Signed-off-by: Alex Deucher (cherry picked from commit 270258ba320beb99648dceffb67e86ac76786e55) Signed-off-by: Sasha Levin commit 1753f5f81ab60a553287f9ee659a6ac363adf8d7 Author: Tvrtko Ursulin Date: Mon Feb 23 12:41:31 2026 +0000 drm/amdgpu/userq: Do not allow userspace to trivially triger kernel warnings [ Upstream commit 7b7d7693a55d606d700beb9549c9f7f0e5d9c24f ] Userspace can either deliberately pass in the too small num_fences, or the required number can legitimately grow between the two calls to the userq wait ioctl. In both cases we do not want the emit the kernel warning backtrace since nothing is wrong with the kernel and userspace will simply get an errno reported back. So lets simply drop the WARN_ONs. Reviewed-by: Alex Deucher Signed-off-by: Tvrtko Ursulin Fixes: a292fdecd728 ("drm/amdgpu: Implement userqueue signal/wait IOCTL") Cc: Arunpravin Paneer Selvam Cc: Christian König Cc: Alex Deucher Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 2c333ea579de6cc20ea7bc50e9595ef72863e65c) Signed-off-by: Sasha Levin commit 6f60a783860c77b309f7d81003b6a0c73feca49e Author: Niklas Cassel Date: Wed Feb 11 18:55:41 2026 +0100 PCI: dwc: ep: Flush MSI-X write before unmapping its ATU entry [ Upstream commit c22533c66ccae10511ad6a7afc34bb26c47577e3 ] Endpoint drivers use dw_pcie_ep_raise_msix_irq() to raise an MSI-X interrupt to the host using a writel(), which generates a PCI posted write transaction. There's no completion for posted writes, so the writel() may return before the PCI write completes. dw_pcie_ep_raise_msix_irq() also unmaps the outbound ATU entry used for the PCI write, so the write races with the unmap. If the PCI write loses the race with the ATU unmap, the write may corrupt host memory or cause IOMMU errors, e.g., these when running fio with a larger queue depth against nvmet-pci-epf: arm-smmu-v3 fc900000.iommu: 0x0000010000000010 arm-smmu-v3 fc900000.iommu: 0x0000020000000000 arm-smmu-v3 fc900000.iommu: 0x000000090000f040 arm-smmu-v3 fc900000.iommu: 0x0000000000000000 arm-smmu-v3 fc900000.iommu: event: F_TRANSLATION client: 0000:01:00.0 sid: 0x100 ssid: 0x0 iova: 0x90000f040 ipa: 0x0 arm-smmu-v3 fc900000.iommu: unpriv data write s1 "Input address caused fault" stag: 0x0 Flush the write by performing a readl() of the same address to ensure that the write has reached the destination before the ATU entry is unmapped. The same problem was solved for dw_pcie_ep_raise_msi_irq() in commit 8719c64e76bf ("PCI: dwc: ep: Cache MSI outbound iATU mapping"), but there it was solved by dedicating an outbound iATU only for MSI. We can't do the same for MSI-X because each vector can have a different msg_addr and the msg_addr may be changed while the vector is masked. Fixes: beb4641a787d ("PCI: dwc: Add MSI-X callbacks handler") Signed-off-by: Niklas Cassel [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Reviewed-by: Frank Li Link: https://patch.msgid.link/20260211175540.105677-2-cassel@kernel.org Signed-off-by: Sasha Levin commit 3d64dcc0799c2d6921ba027716b7be721eb19fa8 Author: Will Deacon Date: Mon Feb 23 22:10:11 2026 +0000 arm64: io: Extract user memory type in ioremap_prot() [ Upstream commit 8f098037139b294050053123ab2bc0f819d08932 ] The only caller of ioremap_prot() outside of the generic ioremap() implementation is generic_access_phys(), which passes a 'pgprot_t' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprot_t' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from ioremap_prot() which faults when accessed from the kernel on systems with PAN: | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 | ... | Call trace: | __memcpy_fromio+0x80/0xf8 | generic_access_phys+0x20c/0x2b8 | __access_remote_vm+0x46c/0x5b8 | access_remote_vm+0x18/0x30 | environ_read+0x238/0x3e8 | vfs_read+0xe4/0x2b0 | ksys_read+0xcc/0x178 | __arm64_sys_read+0x4c/0x68 Extract only the memory type from the user 'pgprot_t' in ioremap_prot() and assert that we're being passed a user mapping, to protect us against any changes in future that may require additional handling. To avoid falsely flagging users of ioremap(), provide our own ioremap() macro which simply wraps __ioremap_prot(). Cc: Zeng Heng Cc: Jinjiang Tu Cc: Catalin Marinas Fixes: 893dea9ccd08 ("arm64: Add HAVE_IOREMAP_PROT support") Reported-by: Jinjiang Tu Reviewed-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 835da0da68d0fc165b1a7a91682dc53bdcda4f51 Author: Will Deacon Date: Mon Feb 23 22:10:10 2026 +0000 arm64: io: Rename ioremap_prot() to __ioremap_prot() [ Upstream commit f6bf47ab32e0863df50f5501d207dcdddb7fc507 ] Rename our ioremap_prot() implementation to __ioremap_prot() and convert all arch-internal callers over to the new function. ioremap_prot() remains as a #define to __ioremap_prot() for generic_access_phys() and will be subsequently extended to handle user permissions in 'prot'. Cc: Zeng Heng Cc: Jinjiang Tu Cc: Catalin Marinas Reviewed-by: Catalin Marinas Signed-off-by: Will Deacon Stable-dep-of: 8f098037139b ("arm64: io: Extract user memory type in ioremap_prot()") Signed-off-by: Sasha Levin commit 00ea0c8696b40232665263ea7cd3a96fdfcc9ee4 Author: Heiko Carstens Date: Wed Feb 18 15:20:05 2026 +0100 s390/vtime: Fix virtual timer forwarding [ Upstream commit dbc0fb35679ed5d0adecf7d02137ac2c77244b3b ] Since delayed accounting of system time [1] the virtual timer is forwarded by do_account_vtime() but also vtime_account_kernel(), vtime_account_softirq(), and vtime_account_hardirq(). This leads to double accounting of system, guest, softirq, and hardirq time. Remove accounting from the vtime_account*() family to restore old behavior. There is only one user of the vtimer interface, which might explain why nobody noticed this so far. Fixes: b7394a5f4ce9 ("sched/cputime, s390: Implement delayed accounting of system time") [1] Reviewed-by: Sven Schnelle Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit d30168b0cbc132626807341538fe5ae4b9b90d2d Author: Heiko Carstens Date: Wed Feb 18 15:20:04 2026 +0100 s390/idle: Fix cpu idle exit cpu time accounting [ Upstream commit 0d785e2c324c90662baa4fe07a0d02233ff92824 ] With the conversion to generic entry [1] cpu idle exit cpu time accounting was converted from assembly to C. This introduced an reversed order of cpu time accounting. On cpu idle exit the current accounting happens with the following call chain: -> do_io_irq()/do_ext_irq() -> irq_enter_rcu() -> account_hardirq_enter() -> vtime_account_irq() -> vtime_account_kernel() vtime_account_kernel() accounts the passed cpu time since last_update_timer as system time, and updates last_update_timer to the current cpu timer value. However the subsequent call of -> account_idle_time_irq() will incorrectly subtract passed cpu time from timer_idle_enter to the updated last_update_timer value from system_timer. Then last_update_timer is updated to a sys_enter_timer, which means that last_update_timer goes back in time. Subsequently account_hardirq_exit() will account too much cpu time as hardirq time. The sum of all accounted cpu times is still correct, however some cpu time which was previously accounted as system time is now accounted as hardirq time, plus there is the oddity that last_update_timer goes back in time. Restore previous behavior by extracting cpu time accounting code from account_idle_time_irq() into a new update_timer_idle() function and call it before irq_enter_rcu(). Fixes: 56e62a737028 ("s390: convert to generic entry") [1] Reviewed-by: Sven Schnelle Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 3f89b61dd504c5b6711de9759e053b082f9abf12 Author: Peter Zijlstra Date: Tue Feb 24 13:29:09 2026 +0100 perf: Fix __perf_event_overflow() vs perf_remove_from_context() race [ Upstream commit c9bc1753b3cc41d0e01fbca7f035258b5f4db0ae ] Make sure that __perf_event_overflow() runs with IRQs disabled for all possible callchains. Specifically the software events can end up running it with only preemption disabled. This opens up a race vs perf_event_exit_event() and friends that will go and free various things the overflow path expects to be present, like the BPF program. Fixes: 592903cdcbf6 ("perf_counter: add an event_list") Reported-by: Simond Hu Signed-off-by: Peter Zijlstra (Intel) Tested-by: Simond Hu Link: https://patch.msgid.link/20260224122909.GV1395416@noisy.programming.kicks-ass.net Signed-off-by: Sasha Levin commit b9db33aafc129f89c69509d2e1d2b491b363dd3d Author: Takashi Iwai Date: Wed Feb 25 09:52:31 2026 +0100 ALSA: usb-audio: Use inclusive terms [ Upstream commit 4e9113c533acee2ba1f72fd68ee6ecd36b64484e ] Replace the remaining with inclusive terms; it's only this function name we overlooked at the previous conversion. Fixes: 53837b4ac2bd ("ALSA: usb-audio: Replace slave/master terms") Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260225085233.316306-5-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 9a6693b598435071c07a7b7f7fe53aa172d8747a Author: Takashi Iwai Date: Wed Feb 25 09:52:28 2026 +0100 ALSA: usb-audio: Cap the packet size pre-calculations [ Upstream commit 7fe8dec3f628e9779f1631576f8e693370050348 ] We calculate the possible packet sizes beforehand for adaptive and synchronous endpoints, but we didn't take care of the max frame size for those pre-calculated values. When a device or a bus limits the packet size, a high sample rate or a high number of channels may lead to the packet sizes that are larger than the given limit, which results in an error from the USB core at submitting URBs. As a simple workaround, just add the sanity checks of pre-calculated packet sizes to have the upper boundary of ep->maxframesize. Fixes: f0bd62b64016 ("ALSA: usb-audio: Improve frames size computation") Link: https://bugzilla.kernel.org/show_bug.cgi?id=221076 Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260225085233.316306-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 4e3ca5f82346cc23c0a71f1ceb006115ff6b0745 Author: Jonathan Cavitt Date: Tue Feb 24 22:12:28 2026 +0000 drm/client: Do not destroy NULL modes [ Upstream commit c601fd5414315fc515f746b499110e46272e7243 ] 'modes' in drm_client_modeset_probe may fail to kcalloc. If this occurs, we jump to 'out', calling modes_destroy on it, which dereferences it. This may result in a NULL pointer dereference in the error case. Prevent that. Fixes: 3039cc0c0653 ("drm/client: Make copies of modes") Signed-off-by: Jonathan Cavitt Cc: Ville Syrjälä Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20260224221227.69126-2-jonathan.cavitt@intel.com Signed-off-by: Sasha Levin commit 869c979f3657421a7491a3bf01ae67518983f8af Author: Christoph Hellwig Date: Tue Feb 24 06:21:45 2026 -0800 zloop: check for spurious options passed to remove [ Upstream commit 3c4617117a2b7682cf037be5e5533e379707f050 ] Zloop uses a command option parser for all control commands, but most options are only valid for adding a new device. Check for incorrectly specified options in the remove handler. Fixes: eb0570c7df23 ("block: new zoned loop block device driver") Signed-off-by: Christoph Hellwig Reviewed-by: Damien Le Moal Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f6c6a888c8a41d189538786643be59678cf7ad19 Author: Christoph Hellwig Date: Tue Feb 24 06:21:44 2026 -0800 zloop: advertise a volatile write cache [ Upstream commit 6acf7860dcc79ed045cc9e6a79c8a8bb6959dba7 ] Zloop is file system backed and thus needs to sync the underlying file system to persist data. Set BLK_FEAT_WRITE_CACHE so that the block layer actually send flush commands, and fix the flush implementation as sync_filesystem requires s_umount to be held and the code currently misses that. Fixes: eb0570c7df23 ("block: new zoned loop block device driver") Signed-off-by: Christoph Hellwig Reviewed-by: Damien Le Moal Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 93b64bef8cd4074806d981ed1b4c38c3ae0542e3 Author: Felix Gu Date: Tue Feb 24 19:19:03 2026 +0800 regulator: bq257xx: Fix device node reference leak in bq257xx_reg_dt_parse_gpio() [ Upstream commit 4baaddaa44af01cd4ce239493060738fd0881835 ] In bq257xx_reg_dt_parse_gpio(), if fails to get subchild, it returns without calling of_node_put(child), causing the device node reference leak. Fixes: 981dd162b635 ("regulator: bq257xx: Add bq257xx boost regulator driver") Signed-off-by: Felix Gu Link: https://patch.msgid.link/20260224-bq257-v1-1-8ebbc731c1c3@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit bbc104dcfc59b649843a204957527f6e8c4c49da Author: Peter Wang Date: Mon Feb 23 18:37:57 2026 +0800 scsi: ufs: core: Move link recovery for hibern8 exit failure to wl_resume [ Upstream commit 62c015373e1cdb1cdca824bd2dbce2dac0819467 ] Move the link recovery trigger from ufshcd_uic_pwr_ctrl() to __ufshcd_wl_resume(). Ensure link recovery is only attempted when hibern8 exit fails during resume, not during hibern8 enter in suspend. Improve error handling and prevent unnecessary link recovery attempts. Fixes: 35dabf4503b9 ("scsi: ufs: core: Use link recovery when h8 exit fails during runtime resume") Signed-off-by: Peter Wang Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260223103906.2533654-1-peter.wang@mediatek.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 5fc4e150c5ada5f7d20d8f9f1b351f10481fbdf7 Author: Dave Jiang Date: Thu Feb 12 14:50:38 2026 -0700 cxl: Fix race of nvdimm_bus object when creating nvdimm objects [ Upstream commit 96a1fd0d84b17360840f344826897fa71049870e ] Found issue during running of cxl-translate.sh unit test. Adding a 3s sleep right before the test seems to make the issue reproduce fairly consistently. The cxl_translate module has dependency on cxl_acpi and causes orphaned nvdimm objects to reprobe after cxl_acpi is removed. The nvdimm_bus object is registered by the cxl_nvb object when cxl_acpi_probe() is called. With the nvdimm_bus object missing, __nd_device_register() will trigger NULL pointer dereference when accessing the dev->parent that points to &nvdimm_bus->dev. [ 192.884510] BUG: kernel NULL pointer dereference, address: 000000000000006c [ 192.895383] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20250812-19.fc42 08/12/2025 [ 192.897721] Workqueue: cxl_port cxl_bus_rescan_queue [cxl_core] [ 192.899459] RIP: 0010:kobject_get+0xc/0x90 [ 192.924871] Call Trace: [ 192.925959] [ 192.926976] ? pm_runtime_init+0xb9/0xe0 [ 192.929712] __nd_device_register.part.0+0x4d/0xc0 [libnvdimm] [ 192.933314] __nvdimm_create+0x206/0x290 [libnvdimm] [ 192.936662] cxl_nvdimm_probe+0x119/0x1d0 [cxl_pmem] [ 192.940245] cxl_bus_probe+0x1a/0x60 [cxl_core] [ 192.943349] really_probe+0xde/0x380 This patch also relies on the previous change where devm_cxl_add_nvdimm_bridge() is called from drivers/cxl/pmem.c instead of drivers/cxl/core.c to ensure the dependency of cxl_acpi on cxl_pmem. 1. Set probe_type of cxl_nvb to PROBE_FORCE_SYNCHRONOUS to ensure the driver is probed synchronously when add_device() is called. 2. Add a check in __devm_cxl_add_nvdimm_bridge() to ensure that the cxl_nvb driver is attached during cxl_acpi_probe(). 3. Take the cxl_root uport_dev lock and the cxl_nvb->dev lock in devm_cxl_add_nvdimm() before checking nvdimm_bus is valid. 4. Set cxl_nvdimm flag to CXL_NVD_F_INVALIDATED so cxl_nvdimm_probe() will exit with -EBUSY. The removal of cxl_nvdimm devices should prevent any orphaned devices from probing once the nvdimm_bus is gone. [ dj: Fixed 0-day reported kdoc issue. ] [ dj: Fix cxl_nvb reference leak on error. Gregory (kreview-0811365) ] Suggested-by: Dan Williams Fixes: 8fdcb1704f61 ("cxl/pmem: Add initial infrastructure for pmem support") Tested-by: Alison Schofield Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260205001633.1813643-3-dave.jiang@intel.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit af9bf9889663902931cb0694c5df32de4de4954c Author: Dave Jiang Date: Wed Feb 11 17:31:23 2026 -0700 cxl: Move devm_cxl_add_nvdimm_bridge() to cxl_pmem.ko [ Upstream commit e7e222ad73d93fe54d6e6e3a15253a0ecf081a1b ] Moving the symbol devm_cxl_add_nvdimm_bridge() to drivers/cxl/cxl_pmem.c, so that cxl_pmem can export a symbol that gives cxl_acpi a depedency on cxl_pmem kernel module. This is a prepatory patch to resolve the issue of a race for nvdimm_bus object that is created during cxl_acpi_probe(). No functional changes besides moving code. Suggested-by: Dan Williams Acked-by: Ira Weiny Tested-by: Alison Schofield Reviewed-by: Alison Schofield Link: https://patch.msgid.link/20260205001633.1813643-2-dave.jiang@intel.com Signed-off-by: Dave Jiang Stable-dep-of: 96a1fd0d84b1 ("cxl: Fix race of nvdimm_bus object when creating nvdimm objects") Signed-off-by: Sasha Levin commit a29e6379506313e1f08546eb4bc2abd5baac8be7 Author: Waiman Long Date: Sat Feb 21 13:54:12 2026 -0500 cgroup/cpuset: Fix incorrect use of cpuset_update_tasks_cpumask() in update_cpumasks_hier() [ Upstream commit 68230aac8b9aad243626fbaf3ca170012c17fec5 ] Commit e2ffe502ba45 ("cgroup/cpuset: Add cpuset.cpus.exclusive for v2") incorrectly changed the 2nd parameter of cpuset_update_tasks_cpumask() from tmp->new_cpus to cp->effective_cpus. This second parameter is just a temporary cpumask for internal use. The cpuset_update_tasks_cpumask() function was originally called update_tasks_cpumask() before commit 381b53c3b549 ("cgroup/cpuset: rename functions shared between v1 and v2"). This mistake can incorrectly change the effective_cpus of the cpuset when it is the top_cpuset or in arm64 architecture where task_cpu_possible_mask() may differ from cpu_possible_mask. So far top_cpuset hasn't been passed to update_cpumasks_hier() yet, but arm64 arch can still be impacted. Fix it by reverting the incorrect change. Fixes: e2ffe502ba45 ("cgroup/cpuset: Add cpuset.cpus.exclusive for v2") Signed-off-by: Waiman Long Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit e540616ec3a51f0d94fff07a0eb05794caac9738 Author: Matt Roper Date: Fri Feb 6 14:30:59 2026 -0800 drm/xe/wa: Steer RMW of MCR registers while building default LRC [ Upstream commit 43d37df67f7770d8d261fdcb64ecc8c314e91303 ] When generating the default LRC, if a register is not masked, we apply any save-restore programming necessary via a read-modify-write sequence that will ensure we only update the relevant bits/fields without clobbering the rest of the register. However some of the registers that need to be updated might be MCR registers which require steering to a non-terminated instance to ensure we can read back a valid, non-zero value. The steering of reads originating from a command streamer is controlled by register CS_MMIO_GROUP_INSTANCE_SELECT. Emit additional MI_LRI commands to update the steering before any RMW of an MCR register to ensure the reads are performed properly. Note that needing to perform a RMW of an MCR register while building the default LRC is pretty rare. Most of the MCR registers that are part of an engine's LRCs are also masked registers, so no MCR is necessary. Fixes: f2f90989ccff ("drm/xe: Avoid reading RMW registers in emit_wa_job") Cc: Michal Wajdeczko Reviewed-by: Balasubramani Vivekanandan Link: https://patch.msgid.link/20260206223058.387014-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper (cherry picked from commit 6c2e331c915ba9e774aa847921262805feb00863) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 3464e751755172ddbb849c1bd92f5f59e95c59a1 Author: Lizhi Hou Date: Thu Feb 19 13:19:46 2026 -0800 accel/amdxdna: Validate command buffer payload count [ Upstream commit 901ec3470994006bc8dd02399e16b675566c3416 ] The count field in the command header is used to determine the valid payload size. Verify that the valid payload does not exceed the remaining buffer space. Fixes: aac243092b70 ("accel/amdxdna: Add command execution") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260219211946.1920485-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 1500b31db94374a6669e73ce94d6f71cf8e85e06 Author: Lizhi Hou Date: Tue Feb 17 11:28:15 2026 -0800 accel/amdxdna: Prevent ubuf size overflow [ Upstream commit 03808abb1d868aed7478a11a82e5bb4b3f1ca6d6 ] The ubuf size calculation may overflow, resulting in an undersized allocation and possible memory corruption. Use check_add_overflow() helpers to validate the size calculation before allocation. Fixes: bd72d4acda10 ("accel/amdxdna: Support user space allocated buffer") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260217192815.1784689-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 247cd87f04748f47c88ace2cfd2458642014c23e Author: Lizhi Hou Date: Thu Feb 5 22:02:37 2026 -0800 accel/amdxdna: Remove buffer size check when creating command BO [ Upstream commit 08fe1b5166fdc81b010d7bf39cd6440620e7931e ] Large command buffers may be used, and they do not always need to be mapped or accessed by the driver. Performing a size check at command BO creation time unnecessarily rejects valid use cases. Remove the buffer size check from command BO creation, and defer vmap and size validation to the paths where the driver actually needs to map and access the command buffer. Fixes: ac49797c1815 ("accel/amdxdna: Add GEM buffer object management") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260206060237.4050492-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit c67ab059953e3b66cb17ddd6524c23f9e1f6526d Author: Namhyung Kim Date: Mon Jun 2 21:51:05 2025 -0700 perf/core: Fix invalid wait context in ctx_sched_in() [ Upstream commit 486ff5ad49bc50315bcaf6d45f04a33ef0a45ced ] Lockdep found a bug in the event scheduling when a pinned event was failed and wakes up the threads in the ring buffer like below. It seems it should not grab a wait-queue lock under perf-context lock. Let's do it with irq_work. [ 39.913691] ============================= [ 39.914157] [ BUG: Invalid wait context ] [ 39.914623] 6.15.0-next-20250530-next-2025053 #1 Not tainted [ 39.915271] ----------------------------- [ 39.915731] repro/837 is trying to lock: [ 39.916191] ffff88801acfabd8 (&event->waitq){....}-{3:3}, at: __wake_up+0x26/0x60 [ 39.917182] other info that might help us debug this: [ 39.917761] context-{5:5} [ 39.918079] 4 locks held by repro/837: [ 39.918530] #0: ffffffff8725cd00 (rcu_read_lock){....}-{1:3}, at: __perf_event_task_sched_in+0xd1/0xbc0 [ 39.919612] #1: ffff88806ca3c6f8 (&cpuctx_lock){....}-{2:2}, at: __perf_event_task_sched_in+0x1a7/0xbc0 [ 39.920748] #2: ffff88800d91fc18 (&ctx->lock){....}-{2:2}, at: __perf_event_task_sched_in+0x1f9/0xbc0 [ 39.921819] #3: ffffffff8725cd00 (rcu_read_lock){....}-{1:3}, at: perf_event_wakeup+0x6c/0x470 Fixes: f4b07fd62d4d ("perf/core: Use POLLHUP for a pinned event in error") Closes: https://lore.kernel.org/lkml/aD2w50VDvGIH95Pf@ly-workstation Reported-by: "Lai, Yi" Signed-off-by: Namhyung Kim Signed-off-by: Peter Zijlstra (Intel) Tested-by: "Lai, Yi" Link: https://patch.msgid.link/20250603045105.1731451-1-namhyung@kernel.org Signed-off-by: Sasha Levin commit 9a3bcd2984b8da998e97a7c172f1291fee9102a0 Author: Mathieu Desnoyers Date: Fri Feb 20 15:06:40 2026 -0500 rseq: Clarify rseq registration rseq_size bound check comment [ Upstream commit 26d43a90be81fc90e26688a51d3ec83188602731 ] The rseq registration validates that the rseq_size argument is greater or equal to 32 (the original rseq size), but the comment associated with this check does not clearly state this. Clarify the comment to that effect. Fixes: ee3e3ac05c26 ("rseq: Introduce extensible rseq ABI") Signed-off-by: Mathieu Desnoyers Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260220200642.1317826-2-mathieu.desnoyers@efficios.com Signed-off-by: Sasha Levin commit 22a1536b3f5acfb3a5c186653a235716368e3375 Author: Peter Zijlstra Date: Tue Apr 22 12:16:28 2025 +0200 sched/fair: Fix lag clamp [ Upstream commit 6e3c0a4e1ad1e0455b7880fad02b3ee179f56c09 ] Vincent reported that he was seeing undue lag clamping in a mixed slice workload. Implement the max_slice tracking as per the todo comment. Fixes: 147f3efaa241 ("sched/fair: Implement an EEVDF-like scheduling policy") Reported-off-by: Vincent Guittot Signed-off-by: Peter Zijlstra (Intel) Tested-by: Vincent Guittot Tested-by: K Prateek Nayak Tested-by: Shubhang Kaushik Link: https://patch.msgid.link/20250422101628.GA33555@noisy.programming.kicks-ass.net Signed-off-by: Sasha Levin commit c1591343440ef1fd81c06281b8d1f9be45e90a9f Author: Wang Tao Date: Tue Jan 20 12:31:13 2026 +0000 sched/eevdf: Update se->vprot in reweight_entity() [ Upstream commit ff38424030f98976150e42ca35f4b00e6ab8fa23 ] In the EEVDF framework with Run-to-Parity protection, `se->vprot` is an independent variable defining the virtual protection timestamp. When `reweight_entity()` is called (e.g., via nice/renice), it performs the following actions to preserve Lag consistency: 1. Scales `se->vlag` based on the new weight. 2. Calls `place_entity()`, which recalculates `se->vruntime` based on the new weight and scaled lag. However, the current implementation fails to update `se->vprot`, leading to mismatches between the task's actual runtime and its expected duration. Fixes: 63304558ba5d ("sched/eevdf: Curb wakeup-preemption") Suggested-by: Zhang Qiao Signed-off-by: Wang Tao Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Vincent Guittot Tested-by: K Prateek Nayak Tested-by: Shubhang Kaushik Link: https://patch.msgid.link/20260120123113.3518950-1-wangtao554@huawei.com Signed-off-by: Sasha Levin commit ee54b5ba72d421a7d51c9d580b7b015b45ff8846 Author: Peter Zijlstra Date: Fri Jan 23 16:49:09 2026 +0100 sched/fair: Only set slice protection at pick time [ Upstream commit bcd74b2ffdd0a2233adbf26b65c62fc69a809c8e ] We should not (re)set slice protection in the sched_change pattern which calls put_prev_task() / set_next_task(). Fixes: 63304558ba5d ("sched/eevdf: Curb wakeup-preemption") Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Vincent Guittot Tested-by: K Prateek Nayak Tested-by: Shubhang Kaushik Link: https://patch.msgid.link/20260219080624.561421378%40infradead.org Signed-off-by: Sasha Levin commit 99673934a89febe664e704550216638dcb2336a8 Author: Peter Zijlstra Date: Mon Feb 9 15:28:16 2026 +0100 sched/fair: Fix zero_vruntime tracking [ Upstream commit b3d99f43c72b56cf7a104a364e7fb34b0702828b ] It turns out that zero_vruntime tracking is broken when there is but a single task running. Current update paths are through __{en,de}queue_entity(), and when there is but a single task, pick_next_task() will always return that one task, and put_prev_set_next_task() will end up in neither function. This can cause entity_key() to grow indefinitely large and cause overflows, leading to much pain and suffering. Furtermore, doing update_zero_vruntime() from __{de,en}queue_entity(), which are called from {set_next,put_prev}_entity() has problems because: - set_next_entity() calls __dequeue_entity() before it does cfs_rq->curr = se. This means the avg_vruntime() will see the removal but not current, missing the entity for accounting. - put_prev_entity() calls __enqueue_entity() before it does cfs_rq->curr = NULL. This means the avg_vruntime() will see the addition *and* current, leading to double accounting. Both cases are incorrect/inconsistent. Noting that avg_vruntime is already called on each {en,de}queue, remove the explicit avg_vruntime() calls (which removes an extra 64bit division for each {en,de}queue) and have avg_vruntime() update zero_vruntime itself. Additionally, have the tick call avg_vruntime() -- discarding the result, but for the side-effect of updating zero_vruntime. While there, optimize avg_vruntime() by noting that the average of one value is rather trivial to compute. Test case: # taskset -c -p 1 $$ # taskset -c 2 bash -c 'while :; do :; done&' # cat /sys/kernel/debug/sched/debug | awk '/^cpu#/ {P=0} /^cpu#2,/ {P=1} {if (P) print $0}' | grep -e zero_vruntime -e "^>" PRE: .zero_vruntime : 31316.407903 >R bash 487 50787.345112 E 50789.145972 2.800000 50780.298364 16 120 0.000000 0.000000 0.000000 / .zero_vruntime : 382548.253179 >R bash 487 427275.204288 E 427276.003584 2.800000 427268.157540 23 120 0.000000 0.000000 0.000000 / POST: .zero_vruntime : 17259.709467 >R bash 526 17259.709467 E 17262.509467 2.800000 16915.031624 9 120 0.000000 0.000000 0.000000 / .zero_vruntime : 18702.723356 >R bash 526 18702.723356 E 18705.523356 2.800000 18358.045513 9 120 0.000000 0.000000 0.000000 / Fixes: 79f3f9bedd14 ("sched/eevdf: Fix min_vruntime vs avg_vruntime") Reported-by: K Prateek Nayak Signed-off-by: Peter Zijlstra (Intel) Tested-by: K Prateek Nayak Tested-by: Shubhang Kaushik Link: https://patch.msgid.link/20260219080624.438854780%40infradead.org Signed-off-by: Sasha Levin commit 423b750d87d2e162139c53be709a60a59829f928 Author: Ingo Molnar Date: Tue Dec 2 16:10:32 2025 +0100 sched/fair: Introduce and use the vruntime_cmp() and vruntime_op() wrappers for wrapped-signed aritmetics [ Upstream commit 5758e48eefaf111d7764d8f1c8b666140fe5fa27 ] We have to be careful with vruntime comparisons and subtraction, due to the possibility of wrapping, so we have macros like: #define vruntime_gt(field, lse, rse) ({ (s64)((lse)->field - (rse)->field) > 0; }) Which is used like this: if (vruntime_gt(min_vruntime, se, rse)) se->min_vruntime = rse->min_vruntime; Replace this with an easier to read pattern that uses the regular arithmetics operators: if (vruntime_cmp(se->min_vruntime, ">", rse->min_vruntime)) se->min_vruntime = rse->min_vruntime; Also replace vruntime subtractions with vruntime_op(): - delta = (s64)(sea->vruntime - seb->vruntime) + - (s64)(cfs_rqb->zero_vruntime_fi - cfs_rqa->zero_vruntime_fi); + delta = vruntime_op(sea->vruntime, "-", seb->vruntime) + + vruntime_op(cfs_rqb->zero_vruntime_fi, "-", cfs_rqa->zero_vruntime_fi); In the vruntime_cmp() and vruntime_op() macros use Use __builtin_strcmp(), because of __HAVE_ARCH_STRCMP might turn off the compiler optimizations we rely on here to catch usage bugs. No change in functionality. Signed-off-by: Ingo Molnar Stable-dep-of: b3d99f43c72b ("sched/fair: Fix zero_vruntime tracking") Signed-off-by: Sasha Levin commit 028084eca16915b66946671219810f538d269309 Author: Ingo Molnar Date: Tue Dec 2 16:09:23 2025 +0100 sched/fair: Rename cfs_rq::avg_vruntime to ::sum_w_vruntime, and helper functions [ Upstream commit dcbc9d3f0e594223275a18f7016001889ad35eff ] The ::avg_vruntime field is a misnomer: it says it's an 'average vruntime', but in reality it's the momentary sum of the weighted vruntimes of all queued tasks, which is at least a division away from being an average. This is clear from comments about the math of fair scheduling: * \Sum (v_i - v0) * w_i := cfs_rq->avg_vruntime This confusion is increased by the cfs_avg_vruntime() function, which does perform the division and returns a true average. The sum of all weighted vruntimes should be named thusly, so rename the field to ::sum_w_vruntime. (As arguably ::sum_weighted_vruntime would be a bit of a mouthful.) Understanding the scheduler is hard enough already, without extra layers of obfuscated naming. ;-) Also rename related helper functions: sum_vruntime_add() => sum_w_vruntime_add() sum_vruntime_sub() => sum_w_vruntime_sub() sum_vruntime_update() => sum_w_vruntime_update() With the notable exception of cfs_avg_vruntime(), which was named accurately. Signed-off-by: Ingo Molnar Link: https://patch.msgid.link/20251201064647.1851919-7-mingo@kernel.org Stable-dep-of: b3d99f43c72b ("sched/fair: Fix zero_vruntime tracking") Signed-off-by: Sasha Levin commit 50890a9a01f34037ac3ec2541ddae5ded6ba320f Author: Ingo Molnar Date: Wed Nov 26 12:09:16 2025 +0100 sched/fair: Rename cfs_rq::avg_load to cfs_rq::sum_weight [ Upstream commit 4ff674fa986c27ec8a0542479258c92d361a2566 ] The ::avg_load field is a long-standing misnomer: it says it's an 'average load', but in reality it's the momentary sum of the load of all currently runnable tasks. We'd have to also perform a division by nr_running (or use time-decay) to arrive at any sort of average value. This is clear from comments about the math of fair scheduling: * \Sum w_i := cfs_rq->avg_load The sum of all weights is ... the sum of all weights, not the average of all weights. To make it doubly confusing, there's also an ::avg_load in the load-balancing struct sg_lb_stats, which *is* a true average. The second part of the field's name is a minor misnomer as well: it says 'load', and it is indeed a load_weight structure as it shares code with the load-balancer - but it's only in an SMP load-balancing context where load = weight, in the fair scheduling context the primary purpose is the weighting of different nice levels. So rename the field to ::sum_weight instead, which makes the terminology of the EEVDF math match up with our implementation of it: * \Sum w_i := cfs_rq->sum_weight Signed-off-by: Ingo Molnar Link: https://patch.msgid.link/20251201064647.1851919-6-mingo@kernel.org Stable-dep-of: b3d99f43c72b ("sched/fair: Fix zero_vruntime tracking") Signed-off-by: Sasha Levin commit 50b3d683dcd4564b7b2bda0345ecfa878439a094 Author: Peter Zijlstra Date: Wed Feb 11 13:59:43 2026 +0100 x86/cfi: Fix CFI rewrite for odd alignments [ Upstream commit 24c8147abb39618d74fcc36e325765e8fe7bdd7a ] Rustam reported his clang builds did not boot properly; turns out his .config has: CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_64B=y set. Fix up the FineIBT code to deal with this unusual alignment. Fixes: 931ab63664f0 ("x86/ibt: Implement FineIBT") Reported-by: Rustam Kovhaev Signed-off-by: Peter Zijlstra (Intel) Tested-by: Rustam Kovhaev Signed-off-by: Sasha Levin commit e58f1a9b0677de24dcfee0b21393446ec92ff120 Author: Andrew Cooper Date: Tue Jan 6 13:15:04 2026 +0000 x86/fred: Correct speculative safety in fred_extint() [ Upstream commit aa280a08e7d8fae58557acc345b36b3dc329d595 ] array_index_nospec() is no use if the result gets spilled to the stack, as it makes the believed safe-under-speculation value subject to memory predictions. For all practical purposes, this means array_index_nospec() must be used in the expression that accesses the array. As the code currently stands, it's the wrong side of irqentry_enter(), and 'index' is put into %ebp across the function call. Remove the index variable and reposition array_index_nospec(), so it's calculated immediately before the array access. Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code") Signed-off-by: Andrew Cooper Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260106131504.679932-1-andrew.cooper3@citrix.com Signed-off-by: Sasha Levin commit ddbbdebeeea80fb7943f2e83fbcc6369b8506979 Author: Geoffrey D. Bennett Date: Sat Feb 21 02:36:35 2026 +1030 ALSA: usb-audio: Add QUIRK_FLAG_SKIP_IFACE_SETUP [ Upstream commit 38c322068a26a01d7ff64da92179e68cdde9860b ] Add a quirk flag to skip the usb_set_interface(), snd_usb_init_pitch(), and snd_usb_init_sample_rate() calls in __snd_usb_parse_audio_interface(). These are redundant with snd_usb_endpoint_prepare() at stream-open time. Enable the quirk for Focusrite devices, as init_sample_rate(rate_max) sets 192kHz during probing, which disables the internal mixer and Air and Safe modes. Fixes: 16f1f838442d ("Revert "ALSA: usb-audio: Drop superfluous interface setup at parsing"") Signed-off-by: Geoffrey D. Bennett Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/65a7909b15f9feb76c2a6f4f8814c240ddc50737.1771594828.git.g@b4.vu Signed-off-by: Sasha Levin commit 71f72c5d74a989e10c58f1317032cbf1e2b1388b Author: Geoffrey D. Bennett Date: Sat Feb 21 02:34:48 2026 +1030 ALSA: usb-audio: Remove VALIDATE_RATES quirk for Focusrite devices [ Upstream commit a8cc55bf81a45772cad44c83ea7bb0e98431094a ] Remove QUIRK_FLAG_VALIDATE_RATES for Focusrite. With the previous commit, focusrite_valid_sample_rate() produces correct rate tables without USB probing. QUIRK_FLAG_VALIDATE_RATES sends SET_CUR requests for each rate (~25ms each) and leaves the device at 192kHz. This is a problem because that rate: 1) disables the internal mixer, so outputs are silent until an application opens the PCM and sets a lower rate, and 2) the Air and Safe modes get disabled. Fixes: 5963e5262180 ("ALSA: usb-audio: Enable rate validation for Scarlett devices") Signed-off-by: Geoffrey D. Bennett Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/09b9c012024c998c4ca14bd876ef0dce0d0b6101.1771594828.git.g@b4.vu Signed-off-by: Sasha Levin commit 561cefafd79dc04d532b320336143bacc30adb7a Author: Geoffrey D. Bennett Date: Fri Feb 20 21:58:48 2026 +1030 ALSA: scarlett2: Fix DSP filter control array handling [ Upstream commit 1d241483368f2fd87fbaba64d6aec6bad3a1e12e ] scarlett2_add_dsp_ctls() was incorrectly storing the precomp and PEQ filter coefficient control pointers into the precomp_flt_switch_ctls and peq_flt_switch_ctls arrays instead of the intended targets precomp_flt_ctls and peq_flt_ctls. Pass NULL instead, as the filter coefficient control pointers are not used, and remove the unused precomp_flt_ctls and peq_flt_ctls arrays from struct scarlett2_data. Additionally, scarlett2_update_filter_values() was reading dsp_input_count * peq_flt_count values for SCARLETT2_CONFIG_PEQ_FLT_SWITCH, but the peq_flt_switch array is indexed only by dsp_input_count (one switch per DSP input, not per filter). Fix the read count. Fixes: b64678eb4e70 ("ALSA: scarlett2: Add DSP controls") Signed-off-by: Geoffrey D. Bennett Link: https://patch.msgid.link/86497b71db060677d97c38a6ce5f89bb3b25361b.1771581197.git.g@b4.vu Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 38072446442c76e4785e2084085dbb5dbc2b6f4c Author: Chen Ni Date: Wed Feb 4 17:06:29 2026 +0800 drm/imx: parallel-display: check return value of devm_drm_bridge_add() in imx_pd_probe() [ Upstream commit c5f8658f97ec392eeaf355d4e9775ae1f23ca1d3 ] Return the value of devm_drm_bridge_add() in order to propagate the error properly, if it fails due to resource allocation failure or bridge registration failure. This ensures that the probe function fails safely rather than proceeding with a potentially incomplete bridge setup. Fixes: bf7e97910b9f ("drm/imx: parallel-display: add the bridge before attaching it") Signed-off-by: Chen Ni Reviewed-by: Luca Ceresoli Link: https://patch.msgid.link/20260204090629.2209542-1-nichen@iscas.ac.cn Signed-off-by: Luca Ceresoli Signed-off-by: Sasha Levin commit 824a7672e3540962d5c77d4c6666254d7aa6f0b3 Author: Salomon Dushimirimana Date: Fri Feb 13 19:28:06 2026 +0000 scsi: pm8001: Fix use-after-free in pm8001_queue_command() [ Upstream commit 38353c26db28efd984f51d426eac2396d299cca7 ] Commit e29c47fe8946 ("scsi: pm8001: Simplify pm8001_task_exec()") refactors pm8001_queue_command(), however it introduces a potential cause of a double free scenario when it changes the function to return -ENODEV in case of phy down/device gone state. In this path, pm8001_queue_command() updates task status and calls task_done to indicate to upper layer that the task has been handled. However, this also frees the underlying SAS task. A -ENODEV is then returned to the caller. When libsas sas_ata_qc_issue() receives this error value, it assumes the task wasn't handled/queued by LLDD and proceeds to clean up and free the task again, resulting in a double free. Since pm8001_queue_command() handles the SAS task in this case, it should return 0 to the caller indicating that the task has been handled. Fixes: e29c47fe8946 ("scsi: pm8001: Simplify pm8001_task_exec()") Signed-off-by: Salomon Dushimirimana Reviewed-by: Damien Le Moal Link: https://patch.msgid.link/20260213192806.439432-1-salomondush@google.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c3598e86c916d7d568fe3a15d52946f36b0c7531 Author: Mathias Krause Date: Thu Feb 12 11:23:27 2026 -0800 scsi: lpfc: Properly set WC for DPP mapping [ Upstream commit bffda93a51b40afd67c11bf558dc5aae83ca0943 ] Using set_memory_wc() to enable write-combining for the DPP portion of the MMIO mapping is wrong as set_memory_*() is meant to operate on RAM only, not MMIO mappings. In fact, as used currently triggers a BUG_ON() with enabled CONFIG_DEBUG_VIRTUAL. Simply map the DPP region separately and in addition to the already existing mappings, avoiding any possible negative side effects for these. Fixes: 1351e69fc6db ("scsi: lpfc: Add push-to-adapter support to sli4") Signed-off-by: Mathias Krause Signed-off-by: Justin Tee Reviewed-by: Mathias Krause Link: https://patch.msgid.link/20260212192327.141104-1-justintee8345@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1883332bf21feb8871af09daf604fc4836a76925 Author: Nam Cao Date: Thu Feb 12 12:41:25 2026 +0100 irqchip/sifive-plic: Fix frozen interrupt due to affinity setting [ Upstream commit 1072020685f4b81f6efad3b412cdae0bd62bb043 ] PLIC ignores interrupt completion message for disabled interrupt, explained by the specification: The PLIC signals it has completed executing an interrupt handler by writing the interrupt ID it received from the claim to the claim/complete register. The PLIC does not check whether the completion ID is the same as the last claim ID for that target. If the completion ID does not match an interrupt source that is currently enabled for the target, the completion is silently ignored. This caused problems in the past, because an interrupt can be disabled while still being handled and plic_irq_eoi() had no effect. That was fixed by checking if the interrupt is disabled, and if so enable it, before sending the completion message. That check is done with irqd_irq_disabled(). However, that is not sufficient because the enable bit for the handling hart can be zero despite irqd_irq_disabled(d) being false. This can happen when affinity setting is changed while a hart is still handling the interrupt. This problem is easily reproducible by dumping a large file to uart (which generates lots of interrupts) and at the same time keep changing the uart interrupt's affinity setting. The uart port becomes frozen almost instantaneously. Fix this by checking PLIC's enable bit instead of irqd_irq_disabled(). Fixes: cc9f04f9a84f ("irqchip/sifive-plic: Implement irq_set_affinity() for SMP host") Signed-off-by: Nam Cao Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260212114125.3148067-1-namcao@linutronix.de Signed-off-by: Sasha Levin commit 183a6264b32e40a62a2fd9446c4bac10ed5009cb Author: Ethan Tidmore Date: Sun Feb 15 22:04:38 2026 -0600 drm/tiny: sharp-memory: fix pointer error dereference [ Upstream commit 46120745bb4e7e1f09959624716b4c5d6e2c2e9e ] The function devm_drm_dev_alloc() returns a pointer error upon failure not NULL. Change null check to pointer error check. Detected by Smatch: drivers/gpu/drm/tiny/sharp-memory.c:549 sharp_memory_probe() error: 'smd' dereferencing possible ERR_PTR() Fixes: b8f9f21716fec ("drm/tiny: Add driver for Sharp Memory LCD") Signed-off-by: Ethan Tidmore Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260216040438.43702-1-ethantidmore06@gmail.com Signed-off-by: Sasha Levin commit cd2713a37336d839027f60ecb3964f1c595991bf Author: Simon Ser Date: Sun Feb 8 22:47:26 2026 +0000 drm/fourcc: fix plane order for 10/12/16-bit YCbCr formats [ Upstream commit e9e0b48cd15b46dcb2bbc165f6b0fee698b855d6 ] The short comments had the correct order, but the long comments had the planes reversed. Fixes: 2271e0a20ef7 ("drm: drm_fourcc: add 10/12/16bit software decoder YCbCr formats") Signed-off-by: Simon Ser Reviewed-by: Daniel Stone Reviewed-by: Robert Mader Link: https://patch.msgid.link/20260208224718.57199-1-contact@emersion.fr Signed-off-by: Sasha Levin commit bce3847f7c51b86332bf2e554c9e80ca3820f16c Author: Fuad Tabba Date: Fri Feb 13 14:38:14 2026 +0000 KVM: arm64: Fix ID register initialization for non-protected pKVM guests [ Upstream commit 7e7c2cf0024d89443a7af52e09e47b1fe634ab17 ] In protected mode, the hypervisor maintains a separate instance of the `kvm` structure for each VM. For non-protected VMs, this structure is initialized from the host's `kvm` state. Currently, `pkvm_init_features_from_host()` copies the `KVM_ARCH_FLAG_ID_REGS_INITIALIZED` flag from the host without the underlying `id_regs` data being initialized. This results in the hypervisor seeing the flag as set while the ID registers remain zeroed. Consequently, `kvm_has_feat()` checks at EL2 fail (return 0) for non-protected VMs. This breaks logic that relies on feature detection, such as `ctxt_has_tcrx()` for TCR2_EL1 support. As a result, certain system registers (e.g., TCR2_EL1, PIR_EL1, POR_EL1) are not saved/restored during the world switch, which could lead to state corruption. Fix this by explicitly copying the ID registers from the host `kvm` to the hypervisor `kvm` for non-protected VMs during initialization, since we trust the host with its non-protected guests' features. Also ensure `KVM_ARCH_FLAG_ID_REGS_INITIALIZED` is cleared initially in `pkvm_init_features_from_host` so that `vm_copy_id_regs` can properly initialize them and set the flag once done. Fixes: 41d6028e28bd ("KVM: arm64: Convert the SVE guest vcpu flag to a vm flag") Signed-off-by: Fuad Tabba Link: https://patch.msgid.link/20260213143815.1732675-4-tabba@google.com Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit 7a15a1e3228dbf92103b3af5deaf1f6f4a0978dd Author: Fuad Tabba Date: Fri Feb 13 14:38:12 2026 +0000 KVM: arm64: Hide S1POE from guests when not supported by the host [ Upstream commit f66857bafd4f151c5cc6856e47be2e12c1721e43 ] When CONFIG_ARM64_POE is disabled, KVM does not save/restore POR_EL1. However, ID_AA64MMFR3_EL1 sanitisation currently exposes the feature to guests whenever the hardware supports it, ignoring the host kernel configuration. If a guest detects this feature and attempts to use it, the host will fail to context-switch POR_EL1, potentially leading to state corruption. Fix this by masking ID_AA64MMFR3_EL1.S1POE in the sanitised system registers, preventing KVM from advertising the feature when the host does not support it (i.e. system_supports_poe() is false). Fixes: 70ed7238297f ("KVM: arm64: Sanitise ID_AA64MMFR3_EL1") Signed-off-by: Fuad Tabba Link: https://patch.msgid.link/20260213143815.1732675-2-tabba@google.com Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit f8a6eba20edb938166b26e133cc61306e1bc6de9 Author: Felix Gu Date: Fri Jan 30 00:21:19 2026 +0800 drm/logicvc: Fix device node reference leak in logicvc_drm_config_parse() [ Upstream commit fef0e649f8b42bdffe4a916dd46e1b1e9ad2f207 ] The logicvc_drm_config_parse() function calls of_get_child_by_name() to find the "layers" node but fails to release the reference, leading to a device node reference leak. Fix this by using the __free(device_node) cleanup attribute to automatic release the reference when the variable goes out of scope. Fixes: efeeaefe9be5 ("drm: Add support for the LogiCVC display controller") Signed-off-by: Felix Gu Reviewed-by: Luca Ceresoli Reviewed-by: Kory Maincent Link: https://patch.msgid.link/20260130-logicvc_drm-v1-1-04366463750c@gmail.com Signed-off-by: Luca Ceresoli Signed-off-by: Sasha Levin commit a473c09666f0c03de02158876fa6241fa866c9dd Author: Thomas Gleixner Date: Sat Feb 7 14:27:05 2026 +0100 debugobject: Make it work with deferred page initialization - again [ Upstream commit fd3634312a04f336dcbfb481060219f0cd320738 ] debugobjects uses __GFP_HIGH for allocations as it might be invoked within locked regions. That worked perfectly fine until v6.18. It still works correctly when deferred page initialization is disabled and works by chance when no page allocation is required before deferred page initialization has completed. Since v6.18 allocations w/o a reclaim flag cause new_slab() to end up in alloc_frozen_pages_nolock_noprof(), which returns early when deferred page initialization has not yet completed. As the deferred page initialization takes quite a while the debugobject pool is depleted and debugobjects are disabled. This can be worked around when PREEMPT_COUNT is enabled as that allows debugobjects to add __GFP_KSWAPD_RECLAIM to the GFP flags when the context is preemtible. When PREEMPT_COUNT is disabled the context is unknown and the reclaim bit can't be set because the caller might hold locks which might deadlock in the allocator. In preemptible context the reclaim bit is harmless and not a performance issue as that's usually invoked from slow path initialization context. That makes debugobjects depend on PREEMPT_COUNT || !DEFERRED_STRUCT_PAGE_INIT. Fixes: af92793e52c3 ("slab: Introduce kmalloc_nolock() and kfree_nolock().") Signed-off-by: Thomas Gleixner Tested-by: Sebastian Andrzej Siewior Acked-by: Alexei Starovoitov Acked-by: Vlastimil Babka Link: https://patch.msgid.link/87pl6gznti.ffs@tglx Signed-off-by: Sasha Levin commit 531f45589787799aa81b63e1e1f8e71db5d93dd1 Author: Ian Forbes Date: Tue Jan 13 11:53:57 2026 -0600 drm/vmwgfx: Return the correct value in vmw_translate_ptr functions [ Upstream commit 5023ca80f9589295cb60735016e39fc5cc714243 ] Before the referenced fixes these functions used a lookup function that returned a pointer. This was changed to another lookup function that returned an error code with the pointer becoming an out parameter. The error path when the lookup failed was not changed to reflect this change and the code continued to return the PTR_ERR of the now uninitialized pointer. This could cause the vmw_translate_ptr functions to return success when they actually failed causing further uninitialized and OOB accesses. Reported-by: Kuzey Arda Bulut Fixes: a309c7194e8a ("drm/vmwgfx: Remove rcu locks from user resources") Signed-off-by: Ian Forbes Reviewed-by: Zack Rusin Signed-off-by: Zack Rusin Link: https://patch.msgid.link/20260113175357.129285-1-ian.forbes@broadcom.com Signed-off-by: Sasha Levin commit 2633a30eb45bcf22af46cd272dcb4bfe7a6396bb Author: Brad Spengler Date: Wed Jan 7 12:12:36 2026 -0500 drm/vmwgfx: Fix invalid kref_put callback in vmw_bo_dirty_release [ Upstream commit 211ecfaaef186ee5230a77d054cdec7fbfc6724a ] The kref_put() call uses (void *)kvfree as the release callback, which is incorrect. kref_put() expects a function with signature void (*release)(struct kref *), but kvfree has signature void (*)(const void *). Calling through an incompatible function pointer is undefined behavior. The code only worked by accident because ref_count is the first member of vmw_bo_dirty, making the kref pointer equal to the struct pointer. Fix this by adding a proper release callback that uses container_of() to retrieve the containing structure before freeing. Fixes: c1962742ffff ("drm/vmwgfx: Use kref in vmw_bo_dirty") Signed-off-by: Brad Spengler Signed-off-by: Zack Rusin Cc: Ian Forbes Link: https://patch.msgid.link/20260107171236.3573118-1-zack.rusin@broadcom.com Signed-off-by: Sasha Levin commit c27dea9f50ed525facb62ef647dddc4722456e07 Author: Haocheng Yu Date: Tue Feb 3 00:20:56 2026 +0800 perf/core: Fix refcount bug and potential UAF in perf_mmap commit 77de62ad3de3967818c3dbe656b7336ebee461d2 upstream. Syzkaller reported a refcount_t: addition on 0; use-after-free warning in perf_mmap. The issue is caused by a race condition between a failing mmap() setup and a concurrent mmap() on a dependent event (e.g., using output redirection). In perf_mmap(), the ring_buffer (rb) is allocated and assigned to event->rb with the mmap_mutex held. The mutex is then released to perform map_range(). If map_range() fails, perf_mmap_close() is called to clean up. However, since the mutex was dropped, another thread attaching to this event (via inherited events or output redirection) can acquire the mutex, observe the valid event->rb pointer, and attempt to increment its reference count. If the cleanup path has already dropped the reference count to zero, this results in a use-after-free or refcount saturation warning. Fix this by extending the scope of mmap_mutex to cover the map_range() call. This ensures that the ring buffer initialization and mapping (or cleanup on failure) happens atomically effectively, preventing other threads from accessing a half-initialized or dying ring buffer. Closes: https://lore.kernel.org/oe-kbuild-all/202602020208.m7KIjdzW-lkp@intel.com/ Reported-by: kernel test robot Signed-off-by: Haocheng Yu Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260202162057.7237-1-yuhaocheng035@gmail.com Signed-off-by: Greg Kroah-Hartman